5.2 Entwurf der Graphtransformationsregeln
5.2.1 Das Ecore-Modell als Graph
Graphtransformationsregeln operieren im Allgemeinen auf attribuierten Graphen. Das Datenmodell attribuierter Graphen besteht, wie aus der Definition des Graphen in Ab-schnitt 2.6.1 ersichtlich, aus Knoten, die Attribute tragen und Kanten. Jede Kante ver-bindet zwei Knoten. Dabei ist eine Kante im einfachsten Fall als Tripel, bestehend aus
Quellknoten, Typ und Ziel definiert. Die Kanten sind damit gerichtet, bleiben jedoch bidirektional traversierbar.
ModGraph nutzt Ecore zur strukturellen Modellierung und hat sich zum Ziel gesetzt, die Regeln auf Instanzen von Ecore-Modellen anzuwenden. Damit ist das im Weiteren genutzte Datenmodell auf Ecore, d.h. auf ein objektorientiertes Datenmodell, festgelegt.
Dies wirkt sich auf die Graphtransformationsregeln aus. Um Graphtransformationsre-geln auf Modellinstanzen anwenden zu k¨onnen, muss zun¨achst untersucht werden, wie die Instanzen als Graphen aufgefasst werden k¨onnen und welchen Einschr¨ankungen sie gegen¨uber dem allgemeinen attribuierten Graphen unterliegen.
Eine Modellinstanz l¨asst sich als Graph auffassen, indem man die Objekte (Instanzen der Klassen) als Knoten und die Links (Instanzen der Referenzen) als Kanten inter-pretiert. Objekte und deren Attribute lassen sich eins zu eins auf Knoten und Knoten-attribute abbilden. Beziehungen weisen jedoch einige Besonderheiten auf, die in den ModGraph-Regeln ber¨ucksichtigt werden m¨ussen.
In Ecore werden den Referenzen Multiplizit¨aten zugeordnet. Sie stellen Beziehungen zwischen Objekten dar, die u.U. auch Enthaltenseinsbeziehungen repr¨asentieren. Diese Beziehungen k¨onnen geordnet sein. Zudem wird zwischen uni- und bidirektionalen Refe-renzen unterschieden. Daraus ergeben sich verschiedene Konsistenzbedingungen1 an die Links:
K1 Referenzielle Integrit¨at: Quell- und Zielobjekt eines Links m¨ussen existieren.
K2 Bidirektionalit¨at: Bei bidirektionalen Referenzen muss zu jedem Vorw¨arts- ein R¨ uck-w¨artslink existieren.
K3 Exklusivit¨at: Jedem Objekt muss ein eindeutiger Beh¨alter zugeordnet sein.
K4 Zyklenfreiheit: Enhaltensseinsbeziehungen d¨urfen keine Zyklen bilden.
K5 Transitives L¨oschen: Wird ein Objekt gel¨oscht, m¨ussen alle enthaltenen Objekte ebenfalls gel¨oscht werden.
K6 Einhaltung der Multiplizit¨at: Die Anzahl der Links darf die durch die Multiplizit¨at der Referenz angegebenen Schranken nicht verlassen.
Wie diese Konsistenzbedingungen bei der Anwendung einer Graphtransformationsregel eingehalten werden, wird nun untersucht.
Unidirektionale Referenzen
Unidirektionale Referenzen sind nur in eine Richtung navigierbar. Sie werden verwendet, um Modelle effizienter zu gestalten, indem unn¨otige R¨uckrichtungen eingespart werden.
Außerdem erfordert die Definition einer unidirektionalen Referenz lediglich eine Erwei-terung der Quellklasse, w¨ahrend die Zielklasse unver¨andert bleibt.
1Die relevanten Textstellen zu den Konsistenzbedingungen K3-K5 in den Standards sind: MOF 2.4 Beta, S. 39, UML Infrastructure 2.4, S. 98 bzw. 113.
Das sonst ¨ubliche Datenmodell des attribuierten Graphen sieht nur bidirektionale (gerichtete) Beziehungen vor. Damit ergeben sich zwei Probleme:
P1 Das L¨oschen eines Knotens im Graphdatenmodell beinhaltet das Entfernen aller adjazenten Kanten. F¨ur das L¨oschen eines Objekts m¨ussen demnach auch die ein-laufenden, nicht navigierbaren Kanten gel¨oscht werden.
P2 Bei der Mustersuche, die zur Ausf¨uhrung der Regel n¨otig ist, k¨onnen Knoten und damit die zugeh¨origen Objekte nicht erreicht werden, wenn sie in der falschen Richtung mit einem bekannten Objekt verbunden sind.
P1muss gel¨ost werden, um die referenzielle Integrit¨at (K1) des Links zu gew¨ahrleisten.
Bez¨uglich des L¨oschens stellt EMF eine passende Hilfsklasse (EcoreUtil) zur Verf¨ugung, die eine Methode zum L¨oschen eines Objekts und seines Kontexts bereit stellt. Damit werden auch alle verbundenen Links gel¨oscht.
P2 kann nur gel¨ost werden, indem jede Regel bereits vor der Mustersuche sicherstellt, dass alle zu suchenden Objekte erreichbar sind. Dies ist in der von ModGraph genutz-ten navigierenden Mustersuche begr¨undet, die Parameter und das aktuelle Objekt als Ausgangspunkt der Suche nutzt. Dazu wird die Validierung verwendet. Sie stellt sicher, dass eine Kante oder ein Pfad (eine Folge von Kanten) existiert, so dass jedes Objekt von einem bekannten Objekt aus erreichbar ist.
Bidirektionale Referenzen
Bidirektionale Referenzen sind in beide Richtungen navigierbar. Sie entsprechen insofern einer Kante im Graphen. Allerdings sind sie in Ecore streng genommen aus zwei auf-einander verweisenden (und damit zu einem Paar zusammengefassten) unidirektionalen Referenzen aufgebaut. Damit ergibt sich folgendes Problem:
P3 Die beiden einzelnen Links m¨ussen konsistent gehalten werden. Es d¨urfen keinerlei inkonsistente Operationen auf den Links ausgef¨uhrt werden.
P4 Vorw¨arts- und R¨uckw¨artslink k¨onnen innerhalb einer Regel inkonsistent spezifiziert werden.
P3 ist durch die Quelltextgenerierung in EMF bereits gel¨ost. Wird ein Link ver¨andert, so wird der gegen¨uberliegende ebenso angepasst. Die Konsistenzbedingung der Bidirek-tionalit¨at (K2) ist demnach nicht verletzt. P4 tritt auf, sobald beide Richtungen der Referenz in der Regel durch Links verschiedener Status eingezeichnet sind. So kann der Vorw¨artslink nicht erstellt oder erhalten werden, w¨ahrend der R¨uckw¨artslink gel¨oscht wird. Eine solche Regel ist nicht anwendbar. Dieses Problem wird durch die Validierung der Regeln ¨uberpr¨uft. Dabei d¨urfen Links grunds¨atzlich nicht zweimal eingezeichnet werden. Da Vorw¨arts- und R¨uckw¨artslink sich gegenseitig bedingen, werden sie als In-stanzen derselben bidirektionalen Referenz aufgefasst. Sie d¨urfen daher nicht gleichzeitig zwischen dem selben Objektpaar in einer Regel vorkommen.
Damit ist auch die Mustersuche von P4 betroffen. Sie fordert die Erreichbarkeit der unbekannten Knoten von bekannten aus, durch Navigation der Links. ModGraph erlaubt die R¨uckw¨artsnavigation eines Links, sofern der (nicht eingezeichnete, jedoch implizit ge-gebene) entgegengesetzte Link existiert. So spielt auch bei der Mustersuche die Richtung des Links, der die bidirektionale Referenz instanziiert, keine Rolle.
Multiplizit¨aten der Referenzen
In Graphen d¨urfen Knoten durch beliebig viele Kanten verbunden werden, sofern Kan-tentypen nur den Quell- und Zieltyp von Knoten einschr¨anken. Wird die mengentheore-tische Definition des Graphen verwendet, so wird dem Wirtsgraphen einfach eine weitere Kante als Tripel aus Quelle, Typ und Ziel hinzugef¨ugt oder eben entfernt.
In Ecore sind den Referenzen jedoch einzuhaltende Multiplizit¨aten (K6) zugeordnet, was zu folgenden Problemen f¨uhrt:
P5 Die maximale Multiplizit¨at einer Referenz darf durch die Anzahl der Links nicht uberschritten werden.¨
P6 Die minimale Multiplizit¨at einer Referenz darf nicht unterschritten werden.
Ecore unterscheidet bei der Codegenerierung bez¨uglich der maximalen Multiplizit¨at in P5 lediglich zwischen einwertigen und mengenwertigen Referenzen. Mengenwertige Re-ferenzen d¨urfen beliebig oft auftreten. Daher k¨onnen sie beliebig oft gesetzt werden und verhalten sich wie die oben genannten Kanten im Graphen. Einwertige Referenzen je-doch werden durch Zuweisungen manipuliert, die einen Seiteneffekt aufweisen. Bei jeder Zuweisung geht der vorher zugewiesene Link verloren. Dies wird in ModGraph toleriert und unterst¨utzt: Ein zus¨atzlicher explizit als zu l¨oschend eingezeichneter Link ist nicht erforderlich.
Allerdings d¨urfen eine einwertige Referenz instanziierende Links nicht mehrmals aus einem Objekt der Regel auslaufen (auch nicht, wenn sie nur implizit durch ihren jeweili-gen entgejeweili-gengesetzten Link eingezeichnet sind), es sei denn, die Ersetzung wird explizit angegeben. Das mehrmalige Auftreten einwertiger Links wird durch die Validierung er-kannt.
EMF garantiert nicht, dass die minimalen Multiplizit¨aten nicht unterschritten werden.
Deshalb wird in ModGraph ebenfalls nicht versucht, P6 zu garantieren.
An dieser Stelle sei angemerkt, dass EMF bei der Modellierung mit Ecore beliebige Zahlenwerte f¨ur die oberen und unteren Schranken zul¨asst. Dies ist ein seltener Son-derfall. ModGraph pr¨uft hier lediglich, dass die Anzahl der Links einer Regel die obere Schranke nicht ¨uberschreitet und ¨uberl¨asst die weitere Verwaltung EMF.
Geordnete Referenzen
In EMF sind derzeit alle mengenwertigen Referenzen geordnet. Sie werden als Listen im-plementiert. In vielen F¨allen ist die Reihenfolge der Links nicht relevant und es wird das
Standardverhalten von EMF genutzt, neue Links am Ende der Liste einzuf¨ugen. Manch-mal ist die Reihenfolge jedoch wichtig, woraus sich f¨ur die Regeln folgendes Problem ergibt:
P7 Die Position beim Einf¨ugen des Links in eine Liste, die eine geordnete mehrwertige Referenz repr¨asentiert, ist nicht definiert.
ModGraph bietet zur L¨osung vonP7 das Konzept der geordneten Links an. Dabei kann angegeben werden, ob ein Link am Anfang, am Ende, an einer bestimmten Stelle oder vor bzw. nach einem angegebenen Element (das durch seinen Namen vorgegeben wird) eingef¨ugt wird.
Enthaltenseinsbeziehungen
EMF unterst¨utzt Containment-Referenzen, die Enthaltenseinsbeziehungen darstellen.
Sie d¨urfen keinerlei Zyklen enthalten (K4). Da sie jedem Objekt h¨ochstens einen Con-tainer zuweisen, unterliegen sie ebenfalls der Exklusivit¨at (K3). Außerdem definieren sie, welche Objekte transitiv gel¨oscht werden m¨ussen (K5). Dadurch entstehen einige Probleme, die in den Regeln ber¨ucksichtigt werden m¨ussen:
P8 Ein Objekt kann potenziell in mehrere Container eingef¨ugt werden.
P9 Durch die Erzeugung von zugeh¨origen Links k¨onnen Zyklen in den Enthaltenseins-beziehungen entstehen.
P10 Ist ein Objekt durch eine Enthaltenseinsbeziehung mit einem zu l¨oschenden ande-ren Objekt verbunden, muss es ebenso gel¨oscht werden.
Zur L¨osung vonP8wird die Eindeutigkeit des Containers in ModGraph zun¨achst ana-log zur Eindeutigkeit einwertiger Referenzen behandelt. Dies ist eine geeignete Methode, solange auch das strukturelle Modell nur einen m¨oglichen Container erlaubt. Da das Ecore-Modell jedoch die Modellierung mehrerer eingehender Containment-Referenzen in eine Klasse erlaubt, muss die Exklusivit¨at des Containers bei Objekten weitergehend gepr¨uft werden: Es d¨urfen keinesfalls mehrere Links, die verschiedene - auf Modellebene erlaubte - Containment-Referenzen instanziieren, in ein Objekt eingehen, da ansonsten die Exklusivit¨at (K3) verletzt ist. Dies muss zur Laufzeit gepr¨uft werden, da sie nicht zwingend in der Regel vorkommen.
Obwohl der direkte Container des Objekts eindeutig ist, k¨onnen sich trotzdem Zyklen in der Containment-Hierarchie aufbauen (P9). Um diese zu erkennen, sind statische und dynamische ¨Uberpr¨ufungen notwendig. Die Regel wird auf Zyklenfreiheit validiert, indem gepr¨uft wird, ob die eingezeichneten Links bereits zu einem Zyklus f¨uhren. Ist dies der Fall, ist die Regel nicht ausf¨uhrbar. Da in der Regel nicht zwingend der gesamte Kontext eines Objekts angegeben ist, muss die Zyklenfreiheit zur Laufzeit nochmals auf der gesamten Instanz gepr¨uft werden. Dies geschieht in einem letzten Schritt der Mustersuche. Damit ist die Zyklenfreiheit eine implizite Anwendbarkeitsbedingung f¨ur die Regel.
Bleibt P10 zu betrachten, zu dessen L¨osung das transitive L¨oschen erfolgreich ver-wirklicht werden muss. Sind Objekte durch eine Enthaltenseinsbeziehung verbunden und wird ein Container gel¨oscht, so m¨ussen alle enthaltenen Objekte ebenso gel¨oscht werden (K5). Die Klasse EcoreUtilstellt eine M¨oglichkeit hierf¨ur bereit, die in ModGraph ge-nutzt wird. Damit hat das L¨oschen eines Objekts einen Seiteneffekt auf andere Objekte.
Dies wirkt sich auch auf die Konsistenz der Graphtransformationsregeln aus. Ein zu l¨oschender Knoten wird ¨uber einer Container-Klasse typisiert, ein zu erhaltender Kno-ten ¨uber einer Klasse innerhalb des Containers. Sind beide durch einen zu l¨oschenden, die Containment-Referenz instanziiernden Link verbunden, ist die Regel inkonsistent.
Dies kann durch die ModGraph Validierung statisch gepr¨uft werden. Es wird gefordert, dass der Container und das beinhaltete Objekt denselben Status aufweisen. Das alleinige L¨oschen des Containment-Links l¨oscht die Objekte im ¨Ubrigen nicht,damit diese dann einem anderen Container zugeordnet werden k¨onnen.
Die Regel wird ebenso inkonsistent, wenn ein in der Containment-Hierarchie ¨uber einem anderen stehendes Objekt gel¨oscht wird, das Objekt innerhalb des Containers je-doch erhalten werden soll und in der Regel zwischen beiden Objekten keine Verbindung besteht. Dies kann statisch nicht gepr¨uft werden. Die Pr¨ufung findet also nach der Mus-tersuche statt, indem gepr¨uft wird, ob ein Pfad aus Containment-Referenzen zwischen dem zu l¨oschenden und dem zu erhaltenden Objekt existiert. Ist dies der Fall, muss die Regelausf¨uhrung scheitern. Man kann dementsprechend auch diese Konsistenzbedingung als implizite Anwendbarkeitsbedingung der Regel auffassen.
Fazit
Nach eingehender Betrachtung der Unterschiede wird klar, dass die Referenzen eines Modells eine komplexere Betrachtung erfordern als Kanten in einem Graphen. Die Ein-haltung der Konsistenzbedingungen f¨uhrt gerade bei großen Modellen zu einer Erh¨ohung der Laufzeit. Dies begr¨undet sich einerseits im L¨oschen, andererseits in der Pr¨ufung auf nicht erlaubte Zyklen bei Enthaltenseinsbeziehungen. Wird ein Objekt gel¨oscht, m¨ussen die enthaltenen Objekte gel¨oscht werden. Ebenso m¨ussen alle einlaufenden Kanten ent-fernt werden. Dazu ist es notwendig, das gesamte Modell zu untersuchen, was letztendlich bei großen Modellen viel Zeit in Anspruch nimmt.
Um hohe Laufzeiten zu vermeiden, w¨are ein konfigurierbarer ModGraph-Generator denkbar, der es dem Nutzer ¨uberl¨asst, welche der Konsistenzbedingungen eingehalten werden. Damit k¨onnte der Nutzer die Laufzeit direkt beeinflussen, indem er die Anzahl der w¨ahrend der Generierung der Regeln zu ber¨ucksichtigenden Konsistenzbedingungen selbst w¨ahlt.