Seite 3: Eclipse Modeling Tools

Inhaltsverzeichnis

Graphical Modeling Framework

Mit dem Graphical Modeling Framework (GMF) generiert man grafische Editoren, die Instanzen eines domänenspezifischen Metamodells erzeugen und darstellen können. Die meisten Anwender bevorzugen grafische Repräsentationen. Sie bieten, zumindest bei kleineren Modellen, einen guten Überblick über die Architektur. Anzumerken ist hier, dass der Trend derzeit zu textuellen Darstellungen geht, die für bestimmte Anwendungsfälle einige Vorteile mit sich bringen [4].

GMF ist ein generatives Framework zum Erstellen grafischer Editoren auf Basis von EMF. Als Subprojekt des Eclipse Modeling Project setzt es sich aus dem Graphical Editing Framework (GEF), dem Eclipse Modeling Framework (EMF), einer Runtime Library sowie einem Code-Generator zusammen. Um mit GMF einen grafischen Editor zu generieren, ist es notwendig, zusätzlich zum domänenspezifischen Metamodell drei weitere Modelle zu erstellen.

• Graph Model: Im Graph Model werden die Formen, welche im Diagramm dann zur Verfügung stehen, deklarativ beschrieben. Der Anwender kann die gängigen Draw2D-Elemente verwenden und ihnen Layouts, Schriftarten, Farben sowie diverse andere Parameter zuweisen. Das Graph Model ist vom definierten Domänenmodell unabhängig und kann somit wiederverwendet werden.
• Tool Model: Das Tool Model dient der Erstellung der Werkzeugpalette, die an der rechten Seite des Editors zur Auswahl steht. Es hängt nicht vom Domänen-Modell ab und ist

somit ebenfalls leicht wiederzuverwenden.

• Mapping Model: Das Mapping Model ist das zentrale Modell von GMF. Es vereint alle vorherigen Modelle, sodass grafische Elemente, die im Graph Model erstellt wurden, mit semantischen Elementen aus dem Domänenmodell verbunden sind. Hier werden auch die Tools angebunden, um sie in der Toolbar anzuzeigen und das Erstellen neuer Elemente im Diagramm zu ermöglichen.

Sobald alle Modelle erstellt und fehlerfrei sind, ist das GMF-Gen-Modell zu erstellen. Es enthält zusätzliche Beschreibungsdaten für den Generierungsprozess und einige Optionen, manuell in die Generierung einzugreifen. Das Gen-Modell ist sehr mächtig, aber leider fast nicht dokumentiert. Ist es allerdings erstellt und auf die eigenen Anforderungen konfiguriert, kann aus ihm der Code für den grafischen Editor generiert werden. Mithilfe des generierten Architektur-Editors ist es nun möglich, die zuvor beschriebene Beispielarchitektur zu definieren (siehe Abb. 4).

openArchitectureWare (oAW)

Da Dependometer zur Architekturvalidierung XML als Eingabe erwartet, muss man zunächst aus der DSL die benötigten XML-Dateien erzeugen. Mit oAW als Generator-Framework lässt sich diese Aufgabe einfach bewerkstelligen. Es ist ein Framework für die modellgetriebene Softwareentwicklung, das unter der Eclipse Public License (EPL) quelloffen verfügbar ist und viele Entwickler entwickeln. Unter anderem kann oAW Codegeneratoren für beliebige Modelle erstellen. Zu diesen Modellen gehören EMF-Modelle, fast alle mit UML-Werkzeugen erstellten Modelle, aber auch Visio-Modelle oder textuelle Spezifikationen. Aus den Modellquellen können beliebige Artefakte generiert werden. Auf der Basis des zuvor erstellten domänenspezifischen Metamodells und der grafischen Architekturbeschreibung werden durch den Einsatz von Xpand die von Dependometer benötigten XML-Dateien generiert. Xpand ist eine Template-Sprache mit statischen Typen und enthält spezielle für die Codegenerierung wichtige Eigenschaften:

• Schreiben in Dateien innerhalb von Templates
• Polymorpher Aufruf der Templates
• Erweiterbarkeit durch andere oAW Sprachen wie Xtend

Abbildung 5 zeigt ein Xpand-Beispiel, das aus einem Subsystem die darunter angegebene entsprechende XML-Repräsentation erzeugt.

Neben weiteren Sprachen wie Xtend und Check setzt oAW auf einem Komponentenframework auf, auch als Workflow Engine bezeichnet. Der Workflow-Mechanismus stößt den Generierungsprozess an und steuert ihn. Auf eine detaillierte Beschreibung von oAW sei an dieser Stelle aber verzichtet. Der interessierte Leser findet in [7] eine ausführliche Einführung in oAW. Der folgende Abschnitt zeigt stattdessen, wie aus den bisher vorgestellten Konzepten eine kompakte Anwendung zu schnüren ist.

Integration in einen Gesamtprozess

Der Einsatz von Softwarewerkzeugen scheitert oftmals an fehlender Akzeptanz der Anwender. Dies liegt nicht selten in einer umständlichen Bedienung begründet. Schlecht gestaltete Benutzerschnittstellen führen dazu, dass selbst konzeptionell sinnvolle Anwendungen ein Schattendasein fristen, da Anwender sie nicht nutzen. Um sowohl Entwicklern als auch Architekten ein effektives Arbeiten zu ermöglichen, ist die vorgestellte Open-Source-Toolkette in einen Prozess innerhalb der Eclipse-IDE integriert. Die Ziele lagen insbesondere auf:

• der nahtlosen Integration des Architektur-Editors in die Eclipse-IDE,
• dem einfachen Ausführen der Architekturverifikation sowie
• der Einbindung in einen Continuous-Integration-(CI-)-Prozess.

Da die Toolkette als Eclipse-Plug-in realisiert wurde, können Architekten und Entwickler sie verwenden, ohne ihre gewohnte Arbeitsumgebung verlassen zu müssen. Durch unterschiedliche Werkzeuge erzwungene Kontextwechse entfallen somit. Sowohl die initiale Architekturerstellung als auch die projektbegeleitende -verifikation können innerhalb derselben Entwicklungsumgebung durchgeführt werden. Bindet man die Verifikation mit Ant Targets in Continuous-Integration-Werkzeuge wie Cruise Control ein, kann man die Architektur regelmäßig während der "Nightly Builds" prüfen. Da mit dem vorgestellten Ansatz Architekten und Entwickler jederzeit im Entwicklungsprozess den Quellcode anhand der vorhandenen Architekturspezifikation prüfen können, ist eine hohe Softwarequalität gewährleistet.