3.2 Vergleich der Metamodelle von GXL, MOF und ecore
3.2.2 Beispiele f¨ur GXL, MOF und ecore
An dieser Stelle wird ein Schema definiert (Abb. 3.5), welches mittels der verschiedenen Metamodelle instanziiert wird.
Diese Beispiele vertiefen das Verst¨andnis der Metamodelle, zus¨atzlich l¨asst sich anhand dieser Beispielmodelle nochmals genauer feststellen, welche Elemente der Metamodel-le in das neue JGraLab-Metamodell ¨ubernommen werden k¨onnen.
Allgemeine Beschreibung des Beispiels
Junction {abstract}
CityMap
Intersection
-Capacity : int CarPark
-StreetName : string Street StreetStart
StreetEnd 1..6
1..6
Abbildung 3.5: Beispiel f¨ur ein Graphenschema
Die Graphklasse CityMap (Stadtplan) soll Kanten vom Typ Street (Straße) und Kno-ten vom Typ Intersection (Kreuzung) und CarPark (Parkplatz) beinhalKno-ten. Die beiden
3.2. Vergleich der Metamodelle von GXL, MOF und ecore Knotentypen k¨onnen zu einem abstrakten Typ Junction (Verbindungspunkt) zusammen-gefasst werden.
Ein Parkplatz besitzt ein Attribut Capacity vom Typ Int. Jede Straße besitzt zudem ein Attribut StreetName vom Typ String. Straßen d¨urfen nur mit Verbindungspunkten verbunden werden und umgekehrt, die Kombinationen Verbindungspunkt-Verbindungs-punkt und Straße-Straße scheiden aus. Es d¨urfen minimal 1 und maximal 6 Verkn¨upfun-gen pro Knoten existieren.
GXL
-limits: int x int = 1, 6 from -limits: int x int = 1, 6
to
name : string = CityMap CityMap : GraphClass
name : string = Street isAbstract : bool = false isDirected : bool = false Street : EdgeClass
name : string = StreetName Name : AttributeClass name : string = Junction isAbstract : bool = true
Junction : NodeClass
name : string = Intersection isAbstract : bool = false
Intersection : NodeClass name : string = CarPark isAbstract : bool = false CarPark : NodeClass
name : string = Capacity Capacity : AttributeClass
Abbildung 3.6: Beispiel f¨ur ein Graphenschema in GXL
In der Darstellung des Schemas 3.5 als Instanz des GXL-Metamodells (Abb. 3.2) kann das Beispiel relativ gut ausgedr¨uckt werden (Abb. 3.6), es existiert ein Stadtplan vom Typ GraphClass, Straßen vom Typ EdgeClass, Verbindungspunkte bzw. Kreuzungen und Parkpl¨atze vom Typ NodeClass.
Die Instanzen der Assoziationsklassen from und to k¨onnen zwischen Straßen und Ver-bindungspunkten bestehen, um die Multiplizit¨aten auszudr¨ucken.
Die beiden Attribute k¨onnen mit je einer Instanz der AttributeClass repr¨asentiert werden und verweisen auf ihre entsprechenden Dom¨anen Int und String.
Fazit des GXL-Beispiels
In GXL kann das Beispiel vollst¨andig ausgedr¨uckt werden.
MOF
isAbstract : bool = true Junction : Class
isAbstract : bool = false CarPark : Class isAbstract : bool = false
Intersection : Class
generalizes generalizes
isAbstract : bool = false Street : Association
isAbstract : bool = false String : String
isOfType
isAbstract : bool = false Int : Int Capacity : Attribute contains
isOfType
Abbildung 3.7: Beispiel f¨ur ein Graphenschema in MOF
In MOF (Abb. 3.7) kann kein Objekt CityMap erstellt werden, da keine direkte nicht-abstrakte Aggregation von Modellelementen existiert. Im Diagramm existieren Kanten-typen (also Streets, entsprechend Instanzen der Klasse Association) und Junctions (Ver-bindungspunkte, entsprechend Instanzen der Klasse Class). Verbindungspunkte lassen sich in MOF als abstrakt markieren. Das name-Attribut wurde im Objektdiagramm aus
3.2. Vergleich der Metamodelle von GXL, MOF und ecore Ubersichtlichkeitsgr¨unden weggelassen, da es in allen Objekten vorkommt. Eine Juncti-¨ on kann weiter zu Intersection und CarPark spezialisiert werden, da die abstrakte Klasse Classifier eine Generalizes-Assoziation auf sich selbst besitzt.
Eine Junction beinhaltet eine JunctionRef, welche mittels der exposes und der refersTo Verkn¨upfung auf die beiden AssociationEnds referenziert. Die beiden AssociationEnd-Objekte geh¨oren zur Street und repr¨asentieren ihre Endpunkte, an welcher sie mit einer Junction verkn¨upft wird.
Multiplizit¨aten k¨onnen als multiplicity-Attribute von AssociationEnds ausgedr¨uckt wer-den. Die Attribute StreetName und Capacity k¨onnen ¨ahnlich wie in den anderen Spra-chen als Attribute von Street bzw. CarPark modelliert werden.
Fazit des MOF-Beispiels
In MOF kann das Beispiel nicht vollst¨andig ausgedr¨uckt werden, da die Entsprechung einer Graphklasse fehlt. Zus¨atzlich sind Kantenklassen kompliziert zu modellieren.
ecore
Im ecore-Modell (Abb. 3.8) wird als Graphenklasse ein EPackage verwendet. Dieses beinhaltet ein Objekt vom Typ EClass. ¨Uber die abstrakte Klasse EStructuralFeature k¨onnen die EReferences in einer EClass beinhaltet werden.
Im ecore-Modell existiert keine direkte Entsprechung einer Kantenklasse, im Beispiel wird ein Kantentyp durch zwei EReferences repr¨asentiert, die sich gegenseitig durch eOpposite referenzieren k¨onnen. Durch die eReferences-Verkn¨upfung wird auf eine Junction verwiesen. Das containment-Attribut wird auf false gesetzt, die Kardina-lit¨aten k¨onnen angegeben werden.
Das Capacity-Attribut kann inklusive seiner Dom¨ane EInt als EAttribute dargestellt wer-den.
Nicht modelliert werden kann das Attribut StreetName, da in ecore die EReferences keine Attribute tragen k¨onnen.
Alternativ kann die Kantenklasse als EClass modelliert werden. Damit besteht je eine EReference zwischen der Kantenklasse und der Knotenklasse (Abb. 3.9). Die Kanten-klasse kann in das EPackage aufgenommen werden.
name : string = Intersection abstract : bool = false
Intersection : EClass
name : string = CarPark abstract : bool = false
CarPark : EClass name : string = StreetStart
containment : bool = false lowerBound : int = 1 upperBound : int = 6
StreetRef1 : EReference
name : string = StreetEnd containment : bool = false lowerBound : int = 1 upperBound : int = 6
StreetRef2 : EReference eOpposite
eOpposite
eReferences eReferences
isA isA
CityMap : EPackage
contains
contains contains
name : string = Junction abstract : bool = true
Junction : EClass
name : string = Capacity lowerBound : int = 1 upperBound : int = 1 Capacity : EAttribute
contains
Int : EInt
hasDomain
Abbildung 3.8: Beispiel f¨ur ein Graphenschema in ecore
3.2. Vergleich der Metamodelle von GXL, MOF und ecore
name : string = Intersection abstract : bool = false
Intersection : EClass
name : string = CarPark abstract : bool = false
CarPark : EClass name : string = StreetStart
containment : bool = false lowerBound : int = 1 upperBound : int = 6
JunctionRef : EReference
name : string = StreetEnd containment : bool = false lowerBound : int = 2
name : string = Junction abstract : bool = false
Junction : EClass
name : string = Capacity lowerBound : int = 1 name : string = Street abstract : bool = false Street : EClass name : string = Streetname lowerBound : int = 1
Abbildung 3.9: Alternatives Beispiel f¨ur ein Graphenschema in ecore
Fazit des ecore-Beispiels
In ecore sind Assoziationen wiederum anders modelliert wie in GXL und MOF. At-tribute von Assoziationen lassen sich nur ¨uber einen Umweg modellieren, wenn die Kantenklasse durch eine EClass repr¨asentiert wird.