Entwicklung eines Plugin fähigen Editors zur Projektverwaltung auf

Entwicklung eines Plugin fähigen Editors zur Projektverwaltung auf
Technische Universität Dresden
Fakultät Informatik
Institut für Systemarchitektur
Professur Rechnernetze
Großer Beleg
Entwicklung eines Plugin fähigen Editors
zur Projektverwaltung auf Basis
Eclipse Rich Client Architektur
Clark Helwig
Matr. Nummer 2 564 176
Betreuer :
Dr. Andriy Luntovskyy
Dr. Dietbert Gütter
Hochschullehrer :
September 2006
Prof. Dr. A. Schill
Technische Universität Dresden
Fakultät Informatik, Professur Rechnernetze
AUFGABENSTELLUNG FÜR GROßEN BELEG
Name, Vorname:
Helwig, Clark
Studiengang:
Medieninformatik
Matrikelnummer:
2 564 176
Thema :
Entwicklung eines Plugin fähigen Editors
zur Projektverwaltung auf Basis Eclipse
Rich Client Architektur
Zielstellung :
Innerhalb des CANDY-Frameworks wurden mehrere Tools
zur Unterstützung der Rechnernetzprojektierung entwickelt. Dabei wurden oftmals Tools von Anfang an neu
entwickelt. Ziel dieser Arbeit ist es, zu untersuchen, wie
die Toolentwicklung vereinfacht und verkürzt werden kann.
Als möglicher Ansatz kommt das Eclipse Rich Client Framework in Frage. Es wird untersucht, wie sich das Rich
Client Framework für einen derartigen Ansatz eignet. Ein
graphischer Editor für die Projektverwaltung wird implementiert. Dieser soll so gestaltet werden, dass durch einfaches hinzufügen von Plugins dieser an Erweiterung der
NDML angepasst werden kann. Anhand dieses Editors wird
untersucht, wie sich die gefundenen theoretischen Erkenntnisse praktisch in die CANDY Tool Entwicklung einfügen
lassen.
Betreuer :
Dr. Andriy Luntovskyy
Dr. Dietbert Gütter
Verantwortlicher Hochschullehrer :
Prof. Dr. A. Schill
Beginn am :
14. 6. 2006
Einzureichen am :
14. 12. 2006
Selbstsständigkeitserklärung
Hiermit erkläre ich, dass ich den vorliegenden Großen Beleg selbstständig angefertig habe. Es sind dazu nur die angebenen Quellen
benutzt worden. Zitate und Bilder verfügen über entsprechende
Quellenangaben.
Clark Helwig
vi
12. September 2006
Inhaltsverzeichnis
1 Vorbetrachtungen
1
1.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Anforderungen an Entwicklungsumgebung und Software Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Eclipse Rich Client Plattform
1
2
5
2.1
Anforderung und Definition Rich Client . . . . . . . . . . . . . .
5
2.2
Aufbau und Architekturder Rich Client Plattform . . . . . . . .
7
2.2.1
7
2.3
RCP Komponenten und ihre zugehörigen Klassen . . . .
Die Entwicklung eines Plugins . . . . . . . . . . . . . . . . . . . 10
2.3.1
Präferenzen . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Graphische Schnittstellen
3.1
13
AWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1
Ereignisverwaltung in JAVA . . . . . . . . . . . . . . . . 15
3.2
Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3
SWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4
3.3.1
Wesentliche Klassen und Packages . . . . . . . . . . . . . 17
3.3.2
Oberflächenkomponenten . . . . . . . . . . . . . . . . . . 18
3.3.3
SWT eigene Layoutmanager . . . . . . . . . . . . . . . . 19
3.3.4
Dialoge
3.3.5
Nebenläufigkeit von Oberflächenkomponenten . . . . . . 21
3.3.6
Integration von AWT/Swing Komponenten . . . . . . . . 22
. . . . . . . . . . . . . . . . . . . . . . . . . . . 21
JFace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.1
Unterstützung für Ressourcen . . . . . . . . . . . . . . . 23
3.4.2
Fenster und Dialoge
. . . . . . . . . . . . . . . . . . . . 24
viii
Inhaltsverzeichnis
3.5
3.4.3
Einsatz von Viewer . . . . . . . . . . . . . . . . . . . . . 26
3.4.4
Menüs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.5
Weitere Komponenten zur Nutzerinteraktion . . . . . . . 27
GEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.1
3.6
Weitere Eigenschaften GEF . . . . . . . . . . . . . . . . 29
Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Beschreibungssprachen für CANDY Dokumente
4.1
XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1
4.2
33
Begriffsbstimmung . . . . . . . . . . . . . . . . . . . . . 35
NDML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Implementierung der Anwendung
39
5.1
Allgemeine Anforderung . . . . . . . . . . . . . . . . . . . . . . 39
5.2
Eclipseterminologie . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3
5.4
5.5
5.2.1
Workbench . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.2
Perspektive . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.3
Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.4
Aktionen, Kommandos . . . . . . . . . . . . . . . . . . . 43
5.2.5
Pluginintegration . . . . . . . . . . . . . . . . . . . . . . 43
Implementierungsdetails . . . . . . . . . . . . . . . . . . . . . . 46
5.3.1
Workspace Konzept . . . . . . . . . . . . . . . . . . . . . 46
5.3.2
Erstellen einer RCP Anwendung . . . . . . . . . . . . . . 46
5.3.3
Erstellen eines Views . . . . . . . . . . . . . . . . . . . . 47
5.3.4
Erstellen eines Editors . . . . . . . . . . . . . . . . . . . 48
5.3.5
Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.6
Wizard Implentierung . . . . . . . . . . . . . . . . . . . 53
5.3.7
XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Package- und Verzeichnisstruktur, Namenskonventionen . . . . . 54
5.4.1
Package- und Verzeichnisstruktur . . . . . . . . . . . . . 54
5.4.2
Namenskonventionen und Programmierempfehlungen . . 56
Noch offene Probleme . . . . . . . . . . . . . . . . . . . . . . . . 57
5.5.1
Verteiltes Bearbeiten, Synchronisation . . . . . . . . . . 57
5.5.2
Workspaceverzeichnis ändern
6 Fazit
. . . . . . . . . . . . . . . 58
59
12. September 2006
Inhaltsverzeichnis
ix
Glossar
63
Anhang
67
12. September 2006
x
Inhaltsverzeichnis
12. September 2006
1 Vorbetrachtungen
1.1 Einleitung
Das Computer Aided Network Development Utility (CANDY) Projekt umfaßt
die Entwicklung einer Menge von Tools die zur Planung von Netzwerken und
Bestimmung ihrer (informations-)technischen Eigenschaften genutzt werden.
Für den genauen Aufbau von CANDY wird auf die Arbeit von Rico Klinkewitz ([Kli05]) verwiesen. Dabei ist bereits jetzt das Problem existent, dass viele
Tools nebeneinander existieren. Die Wiederverwendbarkeit von Komponenten
ist derzeit recht gering. Des weiteren wird viel Zeit benötigt, aus den ermittelten fachlichen Lösungen geeignete Anwendungen zu erstellen. Es ist daher
notwendig, dass bei der Entwicklung von neuen Tools der Aufwand auf die
fachlichen Problemlösung verlagert wird, während die Umsetzungsaufwand als
Anwendung deutlich reduziert werden muß.
Daraus ergibt sich die Forderung, die Menge an wiederbenutzbaren und tatsächlich wiederbenutzten Komponenten zu erhöhen. Zunächst wird bestimmt,
welche Komponenten sich besonders für eine hohe Wiederbenutzbarkeit eigenen bzw. mit geringen Anpassungen in verschiedenen Anwendungen benutzt
werden können.
Ein Programm läuft in der Form ab, dass Daten hineingeben werden. Diese Daten werden be/verarbeitet und danach ausgeben. Bei Betrachtung von
CANDY Tools läßt sich diese Prozeßkette ebenfalls gut erkennen:
1 Daten werden aus Dateien gelesen und in das lokale Objektmodell der
Anwendung geladen oder bei Neuanlegen eines Projektes wird das lokale
Objektmodell initialisiert.
2
1 Vorbetrachtungen
2 Werden diese Daten bearbeitet geschieht dies durch
2.a den Nutzer mittels GUI oder
2.b durch interne Routinen, in denen die fachlichen Lösungen implementiert sind
3 Die Änderungerungen werden persistent gespeichert
Ansätze für eine hohe Wiederbenutzbarkeit können sich ergeben bei dem Prozeß des Dateneinlesens (1). Da die CANDY Tools auf XML Datein zur Datenhaltung aufsetzen, muß der Prozeß des Dateneinlesens nur noch an die
fachspezifischen Tags angepaßt werden und die korrespondieren Objekte im
lokalen Objektmodell. Mit der selben Begründung läßt sich eine hohe Wiederverwendbarkeit beim Prozeß des persistenten Speichern erwarten (3). Für
die GUI (2a) kann die Wiederverwendbarkeit erhöht werden, in dem ensprechende Dialoge, Fenster etc. zur Verfügung gestellt werden, die dann an das
jeweilige lokale Objektmodell der Anwendung angepaßt werden müssen. Durch
ausführliche Dokumentation und Beispielimplementierungen kann der Einarbeitungsaufwand reduziert werden. Die internen Routinen (2b) lassen keine
oder eine nur sehr geringen Wiederbenutzbarkeit erwarten. Dies liegt daran,
dass diese Routinen individuelle Problemlösungen für einzelne CANDY Tools
implementieren. Ein Ansatz zur erhöhung der Wiederverwendbarkeit könnte
jedoch darin bestehen, die verwendeten Algorithmen so allgemein zur gestalten, das sie von verschiedenen Tools genutzt werden können.
1.2 Anforderungen an Entwicklungsumgebung
und Software Bibliotheken
Aus den oben genannten Problemen lassen sich folgende Anforderungen und
Entscheidungskriterien für die Auswahl geeigneter Programmierschnittstellen
herleiten:
1 Integrationsfähigkeit bisher erstellten Programmcodes
2 Unterstüzung durch Entwickler-/ Programmiertools
3 Angebot an höherwertigen GUI Funktionalitäten
12. September 2006
1.2 Anforderungen an Entwicklungsumgebung und Software Bibliotheken3
4 Unterstüzung von nicht codeverändernden Erweiterbarkeit, bspw. durch
Plugin-Konzepte
5 freie Verfügbarkeit der Komponenten
6 Verfügbare Dokumentationen
7 Unterstützung von XML.
Ausgehend von 1. ergibt sich, dass als Programmiersprache Java benutzt wird,
da diese für bisherige Lösungen benutzt wurde. Entsprechende Unterstützung
im Sinne von 2 ist durch NetBeans von Sun, durch JBuilder von Borland, BlueJ
und Eclipse gegeben. Interessant ist der Aspekt der GUI Funktionalitäten nach
Punkt 3. Natürlich ist es möglich in Programme, die mittels vorgenannten Editoren erstellt werden, GUI Funktionaläten von JAVA zu implementieren. Zusätzlich bietet JBuilder die Möglichkeit GUI Oberflächen mittels graphischen
Editor zu erstellen. Für die Eclipse IDE sind Plugins erhältlich, die ebenfalls bei Erstellung von Oberflächen genutzt werden können. Zusätzlich bietet
Eclipse mittels SWT eine eigene GUI Bibliothek an. Diese verfügt über mehr
Funktionalitäten als die Standart JAVA Bibliotheken AWT und Swing und
ist performanter als Swing. Gegenwärtig bietet nur Elipse eine Unterstützung
für die Entwicklung von Software, die mittels Plugin erweiterbar sein soll. Bei
den anderen genannten IDEs muß eine Plugin Architektur selbst entwickelt
werden. Sowohl die JAVA Laufzeitumgebung (JRE,) das Java Software Developement Kit (Java SDK) als auch die SWT Bibliothek sind frei verfügbar
und können für eigene Programme benutzt werden. Ebenso sind für Java als
auch AWT, Swing und SWT entsprechende Dokumentationen, Tutorials und
Beispielprogramme verfügbar. Eine Unterstützung für XML ist durch JAVA
gegeben, entsprechende Klassen zur Unterstützung der CANDY Dokumente
muß aber noch entwickelt werden.
Nach dieser einführender Vorbetrachtung läßt sich feststellen, dass derzeit nur
die Eclipse IDE mit RCP Unterstützung über Merkmale verfügt, die deutlich
über die JAVA Standart Distribution hinausgehen. Daher wird eingehender
untersucht, wie sich RCP als Basis für die Entwicklung zukünftiger CANDY
Tools eignet.
12. September 2006
4
1 Vorbetrachtungen
12. September 2006
2 Eclipse Rich Client Plattform
2.1 Anforderung und Definition Rich Client
Die Eclipse Rich Client Plattform ist ein Framework zur Erzeugung von Anwendungen und deren graphischen Benutzeroberflächen. Zunächst wird untersucht, was unter einem Rich Client verstanden wird, und wie die Eclipse Rich
Client Plattform, im folgenden RCP genannt, die Entwicklung von Rich Clients
unterstützt.
Der Begriff des Clients legt nahe, dass eine Unterstüzung für eine Client-Server
Architektur in der RCP vorhanden ist oder die Entwicklung von entsprechenden Clients durch das Framework unterstützt wird. Es kann nun zwischen zwei
Arten einer Client-Server Architektur unterschieden werden. Zum einen in Sinne eines verteilten Systems, bei der die Kommunikation zwischen Client und
Server über Netzwerkprotokolle funktioniert. Eine andere mögliche Bedeutung
ist, dass ein Serverprozeß a¨ls lokaler Dienstabieter agiert und beliebige Clients mittels Interprozeßkommunikation auf diese Serverdienste zugreifen kann.
Rich Client würde darüber hinaus bedeuten, dass der Client über eigene Programmlogik verfügt und somit eine Teilautonomie gegenüber dem Server hat.
Folgende Merkmale werden deshalb als wesentliche Eigenschaften eines Rich
Clients erachtet (vgl. [Bal00] und [Dau05]):
• Architekturtransparenz: Dem Nutzer soll verborgen sein, ob der Rich
Client in einem (echt) verteilten System agiert, eine Anwendung ist, die
auf andere lokale Diensteanbieter aufbaut oder um eine, abgesehen von
Betriebssystemdiensten, autonome Anwendung handelt.
• Interfacehomogenität: Das für den Nutzer gewohnte Interface wird zur
6
2 Eclipse Rich Client Plattform
Nutzer-Programm-Interaktion benutzt.
• Teilautonomie: Wesentliche Funktionen des Clients stehen auch ohne Server zur Verfügung. Dies erfordert lokale Datenhaltung sowie Synchronisationsmechanismen mit dem Server.
• Synchronisation: Ermöglicht die lokalen Daten mit einem Server abzugleichen und somit Datenkonsistenz sicherzustellen.
• Selbstmodifikation: Der Client konfiguriert sich selbständig, in dem er
Updates und Erweiterungen weitesgehend selbständig einbindet.
• Serverzentrierte Konfiguration: Zentral gespeicherte Nutzer- bzw. Rollenprofile mit ihren Rechten und Konfigurationen werden durch den Client
entsprechen auswertet und sein Verhalten danach entsprechend angepaßt.
Gerade der Aspekt der Teilautonomie unterscheidet wesentlich den Rich Client von anderen Clients in verteilten Anwendungen wie Anwendungen, die
Webbrowser als Nutzerinterface haben. Erfüllt ein Client die obigen Anforderungen, ist er ebenfalls mobil. Dass bedeutet dass dieser Client ortsunabhängig
benutzt werden kann.
Die RCP unterstütz jedoch zunächst nur die Entwicklung von Anwendungen,
die Forderungen nach Selbstmodifikation, Serverzentrierter Konfiguration und
Interfacehomogenität erfüllen sollen, und damit wird nur die Entwicklung von
nichtverteilten Anwendungen direkt unterstützt. Um Anwendungen entwickeln
zu können, die die Forderungen Teilautonomie und Synchronisation zu erfüllen, müssen die Clienten entsprechend durch zusätzliche Plugins erweitert werden. Dies spielt jedoch nur dann eine Rolle, wenn dies auch erforderlich ist.
Für eine Projektverwaltung z.B. kann unter Umständen die Forderung nach
Synchronisation mit anderen Clients bestehen, je nachdem welche funktionalen Anforderungen an die Projektverwaltung im Detail gestellt werden. Nach
Festlegung der funktionalen Anforderungen kann geprüft werden in welchem
Umfang welche Plugins mit integriert werden müssen.
Als erste Einschätzung zeigt sich, dass RCP die Entwicklung von Client Software nicht unterstützt. Diese fehlende Unterstützung ist jedoch durch das modulare Plugin Konzept der RCP zu kompensensieren, welches die Einbindung
12. September 2006
2.2 Aufbau und Architekturder Rich Client Plattform
7
von Plugins von Drittanbietern unterstützt. Ausblickend sei bemerkt, das es
jedoch bereits Projekte gibt, die eine entsprechende Client Entwicklung ins
RCP zu integrieren. Als Verweis seien [Eco06] und [Ecl07] genannt.
2.2 Aufbau und Architekturder Rich Client
Plattform
Die Rich Client Architektur wie sie hier dargestellt wird, existiert so erst seit
Version 3.0 der Eclipse IDE. In den vorhergehenden Versionen handelte es sich
bei der Eclipse IDE um eine durch Plugins erweiterbare Anwendung. Ab Version 3.0 gibt es eine völlig neu gestaltete Architektur, die sich unterteilt in einen
Kernel der für die Steuerung, auch als OSGi Plattform bzw. Eclipse Runtime
bezeichnet, und Plugins. Der Kernel ist für die Verwaltung und das Laden von
Plugins zuständig. Alle weitere Bestandteile der RCP Binärdistribution sind
bereits als Plugins realisiert. Diese Plugins geben wesentliche Unterstützung
für Graphische Nutzerinteraktion, im folgenden als GUI für graphical user interface abgekürzt. Diese neue Architektur des RCP Plattformkonzept fand in
der Eclipse IDE ihre erste volle Umsetzung. Die Eclipse IDE ist somit eine
RCP Anwendung, die erst durch Plugins ihre volle Funktionalität erhält. Die
folgende Abbildung zeigt, welche Kernkomponenten RCP sind. Die mitabgebildeten Bestandteile der Eclipse IDE nutzen diese Kernkomponenten, in dem
sie sich an die entsprechen Schnittstellen binden.
2.2.1 RCP Komponenten und ihre zugehörigen Klassen
Für das Verständnis der Funktionsweise der RCP werden nun die einzelnen
Klassen und Funktionalitäten erläutert, um zu verstehen welche Funktionalitäten durch die RCP zur Verfügung stehen und welche Abhängigkeiten bei
Nutzung der einzelnen Komponenten damit einhergehen.
12. September 2006
8
2 Eclipse Rich Client Plattform
Text/ IDE Compare
Help
Update
Text
'
GUI (Generic Workbench)
Forms, Editors, Views
& Dialogs, Wizard
JFace
SWT
Debug
Search
Team
IDE
$
% Workspace/ Ressources
OSGi plattform (Eclipse runtime)
Abbildung 2.1: Schematischer Aufbau der Eclipse IDE, oval umrundet die
Komponenten der RCP vgl.[Dau05] S.10ff
Eclipse Runtime
Diese Ebene stellt die Kernfunktionen der RCP zur Verfügung. Dabei ist der
Kern von Eclipse nur ein Microkernel, der nur dafür zuständig ist, die Plugins
zu starten. Dieser Microkernel lädt beim Start die Plugins org.eclipse.core.commands, org.eclipse.core.expressions und org.eclipse.core.runtime. Weiterhin werden die Plugins org.eclipse.osgi und org.eclipse.update.configurator geladen. Die ersten drei genannten Plugins sind, wie die Namen der Plugins
anzeigen, für die Funktionen des Kerns zuständig. Die beiden letztgenannten
Plugins ermöglichen die einfache Intergration von weiteren Plugins.
Das Plugin org.eclipse.osgi implementiert dabei die Funktionen des OSGiStandards (Open Service Gateway Initiative). Dabei ist der Zweck dieser Initiative, Dienste zu standardisieren, die in eingebetteten Geräten oder lokalen
Netzwerken zum Einsatz kommen. OSGi Server können dann von OSGi konformen Diensten genutzt werden. Java Anwendungen werden auf einem OSGi konformen Server in Form von Bundles eingesetzt. Dabei arbeitet Eclipse
Ablaufkern als OSGi Server und die Eclipse Plugins entsprechen den OSGi
Bundels. Die Eclipse Plugins und die OSGi Bundles werden jedoch durch unterschiedliche Klassen repräsentiert. Und der Eclipse Ablaufkern stellt seine
Funktionen nur der konkreten Anwendung zur Verfügung, die ihn aufruft. Damit handelt sich bei RCP also nicht um eine Client-Server Architektur im Sinne
des Kapitels 1.1, wenngleich die RCP über eine sehr stark daran orientierte
Architektur verfügt.
12. September 2006
2.2 Aufbau und Architekturder Rich Client Plattform
9
Das Einbinden von weiteren Plugins wird durch das Plugin org.eclipse.update.configurator ermöglicht. Auch dabei wird auf die Vorgaben der OSGi zurückgegriffen, indem dieses Kern-Plugin aus den sogenannten Manifesten herausliest,
welche Plugins geladen werden müssen. Ein Plugin Manifest ist eine XMLDatei die stets den Namen plugin.xml tragen muß. Dabei werden, sofern es
nicht ausdrücklich durch das Manifest konfiguriert ist, keine Instanzen von
Klassen erzeugt. Im Manifest werden die Schnittstellen für die Plugins konfiguriert. Unterschieden wird hier zwischen Extensions und Extension Points.
Extensions binden dabei ein Plugin an einen Extenstion Point, dass bedeudet,
das die Extension auf Seite des Plugins für eine Anbindung an die Eclipse
Laufzeitumgebung sorgt, während der Extension Point auf Seite der Laufzeitumgebung die Anbindung von Plugins ermöglicht. Ein Plugin muß damit über
eine Extension verfügen kann aber auch selbst Extension Points für andere
Plugins anbieten.
SWT, JFace, UI
Diese, ebenfalls als Plugin realisierten Kernkomponenten stellen Methoden zur
Gestaltung von GUIs zur Verfügung. Das SWT (Standard Widget Toolkit) ist
systemnah, während JFace und UI Komponenten auf SWT Methoden zurückgreift. Wesentliche Plugins sind dabei org.eclipse.swt, org.eclipse.jface (ohne
Textverarbeitung), org.eclipse.ui und org.eclipse.workbench. Wie die Klassen
miteinander agieren und welche Unterscheidungsmerkmale es gibt, wird ausführlich im Kapitel 2 untersucht.
Help
Das Plugin org.eclipse.help stellt Methoden zur Einbindung von geeigneten
Hilfesystemen zur Verfügung.
Alle bisher in diesem Kapitel erwähnten Plugins sind in einem sogenannten
Feature zusammengefaßt, mit den dem Namen org.eclipse.rcp. Folgende Plugins, die zunächst für die Entwicklung von Editoren entwickelt wurden, sollten
auf Nutzbarkeit für die gegebene Aufgabenstellung untersucht werden :
• Für Implementierung von verschiedenen Rollen kann es sich anbieten,
12. September 2006
10
2 Eclipse Rich Client Plattform
verschiedene Ansichten (Views) zu implementieren. Dafür eignet sich
das Plugin
org.eclpise.ui.views
• Soll der Nutzer die Möglichkeit bekommen, die XML/ NDML Dateien zu
bearbeiten, muß ein entsprechender Editor intergriert werden. Die Plugins
org.eclipse.ui.workbench.texteditor und org.eclipse.ui.editors stellen Methoden für Editoren zur verfügung.
• Muß es eine Möglichkeit geben, Berichte zu verfassen, wird eine Textverarbeitung benötigt. Die Entwicklung wird durch die Plugins org.eclipse.text
und
org.eclipse.jface.text unterstützt.
• Für die Erweiterung des Hilfesystems können die Plugins org.eclipse.help.base,
org.eclipse.help.ui und org.eclipse.ui.forms
Für die Entwicklung von Diagrammeditoren sei auf das GEF-Projekt (Graphical Editor Framework) unter [Geo06] verwiesen.
2.3 Die Entwicklung eines Plugins
In dem vorhergehenden Kapitel wurde dargelegt, dass eine RCP Anwendung
aus einem Kernel besteht, der die Plugins verwaltet und den Plugins, die die
Funktionen der Anwendung implementieren. Somit ist Anwendungsentwicklung gleichbedeutend mit Plugin Entwicklung. Diese Plugins werden in Java
realisiert und bestehen damit aus einem oder mehreren Java Archiven, die zur
Ausführung der Anwendung notwendig sind. Es ist auch möglich, Plugins zu
entwicklen, die keine Klassen enthalten. Dies kann zu deklarativen Zwecken
geschehen. Da aber eine Anwendung entwickelt werden soll, welche über die
entsprechende Funktionen verfügt , wird dieser Fall hier nicht weiter betrachtet. Auch wenn es nicht zwingend erforderlich ist, ein neues Plugin von der
abstrakten Klasse Pluginabzuleiten. wird dies ausdrücklich empfohlen. Dadurch ist es möglich auf Plugin-spezifische Benutzerpreferenzen und den OSGi
Kontext zuzugreifen.
12. September 2006
2.3 Die Entwicklung eines Plugins
11
Bis einschließlich Version 3.0 der Eclipse IDE war die Entwicklung von Plugins
recht aufwendig. Sämtliche Klassen, die für die Interaktion des Eclipse Kerns
benötigt wurden, mußten von Hand eingebunden bzw. abgeleitet werden. Seit
Version 3.1 wird das Entwickeln von Plugins durch einen entsprechenden Assistenten unterstützt. Dies reduziert nicht nur den Entwicklungsaufwand, sondern auch die Fehlerwahrscheinlichkeit. Die eigentliche Konfiguration erfolgt in
dem entsprechenden Assistenten, der auch eine entprechende Manifest Datei
plugin.xml erzeugt. Die dabei erzeugten Klassen können nun erweitert und an
die eigenen Anforderungen angepaßt werden.
Bei der Aktivierung eines Plugins wird genau eine Instanz des konkreten Plugins erzeugt (Singleton-Pattern). Wird später die Instanz des Plugins benötigt,
kann darauf mittels der Methode getDefault zugegriffen werden. Dadurch, dass
Methode statisch ist, kann sie nicht überschrieben und erweitert werden. Soll
diese Methode erweitert werden, geht dies nur durch entwicklen einer neuen Methode, die dann getDefault aufruft. Beim Aktivieren eines Plugins wird
die Methode start() aufgerufen. Diese kann für anwendungsspezifische Initialisierungaktivitäten genutzt werden. Als Beispiel sei Anmeldung an einen Server genannt. Die Methode stop() ist das entsprechende Gegenstück zu start()
und wird beim Deaktiveren eines Plugins aufgerufen. In dieser stop() Methode
könnte beispielsweise die Verbindung zu einem Server beendet werden. Besteht
die Notwendigkeit, den Installationsort einer Pluginkomponente zu ermitteln,
geht dies mittels find(). Das zurückgelieferte Resultat muß dann jedoch noch
mittels Platform.resolve() umgewandelt werden, damit es benutzbar ist.
Ist ein Plugin dafür vorgesehen, an der Benutzerobefläche zu erscheinen, sollte es nicht von der Klasse Plugin abgeleitet werden sondern von der Klasse
AbstractUIPlugin. Die Klasse AbstractUIPlugin ist von der Klasse Plugin abgeleitet. Sie implementiert zusätzlich einige Methoden, die die Interaktion und
Gestaltung des Nutzerinterfaces erleichtern. Es seien die Methoden imageDescriptorFromPlugin() für das Laden von Bildern und getDialogSettings() zur
Abfrage aller persistenten Dialoge genannt.
12. September 2006
12
2 Eclipse Rich Client Plattform
2.3.1 Präferenzen
In den vorhergehende Absätzen ist bereits der Begriff der Präferenz genannt
worden, der hier nun genauer beschrieben wird. Präferenzen beschreiben Voreinstellungen eines Plugins. Diese werden durch entsprechende Tripel repräsentiert, und durch die Klasse Preferences unterstützt. Diese Tripel bestehen
aus je einem Namen, einem Wert und einer Vorbelegung. Dabei können die
Werte und Vorbelegungen durch entsprechende getValue und setValue Methoden abgefragt und modifiziert werden. Die Werte werden durch Benutzereingaben festgelegt und persistent gespeichert. Die Vorbelegungen werden nicht
gespeichert und sind entsprechend durch das Plugin zu setzen. Es werden die
Datentypen boolean, double, float, float, int, long und String unterstützt. Es ist
nicht möglich, Klassen als Präferenz zu benutzen, es wäre nur möglich, Klassenattribute in den vorgenannten Datentypen zu speichern. Wenn sich Werte
der Präferenzen ändern, können diese Änderungen mittels IPropertyChangeListener wahrgenommen werden.
12. September 2006
3 Graphische Schnittstellen
Für einen Editor zur Projektverwaltung ist es wichtig, dass dieser intuitiv zu
bedienen ist. Es ist davon auszugehen, das sich bestimmte Informationen als
Grafik besser darstellen lassen, als wenn sie textuell beschrieben werden. Als
Beispiel seien zwei Aufgaben innerhab eines Projektes benannt, die aufeinander aufbauen. Ist Aufgabe 1 Vorraussetzung für das Ausführen von Aufgabe 2,
kann dies durch Pfeile deutlich gemacht werden, während die Aufgabe selbst
als Viereck dargestellt werden kann. Der Benutzer des Editors würde sich vermutlich wünschen, dasß Aufgaben, die in Verzug geraten sind, farblich hervorgehoben werden . Oder er möchte Zusatzinformationen speichern, die er aber
nur bei Auswähl des vorgenannten Vierecks einsehen möchte, weil sie sonst die
Übersichtlichkeit behindern würden.
Dieses einleitende Beispiel zeigt, welche Anforderungen an ein Interface für
eine Projektverwaltung gestellt werden könnten. Gleichzeitig gibt es verschiedene Möglichkeiten, diese in Java zu realisieren. Daher wird in diesem Kapitel
untersucht, welche Möglichkeiten es gibt und wie deren Einsatz in Bezug auf
die Aufgabenstellung zu bewerten sind.
Die ersten beiden Unterkapitel untersuchen AWT und Swing, die Bestandteil
der JAVA-Laufzeitumgebung (JRE ) sind. Diese brauchen daher nicht mit der
RCP Anwendung mitgeliefert werden, was die Anwendung kleiner macht. Die
beiden Plugins SWT und JFace sind in Teilen Bestandteil der RCP Distribution. Das Graphical Editor Framework (GEF) ist kein Bestandteil der RCP,
sondern ein seperates Plugin, welches unter [Geo06] bezogen werden kann. Bei
Benutzung von GEF wäre darauf zu achten, das der Nutzer nach Möglichkeit dieses Plugin nicht seperat installieren muß und dass sich dieses Plugin
aus Sicht des Nutzers vollkommen transparent verhält. Dem Nutzer soll die
14
3 Graphische Schnittstellen
Plugin-Struktur verborgen bleiben.
Auf die Darstellung der einzelnen Klassen wird bei AWT und Swing verzichtet.Dies geschieht ausführlich und übersichtlich in den Java Tutorials und Dokumentationen.
3.1 AWT
Das Abstract Window Toolkit wurde mit Java Version 1.0 eingeführt. Ziel war
es damals, eine Plattformunabhängige aber gleichzeitig native GUI unterstützung zu schaffen. Und diese sollte dabei auch noch sowohl in Java-Applets als
auch in Java programmierten Anwendungen nutzbar sein. Es mußte also eine
Beschränkung erfolgen, d.h. es wurden nur die GUI Elemente untersützt die
auf allen Plattformen vorhanden waren, fur die die JRE verfügbar war. Dies
führte zu dem kleinsten gemeinsamen Nenner, es werden seither durch AWT
im wesentlichen Menüs, Check und Auswahl-Boxen, Buttons, Labels, Textfields/Textareas und Auswahllisten unterstützt. Dazu kommt noch das Panel,
der als Art Behälter für die Graphischen Elemente zu verstehen ist. Dies suggeriert Plattformunabhängigkeit, was jedoch praktisch nicht gegeben ist. Das
liegt daran , dass die einzelnen Elemente auf verschiedenen Systemen unterschiedlich dargestellt werden. So kann es sein, dass ein ein Dialog auf Windows
optisch gut aussieht und auch die Schrift gut lesbar ist, während dies unter Linux und anderen Systemen nicht der Fall ist. Erschwerend kam hinzu, dass
schon mit der Einführung der AWT bestimmte Fenster und Dialog Aufteilungen hart kodiert wurden. Dass heißt die Position von graphischen Elementen
wie z.B. innerhalb von Dialogen wurde in absoluten Werten angegeben. Dies
führt dann dazu, das Schrift nicht korrekt umgebrochen wird, sondern einfach
nur außerhalb des Dialogfensters abgeschnitten wird. Dieses Problem ist jedoch
nicht dem AWT zuzuschreiben, sondern den Programmieren bzw. den von ihnen benutzten Werkzeugen zur Gestaltung der Oberflächen. Das AWT bietet
durch die Layoutmanager Möglichkeiten, Graphische Elemente entsprechend
flexibel anzuordnen und diese Elementanordnung paßt sich dem Zielsystem an.
Für komplexere graphische Elemente wie Tabellen oder auch Auswahlbäume
bietet das AWT keine Unterstützung an.
12. September 2006
3.1 AWT
15
3.1.1 Ereignisverwaltung in JAVA
In der Version 1.0 des Java Developement Kit (JDK) wird auch ein Modell
für die Behandlung von GUI Ereignissen benutzt, welches die Performance einer Anwendung negativ beeinflußsen kann. GUI Ereignisse sind Tastatureingaben und Mausbewegungen oder das Drücken von Maustasten. Bei diesem Modell wird ein Ereignis an die Ereigniskomponente gemeldet, in der es auftritt.
Wird dieses Ereignis in der Ereigniskomponente nicht verarbeitet, so reicht
diese Ereigniskomponente das Ereignis an die in der Komponentenhiearchie
höherliegende Komponente weiter. Ist das Ereignis an das Wurzelelement der
Komponentenhierarchie durchgereicht wurden, und wurde es von diesem Wurzelelement nicht verarbeitet, wird es verworfen. Dies geschieht natürlich sehr
haüfig. Denn das Ereignis Maus bewegt tritt bei einem Graphischen Nutzer System sehr häufig auf, während jedoch meist nur die Ereignisse von Bedeutung
sind, bei denen ein Mausknopf gedrückt wird. Ein weiteres Problem bsteht darin, andere Komponenten über dieses Ereignis zu informieren, wenn sie nicht in
der Komponentenhierarchie zwischen Wurzel und Ereigniskomponente lagen.
Seit JDK Version 1.1 vefügt Java über ein neues Modell der Ereignisbehandlung. Ziel war dabei nicht nur die Perfomanceverluste zu minimieren, sondern
auch eine Möglichkeit zu schaffen, dass Objekte unabhängig von Ihre Position
mit einander über Ereignisse kommunizieren zu lassen. Wird im Modell von
JDK 1.0 ein Ereignis innerhalb der Hierarchie kaskadiert, wird nun das Ereignis
delegiert. Das bedeutet, dass die Ereigniskomponente das Ereignis nur noch an
die Objekte meldet die es verarbeiten wollen. Dafür zuständig sind die sogennanten Listener. Ein Listener registriert ein Objekt bei einer Ereignisquelle.
Tritt ein Ereignis ein, werden ereignisverarbeitende Methoden des durch den
Listener registrierten Objekts aufgerufen. Das führt offensichtlich zu einem
Performancegewinn gegenüber dem Modell des JDK 1.0. Zum anderen erlaubt
es, dass sich beliebige Objekte vom Auftreten ein Ereignises Informieren lassen
können. Gleichzeitig gibt es keine festen Schranken mehr, wieviele Objekte das
Ereignis verarbeiten.
Die Klassen und und Methoden für die Ereignisverarbeitung nach dem Modell
JDK 1.0 sind inzwischen als depreceated gekennzeichnet. Auf deren Verwendung soll bei der Programmierung verzichtet werden, da eine weitere Unter-
12. September 2006
16
3 Graphische Schnittstellen
stützung durch zukünftige JREs nicht mehr sichergestellt ist.
3.2 Swing
Swing ist mit Version 1.1 des JDK veröfflicht worden und ist eine Erweiterung
des AWT. Bei der Entwicklung von Swing stand die Plattformunabhängigkeit im Vordergrund. Jede auf Swing basierende Anwendung sollte auf jedem
System gleich aussehen und sich gleich benutzen lassen. Dies ist auch gelungen, führte jedoch zu dem Problem, dass sich Swing-Anwendungen in der Benutzung und Aussehen von den Anwendungen unterscheiden, die native für
bestimmte Systeme geschrieben sind. Gleichzeitig versucht Swing bestimmte
graphische Komponente des jeweiligen Systems nachzubilden und zeichnete die
graphischen Elemente durch die JRE. Dies führte bei der Benutzung von Swing
zu Perfomanceeinbusen, die jedoch inzwischen aufgrund der Verbesserung der
Just-in-time Compiler bei gleichzeitig steigender Rechenleistung kaum noch
vorhanden sind.
Die Menge der verschiedenen graphischen Elemente, die direkt unterstützt werden hat sich von etwa 20 (AWT) auf etwa 40 bei Swing verdoppelt. In [Mid03]
ist auf Seite 218 in Tabelle 8.1 auch noch eine genaue Auflistung der AWT
und Swing Komponenten zu finden. Zusätzlich sind durch Swing die Layoutmanager BoxLayout und SpringLayout eingeführt worden. Dabei kann nach
[Mid03] in Lightweight- und Heavyweight-Komponenten unterschieden werden.
Zu den Lightweight Komponenten zählen alle Swing Oberflächenkopmonenten außer JApplet,JFrame, JDialog und JWindow. Diese Lightweight Komponenten werden durch die JRE gezeichnet. Die AWT Komponenten werden
als Heavyweight bezeichnet werden. Dabei liegen die Heavyweightkomponente in Z-Richtung über den Lightwightkomponenten und verfügen nicht über
transparenten Bereiche. Heavyweight komponenten sind darüber hinaus stets
rechteckig. Hauptproblem von Swing ist allerdings, dass es nicht von Browsern unterstützt wird und damit Applets von Swing nicht profitieren. Ob dies
mit der nächsten Version von JRE anders wird, kann derzeit nicht beurteilt
werden.
12. September 2006
3.3 SWT
17
3.3 SWT
Das Standard Widget Toolkit, kurz SWT, ist so etwas wie ein Schritt zurück zu
den Anfängen. Es setzt wie AWT auf die graphischen Elementen des jeweiligen
Systems auf. Anwendungen sehen daher auf einem System so aus, wie der
Anwender es von den sonstigen Anwendungen seines Systems gewohnt ist.
Zwar gibt es dadurch Abweichungen in der graphischen Darstellung zwischen
verschiedenen Systemen, jedoch ist dieser Fakt nicht als schwerwiegend zu
bewerten, da Grundfunktionalitäten einer Anwendung erhalten bleiben und ein
Anwender vermutlich nicht so häufig zwischen verschieden ihm unbekannten
Systemen wechselt.
Dass sich mit dem SWT optisch ansprechende, funktionale und performante Oberflächen erstellen lassen, zeigt sich bereits an der Eclipse IDE. Dabei
ist besonders die Möglichkeit hervorzuheben, dass die Aufteilung in verschieden Perspektiven und Views unterstützt wird. Damit ist es möglich, Anzeigen
rollen- und aufgabenspezifisch anzupassen.
3.3.1 Wesentliche Klassen und Packages
Ereignisverwaltung
Die Ereignisverwaltung innerhalb von SWT erfolgt nach dem gleichen Delegationsprinzip, wie es in Java 1.1 eingeführt wurde. Aufgrund eines anderen
Aufbaus wird die Ereignisverwaltung nicht durch die javeeigenen Klassen java.
awt.event..... realisiert, sondern durch Klassen im Package org.eclipse.swt.event.
Layoutmanager
Bei den Layoutmanagern gibt es ebenfalls Abweichungen zu AWT/Swing. Diese werden durch SWT im Package org.eclipse.layout implementiert. Das Borderlayout steht unter SWT standardmäßig nicht zur Verfügung und muß bei
Bedarf nachprogrammiert werden.
12. September 2006
18
3 Graphische Schnittstellen
Weitere Packages und deren Funktionen
• SWT spezifische Konstanten und Exceptions enthält das Package
org.eclipse.swt
• Für die Integration AWT/Swing Komponenten stellt das Package
org.eclipse.swt.awt Methoden zur Verfügung
• Native SWT-Widget Klassen sind im Package org.eclipse.swt.widgets
enthalten
• Nichtnative SWT-Widget Klassen sind im Package org.eclipse.swt.
custom enthalten
• Die Unterstützung für Drag&Drop und die Zwischenablage enthält
das Package org.eclipse.swt.dnd
• Die Druckerunterstützung enthält das Paket org.eclipse.swt.printing
• Der OLE-Mechanismus von Windows wird durch das Paket org.eclipse.
swt.ole.win32 unterstützt
• Graphische Operationen werden durch das Paket
org.eclipse.swt.graphics unterstützt.
3.3.2 Oberflächenkomponenten
Alle Bestandteile einer Benutzeroberfläche werden in SW als Widget bezeichnet. Dazu zählen beispielsweise Buttons, Eingabe/Textfelder, Schieberegler
aber auch Behälter, in denen die einzelnen Komponenten angeordnet werden. Als native Elemente werden die Komponenten bezeichnet, die über eine
korrespondierende Komponente im jeweiligen System verfügen. Durch Aufruf
der entsprechenden Systemfunktionen werden diese dann durch das System
direktgezeichnet. Einige wenige Komponenten, die keine Entsprechung im System haben, werden als nichtnative Komponenten bezeichnet. Die Klassennamen dieser Komponenten beginnen mit einem „C“, gefolgt von einem zweitem
Großbuchstaben. Als Beispiel seien die Klassen CLabel und CCombo genannt.
Alle GUI Komponenten sind von der abstrakten Klasse Widget abgeleitet.
Sie stellt grundlegende Methoden zur Erzeugung und Entfernung von Kompo-
12. September 2006
3.3 SWT
19
nenten und korrespondierenden Listenern zu Verfügung. Eine weiterer Vorteil
besteht darin, das bereits bei der Instanzierung durch sogenante Stilkonstanten
Aussehen und Verhalten konfiguriert werden können. Diese Stilkonstanten sind
in der Klasse SWT vordefiniert. Die Auswertung und Wirkung der einzelnen
Stilkonstante ist natürlich von der konkreten Klasse abhängig. Es ist ebenfalls
möglich, Stilkonstanten mittel „|“ Operator zu kombinieren.
Von der abstrakten Widget Klasse existieren im SWT mehrere abgeleitete
Klassen. Besonders hervorzuheben sind dabei die Klassen Control und Item.
Von der ebenfalls abstrakten Klasse Control sind die bedienbaren GUI Elemente abgeleitet. Sie enthält bereits Methoden für die Ereignisverwaltung. Dazu
zählen folgende Ereignisse: ControlEvent, FocusEvent, HelpEvent, KeyEvent,
PaintEvent und MouseEvent. Von der Klasse Item sind die Items für die GUI
Elemente abgeleitet. Items können sich selbst nicht darstellen sondern sind
stets (änderbare) Bestandteile eines GUI Elements. Als Beispiel sei TableItem
genannt, das einen Bestandteil eines Table -Elements repräsentiert und ohne
eine Tabelle nicht dargestellt werden kann.
Die Widgets müssen natürlich auch innerhalb eines bestimmten Gerätekontextes dargestellt werden. Dies ist im allgemeinen der Anzeigekontext, der durch
die Klasse Display repräsentiert wird. Die Klasse Display ist von der Klasse
Device abgeleitet. Die Klasse Display ermöglicht das Auslesen der Systemkonfiguration bzgl. Anzahl Monitore, systemweite Schriftarten und Farben. Durch
den Aufruf von PlatformUI.createDisplay() kann eine Instanz von Display erzeugt werden. Diese kann dann mittels PlatformUI.getWorkbench().getDisplay
abgefragt werden.
3.3.3 SWT eigene Layoutmanager
Bereits mit AWT wurden Layoutmanager in Java eingeführt. Der Zweck ist,
dass einerseits auf eine absolute Positionierung der Komponenten verzichtet.
Andererseits soll die Berechnungen für eine relative Anordnung einzelner Komponenten nicht durch den Anwendungsporgrammierer erledigt werden. Damit
wird das Programmieren erleichtert und gleichzeitig werden Fehler vermieden.
Seitens SWT werden 5 Layoutmanager angeboten, die einzelnen Instanzen der
Composite Klasse mittels setLayout() zugewiesen werden können.
12. September 2006
20
3 Graphische Schnittstellen
• FillLayout Die enthalten Komponenten, auch child Elemente genannt,
fühlen das Composite Komplett aus. Die Höhe richtet sich nach dem
höchsten und die Breite nach dem breitesten Child Element, so dass alle
Child Element die gleiche Höre und Breite haben. Ein automatischer
Umbruch erfolgt nicht. Eine Anordnung ist der Child Elemente ist sowohl
horizontal als auch vertikal möglich.
• RowLayout Alle Child Elemente werden in einer Reihe angeordnet, es
ist sowohl horizontale als auch vertikale Ausrichtung der Elemente möglich. Zusätzlich kann ein automatischer Umbruch ermöglicht werden. Die
Größe der Randbereiche und auch der Abstand der einzelnen Komponenten können separat festgelegt werden und bei Bedarf kann die Größe
eines jeden Child Elementes individuell eingestellt werden.
• GridLayout Das GridLayout kann als Tabelle aufgefaßt werden, in dem
die einzelnen Child Elemente angeordnet sind. Die einzelnen Elemente
werden von links nach recht zeilenweise eingefügt. Durch Benutzung von
GridData Instanzen kann die Anordnung sowie die Ausrichtung und Ausdehnung der entha¨ltenen Komponenten sehr Individuell gestalltet werden.
• FormLayout Das FormLayout ermöglicht die Position eines Child Elements in Abhängigkeit zu den Rändern und der anderen enthaltenen
Child Elemende des jeweiligen Composites zu spezifizieren. Die Konfiguration erfolgt dabei mittels Instanzen der Klassen FormAttachemant
und FormData.
• StackLayout Beim Stacklayout wird immer nur ein Child Element angezeigt. Die Größe der einzelnen Element richtet sich nach dem höchsten
und dem breitesten enthaltenen Kindelement. Um ein Element sichtbar
zu machen, d.h. es an die oberste Stelle des Stacklayouts zu bringen, wird
es der Variable topControl zugewiesen.
Da der Umgang mit den einzelnen Componenten und die Benutzung der Layoutmanagern bei Gestaltung von GUIs zeitaufwendig ist, wird empfohlen, visuelle Editoren zu benutzen. Diese bieten den Vorteil, dass ohne permanentes
Neuübesetzung der Anwendung experimentiert werden kann, um die beste Lösung für ein GUI zu finden. Unter [Ecl06] kann der frei verfügbare emphEclipse
12. September 2006
3.3 SWT
21
Visual Editor heruntergeladen werden.
3.3.4 Dialoge
SWT bietet mit der abstrakten Klasse Dialog eine Klasse an, von der eigene
native Dialoge abgeleitet werden können. Diese Variante hat aber den Nachteil,
dass zum Teil noch recht viel Arbeit bei der Anpassung an die eigenen Anforderung erfolgen muss. Es wird daher empfohlen, die Möglchkeiten von JFace
zu nutzen. Allerdings stellt SWT bereits einige sehr oft benötigte Dialoge zu
Verfügung.
• DirectoryDialog Dieser kann genutzt werden um Verzeichnisse auszuwählen.
• FileDialog Zur Dateiauswahl beim Laden oder Speichern wird dieser
Dialog benutzt. Wird die Stilkonstante SWT.OPEN benutzt, wird die
Datei gelesen, bei Benutzung von SWT.SAVE gespeichert.
• MessageBox Wird für alle Arten von Meldungen benutzt. Mittels zugehöriger Stilkonstanten können sowohl die zu benutzenden Knöpfe als
auch das darzustellende Icon festgelegt werden.
• FontDialog wird benutzt um Schriftart und Größe auszuwählen
• PrintDialog Dient zur Einrichtung und Auswahl eines im System verfügbaren Druckers
3.3.5 Nebenläufigkeit von Oberflächenkomponenten
Bei der Programmierung von Oberflächen ist darauf zu achten, dass ressourcenintensive oder langlaufende Programmteile nicht im selben Thread wie SWT
laufen. Das würde dazu führen, das SWT scheinbar stillsteht und keine Benutzerinteraktion mehr möglich wäre. Auch das Benutzen von Fortschrittsanzeigen
( durch die Klasse ProgressBar ) wäre unmöglich. Daher müssen entsprechende
Programmteile in einen seperaten Thread ausgelagert werden. Wie dies geht,
und was dabei im allgemeinen zu beachten ist, kann in [Mid03] nachgelesen
werden. Die Schwierigkeit besteht darin, dass SWT keine Zugriffe aus nebenläufigen Threads erlaubt. Dies kann dann jedoch über die Zugriffsdelegation
12. September 2006
22
3 Graphische Schnittstellen
an die zugehörige Display Instanz erfolgen. Sie stellt dazu die Methoden timerExec(), asynchExec und synchExec zu Verfügung. Alternativ können Funktionanlitäten von JFace benutzt werden.
3.3.6 Integration von AWT/Swing Komponenten
Bisherige CANDY Tools setzen, wenn sie in Java programmiert wurden, sehr
oft auf AWT und Swing auf. Sollen diese auf RCP Basis weiterentwickelt werden, ist es unerläßlich den Aufwand zur Neuprogrammierung zu minimieren.
Dazu ist es sinnvoll, die bereits entwickelten Nutzerinterfaces anzupassen, anstatt sie komplett neu zu programmieren. SWT stellt für die Migration von
AWT/Swing das Package org.eclipse.swt.awt zur Verfügung. Für Windows
funktioniert das ab JRE 1.3, für andere Systeme ist die JRE 1.5 erforderlich.
Die Erzeugung einer geeigneten AWT/Swing Umgebung erfolgt durch anlegen
eines Composites, der als Container dient. Im Konstruktor des Composites
wird die Stilkonstante SWT.EMBEDDED angegeben. Dieser Container darf
keine SWT Komponenten enthalten bzw. aufnehmen. Eine neues AWT Frame
wird danach mittels SWT_AWT.new_Frame() erzeugt.
Es ist ebenso möglich, SWT Komponenten in AWT/Swing zu integrieren. Dazu
wird mittels der SWT_AWT Methode new_Shell() in einem gegebenen AWT
Container eine SWT Shell angelegt, die dann SWT Komponenten aufnimmt.
Ereignisse bei gemischten AWT/Swing und SWT Umgebungen
Sowohl AWT/Swing komponenten als auch SWT Komponenten verfügen über
auf sie zugeschnittene Listener. Da AWT/Swing und SWT aber in verschiedenen Threads laufen, ist ein Zugriff von AWT Listenern auf SWT Komponenten nur durch Delegation an eine Display Instanz möglich. Der Zugriff von
SWT Listenern auf AWT/Swing Komponenten soll in ein Runnable gekapselt
werden und wird dann mittels der AWT Methode EventQueue.invokeLater()
ermöglicht.
12. September 2006
3.4 JFace
23
3.4 JFace
JFace ist ein Plugin der Eclipse Standard Binärdistribution und setzt auf SWT
auf. Es erweitert die Möglichkeiten der SWT dadurch, dass es komplexere GUI
Komponenten zur Verfügung stellt. Zu den komplexeren GUI Komponenten
zählen Dialoge, Aktionen, Wizards und auch Viewer. Wesentlich erweitert sind
auch die Möglichkeiten, Systemressourcen zu nutzen.
3.4.1 Unterstützung für Ressourcen
Als Ressourcen werden Schriften, Farben und Bilder verstanden. Diese können
durch Methoden von JFace ausgelesen und manipuliert werden. Ressourcen
werden mittels sogenannter Registries verwaltet.
Bilder
Für die Verwaltung von Bildern ist die Klasse ImageRegistry zuständig. Diese
Bilder sind geräateabhängige Instanzen der Image Klasse. Die Registrierung
erfolgt mittels der Methode put. Dabei wird dem Bild ein symbolischer Name zugeordnet. Dieser kann mit get() abgefragt werden. Die Image Instanzen
dürfen nicht mit dispose() freigegeben werden, dies erledigt die ImageRegistry.
Statt mittels Image kann auch eine ImageDescriptor Instanz der Registry zugeordnet werden. Ein ImageDescriptor enthält statt des Bildes nur die Informationen wo das Bild zu finden ist und was für ein Typ von Bild es ist (z.B.
.jpeg oder .ico). Erst wenn es mittels get() tatsächlich angefordert wird, wird
es tatsächlich geladen.
Farben
Ähnlich wie bei Bildern erfolgt die Verwaltung von Farben mittels einer Registry. Dabei wird die Verwaltung der Farben von der ColorRegisty übernommen.
Die Farben werden als geräteunabhängige RGB-Instanzen unter einem symbolischen Namen abgelegt. Dies geschieht durch Aufruf der Methode put. Durch
Aufruf der Methode get() wird dann eine geräteabhängige Color Instanz für
12. September 2006
24
3 Graphische Schnittstellen
das entsprechende Display zurückgegeben. Auch hier darf die Ressource nicht
mittels freigegeben werden, die Registry erledigt die Freigabe.
Durch die Klasse JFaceColors wird es ermöglicht, Zugriff auf die Farben von
JFace zu bekommen, etwa um die Farben von Umrahmungen, Fehlermeldungen
und Hyperlinks zu verändern.
Schriften
Auch hier erfolgt die Verwaltung mittels einer Registry. Die Klasse FontRegistry verwaltet die Schriftarten innerhalb einer Applikation. Unter einem symbolischen Namen werden dabei die geräteunabhängigen Schriften verwaltet.
Die Einträge in die Regsitry sind dabei Instanzen der Klasse FontData. Das
Eintragen in die Registry erfolgt wieder mit put(), das Abfragen erfolgt mittels
der get() Methode. Wie bei den vorgenannten Ressourcen dürfen auch Schrift
Ressourcen nicht mittels dispose() freigegeben werden, da dies ausschließlich
durch die Registry geschieht.
3.4.2 Fenster und Dialoge
Für die Gestaltung von Fenstern und Dialogen wird das Package org.eclipse.
jface.dialogs zur Verfügung gestellt. Als wesentliches Element ist die abstrakte
Klasse Window einzuordnen, da von ihr alle Klassen dieses Packages abgeleitet
sind.
Die abstrakte Window Klasse
Als Grundlage für die Implementierung eigener Fenster ist sie bereits mit den
wichtigsten Methoden ausgestattet. Dazu zählen create(), open() und close().
Nach dem Anlegen einer neuen Fensterinstanz mittels new können auf die vorgenannten Methoden zugegriffen werden. Dabei soll create() vor open() ausgeführt werden. Durch create() werden die Methoden createContents() und
initializeBounds() aufgerufen um den Fensterinhalt zu erzeugen. Diese Methoden können entsprechend erweitert oder überschrieben werden. Wird open()
12. September 2006
3.4 JFace
25
aufgerufen, bevor ein create() aufgerufen wurde, so ruft open() die Methode
create() auf.
Ist es notwendig den Zustand eines Fensters in Erfahrung zu bringen, so wird
die Methode getReturnCode() benutzt. Diese liefert Window.Ok für ein geöffnetes Fenster und Window.CANCEL für ein geschlossenes Fenster zurück. Bei Erzeugung eigener Fenster muß durch Aufruf der Methode setBlockOnOpen(true)
das Fenster modifiziert werden. Nur dadurch ist sichergestellt, das es nach einem Aufruf von open() offen und damit benutzbar bleibt.
Die Klasse Dialog
Die Klasse Dialog ist direkt von der Klasse Window abgeleitet. Damit ein
Dialogfenster über Inhalt verfügt werden die Methoden createDialogArea()
und createButtonbar() bzw. createButtonsForButtonBar() überschrieben. In
der Voreinstellung sind ein Cancel und ein Ok Button Bestandteil eines Dialogs. Durch Aufruf der Methode createButton() ist es möglich, eigene Tasten
und ihre Ereignisverarbeitung zu erzeugen. Es gilt zu beachten, dass der Rückkehrcode in der open() Methode zurückgeliefert wird. Dieser kann aber auch
mittels getReturnCode() abgefragt werden. Bei einem nichtmodifiziertem Dialog sind die möglichen Rückgabewerte Window.CANCEL für einen Abbruch
und Window.OK nach Benutzung. Besteht die Notwendigkeit, Dialoge persistent zu speichern, kann das durch Instanzen der Klasse IDialogSettings erfolgen.
Spezielle Dialogklassen
InputDialog Mittels der InputDialog Klasse können einfache Eingabe Dialoge
erzeugt werden. Sie bestehen aus einem OK und Cancel Button und einem
Eingabfeld bestehen.
MessageDialog Die Klasse MessageDialog kann für Meldungen benutzt werden. Sie bietet im Vergleich zur Klasse MessageBox mehr Möglichkeiten, den
Inhalt und das Aussehen des Dialoges zu beeinflussen.
ProgressMonitorDialog Ein ProgressMonitorDialog ermöglicht die Darstellung von Dialogen mit Fortschrittsbalken. Es werden Methoden zur Verfügung
12. September 2006
26
3 Graphische Schnittstellen
gestellt, die sicherstellen, dass die beobachtete Aktivität und GUI sich wechselseitig nicht behindern.
TitleAreaDialog Diese Klasse ist eine Basisklasse zur Erzeugung eigener
komplexer Dialoge und ermöglicht, Dialoge vollständig nach eigenen Vostellung zu programmieren.
3.4.3 Einsatz von Viewer
Viewer dienen zur Dartstellung von Daten. Dazu implementieren sie das ModelViewer-Controller Entwurfsmuster, eine Ausprägung des Observer bzw. Beobachter Musters. Durch Trennung zwischen den den Daten und der Darstellung
von Daten ist es möglich auf bestimmte Daten verschiedene Präsentationen
zu implementieren. Die Viewer stellen dabei nicht nur die Daten dar, sie stellen auch Methoden zur Verfügung, dass bei Änderung von Daten alle anderen
möglichen Viewer von der Änderung unterrichtet werden und ihrerseits die
Darstellung der Daten aktualisieren.
Die Klasse Viewer dient als Ausgang für SWT Komponenten Viewer und zur
Erstellung eigener Viewer. Die SWT eigenen Viewer unterstützen SWT Komponenten und bieten zusätzlich untersützung für die Ansicht von Textdateien.
Dieser kann für die Darstellung von XML Dateien modifiziert werden.
Ein weiterer Vorteil der Viewer ist die Unterstützung von Drag&Drop, so dass
der Transfermechanismus nur noch an die Datenebene angepasst werden muß.
3.4.4 Menüs
In JFace sind Menüs nur eine spezielle Repräsentation von Aktionen. Eine
weitere Möglichkeit, in JFace Aktionen graphisch zu repräsentieren, wäre die
Anzeige als Werkzeug-Icon. Eigene Aktionen können von der abstrakten Action
abgeleitet werden. Als Eigenschaften können Ids, verschiedene Beschreibungen
und auch die verschiedenen Zustände {enabled, disabled, hover } gespeichert
und ausgelesen werden. Wesentlich ist die run Methode, mit der die auszuführendene Programmteile erst gestartet werden.
12. September 2006
3.4 JFace
27
Die Darstellung der einzelnen Aktionen erfolgt durch Instanzen der von IContributionManager abgeleiteten Klassen. Dazu zählen die Klassen IToolBarManager, ICoolBarManager und speziell für Menüs die Klasse IMenuManager.
Diese Klassen bieten dann Methoden, die Darstellung der Aktionen zu modifizieren.
Zu den vom IContributionManager abgeleiteten Klassen zählt auch die Klasse
StatusLineManager. Dieser ermöglicht die Darstellungen von Informationen
auf der Statusleiste. Die Klasse unterstützt Meldungen, Fehlermeldungen und
auch die Darstellung von Fortschrittsbalken.
3.4.5 Weitere Komponenten zur Nutzerinteraktion
Bei Präferenzen handelt es sich im wesentlichen um Einstellungsmöglichkeiten,
die es erlauben, das der Endnutzer die RCP-Anwendung nach seinen Vorstellungen einrichten kann. Diese müssen na¨türlich über eine Voreinstellung verfügen. Hat der Endnutzer von den Voreinstellungen abweichende Einstellungen
vorgenommen, so müssen diese persistent gespeichert und bei Bedarf ausgelesen werden. Diese Prozesse werden durch das JFACE Framework unterstützt.
Die Auswertung bleibt natürlich der Programmlogik vorbehalten.
Die Klasse PreferenceStore ist die Standardimplementierung der Interfaces
IPreferenceStore und IPersistentPreferenceStore. Mit den den Methode save()
und load() kann auf die persistent gespeicherten Daten zugegriffen werden. Es
werden nur einfache Datentypen (long,int,double,float, boolean) sowie String
unterstützt. Zusätzlich ist es möglich, durch Benutzung der Klasse PreferenceConverter auch Objekttypen im PreferenceStore abzuspeichern, wobei die Objekttypen dann als intern als String dargestellt werden. Die Erzeugung von
Dialogen, in denen die Preferenzen eingestellt werden können, wird durch die
abstrakte Klasse PreferencePage unterstützt.
Ein weiteres durch JFACE unterstützes GUI Element sind Wizards. Ein Wizard ist eine Folge von zusammengehörigen Dialogen, die es dem Nutzer ermöglichen soll, schrittweise Einstellungen und Arbeitsschritte vorzunehmen.
Ein Wizard kann beispielsweise benutzt werden, um beim Anlegen eines neuen
Projektes den Nutzer zu unterstützen. Durch sinnvolle Aufteilung der Einstellmöglichkeiten ist dem Nutzer ein einfaches Einarbeiten zu ermöglichen.
12. September 2006
28
3 Graphische Schnittstellen
Wizards müssen IWizard, ein Interface, implementieren, oder von der Klasse
Wizard abgeleitet werden. Die eigentliche Darstellung erfolgt dann durch die
Klasse WizardDialog. Sie stellt alle dann alle Seiten eines Wizards dar. Die
Seiten, die das Interface IWizardPage implementieren oder von WizardPage
abgeleitet sind, enthalten dann die Komponenten, die zur Einstellung notwendig sind.
Soll dem Nutzer die Auswahl eines Wizards aus mehreren Wizards ermöglicht
werden, kann die Klasse WizardSelectionPage benutzt werden. Da auch sie
IWizardPage implementiert, kann sie wie alle anderen Wizards ohne klassenspezifische Besonderheiten beachten zu müssen, in eigene Programme integriert
werden.
3.5 GEF
Das Graphical Editor Framework (GEF) ist nicht Bestandteil der Standard
RCP Distribution sondern ein seperates Plugin. Es steht unter [Geo06] zum
freien Download zur Verfügung und kann in eigene Anwendungen integriert
werden. Bei der Auslieferung von Anwendungen muss es also ebenfalls mitgeliefert werden, wenn Anwendungen auf Funktionalitäten des GEFs aufsetzen.
GEF ist ursprünglich konzipiert, um ein Framework für Entwicklungswerkzeuge wie UML Editoren zu schaffen. Eine weitere Anwendung, die auf GEF
basiert, ist der Visual Editor, der unter [Eco06] zum Download zur Verfügung
steht. Dieser Editor kann zur Gestaltung von SWT und JFace Oberflächen
benutzt werden.
Das GEF setzt auf Draw2D auf. Draw2D realisiert einen den leichtgewichtigen
Aufbau über SWT. Dass hat den Vorteil, das direkt mit graphischen Objekten
wie Rechteck, Thumbnail oder Panel gearbeitet werden, anstatt mit Gerätekontexten oder deren Listenern agieren zu müssen. Dabei baut GEF bei der
Implementierung auf das Modell-View-Controller Entwurfsmuster auf. GEF
stellt dabei die Controller und Viewer zur Verfügung. Das Modell ist durch
die jeweiligen Anwendung zu implementieren. Alle grafischen Objekte sind
von der Klasse Figure abgeleitet. Die Klasse Figure selbst implementiert das
Interface IFigure. Durch Figure sind bereits grundlegende Mechanismen zur
12. September 2006
3.5 GEF
29
Ereignisverarbeitung wie Tastaturer-, Maus- und PropertyChange Ereignise
implementiert, die dann an das Modell der Anwendung angepaßt werden.
Die Grafikobjekte werden mittels einer add() Operation einem Behälter (Container ) hinzugefügt und durch ein remove() aus einem Behälter wieder entfernt. Es ist dadurch leicht möglich, nichtanonym implementierte Grafikobjekte
von einem Behälter in einen anderen Behälter zu verschieben.
3.5.1 Weitere Eigenschaften GEF
Die Leistungsfähigkeit des GEF beschränkt sich natürlich nicht auf das Darstellen primitiver Elemente, sondern ermöglicht durch Intergration verschiedener
GUI Elemente die Abdeckung eines breiten Aufgabenspektrums.
Datenmodellunabhängigkeit Durch die Implementierung des MVC- Entwurfsmuster kann GEF beliebige Datenmodelle grafisch darstellen.
Multilayer Support Dadurch ist es möglich, verschiedene Ebenen voneinander unabhänigig darzustellen, zu bearbeiten oder sich überschneiden zu
lassen
Werkzeugpalletten Werden durch frei positionierbare Iconleisten repräsentiert. Damit kann eine aufgabenspezifische Vorauswahl an Aktionen getroffen werden, die mögliche Fehlbedienungen reduziert.
Verbindungslinienunterstützung durch automatischen Routing und einfache Konfiguration von Anfangs/End Punkten
Zoomunterstüzung Erleichtert die Übersichtlichkeit und ermöglicht detailierte Darstellungen
Lineale/ Hilfslinien können genutzt werden, wenn es auf maßstabsgenaue
Darstellung z.B. von Gebaäude/-teilen ankommt
Raster/ Einrastpunkte helfen bei genauer Positionierung
Drag&Drop, Copy&Paste diese Standardaktionen beim Bearbeiten werden
unterstützt
Druckausgabe Aus den Daten des Modells können leicht Grafiken zum
Drucken generiert werden.
12. September 2006
30
3 Graphische Schnittstellen
Zwar können mittels GEF beliebige Datenmodelle dargestellt werden, jedoch
beschränken sich diese Graphiken auf die Menge der Polygone, Ellipsen und
Bilder. Gegenwärtig existiert keine Unterstützung für Kurven, wie Bezierkurven. Ebenfalls wird Antialiasing nicht unterstützt, so dass die Graphiken nicht
immer den ästethischen Erwartungen des Nutzers gerecht werden könnten. Gerade bei Linien(-zügen) sind bei bestimmten Steigungen einzelne horizontale/
vertikale Teillinien zu erkennen.
Derzeit ist auch die Dokumentation eine Schwachstelle von GEF. Im Vergleich
zu Java SDK Dokumentation und Java Tutorials ist sie als zu schlecht zu
betrachten. Dies führt zu einer entsprechend steilen Lernkurve. Es gibt allerdings eine immer größer werdende Anzahl von Open Source Anwendungen,
die auf GEF basieren. In diesen Anwendung können dann Anregungen für den
Umgang mit einzelnen GEF Komponenten gefunden werden.
3.6 Vergleich
Bei diesem Vergleich ist es das Ziel, herauszufinden, welche Graphikschnittstelle(n) für weitere CANDY Projekte geeignet ist(sind). Es wird unterstellt,
das zukünftige Anwendungen als RCP Anwendungen erstellt werden, da diese
durch die Plugin Architektur leicht erweiterbar sind. Daraus ergibt sich, dass
keine Java Applets erstellt werden können und das Kriterium der Browserkompatibilität nicht betrachtet wird. Alle RCP Anwendungen können sowohl auf
die Java eigenen GUIs AWT/Swing als auch auf SWT/JFace zurückgreifen.
Der Vorteil von AWT und Swing liegt darin, dass eine Anwendung auf jedem
durch die JRE unterstützten System läuft. Dabei ist AWT jedoch recht beschränkt in der Anzahl der GUI Elemente, was einen sehr hohen Zeitaufwand
für die Implementierung komplexer GUI Elemente erfordert. Swing erweitert
die Menge der verfügbaren GUI Elemente und unterstützt für viele dieser GUI
Elemente Drag&Drop Funktionen. Swing besitzt aber den Nachteil, dass es
auf älteren und nicht leistungsfähigen Endgeräten (Bsp. Laptops) nicht performant genug ist. Nutzer von Swing Programmen könnten dieses behäbige
Verhalten als störend empfinden.
SWT/JFace bietet den Vorteil dass es über eine Vielzahl von graphischen Ele-
12. September 2006
3.6 Vergleich
31
menten verfügt, aus denen der Programmierer anhand seiner Vorstellungen
auswählen kann. Da SWT/JFace plattformspezifisch implementiert ist, muss
für jede zu unterstützende Plattform ein entsprechendes Paket zusammengestellt werden. Bei der Auslieferung eines fertigen CANDY Bausteins müssen
dann für die verschiedenen Zielplattformen in mehreren Build Prozessen die
Installationspakete erstellt werden. Der Vorteil ist dafür ein wesentlich performanteres Verhalten als bei Swing.
GEF bietet den Vorteil das es sehr viele graphische Operationen abstrahiert
und somit die Entwicklung graphischer Editoren wesentlich vereinfacht. Bei
der Planung von Software Projekten ist jedoch der Einarbeitungsaufwand zu
berücksichtigen. Da GEF auf SWT zurückgreift, ist eine Kooperation mit
AWT/Swing nur eingeschränkt möglich.
Es stehen sowohl für AWT/Swing als auch für SWT/JFace graphische Editoren zu Verfügung, die den Einstieg und den Umgang mit entsprechenden
Oberflächen erleichtern. Drag&Drop wird von beiden GUIs unterstützt, Unterschiede liegen in den Implementierungsdetails. Es wird empfohlen, für weitere
CANDY Tools auf SWT aufzusetzen, da es performanter ist und insbesonder
durch JFace über wesentlich mehr Elemente verfügt. Bei der Portierung auf
verschiedene Platformen ist bei SWT Benutzung ein Anpassungsaufwand zu
berücksichtigen. Da zu erwarten ist, das viele Editoren graphische Darstellungen benutzen wird ebenfalls empfohlen GEF in CANDY einzuführen. Als
Anregung für weitere Belegthemen sei GEF empfohlen, insbesondere um den
Einarbeitungsaufwand zu reduzieren.
12. September 2006
32
3 Graphische Schnittstellen
12. September 2006
4 Beschreibungssprachen für
CANDY Dokumente
Für die Entwicklung eines Tools zur Verwaltung von Pojekten ist es notwendig,
die durch den Nutzer eingegebenen Daten oder Ergebnisse aus Berechnungen
eines Tools persistent zu speichern. Es stehen dabei mehrere Lösungsansätze
zur Verfügung. Es wird davon ausgegangen, dass die persistente lokale Speicherung innerhalb einer Datei erfolgt.
1 Speicherung als Byte Folge, die beim Speichern erzeugt wird. Die Daten werden dazu durch das Programm transformiert. Der Programmierer
muss dazu geeignete Kodierungsmechanismen entwickeln.
2 Speicherung durch Methoden der JRE direkt aus dem Objekt-Stream.
Der Programmierer muss hierzu seine Klassen entsprechend anpassen.
3 Speicherung als Klartextdatei. Auch hier muss der Programmierer geeignete Kodierungsmechanismen implementieren, insbesondere müssen
geeignete Parser entwickelt werden.
4 Speicherung als XML Datei. Der Programmierer muss hierbei die entsprechenden Interfaces in seine Klassen implementieren.
Der Lösungsansatz 2 ist ein Spezialfall des Löungsansatzes 1. Der Unterschied
besteht darin, dass sich der Programmierer bei 2 die Transformation zwischen
den Daten der Anwendung und den Daten in der Datei durch die JRE sicherstellt. Für beide Lösungsansätze gilt, dass die erzeugten Dateien nur maschinenlesbar sind.
34
4 Beschreibungssprachen für CANDY Dokumente
Die Lösungsansätze 3 und 4 sind dagegen nicht nur maschinenlesbar, sondern
können, bei entsprechender Kodierung, direkt durch Menschen gelesen werden. Es ist darüber hinaus zu erwarten, das die Portabilität höher ist als bei
den Lösungsansätzen 1 und 2. Die liegt darin begründet, dass Zahlen als Zeichenkette abgespeichert werden und das Problem bzgl. Big Endian und Little
Endian nicht auftreten kann. Der Lösungsansatz 4 ist ein Spezialfall des Lösungsansatzes 3. Dies ermöglicht, dass XML basierende Dateien eine Struktur
haben, die einfaches Parsen ermöglichen. Dies wird durch die Java Klassen
javax.xml.parsers.SAXParser und javax.xml.parsers.DocumentBuilder unterstützt. Weitere Details können [Mid03] entnommen werden.
Im Rahmen des CANDY Projektes wurden bisher zur persistenten Speicherung
von Daten XML Dokumente benutzt. Für die Benutzung von XML gibt es
folgende Argumente:
Ausgereiftheit : XML ist ein seit mehreren Jahren etablierter Standart für
Dokumente. Es ist daher davon auszugehen dass zukünftige Entwicklungen für Dokumentenverwaltung Kompatible zu XML sind oder geeignete
Transformationsmöglichkeiten geschaffen werden.
Unterstüzung : XML wird durch JRE Javaklassen unterstützt. Dabei wird
beim Parsen eines Dokumentes geprüft ob es wohlgeformt ist, damit reduziert sich der Entwcklungsaufwand
Portabilität : Da XML auf Textdateien aufbaut und dabei auf Unicode UTF8 benutzt, ist eine hohe Portabilität zu erwarten
Editierbarkeit : Aufgrund der UTF-8 Kodierung können XML Dokumente
mit Standardeditoren angesehen und verändert werden
Trennung Inhalt und Form : XML Dokumente beschreiben ausschließlich
was für Elemente dargestellt werden. Wie die Elemente dargestellt werden kann dann durch ein Stylesheet (XSL) beschrieben werden. Dies
ermöglicht, dass Dokumente automatisiert verarbeitet werden können.
Diesen Vorteilen stehen jedoch einige Nachteile gegenüber. Um die Korrektheit eines XML Dokumentes zu prüfen, muss zusätzlich die DTD (Dokumentyp
Definition) verfügbar sein. Daher müssen unter Umständen wesentlich mehr
Dokumente zur Verfügung gestellt werden, als für den Informationsaustausch
12. September 2006
4.1 XML
35
notwendig sind. Ebenfalls müssen mehr Dokumente gewartet werden und neben XML muss auch noch mit einer einer Sprache für die DTD umgegangen
werden. Der Vorteil der leichten Editierbarkeit ist ein Nachteil, wenn sichergestellt werden soll, dass ein Dokument unverändert ist. Bei Abwägung aller
Vor- und Nachteile ist XML dennoch geeignet, da eine DTD relativ stabil ist.
Die Mehraufwand für den Transfer der DTD läßt sich durch automatischen
Abgleich reduzieren. Das Problem der Authentizität ist kein XML spezifisches
Problem, es besteht auch bei den anderen eingangs erwähnten Lösungsansätzen. Da XML bereits für CANDY benutzt wird, ist eine einfachere Migration
zu erwarten, wenn auch die Projektverwaltung auf XML aufsetzt.
4.1 XML
XML ist eine Sprache zur digitalen Abbildung von Daten. Sie ist eine Teilmenge
der SGML. Ziel der XML Entwicklung war dabei, eine Beschreibungssprache zu
schaffen, die einfacher aufgebaut ist als SGML. Damit können Parser einfacher
entwickelt werden und die XML Dokumente sind kompakter. Parser sind so
gestaltet, dass sie nur mit wohlgeformten XML Dateien umgehen können. Sie
sind nicht in der Lage Fehler zu korrigieren. Damit wird sichergestellt, dass
nicht wohlgeformte Dokumente verworfen werden.
4.1.1 Begriffsbstimmung
Zunächst werden die Begriffe definiert, die für den Umgang von XML im Rahmen dieser Arbeit notwendig sind. Für diese Defnitionen wurde im wesentlichen
auf [Gol00] zurückgegriffen. Die Darstellung ist auf das für den Anwendungsfall erforderliche Minimum reduziert. Für weitergehende Aufgabenstellung sei
auf die vorgenannte Quelle verwiesen.
Dokument Ein XML Dokument besteht aus einem Prolog zu Beginn des Dokuments gefolgt von einem Wurzelelement. Diese Wurzelelement beinhaltet alle andere Elemente des Dokuments.
Prolog Der Prolog beschreibt, um was für eine Art von Dokument es sich
handelt. Dabei kennzeichnet die erste Zeile des Dokuments die benutzte
12. September 2006
36
4 Beschreibungssprachen für CANDY Dokumente
XML Version. Beispiel :
<?xml version =“1.0“?>
Danach kann optional die Angabe einer DTD erfolgen, auf der das Dokument basiert
<!DOCTYPE WURZELELEMENT SYSTEM “beispiel.dtd“>
Element In einem Element wird die eigentliche Information gespeichert. Es
besteht aus drei Teilen, einem einleitenden Tag, dem Inhalt, und einem
schließenden Tag. Das schließende Tag muss dem einleitenden Tag entsprechen, zusätzlich wird ein ‘/ ‘vorangestellt
<tag>Inhalt</tag>.
Eine Besonderheit besteht bei leeren Elementen. Sie können sowohl durch
Weglassen des Inhalts dargestellt werden als auch in der Form
<tag />
Tag Ein Tag ist der Elementtyp-Name und wird benutzt um den Anfang und
das Ende eines Elements zu kennzeichnen. Beispiel siehe Element.
Attribut Attribute werden benutzt, um weitere Eigenschaften und Informationen einem Element hinzufügen. Es verfügt über einen eigenen Attributnamen und wird im einleitenden Tag angeben. Der Wert des Attributes wird in ‘ “ ‘angeben und durch ein ‘=‘vom Attributnamen getrennt.
Beispiel:
<tag attributname=“1“ attributname2=“Ein Textattribut“>Inhalt</tag>
bei einem leeren Element
<tag attributname=“1“ attributname2=“Ein Textattribut“/>
Inhalt Als Inhalt eines Elements können sowohl Literale als auch weitere Elemente vorkommen. Dies ist Abhängig von der benutzten DTD
Wohlgeformtheit Wohlgeformtheit bedeutet, dass ein XML Dokument über
einen einen Prolog verfügt, und alle einleitenden Tags über ein schließendes Tag verfügen. Es sind also nur Dateien wohlgeformt, die über die
Struktur verfügen, wie unter Dokument angegeben
Korrektheit Als “Korrekt“ oder “Gültig“ wird ein Dokument bezeichnet, wenn
es den durch die angebene DTD definierten Regeln entspricht. Ist keine
DTD angegeben, kann keine Aussage zur Korrektheit gemacht werden.
Es obliegt dem Programmierer, einen im Anwendungskontext sinnvollen
12. September 2006
4.2 NDML
37
Umgang mit solchen Dokumenten sicherzustellen
Parser Ein Parser hat die Aufgabe, ein XML Dokument einzulesen und dabei
die Wohlgeformtheit zu überprüfen Es gibt dafür 2 etablieterte Ansätze
DOM Das Document Object Modell (DOM) API parst das gesamte Dokument und liefert als Ergbnis einen Baum zurück. Eine Arbeit auf
diesem Baum ist entsprechend leicht möglich. Probleme treten jedoch bei sehr großen Dokumenten auf, da das Einlesen des kompletten Baumes recht lange dauert und entsprechend viele Ressourcen
benötigt.
SAX Das Simple API for XML (SAX) ist ereignisbasierend. Dabei wird
beim Parsen des XML Dokuments nicht der komplette Baum eingelesen, sondern es wird während des Parsens der Anwendung mitgeteilt, wo sich der Parser befindet, beispielweise bei Beginn oder
Ende eines Elements. Der Vorteil liegt in der wesentlich höheren
Effizienz, hat aber den Nachteil, das es aufwändig ist, angepasste
Methoden für die Ereignissverarbeitung zu schreiben
Es gibt darüber hinaus noch validierende Parser, die prüfen, ob das Dokument bezüglich der angegebenen DTD korrekt ist.
DTD Eine DTD enthält Informationen wie ein XML Dokument aufgebaut
sein muss, damit es syntaktisch korrekt ist. Dabei kann die DTD als Block
innerhalb des XML Dokuments enthalten sein, oder in einem separaten
Dokument enthalten sein. Dieses separate Dokument muss dann in der
XML Datei referenziert werden.
4.2 NDML
NDML ist umschreibt eine Menge von Spracheelementen, die in CANDY Tools
benutzt werden. Sie ist toolsspezifisch und wird im Rahmen der einzelnen Tools
ausführlich diskutiert. Innerhalb dieser Arbeit wird nicht separat untersucht,
da sie eine Teilmenge von XML bildet. Sämtliche Klassen und Methoden die für
den Umgang mit XML Dateien entwickelt und benutzt werden müssen dann
nur den toolspezifischen Besonderheiten angepaßt werden. Entsprechende Bei-
12. September 2006
38
4 Beschreibungssprachen für CANDY Dokumente
spielimplementierung sind im Paket de.tudresden.inf.rn.candy.tools.sampleTool
zu finden.
12. September 2006
5 Implementierung der
Anwendung
Dieses Kapitel beschreibt den Prozeß der Erstellng der eigentlichen Anwendung. Diese Beschreibung soll den Einstieg und den Umgang mit der Eclipse
RCP erleichtern. Für die Umsetzung wird vorausgesetzt, das die Eclipse IDE
mit Version 3.1 oder höher vorhanden ist. Sie bietet entprechende Unterstützung bei der Erstellung von Plugins durch Templates und Manifest Editoren.
Es wird ebenfalls ein installierte Visual Editor vorrausgesetzt. Dieser ist als
Plugin unter [Eco06] verfügbar und wird einfach in den Eclipseordner mit hineinkopiert.
5.1 Allgemeine Anforderung
1 Zielbestimmung: Dieser Editor soll das Projektmanagement unterstützen. Dabei soll er als Referenzimplementierung für die Entwicklung weiterer CANDY Tools dienen, welche auf der RCP Architektur aufsetzen.
Der Editor soll durch Plugins erweiterbar sein.
2 Einsatz: Für den Editor sind mehrere Bereiche vorgesehen. Die Produktivversion ist zum Einsatz im Rahmen der Netzwerkprojektion vorgesehen. Eine Entwicklerversion ist dafür gedacht, um sie schrittweise zu
erweitern, Tests zur GUI Gestaltung durchzuführen und sie als Vorlage
für eigene RCP Anwendungen zu nutzen.
40
5 Implementierung der Anwendung
3 Funktionen: Diese Funktionen werden implementiert
3.a Views
3.b Wizards
3.c Editorfunktion
3.d Menubar, Toolbar, CoolBar
3.e Aktionen, Commandos, Keybindings
4 Ergänzungen: Wesentliches Merkmal ist die Nutzung der RCP Architektur und die Erweiterbarkeit durch Plugins. Dabei ist eine geeignete
Plugin Architektur zu wählen.
5.2 Eclipseterminologie
Der Inhalt dieses Kapitel umfaßt neben den Definitionen auch Hinweise mit
dem Umgang der einzelnen hier erläuterten Elemente der Eclipse Architektur.
Als Quellen dienten neben der Eclipse Dokumentation auch die Tutorials, die
jeweils unter [Eco06] zu finden sind und Bestandteil des Eclipse SDK sind.
Weiterhin wurde die Eclipse Wikipedia benutzt, die unter [Wik06] zu finden ist,
das Buch [Dau05] sowie die Quellen [Ecl02] - [Ecl07]. Für die Entwicklung sind
die Guidelines unter [Gui06] eine sehr gute Hilfe zur Gestaltung von homogenen
Nutzerinterfaces.
5.2.1 Workbench
Der Workbench (wörtl.: Arbeitstisch) ist eine Ansammlung von Fenstern, wobei
jedes Fenster ein Menü, eine Toolbar sowie eine oder mehrere Perspektiven
enthält. Eine Perspektive ist ein visueller Container für eine Menge von Views
und Editoren. Views und Editoren werden auch als Parts bezeichnet.
Dies Umsetzung geschieht in der Form, dass das IWorkbench Interface Zugriffe auf jedes einzelne Fenster ermöglicht. Jedes einzelene Fenster wird durch
IWorkbenchWindow repräsentiert. Ein IWorkbenchWindow referenziert Klassen, die IWorkbenchPage implementieren. Mittels IWorkbenchPage Methoden
12. September 2006
5.2 Eclipseterminologie
41
können dann Einstellungen zur Perspektive ermittelt werden. In den Perspektiven können dann Views und Editoren angelegt werden. Anschaulich kann
eine WorkbenchPage als Buch verstanden werden und die Perspektiven sind
die Seiten. Und wie ein Buch kann eine WorkbenchPage viele Seiten (bzw.
Perspektiven) haben, aber es kann immer nur eine angesehen werden.
5.2.2 Perspektive
Für das Konzept der Perspektiven gibt es zwei wesentliche Gründe. Der erste
Grund ist die Möglichkeit zur Informationfilterung. Der zweite Grund ist der,
dass ein aufgabenzentrierter Umgang mit den Informationen ermöglicht wird.
Zum Beipiel könnte eine Anwendung in Abhängigkeit von Logins unterschiedliche Perspektiven erzeugen. In der einen Perspektive wären die Informationen
veränderbar in einer weiteren nicht. In einer dritten würden Information nicht
dargestellt. So kann ohne aufwändige interne Prüfungen eine Rechteverwaltung
ermöglicht werden.
Entwicklung von Perspektiven
Das Anlegen einer Perspektive geht ab der Version Eclipse IDE Version 3.1
durch Auswahl der Datei plugins.xml. Es öffnet sich ein Editor, in dem
unter dem Reiter Extensions die Extension org.eclipse.ui.perspectives selektiert wird. Dann kann mit NEW -> Perspective eine neue Perspektive
hinzugefügt werden. Es ist nicht möglich Perspektiven durch Aufrufen
von API Funktionen zu erzeugen.
5.2.3 Parts
Innerhalb einer Perspektive können Parts angelegt werden. Parts können entweder Views oder Editoren sein.
Alle Editoren, welche mit der Workbench interagieren, leiten sich von der abstrakten Klasse EditorPart ab. Ist es notwendig, eigenen Editoren zu entwickeln muss dafür die Methode createPartControl() überschrieben werden.
In dieser Methode kann mittels JFace und SWT Komponenten nach eigenen
12. September 2006
42
5 Implementierung der Anwendung
Abbildung 5.1: Hauptelemente der Workbench, hier an einem Fenster dargestellt Quelle: [Gui06]
Anforderungen ein Editor gestaltet werden. Durch das Eclipse Framework werden verschiedene (textbasierte) Editoren zur Verfügung gestellt. Dazu zählen
AbstractTextEditor, StatusTextEditor, MultiEditor, MultiPageEditorPart und
FormEditor. Besteht die Notwendigkeit von graphischen Editoren und View,
wie sie beispielsweise für Diagramme benötigt werden, kann auf Editoren des
GEF zurückgegriffen werden.
Editoren verfügen darüber hinaus über Methoden, die zur persisten Speicherung der editierten Daten genutzt werden. Die Aufgaben der Methoden doSave(), doSaveAs() isSaveAsAllowed() und isSaveOnCloseNeeded sind dabei
selbsterklärend. Die Methode isDirty() zeigt an, ob der Inhalt des Editors
verändert wurde.
Views basieren auf der abstrakten Klasse ViewPart. Sie zeigen die Zustandsdaten des aktiven Editors an. Auch hier kann durch Überschreiben der Methode createPartControl ein View nach eigenen Anforderungen gestaltet werden.
Durch Überschreiben der Methode init() kann dann der neugestaltete View
12. September 2006
5.2 Eclipseterminologie
43
benutzt werden. Ein View kann nur durch einen entsprechenden XML Eintrag deklariert werden. Das Aussehen des Views wird dann durch die im XML
Eintrag referenzierte Klasse bestimmt. Weiterhin können Views eigene Werkzeugleisten und Drop Down Menüs zu besitzen. Der Zugriff erfolgt über die
Schnittstelle IViewSite. Durch den Aufruf der Methode getActionBars können
dann die Manager für die View eigenen Tool und Menübar ermittelt werden.
Es empfhielt sich bei der Gestaltung auf das Eclipse Plugin Visual Editor zugrückgreifen.
Wesentliche Unterschiede zwischen View und Editor
Editoren können nur an einer Stelle der WorkBenchPage erscheinen, an dieser Stelle jedoch ihre Größe anpassen. Views können an beliebiger Stelle der
WorkBenchPage dargestellt werden. Editoren können den dirty Status erreichen, d.h. ihr Inhalt ist ungesichert und ist beim Schließen ohne vorheriges
speichern verloren. Views können über eine lokale Toolbar verfügen wohingegen Editoren auf die globale Toolbar zugreifen können. Editoren können mit
Dateien verknüpft werden, so dass sie über Änderungen informiert werden und
den neuen Inhalt anzeigen können.
5.2.4 Aktionen, Kommandos
Aktionen beschreiben Möglichkeiten zur Nutzerinteraktion. Sie können als Eintrag in einem Menü, als Bestandteil einer Toolbar oder einer Coolbar (einer
vom Nutzer repositionierbarer Toolbar) in Erscheinung treten. Kommandos
werden benutzt, um eine Aktion an eine bestimmte Taste zu binden (sog.
KeyBindings) und um Aktionen zu verwalten. Kommandos können als der
deklarative Teil und Aktionen als der programmiertechnische Teil der Benutzerinteraktion aufgefaßt werden.
5.2.5 Pluginintegration
Bisher wurde der Begriff des Plugin benutzt, um eine Erweiterungsmöglichkeit
für ein Programm zu beschreiben. Bei der Implementierung ist es jedoch wichtig, zu welchem Zeitpunkt ein Plugin in eine Anwendung integriert wird. Die
12. September 2006
44
5 Implementierung der Anwendung
Einbindung des Plugins kann zum Zeitpunkt der Kompilierung erfolgen oder
zum Zeitpunkt des Programmaufrufs. Die Unterschiede müssen dann bei der
Implementierung berücksichtigt werden. Erfolgt die Einbindung zum Zeitpunkt
der Kompilierung wird die Entwicklung wesentlich vereinfacht, da keine Mechanismen zum Handling nachladbarer Plugins getroffen werden müssen. Die
Plugin Interfaces werden bereits bei der Kompilierungsphase darauf geprüft,
ob sie syntaktisch korrekt sind. Dem Vorteil der einfacheren Handhabung steht
der Nachteil gegenüber, dass alle Entwickler, welche die Anwendung erweitern
wollen, über den Quellcode verfügen müssen. Die RCP Architektur ermöglicht
es, sowohl Plugins separat zu entwickeln und nach der Kompilierung des Hauptprogramms mit nutzen können als auch Plugins mit dem Hauptprogramm zu
entwickeln.
Bei der Möglichkeit, ein Plugin mit dem Hauptprogramm zu entwickeln wird
ein bestehender Extension Point genutzt und eine Extension hinzugefügt. Auf
diese Extension kann durch andere Plugins nun mittels Platform.getExtensionRegistry() zugegriffen werden. Diese so erzeugten Plugins werden dann Bestandteil des Hauptprogrammes und in der plugin.xml mitregistriert.
Die zweite Möglichkeit besteht im Entwickeln separater Plugins. Der Unterschied zu der vorgenannten Methode ist der, dass diese Plugins ihre eigene
Plugin Beschreibung in Form der plugin.xml mitbringen müssen. Zusätzlich
muss noch sichergestellt werden, das neue Plugins bei dem Hauptprogramm
registriert werden müssen. Zum einen kann dies durch Verändern der config.ini
Datei des Hauptprogramms geschehen, zum anderen auch durch Nutzung des
Plugins org.eclipse.update.configurator
Bei der RCP Architektur stehen verschiedene Möglichkeiten von Plugins zu
Verfügung. Die Dynamik umschreibt dabei die Fähigkeit während des Betriebes einer Anwendung ein Plugin zu laden oder zu entladen.
Nondynamic/nichtdynamische Plugins waren bis Version 3.0 der Eclipse
RCP Architektur üblich. Das Entladen solcher Plugins kann zu Programminstabilitäten führen, da evtl. Plugin Funktionen aufgerufen werden, die nicht mehr zur Verfügung stehen. Ein weiteres Problem liegt
in der Nichtfreigabe von Ressourcen, welche durch derartige Plugin belegt werden. Auch der Garbage Collector der JRE hat keine Möglichkeit
zu erkennen, dass diese Ressourcen nicht mehr benötigt werden. Beim
12. September 2006
5.2 Eclipseterminologie
45
Laden eines solchen Plugins werden im allgemeinen die hinzugekommen
Funktionalitäten nicht erkannt.
Dynamic aware/Dynamik unterstützend:
Diese Plugins untersützen an-
dere dynamische Plugins indem sie darauf vorbereitet sind, auf das dynamische Hinzufügen oder Entfernen eines mit ihnen interagierenden Plugins zu reagieren. Sie selbst sind aber nicht dynamisch. Der WorkBench ist
ein Beispiel dafür. Er kann darauf reagieren, wenn Views und Editoren
dynamisch entfernt/ hinzugefügt werden. Er selbst kann nicht hinzugefügt/ entfernt werden.
Dynamic enabled/dynamisch:
Diese Plugins können dynamisch hinzuge-
fügt und entfernt werden, sind jedoch nicht in der Lage auf das Entfernen/ Hinzufügen von mit ihnen interagierenden Plugins zu reagieren.
Fullydynamic/volldynamisch:
Diese Plugins erfüllen die Anforderung von
Dynamik unterstützenden Plugins als auch die von dynamischen Plugins.
In den Dokumenten zum Plugin Design wird hervorgehoben, dass jedes
Plugin, soweit es konzeptionell sinnvoll ist, volldynamisch sein soll.
Beim Entwurf als auch bei der programmtechnischen Umsetzung von Plugins
muss abgewogen werden zwischen der Forderung nach Dynamik und einfacher
Realisierung. Für CANDY besteht derzeit die Forderung nach Dynamik nicht.
Da bei der Umsetzung auf bestimmte Designrichtlinien geachtet werden muss,
erhöht sich der Einarbeitungsaufwand. Es wird daher die Implementierung von
nichtdynamischen Plugins bevorzugt.
Die RCP Architektur ermöglicht beides, wie sich anhand der Eclipse IDE nachprüfen läßt. Für die Arbeit am CANDY Projekt ist davon auszugehen, dass
der Code für alle zur Verfügung steht, die daran arbeiten. Die Notwendigkeit,
zur Laufzeit erweiterbar zu sein ist derzeit nicht erkennbar.
Bei der Entwicklung dieser Anwendung wird auf die Plugin Mechanismen der
RCP aufgesetzt. Sie entsprechen dem OSGI Standard und werden durch Assistenten in der Eclipse IDE unterstüzt. Auch für Neueinsteiger ist das Anlegen eigener Plugins damit wesentlich erleichtert. Die Einbindung erfolgt dabei
zum Zeitpunkt der Kompilierung. Dies ist sinnvoll, da der Quellcode den Entwicklern zur Verfügung steht und die Gestaltung der Plugins sich wesentlich
vereinfacht.
12. September 2006
46
5 Implementierung der Anwendung
5.3 Implementierungsdetails
5.3.1 Workspace Konzept
Bei bisherigen Arbeiten und Tools stehen Dateien im Mittelpunkt. Ein neuer
Ansatz ist jedoch ein projektzentrierter Ansatz. Dabei werden alle zu einem
Projekt gehörenden Dateien in einer Ordnerhierarchie gespeichert. Die Verwaltung erfolgt nun jedoch nicht durch die einzelnen Tools sondern direkt durch
die RCP Anwendung.
Der Workspace abstrahiert den Dateizugriff vom Dateisystem, so dass sich
der Nutzer keine Gedanken machen muss, wie er innerhalb des jeweiligen Betriebsystem seine Dateien speichert. Mittels RCP wird einmal ein Verzeichnis
für den Workspace gewählt und entsprechendene Dateien (auch Ressourcen
genannt) werden dort angelegt.
Innerhalb des Workspaces können nun einzelne Projekte angelegt werden. Welche Dateien zu den Projekten gehören, wird für jedes Projekt in einer XML
Datei .project gespeichert. Weder Nutzer noch Entwickler kommen mit der
Datei in Kontakt, ein Zugriff erfolgt ausschließlich über das IWorkspace Interface. Wichtig ist dabei, das keine Klasse dieses Interface implementiert. Der
Workspace kann mittels
IWorkspace workspace=ResourcesPlugin.getWorkspace()
ermittel werden.
5.3.2 Erstellen einer RCP Anwendung
Beim Erstellen einer eigenen RCP Anwendung empfiehlt es sich, die ersten
Schritte nicht mit einer eigenen Anwendung zu machen, sondern mit den mitgelieferten Templates. So kann probiert werden, ohne das der eigene Quellcode
verändert wird. Es stehen für die RCP Entwicklung 4 Beispielanwendungen zu
Verfügung, die als Basis für die eigene Anwendung genutzt werden können.
Anlegen eines Projektes:
Neues Plugin Projekt in der Eclipse IDE anlegen.
Einen geeigneten Namen wählen. Die Voreinstellung können beibehalten
werden, sie sind sinnvoll vorbelegt. Wichtig ist in den folgenden Dialogen auf die Frage Would you like to create a rich client aplication? “Yes“
12. September 2006
5.3 Implementierungsdetails
47
auszuwählen. Danach folgt die Auswahl eines Anwendungstemplates. Das
RCP Mail Template enthält eine fertige Anwendung. Dieses kann in einem extra Projekt als Beispiel für die eigene Anwendung benutzt werden.
Als Basis für eine eigene Anwendung empfiehlt sich jedoch Hello RCP,
da dort nur absolut notwendige Bestandteile implementiert sind.
Anpassen der Fensterkonfiguration erfolgt durch Einfügen bzw. Abändern der Klassen ActionBarAdvisor, WorkbenchWindowAdvisor und WorkbenchAdvisor. Die Implementierungen aus dem RCP Mail Template einfach übernehmen und anpassen.
Vor dem Start der Anwendung sind noch ein paar Einstellungen vorzunehmen. Dazu ins Menü Run -> Run wechseln. Die Einstellung Eclipse
Application kopieren und umbennen, z.B. CANDY. In dieser dann unter dem Unterpunkt Program to Run -> Run an Application aktivieren.
In der Auswahl die eigene Applikation auswählen (hier: de.tudresden.
inf.rn.candy.application). Im Reiter Plug-in Choose plug-ins auswählen.
Dort alle Plugins deselektieren. Danach eigenes Plugin aktivieren (hier:
de.tudresden. inf.rn.candy) und mit Add Requiered Plug-ins alle erforderlichen Plugins einbinden. Mittels Validate Einstellungen überprüfen
und Anwendung starten.
5.3.3 Erstellen eines Views
Die Erstellung eines Views ist sehr einfach. Dazu einfach mit im Menü File ->
New -> other selektieren, oder durch Aufruf des Kontextmenües und dann New
-> other wählen. Es öffnet sich ein Auswahlmenü. Durch Auswahl von RCP
-> View Visual Class eine neue Klasse anlegen. Wichtig ist nun die ID. Dieser
String setzt sich zusammen aus dem Namen des Packages, in dem sich der View
befindet und dem eigentlichen Klassennamen. Es wird die Datei plugin.xml
mittel Eclipse geöffnet. Unter extension wird die Extension org.eclipse.ui.views
hinzugefügt. Diese wird dann durch einen view erweitert. Dabei sind die 3
Parameter id, name und class zwingend anzugeben. Der Parameter class wird
durch Browse und der Auswahl der neu erstellten Klasse bestimmt. Da der
Klassenname und die ID identisch sein sollten, wird der Klassenname in das
id Feld übernommen. Der Parameter name erscheint später als Bezeichner auf
12. September 2006
48
5 Implementierung der Anwendung
dem Reiter des Views und sollte daher so gewählt werden, das Anwender sich
leicht daran orientieren können. Bei der automatischen Erstellung werden auch
die Rümpfe zu implementierenden Methoden erzeugt.
Ein View kann erst betrachtet werden, wenn dieser an eine Perspektive gebunden ist. Die Anbindung geschieht in der Funktion
public void createInitialLayout(IPageLayout layout) {
String editorArea = layout.getEditorArea();
layout.setEditorAreaVisible(true);
layout.addStandaloneView(ResourceView.ID, true, IPageLayout.LEFT,
0.25f, editorArea); }
Der Aufruf von addStandaloneView(...) führt zu einem View, der seinen Platz
nicht mit weiteren Views teilt, d.h. alle später hinzugefügten View erscheinen
neben ihm. Ein derartiger View kann nicht verschoben oder geschlossen werden und hat keinen Reiter.
IFolderLayout folder =
layout.createFolder(“multiview“, IPageLayout.LEFT, 0.5f, editorArea);
folder.addView(ResourceView.ID);
Dieser Aufruf erzeugt einen Ordner, der verschiedene Views aufnehmen kann.
Der jeweils aktive View verdeckt dabei die nicht aktiven Views. Jeder View
verfügt über einen eigenen Reiter zur Auswahl. Zusätzlich kann ein View gekennzeichnet werden, so dass er nicht verschiebbar(setMoveable(false)) ist und
auch nicht geschlossen(setCloseable(false)) werden kann.
Für die genauen Details der Implementierung wird auf den mitgelieferten Sourcecode der Klassen im Package de.tudresden.inf.rn.candy.global.views verwiesen.
5.3.4 Erstellen eines Editors
Die Erstellung eines Editors ist ebenfalls sehr einfach. Dazu im Menü File -> New -> other selektieren, oder durch Aufruf des Kontextmenües und
dann New -> other wählen. Es öffnet sich ein Auswahlmenü. Durch Auswahl
von RCP -> Editor Visual Class eine neue Klasse anlegen. Wichtig ist nun
die ID. Dieser String setzt sich zusammen aus dem Namen des Packages, in
dem sich der Editor befindet und dem eigentlichen Klassennamen. Es wird die
12. September 2006
5.3 Implementierungsdetails
49
Datei plugin.xml mittel Eclipse geöffnet. Unter extension wird die Extension
org.eclipse.ui.editors hinzugefügt. Diese wird dann durch einen editor erweitert. Dabei sind die 3 Parameter id, name und icon zwingend anzugeben. Der
Parameter class wird durch Browse und der Auswahl der neu erstellten Klasse bestimmt. Da der Klassenname und die ID identisch sein sollten, wird der
Klassenname in das id Feld übernommen. Der Parameter name erscheint später als Bezeichnung auf dem Reiter des Editors und sollte daher so gewählt
werden, das Anwender sich leicht daran orientieren können. Wichtig: In der
Version 3.2 wird das Feld Icon nicht mehr als zwingend erforderlich dargestellt. Jedoch ist es zwingend erforderlich. Deswegen einfach einen beliebigen
String eintragen, bis ein passendes Icon gefunden wurde. Es wird dann ein rotes
Quadrat angezeigt. Ist kein Icon angegeben wird der Editor nicht erkannt. Bei
der automatischen Erstellung werden auch die Rümpfe zu implementierenden
Methoden erzeugt.
Für die genauen Details der Implementierung wird auf den mitgelieferten SourceCode der Klasse SampleEditor verwiesen. Dieser Editor befindet sich im
Package de.tudresden.inf.rn.candy.tools.sampleTool.
5.3.5 Plugins
Erstellen einer Pluginschnittstelle
Bereits beim Entwurf seiner Anwendung ist es wichtig, zu prüfen, an welchen
Sellen Plugins die Funktionalität sinnvoll erweitern können. Zum einen, um
Schnittstellen und damit entsprechende Interfaces zu defnieren, zum anderen,
um an der geeigneten Stelle abzufragen, welche Plugins mit eingebunden werden können.
Für diesen Beleg und als Beispiel für weitere Plugins wird eine Pluginarchitektur entwickelt, die aus einer XML Datei ein fertiges tolspezifisches Datenmodell
zurückliefert. Es wird vereinfachend angenommen, dass die Datei im lokalen
Workspace vorliegt und vollständig einlesbar ist. Daher ist diese Plugin Architektur nur für kleinere XML Dateien geeignet. Größere Dateien würden abschnittsweise eingelesen werden, jedoch stellt dieses einen entsprechen höhren
Aufwand dar.
12. September 2006
50
5 Implementierung der Anwendung
Um die Implementierung zu erleichtern wird als erstes ein Interface definiert.
Es bekommt den Namen ITransferXML. Es hat nur 4 Funktionen:
Object readXMLFile(IFile file)
erzeugt eine neues Datenmodell
aus der XML Datei
void writeXMLFile(IFile file, Object data)
schreibt das Datenmodell in
die XML Datei
String getXMLString(Object data)
liefert den XML String eines
Objektes zurück
Object getXMLObject(String XMLString)
liefert ein Objekt zu einem
XML String zurück
Im Plugin Editor wird nun ein neuer Extension Point hinzugefügt. Unter dem
gleichnamigen Reiter geschieht dies durch add. Als Name und ID wird xmltransfer genommen. Nach Abschluß der Eingabe öffnet sich der Schema Editor. Der Reiter Overview wird nicht weiter beachtet, im späteren Verlauf sollte
die fehlenden Dokumentation noch ergänzt werden. Bei Definition wird nun
der eigentliche Extension Punkt erzeugt. Der vorhande Punkt extension enthält Informationen über diesen neu erzeugten Extension Point. Hier wird ein
neuer Extension Point mittels New Element hinzugefügt und in xmltransfer
umbenannt. Danach geht es an die eigentliche Definition. Sinnvollerweise soll
jedes Plugin eine ID und einen Namen haben. Diese werden als Attribute hinzugefügt und als required gekennzeichnet. Das dritte Attribut bekommt die
Bezeichnung class, dies ist ebenfalls required und vom Typ java. Damit wird
sichergestellt, dass es zu jeder Extension die diesen Extension Point nutzt eine entsprechende Klasse gibt. Wichtig ist dabei, unter Implements das vorher
definierte Interface ITransferXML anzugeben. Ein weiteres Attribut mit der
Bezeichnung dtd speichert die DTD zu der XML Transfermechanismus paßt.
Dieses Attribut ist ebenfalls required. Zum Abschluß in element das Attribute
Sequence hinzufügen und im Kontextmenü als Reference -> transferxml . Im
Feld max Occurence “unbounded “ eintragen. Dadurch kann es mehrer Plugins
geben, die an den Extension Point transferxml andocken.
Nach der Definition geht es nun darum den neu erzeugten Extension Point zu
nutzen. Dies geht im Reiter extension. Dort den neu erzeugten Punkt
de.tudresden.inf.rn.candy.xmltransfer hinzufügen. Bei ersten Aufruf des Punk-
12. September 2006
5.3 Implementierungsdetails
51
tes class wird automatisch eine Klasse angelegt, die das angegebene Interface
implementiert. Auf gleiche Weise werden nun noch Extensions Points und Extensions für algebraische Algorithmen und für Tools erzeugt.
Es ergibt sich die Frage, ob es sinnvoll ist, Klassen eines Plugins mittels Extension einzubinden. Der Vorteil besteht darin, das es keinen Unterschied macht,
ob eine Extension Point durch eine interne Extension erweitert wird oder durch
ein separates Plugin. Eine Fallunterscheidung entfällt damit.
Pluginmechanismus
Bei der Implementierung eines Pluginmechanismus gibt es zwei Möglichkeiten
dies zu realisieren. Eine Variante besteht darin, Schnittstellen zu integrieren,
wie sie durch Eclipse angeboten werden. Dies erfordert jedoch, das sich alle
Entwickler, die eine Erweiterung schreiben, sich mit dem Plugin Mechanismus vertraut machen müssen. Der Vorteil liegt aber dann darin, die bereits
genannten Plugin Mechanismen von Eclipse nutzen zu können.
Eine zweite Variante wäre die Schaffung eines eigenen Pluginmechanismus.
Dies kann dann sinnvoll sein, wenn Plugins die Funktionalität der RCP Anwendung nur geringfügig erweitern. Eine geringfügige Erweiterung wäre die
Unterstützung eines NDML Elements. Dies erfordert, neben der elementspezifischen Datenverarbeitung nur Ergänzungen der GUI. Diese Plugins werden
im folgenden als Leichtgewichts Plugins bezeichnet. Ein solcher Leichtgewichts
Pluginmechanismus kann auch dann genutzt werden, wenn keine Anforderung
zu Unterstützung von Versionskontrolle oder seperaten Ablaufumgebungen für
die Plugins bestehen.
Natürlich wäre auch eine hybride Lösung möglich. Plugins werden benutzt, um
neue Aufgabenbereiche der Anwendungen hinzufügen und diese Plugins können dann ihrerseits einen Leichtgewichts Pluginmechanismus benutzen. Der
Vorteil liegt darin, das sehr früh ein prototypisches Plugin zur Verfügung steht,
an dem Nutzeraktzeptanz ermittelt werden kann. Die funktionelle Erweiterung
erfolgt dann schrittweise durch das Einfügen der Leichtgwichts Plugins. Es ist
dadurch auch möglich, die für einzelne Tags notwendige Implementierungsarbeit aufzuteilen und zu parallelisieren.
Es wurde bereits gezeigt, dass die Erstellung von Pluginschnittstellen sehr gut
12. September 2006
52
5 Implementierung der Anwendung
unterstüzt wird. Der Pluginmechanismus von Elipse ist ausgereift und setzt auf
einen Standard auf. Daher wird auf eine weitergehende detailierte Betrachtung
zur Entwicklung eigener Pluginmechanismen verzichtet.
Interaktion zwischen Plugins und Actionbars
Bei den Standard Swing/AWT Klassen ist es sehr leicht möglich, eine bestehende Menüzeile zu ermitteln und zu erweitern. Bei der RCP Architektur ist
eine Erweiterung der Actionsbars, zu den auch die Menübar gehört, nicht direkt möglich. Der Grund ist sehr einfach, warum dies seitens der Architektur
unterbunden werden soll. Wenn jedes Plugin eine Actionbar so einfach erweitern könnte, besteht die Gefahr, dass dies auch gemacht wird. Bei einer sehr
großen Anzahl von Plugins, die beispielsweise die Menübar erweitern, würden
die Menübars sehr groß werden. Gleichzeitig kann es geschehen, das Plugins
für vergleichbare Actionen mehrere Menüpunkte anfügen. Anwendungen würden dann mit einer immer größer werdenden Anzahl angebundener Plugins
zunehmend schlechter bedienbar.
Deswegen wird in der RCP Architektur ein anderer Ansatz gewählt. Die Erzeugung der Actionsbars (hier durch die Klasse ApplicationActionBarAdvisor im
Paket de.tudresden.inf.rn.candy.global.start ) geschieht bei der Initialisierung
einer Anwendung. Danach ist eine Änderung der Actionsbars nicht direkt möglich. Wird eine Aktion ausgeführt, kann diese dann an ein Plugin weitergeleitet
und abgearbeitet werden. Soll einem Plugin dennoch die Möglichkeit gegeben
werden, Actionbars zu erweitern, gibt es 2 Möglichkeiten. Bei der ersten Variante wird auf Separatoren zurückgegriffen. Separatoren ohne eigene ID werden
benutzt, um einen Trennbalken in einer Aktionbar zu erzeugen. In Menüzeilen
ist dieser horizontal. Wird ein Separator mit einer ID benuzt, erzeugt dieser
keinen Trennbalken, sondern kann als Anknüpfungspunkt für Erweiterungen
benutzt werden.
Der zweite Ansatz besteht in der Definition lokaler Actionbars. Lokal bedeutet, dass sie durch den View oder Editor definiert werden. Diese sind dann
nur in dem spezielle View oder Editor wirksam. Ein Beispiel zur geeigneten
Anwendung ist die Benutzung zum Aktivieren von Filtern.
12. September 2006
5.3 Implementierungsdetails
53
Abfrage der Pluginkonfiguration
Nachdem Extension Points definiert worden sind und durch Extensions genutzt werden, müssen die Extensions in eigene Routinen mitintegriert werden.
Plugins benutzen die Extension Registry um bei einer Anwendung registriert
zu werden. Eine Anwendung kann die Extension Registry abfragen.
IExtensionRegistry ireg=Platform.getExtensionRegistry();
IConfigurationElement xmlplugins;
xmlplugins=ireg.getConfigurationElementsfor(“xmltransfer“);
Dann kann beispielsweise das DTD Attribut abgefragt werden.
for{i=0;i<xmlplugin.length;i++}{
String dtd= xmlplugin[i].getAttribute(“DTD“)
}
Der vollständige Code, inklusive der notwendigen try/catch Umklammerung
ist in Perspektive.java zu finden.
5.3.6 Wizard Implentierung
Eclipse unterstütz die Entwîcklung von Wizards. Wizards sind Assistenten,
bei denen der Anwender die Möglichkeit hat, schrittweise bei dem Lösen einer
Aufgabe untersützt zu werden. Als Beispiele sei die Erstellung neuer Projekte
oder Dateien genannt, bei denen nach Angaben des Nutzers sinnvolle Voreinstellungen erzeugt werden.
Ein Wizard besteht aus drei Komponenten. Die erste Komponente für den Aufruf eines Wizard ist der WizardDialog. Diese Komponente ruft den eigentlichen
Wizard auf. Ein Wizard selbst besteht aus einer Menge von mindestens einer
WizardPage, einem Cancel und einem Finish Button. Sind in einem Wizard
mehrere WizardPages angelegt, wird automatisch noch der Back und Next
Button hinzugefügt. Wizards sollten genutzt werden, um die Benutzung eines
Produktes zu erleichtern. Für geübte Anwender kann es jedoch wichtiger sein,
direkt ein Element innerhalb eines Tools erzeugen zu können.
12. September 2006
54
5 Implementierung der Anwendung
Abbildung 5.2: Wizard, links Beispiel NewProjectWizard.java, rechts Aufbau
eines Wizards aus [Eci06]
5.3.7 XML
Für den Umgang mit XML Dateien kann sowohl auf das SAX als auch auf
das DOM API zurückgegriffen werden. Da die Schnittstelle für XMLTransfer Plugin keine Vorgaben macht, kann individuell abgewogen werden, wie die
zurückzuliefernden Objekte erzeugt werden. Für DOM spricht, dass es einen
kompletten Baum beim Einlesen liefert, und damit recht einfach zu programmieren ist. Da die zu erzeugenden Objekte möglicherweise auch eine Baumstruktur haben, würden parallel zwei Bäume aufgebaut werden. Dies kostet
Zeit und Ressourcen. SAX erzeugt keine kompletten Bäume sondern arbeitet
von Knoten zu Knoten. Damit ist der Aufbau einer eigenen Objekthierarchie
schneller und ressourcenschonender möglich. Als Nachteil ist dabei, dass die
Erzeugung eigener Objekthierachien weniger intuitiv ist.
5.4 Package- und Verzeichnisstruktur,
Namenskonventionen
5.4.1 Package- und Verzeichnisstruktur
de.tudresden.inf.rn.candy.global.action
Im Paket action sind die Klassen, die die run Methoden implementieren. Dabei
sollen die run Methoden sich auf den Aufruf von Dialogen beschränken. Die
12. September 2006
5.4 Package- und Verzeichnisstruktur, Namenskonventionen
55
eigentlichen Composites werden in separaten Klassen erzeugt.
de.tudresden.inf.rn.candy.global.algorithms
Diese Paket ist derzeit noch ohne Klassen und soll benutzt werden um algebraische Algorithmen zu definieren. Diese Klassen sollen Algorithmen so
implementieren, dass eine hohe Wiederverwendbarkeit erreicht werden kann.
Mögliche Algorithmen wären zum Beispiel Implementierungen der SimplexMethode (vgl. [Sed92]) zur Bestimmung von Optima unter Nebenbedingungen.
de.tudresden.inf.rn.candy.global.dialogs
In diesem Paket sind alle Klassen zu finden, die nichttoolspezifische (=globale)
Dialoge implentieren, also Dialoge die von den run() Methoden der Aktionen
aufgerufen werden.
de.tudresden.inf.rn.candy.global.interfaces
Alle nichttoolspezifischen Interfaces sind in diesem Paket enthalten. Es wird
empfohlen, Klassen die nicht toolspezifisch sind, zunächst als Interface zu definieren und dann darauf aufbauend Klassen zu implementieren. Dadurch wird
es leichter möglich, bei Bedarf passende Extensions bzw. Extension Points zu
erzeugen. Hervorzuheben ist das Interface ICandyDefaults, in dem nichttoolspezfische Konstanten definiert werden.
de.tudresden.inf.rn.candy.global.start
In diesem Paket sind alle zum Start der Anwendung notwendigen Klassen
enthalten. Es brauchen keine Klassen hinzugefügt werden.
de.tudresden.inf.rn.candy.global.support
Diese Paket ist für Klassen, die nichttoolspezifisch sind, bestimmt. In diesem
Paket sind auch die Implentierungen der nicht toolspezifischen Interfaces enthalten.
12. September 2006
56
5 Implementierung der Anwendung
de.tudresden.inf.rn.candy.global.views
Für Views, die in mehreren Tools benutzt werden können. Ein Beispiel ist der
Resourcen View.
de.tudresden.inf.rn.candy.global.wizards
Für alle Wizards, die nicht toolspezifisch sind. Als ein Beispiel sei der Import
Wizard genannt.
de.tudresden.inf.rn.candy.tools.xxx
Mit de.tudresden.inf.rn.candy.tools.xxx.yyy sollen die Pakete der konkreten
Tools beginnen. Dabei bezeichnet xxx den Namen des Tools und yyy steht
für weitere Pakete. Es wird empfohlen die Struktur, wie sie global benutzt
wird, bei den einzelnen Tools zu übernehmen.
5.4.2 Namenskonventionen und
Programmierempfehlungen
Neben den Regeln für die Groß und Kleinschreibung die in JAVA üblich sind,
gibt es noch weitere Empfehlungen. Interfaces sollten grundsätzlich mit großem
I beginnen. Variablen, die als Typ ein Interface haben, sollten daher mit kleinem i beginnen. Konstanten sollten komplett in separate Interfaces ausgelagert
werden. Einzige Ausnahme bilden die IDs von Views und Editoren. Bei der
Benutzung von Interfaces ist eine Referenzimplementierung mitzuliefern. Dies
erleichtert die Einarbeitung. Bei Namen von Variablen auf Sonderzeichen wie
Binde- und Unterstrich zu verzichten. Stattdessen Groß- und Kleinschreibung
benutzen.
12. September 2006
5.5 Noch offene Probleme
57
5.5 Noch offene Probleme
5.5.1 Verteiltes Bearbeiten, Synchronisation
Bei der Berarbeitung eines Dokumentes besteht das Problem, dass alle daran
arbeitende Personen stets die gleiche aktuelle Version eines Dokumentes benötigen könnten. Es wird angenommen, dass die Anwender nicht permanent
mit einem Netzwerk verbunden sind, so dass Anwender die Ergebnisse lokal
zwischenspeichert. Gleichzeitig können Abhängigkeiten zwischen verschiedenen Dokumenten bestehen. Als Beispiel sei auf die Abhängigkeiten zwischen
der Topologie eines Netzwerkes und der tatsächlichen Verkabelung verwiesen.
Lokal wird bei der Speicherung der Dokumente auf Dateien zurückgegriffen,
da andere Lösungen nicht praktikabel sind.
Es wird die Annahme getroffen, dass alle Dokumente zentral verfügbar sind
und die Nutzer ihre lokalen Dokumente in regelmäßigen, aber nicht definierbaren Abständen mit den zentral gespeicherten Dokumenten synchronisieren.
Dabei gibt es 2 Varianten, wie die Synchronisation und zentrale Speicherung
erfolgen kann. Eine Möglichkeit ist die Speicherung in Datenbanken und die
zweite Variante ist die Speicherung in Form von Dateien.
Bei der Speicherung in Form einer Datenbank wird ein XML Dokument geparst
und die Elemente in eine Datenbank hineingeschrieben. Das Erzeugen einer
neuen XML Datei geschieht dann durch auslesen der Datenbank. Wichtig ist
dabei, das die Baumstruktur eines XML Dokuments erhalten bleibt. Dabei
kann noch unterschieden werden, ob der Client die XML Datei parst und direkt
in die Datenbank speichert oder ob der Prozeß der Umwandlung zwischen XML
Datei und Datenbankeintrag durch einen Server für den Client transparent
erfolgt.
Bei der zweiten Variante werden Dateien direkt auf dem Server gespeichert.
Dabei kann der Client entweder direkt mit dem Server kommunizieren durch
entsprechende Protokolle wie FTP oder der Server stellt ein Netzlaufwerk zur
verfügung welches durch das Betriebssystem eingebunden wird.
Probleme können entstehen, wenn mehrere Nutzer ein Dokument bearbeiten.
Ein System kann entweder nur für einen Anwender die Dokument zum Be-
12. September 2006
58
5 Implementierung der Anwendung
arbeiten frei geben oder es bietet Unterstützung beim Zusammenführen von
verschieden Dokumentvarianten und Versionen. Derzeit wird dies nicht unterstützt und der Anwender muss auf separate Systeme wie CVS oder WebDAV
zurückgreifen.
5.5.2 Workspaceverzeichnis ändern
Der Workspace einer Anwendung wird beim Starten automatisch angelegt,
wenn er noch nicht existiert. Bei dem Workspace einer Anwendung handelt es
sich um ein Unterverzeichnis im Installationsverzeichnis einer Anwendung mit
dem Namen Workspace. Alle Plugins benutzen den selben Workspace. Es kann
die Notwendigkeit bestehen, dass die erstellten Dokumente in einem anderen
Verzeichnis gespeichert werden sollen, etwa aufgrund von Lese/Schreibrechten
oder weil nur bestimmte Verzeichnisse in ein (automatisches) Backup mit einbezogen sind. Das ist derzeit nicht möglich. Wie die Eclipse IDE zeigt, ist
zwar möglich, den Workspace zu ändern. Eine Dokumentation zur Implentierung in eigene Anwendungen existiert jedoch nicht. Behelfsweise ist es möglich,
Dateien die nicht im Workspace sind, als Link in ein Projekt einzubinden.
12. September 2006
6 Fazit
Ziel dieser Belegarbeit war es, anhand eines pluginfähigen Editors Möglichkeiten der RCP Architektur zu ermitteln. Dabei sollte die Eignung für die
Entwicklung zukünftiger CANDY-Tools ermittelt werden. Als Beurteilungsgrundlagen können dabei mehrere Kriterien herangezogen werden.
Umfang:
Die Menge der durch das Eclipse SDK mitgelieferten Komponen-
ten ist als sehr umfangreich einzuschätzen. Dabei seien SWT, JFace und
das Forms API als besonders leistungsfähig hervorgehoben. Viele dieser Komponenten sind bereits mit nur leichten Änderungen für eigene
Aufgaben anpaßbar.
Durch die Verfügbarkeit des GEF ist das Standard SDK sehr leicht zu
erweitern und ermöglicht damit die Entwicklung von komplexeren graphischen Editoren.
Plattformunabhängigkeit:
Die Plattformunabhängigkeit kann von zwei Sei-
ten her untersucht werden. Zum einen die Plattformunäbhängigkeit des
Quellcodes und zum Anderen die Plattformunabhängigkeit der daraus
erstellten Binärdateien. Der Quellcode ist, da Java benutzt wird, plattformunabhängig. Die daraus erstellten Binärdateien sind es jedoch nicht
vollständig. Dies liegt an dem Einsatz von SWT. Einige plattformspezifischer Anpassungen innerhalb der Kern Plugins von Eclipse sind ebenfalls nicht Binärkompatibel. Bei der Erstellung eines Produkts müssen
entsprechend die platformspezifischen Plugins mit eingebunden werden.
Bei der Erweiterung eines Produkts durch Plugins muss dann entsprechend sichersgestellt werden, dass diese ebenfalls für die verschiedenen
Plattformen angepaßt sind.
60
6 Fazit
Erweiterbarkeit:
Die Erweiterbarkeit einer Anwendung oder des fertigen
Produkts sind die Stärken der RCP Architektur. Durch Defintion von
Exentension Points bekommt eine Anwendung die Fähigkeit zur Erweiterbarkeit. Durch Nutzung von Extensions kann werden bestehende
Exentension Points erweitert und damit auch die Anwendung. Im Umfang dieses Beleges wurde gezeigt, wie leicht es ist, die Möglichkeiten zur
Erweiterbarkeit zu nutzen.
Einarbeitungsaufwand:
Aufgrund des Umfangs und der Leistungsfähigkeit
der im Eclipse SDK enthalten Komponenten ist davon auzugehen, dass
sich der Einarbeitungsaufwand reduziert. Gleichzeitig ist davon auszugehen, dass durch Wiederverwendung der im Rahmen dieses Belegs erstellten Klassen der Programmieraufwand sich ebenfalls reduziert. In welchem Umfang sich der Einarbeitungsaufwand tatsächlich reduziert ist
aber weiterhin individuell verschieden.
Unterstüzung durch Tools Derzeit wird das Entwickeln von RCP Anwendungen nur durch die Eclipse IDE vollständig durch Wizard, Templates
und angepßte Editoren unterstützt. Zusätzlich zur Unterst¨zung für die
RCP Architektur ist es möglich, die Entwicklung von GUI Komponenten durch den Visual Editor zu unterstützen. Dieses Eclipse IDE Plugin
ermöglicht damit den Aufbau von SWT, AWT und Swing basierenden
Komponenten.
Dokumentation:
Die direkt zum SDK mitgelieferte Dokumentation ist aus-
reichend, jedoch sind die dargestellten Beispiele zum Teil recht knapp
oder zu sehr auf die Erweiterung der Eclipse IDE ausgerichtet. Weitergehende Möglichkeiten bieten [Dau06] sowie online [Sni06]. Unter [Eco06]
sind entsprechende FAQ Sammlungen zu finden. Durch Suchmaschinen
lassen sich weitere Quellen und Beispiele finden. Durch die Sekundärquellen werden Ungenauigkeiten der Dokumentation beseitigt und Empfehlungen bei speziellen Problemen in der Entwicklung gegeben.
Die RCP Architektur eignet sich für die Entwicklung von CANDY Tools, insbesondere aufgrund die zahlreichen Komponenten die durch SWT, JFace, Forms
API und GEF zur Verfügung gestellt werden. Durch Schnittstellen wird die
Entwicklung zahlreicher Standart GUI Elemente wesentlich erleichtert und die
Entwicklungszeit verkürzt. Die Plugin Architektur ermöglicht eine einfache Er-
12. September 2006
61
weiterung und Entwicklung von Editoren. Dadurch wird weniger Zeit für die
Entwicklung geeigneter Softwarearchitekture benötigt. Es kann mehr Zeit für
die Lösung der fachlichen Probleme verwendet werden. Bezugnehmend auf die
Anforderungen, die im ersten Kapitel gestellt wurden, ist die RCP Plattform
zur CANDY Entwicklung geeignet.
12. September 2006
62
6 Fazit
12. September 2006
Glossar
In der Informatik existieren viele Begriffe, die je nach Autor, unterschiedlich
präzise definiert sind. Um Mehrdeutigkeiten zu vermeiden ist dieses Glossar
mit angefügt.
Anwender Als der Anwender wird ein nicht näher definierter Personenkreis
umschrieben, für den ein Produkt entwickelt wird. Durch diesen werden
Anforderung an ein Produkt umschrieben, oder es werden Annahmen
über mögliche Anforderungen gemacht.
Anwendung Die Anwendung ist der zur Ausführung gebrachte Quellcode.
Framework Ein Framework ist eine Menge von miteinander agierendene Methoden, die den Zugriff auf die Ressourcen einer Laufzeitumgebung abstrahieren. Diese Methoden werden vom Softwareentwickler benutzt, um
die Wiederverwendbarkeit von Quellcode zu erhöhen und die Fehlerwahrscheinlichkeit zu senken.
IDE Integrated development enviroment oder Integrierte Entwicklungsumgebung umschreibt eine Editor für Programmiersprachen der das editierte
Programm übersetzt und ausführt, ohne das der Programmierer den Editor verlassen muss bzw. separate zusätzliche Programme zur Ausführung
aufrufen muss.
Plugin Ein Plugin ist Software die durch entsprechende Schnittstellen eine
Anwendung um weitere Funktionalitäten erweitert ohne dass innerhalb
des Quelltextes einer Anwendung Veränderungen durchgeführt werden
müssen
64
Glossar
Produkt Ein Produkt ist eine Anwendung, die vollkommen selbständig lauffähig ist. Sie ist entweder fertig zur Installation oder im bereits beim
Anwender installiert.
Rolle Eine Rolle ist die Funktion die ein Anwender gegenüber einem System
einnimmt. In Abhängigkeit der vom Anwender gewählten Rolle verändert sich das Verhalten des Systems. Als Beispiel sei ein Administrator
genannt, der in der Rolle als Administrator ein System konfigurieren
kann. In seiner Rolle als normaler Anwender kann die selbe Person dies
jedoch nicht.
12. September 2006
Literaturverzeichnis
[Bal00] Helmut Balzert, Lehrbuch der Softwaretechnik, Band 1 SoftwareEntwicklung, 2.Auflage, Spektrum Akademischer Verlag, 2000
[Boc99] Grady Boch, James Rumbaugh, Ivar Jacobson, Das UMLBenutzerhandbuch, 2.Auflage, Addison-Wesley, 1999
[Cub05] Ulrich Cuber, Einstieg in Eclipse 3, 1. Nachdruck, Galileo Press, 2005
[Dau05] Berthold Daum, Rich-Client-Entwicklung mit Eclipse 3.1, 1.Auflage,
dpunkt Verlag, 2005
[Dau06] Berthold Daum, Das Eclipse-Codebuch, 1.Auflage, dpunkt Verlag,
2006
[Eco06] Eclipse online: www.eclipse.org
[Eci06] Eclipse SDK: Online Hilfe der Eclipse IDE
[Ecl02] Eclipse Magazin, Ausgabe 2, Software & Support Verlag, 2005
[Ecl03] Eclipse Magazin, Ausgabe 3, Software & Support Verlag, 2005
[Ecl04] Eclipse Magazin, Ausgabe 4, Software & Support Verlag, 2005
[Ecl05] Eclipse Magazin, Ausgabe 5, Software & Support Verlag, 2006
[Ecl06] Eclipse Magazin, Ausgabe 6, Software & Support Verlag, 2006
[Ecl07] Eclipse Magazin, Ausgabe 7, Software & Support Verlag, 2006
[Fre91] Fremdwörterlexikon, Lizenzausgabe für Wissenverlag,1991
[Geo06] Eclipse online: www.eclipse.org/GEF
66
Literaturverzeichnis
[Gol00] Charles F. Goldfarb, Paul Prescod, Das XML-Handbuch, 2.Auflage,
Addison-Wesley, 2000
[Gui06] http://www.eclipse.org/articles/Article-UI-Guidelines/Index.html
[Kli05] Großer Beleg Rico Klinkewitz, Entwicklung eines CANDY Projektmanagers, 2005
[Mid03] Stefan Middendorf, Reiner Singer, Jörn Heid, Java Programmierhandbuch und Referenz, 3.Auflage, dpunkt Verlag, 2003
[Sed92] Robert Sedgewick, Algorithmen in C,1.Auflage,Addison-Wesley,1992
[Sni06] Eclipse online: dev.eclipse.org/viewcvs/index.cgi/org.
eclipse.swt.snippets/src/org/eclipse/swt/snippets/
[Ste02] Ralph Steyer, Java 2, Markt und Technik Verlag, 2002
[Wik06] wiki.eclipse.org/index.php
12. September 2006
Anhang
Als Anhang gehört eine CD zu diesem Beleg. Folgender Inhalt ist auf der CD:
Verzeichnis
Inhalt
BELEG_LATEX
Latex Dateien und Bilder des Beleges
BELEG_PDF
Beleg als PDF Dokument
BELEG_VERTEIDIGUNG
Präsentation der Verteidigung
ECLIPSE_SDK
Eclipse IDE
ONLINE_QUELLEN
Mitgenutzte Online Quellen
PROGRAMM
Ausführbares Programm “Candy.exe“
QUELLCODE
Der Quellcode der Anwendung
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement