MDA Metamodelle und Metamodelle im Eclipse-Kontext

UML, EMOF, Ecore, Java

Repräsentationen von Modellen

Metamodell ist ein Begriff im Kontext Model Driven Architecture (MDA). Hier gibt es außer dem OMG Ansatz unterschiedliche Quellen (Model Driven Software Development (MDSD), Model Driven Software Engineering (MDSE), generative SWE etc. ) und dementsprechend unterschiedliche Sichten. Ich konzentriere mich im Rahmen diese Beitrags ausschließlich auf das MDA-Begriffsverständnis der OMG.

Model Driven Architecture beschreibt die Entwicklung von Anwendungssystemen über eine Beschreibung ihrer Architekturen. Die Beschreibung der Architekturen, also des Aufbaus und Verhaltens von Systemen, erfolgt mittels Modellierung unter Verwendung formaler Modellierungssprachen, z.B. der UML. Die Entwicklung von Systemen wird in der Regel über mehrere Phasen durchgeführt, von Computational Independet (CIM) über Platform Independet (PIM), Platform Specific (PSM) bis hin zur Implemention (IM). In den jeweiligen Modellierungsebenen und zwischen den Modellierungsebenen kann unter Verwendung des QVT-Ansatzes beliebig zwischen den Modellen transformiert werden. Das funktioniert natürlich nur dann, wenn es sich bei den verwendeten Modellierungssprachen um formale Sprachen handelt.

Eine Modellierungssprache ist dann formal, wenn sie auf der Basis eines formalen Metamodells spezifiziert ist. Im Falle der OMG-Spezifikationen ihrer Modellierungssprachen ist dies mit UML-Klassendiagrammen erfolgt. Die UML selbst ist ebenfalls in diesem Sinne eine formale Modellierungssprache, sie ist mit UML-Klassendiagrammen spezifiziert.

UML
Repräsentation von Modellen in graphischer Form.
Profile - genauer: UML-Profile
UML-Klassendiagramme, die um bestimmte Properties (tagged values) ergänzt oder durch Constraints (OCL) eingeschränkt sind.
Metamodelle - genauer: OMG-Metamodelle
Spezifikationen von Modellierungssprachen in UML-Classdiagrams.
EMOF
Repräsentation von Modellen oder Metamodellen auf der Basis von XMI nach einer Spezifikation der OMG.
Ecore
Repräsentation von Modellen oder Metamodellen auf der Basis von XML nach einer Spezifikation aus dem Eclipse EMF-Projekt.
Java
Klassendiagramme, Metamodelle (ebenfalls Klassendiagramme) können in Form von kommentierten Java-Klassen repräsentiert sein (im Grunde genommen in jeder OO Programmiersprache).
Alle Text-basierten Repräsentationen sind von MDA/MDSD-Tools interpretierbar.
Alle in Eclipse integrierten MDA/MDSD-Tools verwenden das Ecore-Format.
Es ist eine Transformation zwischen allen Formaten möglich, z.B. vom Ecore zum EMOF mit der smartQVT EcoreToEmof-Transformation.

Build und Deploy von Ecore-Modellen

Edit, Build und Deploy von Ecore-Modellen

Ecore-Metamodelle werden mit dem Eclipse Modeling Framework erstellt.
  1. Öffnen eines leeren EMF-Projektes und Erstellen eines Ecore-Files mit dem Ecore Model Editor
  2. Öffnen eines EMF-Projektes unter Verwendung eines Ecore-Files und Bearbeiten des Ecore-Files mit dem Ecore Model Editor
  3. Ecore-Files können beliebig in das EMF-Projekt hinein kopiert werden.
  4. Unter Umständen muss dann noch das genmodel generiert werden
    File > new > other > Eclipse Modeling Framework > EMF-Model. Bei existierenen genmodel-Datei erfolgt das Auffrischen automatisch. Im Zweifel kann ein reload durchgeführt werden.
    Laden eines emof- oder ecore-Modells
  5. Generieren der Java-Repräsentation des Plugins, z.B. mit Generate All.
    Hierzu muss die genmodel-Repräsentation geöffnet sein. Dazu gibt es dann ein Generate-Menü.
  6. Build des Plugins durch export > plugin development > deployeable plugins
  7. Auswählen aller 4 Artefakte der Metamodell-Repräsentation (name(1.0.0), name.edit(1.0.0), name.editor(1.0.0), name.test(1.0.0)) und als Zielort (Destination) das Verzeichnis der Eclipse-Installation angeben.
Es ist ratsam, je ein .ecore-Model in einem EMF-Projekt zu bearbeiten und das Projekt nach dem Modell zu benennen, z.B. 'SimpleUML', da dies bei der Generierung der Plugins (Model, edit, editors, test) zugrunde gelegt wird. D.h. die generierten Quellen der Plugins, die die Metamodelle repräsentieren, heißen so wie das Projekt (mit den entsprechenden Suffixen).
Vor dem Deployment der Plugins sollten die plugin.xml angepasst werden.

Modellieren von Ecore-Modellen

Modellieren von Ecore-Modellen oder anderen Modellen auf der Grundlage von Ecore-Metamodellen erfolgt mit dem Eclipse Modeling Framework.

Ecore-Modellierungsprojekte werden mit File > new > Project > Eclipse Modeling Framework > EMF Projects angelegt.
Diese können initial leer (empty project) sein oder es können vorhanden Modelldateien geladen werden. Es handelt sich um XML-Dateien, die zum einen mit Texteditoren, zum anderen mit speziellen Editoren bearbeitet werden können, z.B. dem Sample Ecore Modeling Editor.
Jedes auf der Basis von Ecore erstellte Metamodell hat in der Regel auch sein Sample Modeling Editor (mit mehr oder weniger ausgeprägter Funktionalität) der mit dem Bauen und Deployen des Modells als Plugin generiert wird. Der Sample Modeling Editor ermöglicht ein Bearbeiten der Modelle in einem graphischen XML-Editor, in dem die XML-Konstrukte Baum-artig präsentiert werden.
Man kann Modelle unterschiedlicher Metamodelle erzeugen und bearbeiten mit File > new > other > Example EMF Model Creation Wizard. Dieser ermöglicht das Öffnen von Modellen nach einem bliebigen vorliegenden Metamodell. Hier sollte sich z.B. auch das SimpleUML- oder SimpleRDBMS-Metamodell wiederfinden, sofern wir das in dem Kontext publiziert haben.

Modellieren von Ecore-Modellen - die Zweite

Diese Modellierung hat auch ihre Schwächen, insbesondere bei selbstgenerierten Modellen. Der Sample Ecore Modeling Editor erlaubt z.B. das Hinzufügen von Childs (Elementen der nächsten Modellierungsebene, z.B. Properties) oder auch Siblings (Elementen auf derselben Modellierungsebene). Andere Sample Modeling Editoren tun dies nicht unmittelbar. (Dies muss explizit implementiert werden.) Siblings muss man bis auf weiteres direkt in der Text-Repräsentation hinzufügen. Am Beispiel der SimpleUML-Modellierung bedeutet das:
  1. Man erzeugt zunächst ein Modell mit dem obersten nicht abstrakten UMLModelElement Package.
  2. Das generierte Modell 
    <?xml version="1.0" encoding="UTF-8"?>
<SimpleUML:Package
xmi:version="2.0"
xmlns:xmi="ht tp://www.omg.org/XMI"
xmlns:SimpleUML="http:///SimpleUML.ecore"/>
     sollte nun zunächst geändert werden nach 
    <?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:SimpleUML="http:///SimpleUML.ecore">
<SimpleUML:Package/>
</xmi:XMI>
  3. Alle anderen Modellelemente sind Siblings, die mit diesem in Beziehung stehen (eigentlich sind die PackageElements in einem Package Childs. Das habe ich Metamodell-mäßig aber noch nicht zufriedenstellen hinbekommen).
    Die UMLModelElements - Class, PrimitiveDataType, Assoziation - muss man also nun mit dem Texteditor jeweils in einer Repräsentation hinzufügen: 
    <SimpleUML:Package           name = ""/>
<SimpleUML:Class             name = "" kind   = ""/>
<SimpleUML:Association       name = "" source = "" destination = ""/>
<SimpleUML:PrimitiveDataType name = ""/>
  4. Alle weiteren kann man im Sample Modeling Editor mittels Copy&Paste erstellen.
  5. Classes können als Childs Attribute haben; diese können mit dem Sample Modeling Editor erstellt werden.
  6. Alle weiteren Properties der UMLModelElemente können mit dem Property-Editor bearbeitet werden, zum Beispiel auch die Beziehung zwischen einem Package und seinen PackageElements.