EMF vs. MDA. Klaus Mairon Klaus Häuptle

Transkript

1 EMF vs. MDA Klaus Mairon Klaus Häuptle Furtwangen,

2 II Inhaltsverzeichnis 1 EMF-Einführung EMF Ecore Metamodell Core Model Genmodel EMF Mechanismen XMI Serialisierung und Persistenz Java Annotationen Notification EMF.Edit und EMF.Codegen EMF.Edit EMF.Codegen EMF-Editor erstellen JET Projekte im Kontext von EMF GEF GMT UML GMF EMF vs. MDA Schichtenmodell MOF vs. Ecore XMI EMF vs. JMI Constraint Language Persistenz Fazit und Ausblick...22 Abkürzungsverzeichnis... III Abstract... IV Abbildungsverzeichnis...24 Anhang...25

3 III Abkürzungsverzeichnis EMF GEF GMF GMT JET JMI MDA MOF QVT SDO UML XMI XSD Eclipse Modeling Framework Graphical Editing Framework Graphical Modeling Framework Generative Model Transformer Java Emitter Templates Java Metadata Interface Model Driven Architecture Meta Object Facility Query/View/Transformation Service Data Objects Unified Modeling Language XML Metadata Interchange XML Schema Infoset Model

4 IV Abstract Eclipse gilt inzwischen als eine der meistgenutzten Java-IDEs. Eclipse ist jedoch mehr als eine reine IDE. Aufgrund der Plug-In-Architektur ist Eclipse flexibel erweiterbar und eine Vielzahl von Projekten beschäftigen sich damit, Eclipse als Entwicklungswerkzeug weiter auszubauen. Wichtige Grundlage hierzu ist das Eclipse Modeling Framework (EMF) mit dem zugrundeliegenden Metamodell Ecore. Ziel dieser Ausarbeitung ist es, die Konzepte des Eclipse Modeling Framework und deren Beeinflussung durch Ideen der Model Driven Architecture darzustellen. Außerdem werden die Ansätze von EMF und der ergänzenden Projekte mit der MDA verglichen. Auf diesem Vergleich aufbauenden zeigt die Ausarbeitung die wesentlichen Unterschiede auf. Es wird auch versucht zu prognostizieren, wie EMF sich in Zukunft in Richtung MDA entwickeln könnte. Kenntnisse der MDA werden hierzu vorausgesetzt. Dabei werden neben der Erläuterung des EMF und seiner Besonderheiten auch einige der begleitenden Projekte wie GEF, GMT oder UML2 vorgestellt.

5 1 EMF-Einführung Das Eclipse Modeling Framework (EMF) ist ein Java / XML Framework für die Modellierung und Generierung von Tools und Anwendungen mittels einfachen Klassen-Modellen. Des Weiteren ist EMF ein modellgetriebenes Metadaten-Management Framework. Der Code von EMF ist sehr reif, da IBM bereits seit Visual Age 3.0 daran arbeitet. IBM hat EMF 2003 als Open Source- Projekt veröffentlicht. Mittlerweile gehört EMF zur eclipse.org und ist ein zentraler Bestandteil von Eclipse, da EMF die Integration verschiedenartigster Tools in Eclipse erlaubt. Da Eclipse 3.1 zum derzeitigen Zeitpunkt noch nicht veröffentlicht ist, basiert diese Ausarbeitung auf EMF 2.0.1, welches durch Eclipse verwendet wird. Die Besonderheiten dieses Frameworks sind die direkte Integration des Modells und dessen Implementierungen. EMF erlaubt es ein Modell in einer bestimmten Form (z.b. Java, XML oder UML) zu erstellen und daraus die anderen Formen zu generieren. Hierbei ist, wie in Abb. 1 zu sehen, ein EMF-Modell die gemeinsame abstrakte Basis, welche alle Repräsentations-Formen verbindet. EMF unterstützt Round-Trip-Engineering, die generierten Artefakte können verändert und erweitert werden bei Veränderungen der Artefakte werden diese automatisch mit dem EMF Modell synchronisiert. Abbildung 1: EMF Modell verbindet XML, UML und Java [Gamma] Bei der Entwicklung von Web Services erlaubt EMF zum Beispiel aus einem Message-Schema direkt ein UML-Klassendiagramm oder Java-Klassen für die XML-Verarbeitung zu erstellen. Zusätzlich kann ein Editor erstellt werden, um die Messages zu bearbeiten. Ebenfalls kann der Entwickler, statt mit dem XML-Schema mit einem Klassendiagramm oder den Java Interfaces starten und daraus das XML-Schema generieren. Der wesentliche Vorteil von EMF gegenüber MOF ist die Integration in Eclipse. Auf der anderen Seite ist EMF nur eine kleine Untermenge des MDA-Ansatzes. Ziel dieser Ausarbeitung ist es die Konzepte die EMF zu Grunde liegen, zu erläutern und EMF mit MDA zu vergleichen. Kapitel 2 erläutert die Konzepte von EMF, es wird dabei vorausgesetzt, dass der Leser grundlegende Kenntnisse über MDA hat. Kapitel 3 vergleicht den Ansatz der OMG mit EMF und zeigt wesentliche Unterschiede auf. In Kapitel 4 werden die Ergebnisse der Ausarbeitung zusammengefasst und bewertet.

6 6 EMF 2 EMF Im folgenden Kapitel werden die verschiedenen Mechanismen und Bestandteile von EMF erläutert. EMF enthält ein Metamodell (Ecore) für die Beschreibung von Modellen und Unterstützung für diese Modelle zum Beispiel in Form von Notification, Persistenz und einer Reflection API. 2.1 Ecore Metamodell Ecore ist das Metamodell und das Meta-Metamodell innerhalb von EMF. Im Vergleich mit MDA entspricht es insofern dem MOF, dass Ecore ebenfalls selbstbeschreibend ist, Ecore ist also sein eigenes Metamodell. Die folgende Abbildung zeigt einen Ausschnitt mit den wesentlichen Meta- Klassen, -Attributen und -Beziehungen des Ecore-Modells. Das vollständige Ecore-Modell befindet sich im Anhang. Abbildung 2: Ausschnitt aus Ecore 1. EClass repräsentiert eine modellierte Klasse. Klassen haben einen Namen, null oder mehrere Attribute und null oder mehrere Referenzen. 2. EAttribute beschreibt ein modelliertes Attribut einer Klasse und hat einen Namen und einen Typ. 3. EReference repräsentiert ein Ende einer Assoziation zwischen Klassen. Es hat einen Namen und einen Typ, der Typ muss hierbei eine Instanz von EClass sein. Die Kardinali-

7 EMF 7 tät der Beziehung wird durch lowerbound und upperbound angegeben. Containment legt fest, ob es sich bei der Beziehung um Komposition handelt. 4. EDataType wird verwendet, um den Java-Typ eines Attributs festzulegen. Ein Datentyp kann entweder ein primitiver oder ein Objekt-Typ sein. 2.2 Core Model Das Core Model ist in einer Datei mit der Dateiendung.Ecore gespeichert und wird innerhalb des EMF als Instanz des Ecore-Modells bezeichnet. Das Core Model ist durch Ecore-Objekte im Speicher repräsentiert. Das EMF-Framework kann diese Objekte lesen beziehungsweise manipulieren und somit direkt auf das Modell zugreifen. Dabei können diese Repräsentationen zum Beispiel entweder aus XML, Java, UML oder einer anderen auf EMF basierenden DSL erstellt werden. Bei Verwendung von UML gibt es drei Alternativen das Modell in den Speicher zu laden: 1. Direkte Bearbeitung des Modells: Zum Beispiel mittels des EclipeUML-Tools oder dem in EMF integrierten baum-basierten Ecore-Editor. 2. Import aus UML mittels des EMF Project Wizard: EMF unterstützt dies für Rational Rose (.mdl) Dateien, andere Formate werden bisher nicht unterstützt. 3. Export aus UML-Tools direkt nach EMF. Dazu muss das Tool allerdings Ecore XMI unterstützen. Die beste Importfunktionalität bietet derzeit der Import über.mdl Dateien. Dies ist darin begründet, dass IBM das Eclipse Modeling Framework mit Rational Rose spezifiziert hat. Neben dem Import kann der Entwickler das Core Model auch direkt über einen baum-basierten Editor oder über EclipseUML bearbeiten. Durch dieses Vorgehen wird die Synchronisation zwischen EMF und den UML-Dateien automatisch erledigt. Ecore definiert das Metamodell für die Core Modelle. Dabei ist Ecore selbst wiederum ein Core Model, wie MOF definiert Ecore sein eigenes Metamodell. Das Core Model findet in zwei verschiedenen Kontexten Verwendung: - Während der Anwendungsentwicklung wird das Core Model zur Codegenerierung verwendet, um beispielsweise Instanzen des Modells erstellen zu können oder ein vorhandenes Modell zu bearbeiten. EMF generiert jedoch nur Modell-Implementierungen in Java. - Das generische EMF-Framework verwendet das Core Model zur Laufzeit dazu, das Verhalten für ein bestimmtes Modell zu bestimmen. Ein Entwickler kann diese APIs verwenden um dynamisch das Modell zu untersuchen und zu bearbeiten. Das Framework erlaubt die Serialisierung und beinhaltet die EObjectAPI. 2.3 Genmodel Das Generator-Modell (Genmodel) ist in einer Datei mit der Endung.genmodel gespeichert und enthält systemabhängige Informationen für die Codegenerierung, zum Beispiel der Speicherort für die Codegenerierung und die Informationen über geschützte Bereiche. Der EMF Codegene-

8 8 EMF rator verwendet dieses Modell um diese Informationen zu speichern. Wie das Core Model ist auch das Generator-Modell ein EMF-Modell. Das Generator-Modell ist im Wesentlichen ein Wrapper um das Core Model, das heißt die Modellklassen sind Decoratoren für die Ecore- Klassen. Zum Beispiel, dekoriert GenClass Eclass und GenFeature dekoriert EAttribute und EReference, dieser Sachverhalt ist in der folgenden Abbildung dargestellt. Abbildung 3: Generator-Modell und Ecore-Modell Durch die Unterscheidung in Core Model und Genmodel ist das Modell von der Codegenerierung getrennt. Dadurch sind die Modelle unabhängig von der Codegenerierung. Allerdings müssen die Dateien immer synchron gehalten werden. EMF erledigt dies automatisch, in dem EMF das Genmodel das Core Model überwacht. Der Entwickler kann die Codegenerierung durch Markierungen beeinflussen, so bedeutet das dass der Code überschrieben werden kann, alle anderen Blöcke werden nicht ersetzt. 2.4 EMF Mechanismen XMI Serialisierung und Persistenz Für die Persistierung der Modelle verwendet EMF standardmäßig das XMI-Fomat in der Version 2.0. EMF begründet dies mit der kompakteren Darstellung von XMI 2.0. Allerdings muss ein Modellierungswerkzeug Ecore XMI unterstützen, damit EMF das Modell importieren kann. Das bedeutet, dass das zu importierende Modell konform zum Ecore Model sein muss. Alternativ zu XMI kann EMF das Modell auch in einem XML-Schema speichern oder einen selbstimplementierten Persisitierungsmechanismen benutzen Java Annotationen Damit der EMF Generator aus einem Java Interface das Ecore-Modell erstellt, müssen das entsprechende Interface und die get-methoden mit der markiert sein. EMF ermittelt daraus Attribute und Referenzen:

9 EMF 9 /** type= Kunde **/ public Collection getkunden(); Wie im Beispiel zu sehen kann Javadoc zusätzliche Informationen enthalten, welche sich nicht durch Reflection ermitteln lassen. So wird hier mittels type= Kunde festgelegt, dass der Typ der Referenz Kunde ist. Die set-methoden müssen nicht im annotierten Interface enthalten sein. Die get-methoden genügen dem Framework, um die Attribute und Referenzen zu identifizieren und daraus die get- und set-methoden zu erstellen Notification Jede EMF- Klasse hat einen Notifier, welcher bei Veränderungen der Attribute oder Referenzen einer Klasse Benachrichtigungen versendet. Ein Adapter ist der Empfänger einer solchen Nachricht und kann sich an jedes EObject binden. Listener werden in EMF Adapter genannt, da sie im Gegensatz zu einem reinen Observer das Verhalten der Objekte, die sie überwachen, erweitern können. Dieser Mechanismus erlaubt die Überwachung von EMF Objekten, zum Beispiel um bestimmte Views zu aktualisieren oder abhängige Objekte zu informieren. Adapter sind, wie im nachfolgenden Kapitel beschrieben, Basis-Elemente für das EMF.Edit Framework. 2.5 EMF.Edit und EMF.Codegen EMF.Edit EMF.Edit ist ein Bestandteil des Eclipse Modeling Frameworks. Bei EMF.Edit handelt es sich um ein Framework zur Erstellung von Editoren für EMF-Modelle. Eclipse bringt von Haus aus eine Reihe von GUI-Klassen (Viewer) wie TreeViewer, TableViewer etc. mit, über die strukturierte Modelle dargestellt werden können. Diese Viewer-Klassen greifen über die als Content Provider bezeichneten Adapter auf das jeweils zugrundeliegende EMF-Modell zu. Das EMF.Edit-Framework besteht aus: - Content- und Label-Provider-Klassen, Property Source Support und zusätzlichen Hilfsklassen, die eine Darstellung eines EMF-Modells über die Standard Desktop Viewer (JFace) und eine Bearbeitung über Property-Sheets ermöglichen. - einem Command-Framework, das einem Editor die Unterstützung eines automatischen Undo / Redo ermöglicht.

10 10 EMF EMF.Codegen Wie EMF.Edit ist auch EMF.Codegen ein weiterer Bestandteil des Eclipse Modeling Framework. Bei EMF.Codegen handelt es sich um einen Generator zur Erstellung eines EMF-Editors. Neben einer Kommandozeilen-Version umfasst EMF.Codegen eine grafische Benutzeroberfläche, über die Einstellungen für die Generierung vorgenommen und der Generatoraufruf vorgenommen werden kann. Hierbei wird die JDT-Komponente (Java Development Tooling) von Eclipse verwendet. Als Templatesprache wird JET (Java Emitter Templates) verwendet, welche nachfolgend noch näher erläutert wird. Auf Basis eines EMF-Modells können über den Generator Content Provider erzeugt und anschließend auf einfache Weise von den Viewer-Klassen benutzt werden. Nach dem Design des Modells und dem Generieren des Codes können die restlichen Teile, die für eine vollständige Anwendung benötigt werden, über Wizards erzeugt werden. Das auf diese Weise erzeugte Plugin kann über die Run-Time-Workbench ausgeführt werden und ermöglicht ein interaktives Bearbeiten einer Modellinstanz EMF-Editor erstellen Mit Hilfe des Generators und des verwendeten EMF.Edit-Frameworks kann mit drei grundlegenden Schritten ein einfacher Editor für ein EMF-Modell bereitgestellt werden. Diese hierfür notwendigen Schritte sind: 1. Definition eines EMF-Modells. Dieses kann entweder mit Rational Rose erstellt sein und als mdl-datei in ein EMF-Projekt importiert werden. Alternativ kann ein Modell auch über annotierte Java-Interfaces und Klassen beschrieben und über einen Wizard das EMF-Modell (core model und generator model) erstellt werden. 2. Generierung des EMF-Model-Codes auf Basis des erstellten EMF-Modells. 3. Generierung des Editors für das erstellte EMF-Modell. Der generierte Editor wird übersetzt und als neues Plug-In für Eclipse in die Umgebung integriert. Abbildung 4: Definition eines EMF-Modells in Rational Rose und in Java

11 EMF 11 Mit Hilfe eines auf diese Weise erstellten einfachen Editors können nun beliebige Modell- Instanzen definiert und im XMI-Format gespeichert werden. Nachfolgende Grafik zeigt Ausschnitte der Bearbeitung einer Modellinstanz in der Eclipse-Umgebung. Abbildung 5: Bearbeiten einer EMF-Modellinstanz Eine nähere Beschreibung der hier genannten Schritte findet sich in dem Tutorial Generating an EMF Model unter folgendem Link: JET Die EMF Codegenerierung basiert auf JET Templates. JET steht für Java Emitter Templates und basiert aus einer Untermenge der JSP Syntax. Die Generierung von Text aus JET Templates basiert auf zwei Schritten: der Übersetzung und der Generierung. Im ersten Schritt wird das Template in eine Java Klasse übersetzt, dieser Quellcode ist lediglich eine andere Form des Templates. Erst im zweiten Schritt wird die Klasse dazu verwendet den Text (z.b. Java Code) zu erzeugen. Abbildung 6 zeigt die wesentlichen Tag-Typen. Typ Syntax Beschreibung JET Directive <%@ jet attributes %> Läutet den Beginn eines Templates ein Include <%@ include file="pfad" %> Anderes Template einbetten Expression <%= expression %> Ergebnis des Ausdrucks einfügen Scriptlet <% code %> Führt den enthaltenen Code aus Abbildung 6: JET Template Tags

12 12 EMF Die JET Directive übermittelt bestimmte Attribute an die Template-Engine. Jedes Template wird in eine Java Klasse übersetzt, welche eine Methode generate enthält. Über die generate-methode wird der Generierungsprozess angestoßen. Als Übergabeparameter erhält diese Methode ein Objekt vom Typ Object und als Rückgabeparameter liefert die Standard-Implementierung einen StringBuffer mit dem generierten Code zurück. Im folgenden Beispiel wir angegeben, dass das Template in eine Java-Klasse HelloWorldTemplate übersetzt werden soll und diese Klasse die Pakete java.io.* und java.util.* importieren muss. jet package="hello" class="helloworldtemplate" imports="java.io.* java.util.*" %> Mit include wird der Text der angegebenen Ressource zur Übersetzungs-Zeit in das JET Template eingefügt. JET unterstützt in diesem Zusammenhang das Überschreiben des Template-Pfads. Dies ermöglicht die Verwendung mehrerer Template-Container. Wenn Template-Dateien oder Include-Dateien mit demselben Namen in verschiedenen Template-Containern existieren, wird nur die Datei im ersten Container berücksichtigt und die anderen ignoriert. Entwickler einer JETbasierten Anwendung können diesen Mechanismus verwenden um allgemein Include-Dateien zur Verfügung zu stellen, welche die ursprünglichen überladen, ohne die ursprüngliche Include- Datei zu verändern. Scriptlets können Java Code ausführen und werden zur Aufruf-Zeit des Templates ausgeführt. Durch Scriptlets können Seiteneffekte auftreten, zum Beispiel in dem Sie Objekte verändern. Im Folgenden ist ein einfaches Beispiel für ein Scriptlet zu sehen. <% if (Calendar.getInstance().get(Calendar.AM_PM) == Calendar.AM) {%> Guten Morgen <% } else { %> Morgen <% } %> Eine JET Expression entspricht einer Java Expression. Das Ergebnis der Expression wird an den Return-Wert der generate-methode angehängt, falls dies nicht möglich ist, wird zur Übersetzungs-Zeit ein Fehler geworfen. Expressions werden zur Template-Aufruf-Zeit ausgewertet. Wie Scriptlets erlauben auch Expressions Seiteneffekte, zum Beispiel das Verändern eines Objektes. Im Folgenden Beispiel wird das aktuelle Datum an den StringBuffer der generate-methode gehängt. <%= (new java.util.date()).tolocalestring() %> Wie bereits erwähnt unterstützt JET nur einen Teil der JSP Syntax, so sind zum Beispiel weder Tags für Deklarationen noch für Kommentare verfügbar. JET befindet sich im org.eclipse.emf.codegen Plugin und läuft nur in der Eclipse Umgebung. Zusätzlich zu JET enthält das EMF Projekt die Template-Sprache JMerge (Java Merge). JMerge führt generierten Code und die existierenden Version der Datei zusammen. Dies geschieht anhand Reguläre Ausdrücke, welche in einer XML-Datei spezifiziert werden.

13 EMF 13 Abbildung 7: Übersetzung und Generierung [Schmauder]

14 14 EMF 2.7 Projekte im Kontext von EMF GEF Das Graphical Editing Framework ist ein Open Source Framework zur Unterstützt die Erstellung grafischer Editoren für die Bearbeitung von Modellen. Es ist vollkommen anwendungsunabhängig und kann zum Beispiel sowohl für die Erstellung eines SWT-Designers, eines HTML- Editors als auch für UML-Modellierungswerkzeuge verwendet werden. Der Haupteinsatzzweck von GEF ist allerdings die Erstellung von Diagramm-Editoren auf Basis von EMF. GEF definiert eine Architektur gemäß dem MVC-Pattern. Das Modell enthält den Zustand des Diagramms. Als Modell kann jede beliebige Datenstruktur verwendet werden. Allerdings hat der Einsatz von EMF wesentliche Vorteile. So kann der Entwickler aus einem EMF-Modell (Metamodell) automatisch die Java-Klassen für das Modell des Editors erstellen und erspart sich somit sehr viel Programmieraufwand. Diese Klassen repräsentieren zum einen das Modell und zum anderen sind sie für die Persistenz des Modells zuständig. Wenn sich das Metamodell während der Entwicklung verändert, können die Java-Klassen neu generiert werden, die Anpassungen für die grafische Darstellung bleiben erhalten. Außerdem werden diese Änderungen am Modell automatisch durch den EMF Notification Mechanismus weitergeleitet. Dies sorgt dafür, dass die View und das Modell immer konsistent sind. Abbildung 8: MVC und GEF Im Unterschied zu EMF bietet GEF keine Code-Generierung. GEF ist nur ein MVC- Framework aus dem sich der Entwickler bedienen kann. Der Controller - EditPart genannt - leitet Änderungen der View direkt an das Modell und Änderungen am Modell an die View weiter. Beispielsweise hat das Entfernen eines Objekts im grafischen Editor sofort Auswirkungen auf das Modell, anschließend sendet das Modell eine Nachricht an den zugehörigen EditPart, dieser aktualisiert die View des Modells. Jeder EditPart hat eine zugehörige Viewer-Komponente. GEF enthält Viewer-Komponenten - EditPartViewer genannt - für die grafische und baum-basierte Darstellung von Modellen. Der Viewer ist für die Erstellung einer View verantwortlich und umfasst unter anderem standardisierte Operationen für Copy&Paste, Drag&Drop sowie für das Zoomen. Der Entwickler kann diese Viewer überall in Eclipse einbinden.

15 EMF 15 Für die Darstellung der grafischen View wird die API des Frameworks Draw2D verwendet. Draw2D ist eine Erweiterung von SWT und erlaubt es komplexe zusammengesetzte grafische Komponenten zu erstellen. Es unterstützt den Entwickler bei der Erstellung der View. Eine Draw2D GUI besteht aus einem Baum von Figures, dieser Baum wird verwendet um die View zu erstellen. Figures stellen die Bausteine dar, aus denen die View zusammengebaut ist, Draw2D definiert eine Reihe von wieder verwendbaren Figures. Im Gegensatz zur grafischen Darstellung wird für die baumbasierte Darstellung das Draw2D-Framework nicht benötigt, hierfür werden die JFace-Klassen TreeView und TreeItem verwendet GMT GMT ist ein Unterprojekt des Eclipse Universal Tool Plattform Projekts und steht für Generative Model Transformer. Das Ziel des Projektes ist die Entwicklung von Tools für die modellgetriebene Entwicklung und hier insbesondere für die Modelltransformation. Die Tools sind allerdings nicht für den produktiven Einsatz gedacht, sondern sollen vor allem Möglichkeiten aufzeigen, welche Modelle in Zusammenhang mit Eclipse bieten. Das Unterprojekt UMLX ist zum Beispiel eine grafische Darstellungsform für Transformationen und soll in den Standard QVT einfließen. Weitere Unterprojekte sind: - Fuut-je: model-getriebener Quellcode- und Text-Generator für GMT (Prototyp) - UMLX: Syntaxdefinition einer Transformationssprache (orientiert sich an QVT) - ATL (ATLAS Transformation Language): eine Sammlung von Transformations-Tools und eine IDE für die ATLAS Tranformation Language der Université de Nantes. - AMW (ATLAS Model Weaver): Tool zum Modellvergleich und zum Verweben von Gemeinsamkeiten in den Modellen (vgl. Aspektorientierung) UML2 UML2 ist ein Unterprojekt des Eclipse Tools Projects und stellt eine EMF basierte Implementierung des UML 2.0 Metamodells für die Eclipse Plattform dar. UML2 ist derzeit in der Version (RC1) für Eclipse 3.1 RC1 und EMF 2.1 verfügbar. Ziel des UML2 Projekts ist die Bereitstellung einer einfach anzuwendenden Implementierung eines UML 2.0-Metamodells für die Entwicklung von Modellierungswerkzeugen. Zusätzlich soll ein gängiges XMI-Schema zum Austausch von semantischen Modellen unterstützt werden. Laut Projektleiter Kenn Hessey bereitet jedoch die noch nicht fertiggestellte und teils fehlerhafte UML 2.0 Spezifikation Probleme, woraus sich häufige Änderungen der API ergeben. Außerdem führen auch die noch debattierten Erfüllungspunkte für die UML 2.0 zu häufigen Änderungen. Bestandteil des Projekts ist neben der reinen API auch der UML2 Editor. Dieser erlaubt eine einfache Bearbeitung eines UML2-Modells und der Eigenschaften der darin enthaltenen Modellelemente.

16 16 EMF Abbildung 9: UML2-Editor Anhand eines einfachen Beispiels aus dem UML2 Tutorial soll nun gezeigt werden, auf welche Weise ein Modell alternativ auch programmatisch aufgebaut und gespeichert werden kann. Zuerst wird ein Modell über das Singleton UML2 Factory erzeugt: Model model = UML2Factory.eINSTANCE.createModel(); model.setname( UML2_Beispiel ); Innerhalb dieses Modells können (Unter-)Pakete, Klassen, primitive Typen sowie Beziehungen zwischen diesen Elementen hergestellt werden. Nachfolgend ein Beispiel für das Erzeugen eines Pakets sowie einer darin enthaltenen Klasse. Zuerst wird das Paket erstellt. Als Root-Package wird in diesem Fall das Modell angegeben. org.eclipse.uml2.package package_; package_ = (org.eclipse.uml2.package) model.createownedmember( UML2Package.eINSTANCE.getPackage()); package_.setname("beispiel"); Als nächstes werden in diesem Paket zwei Klassen Person und Kunde erzeugt. Zwischen den beiden Klassen wird eine Vererbungsbeziehung definiert, wobei Person als abstrakte Basisklasse von Kunde fungiert. org.eclipse.uml2.class class_; class_ = (org.eclipse.uml2.class) package_.createownedmember(uml2package.einstance.getclass_()); class_.setname("person"); class_.setisabstract(true);

17 EMF 17 org.eclipse.uml2.class subclass; subclass = (org.eclipse.uml2.class) package_.createownedmember(uml2package.einstance.getclass_()); subclass.setname("kunde"); subclass.setisabstract(false); Generalization general = subclass.creategeneralization(class_); Abschließend wird das auf diese Weise erzeugte Modell als XMI in einer Datei gespeichert. String filename="beispiel"; URI uri = URI.createURI(filename+UML2Resource.FILE_EXTENSION); Resource resource = new ResourceSetImpl().createResource(uri); resource.getcontents().add(model); try { resource.save(null); } catch (IOException e) { e.printstacktrace(); } Ein vollständiges Beispiel kann bei eclipse.org unter folgendem Link herunter geladen werden: GMF Das Graphical Modeling Framework ist ein Unterprojekt des Eclipse Technology Project und befindet sich derzeit in der Validierungsphase des Eclipse-Entwicklungsprozesses. Hintergrund des Open-Source-Projekts ist die Idee, die zwei erfolgreichen Eclipse-Projekte Eclipse Modeling Framework und Graphical Editing Framework miteinander zu verbinden. Diese beiden Projekte werden häufig für die Erstellung Domänen-spezifischer Modelle verwendet. Hieraus sind verschiedene Techniken entstanden, EMF und GEF hierfür zu kombinieren. Ziel des GMF-Projektes ist es, über eine generative Infrastruktur bereitzustellen, welche die Erstellung von Modellierungswerkzeugen für Eclipse erleichtert. GMF soll die grundlegende Infrastruktur und Komponenten für die Entwicklung und das optische Design von Modellierungswerkzeugen unter Eclipse zur Verfügung stellen. Im Kern ist GMF als eine generative Brücke zwischen EMF und GEF entworfen und soll auf diese Weise die Abhängigkeiten zwischen EMF und GEF verringern. Über einen generativen Ansatz soll das Framework die Bereitstellung von Diagramm-Elementen und Funktionalitäten für den Fall unterstützen, dass für eine spezifische Domäne ein grafischer Editor gewünscht wird. Voraussetzung hierfür ist ein auf EMF basierendes Domänenspezifisches Modell. Die Idee hinter GMF stellt in vielerlei Hinsicht eine Erweiterung der Funktionalität von EMF dar und beinhaltet folgende Komponenten:

18 18 EMF Diagramming Infrastructure Inhalt der Diagramming Infrastructure soll eine Sammlung von Komponenten zur Erstellung von Diagrammen sein. Hierbei ist an die Unterstützung von Diagramm-Elemementen wie Knoten, Kanten und Verbindungen gedacht, aber ebenso an Tools, spezielle Views, Editoren und Navigatoren. Die Diagramming Infrastructure stellt die Zielumgebung der Generierungskomponente von GMF dar. Diagram Generation Framework Basierend auf Diagramm-Definitionen und den entsprechenden Domänen-Modellen sollen über das Diagram Generation Framework Diagramm-Komponenten beziehungsweise -Elemente generiert werden, die zur Erstellung von Anwendungen für die visuelle Modellierung verwendet werden können. Die Definition dieser Diagramme soll über eine Oberfläche erfolgen, die selbst mit GMF erstellt wurde. Exemplary Modeling Tools Im Rahmen des Projekts ist geplant, die Möglichkeiten des Graphical Modeling Frameworks über eine Reihe von Modellierungswerkzeugen zu demonstrieren, die mit Hilfe des Frameworks erstellt wurden. Nachfolgende Grafik gibt einen Überblick über die konzeptionellen Zusammenhänge des Frameworks. Abbildung 10: Zusammenspiel von EMF und GEF im GMF Das Projekt wird derzeit hauptsächlich von Borland vorangetrieben. Laut Borland bestehen die nächsten Schritte im Projekt (Stand April 2005) in der Festlegung der Anforderungen, der Architektur und des weiterführenden Projektplans. Zusätzlich ist eine Untersuchung der verschiedenen existierenden Lösungsansätze erforderlich. Für die Definition des Diagramm-Metamodells wird die UML 2.0 Diagram Interchange Specification ( als mögliche Basis geprüft.

19 3 EMF vs. MDA You can think of EMF as MDA in braining wheels. (Erich Gamma, 2004) Dieses Kapitel vergleicht die wesentlichen Konzepte von EMF und MDA und leitet über zu einer kritischen Betrachtung der Ansätze in Eclipse. 3.1 Schichtenmodell Als grundsätzliche Gemeinsamkeit der beiden Ansätze kann die Einteilung in vier vergleichbare Schichten genannt werden. Die folgende Abbildung zeigt die Einordnung der Eclipse-Begriffe in den MDA-Kontext. M3 Meta-Meta-Modell Ecore M2 Meta-Modell Ecore Model M1 Modell EMF Model M0 Modell-Instanz Ecore Object Abbildung 11: Schichtenmodell bei MOF und Ecore Hierbei ist zu beachten, dass EMF derzeit nur Klassendiagramme und nicht das komplette UML- Metamodell abbildet. Wie MOF kann auch Ecore dazu verwendet werden, neben UML noch andere Modellierungsprachen zu beschreiben. Eclipse implementiert bereits Metamodelle für Java und XML-Schema. 3.2 MOF vs. Ecore MOF und Ecore wurden parallel entwickelt, haben sich aber gegenseitig beeinflusst. Trotzdem unterscheidet sich Ecore von MOF in einigen Gebieten. MOF 2.0 besteht aus zwei verschiedenen Metamodellen Essential MOF (EMOF) und Complete MOF (CMOF). EMOF ist eine Un-

20 20 EMF vs. MDA termenge von CMOF. Ecore orientiert sich in großen Teilen an EMOF. In den meisten Fällen ist es möglich ein EMOF-basiertes Metamodell nach EMF zu importieren. Dabei ist EMF in der Lage das EMOF-Metamodell nach Ecore zu transformieren. Allerdings gibt es einige Unterschiede, welche zu beachten sind. So fokussiert sich Ecore im Gegensatz zu MOF nicht auf Meta-Daten-Repositories sondern auf die Integration von Tools in Eclipse. Die Metamodelle Ecore und MOF unterscheiden außer in der Namensgebung der Klassen in den Bereichen Datentypen-Strukturen, Packet-Beziehungen und komplexe Beziehungen. Zum Beispiel unterstützt Ecore nur binäre und keine höherwertigen Assoziationen. Assoziationen werden immer auf ein Paar von Ecore Referenzen abgebildet. Zusammengefasst kann Ecore als vereinfachtes MOF-Modell bezeichnet werden. 3.3 XMI EMF verwendet für die Serialisierung von Modellen und Metamodellen Ecore XMI. Dieses entspricht dem XMI 2.0 Standard. Da Ecore und MOF verschieden sind, muss EMF das Ecore- Modell nach MOF abbilden, damit das Ecore-Modell XMI 2.0 konform ist. Zu beachten ist hier, dass der XMI 2.0 Standard MOF 1.x nach XML abbildet und nicht MOF 2.0. Für MOF 2.0 ist das Mapping in XMI 2.1 definiert. Der Grund für diese unglückliche Namensgebung, liegt darin begründet, dass die OMG an MOF 2.0 noch nicht gedacht hat, als XMI 2.0 spezifiziert wurde. Langfristig hat EMF zum Ziel jedes mit einem UML-Tool erstellte Metamodell importieren zu können. 3.4 EMF vs. JMI Wie Ecore ist auch das Java Mapping von EMF für die Tool-Integration optimiert. Obwohl das Java Mapping von EMF und JMI ähnlich sind, unterscheiden sich beide vor allem in Bezug auf ihre Interfaces von einander. Da das Java-Mapping für Eclipse sehr ausgereift ist, wird sich daran wahrscheinlich auch nichts ändern. Deshalb müssen Tool-Hersteller, welche sich auf JMI konzentriert haben, ihre Tools für die Integration mit EMF an dessen Java-Mapping anpassen. 3.5 Constraint Language Da EMF keine Contraint Language (z.b. OCL) unterstützt, müssen Entwickler Einschränkungen nachträglich in den Code einfügen. Allerdings hat die Eclipse Community ein Plugin für EMF entwickelt, welches erlaubt OCL in EMF-Modellen zu verwenden. [Kent]. Diese OCL- Implementierung ist jedoch bisher kein offizielles Eclipse Projekt. Das in der Eclipse Version 3.1 integrierte EMF Validation Framework erlaubt die Definition von Invarianten und Named Constraints in Ecore-basierten Modellen. Diese können innerhalb des UML-Diagramms oder mittels eines XML-Schemas definiert werden. Anhand dieser Definition kann der Code für die Validierung der Modellinstanzen generiert werden.

21 3.6 Persistenz EMF speichert die Metadaten in XMI-Dateien und nicht in einer Datenbank. Für die Integration von Tools in Eclipse ist dies auch ausreichend. Allerdings benötigen große Firmen für das Metadaten-Management andere oder zusätzliche Persistenz-Mechanismen. Da EMF auf dem Plugin- Mechanismen von Eclipse basiert, ist es theoretisch möglich alternative Persistenz-Mechanismen einzubinden. Derartige Implementierungen sind derzeit nicht vorhanden.

22 22 Fazit und Ausblick 4 Fazit und Ausblick Wie bereits erwähnt basieren sehr viele ausgereifte Werkzeuge nicht nur für die modellgetriebene Entwicklung - auf EMF. So basiert die IBM Produktfamilien Websphere und Rational Rose/XDE auf EMF. Neben Eclipse und den bereits erwähnten Projekten sind hier insbesondere noch XSD und Hyades zu erwähnen. XSD ist ein Modell für die Arbeit mit XML Schema und Hyades eine Plattform für die Integration von Test-, Profiling-, Debug- und Trace-Werkzeugen. Eine wesentliche Eigenschaft von EMF wird in den genannten Anwendungen deutlich. EMF ist sehr gut dazu geeignet, die Metadaten eines Tools bzw. Entwicklungswerkzeugs zu modellieren und hieraus den Code zu generieren, welcher diese Metadaten verwaltet. Die von EMF generierten Java APIs und Interfaces sind zudem an keine verteilte Middleware gebunden. Eine Unterstützung von CORBA oder EJB ist nicht vorhanden. Hinzu kommt die relativ primitive Persistenz für die Speicherung von Modell-Instanzen. Daher kommt David Frankel in [Frankel 2000, S. 2] zu seiner Bewertung: EMF ist nicht geeignet für Geschäftsanwendungen. Grundsätzlich bleibt aber auch im Vergleich mit MDA der EMF-Ansatz zurück. MDA beschäftigt sich im Gegensatz zu EMF mit vielen Themen rund um die modellgetriebene Entwicklung. Dazu gehören auch Austauschformate, Integration mit verschiedenen Middleware Sprachen, Daten und Anwendungsintegration, Best Practices, Modelltransformationen und Metadaten- Management. EMF unterstützt zwar die Kern-Konzepte von MDA, konzentriert sich allerdings auf die Codegenerierung und die Serialisierung für den Datenaustausch zwischen Tools. Für die Zukunft wird sich EMF mit seinen Unterprojekten weiter auf MDA zu bewegen. So ist unter anderem eine OCL-Unterstützung zur Modell-Validierung und ein generisches Framework zur Transformation der Modelle vergleichbar mit QVT geplant.

23 Literaturverzeichnis Budinsky, F. [u.a.]. Eclipse Modeling Framework. Pearson Education, Inc., Boston, MA, Eclipse Modeling Framework (EMF): Graphical Editing Framework (GEF): Graphical Modeling Framework (GMF): Generative Model Transformer (GMT): Gronback, R.C. Graphical Modeling Framwork (GMF) Creation Review. Borland Software Corp., , Kent OCL library, 2004: Lall, A. Malinowski, M. Murtaza Qureshi, K. Solaiappan. UML Virtual Machine. Computer Science Department, University of Massachusetts Boston, Moore, B. [u.a.]: Eclipse Development Using the GEF and the EMF Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework, IBM Redbooks, Popma, R. JET Tutorial: Schmauder, R. u. Schill, P. Codegenerierung mit dem Eclipse Modeling Framework und JET. Objekt- Spektrum, Sigs-Datacom, 01, UML2: UML 2.0 Superstructure Specification: UML 2.0 Diagram Interchange Specification:

24 24 Fazit und Ausblick UMLX: Abbildungsverzeichnis Abbildung 1: EMF Modell verbindet XML, UML und Java [Gamma]... 5 Abbildung 2: Ausschnitt aus Ecore... 6 Abbildung 3: Generator-Modell und Ecore-Modell... 8 Abbildung 4: Definition eines EMF-Modells in Rational Rose und in Java Abbildung 5: Bearbeiten einer EMF-Modellinstanz Abbildung 6: JET Template Tags Abbildung 7: Übersetzung und Generierung [Schmauder] Abbildung 8: MVC und GEF Abbildung 9: UML2-Editor Abbildung 10: Zusammenspiel von EMF und GEF im GMF Abbildung 11: Vier Schichten Abbildung 12: Ecore Abbildung 13: Ecore Hierarchie Abbildung 14: Operationen von EObject Abbildung 15: Externe Typen Abbildung 16: Java-Typen... 28

25 Anhang Abbildung 12: Ecore

26 26 Fazit und Ausblick Abbildung 13: Ecore Hierarchie

27 Abbildung 14: Operationen von EObject

28 28 Fazit und Ausblick Abbildung 15: Externe Typen Abbildung 16: Java-Typen