EMF-Modelle werden analog zu den von der OMG definierten Metaebenen (siehe Ab-schnitt 2.2.3, Abbildung 2.2) hierarchisch aufgebaut. Zu ihrer Modellierung wird Ecore
Abbildung 3.1: EMF vereinigt UML, Java und XML (Zeichnung analog zu [73])
M2:EcoreͲMetamodell
M1:EcoreͲModell
M0:Instanzen
instanziiert
instanziiert instanziiert
beschreibt
beschreibt
beschreibt
Abbildung 3.2:Metaebenen in Ecore
verwendet. Da bereits das Ecore-Metamodell in sich selbst definiert ist, entf¨allt die Meta-Metaebene und die Modellhierarchie vereinfacht sich zu der in Abbildung 3.2 gezeig-ten. Es handelt sich hierbei um eine dreistufige Hierarchie, beginnend mit dem Metamodell. Dessen Instanzen sind die in der Modellierung mit EMF genutzten Ecore-Modelle. Ecore-Modelle k¨onnen wiederum instanziiert werden zu Ecore-Modellinstanzen, im Folgenden Instanzen genannt, die konkrete Objekte darstellen. Die drei Ebenen wer-den im Folgenwer-den n¨aher betrachtet.
Das Ecore-Metamodell
Das Ecore-Metamodel (M2 in Abbildung 3.2) stellt die abstrakteste Ebene dar. Es ist das Metamodell, das dem EMF-Rahmenwerk zugrunde liegt. Das Ecore-Metamodell ist ebenfalls ein EMF-Modell und basiert auf dem von der OMG definerten eMOF-Standard, der eine Untermenge der MOF bildet [60]. Abbildung 3.3 zeigt das Metamodell, abge-sehen von der Klasse EObject, von der alle Klassen erben. Es handelt sich hierbei um ein selbstbeschreibendes Klassendiagramm. Abstrakte Klassen sind grau hinterlegt und durch kursive Schrift gekennzeichnet, konkrete Klassen sind gelb hinterlegt. Abgelei-tete Referenzen sind blau-gr¨un markiert, direkte Referenzen sind schwarz dargestellt.
Letztere weisen an einigen Stellen Enthaltenseins-Beziehungen, die durch einen schwar-zen Diamanten gekennzeichnet sind, auf. F¨ur alle Enthaltenseins-Beziehungen in einem EMF-Modell gilt das Prinzip der Exklusivit¨at1.
Bevor n¨aher auf das abgebildete Metamodell eingegangen wird, wird zun¨achst die Klasse EObject betrachtet, deren Eigenschaften alle Modellelemente erben. EObject ist zum Einen eine Klasse, die generische Operationen bietet, welche den Zugriff auf Ob-jekte regeln. Beispiele hierf¨ur sind eClass(), das den Typ einer Klasse zur¨uck gibt sowie die reflektiven AkzessoreneGet(...)undeSet(...). Zum Anderen bietet EObjecteinen Me-chanismus zur Notifikation an. ¨Anderungen an Objekten werden dem Observer-Muster folgend propagiert.
1Exklusivit¨at bedeutet, dass es genau einen Container f¨ur ein Objekt gibt.
Abbildung 3.3: Das Ecore-Metamodell (aus [1])
Klassen werden durch die in Abbildung 3.3 zentral dargestellte Klasse EClass model-liert. Dabei k¨onnen die Klassen sowohl abstrakt (Attribut abstract) sein, als auch als Interface (Attribut interface) deklariert werden. Klassen k¨onnen in beliebig geschachtel-ten Pakegeschachtel-ten (EPackage) gruppiert, annotiert (EAnnotation) und in Fabriken (EFactory) erzeugt werden. Jede Klasse kann benannt, attribuiert und referenziert werden. Zu-dem k¨onnen Operationen innerhalb der Klasse spezifiziert werden und die Angabe von Oberklassen f¨ur jede Klasse ist m¨oglich (Referenz eSuperTypes). Hierbei ist Mehrfach-vererbung erlaubt. Das Attribut name zur Benennung der Klasse erbt EClass - wie die meisten Klassen in Ecore - von der abstrakten Klasse ENamedElement. Attribu-te (EAttribuAttribu-te), Operationen (EOperation) und Referenzen (EReference) der Klasse sind im Ecore-Metamodell als eigenst¨andige Klassen modelliert und durch Enthaltenseins-Beziehungen der Klasse zugeordnet (Referenzen eStructuralFeatures und eOperations).
Zu ihrer Beschreibung m¨ussen zun¨achst ihre Oberklassen detaillierter betrachtet werden:
Attribute und Referenzen werden zur abstrakten Klasse der strukturellen Eigenschaften einer Klasse zusammengefasst (EStructualFeature). Strukturelle Eigenschaften k¨onnen mit den Attributen ver¨anderbar (changeable), volatil (volatile), transient (transient), un-setzbar (unsettable) und abgeleitet (derived) gekennzeichnet werden. Dabei werden ab-geleitete Attribute aus bestehenden Daten berechnet. Sie sind daher typischer weise transient, werden also nicht gespeichert. Zudem besteht die M¨oglichkeit, Standardwer-te zu vergeben, mit welchen die strukturellen EigenschafStandardwer-ten initialisiert werden (At-tribut defaultValue) und welche in den zugeh¨origen Literalen gespeichert werden (At-tribut defaultValueLiteral). Strukturelle Eigenschaften sind immer genau einer Klasse zugeordnet (Referenz eContainingClass), w¨ahrend Klassen beliebig viele strukturelle Ei-genschaften aufweisen k¨onnen (ReferenzeStructuralFeatures). Diese strukturellen Eigen-schaften sind wiederum typisierte Elemente, denn die Klasse EStructualFeature erbt von der ebenfalls abstrakten Klasse ETypedElement. Typisierte Elemente k¨onnen geordnet (ordered), eindeutig (unique), mehrwertig (many) und erforderlich (required) sein, sowie eine obere und untere Schranke bez¨uglich ihrer Multiplizit¨at aufweisen. Ihre Typisie-rung erfolgt ¨uber die Klasse EClassifier, einer Oberklasse von EClass, und ihren Namen erben typisierte Elemente wiederum von der Klasse ENamedElement. Neben all diesen Gemeinsamkeiten von Referenzen und Attributen weisen beide einige zus¨atzliche Eigen-schaften auf. Referenzen sind unidirektional, k¨onnen Enthaltenseins-Beziehungen auf-weisen (Attribute containment und container) und es besteht die M¨oglichkeit eine ent-gegengesetzte Referenz zu spezifizieren (Referenz eOpposite), so dass dieses Paar eine bidirektionale Referenz repr¨asentiert. Zudem sind Referenzen immer vom Typ genau einer Klasse (abgeleitete Referenz eReferenceType), n¨amlich derer, auf die sie verwei-sen. Attribute k¨onnen im Gegensatz dazu nur ¨uber Datentypen (EDataType) typisiert werden. Datentypen sind hier sowohl primitive Datentypen (Ganzzahlen, Zeichenketten, etc.) als auch Aufz¨ahlungsdatentypen, die mittels der Klasse EEnum spezifiziert wer-den k¨onnen. Zudem kann ein Datentyp eine beliebige Java-Klasse repr¨asentieren. Damit besteht vollst¨andige Unterst¨utzung zur Modellierung von Klassen und deren statischen Eigenschaften.
Operationen werden im Ecore-Metamodell durch die Klasse EOperation modelliert.
Sie erben alle Eigenschaften der typisierten Elemente (ETypedElement). Operationen beinhalten beliebig viele Parameter, die durch die Klasse EParameter modelliert werden und jeweils in genau einer Operation enthalten sein d¨urfen (Referenzen eParameters und eOperation). Parameter sind ebenfalls typisierte Elemente. Dar¨uber hinaus kann eine Operation beliebig viele Ausnahmen vom Typ eines EClassifiers werfen (Referenz eExceptions).
An dieser Stelle zeichnet sich bereits ein zentraler Punkt des ModGraph-Ansatzes ab: EMF bietet zwar M¨oglichkeiten zur Spezifikation einer Operation, das eigentliche Verhalten der Operation kann jedoch mit Ecore nicht modelliert werden. Wie diese
”L¨ucke“ im EMF-Rahmenwerk geschlossen werden kann, zeigt Teil III dieser Arbeit.
F¨ur eine weitergehende Erl¨auterung des Ecore-Metamodells sei auf Steinberg et al. [73], Kapitel 5, verwiesen.
Abbildung 3.4: Das Refactoring Ecore-Modell
Das Ecore-Modell
Nach dieser ausf¨uhrlichen Betrachtung der relevanten Abschnitte des Ecore-Metamodells, wird im Folgenden seine Instanzebene untersucht: Ecore-Modelle (M1 in Abbildung 3.2) modellieren strukturelle Sachverhalte in Form von Ecore-Klassendiagrammen. Sie wer-den in jedem mit EMF realisierten Projekt ben¨otigt. Als Instanzen des Ecore-Metamo-dells bieten sie alle eben vorgestellten Konzepte an. Abbildung 3.4 zeigt einen Ausschnitt des Ecore-Modells am Beispiel Refactoring auf Klassendiagrammen. Hierbei modelliert die KlasseRefactoringMethoden zum Refactoring von Ecore-Modellen. Dazu ist es n¨otig, Klassen aus dem Ecore-Metamodell zu referenzieren (z.B.EClass), die in Abbildung 3.4 durch einen kleinen Pfeil rechts oben markiert sind. Außerdem wird eine interne Hilfs-klasse (Helper) referenziert, die ihrerseits Methoden bereitstellt.
Ecore-Modelle sind hierarchisch aufgebaut und weisen immer eine Baumstruktur auf.
Dies bedeutet auch, dass f¨ur jedes Modell ein globaler Beh¨alter, das Wurzelobjekt des Baums, existiert. Dieser entspricht immer dem Paket, in welchem sich die Elemente be-finden. Dadurch lassen sie sich auf einfache Weise in Ressourcen speichern. Zur Ressource muss lediglich das Wurzelobjekt des Ecore-Modells hinzugef¨ugt werden, um Persistenz zu erreichen. Damit werden alle enthaltenen Objekte automatisch der Ressource hinzu-gef¨ugt.
Instanzen des Modells
Instanzen dieser Ecore-Modelle bilden die unterste der Ebenen (M0) aus Abbildung 3.2. Sie stellen konkrete Sachverhalte dar. Instanzen werden entweder direkt im Quell-text oder mittels (der generierten) Editoren erstellt und bearbeitet. Sie d¨urfen beliebige Klassen des Ecore-Modells beliebig oft instanziieren. Da dies auch das Wurzelobjekt des EcoModells betrifft, werden die Instanzen in der Regel durch einen Wald re-pr¨asentiert. Instanzen werden ebenfalls in Ressourcen gespeichert. Um Persistenz zu erreichen, m¨ussen hier alle, in der Instanz enthaltenen, Wurzelobjekte zur Ressource hinzugef¨ugt werden.
Ressourcen
Eine Ressource kann mittels eines Beh¨alters f¨ur Ressourcen, der Ressourcenmenge, er-zeugt werden. Jede Ressource repr¨asentiert einen physikalischen Speicherort, eine Datei.
Objekte k¨onnen durch ressourcen¨ubergreifende Referenzen verbunden werden, sofern al-le Resourcen innerhalb derselben Ressourcenmenge liegen. Diese Referenzen werden bei Bedarf aufgel¨ost, d.h. die Objekte werden in den Speicher geladen. Dies wird dynami-sches Laden von Ressourcen innerhalb einer Ressourcenmenge genannt. Die Notwendig-keit, Objekte dynamisch zu laden, ergibt sich aus der Serialisierung der EMF-Modelle.
EMF-Ressourcen werden im XMI-Format serialisiert und m¨ussen somit in den Speicher geladen werden, um Zugriff zu erm¨oglichen. Im Refactoring-Beispiel wird dynamisches Laden ben¨otigt, um die aus dem Ecore-Modell importierten Klassen in das Refactoring-Modell zu laden.