EMF - Eclipse Modeling Framework Seminararbeit im Seminar Information Systems Engineering

EMF - Eclipse Modeling Framework Seminararbeit im Seminar Information Systems Engineering Roman Engelmann Fachhochule Aachen, Fachbereich Elektrotechnik und Informationstechnik, Eupener Straße 70, 52066 Aachen, Germany http://www.fh-aachen.de Abstract. Bei der Modellgetriebenen Softwareentwicklung verspricht man sich durch die automatische Codegenerierung eine Produktivitätssteigerung und vor allem eine bessere Qualität und Wartbarkeit der Software. Im Java Umfeld steht hierfür das Eclipse Modeling Framework (EMF) zur Verfügung. Die Arbeit geht im Wesentlichen auf den Aufbau des Frameworks ein und stellt den damit verbundenem Workflow im Softwareentwicklungs-Prozess vor. EMF stellt sich dabei als ein mächtiges Werkzeug dar, welches es erlaubt, mit wenig Aufwand modellgetriebene Softwareentwicklung zu realisieren. 1 Einführung In der modellgetriebenen Softwareentwicklung steht im Zentrum das Modell, welches einen Ausschnitt aus der Realität beschreibt. Reale Prozessabläufe sind im Allgemeinen durch hohe Komplexität geprägt. Da meistens nicht alle Aspekte relevant sind, ist die Modellbildung durch eine Reduktion beziehungsweise Abstraktion der beobachteten Abläufe charakterisiert. In der Softwareentwicklung dienen Modelle häufig der Dokumentation komplexer Prozessabläufe oder komplexer Datenstrukturen. Modelle können aber auch direkt als Metadaten in die Software integriert werden, wie diese Ausarbeitung am Beispiel von EMF verdeutlichen wird. Das Eclipse Modelling Framework (EMF) ist ein mächtiges und zudem ein Open Source verfügbares Framework, das auf der Basis von strukturierten Modellen Java-Programmcode erzeugen kann. Entwickelt um das Modellieren für Java Programmierer einfach zugänglich zu machen, vereint es die drei wichtigen Technologien: Java, XML und UML. Modelle können somit mittels einem UML Diagramm, einem XML Schema oder sogar mittels einfachen Annotations in Java- Interfaces definiert werden. Im letzten Fall braucht der Entwickler lediglich die Interfaces des Modells zu implementieren und der Rest wird automatisch generiert. Das ursprüngliche Ziel von EMF war die Implementierung der Meta Object Facility[2] (MOF). Die MOF Spezifikation ist ein Framework und eine abstrakte Sprache zur Erstellung und Verwaltung von Metamodellen sowie der persistenten

2 EMF - Eclipse Modeling Framework Speicherung und den Austausch von Modellen zwischen verschiedenen Systemen. Im Laufe der Entwicklung hat sich das hat sich das aber als zu komplex herausgestellt. Somit ist EMF eine Spezialisierung von MOF, die, für die speziellen Bedürfnisse der Programmiersprache Java angepasst wurde. D.h. EMF ist als Implementierung einer Teilmenge von MOF anzusehen, die auch Essential MOF (EMOF) bezeichnet wird [1]. Entwickelt wurde EMF durch die Eclipse Foundation [5]. Dabei handelt es sich um eine not-for-profit Organisation, die durch IBM im Jahre 2001 ins Leben gerufen wurde. Im Jahre 2004 folgte dann die Reorganisation zur einer echten Open Source Gemeinde. Die Eclipse Foundation ist durch das Eclipse Framework bekannt geworden. Durch die Plug-In-Architektur ist Eclipse eine flexible und mächtige Programmierumgebung, die mittlerweile für praktisch alle gängigen Programmiersprachen genutzt werden kann. Eclipse und auch alle Plug-Ins sind in Java implementiert und können somit Plattformunabhängig betrieben werden. Mit Hilfe von EMF ist es möglich, aus den definierten Modellen Plug-Ins für Eclipse zu erzeugen. Diese ermöglichen es z.b. die Modelle über einen graphischen Editor anzulegen und zu bearbeiten. Dadurch, das die EMF-API sehr flexible und performant arbeitet und zudem viele Aufgaben, wie z.b. die Validierung und Persistierung der Modelle sowie die automatische Änderungs- Erkennung/Benachrichtigung(Change notification) übernimmt, hat sich das Framework mittlerweile auf dem Markt stark etabliert. Viele führenden Modellierungstool Anbieter wie Borland und IBM haben ihre Produkte basierend auf EMF entwickelt [3]. Ziel der Arbeit ist es die Mächtigkeit und den Nutzen, den EMF in dem Softwareentwicklungs-Prozess einbringt, vorzustellen. Hierfür wird in Kapitel 2 zuerst auf die einzelnen Komponenten von EMF eingegangen. Zudem wird Ecore, das Metamodell des EMF beschrieben. Im Kapitel 3 wird das Generatormodell vorgestellt, welches für die automatische Codegenerierung zuständig ist. Kapitel 4 geht auf den typischen Workflow in Zusammenhang mit EMF ein und erläutert zudem die Arbeit mit EMF unter Eclipse. Außerdem werden weitere Projekte vorgestellt, die auf EMF basieren. Die Arbeit endet mit dem Kapitel 5, in dem eine Zusammenfassung zu EMF gegeben wird. 2 Eclipse Modeling Framework In diesem Kapitel wird die Architektur des EMF Frameworks vorgestellt. Dabei werden die einzelnen Komponenten und deren Funktion vorgestellt und erläutert. Anhand eines Beispiels soll zuletzt verdeutlicht werden, wann EMF eingesetzt werden kann. EMF ist eine Teilmenge des Model-Driven-Architecture (MDA) [15] Anstazes. MDA ist ein von der OMG vorgeschlagener Ansatz für die Industrie zur modellgetriebenen und generativen Software-Entwicklung. Dabei sieht der Ansatz vor, dass anhand von Modellen, die auf unterschiedlichen Abstraktions-Ebenen definiert werden, eine komplette und lauffähige Applikation generiert wird. Die

EMF - Eclipse Modeling Framework 3 unterschiedlichen Abstraktions-Ebenen sind dafür notwendig, damit die Applikation komplett Sprachen- und Plattform-unabhängig erzeugt werden kann. EMF ist insofern als eine Teilmenge von MDA anzusehen, da es das MDA Schlüssel-Konzept (Modell als Input für die Entwicklung) unterstützt, es aber jedoch auf die Programmiersprache Java begrenzt. Das EMF baut auf der Eclipse Plattform auf und besteht im Wesentlichen aus den zwei grundlegenden Teilen der EMF Runtime und den EMF Tools. Die EMF Runtime ist dabei der Kern des Frameworks und die EMF Tools sind z.b. für die automatische Generierung von Editoren zuständig. EMF ist dabei nicht so Umfangreich wie z.b. die Microsoft DSL Tools und konzentriert sich hauptsächlich auf die Definition von Modellen und auf die Codegenerierung. Wenn es z.b. darum geht, aus dem Modell mit Hilfe von Templates eigenen Code zu generieren oder das Modell in einem graphischen Editor auf eine bestimmte Art und Weise (z.b. bestimmte Figuren oder Icons) anzuzeigen, muss das Framework mit Hilfe von Plug-Ins, die in den nächsten Abschnitten beschrieben werden, erweitert werden. Für die Erstellung von graphischen Editoren, die es erlauben, Instanzen von dem definierten EMF Modell anzulegen und zu bearbeiten, gibt es hier das Graphical Editing Framework (GEF) und das Graphical Modeling Framework (GMF) [16]. Mit diesen beiden Plug-Ins, die auch zu dem Eclipse Modeling Project gehören, können anspruchsvolle graphische Editoren erstellt werden. Das darunter liegende Datenmodell kann somit auf beliebige Art und Weise dargestellt werden. Dadurch, dass die Plug-Ins bereits viele Funktionen (z.b. verschiedene Werkzeug-Paletten, Undo/Redo Support, verschiedene vordefinierte Views) mitliefern, können anspruchsvolle Editoren nach kurzer Einarbeitungszeit erstellt werden. Das JET Framework [17] ist eine model-to-text Engine, welche es erlaubt, mit Hilfe von Templates aus einem EMF-Modell bestimmte Texte zu generieren. JET benutzt dabei eine Template-Technologie, die ähnlich zu der Syntax von Java Server Pages (JSPs) ist. Mit dem Framework ist man dann in der Lage aus dem angelegten Modell Java, XML, Text oder HTML Dateien zu erzeugen. Insgesamt umfasst das Eclipse Modeling Project viele verschiedene Frameworks, die das EMF erweitern. Dadurch kann das EMF im sehr breiten Spektrum eingesetzt werden. In der Abbildung 1 ist die Architektur des Frameworks dargestellt. Die einzelnen Elemente von der EMF Runtime und den EMF Tools sind[6]: EMF - Der Kern des EMF Frameworks enthält ein Meta-Modell (Ecore), welches für die Beschreibung des Modells und für die Bereitstellung verschiedener Support-Funktionen für das Modell zuständig ist. Diese sind z.b. die Änderungs-Erkennung/Benachrichtigung(Change notification), die Persistierung und eine sehr effiziente Reflection-API, die es erlaubt, die EMF Objekte generisch zu manipulieren. EMF.Edit - Das EMF.Edit Framework umfasst generische wiederverwendbare Klassen für den Aufbau von Editoren zur Bearbeitung von Instanzen

4 EMF - Eclipse Modeling Framework Fig. 1. Die EMF Architektur [8] des Modells. Es beinhaltet alle notwendigen Klassen, die es erlauben, EMF- Modelle auf Standard Desktop-Dialogen(JFace Viewers) oder Editoren anzuzeigen. Zudem enthält es auch das Command Framework. Dieses beinhaltet viele generische Klassen, die es erlauben einen Editor zu erstellen, der z.b. automatisch die Undo/Redo-Funktionen unterstützt. EMF.Codegen - Die EMF Code-Generierungs-Einheit ist in der Lage alles Notwendige zu generieren, um einen kompletten Basis-Editor für das EMF Modell zu implementieren. Über eine GUI können die Generierung-Optionen verändert und Generatoren gestartet werden. Diese Einheit baut auf der JDT (Java Development Tools) Komponente von Eclipse auf. Um zu verstehen was EMF ist und wann es eingesetzt werden kann, soll ein kleines Java Beispiel (Listing 1) gegeben werden. Es soll ein Programm entwickelt werden, welches die Bestellungen für eine Geschäftsstelle oder einen Lieferanten verwaltet. Anhand der Spezifikation weiß der Entwickler, dass eine Bestellung (purchase order) eine Rechnungs- und Lieferadresse sowie die einzelnen Artikel (item) enthält. Dabei besteht ein Artikel aus einem Name, der Menge und dem Preis. Ohne lange nachzudenken implementiert der Entwickler die folgenden Interfaces: public interface PurchaseOrder { String getshipto(); void setshipto(string value); String getbillto(); void setbillto(string value); List getitems(); // List of Item } public interface Item { String getproductname(); void setproductname(string value);

EMF - Eclipse Modeling Framework 5 } int getquantity(); void setquantity(int value); float getprice(); void setprice(float value); Listing 1 - Interfaces PurchaseOrder und Item Mit den implementierten Interfaces ist der Entwickler in der Lage die restlichen Aufgaben wie die GUI und Persistierung anzugehen. Davor wird er jedoch vom Chef gebeten, zuerst das Modell für die Problemstellung zu erstellen. Wie die meisten Entwickler, fragt sich dieser, welchen Mehrwert ein formal definiertes Modell gegenüber dem bereits erstellten Modell auf Code-Ebene (Java Interfaces) bringen soll. Das Klassendiagram wird doch lediglich die Seiten der Dokumentation ausfüllen, aber keinen weiteren Nutzen zufügen denkt sich der Entwickler. Um den Chef jedoch zufrieden zu stellen, erstellt er das in der Abbildung 1 dargestellte Klassendiagramm. Fig. 2. UML Diagramm Nach dem der Entwickler wieder seine Ruhe hatte, konnte er sich auf die nächste wichtige Aufgabe, die Persistierung, konzentrieren. Damit das erstellte Modell gespeichert und auch mit anderen Programmen oder Mitarbeitern ausgetauscht werden kann, muss der Entwickler ein Speicherformat und ein Austauschformat definieren. Hierfür ist das XML Format gut geeignet, da es sehr verbreitet ist. Da sich der Entwickler mit dem XML- Format gut auskennt, entwirft er direkt das folgende XML-Schema. <?xml version="1.0" encoding="utf-8"?>... <xsd:complextype name="purchaseorder"> <xsd:sequence> <xsd:element name="shipto" type="xsd:string"/> <xsd:element name="billto" type="xsd:string"/> <xsd:element name="items" type="po:item" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="item">... </xsd:complextype> </xsd:schema> Listing 2 - XML Schema PurchaseOrder und Item

6 EMF - Eclipse Modeling Framework An dieser Stelle wird dem Entwickler bewusst, dass er jetzt insgesamt drei verschiedene Darstellungen für ein und dasselbe Datenmodell erstellt hat. Damit diese drei Darstellungen (Java Interfaces, UML Klassendiagram und XML-Datei) immer konsistent bleiben, muss ein großer Aufwand investiert werden. Denn ändert der Entwickler an einer Repräsentation des Modells ein Detail (z.b. in den Java-Interfaces), muss das UML- Diagramm sowie das XML-Schema angepasst oder neu erzeugt werden. Genau hier kommt EMF zum Einsatz. EMF ist ein mächtiges Framework und Code- Generierung-Tool, welches es erlaubt, in einer von den drei Darstellungsformen das Modell zu erstellen und die anderen daraus automatisch zu generieren. Die Abbildung 3 zeigt, wie EMF die drei wichtigen Technologien Java, XML und UML vereint. Unabhängig davon, welche Form für die Definierung gewählt wurde, ist das EMF Modell eine Gemeinsame Darstellung die alles zusammenklebt. Fig. 3. EMF vereint Java, XML, und UML Die Synchronisation wird bei einer Änderung automatisch von EMF in allen Modellrepräsentationen durchgeführt. Durch den Notify-Mechanismus werden alle anderen Repräsentationen des Modells benachrichtigt, sobald eine Änderung stattgefunden hat. Grundsätzlich wird bei einer Änderung immer zuerst das EMF-Modell aktualisiert und daraus die beiden anderen Repräsentationen erzeugt. Alle EMF-Modelle haben eins gemeinsam: sie sind eine Instanz des Ecore Metamodells. Im Kapitel 2.1 werden der Aufbau des EMF Metamodells und die Beziehungen zwischen den einzelnen Metamodellelementen erläutert. 2.1 Das Ecore Metamodell Das Ecore Metamodell definiert die Struktur von Objekten in einem Ecore Modell. Dabei ist das Ecore Metamodell selbst ein Ecore Modell. Es wird als Metamodell bezeichnet, weil man mit diesem Modell in der Lage ist, andere Modelle zu beschreiben und zu repräsentieren. Wie im Kapitel 1 schon beschrieben, hat EMF seine Wurzeln in MOF und UML. Die Datentypen und Konstrukte sind stark an Java angelehnt. Die meisten Modellierung Konzepte, die das Ecore zur Verfügung stellt, bauen daher auf Klassen und deren Beziehungen auf. Folglich sollte ein Objektorientierter Entwickler keine große Mühe haben, mit EMF, seine Modelle zu definieren. Die Abbildung 4 stellt eine Teilmenge von Ecore (den sogenannten Kernel) dar. Die im Diagramm zu sehenden Entitäten sind: EClass: wird verwendet, um eine beliebige Klasse zu repräsentieren. Sie hat einen Namen sowie eine unbestimmte Anzahl von Attributen und Referenzen.

EMF - Eclipse Modeling Framework 7 Fig. 4. Ecore Kernel [3, S.124] EAttribute: repräsentiert ein Attribut der Klasse. Dieser besteht aus einem Namen und einem Typ. EReference: wird verwendet, um ein Assoziationsende zwischen Klassen zu bezeichnen. Es besteht aus einen Namen, ein Flag, ob es sich um eine Einschlussbeziehung handelt (in UML als black diamond an einem Assoziationsende ausgedrückt), und einen Referenztyp, der auf eine Klasse zeigt. EDataType: beschreibt den Typ eines Attributs. Dieser kann ein primitiver Typ, ein Java-Objekt oder ein Array sein. Mit diesen vier Entitäten ist man in der Lage, sein Modell als ein Ecore-Modell zu repräsentieren. Durch die Tatsache, dass die Ecore auch Konstrukte wie die Assoziation (mittels bidirektionalen Referenzen), Mehrfachvererbung und abstrakte Klassen unterstützt, können auch komplexe Modelle abgebildet werden. Mit dem so erzeugten Ecore-Modell, lässt sich die EMF-Infrastruktur nutzen, um Code oder Modell-Editoren automatisch zu generieren. Mit Hilfe des erzeugten Editors ist eine Basis zur Erstellung eigener Editoren geschaffen. Zuvor sei noch erläutert, wie man EMF-Modelle erzeugen kann. Ecore-Modelle lassen sich auf unterschiedliche Weise erzeugen: Man kann das Ecore-Modell direkt mit einem geeigneten Editor erstellen. Dabei stellt das EMF zwei unterschiedliche Editoren zur Verfügung. Der erste ist ein Strukturbaum-basierter Editor, der eine gewisse Erfahrung mit dem Ecore-Metamodell voraussetzt. Der letztere ist ein auf der UML Notation aufgesetzter Editor, der das Modellieren für Objektorientierte Entwickler stark vereinfacht (siehe Abbildung 6). Mit dem EMF-Projekt- und EMF-Model-Wizard kann man aus UML-Diagrammen ein Modell importieren und daraus ein Ecore-Modell generieren. Das Modell kann aus Java-Interfaces erstellt werden, die mit Modellierungseigenschaften annotiert sind. Die verschiedenen Java-Annotations wie das @model Annotation teilt dem EMF-Codegenerator, welches Objekte und Attribute modellrelevant sind. Das ist der einfachste Weg, da man weder ein spezielles Tool noch Kenntnisse der UML oder XML benötigt. 2.2 Die Persistierung Für die Persistierung der Ecore-Modelle setzt EMF das XMI (XML Metadata Interchange) Format [9] ein. Dabei handelt es bei diesem Format um einen OMG-Standard

8 EMF - Eclipse Modeling Framework zur Serialisierung und zum Austausch von Metadaten, das z.b. von vielen UML-Tools zum Exportieren und Importieren von UML-Modelle eingesetzt wird. Der Vorteil von diesem Format ist, dass nur die notwendigen Modell-Informationen gespeichert werden. Zudem ist EMF auch in der Lage, das Modell in einem XML-Schema zu speichern oder eine selbst implementierte Serialisierung/Deserialisierung zu nutzen. 2.3 Notifier Framework Die Ecore stellt auch ein Notifier Framework zur Verfügung, sodass jede EMF-Klasse grundsätzlich über einen Notifier verfügt. Dieser versendet Benachrichtigungen an die Adapter, sobald sich ein Attribut oder eine Referenz geändert hat. Ein Adapter agiert wie ein Listener, der sich zuvor bei dem Objekt, für das es sich interessiert, anbindet. Sobald z.b. ein Attribut einer Klasse verändert wird, ruft der Notifier der EMF-Klasse die notifychanged() Methode des Adapters auf. 3 Das Generatormodell Nachdem in dem vorherigen Kapitel erläutert wurde, wie man mit Hilfe des Ecore Metamodells eigene EMF-Modelle erzeugen kann, wird in diesem Kapitel das Generatormodell von EMF vorgestellt. Neben dem Aufbau des Generatormodells, wird auch die Notwendigkeit eines zusätzlichen Modells für die Codegenerierung erklärt. Das Generatormodell generiert anhand der EMF-Modelle automatisch den Code. Für die Codegenerierung sind nahezu alle Quell-Informationen in dem Ecore-Modell (Dateiendung.ecore) enthalten. Dieses umfasst die Klassennamen, Attribute, Datentypen und die Referenzen. Für die Generierung werden jedoch noch weitere Informationen, wie der Speicherort, die Präfixe für die Dateinamen oder die Bezeichnung der Packages, benötigt. Da diese Informationen, die der Benutzer setzen kann, Plattformabhängig sind, werden diese in einer separaten Datei (Dateiendung.genmodel) gespeichert. Dabei setzt der EMF Codegenerator auf ein Generatormodell, indem alle Informationen hinterlegt sind. Genau wie beim Ecore-Modell, handelt es sich beim Generatormodell wieder um ein EMF Modell. Das Generatormodell ist wie eine Wrapperklasse, die das Ecore-Modell umhüllt und alle Notwendigen Informationen für Generierung zur Verfügung stellt. Die einzelnen Ecore-Modell Elemente werden dabei durch eigene Generator Klassen abgebildet. So wird aus EClass die GenClass und aus EAttribute und EReference das GenFeature. Durch diese Trennung hat man den Vorteil, dass ein Modell mehrere Codegenerierungen haben kann und die Modellinformationen unabhängig von der Codegenerierung sind. Der Nachteil, nicht alle Informationen in einem Ecore-Modell zu speichern, ist der, dass eine Inkonsistenz zwischen den Modellen entstehen kann. Diese Synchronisation wird allerding vom EMF automatisch durchgeführt, indem das Generatormodell das Ecore-Modell überwacht. Das wichtigste Ziel von dem Codegenierungs-Framework ist, einen sauberen, einfachen und effizienten Code zu generieren. Da EMF als ein leichtgewichtigstes Framework bezeichnet wird, wird bei der Generierung viel Wert darauf gelegt, einen leichtgewichtigen Code für das Modell zu erstellen [3]. Die Idee dabei ist, dass der Code genauso aussieht, als ob dieser per Hand geschrieben worden wäre. Dadurch aber, dass der Code generiert worden ist, kann man davon ausgehen, dass dieser Korrekt ist.

EMF - Eclipse Modeling Framework 9 Fig. 5..genmodel und.ecore Die generierten Klassen Nach dem der Code generiert wurde, wird die Ecore-Klasse (EClass) in Java durch zwei Elemente dargestellt: ein Interface und die entsprechende Implementierungsklasse. Für die EClass PruchaseOrder aus dem Kapitel 2 würde dann das folgende Interface generiert: public interface PurchaseOrder... und die entsprechende Implementierungsklasse: public class PurchaseOrderImpl extends... implements PurchaseOrder { EMF unterstützt somit die Interface/Implementierung-Trennung, die insbesondere bei Modell-APIs oft zum Einsatz kommt, wie z.b. in dem Document Object Model (DOM). Außerdem wird dieses Konzept auch in vielen Eclipse-APIs umgesetzt und ist notwendig für die Implementierung der Mehrfachvererbung in Java. Die Merge Funktion Der EMF Codegenerator ist in der Lage den generierten Code mit handgeschriebenem Code zu erweitern. Somit ist man in der Lage in den generierten Klassen direkt Methoden oder Instanzen von Variablen anzulegen. Bei der erneuten Generierung bleibt der hinzugefügte Code erhalten. Hierfür benutzt EMF den @generated-tag, der generierte Interfaces, Klassen, Methoden usw. markiert. Der Tag wird dabei einfach in das Javadoc eingetragen. Die getshipto() Methode würde z.b. so aussehen: /** * @generated */ public String getshipto() {... Alle anderen Methoden die keinen @generated-tag haben, werden beibehalten. Entsteht ein Konflikt mit einer bereits vorhandener und einer generierten Methode, wird die vorhandene beibehalten und die generierte mit einem Suffix (z.b. getshiptogen) angelegt. Das Codegenerierungs-Framework ist jedoch mächtiger und geht über die Generierung von Java-Klassen hinaus. Es ist möglich, aus dem definierten Modell direkt ein Plugin- In für einen eigenen Modell-Editor generieren zu lassen. Kapitel 4 geht auf diese Funktion näher ein.

10 EMF - Eclipse Modeling Framework 4 Einsatz von EMF Nachdem das Metamodell und das Generatormodell von EMF beschrieben wurden, wird in diesem Kapitel der Softwareentwicklungs-Prozess in Zusammenhang mit EMF als Ganzes vorgestellt. Anhand des vorherigen Beispiels (PurchaseOrder und Item) wird gezeigt, welche Schritte notwendig sind, um aus einem Modell einen Editor zu generieren. Des Weiteren soll die Vorteilhaftigkeit der Integration von EMF in das Eclipse Framework hervorgehoben werden. Zuletzt werden noch einige Projekte vorgestellt, in denen EMF verwendet wird. Der typische Workflow in Zusammenhang mit EMF sieht wie folgt aus: Modellierung - in diesem Schritt wird ein plattformunabhängiges Modell definiert und modelliert. Wie im Kapitel 2 beschrieben, kann das Modell mit Hilfe eines Editors definiert werden oder aus einem UML-Diagramm, XML-Schema oder einem Java-Interface importiert werden. Definiere das Generatormodell - hier werden plattformabhängige Parameter wie die Bezeichnungen der Packages und die Dateinamen definiert. Generiere den Code - in diesem Schritt generiert EMF den Code, die Editoren und die passenden JUnit Tests. Validierung - hier wird mit Hilfe der generierten Editoren das Modell auf die Richtigkeit geprüft. Ergänze den Code- Im vorletzten Schritt wird der generierte Code um eigene Erweiterungen ergänzt. Hier sollten auch die von EMF generierten JUnit Tests implementiert werden. Implementiere den Rest - Im letzten Schritt wird der Rest der Anwendung implementiert. Im Einzelnen wird hier der generierte Editor an die eigenen Anforderungen angepasst und das EMF Datenmodell mit den GUI Komponenten und der Logikschicht verbunden. Anhand des bereits eingeführten Beispiels (Bestellung und Artikel) aus dem Kapitel 2 soll nun die Arbeit mit einem EMF-Modell veranschaulicht werden. Alles was für die modellgetriebene Softwareentwicklung benötigt wird, ist das Eclipse Framework und die EMF-Modellierungs Plug-Ins, die man direkt aus Eclipse installieren kann. Sind die Plug-Ins installiert, ist Eclipse ein vollwertiges Modellierungswerkzeug mit dem alle Aufgaben erledigt werden können. In Abbildung 6 sieht man die Eclipse-Entwicklungsumgebung mit den installierten EMF Plug-Ins. Dabei ist das Beispiel aus dem Kapitel 2 bereits geladen. Auf der linken Seite ist die übliche Baumansicht (Package Explorer) der Eclipse-Entwicklungsumgebung zu sehen, in der man die Packages, Klassen und die Interfaces auswählen kann. Auf der rechten Seite sieht man, zum einen die zwei unterschiedlichen Editoren zum Bearbeiten des Ecore-Modells und zum anderen die generierte Klasse PurchaseOrder- Impl.java für das PurchaseOrder Objekt aus dem Beispiel. Ganz rechts ist die Baumansicht des Ecore-Modells das man durch die Auswahl der PurchaseOrder.ecore Datei erhält. Dieser Editor erfordert eine gewisse Erfahrung mit den EMF Elementen, da das Modell in der Baumansicht editiert werden muss. Durch die Auswahl der PurchaseOrder.ecorediag Datei wird der in der Mitte zusehende Editor geöffnet. Dieser Editor stellt das Ecore-Modell in einer UML-Kassendiagramm Notation dar und ist somit für nicht so erfahrene Modellierer gut geeignet. Das Ecore-Modell wird dabei einfach mit dem Drag & Drop Prinzip erstellt. Für die Konfiguration der einzelnen Attribute des Modells, wie z.b. den Rückgabetyp einer Methode, steht die sogenannte Properties-View zur Verfügung.

EMF - Eclipse Modeling Framework 11 Fig. 6. Eclipse mit den EMF Plug-Ins Anhand dieses Beispiels erkennt man die Vorteile der engen Verbindung von EMF und Eclipse. Der Entwickler arbeitet mit der bekannten Entwicklungsumgebung und ist in der Lage das Modell und den Code über dieselben Eingabemasken zu editieren. Für die Erstellung des in der Abbildung 6 abgebildeten Zustands wurden folgende Schritte durchgeführt: Erstellung eines leeren EMF Projektes mittels dem EMF Projekt Wizard. Erstellung des Ecore-Modells mit den zwei Objekten PurchaseOrder und Item und der Referenz. Anlegen eines Generatormodells mit Hilfe eines Wizards. Generierung von: Modell-Code, Edit-Code, Editor-Code und dem Test-Code. Der Modell-Code wird dabei in den src-ordner des Projektes generiert (siehe Abbildung 6 Package Explorer), indem sich auch das Ecore-Modell befindet. Der Name der Packages wird dabei in dem Generatormodell festgelegt. Neben dem Modell-Code wurde auch der Edit-Code und das Editor-Code generiert. Wie der Name schon sagt, handelt es sich hier um den Code für den Editor. EMF generiert diesen Code direkt als zwei einzelne Plug-Ins. Mit Hilfe dieser zwei Plug-Ins ist man in der Lage, das definierte Modell über einen graphischen Editor zu testen. Soll der Editor direkt aus Eclipse gestartet werden, muss man lediglich die plugin.xml Datei des *.editor Projektes öffnen und unter dem Abschnitt Testing Launching an Eclsipse Application auswählen. Wie in der Abbildung 7 zu sehen ist, wird dabei eine neue Instanz von Eclipse geöffnet,

12 EMF - Eclipse Modeling Framework Fig. 7. Der generierte Modell-Editor die, die Plug-Ins geladen hat. Dadurch kann eine Instanz des definierten Modells mit wenigen Mausklicken angelegt werden. Die generierten Plug-Ins enthalten somit alle Notwendigen Klassen für die Erstellung und die Darstellung von Instanzen des eigen definierten Modells. Zudem wird auch ein Wizard generiert, der das Anlegen einer Instanz des Modells ermöglicht. Mit diesen beiden Plug-Ins ist somit eine Basis für die Entwicklung eigener Editoren geschaffen. Hierfür muss man lediglich die Plug-Ins in die eigene Applikation importieren und die generierten Klassen erweitern. Des Weiteren besteht auch die Möglichkeit, für den generierten Modell-Code die JUnit Tests direkt mit zu generieren. Wie in der Abbildung 6 zu sehen ist, wird hierfür ein *.tests Projekt generiert. Darin sind vollständige Test-Cases enthalten, die eigenständig ausgeführt werden können. EMF generiert dabei eine Test-Case Schale, die alles Notwendige zum Ausführen der JUnit Tests enthält und der Entwickler muss lediglich die einzelnen Testmethoden vervollständigen. Dabei werden nur Testmethoden Schallen für Methoden generiert, die keine Setter und Getter sind. Im Listing 3 ist der generierte Test-Case für das PurchaseOrder Objekt mit der zusätzlichen Funktion (EOperation) sumtotal() (Funktion soll dabei die Summe aller einzelnen Artikel als Float-Wert zurück liefern) zu sehen. Fig. 8. PurchaseOrder mit sumtotal() /** * <p> * The following operations are tested: * <ul> * <li>{@link purchaseorder.purchaseorder#sumtotal() <em>sum Total</em>}</li> * </ul> * </p>

EMF - Eclipse Modeling Framework 13 * @generated */ public class PurchaseOrderTest extends TestCase {... /** * @generated */ public static void main(string[] args) { TestRunner.run(PurchaseOrderTest.class); }... /** * @see junit.framework.testcase#setup() * @generated */ @Override protected void setup() throws Exception { setfixture(purchaseorderfactory.einstance.createpurchaseorder()); } /** * @see junit.framework.testcase#teardown() * @generated */ @Override protected void teardown() throws Exception { setfixture(null); } /** * Tests the {@link purchaseorder.purchaseorder#sumtotal() <em>sum Total</em>} operation. * @see purchaseorder.purchaseorder#sumtotal() * @generated */ public void testsumtotal() { // TODO: implement this operation test method // Ensure that you remove @generated or mark it @generated NOT fail(); } } //ItemTest Listing 3 - Generierter TestCase für PurchaseOrder Diese Funktion fördert die Testgetriebene-Softwareentwicklung und unterstützt den Entwickler, indem es die Erzeugung von gleichartigen und immer wiederkehrenden Code übernimmt. Dadurch, braucht sich der Entwickler nur auf die eigentlichen Test- Cases zu konzentrieren und die Wahrscheinlichkeit, dass die Tests geschrieben werden, wird somit viel größer. Im nächsten Abschnitt werden einige Projekte vorgestellt, die auf EMF aufbauen.

14 EMF - Eclipse Modeling Framework Projekte die auf EMF basieren Wie bereits im Kapitel 1 beschrieben, stellen die zwei Softwareunternehmen Borland und IBM einige kommerzielle Produkte zur Verfügung, die auf EMF basieren. Borlands Produkt ist das Together Tool [13], welches ein visuelles Modellierungswerkzeug für die Softwareentwicklung ist. Dabei können neben UML-Modellen auch BPMN-Modelle modelliert werden. Da Together auf EMF aufbaut, besteht auch die Möglichkeit EMF- Modelle in das Werkzeug zu importieren und zu exportieren. IBM setzt das EMF sogar in mehreren Produktlinien ein: der Produktlinie IBM Rational [10] und WebSphere [11]. Die Produktlinie IBM Rational umfasst verschiedene Entwicklungstools, die, die Anwendungsentwicklung beschleunigen sollen. IBMs Web- Sphere Produktlinie beschäftigt sich mit Software für SOA-Umgebungen und Anwendungs- Infrastrukturen für verschiedene Geschäftssituationen. Des Weiteren wird EMF auch in vielen Projekten in Zusammenhang mit GEF (Graphical Editing Framework) [13] eingesetzt. Wie im Kapitel 2 beschrieben, ist GEF auch ein Bestandteil von Eclipse Modeling Project. Es basiert komplett auf EMF und ermöglicht es, zu existierenden Modellen Rich Graphical Editoren zu erstellen. Für die Darstellung von graphischen Objekten (Figures) und für das Layout nutzt GEF das Draw2D Framework [14]. GEF ist nach der Model-View-Controller Architektur (MVC) aufgebaut, die es möglich macht, Veränderung am Modell in die graphische Repräsentation zu übertragen. Dadurch, das GEF bereits viele Funktionen wie z.b. Undo/Redo, Selektion-, Erzeugung-, Connection-Tools und verschiedene Werkzeug- Paletten sowie verschiedene vordefinierte Views mitbringt, ist es ein Fundament um fast jede Art von Anwendung zu erschaffen, beispielsweise für Aktivitätsdiagramme, Klassendiagrammeditoren und Zustandsautomaten. In der Abb. 9 ist ein Editor dargestellt, der mit GEF entworfen wurde. Fig. 9. GEF Editor [14]

EMF - Eclipse Modeling Framework 15 5 Zusammenfassung Diese Arbeit gab einen detailierten Überblick über den Aufbau von EMF und über die Möglichkeiten, die EMF bietet. EMF ist ein leichtgewichtiges aber dennoch mächtiges Tool, um mit wenig Ausstattung modellgetriebene Softwareentwicklung zu realisieren. Ohne großen Aufwand können dabei Modelle erzeugt und entsprechender Code ohne Nutzung weiterer komplexer Tools generiert werden. Ein Nachteil von EMF sind die generierten Modell-Ediotren. Dabei handelt es sich um reine Basis-Editoren, die das Modell lediglich in der Baumansicht darstellen können. Soll der Editor an die eigenen Bedürfnisse angepasst werden, muss ein großer Implementierungsaufwand investiert werden. Daher sollte man in diesem Fall, wie im Kapitel 2 beschrieben, auf GEF oder GMF zurück greifen. Durch die Tatsache das EMF für die Java-Programmiersprache entworfen wurde, können Objektorientierte Entwickler, vor allem Entwickler die Eclipse nutzen, nach sehr kurzer Zeit modellgetriebene Softwareentwicklung betreiben. Ein großer Vorteil von EMF ist, dass das Separation of Concerns Prinzip unterstützt wird. Dadurch sind die Business-Modelle komplett Plattform- und Codeunabhängig. Die automatische Synchronisierung der verschiedenen Modellrepräsentationen sorgt für die Konsistenz. Außerdem bietet EMF auch eine gute Möglichkeit den generierten Code vom manuell implementierten Code zu trennen. Durch die Erweiterungen die das Eclipse Modeling Project bietet, kann das EMF im sehr breiten Spektrum seinen Einsatz finden. Alles in einem kombiniert EMF die Ansätze von Modellierung und Programmierung vorteilhaft miteinander und kann somit den Softwareentwicklung- Prozess effektiver gestalten. References 1. IT-Wissen EMF, http://www.itwissen.info/definition/lexikon/emf-eclipsemodelling-framework.html 2. MOF, http://www.omg.org/mof/ 3. EMF: Eclipse Modeling Framework (Second Edition). Erich Gamma, Lee Nackman, John Wiegand, Michigan (2008) 4. EMF Tutorial, http://www.vogella.com/articles/eclipseemf/article.html 5. Eclipse Foundation, http://www.eclipse.org/org/ 6. Eclipse Modeling Framework Project (EMF), http://www.eclipse.org/modeling/emf/?project=emf#emf 7. EMF ECore, http://download.eclipse.org/modeling/emf/emf/javadoc/2.8.0/org/eclipse/emf/ecore/packagesummary.html#details 8. Eclipse Con2008, http://www.eclipsecon.org/2008/index.php?page=sub/&id=309 9. XMI, http://www.omg.org/spec/xmi/ 10. IBM Rational, http://www-01.ibm.com/software/de/rational/ 11. IBM WebSphere, http://www-01.ibm.com/software/de/websphere/ 12. Borland Together, http://www.borland.com/products/together/default.aspx 13. GEF, http://www.eclipse.org/gef/ 14. Draw2d, http://www.eclipse.org/gef/draw2d/index.php 15. MDA, http://www.omg.org/mda/ 16. GMF, http://www.eclipse.org/modeling/gmp/ 17. JET, http://www.vogella.com/articles/eclipsejet/article.html