Modellgetriebene Softwareentwicklung mit EMF und Xtext

Modelle dienen nicht selten zur Dokumentation komplexer Prozessabläufe, sie sind aber auch direkt als Metadaten in die Software zu integrieren. heise Developer stellt diese "entwicklungsnahe" Modellierung anhand der zwei Eclipse-Projekte EMF und Xtext vor.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 16 Min.
Von
  • Thomas Pohl
  • Alexander Neumann
Inhaltsverzeichnis

In der Softwareentwicklung dienen Modelle nicht selten zur Dokumentation komplexer Prozessabläufe, sie sind aber auch direkt als Metadaten in die Software zu integrieren. heise Developer stellt diese "entwicklungsnahe" Modellierung anhand der zwei Eclipse-Projekte EMF und Xtext vor.

Im Zentrum modellgetriebener Softwareentwicklung (MDSD) steht das Modell. Es soll einen Ausschnitt aus der Realität beschreiben, den die Software abbildet. Da realen Abläufen im Allgemeinen eine hohe Komplexität innewohnt und nicht alle Aspekte relevant sind, ist die Modellbildung charakterisiert durch eine Reduktion beziehungsweise Abstraktion der beobachtbaren Abläufe.

Modelle lassen sich in der Softwareentwicklung unterschiedlich nutzen. In vielen Fällen nutzt man sie zur Dokumentation komplexer Prozessabläufe, sie lassen sich aber auch direkt als Metadaten in die Software integrieren, wie der Artikel beispielhaft an zwei Eclipse-Projekten verdeutlicht.

Beim Eclipse Modeling Framework (EMF) handelt es sich um ein Java-Tool zum Generieren von Codefragmenten und Applikationen, die ein strukturiertes Modell enthalten. Der Vorteil von EMF liegt darin, einen einfachen und kostengünstigen Einstieg in die modellgetriebene Softwareentwicklung zu ermöglichen. Sein Ziel ist nicht, das Verhalten und die Struktur der Applikation mit dem Modellierungsarsenal der UML unter Verwendung von Klassen-, Komponenten-, Aktivitäts-, Sequenz-, Zustandsdiagrammen et cetera möglichst vollständig durchzumodellieren, um daraus per Knopfdruck einen großen Teil beziehungsweise die gesamte Applikation zu generieren. Stattdessen beschränkt sich EMF auf Klassendiagramme, die die Struktur der grundlegenden (Geschäfts-)Objekte beschreiben.

Ein wesentlicher Bestandteil von EMF ist das Ecore-Metamodell, mit dem sich die Objektmodelle kanonisch beschreiben lassen. EMF erlaubt es, Objektmodelle in unterschiedlichen Repräsentationen (zum Beispiel mit einem UML-Klassendiagramm) zu importieren und daraus die kanonische Ecore-Repräsentation zu erzeugen. Sie lässt sich in das Format XML Metadata Interchange (XMI) serialisieren. Der Ecore-Ansatz ist allgemein gehalten. Es ist nicht nur möglich, mit Ecore spezifische Objektmodelle zu beschreiben, wie das Geschäftsobjekt "Geschäftspartner", sondern auch allgemeiner den gemeinsamen Aufbau von Geschäftsobjekten (das heißt das Metamodell für Geschäftsobjekte). Daher kann man ein Ecore-Modell als ein Meta-Metamodell ansehen. Der Einfachheit halber ist im Folgenden von Ecore-Modellen die Rede. Damit ist die Repräsentation des Modells in Ecore gemeint.

Die folgende Abbildung zeigt eine Teilmenge von Ecore (den sogenannten Kernel), an der sich die wichtigsten Prinzipien einfach erklären lassen.

Ecore-Kernel-Metamodell (Abb. 1)



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.
  • EAttribute: dient zur Repräsentation eines Attributs. Letzteres besteht aus einem Namen und einem Typ.
  • EReference: wird verwendet, um ein Assoziationsende zwischen Klassen zu bezeichnen. Es enthält 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: repräsentiert den Typ eines Attributs.

Hat man die Ecore-Präsentation eines Modells, lässt sich die EMF-Infrastruktur nutzen, um Code oder Modell-Editoren zu generieren. Zuvor sei noch erläutert, wie man EMF-Modelle erzeugt.

Da Modelle sich konzeptionell auf unterschiedliche Weise darstellen lassen, stellt sich die Frage nach einer geeigneten Serialisierung der Ecore-Modelle. Hierzu dient das XMI-Format, das die Modelle direkt in ein XML-Dokument überführt.

Ecore-Modelle lassen sich auf unterschiedliche Weise erzeugen:

  • Man kann Ecore-Modelle direkt mit einem geeigneten Editor erstellen. Die Vorgehensweise setzt voraus, dass man mit dem Ecore-Metamodell hinreichend vertraut ist.
  • Mit dem EMF-Projekt- und EMF-Model-Wizard kann man aus UML-Diagrammen ein Modell importieren und daraus ein Ecore-Modell generieren.
  • Objekte lassen sich mit Java-Interfaces definieren. Um dem EMF-Codegenerator mitzuteilen, welche Objekte beziehungsweise Attribute modellrelevant sind, steht das Tag @model zur Verfügung, das sich im Javadoc-Kommentar befindet. Mit ihm erhält der Generator weitere Anweisungen, zum Beispiel ob ein Attribut nur einen lesenden Zugriff erlaubt.

Java-Interface BankDetails (Abb. 2)

Zur Verdeutlichung sei das Konzept an einem einfachen Beispiel beschrieben, in dem man die dritte Methode wählt und ein Java-Interface definiert, das wie in Abbildung 2 aufgebaut ist.

Zum Erzeugen des Ecore-Modells legt man ein leeres EMF-Projekt an und erstellt darin das Java-Interface. Aus dem Kontextmenü zum Ordner model, den das EMF-Projekt generiert, erzeugt man mit dem Projekt-Wizard ein neues EMF-Modell mit dem Namen bankdetails.genmodel und sucht "Annotated Java" aus der Liste der Model Importer heraus. Im erscheinenden Pop-up ist nun das das Java-Interface enthaltende Paket auszuwählen. Daraus erstellt die Laufzeitumgebung ein Ecore- (bankdetails.ecore) und ein Generatormodell (bankdetails.genmodel).

Ecore-Modell (Abb. 3)