3.2 Vergleich der Metamodelle von GXL, MOF und ecore
3.2.1 Einf¨uhrung der Metamodelle
Ahnlich wie im letzten Abschnitt generalisiert beschrieben, werden an dieser Stelle die¨ Ebenen definiert, welche speziell f¨ur JGraLab ben¨otigt werden.
• M3, Meta-Schema: Die M3-Ebene beschreibt, welche Elemente ein Graphen-schema beinhalten darf. Sie legt fest, was z.B. eine Graphenklasse oder was eine Knotenklasse ¨uberhaupt ist. Diese Ebene soll selbstbeschreibend sein. Damit ist keine M4-Ebene mehr notwendig.
3.2. Vergleich der Metamodelle von GXL, MOF und ecore
Abbildung 3.1: Die Ebenen von JGraLab
• M2, Schema: Instanzen von M3-Modellen bilden die M2-Ebene, das konkre-te Graphenschema selbst. Sie legen fest, welche Elemenkonkre-te ein Graph besitzen darf. Dies geschieht in Form von Graphen-, Knoten- und Kantenklassen. Die M2-Ebene kann mittels zweier Notationen beschrieben werden. Erstens als Instanz der M3-Ebene in Form eines Objektdiagramms und zweitens als UML-Diagramm, um als Schema f¨ur die M1-Ebene zu dienen.
• M1, Graphen: Werden M2-Schemata instanziiert, kommt man zu den Graphen selbst. Sie bestehen aus Knoten und Kanten, welche eine Instanz aus ihrer jewei-ligen Knoten- oder Kantenklasse bilden.
In den folgenden Abschnitten werden die Metamodelle der Abbildungen 3.2, 3.3 und 3.4 zun¨achst einmal beschrieben. Sie entsprechen der soeben definierten Ebene M3.
GXL
GXL1 ist ein XML-basiertes Austauschformat, um Graphen und ihr Schema zu spei-chern. Speziell wird es im Reengineering-Bereich eingesetzt, um die Interoperabilit¨at zwischen verschiedenen Tools zu gew¨ahrleisten. Es kann mehr als nur TGraphen dar-stellen, auch hierarchische Graphen und Hypergraphen sind m¨oglich. Dabei k¨onnen so-wohl die Graphen als auch das dazugeh¨orige Schema innerhalb eines einzigen Formats ausgetauscht werden [HoSc02-1].
In Abbildung 3.2 ist das Wichtigste des GXL Metamodells dargestellt. Auf Hypergra-phen und auf hierarchische GraHypergra-phen wird verzichtet. Das gezeigte Subset von GXL kann TGraphen-Schemata darstellen.
1GXL: Graph eXchange Language
-name : string
-aggregate : (from, to) AggregationClass
Abbildung 3.2: Metamodell GXL
3.2. Vergleich der Metamodelle von GXL, MOF und ecore Das Hauptelement des GXL Metamodells bildet die abstrakte Klasse AttributedEle-mentClass. Sie aggregiert eine Reihe von AttributeClasses, welche jeweils unterschied-liche Attribute darstellen k¨onnen. Aus der AttributedElementClass l¨asst sich die Klasse GraphClass spezialisieren, welche einen Graphtyp darstellt. Diese Klasse kann wieder-um abstrakte Klassen vom Typ GraphElementClasses enthalten, welche ihrerseits eine weitere Spezialisierung der AttributedElementClass bildet.
Durch die isA-Assoziation der GraphElementClass k¨onnen Graphelementklassen (n¨am-lich EdgeClasses und NodeClasses) untereinander eine Hierarchie bilden. Hierbei k¨on-nen sowohl EdgeClasses als auch NodeClasses untereinander ihre Eigenschaften verer-ben.
Die Verbindung zwischen Edge- und NodeClasses ¨ubernehmen zwei Assoziationsklas-sen (from und to), welche jeweils die Kardinalit¨aten enthalten.
Es ist im GXL-Metamodell nicht festgeschrieben, dass Kanten nur mit Knoten verbun-den werverbun-den k¨onnen, sie lassen sich beliebig verketten. Allerdings unterbindet der so genannte GXL-Validator dies, jedoch ist diese Einschr¨ankung nicht so im Metamodell untergebracht [Kacz03].
Als Spezialf¨alle der EdgeClass existieren die AggregationClass und ferner die Compo-sitionClass, welche eine Aggregation bzw. eine Komposition darstellen.
In diesem Auszug des GXL-Metamodells wurde aus ¨Ubersichtsgr¨unden die Definiti-on der Wertebereiche weggelassen. Folgende Dom¨anen werden vDefiniti-on GXL unterst¨utzt (hierbei wurde sich an OCL orientiert) [HoSc02-2]:
• Atomare Wertebereiche: Int, Float, Bool, String
• Aufz¨ahlungswertebereich: Enum
• Zusammengesetzte Wertebereiche: Bag, Set, Seq, Tup
MOF
MOF2 wurde entwickelt, um nachtr¨aglich eine Metaebene f¨ur UML zu repr¨asentieren.
Wie GXL ist sie selbstbeschreibend, d.h. sie kann sich durch ihr Metamodell selbst instanziieren. Die Spezifikation MOF 1.4 ist die derzeit g¨ultige Variante, Version 2.0
2MOF: Meta Object Facility
-multiplicity : int x int StructuralFeature
{abstract}
-isAbstract : bool GeneralizableElement
{abstract}
Attribute Reference
-multiplicity : int x int AssociationEnd
Class DataType
1
*
isOfType
*refersTo 1
* 1
exposes Association
* Generalizes*
-name : string ModelElement
{abstract}
NameSpace {abstract}
TypedElement {abstract}
Classifier {abstract}
contains
Abbildung 3.3: Metamodell MOF
3.2. Vergleich der Metamodelle von GXL, MOF und ecore steht zur Zeit noch in der Abnahmephase [OMG05]. MOF 1.4 wird in den n¨achsten Zeilen beschrieben.
Die Darstellung von MOF wurde in diesem Modell (Abb. 3.3) stark reduziert. Dennoch bietet MOF auch hier mehr Freiheiten an, als gew¨unscht.
Kernelement des Metamodells bildet die Klasse ModelElement, welche sich in Na-mespace und TypedElement spezialisieren l¨asst. Ein NaNa-mespace kann zwar mehrere ModelElements aggregieren, jedoch kann es aufgrund des abstrakten Charakters keine Graphen-Klasse repr¨asentieren.
Die ¨uber Namespace spezialisierte Klasse GeneralizableElement bietet durch die Gene-ralizes-Assoziation auf sich selbst die Vererbungshierarchie an, welche auf ihre Spezia-lisierungen Classifier und anschließend Association, Class und DataType wirkt.
Eine Class kann einem Knotentyp entsprechen, eine Association zu einem Teil einem Kantentyp (es werden f¨ur einen Kantentyp weitere Elemente ben¨otigt), sowie ein Da-taType den herk¨ommlichen Datentypen f¨ur Attribute, sowohl primitive als auch zusam-mengesetzte.
Auf der anderen Seite l¨asst sich ein TypedElement in AssociationEnd sowie in die ab-strakte Klasse StructuralFeature spezialisieren, welche ihrerseits die Klassen Attribute und Reference generalisiert.
Um eine Assoziation zwischen Class-Objekten zu beschreiben, werden 3 Elemente des Metamodells ben¨otigt: Als erstes bildet die Association in einfacher Ausf¨uhrung den Kernkantentyp, welcher Klassen vom Typ Attribute enthalten kann (dies geschieht
¨uber die Komposition der abstrakten Klasse Namespace). Die beiden Verbindungs-punkte zwischen Kanten- und Knotentypen werden mittels der zweiten Klasse Asso-ciationEnd repr¨asentiert. Diese Punkte k¨onnen Inzidenzen in Graphen entsprechen. Die Class-Klasse enth¨alt zur Navigation zwei sogenannte References, welche jeweils auf das anliegende (exposes) und auf das entfernte (refersTo) AssociationEnd zeigen. Eine Association beinhaltet schließlich zwei AssociationEnds [GeRa03], [OMG02].
Die folgenden Datentypen existieren in MOF:
• Primitive Type fasst die primitiven Datentypen Boolean, Integer, Long, Float, Double und String zusammen.
• Structured Type bildet ein Tupel.
• Enumeration Type repr¨asentiert den Aufz¨ahlungswertebereich.
• Alias Type weist einem Datentypen einen weiteren Namen zu.
• Collection Type kann beliebig viele Objekte eines bestimmten Basisdatentyps aufnehmen.
ecore
Ecore (Abb. 3.4) ist das M3-Modell des EMF3. Es basierte urspr¨unglich auf dem MOF Modell 1.4 und wurde sp¨ater an OMGs EMOF 2.04angeglichen. Es dient dazu, Modelle in EMF zu beschreiben.
Im Vergleich zum vorherigen Abschnitt sieht man, dass ecore sehr an MOF angelehnt ist. Auch hier bildet das EModelElement den Kern des Modells. Zudem korrespondieren die Spezialisierungen von ENamedElement, n¨amlich ETypedElement, EClassifier und ferner EStructuralFeature mit MOF.
Die Klasse EClass kann einen Knotentyp darstellen, welcher durch die Vererbung der Komposition zu EStructuralFeature Attribute (Klasse EAttribute) besitzt und selbst eine Vererbungshierarchie unterst¨utzt. Die Klasse EDataType beschreibt den Wertebereich des Attributs.
Kantentypen k¨onnen durch EReferences repr¨asentiert werden, es existieren hiervon bei ungerichteten Graphen zwei Exemplare, mit denen jeweils andere Richtungen beschrie-ben werden. Durch eOpposite wird jeweils auf die andere EReference referenziert. Her-vorzuheben ist, dass nur EClasses Attribute besitzen k¨onnen, EReferences k¨onnen es nicht. Damit k¨onnen Assoziationen nicht direkt beschrieben werden [BaGra05].
Alternativ k¨onnte eine Kantenklasse als EClass modelliert werden, damit wird die Ver-wendung von Attributen an Kantenklassen wieder erm¨oglicht.
Folgende Datentypen werden von ecore unterst¨utzt [IBM04]:
• Einfache Datentypen: EBoolean, EByte, EChar, EDouble, EFloat, EInt, ELong, EShort, EString, EByteArray
3EMF = Eclipse Modelling Framework
4EMOF = Essential MOF, die zur Zeit in der Abnahmephase befindliche Teilmenge einer Nachfolge-version von MOF 1.4, gleicht ecore bis auf Namensunterschiede sowie der dort nicht vorhandenen Unterscheidung zwischen Referenzen und Attributen.
3.2. Vergleich der Metamodelle von GXL, MOF und ecore
-name : string -abstract : bool
EClass
-name : string EDataType
-name : string -lowerBound : int -upperBound : int
EAttribute -name : string
-containment : bool -lowerBound : int -upperBound : int EReference
eSuperTypes0..*
-eDataType 1 -eReferences 1
-eOpposite
0..1
EModelElement {abstract}
ENamedElement {abstract}
ETypedElement {abstract}
Eclassifier {abstract}
EStructuralFeature {abstract}
EPackage
Abbildung 3.4: Metamodell ecore
• Komplexe Datentypen: EDate, EBigInteger, EBigDecimal, EResource, EResource-Set, EFeatureMapEntry, EFeatureMap, EEnummerator, EList, ETreeIterator