1 Einleitung
1.1 Motivation
1.2 Umfeld - XXXX
1.2.1 XXXX
1.2.2 XXXX
1.2.3 XXXX
1.2.4 XXXX
1.2.5 XXXX
1.2.6 XXXX
1.2.7 XXXX
1.3 Beschreibung des Aufbaus der restlichen Arbeit
1.4 Zeitplan
1.4.1 Vorgänge mit Aufwandsschätzung
1.4.2 Meilenstein Netzplan
1.4.3 MPM Netzplan

2 Theoretische Grundlagen, Wichtige Begriffe
2.1 Die Programmiersprache JAVA
2.1.1 Geschichte von Java
2.1.2 Projektbezug
2.2 AWT - Abstract Window Toolkit
2.2.1 Projektbezug
2.3 Swing
2.3.1 Projektbezug
2.4 SWT
2.4.1 Projektbezug
2.5 XML - Extensible Markup Language
2.5.1 Entwicklung von XML
2.5.2 Verarbeitung von XML
2.5.3 Sprachen, um XML Dateien zu beschreiben
2.5.4 Vorteile von XML
2.5.5 Projektbezug
2.6 Framework

3 Anforderungsanalyse
3.1 Einführung
3.2 Systemidee
3.3 Stakeholder
3.4 Interessen der Anforderungsbeitragenden
3.5 Beschreibung der Anforderungen
3.5.1 Probleme und Ziele
3.5.2 Funktionale Anforderungen
3.5.3 Randbedingungen(Gesetze, Standards)
3.5.4 Qualitätsanforderungen
3.5.5 Testanforderungen
3.5.6 Abnahmekriterien

4 Das aktuelle System der SSE
4.1 Was ist die SSE
4.2 Grob Konzept
4.3 Was leistet das System im Bezug auf die Problemstellung

5 Eclipse
5.1 Einführung
5.2 Bedeutung als integrierte Entwicklungsumgebung
5.3 Grobkonzept
5.4 Die Plattform
5.4.1 Platform Runtime
5.4.2 Eclipse Platform
5.4.3 Workspace
5.4.4 Workbench
5.4.5 Team
5.4.6 Help
5.4.7 JDE
5.4.8 PDE
5.5 API
5.6 Erweiterungsregeln
5.6.1 Erweiterer
5.6.2 Enabler
5.6.3 Veröffentlicher
5.7 Plug-In Entwicklung
5.7.1 Bestimmung der Integrationspunkte eines Plug-Ins
5.7.2 Anforderungsbestimmung der Erweiterungspunkte
5.7.3 Deklarieren der Plug-In-Manifest Datei
5.7.4 Plug-In-Klasse definieren
5.7.5 Plug-In installieren
5.8 Features und Aufbauen einer eclipsebasierten Anwendung
5.8.1 Typen
5.8.2 Featuredefinition
5.9 Produkt

6 NetBeans
6.1 Einführung
6.1.1 Beispielanwendung ECSI MINEX V
6.1.2 Beispielanwendung Project XEMO
6.2 Features
6.2.1 Benutzerschnittstellenmanagement (User interface management)
6.2.2 Daten- und Darstellungsmanagement (Data and presentation management)
6.2.3 Der Editor
6.2.4 Einstellung Management (Setting management)
6.2.5 Das Wizard Framework
6.2.6 Konfigurationsmanagement (Configuration management)
6.2.7 Speicherplatzverwaltung(Storage management)
6.2.8 Plattformunabhängigkeit (Cross-platform)
6.2.9 Modularität
6.3 Warum NetBeans nicht weiter betrachtet wird

7 JavaBeans
7.1 Einführung
7.2 Grundlagen und Konzepte
7.2.1 JavaBeans vs. Java-Klassen
7.2.2 Ereignisse
7.2.3 Persistenz
7.2.4 Reflection
7.2.5 Introspection
7.2.6 Customizer
7.3 InfoBus
7.3.1 Anmelden am InfoBus
7.3.2 Warten auf Ereignisse
7.3.3 Kommunikation beim Datenaustausch
7.3.4 Datenübertragung
7.3.5 Änderung der Daten
7.4 Container und Personalisierung

8 Wie können die Anforderungen gelöst werden
8.1 Eclipse
8.1.1 Untersuchung der Anforderungen
8.1.2 Swing Versus SWT
8.1.3 Ergebnis der Betrachtung für Eclipse
8.2 JavaBeans und InfoBus
8.2.1 Untersuchung der Anforderungen
8.2.2 Ergebnisse der Betrachtung für JavaBeans und InfoBus
8.3 NetBeans
8.4 Welche Lösung wurde gewählt

9 Modellierungen der Lösung
9.1 Idee
9.2 Der Kern der Anwendung
9.2.1 Klassendiagramm
9.2.2 Sequenzdiagramm der main() Methode
9.3 Die Personalisierung
9.3.1 appConfig.xml
9.3.2 Modulkonfig-Datei
9.3.3 Das Package de.einsundeins.ccsys.rcf.configdocuments
9.4 Das Anwendungs-Fenster (de.einsundeins.ccsys.rcf.swing)
9.4.1 Klassendiagramm
9.5 Kommunikation der Komponenten
9.5.1 InfoBus Kommunikation im RCF
9.5.2 Warum wurde der InfoBus nicht verwendet
9.5.3 Kommunikation mit de.einsundeins.ccsys.rcf.beanCommunication
9.6 Prototyp
9.6.1 Prototyp „rcfMitInfoBus“
9.6.2 Prototyp „rcf“

10 Evaluierung der Ergebnisse
10.1 Wurde die Zielsetzung erreicht
10.1.1 Funktionale Anforderungen
10.2 Wie kann die neue Lösung in die aktuelle Lösung einfliesen

11 Zusammenfassung/Ausblick
11.1 Zeitplanung
11.2 Evaluierung
11.3 Modellierung der eigenen Lösung
11.3.1 Neue Funktionalitäten des RCF’s
11.3.2 Grafische Funktionalität des RCF’s
11.3.3 BeanCommunication des RCF’s

12 Verzeichnisse
12.1 Literaturverzeichnis
12.1.1 Bücher
12.1.2 Onlinedokumente
12.2 Abbildungsverzeichnis
12.3 Abkürzungsverzeichnis

13 Anhänge
13.1 Ehrenwörtliche Erklärung
13.2 Code Fragmente
13.2.1 Quellcode zu Kapitel 4.1.4
13.3 XML Konfigurationsdatei Beispiele
13.3.1 appConfig.xml
13.3.2 Bean1.xml
13.4 Eclipse API
13.5 Screenshots
13.5.1 SSE

---

1 Einleitung
1.1 Motivation
1.3 Beschreibung des Aufbaus der restlichen Arbeit
Es muss evaluiert werden, ob es schon Lösungen für das Problem gibt. Danach gilt es zu klären, ob es sinnvoll ist, diese Lösungen zu nutzen.
Man geht davon aus, dass eine komponentenbasierte Lösung gefunden werden kann. Hier besteht das Hauptproblem in der Kommunikation der Komponenten. Des Weiteren die Konfiguration des Layouts.
1.4 Zeitplan
Die Vorgänge im Zeitplan des Projektes orientieren sich stark am Aufbau der Arbeit. Dieser orientiert sich natürlich an der Lösung der Aufgabenstellung. Zur Zeitplanung wurde die Netzplantechnik gewählt. Netzpläne werden nach [1] häufig im Rahmen des Projektmanagement eingesetzt. Hier eignen sie sich besonders zur Projektfortschrittskontrolle.
1.4.3 MPM Netzplan
3.4 Interessen der Anforderungsbeitragenden
XXXX (Anforderungsverantwortlicher):
Nach Meinung des Anforderungsverantwortlichen hat das bisherige System Schwächen bezüglich der Usability. Das heißt: Durch die unterschiedlichen Arbeitsgebiete der einzelnen Teams, die die SSE einsetzen, wird ein personalisierbarer Client gewünscht, um die Benutzerfreundlichkeit zu steigern.
Durch die Designschwäche des aktuellen Clients ist die Wartung und Weiterentwicklung für sein Entwicklerteam zeitaufwändig und kompliziert.
Man erwartet von der neuen Technik, dass beide Probleme gelöst werden können und gleichzeitig eine gleiche oder bessere Performance geboten wird. Die neue Technik soll dabei relativ universell und in anderen Projekten verwendbar sein. Somit soll sich eine wesentliche Verbesserung für den Customer Care Support ergeben und eine effizientere Wartungs- und Entwicklungsarbeit des Entwicklerteams.
Man ist aber skeptisch, ob eine einfache Migration vom alten zum neuen Design möglich ist.

XXXX (Fachexperte, Systembetroffener):
Durch die Designschwäche des aktuellen Clients ist es schwierig, den gesamten Programmcode zu überblicken. Dies erschwert die täglichen Wartungsarbeiten. Das gleiche gilt auch für die Weiterentwicklung. Versuche, den Client der SSE zu personalisieren, gelingen aktuell nur andeutungsweise.
Man erwartet also eine große Arbeitserleichterung.

Jens Lambert (Systembetroffener Backoffice Hardware):
Oft dauern Arbeitsvorgänge für den Call-Agent zu lange, da das Userinterface so komplex ist. Punkte, die für Ihn wichtig sind. Lassen sich nicht auf den ersten Blick erkennbar sind. Man wünscht sich, dass Bereiche, die für die tägliche Arbeit wichtig sind, ausgeblendet werden können.
Oft ist der aktuelle Client etwas träge und es treten manchmal längere Wartezeiten auf. Die Agents wünschen sich auch einen Geschwindigkeitsvorteil von der neuen Technik.
3.5 Beschreibung der Anforderungen
3.5.1 Probleme und Ziele
Die Probleme und Ziele wurden schon in Kapitel 1.1 und Kapitel 3.2 bearbeitet und sollen an dieser Stelle nicht noch einmal wiederholt werden.
3.5.2 Funktionale Anforderungen
Kommentar zu Nr.1:
Die Platzierung der Module untereinander könnte in der SSE wie folgt aussehen:
Kommentar zu Nr.3:
Wenn der User nicht die entsprechenden Rechte hat oder diese Funktionalität in dieser Abteilung nicht gebraucht wird, können einzelne Komponenten über eine Konfiguration unsichtbar gemacht werden (z.B. grauer Bereich anstelle eines Buttons). Textfeldern oder ähnlichen Elementen können auf read only gestellt werden.
Kommentar zu Nr.5:
Das bedeutet: Wenn beim obigen Beispiel ein Vertrag in der Vertragsübersicht ausgewählt wird, aktualisiert sich das Modul „Vertragsdetails“ automatisch mit den korrekten Vertragsdetails.
Ein weiteres Beispiel: Wird im Modul Registerkarten vom Benutzer ein anderer Reiter gewählt, können neue Module angezeigt werden, und Module, die schon angezeigt werden entfernt/unsichtbar gemacht werden.
3.5.3 Randbedingungen(Gesetze, Standards)
3.5.4 Qualitätsanforderungen
3.5.5 Testanforderungen
Es müssen Testreihen erstellt werden, die alle Pflicht Anforderungen auf korrekte Funktion überprüfen. Diesen Test sollte der Prototyp auch durchführen können.
3.5.6 Abnahmekriterien
Es müssen alle funktionalen Pflichtanforderungen erfüllt sein. Das gleiche gilt im Prinzip auch für die Qualitätsanforderungen. Da man hier keine absoluten Zahlen festlegen kann, muss dieses Verhalten mit einem Prototyp getestet werden und sollte fair betrachtet in einem vertretbaren Rahmen liegen (da diese Zeiten nicht nur vom Framework, sondern auch von der späteren Anwendung abhängig sind).
8 Wie können die Anforderungen gelöst werden
8.1 Eclipse
Um eine Aussage zu treffen, ob dies möglich ist, werden alle Anforderungen an das Produkt nacheinander durchgegangen und bewertet. Dabei werden nur die Pflichtanforderungen betrachtet.
8.1.1 Untersuchung der Anforderungen

8.1.1.1 Anf. Nr. 1: Vorkonfigurierbare Platzierung von Modulen auf einem Fenster untereinander
Mit der Eclipse Plattform ist es möglich, Module auf einem Fenster zu platzieren, zum Beispiel mehrere Eclipse-Ansichten untereinander. Verschiedene Plug-Ins werden zu einem Eclipse-Feature verpackt. In der „install.ini“ wird festgelegt, wo die einzelnen Features platziert werden.

8.1.1.2 Anf. Nr. 3: Moduleinhalte müssen auch konfigurierbar sein (Sichtbarkeit/Schreibzugriff)
Das Einführen eines Rechte-Systems mit Java ist kein Problem. Nachdem sich beispielsweise ein User über ein Anmelde-Plug-In (Feature) authentifiziert hat, könnte man festlegen, dass alle Module diese Plug-In's erweitern müssen. Über Schnittstelle könnte somit die Sichtbarkeit/Schreibrechte anhand des Users für die beitragenden Module bestimmt werden.

8.1.1.3 Anf. Nr. 5: Allgemeine Modulkommunikation möglich
Die Kommunikation der Module wird bei Eclipse über die Erweiterungspunkte gesteuert.

8.1.1.4 Anf. Nr. 8: Konfiguration über Teamzugehörigkeit
Für diese Anforderung gilt das gleiche, wie für die Anforderung 3.

8.1.1.5 Anf. Nr. 10: Vorkonfigurierbare Menüeinträge des Fensters
Menüeinträge sind besonders leicht zu integrieren, da es sich dabei wiederum um Plug-Ins handelt. Wenn ein Plug-In einen Menüeintrag braucht, kann es diesen einfach durch das Bereitstellen eines zugehörigen Menü-Plug-In's tun.

8.1.1.6 Anf. Nr. 11: Erweiterbarkeit
Durch seine Plug-In Architektur ist Eclipse sozusagen spezialisiert auf die Erweiterbarkeit.

8.1.1.7 Anf. Nr. 12: Eignung für zukünftige Entwicklungen
Eclipse ist prinzipiell geeignet für zukünftige Entwicklungen, die ein Rich-Client benötigen. Java und die Eclipse Plattform werden noch über einen längeren Zeitraum weiterentwickelt. Darüber hinaus handelt es sich bei Eclipse um ein Open Source Produkt, an dessen Entwicklung man sich beteiligen kann. Sollte man das nicht wollen, reicht es die Plattform an seine eigenen Bedürfnisse anzupassen.

8.1.1.8 Anf. Nr. 13: Plattformunabhängigkeit
Durch den Einsatz von Java ist Eclipse prinzipiell Plattform unabhängig. Eingeschränkt wird dies nur durch SWT. Eclipse läuft nicht auf Plattformen, die von SWT nicht unterstützt werden. Da SWT aber alle wichtige Plattformen unterstützt (MS Windows über Mac OS und Linux/Unix), könnte man sagen, dass „faktisch“ Plattformunabhängig Eclipse.

8.1.1.9 Anf. Nr. 14: Einsatz von JAVA
Eclipse ist eine 100% Java Applikation.

8.1.1.10 Anf. Nr. 15: Verwendung von SWING
Eclipse setzt SWT statt SWING ein. Das ist leider als K.O Kriterium zu bewerten. Eclipse und SWT sind so eng miteinander verbunden, dass es nicht möglich ist, SWT durch SWING zu ersetzen.

8.1.1.11 Anf. Nr. 16: Verwendung keiner kommerziellen Produkte
Diese Anforderung wäre ebenfalls erfüllt, da Eclipse ein OpenSource Produkt ist.

8.1.1.12 Anf. Nr. 18: Startzeit unter einer Minute
Diese Anforderung lässt sich nicht so einfach überprüfen, da hierfür ein entsprechender SSE-Eclipse-Prototyp vorhanden sein müsste, der im XXXX Firmen-Kontext getestet werden könnte. Beim Startvorgang der aktuellen SSE werden ungefähr 5 MByte Daten geladen, dies entspricht auch der Größe von PDE.
Ein Test mit einem Athlon XP 2400+(2Ghz) und 512 MB Arbeitsspeicher bringt folgende Ergebnisse. Eclipse Plattform und PDE belegen etwa 70 MByte Hauptspeicher. Nach dem Start der aktuellen SSE werden ca. 40 MByte Hauptspeicher belegt. Das Starten der aktuellen SSE dauert etwa 16s, das Starten der Eclipse Plattform und PDE dauert bei einer lokalen Installation ebenfalls 16s. Da Eclipse lokal installiert ist und die SSE über Webstart geladen wird, wird angenommen, dass die Eclipse Plattform mit PDE um einiges langsamer startet. Auf der einen Seite ist der IDE-Bus im Rechner schneller als Ethernet 100 Base TX, doch auf der anderen Seite muss die Eclipse Anwendung nicht warten bis der User authentifiziert wurde.
Es bleibt also die Befürchtung, dass durch den Einsatz der Eclipse Plattform sich die Startperformance verschlechtert.

8.1.1.13 Anf. Nr. 19: Günstiger Ressourcenverbrauch
Ein Test mit den gleichen Voraussetzungen wie beim Test für die Anforderung 18 ergibt, dass die Eclipse Plattform und PDE etwa 70 MByte Hauptspeicher belegen. Nach dem Start der aktuellen SSE werden ca. 40 MByte Hauptspeicher belegt. Somit braucht Eclipse in unserem Beispiel fast doppelt so viel Hauptspeicher. Ob Eclipse mit PDE wirklich vergleichbar ist mit einer SSE-Eclipse Anwendung, bleibt unklar. Wie oben schon erwähnt wurde, haben die PDE Plug-Ins eine Größe von 5MByte. Dies entspricht auch der Datenmenge, die für den Start der aktuellen SSE geladen wird. Deshalb ist zu vermuten, dass eine SSE-Eclipse etwas mehr Ressourcen beansprucht als die aktuelle SSE. Das dürfte aber nur an der Größe der Plattform liegen. Wenn man nämlich von der Größe der Plattform absieht, hat Eclipse ein Ressourcen schonendes Verhalten, da Plug-Ins erst in den Hauptspeicher geladen werden, wenn sie benutzt werden.

8.1.1.14 Anf. Nr. 20: Wartezeit bei Benutzeraktionen wie im aktuellen Client
Durch den Einsatz von SWT statt SWING ist ein leichter Performance gewinn zu erwarten, der aber in anbetracht der hohen Performance aktuelle PC-Systeme nicht so stark ins Gewicht fallen dürfte.

8.1.1.15 Anf. Nr. 22,23: Verbesserte Erweiterbarkeit/Wartbarkeit gegenüber aktuellem System
Wie schon oben erwähnt, ist dies durch die Plug-In Architektur sehr leicht möglich. Vor allem im Hinblick darauf, dass die aktuelle SSE ein monolithischer Block ist.
8.1.3 Ergebnis der Betrachtung für Eclipse
Die Eclipse-Technologie bietet große Vorteile durch ihr Design. Somit ist sie für einen Rich Client besonders geeignet. Da man aber eine Technik für ein bestehendes Projekt sucht, das auf SWING basiert, möchte XXXX die Firma nicht SWT einsetzen. Deshalb gehört die Verwendung von Swing auch zum Anforderungskatalog und kann deshalb nicht eingesetzt werden.
Obwohl die Eclipse-Technologie sich sehr gut eignet, um eigene Anwendungen zu realisieren, findet man auf Anhieb keine. Bis jetzt wird nur die Erweiterbarkeit der IDE ausgiebig von Firmen genutzt.
Außerdem ist die Eclipse Plattform sehr komplex, was eigentlich ein Vorteil darstellt. Aber für das XXXX Projekt bietet sie sehr viele Features, die nicht genutzt werden könnten. Deshalb ist eine kompaktere Lösung gegenüber der Eclipse Plattform im Vorteil (siehe Bemerkungen zu Anforderungen 18,19).
Trotzdem bietet die Eclipse-Technologie durch ihr gutes Konzept gute Ansätze für eine selbst entwickelte Lösung für das Problem. Die Arbeitsweise der Plug-Ins, Verpackung in Features und schließlich Verpackung zu einem Produkt ist sehr vorteilhaft. Dies würde sich sehr positiv auf die Erweiterbarkeit und Wartbarkeit auswirken.
8.2 JavaBeans und InfoBus
JavaBeans und InfoBus allein reichen noch nicht aus, um einen Rich Client zu realisieren. Dazu benötigt man beispielsweise ein Framework, welches es ermöglicht, Java-Beans in Module zu verpacken und die Platzierung über XML zu konfigurieren.
8.2.1 Untersuchung der Anforderungen

8.2.1.1 Anf. Nr. 1: Vorkonfigurierbare Platzierung von Modulen auf einem Fenster untereinander
Um dieses zu realisieren, müsste man ein Framework entwickeln, das die Konfiguration der Module beispielsweise aus XML Dateien auslesen kann. Durch das Lesen der XML Anwendungskonfigurationsdatei könnte sich das Modul für die Anwendung registrieren. Danach wird das Modul geladen. Dabei geht der nächste Punkt näher auf die Beschaffung eines Moduls ein.

8.2.1.2 Anf. Nr. 3: Modulinhalte müssen auch konfigurierbar sein (Sichtbarkeit/Schreibzugriff)
JavaBeans könnte man zu Modulen zusammenfassen. Für die Konfiguration der Modulinhalte sollte eine XML Modulkonfigurationsdatei benutzt werden. Diese wird ebenfalls von der Anwendung gelesen und interpretiert.

8.2.1.3 Anf. Nr. 5: Allgemeine Message Austausch zwischen Modulen
Die Kommunikation der Module könnte über InfoBus -die Java Erweiterung für Java-Beans – gesteuert werden.

8.2.1.4 Anf. Nr. 6: Menüeinträge können konfiguriert werden
Da diese Funktionalität nicht von vorneherein gegeben ist, muss das Framework so konzipiert werden, dass man durch Konfigurationseinträge Menüeinträge generieren kann.

8.2.1.5 Anf. Nr. 8: Konfiguration über Teamzugehörigkeit
Je nachdem welcher User sich authentifiziert, wird eine bestimmte XML Anwendungskonfigurationsdatei geladen, die genau auf das Team abgestimmt ist.

8.2.1.6 Anf. Nr. 10: Erweiterbarkeit
Durch das Einsetzen von JavaBeans besteht die Möglichkeit die einzelnen Beans upzudaten, da neuere Versionen abwärtskompatibel sein müssen. Die Zusammenstellung der Anwendung durch das Nutzen von Beans und das Verpacken zu Modulen ermöglicht sowieso eine einfache Erweiterbarkeit

8.2.1.7 Anf. Nr. 11: Eignung für zukünftige Entwicklungen
Das zu entwickelte Framework eignet sich prinzipiell für weiter Swing-basierte Rich Clients.

8.2.1.8 Anf. Nr. 12: Plattformunabhängigkeit
Durch den Einsatz von Java, Swing, JavaBeans, XML und InfoBus ist eine echte Plattformunabhängigkeit gegeben.

8.2.1.9 Anf. Nr. 13: Einsatz von JAVA
JavaBeans, Swing und InfoBus gehören zu Java. Außerdem liefert JAVA von sich aus schon alles, um mit XML umzugehen. Der Einsatz von anderen Programmiersprachen ist somit überflüssig.

8.2.1.10 Anf. Nr. 14: Verwendung von SWING
Die Verwendung von Swing in diesem Kontext ist kein Problem, da der Funktionsumfang des Swing Packages ist völlig ausreichend

8.2.1.11 Anf. Nr. 15: Verwendung keiner kommerziellen Produkte
Java, Swing, JavaBeans, XML und InfoBus sind keine kommerziellen Produkte.

8.2.1.12 Anf. Nr. 17: Startzeit unter einer Minute
Diese Anforderung lässt sich nicht so einfach überprüfen, da hierfür ein entsprechender aussagekräftiger Prototyp vorhanden sein müsste, der im XXXX Firmen-Kontext getestet werden könnte. Da aber eine kompakte Lösung angestrebt wird, ist zu erwarten, dass die Performance besser sein sollte als beim aktuellen System.

8.2.1.13 Anf. Nr. 18: Günstiger Ressourcenverbrauch
Diese Anforderung lässt sich ebenfalls nicht so einfach überprüfen, da hierfür ein entsprechender aussagekräftiger Prototyp vorhanden sein müsste, der im XXXX Firmen-Kontext getestet werden könnte.
Es ist aber anzunehmen, dass der Ressourcenverbrauch günstiger ist als im aktuellen System, da die neue Lösung eine auf Modulbasis personalisierbare ist. Das hat den Vorteil, dass die Anwendung nur noch Module enthält, die auch gebraucht werden, wobei bei der aktuellen monolithischen Anwendung immer alles geladen wird.

8.2.1.14 Anf. Nr. 19: Wartezeit bei Benutzeraktionen wie im aktuellen Client
Die Wartezeit bei Benutzeraktionen wird sich nur unwesentlich ändern, da sich nur der Client ändert, die Middleware bleibt gleich. Bei solchen Anwendungen muss der Benutzter in der Regel länger auf die Daten der Middleware warten, zu Verzögerungen durch den Swing Bildaufbau kommt es selten.

8.2.1.15 Anf. Nr. 21,22: Verbesserte Erweiterbarkeit/Wartbarkeit gegenüber aktuellemSystem
Wie schon oben erwähnt ist dies durch das Einsetzen von Modulen/JavaBeans sehr leicht möglich. Vor allem im Hinblick darauf, dass die aktuelle SSE ein monolithischer Block ist.
8.2.2 Ergebnisse der Betrachtung für JavaBeans und InfoBus
Das Einsetzen von JavaBeans und InfoBus bietet große Vorteile. Dies allein ermöglicht allerdings nicht die Realisation eines Rich Clients. Es kommt also auf die Qualität des Frameworks an, das die bestimmten Anforderungen an die Anwendung lösen kann. Abgesehen davon können alle Anforderungen prinzipiell erfüllt werden. Durch das Einsetzen eines eigenen Frameworks ist man ohnehin vollkommen unabhängig von anderen (Community, Firma). Dies lässt eine kompakte Lösung zu, was sich auf ein verteiltes System im Netzwerk positiv auswirken wird. Dabei können auch Konzepte der Eclipse Plattform zum Einsatz kommen. Beispielsweise JavaBeans verpacken als Module. Diese Module könnten dann wiederum zu einer Anwendung zusammen gepackt werden. Diese Analogie zu Eclipse würde sich sehr positiv auf die Erweiterbarkeit und Wartbarkeit auswirken.
Darüber hinaus werden JavaBeans von sehr vielen Entwicklern und vor allem von der Industrie eingesetzt ([Jess04]). Das bedeutet, dass sich diese Technologie durchgesetzt hat.
8.3 NetBeans
Die Lösung der Anforderungen wären durch das Einsetzen der NetBeans Plattform sicherlich auch möglich. Dies wurde aber aus oben genannten Gründen nicht näher untersucht. Obwohl NetBeans im Vergleich zu Eclipse plattformunabhängig ist und Swing einsetzt, muss man trotzdem annehmen, dass eine Lösung mit NetBeans nicht kompakt genug wäre.
8.4 Welche Lösung wurde gewählt
Die untersuchten Lösungsmöglichkeiten führen zu dem Schluss, JavaBeans und den InfoBus einzusetzen. Eclipse ermöglicht die Erfüllung der Anforderungen bis auf den Einsatz von Swing und die damit zusammenhängende Plattformabhängigkeit. Das verbietet schon den Einsatz. Entscheidend für die gewählte Lösung ist die Unabhängigkeit von einer Community oder einem Firmenkonsortium, obwohl XXXX die Firma gerne Open Source Produkte einsetzt. Ein weiterer ausschlaggebender Punkt ist die Möglichkeit eine kompaktere Lösung zu schaffen. Letztendlich ist die Migration in die neue Technologie einfacher, als ein harter Schnitt. Denn für eine komplette Neuentwicklung, was beim Einsetzen der Eclipse-Plattform nötig wäre, fehlen die Ressourcen.
9 Modellierungen der Lösung
9.1 Idee
Informationen zur Personalisierung werden in XML-Files gespeichert. Dies geschieht einmal für die Anwendung in einer appConfig.xml zur allgemeinen Konfiguration der Anwendung. Zum anderen gibt es für jedes Modul eine separate Konfiguration in Form eines XML Files. Wenn die Anwendung startet, werden diese Dateien geladen und ausgewertet. Aus dieser Auswertung geht hervor, welche JavaBeans geladen werden. Sichtbare JavaBeans werden in einem JFrame gemäß Konfiguration platziert. Unsichtbare
werden in einem Vector im Speicher gehalten.
Damit keine festen Beziehungen zwischen den JavaBeans entstehen, werden Ereignisse nicht statisch programmiert. Um das Event Handling dynamisch zu lösen kommt der InfoBus (Sun) oder eine eigene Lösung (RCFBeanCommunication) zum Einsatz.
9.2 Der Kern der Anwendung
Der Kern der Anwendung wird durch die Klasse de.einsundeins.ccsys.rcf.RCFCore dargestellt. Diese Klasse enthält die main() Methode der Anwendung. Hier werden alle nötigen Informationen in den Attributen gespeichert.
9.2.1 Klassendiagramm

Alle Attribute der Klasse, außer das Attribut appWindow, werden beim Erzeugen eines Objektes initialisiert. Um ein Objekt der Klasse RCFAppConfigDocument anzulegen, werden die Pfad Angaben der Attribute appConfigFilePath und moduleDir benötigt. Dieses wird detaillierter in 9.3.3 beschrieben.
9.2.2 Sequenzdiagramm der main() Methode


Nachdem das Objekt appConfig im Konstruktor initialisiert wurde, werden die darin gespeicherten Informationen durch die Methode configToString() über System. out.print() zur Kontrolle ausgegeben. Danach wird das Anwendungs-Fenster repräsentiert durch das Objekt appWindow initialisiert.
Jetzt werden die Module gemäß der Konfig-Dateien geladen. Sollte die JavaBean nicht die Interfaces Serializable und RCFBeanCommunicationMember implementieren wird eine RCFBeanIsNotValidException geworfen. Wenn die JavaBean visible ist, wird sie dem appWindow hinzugefügt, aber nur wenn es sich dabei um eine Instanz einer java.awt.Component handelt, sonst wird die RCFBeanIsNotValidException geworfen. Sollte die JavaBean invisible sein wird sie im Vector invisibleBeans im Speicher gehalten.
Wie man im Sequenzdiagramm sehen kann, wird als letztes durch die Methode showAppWindow() das Anwendungs-Fenster appWindow angezeigt.
Sollte dabei an irgendeiner Stelle in RCFCore eine Exception abgefangen werden, wird diese in einem Dialog ausgegeben und die Anwendung beendet.
9.3 Die Personalisierung
Durch das Einsetzten der JavaBean Technologie ist es möglich, Module vorzukonfigurieren. Dies funktioniert natürlich nur, wenn die JavaBean Entwickler den Serialisierungs-Mechanismus bei der Entwicklung berücksichtigen. Der JavaBean Entwickler kann es dem JavaBean Benutzer nicht nur ermöglichen, über eine JavaBean Entwicklungsumgebung z.B. die Hintergrundfarbe zu ändern, sondern auch bestimmte Felder
oder Buttons ein-/auszublenden.
Diese Vorgehensweise ist auf jeden Fall wünschenswert.
Die eigentliche Konfiguration der Anwendung geschieht aber in XML Dateien. Der konfigurierbare Inhalt der XML Dateien richtet sich stark an den eingesetzten Technologien aus. Dabei handelt es sich häufig um Informationen, die bei der Verwendung von Swing als Parameter gebraucht werden. Für die Kommunikation des Menüs mit den Modulen werden zusätzliche Tags eingesetzt.
9.3.1 appConfig.xml
Alle Einträge müssen innerhalb des <application> Tags vorgenommen werden. Die Tags für das Generieren von Menüeinträgen sind optional, alle anderen Tags sind Pflicht.
In einem javax.swing.JFrame kann man nach [Fisc01] einen Titel definieren, dafür sind in der appConfig.xml drei Tags vorgesehen.

• <app_name>: Name der Anwendung (String)
• <version>: Versionsnummer (String)
• <company>: Firmen Name (String)

Ein JFrame wird an einer bestimmten Stelle, mit einer bestimmten Größe auf dem Bildschirm positioniert. Dazu werden folgende Angaben benötigt.

• <position_X>: X Achsen Position auf dem Desktop (Natürliche Zahl)
• <position_Y>: Y Achsen Position auf dem Desktop (Natürliche Zahl)
• <dimension_X>: Größe des Fensters auf der X Achse (Natürliche Zahl)
• <dimension_Y>: Größe des Fensters auf der Y Achse (Natürliche Zahl)

Um dem JFrame eine javax.swing.JMenubar hinzuzufügen, wird ebenfalls ein Tag benötigt.
Experimentell gibt es noch ein Tag um das Logging zu aktivieren. Dieses Feature
ist aber nur zu Test-Zwecken.

• <enable_menue>: Menüleiste aktivieren (Boolescher Wert: true/false)
• <enable_logging>: Logging aktivieren (Boolescher Wert: true/false)

Wenn man <enable_menue> auf den Wert true gesetzt hat, wird der JMenubar ein javax.swing.JMenu mit dem Namen „Datei“ hinzugefügt. Dieses JMenu enthält die javax.swing.JMenuItem mit dem Namen „about“ und „beenden“.
Durch aufrufen des Menüpunktes „about“ bekommt der Benutzer einen Infotext angezeigt. Durch das Auswählen von „beenden“ wird die Anwendung natürlich geschlossen.
Wenn weitere JMenu’s dargestellt werden sollen, können diese über das <menue> Tag konfiguriert werden. Diese Einträge werden natürlich nur beachtet wenn der Wert für <enable_menue> true ist.

• <menue>: Name des Menüs als String. Menüs dürfen nicht gleich lauten.
• <menue_item>: Name des Menüeintrages als String. Dieser Tag muss innerhalb von <menue> liegen. Menü-Items innerhalb eines Menüs dürfen nicht gleich lauten.
• <menue_command>: Name des Events, das ausgelöst werden soll, wenn der Menüpunkt aktiviert wird. Dieser Tag muss innerhalb von <menue_item> liegen.

Schließlich müssen noch die Module angegeben werden. Dazu muss man innerhalb des <module> Tags das Modul über das Tag <module_name> spezifizieren. Hier müssen alle Module die benutzt werden eingetragen werden.

• • <module_name>: Name des Moduls (String), die zugehörige Modulkonfiguration heißt dann [module_name].xml.

Im Anhang 13.3.1 befindet sich eine Beispiel „appConfig.xml“.
9.3.2 Modulkonfig-Datei
Die XML Konfigurationsdatei muss so benannt werden, wie sie in der appConfig.xml angeben wird, natürlich mit der Erweiterung .xml (also [Modulname].xml). Alle Tags sollten innerhalb des <module> Tags gemacht werden. Alle Tags sind Pflicht-Tags.
Als erstes werden allgemeine Modulinformationen benötigt.

• <mod_name>: Name des Moduls (String). Dieser Name wurde auch schon in der appConfig.xml angegeben.
• <bean>: Name der JavaBean, die das Modul darstellt (String ohne Dateinamenerweiterung)
• <visible>: soll die JavaBean im JFrame angezeigt werden (Boolescher Wert: true/false)?

Alle Angaben zum Layout erfolgen im Tag <layout>. Diese orientieren sich natürlich am eingesetzten LayoutManager. Momentan wird das GridBagLayout genutzt. Deshalb werden folgende Tags benötigt.

• <lay_width>: Breite (in Rasterzellen) der Komponente (Natürliche Zahl)
• <lay_height>: Höhe (in Rasterzellen) der Komponente (Natürliche Zahl)
• <lay_grid_X>: X Achsen Position ausgehen der Ecke oben links in Rasterzellen (Natürliche Zahl)
• <lay_grid_Y>: Y Achsen Position ausgehen der Ecke oben links in Rasterzellen (Natürliche Zahl)
• <lay_weigth_X>:Horizontales Gewicht der Komponente (Dezimal)
• <lay_weigth_Y>: Vertikales Gewicht der Komponente (Dezimal)

Im Anhang 13.3.2 befindet sich eine Beispiel [ModulName].xml.
9.3.3 Das Package de.einsundeins.ccsys.rcf.configdocuments
Dieses Package enthält die Klassen, die vom Framework benötigt werden, um die XML Konfiguration zu lesen und die Inhalte zu speichern. Der Konstruktor von „RCFApp-Config“ benötigt lediglich als Parameter die Angabe wo sich die appConfig.xml und die [beanName].xml befinden.
Zuerst werden die XML Files geparst.
Dabei kommt DOM2 zum Einsatz. Diese Methode, XML zu verarbeiten, sollte man nach [SeWe02] bevorzugen. Denn im Gegensatz zur Arbeit mit dem SAX-Parser3, wird hier die eingelesene und geparste Datei in einem Dokumentenbaum abgebildet. Dies erlaubt es, bestimmte Tags aus dem Dokumentenbaum auszulesen und ermöglicht es prinzipiell, in Zukunft Tags zu ändern um dann die geänderte Konfiguration zu sichern. Darüber hinaus ist DOM Bestanteil der XML-API von Java 2 SE Version 1.4. Im Package de.einsundeins.ccsys.rcf.configdocuments können beim einlesen der XML Files folgende Exceptions auftreten:

• RCFCanNotReadFileException: Wenn ein XML File nicht lesbar ist.
• RCFConfigXMLFileTagException: Wenn die XML Datei nicht die geforderten Tags enthält.
• RCFConfigXMLFileFormatException: Wenn ein Tag einen ungültigen Wert enthält, z.B. statt einer Zahl einen String.
• RCFModuleAppConfigException: Wenn ein Fehler bei der internen Verarbeitung der Modulkonfigurationen geschieht.
• RCFModuleConfigNotExistException: Wenn ein in der „appConfig.xml“ eingetragenes Modul keine zugehörige XML Datei hat.

9.3.3.1 Klassendiagramm


Alle Attribute werden im Konstruktor durch Aufruf der jeweilige setMethode gesetzt. Funktionalitäten der beiden Arten von Konfigurationsdokumenten werden in Ihrer Oberklasse gekapselt. Exceptions, die im Package de.einsundeins.ccsys.rcf.configdocuments eingesetzt werdenm sind als Innere Klassen implementiert.
9.4 Das Anwendungs-Fenster (de.einsundeins.ccsys.rcf.swing)
Das Anwendungs-Fenster appWindow der Klasse RCFAppFrame ist – wie das Klassendiagramm zeigt - ein JFrame mit einer contentPane im GridBagLayout. Es wird in der Methode RCFCore.initAppWindow() eine Instanz der Klasse RCFAppFrame angelegt. Der Konstruktor verlangt die entsprechenden Parameter aus der „appConfig.xml“.
Sollte in der „appConfig.xml“ der Wert für <enable_menue> (siehe Kapitel 9.3.1) true sein, wird durch Funktionen der Klasse RCFAppFrame eine JMenuBar mit einem Standard Menü „Datei“ dem appWindow hinzugefügt. Dieses Menü enthält die Einträge „beenden“ und „about“. Dann werden – falls vorhanden – weitere Menüs aus der „app-Config.xml“ gemäß Kapitel 9.3.1 eingefügt.
In Kapitel 9.2 wurde schon erwähnt, dass in der Methode RCFCore.loadModules() JavaBeans dem appWindow hinzugefügt werden. Dies geschieht über die Methode add-Component() der Klasse RCFAppFrame. Als Parameter sind die Angaben aus der entsprechenden XML Datei (siehe Kapitel 9.3.2) zwingend erforderlich.
Die Methode showIt() wird benutzt, um das Fenster anzuzeigen. Sie wird von der Klasse RCFCore in der Methode RCFCore.showAppWindow() aufgerufen. hideIt() wurde nur der Vollständigkeit wegen implementiert und wird möglicherweise zukünftig benutzt.
Der RCFDialog wird benötigt, um nach auswählen von „about“ einen Dialog anzuzeigen, der einem Applikation Info Textes anzeigen kann. Diese Klasse spielt weiter aber keine Rolle.
9.4.1 Klassendiagramm
9.5 Kommunikation der Komponenten
Während der Evaluations-Phase wurde der InfoBus von Sun als Kommunikationsmittel gewählt. Dies ist prinzipiell möglich. Im ersten Schritt wird eine Lösung mit dem Info-Bus gezeigt und warum diese nicht genutzt wurde. Im zweiten Schritt die endgültig gewählte Lösung mit dem Package de.einsundeins.ccsys.rcf.beanCommunication.
9.5.1 InfoBus Kommunikation im RCF
Wenn man mit dem Package javax.infobus arbeitet, sollte man nach [17] die Klasse InfoBus nie direkt verwenden. Die Methoden zur Mitgliedschaft am InfoBus werden von der Klasse InfoBusBeanSupport gerufen, die das Interface InfoBusBean implementiert. Des Weiteren muss eine Anwendung - wie RCF - dem InfoBus über die Methode joinInfoBus() beitreten. Als Parameter muss nach [17] ein String zur Benennung der
InfoBus Instanz angegeben werden, da es sich bei RCF um keine Applet handelt.
Ein Objekt der Klasse InfoBusBeanSupport ist ein Attribut der Klasse RCFCore (natürlich nur bei der Lösung mit InfoBus). Im Konstruktor von RCFCore wird dann ein InfoBus mit dem Namen “testBus“ durch Aufruf der Methode joinInfoBus() erzeugt.


Da die Module die InfoBus Instanz brauchen, müssen alle JavaBeans das Interface de.einsundeins.ccsys.rcf.indobus.RCFInfoBus implementieren.


Beim Laden der Module in der Methode loadModules() der Klasse RCFCore wird die InfoBus Instanz durch Aufruf von setRCFInfoBus() übergeben. Danach werden die JavaBeans noch als Producer oder als Consumer registriert. Dazu ein kleines Code Fragment der Methode RCFCore.loadModules():

if (this.isInfoBusDataConsumer(bean)){
(RCFInfoBus) bean).setRCFInfoBus(this.getInfoBus());
this.getInfoBus().addDataConsumer((InfoBusDataConsumer) bean);
}
if (this.isInfoBusDataProducer(bean)){
((RCFInfoBus) bean).setRCFInfoBus();
this.getInfoBus().addDataProducer((InfoBusDataProducer) bean);
}

9.5.1.1 Wie muss ein Modul / JavaBean implementiert werden
Eine JavaBean, die den InfoBus benutzen will, muss nach [17] das Interfaces InfoBus-Bean implementieren. Das hat zur Folge, dass einige Wrapper Methoden implementiert werden müssen. Da diese Vorgehensweise immer gleich ist, wurde die Klasse de.einsundeins.ccsys.rcf.indobus.RCFInfoBusBean geschaffen. Diese wird vom Interface RCFInfoBus benutzt.
Somit muss jede JavaBean, die im RCF (mit InfoBus) verwendet wird, das Interface RCFInfoBus implementieren.
Eine Teilnahme am InfoBus macht nur Sinn, wenn die JavaBean ein InfoBusDataProducer und oder InfoBusDataConsumer ist. Dazu muss die Bean die gleichnamigen Interfaces implementieren.

9.5.1.1.1 Consumer
Consumer warten auf das InfoBusItemAvailableEvent. Dieses tritt auf, wenn ein DataItem bereitgestellt wird. Wenn dieses Ereignis auftritt, wird die InfoBusDataConsumer Methode dataItemAvailable() ausgeführt.
In dieser Methode wird nun geprüft, ob man Interesse an diesem DataItem hat. Sollte dies der Fall sein, kann man mit der Methode requestDataItem() auf dem InfoBusItemAvailableEvent das DataItem anfordern. Dazu ein Quellcode Fragment:

public void dataItemAvailable ( InfoBusItemAvailableEvent ibe ){
.....
String s = ibe.getDataItemName();
if ( ( s != null ) && s.equals( this.dataName )){
Object tmpData = ibe.requestDataItem( this, null );
synchronized ( this.dataLock ){
this.setText(((ImmediateAccess)tmpData).getValueAsString());
}
}
}
Zum besseren Verständnis das zugehörige Klassendiagramm mir einem Consumer TestBeanB:


9.5.1.1.2 Producer
Damit der Consumer ein InfoBusItemAvailableEvent empfangen kann, muss ein Producer dieses Event auslösen. Dies geschieht ganz einfach durch Aufruf der Methode fireItemAvailable() auf der InfoBus Instanz.
Dieses Item ist so lange verfügbar, bis es mit der Methode fireItemRevoked() widerrufen wird. Dazu folgendes Klassendiagramm:

9.5.2 Warum wurde der InfoBus nicht verwendet.
Das obige Beispiel zeigt nur wenig von der Funktionalität des InfoBusses. Es gibt auch die Möglichkeit, dass ein Consumer ein DataItem durch die Methode findDataItem() auf der InfoBus Instanz anfordern kann. Dies löst ein InfoBusItemRequestedEvent aus, für das der InfoBusDataProducer die Methode dataItemRequested() implementieren muss, die bei diesem Ereignis ausgeführt wird. Die meisten sind für dieses Projekt jedoch
überflüssig.
Wenn z.B. ein InfoBusItemAvailableEvent ausgelöst wird, löst dies bei allen DataConsumern die Methode dataItemAvailable() aus. Auch bei solchen Consumern die sich gar nicht für dieses Item interessieren.
Das gleiche gilt natürlich auch für alle anderen Events (auch das InfoBusItemRequestedEvent). Dadurch entsteht ein hoher Verkehr auf dem Bus, den man sich eigentlich sparen könnte.
Nach Anforderung Nr.5 in Kapitel 3.5.2 soll es möglich sein, dass Module untereinander Messages austauschen können. Das sind im wesentlichen Events zuzüglich einer kleinen Botschaft. Dazu ist es nicht notwendig, dass Botschaften über einen längeren Zeitraum verfügbar sind, sondern nur beim Ereignis und nur für Consumer, die sich dafür interessieren.
Beim InfoBus können auch wesentlich komplexere Daten verschickt werden, je nachdem welches Interface vom DataItem implementiert wird. Zum Beispiel:

• ImmediateAccess : einfache DataItems
• ArrayAccess : DataItems organisiert in einem n-dimensionierten Array
• RowsetAccess : DataItems mit Zeilen aus einer Datenbank inklusive Metadaten
• ScrollableRowsetAccess : DataItems mit Zeilen aus einer Datenbank inklusive Metadaten. Hier kann man zusätzlich noch vorwärts und rückwärts durch die Daten navigieren.
• Usw.

Das verschicken solch komplexer Daten ist im RCF nicht notwendig und sinnvoll, denn das RCF soll in einer Umgebung eingesetzt werden, in der die Daten nicht direkt von der Datenbank angefordert werden, sondern vom Applikationsserver JBoss mittels Enterprise Java Beans. Erst recht sollten Daten nicht von Modulen angefordert werden. Das Konkurrieren dieser Technologien würde ja auch zu riesigen Problemen führen..
In der Praxis genügt es im RCF, beim Eintritt eines Ereignisses eine kleine Botschaft sofort an alle zu verschicken, die es gerade interessiert. Nicht mehr. Beispielsweise. eine Benutzer Eingabe, aber keine Kunden-Tabelle oder ähnliches.
Der InfoBus scheint so allgemein zu sein, dass er in vielen unterschiedlichen Anwendungen eingesetzt werden kann. Für das RCF ist er aber zu komplex und der Overhead wäre einfach zu groß.
Deshalb kommt eine eigene Lösung zum Einsatz, die sich am InfoBus orientiert, aber die genannten Nachteile zu vermeiden versucht. Die Lösung nennt sich RCFBeanCommunication und befindet sich im Package de.einsundeins.ccsys.rcf.beanCommunication.
9.5.3 Kommunikation mit de.einsundeins.ccsys.rcf.beanCommunication

9.5.3.1 Idee
Ein Producer schickt eine benannte Botschaft in eine Blackbox. Diese benannte Botschaft kann der Producer auch für sich registrieren, so dass nur er unter diesem Namen Botschaften verschicken darf. Ein Consumer empfängt eine Botschaft aus einer Blackbox nur dann, wenn sie über einen bestimmten Namen bereitgestellt wurde. Dabei bekommt der Consumer keine Events von Botschaften, für die er sich nicht registriert hat.
Consumer und Producer müssen sich nicht gegenseitig kennen. Der Name, unter der die Botschaft verschickt wird, muss aber eindeutig sein. Außerdem müssen Consumer wissen, für was sie sich interessieren und unter welchem Namen sie die Botschaft empfangen. Nur dann können sie auch die Botschaft auswerten.

9.5.3.2 Die Klasse RCFBeanCommunication
Sie entspricht der oben genannten Blackbox und stellt alle nötigen Methoden zur Bean Kommunikation bereit. Diese werden im Folgenden erläutert.


9.5.3.3 Verbindung zwischen RCF und den Modulen
Um an der RCFBeanCommunication teilzunehmen, muss man mindestens eine Rolle erfüllen. Die des Bereitstellers ( Interface RCFBeanCommunicationDataProducer) und / oder die des Empfängers ( Interface RCFBeanCommunicationDataConsumer) einer benannten Botschaft, natürlich in Anlehnung an den InfoBus. Eigentlich gibt es noch eine dritte Rolle, die des einfachen Mitgliedes (Interface RCFBeanCommunication- Member). Dieses Interface ist allerdings abstract und der RCFBeanCommunicationDataProducer und RCFBeanCommunicationDataConsumer leiten davon ab.


Das bedeutet, dass Producer und Consumer automatisch das Interface RCFBeanCommunicationMember auch implementieren müssen. Es bewirkt, dass der Kern von RCF (die Klasse RCFCore) eine Instanz der Klasse RCFBeanCommunication an jedes Modul verteilen kann. Deshalb wird in der Methode RCFCore.loadModules() auf jeder JavaBean die Methode setBeanCom() gerufen.
Die JavaBean sollte sich dann als Producer und / oder Consumer registrieren. Dies sollte in der Methode setBeanCom() gemacht werden. Nicht im Konstruktor der Klasse, da beim Erzeugen des Objektes noch keine Instanz der Klasse RCFBeanCommunication durch RCFCore zugeteilt wurde. Der Grund dafür ist, dass JavaBeans parameterlose Konstruktoren haben müssen. Das Registrieren geschieht durch die RCFBeanCommunication Methoden (siehe auch Klassendiagramm):

• Producer: joinAsDataProducer(..)
• Consumer: joinAsDataConsumer(..)

Durch dieses Registrieren werden die JavaBeans - je nachdem um welchen Member Typ es sich handelt - in den Vectoren producer / consumer der RCFBeanCommunikation Instanz gespeichert. Dabei können Exceptions geworfen werden:

• RCFBeanCommunicationNullPointerException: Wenn ein Parameter null ist.
• RCFBeanCommunicationDataProducerException: Wenn der Producer schon registriert ist
• RCFBeanCommunicationDataConsumerException: Wenn der Consumer schon registriert ist

9.5.3.4 Producer
Wenn ein Producer sich als solches registriert hat, darf er benannte Botschaften versenden. Gleiche Botschaften dürfen auch von verschiedenen Producern gesendet werden, denn wie in Kapitel 9.5.3.1 bereits erwähnt, müssen Consumer wissen, was sie mit der Botschaft unter einem bestimmten Namen anfangen können, egal wer sie sendet. Deshalb besteht eine benannte Botschaft aus einem String und einem Object.
Soll eine benannte Botschaft nur von einem Producer verschickt werden dürfen, dann muss man diesen Producer zum Besitzer machen.
Zum senden muss also die Methode setDataItemAvailable(..) (siehe Klassendiagramm) auf der RCFBeanCommunication Instanz aufgerufen werden. Als Parameter muss die benannte Botschaft übergeben werden (dataName, dataItem), der Producer selbst und ob der Producer auch der Besitzer ist (ownerSensitiv). Wenn eine Botschaft ownerSensitiv ist, so wird diese in der Hashtable dataItemOwner registriert (Key: Name, Value: Producer).
Dabei können Exceptions auftreten:

• RCFBeanCommunicationNullPointerException: Wenn ein Parameter null ist.
• RCFBeanCommunicationDataProducerException: Wenn der Producer nicht registriert ist.
• RCFBeanCommunicationDataProducerException: Sollte die zu sendende Botschaft schon einen anderen Besitzer haben. Sollte keine Exception auftreten , wird ein RCFBeanCommunicationDataItemAvailableEvent ausgelöst.

Die Hashtable dataItemsAndMultiCasterDadurch der RCFBeanCommunication Instanz enthält für jede Botschaft einen eigenen Multicaster (Key: Name, Value: RCFBeanCommunicationEventMulticaster). Das Event wird in der Multicaster Methode .availableDataItem(..) ausgelöst. Dazu später mehr.
Consumer können diesem Event dann die bennante Botschaft entnehmen.
Producer müssen so implementiert werden:


Nur wenn ein Producer sichtbar ist, muss er von einer Component ableiten. Die setBeanCom(..) sollte folgendermaßen implementiert werden:


9.5.3.5 Consumer
Wenn ein Consumer sich als solches registriert hat, kann er benannte Botschaften empfangen. Dazu sollte er in der setBeanCom() Methode sich für die Botschaften registrieren. Dazu muss die Methode startListenToDataItem(..) auf der RCFBeanCommunication Instanz gerufen werden. Die erforderlichen Parameter sind nach Abb. 49 der Name der Botschaft und der Consumer selbst. Dabei können folgende Exceptions auftreten:

• RCFBeanCommunicationNullPointerException: Wenn ein Parameter null ist.
• RCFBeanCommunicationDataConsumerException: Wenn der Consumer nicht registriert ist.

Durch diese Methode wird der Consumer als RCFBeanCommunicationDataItemAvailableListener dem Multicaster hinzugefügt, der in der Hashtable dataItemsAndMulti-Caster als Value unter dem Namen der Botschaft hinterlegt ist. Warum dies möglich ist zeigt folgendes Diagramm:


Das Interface RCFBeanCommunicationDataItemAvailableListener sorgt für die Implementation der Methode, die ausgelöst wird, wenn das RCFBeanCommunicationDataItemAvailableEvent für eine bestimmte Botschaft ausgelöst wird.
Dies geschieht in der Methode availableDataItem(..) des RCFBeanCommunicationEventMulticaster. Dazu das entsprechende Klassendiagramm und Sequenzdiagramm der Methode:



Damit keine Botschaften unter einem bestimmten Namen empfangen werden, kann stopListenToDataItem(..) auf der RCFBeanCommunication Instanz aufgerufen werden. Die erforderlichen Parameter sind nach Abbildung Klassendiagramm RCF der Name der Botschaft und der Consumer selbst. Dabei können folgende Exceptions auftreten:

• RCFBeanCommunicationNullPointerException: Wenn ein Parameter null ist.
• RCFBeanCommunicationDataConsumerException: Wenn der Consumer nicht registriert ist.
• RCFBeanCommunicationDataConsumerException: Wenn es beim Entfernen einen Fehler gab. Consumer müssen so implementiert werden:

Nur wenn ein Consumer sichtbar ist, muss er von einer Component ableiten. Die setBeanCom(..) sollte so implementiert werden:


9.5.3.6 Menü Kommunikation
Damit das JMenu der Klasse RCFAppFrame mit den Modulen kommunizieren kann, implementiert diese Klasse ebenfalls das Interface RCFBeanCommunicationDataProducer. Die Funktionsweise ist analog zur normalen Consumer - Producer Kommunikation.
Dazu werden Botschaften unter dam Namen versendet, der in der „appConfig.xml“ mit dem Tag <menue_command> festgelegt wurden.
9.6 Prototyp
Auf der beiliegenden CD befinden sich zwei Prototypen. Ein etwas älterer mit InfoBus (Ordner: „rcfMitInfoBus“) zur Bean - Kommunikation und ein aktueller, der das Package RCFBeanCommunication nutzt (Ordner: „rcf“). Beides sind Eclipse Projekte, können natürlich auch in anderen IDE’s getestet werden. „rcf“ und „rcfMitInfoBus“ enthalten folgende Ordner:

• build: Als Ort für spätere Builds
• classes: Diesen Ordner in der IDE angeben für die .class Files
• config: enthält die „appConfig.xml“
• lib: Ordner für Bibliotheken.
• log: Ordner für zukünftiges Logging
• modules: Enthält die JavaBeans und die Modulkonfigurationen
• src: Enthält den Quellcode

Die Prototypen wurden mit Java SDK 1.4.2 entwickelt und sollten auch unter dem zukünftigen Java SDK 1.5 laufen, da zum jetzigen Kenntnisstand keine Sprachkonstrukte genutzt wurden, die unter Java SDK 1.5 nicht mehr funktionieren.
Zum Testen des jeweiligen Prototyps muss der entsprechende Ordner in die IDE importiert werden. Man sollte den „classes“ Ordner in der IDE als Pfad für die übersetzten .Class Files angeben. Sehr wichtig ist das Hinzufügen zum Classpath der verwendeten JavaBeans / Modulen im „modules“ Ordner. Für den Prototyp in „rcfMitInfobus“ müssen die Bibliotheken in der IDE bekannt gemacht werden, der Prototyp „rcf“ benötigt
keine Bibliotheken.
Alle Konfigurationsdateien und Module befinden sich schon in den richtigen Ordnern. Zum Starten des jeweiligen Prototyps muss die Klasse „RCFCore“ im Package de.einsundeins.ccsys.rcf als Application ausgeführt werden. In der Konsole können während des Testens die log Einträge untersucht werden.
9.6.1 Prototyp „rcfMitInfoBus“


Dieser Prototyp enthält zwei Module. „TestBeanA.jar“ zum Senden von TESTDATA über den InfoBus und die „TestBeanB.jar“ zum Empfang von TESTDATA. Zum senden der Eingabe muss der „ok“ Button gedrückt werden. Danach erscheint der Text in den Modulen „zum Empfang“. Der „clear“ Button hat über das jeweilige Modul hinaus keine Bedeutung.
9.6.2 Prototyp „rcf“
Dieser Prototyp enthält fünf Module:

• TestBeanProducerA: sendet die Eingabe als TESTDATA (ProducerA)
• TestBeanProducerA2: sendet die Eingabe als TESTDATA (ProducerA Owner) mit der Besitzer Rolle
• TestBeanProducerB: sendet die Eingabe als TESTDATA2 (ProducerB)
• TestBeanConsumerA: empfängt TESTDATA und zeigt diese an(ConsumerA)
• TestBeanConsumerB: empfängt TESTDATA und zeigt diese an(ConsumerB) Der „clear“ Button hat über das jeweilige Modul hinaus keine Bedeutung.

Zur Demonstration der Menüfunktion wurde ein Menü ProducerA eingefügt. Über den Eintrag „senden“ kann die Eingabe gesendet werden, der Eintrag „clear“ löst die Funktion des Buttons „clear“ aus.
Wenn man zum Senden den ProducerA2 benutzt, ist es dem ProducerA nicht mehr möglich zu senden, da der Producer dann die Besitzer Rolle für TESTDATA innehat (auch zu sehen im Log Eintrag der Konsole).
10 Evaluierung der Ergebnisse
10.1 Wurde die Zielsetzung erreicht
10.1.1 Funktionale Anforderungen
Im Folgenden wird geprüft, ob die Anforderungen aus Kapitel 3.5 erfüllt wurden. Dazu werden die funktionalen Anforderungen geprüft. Die restlichen Anforderungen wurden schon in Kapitel 8.2 überprüft.


Das Projekt kann nun nach Kapitel 3.5.6 Abgenommen werden, da mindestens alle funktionalen Pflichtanforderungen erfüllt wurden. Das gleiche gilt für die Randbedingungen. Bezüglich der Qualitätsanforderungen können keine genauen Aussagen getroffen werden, da der Prototyp einen Vergleich mit dem aktuellen Client nicht zulässt. Dazu müsste ein Prototyp hergestellt werden, der die Funktionalität des aktuellen Client zum Teil nachbildet.
10.2 Wie kann die neue Lösung in die aktuelle Lösung einfliesen
Der SSE Client ist zu einer mächtigen Anwendung herangewachsen. Deshalb ist eine schnelle Migration nicht möglich. Wenn für Migration genügend Ressourcen zur Verfügung stehen, könnte man die Weiterentwicklung des alten Client einstellen und einen neuen auf Basis dieser Arbeit erstellen. Dadurch, dass sich die Arbeitsprozesse der Anwender der SSE ständig ändern, müsste der alte Client noch so lange weiter gepflegt werden, bis der neue Client auf einem Stand ist, mit dem die Anwender arbeiten können. Während des Umstellungsprozesses könnten bestimmte Abteilungen testweise mit dem neuen Client arbeiten.
Man muss allerdings davon ausgehen, dass die entsprechenden Ressourcen für eine solche Umstellung nicht vorhanden sind. Dies liegt daran, dass die Pflege des aktuellen Systems sehr aufwendig ist. Das liegt nicht nur an den sich öfters ändernden funktionalen Anforderungen, sondern auch an den häufigen Problemen mit den Datenbanken und des Applikationsservers JBoss. Dadurch ist die Zeit des SSE Teams für Weiterentwicklung relativ knapp. Ein Redesign des Clients wäre aber auf jeden Fall zu empfehlen, um den Aufwand für Wartung und Pflege in Zukunft zu reduzieren.
Durch diese Ressourcenknappheit ist also nur eine fließende Migration möglich. Im ersten Schritt müsste man den aktuellen Client modularisieren und diese Module als JavaBeans realisieren. Denn dies ist die Grundlage für die gewünschte Möglichkeit, den Client zu personalisieren. Egal ob man sich für das RCF entscheidet oder nicht, dazu ist das Package de.einsundeins.ccsys.rcf.beancommication nötig. Dessen Funktionalität und Performance müsste allerdings noch etwas verbessert werden. Dazu später im Kapitel 11 mehr.
Soll die Personalisierung mit dem RCF erfolgen, müssen die funktionalen Anforderungen an die Grafischen Komponenten des RCF erweitert werden. Denn im aktuellen Client werden auch verschiedene Dialoge und Wizards gebraucht. Dazu ebenfalls später mehr in Kapitel 11. Denn erst dann ist das Framework so flexibel, dass auch Anmeldedialoge etc. realisiert werden können.
Der nächste Schritt wäre dann ein kompletter Wechsel zum RCF. Dann sollten die Wartung der Module und die Weiterentwicklung des Frameworks sich nicht mehr gegenseitig beeinflussen.
11 Zusammenfassung/Ausblick
11.1 Zeitplanung
Bezüglich der Zeitplanung wäre es besser gewesen, den Zeitraum für die Evaluation der bekannten Lösungen etwas kurzer zu planen, damit für die Modellierung der Lösung und das Anfertigen des Prototyps mehr Zeit zur Verfügung gestanden hätte. Denn die Zeit für die Entwicklung der RCFBeanCommunication war zu knapp, nachdem man sich gegen den Einsatz des InfoBusses entschieden hatte.
Dennoch wurden weitestgehend die gesetzten Zeiträume eingehalten.
11.2 Evaluierung
Bei Betrachtung der existierenden Lösungen stellt man fest, dass das meiste Potential in der Eclipse Plattform liegt. Das liegt vor allem an der Qualität der Version 3, die sehr stabil läuft und in der das Plug-In Konzept sehr durchdacht ist. Dies bestätigt auch die Tatsache, dass Informatik Größen wie Erich Gamma und Kent Beck in [GaBe04] Regeln für die Plug-In Entwicklung entworfen haben.
Diese Qualität wird honoriert durch die hohe Akzeptanz am Markt. Ebenso sichtbar an der Größe des Eclipse Konsortiums, dem auch sehr viele Große Namen der Branche angehören. Es gibt schon eine sehr große Zahl von kommerziellen Plug-Ins, z.B. für den Bereich Software-Engineering (Plug-Ins von Omondo zum Erstellen von UML Diagrammen). In den Unternehmen wird die Funktionalität der IDE ebenfalls sehr oft mit Plug-Ins erweitert. Dieser Trend wurde auch schon von den Hochschulen erkannt. Studenten der Digitalen Medien der Fachhochschule Kaiserslautern können im Fach Medienkonzeption und –produktion bei Prof. Dr. Hendrik Speck ein Projekt bearbeiten, in dem ein Eclipse Plug-In entwickelt wird.
Allerdings kann das NetBeans Projekt, im Gegensatz zu Eclipse, schon einige Applikationen vorweisen. Diese sind auf [22] aufgelistet. Trotzdem ist ein Trend hin zu Eclipse spürbar, die Existenz von kompletten Applikationen auf Eclipse Basis ist nur noch eine Frage der Zeit.
11.3 Modellierung der eigenen Lösung
11.3.1 Neue Funktionalitäten des RCF’s
Bei einer Weiterentwicklung könnte man zur Erleichterung der Konfiguration dem Benutzer anbieten, die Konfiguration Toolgestützt durchzuführen. Denn dadurch wird das Konfigurieren weniger fehlerbehaftet, da nicht direkt im XML Quellcode gearbeitet werden muss. So sollte das Tool in der Lage sein, nicht nur Tippfehler auszuschließen, sondern auch logische Fehler.
Im Moment werden log Information über die Konsole ausgegeben, bestimmte Exceptions Texte in Dialog Fenstern. Damit im Fehlerfall diese Informationen besser genutzt werden können, sollte in Zukunft mit Logfiles gearbeitet werden. Hier würde sich besonders das Package log4j des Jakarta Projektes anbieten.
11.3.2 Grafische Funktionalität des RCF’s
Die Anforderung an die grafischen Funktionalitäten des Frameworks sind nach Kapitel 3.5.2 relativ gering. Momentan ist es möglich, die Module auf einem Fenster gemäß GridBagLayout zu platzieren. Dies reicht für einfache Anwendungen aus.
Der aktuelle SSE Client ist grafisch um einiges aufwendiger. So sollte eine Weiterentwicklung des RCF’s das Package de.einsundeins.ccsys.swing erweitern. Beispielsweise sollte die Klasse RCFAppFrame in Zukunft in der Lage sein, an der Stelle einer sichtbaren JavaBean in der ContentPane nach einer Benutzeraktion eine andere JavaBean anzuzeigen. Dies betrifft ebenfalls die XML Konfigurationsdateien, da in ihnen auch Layoutinformationen festgelegt werden. Deshalb muss hier ebenfalls ein Redesign durchgeführt werden. Man könnte z.B. die Positionierung der JavaBean in den XML-Files festlegen, wie jetzt auch, nur müsste noch eine weitere Unterscheidungsmöglichkeit eingefügt werden. Im Moment gibt es nur permanent sichtbare und permanent unsichtbare JavaBeans. Es wäre beispielsweise möglich, einer JavaBean eine Position zuzuweisen und zu definieren, dass sie noch nicht sichtbar ist, aber es später sein kann. Dabei muss ausgeschlossen werden, dass sich nach dem Programmstart JavaBeans gegenseitig überlagern. So ein neuer Typ könnte über die RCFBeanCommunication ereignisgesteuert sichtbar gemacht werden, natürlich erst nachdem die JavaBean, welche zuerst diese Position innehatte, unsichtbar gemacht wurde.
Des Weiteren könnte das Package noch um Klassen erweitert werden, die es ermöglichen, spezielle Dialogfenster zur Benutzung zur Verfügung zu stellen. Zum Beispiel zum Anzeigen von Dokumenten wie Faxen oder Email-Anhängen. Eine sehr vorteilhafte Erweiterung in diesem Bereich wäre das Schaffen von Klassen zur einfachen und schnellen Generierung von Wizards. Diese Feature wird auch von der Eclipseplatform angeboten und ist deshalb für den zukünftigen SSE Client sinnvoll, da der aktuelle Client auch einige Wizards besitzt.
11.3.3 BeanCommunication des RCF’s
Das aktuelle Package de.einsundeins.ccsys.rcf.beancommunication ist noch relativ rudimentär, da man sich erst relativ spät gegen den InfoBus entschieden hatte. Deshalb sollten bei einer Weiterentwicklung einige Optimierungen vorgenommen werden. Einige sind jetzt schon bekannt.
Die Klasse RCFBeanCommunicationEventMulticaster ist sehr einfach implementiert. Dabei könnte zur Performance-Steigerung das Versenden der Events Beispielsweise auch mit Java Threads geschehen.
Das Besitzer Konzept der BeanCommunication ist ebenfalls ungünstig implementiert. Im Moment wird der Producer erst zum Besitzer einer benannten Botschaft, wenn er eine benannte Botschaft versenden möchte. Dadurch können ungewollte Exceptions auftreten, da man hier schnell den Überblick verlieren kann, ob es für bestimmte benannte Botschaften Besitzer gibt oder nicht. Deshalb sollte das Interface RCFBean- CommunicationDataProducer um eine Funktion erweitert werden, in der die JavaBean bekannt machen muss, für welche benannten Botschaften sie Besitzer ist. Diese Funktion sollte dann in der Methode setBeanCom gerufen werden, nachdem die JavaBean sich als Producer registriert hat. So könnte verhindert werden, dass ein Konflikt um eine benannte Botschaft erst zur Laufzeit auftritt. Fehler treten dann während des Startvorganges auf und können behoben werden, bevor der personalisierte Client freigegeben wird.
Der Name einer Botschaft ist momentan im Quellcode festgelegt. Dabei handelt es sich um ein statisches Element in der BeanCommunication. Sofern man sich dafür entscheidet, die Kommunikation streng dynamisch durchzuführen, könnte man die Namen für die Botschaften in die XML Modulkonfiguration packen. Die Anwendung könnte diese Namen mappen, damit diese nicht mehr im Quellcode stehen müssen.
12 Verzeichnisse
12.1 Literaturverzeichnis
12.1.1 Bücher
12.1.2 Onlinedokumente
12.2 Abbildungsverzeichnis
Abb. 1 Tabelle: Produkt Segmente XXXX [2]
Abb. 2 Tabelle: Outsourcing Segmente XXXX [2]
Abb. 3 Tabelle: Online Marketing Segmente XXXX [2]
Abb. 4: Tabelle: Vorgänge mit Aufwandsschätzung des Projektes
Abb. 5: Diagramm: Meilenstein Netzplan des Projektes
Abb. 6: Diagramm: MPM Netzplan des Projektes
Abb. 7: Tabelle: Die Entwicklung des JDK
Abb. 8: Diagramm: XML als Datenaustauschformat
Abb. 9 Tabelle: Funktionale Anforderungen
Abb. 10 Diagramm: Entwurf des Anwendungsfensters
Abb. 11: Diagramm: Anwendungsverhalten
Abb. 12 Tabelle: Randbedingungen der Anforderungen
Abb. 13 Tabelle: Qualitätsanforderungen
Abb. 14: Screenshot: SSE Startschirm
Abb. 15: Screenshot: SSE mit geöffnetem Kunden - Vertragsübersicht
Abb. 16: Screenshot: SSE mit geöffnetem Kunden – Kundenkontaktnotiz verfassen
Abb. 17: Screenshot: SSE Wizard beim Schließen/Weiterleiten eines Kunden
Abb. 18 Diagramm: Systemskizze SSE
Abb. 19 Diagramm: Eclipse Architektur
Abb. 20 Diagramm: Eclipse Framework Übersicht
Abb. 21 Screenshot: Eclipse User Interface
Abb. 22 Screenshot: Eclipse Dialogfenster
Abb. 23 Screenshot: Other Regel
Abb. 24 Tabelle: Erläuterungen zu Eclipse XML Tags der Plug-In Manifest Datei
Abb. 24 Tabelle: Erläuterungen zu Eclipse XML Tags der Plug-In Manifest Datei
Abb. 26 Tabelle: Erläuterungen zu Eclipse XML Tags der Plug-In Manifest Datei
Abb. 27 Tabelle: Möglichkeiten der Eclipse Erweiterungen
Abb. 28 Tabelle: Eclipse Beispiel Symbolleistenerweiterungen
Abb. 29 Diagramm: Eclipse - Verbindung zwischen Plug-In’s
Abb. 30 Tabelle: Eclipse – Erläuterungen zu bestimmten Methoden
Abb. 31 Tabelle: Eclipse – Erläuterungen zu bestimmten Methoden
Abb. 32 Diagramm: Eclipse – Vorraussetzungen, Struktur und Inhalte von Plug-In’s
Abb.33 Screenshot: NetBeans Anwendung ECSI MINEX V
Abb.34 Screenshot: NetBeans Anwendung XEMO
Abb.35 Screenshot: Bean Builder
Abb. 36 Diagramm: JFrame
Abb. 37 Diagramm: Sequenzdiagramm Display-Shell
Abb. 38 Screenshot: Swing Fenster
Abb. 39 Screenshot: SWT Fenster
Abb. 40 Diagramm: Sequenzdiagramm Swing Beispiel
Abb. 41 Diagramm: Sequenzdiagramm SWT Beispiel
Abb. 42 Diagramm: Klasse de.einsundeins.ccsys.rcf.RCFCore
Abb. 43 Diagramm: Sequenzdiagramm der Klasse de.einsundeins.ccsys.rcf.RCFCore
Abb. 44 Diagramm: Klassendiagramm Package de.einsundeins.ccsys.rcf.configdocuments
Abb. 45 Diagramm: Klassendiagramm Package de.einsundeins.ccsys.rcf.swing
Abb. 46 Diagramm: Klasse de.einsundeins.ccsys.rcf.RCFCore (mit InfoBus)
Abb. 47 Diagramm: Interface de.einsundeins.ccsys.rcf.infobus.RCFInfoBus
Abb. 48 Diagramm: Klassendiagramm Package de.einsundeins.ccsys.rcf.infoBus und Consumer
Abb. 49 Diagramm: Klasse de.einsundeins.ccsys.rcf.beanCommunication.RCFBeanCommunication)
Abb. 50 Diagramm: Klassendiagramm Package de.einsundeins.ccsys.rcf.beanCommunication.memberTypes
Abb. 51 Diagramm: Klassendiagramm Package de.einsundeins.ccsys.rcf.beanCommunication.Exceptions
Abb. 52 Diagramm: Klassendiagramm Package de.einsundeins.ccsys.rcf.beanCommunication.eventModel
Abb. 53 Diagramm: Klassendiagramm Producer
Abb. 54 Diagramm: Sequenzdiagramm Producer
Abb. 55 Diagramm: Klassendiagramm RCFBeanCommunicationDataProducer
Abb. 56 Diagramm: Klassendiagramm RCFBeanCommunicationEventMulticaster
Abb. 57 Diagramm: Sequenzdiagramm RCFBeanCommunicationEventMulticaster
Abb. 58 Diagramm: Klassendiagramm Consumer
Abb. 59 Diagramm: Sequenzdiagramm Consumer
Abb. 60 Screenshot: Prototyp rcfMitInfoBus
Abb. 61 Tabelle: Kommentar zu den Funktionale Anforderungen
12.3 Abkürzungsverzeichnis
SSE: Service Support Environment
EU: Europäische Union
DSL Digital Subscriber Line
ISP Internet Service Provider
CGI Common Gateway Interface
WLan Wireless Local Area Network 1.2.7
WWW World Wide Web
FH Fachhochschule
MPM Metra Potential Method->Vorgansknotennetzplan1.4.3
JDK Java Development Kit 2.1
JRE Java Runtime Environment
RMI Remote Methode Invocation
JFC Java Foundation Classes
AWT Abstract Window Toolkit
JSP Java Server Pages
API Open Application Programming Interface
J2ME Java-2 Micro Edition
J2SE Java-2 Standard Edition
J2EE Java-2 Enterprise Edition
VM Virtual Machine
I/O Input/Output
GUI Grafische Benutzerschnittstelle
SWT Standard Widget Toolkit2.4.
CRM Customer Relationship Management
SGML Standard Generalized Markup Language
HTML Hypertext Markup Language
SAX Simple API for XML
DOM Document Object Model
DTD Dokumenttypdefinition
W3C Word Wide Web Consortium
RDF Resource Description Framework
SPAM ein Datenbank der XXXX der Firma
DB Datenbank
UI User Interface
JDT Java Development Tools
PDE Plug-In Development Environment
VCM Versions- und Konfigurationsmanagement
CVS Concurrent Versions- System
RAD Rapid Application Development
IDE-Bus Integrated Drive Electronics -Bus
IDE integrated developement evironment
JAR Java Archiv
13 Anhänge
13.3 XML Konfigurationsdatei Beispiele
13.3.1 appConfig.xml
<?xml version="1.0" encoding="UTF-8"?>
<application>
<app_name>SSE Prototyp</app_name>
<version>0.0.1</version>
<company>XXXX die Firma</company>
<position_X>80</position_X>
<position_Y>80</position_Y>
<dimension_X>800</dimension_X>
<dimension_Y>600</dimension_Y>
<enable_menue>true</enable_menue>
<enable_logging>false</enable_logging>
<menue>beispielmenü
<menue_item>senden
<menue_item_command>ProducerA_send</menue_item_command>
</menue_item>
<menue_item>clear
<menue_item_command>ProducerA_clear</menue_item_command>
</menue_item>
</menue>
<mod_name>Bean1</mod_name>
<mod_name>Bean2</mod_name>
<mod_name>Bean3</mod_name>
<mod_name>Bean4</mod_name>
<mod_name>Bean5</mod_name>
</application>
13.3.2 Bean1.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<module>
<mod_name>Bean1</mod_name>
<bean>TestBeanA</bean>
<visible>true</visible>
<layout>
<lay_width>1</lay_width>
<lay_height>1</lay_height>
<lay_grid_X>0</lay_grid_X>
<lay_grid_Y>0</lay_grid_Y>
<lay_weigth_X>1.0</lay_weigth_X>
<lay_weigth_Y>1.0</lay_weigth_Y>
</layout>
</module>