Zusammenfassung der Konzepte

Soeben wurden die in ModGraph zur Spezifikation eines ausf¨uhrbaren Modells genutzten Konzepte vorgestellt. Dabei wurden insbesondere die Graphtransformationsregeln am Beispiel Bugtracker gezeigt. Die Konzepte werden hier zusammengefasst.

Nachdem der Nutzer ein strukturelles Modell unter Verwendung von Ecore oder Xco-re definiert hat, steht ihm im ModGraph-Ansatz die M¨oglichkeit offen, das Verhalten mittels Graphtransformationsregeln zu modellieren.

Jede Graphtransformationsregel implementiert eine Operation des Ecore-Modells. Sie modelliert das Verhalten der Operation. Durch die Nutzung der zusammengef¨uhrten Darstellung f¨ur die linke und rechte Regelseite kann die Regel einen Test, eine Anfra-ge oder eine Transformation darstellen. Tests implementieren Boolesche Operationen.

Diese stellen eine Bedingung an die Instanz. Ihre Ausf¨uhrung f¨uhrt immer zu einem Wahrheitswert, der Aufschluss gibt, ob die betrachtete Instanz die Bedingung erf¨ullt.

Anfragen ¨andern die Instanz nicht, geben jedoch ein einzelnes Objekt oder eine Menge von Objekten zur¨uck. Transformationen f¨uhren, wie der Name sagt, ¨Anderungen auf den Instanzen durch. Sie d¨urfen, wie die Abfragen, einen R¨uckgabewert aufweisen.

Die Kernkomponente einer Graphtransformationsregel ist das Graphmuster. Es gibt das zu suchende Objektmuster innerhalb der Modellinstanz, sowie die ¨Anderungen, wel-che an diesem vorgenommen werden sollen, an. Dazu werden Graphen genutzt. Die Knoten stehen stellvertretend f¨ur Objekte der Instanz, die Kanten stellen die Beziehun-gen zwischen ihnen dar. Zur Modellierung stehen verschiedene Knoten- und

Kantenar-ten zur Verf¨ugung. Knoten werden in einwertige und mehrwertige sowie in gebundene und ungebundene unterschieden. Einwertige Knoten stehen f¨ur Objekte und mehrwer-tige Knoten f¨ur Mengen von Objekten gleichen Typs. Zudem wird zwischen obligato-rischen und optionalen Knoten unterschieden. W¨ahrend ein obligatorischer Knoten zur Ausf¨uhrung der Regel auf ein Objekt der Instanz abgebildet werden muss, kann das Objekt zum optionalen Knoten in der Instanz fehlen. Dies geschieht genau dann, wenn keine ¨Ubereinstimmung zwischen dem Knoten und den Objekten der Instanz gefunden werden kann. Optionale Knoten werden mit << optional >> markiert.

Gebundene Knoten stellen nicht-primitive Parameter der Operation dar. Sie repr¨ asentie-ren ein Objekt, keinen Datentyp. Ist ein solcher Knoten optional, wird er als unter Umst¨anden null-wertig aufgefasst. Parameterknoten werden in der Regel ohne ihren Typ abgebildet, es sei denn, sie unterliegen einer Typumwandlung. Dann wird der ab-weichende Typ angezeigt.

Ein besonderer gebundener Knoten ist derjenige f¨ur das aktuelle Objekt. Er wird in Anlehnung an Programmiersprachen immer mit this benannt und repr¨asentiert das Ob-jekt, auf welchem die Operation aufgerufen wird. Dieser Knoten ist immer obligatorisch.

Neben den gebundenen Knoten werden ungebundene Knoten im Graphmuster ange-boten. Diese m¨ussen zur Laufzeit durch die Mustersuche gefunden werden und sind ¨uber Klassen typisiert. Einwertige ungebundene Knoten stehen f¨ur Objekte der betrachteten Modellinstanz, wohingegen mehrwertige ungebundene Objekte Mengen von Objekten gleichen Typs repr¨asentieren.

Allen Knoten im Graphmuster, ausgenommen dem das aktuelle Objekt repr¨ asentie-rende, ist ein Status zugewiesen. Dieser ist entweder zu erhalten, zu l¨oschen oder zu erzeugen. Zu erhaltende Knoten werden grau hinterlegt, zu l¨oschende rot und mit −−

markiert, zu erzeugende gr¨un und mit ++ gekennzeichnet. Der Status des Knotens f¨ur das aktuelle Objekt kann nicht ver¨andert werden. Es ist implizit zu erhalten. Nicht-primitive Parameter repr¨asentierende Knoten k¨onnen entweder den Status zu erhalten oder zu l¨oschen tragen. Ungebundene einfache Knoten d¨urfen alle drei Status annehmen.

Sie k¨onnen zu erhalten, zu l¨oschen oder zu erzeugen sein. Einwertige Knoten m¨ussen bei ihrer Erzeugung ¨uber konkrete Klassen (nicht abstrakt und kein Interface im EMF-Kontext) typisiert werden. Ungebundene, mehrwertige Knoten d¨urfen nur erhalten oder gel¨oscht werden. Statusbehaftete Knoten d¨urfen ebenso als R¨uckgabeparameter der Ope-ration gekennzeichnet werden. Dies geschieht durch eine Markierung mit << out >>. Sind mehrere Knoten konform zur implementierten Operation als R¨uckgabeparameter markiert, werden diese (als Liste) zur¨uckgegeben. An zu erhaltende und zu l¨oschende Knoten d¨urfen Bedingungen gestellt werden. Diese sind textuell und k¨onnen als OCL-oder Xcore-Bedingung formuliert werden. Zudem sind Bedingungen an Attributwerte m¨oglich. Knoten, die erhalten oder erzeugt werden, k¨onnen Attributzuweisungen und Operationsaufrufe enthalten.

Knoten k¨onnen durch Kanten verbunden werden. Dazu stehen Links und Pfade zur Auswahl. Links sind Instanzen der Referenzen im Modell. Sie d¨urfen zwischen Kno-ten gezogen werden, die Objekte des Typs der Quell- und Zielklasse der Referenz re-pr¨asentieren. Nat¨urlich sind auch Knoten, die auf Objekte einer Unterklasse der Quell-oder Zielklasse verweisen, zul¨assig. Ein Link wird durch den Namen der Referenz

gekenn-zeichnet. Zudem kann jedem Link einer der drei bekannten Status zugeordnet werden.

Dabei ist es unzul¨assig, widerspr¨uchliche Status an Knoten und an die mit ihnen ver-bundenen Links zu vergeben. So kann beispielsweise in einen zu l¨oschenden Knoten kein zu erzeugender Link eingehen. Des Weiteren d¨urfen keine Links - und auch keine Pfa-de - zwischen mehrwertigen Knoten gezogen werPfa-den. Mehrwertige zu erzeugenPfa-de Links k¨onnen geordnet sein. Sie geben an, an welcher Stelle das Objekt in den Link aufgenom-men wird. Dabei sind first, last und die direkte Angabe der Position als Index zugelassen sowie das Einf¨ugen vor oder nach einem namentlich vorgegebenen Objekt. Pfade stellen abgeleitete Referenzen dar und werden mit einem Pfadausdruck beschriftet, der entweder in OCL oder Xcore geschrieben werden kann. Dieser Pfadausdruck wird auf dem durch den Quellknoten des Pfads dargestellten Objekt ausgewertet und liefert mindestens ein Zielobjekt zur¨uck. Stehen mehrere Objekte zur Auswahl, wird aber nur eines ben¨otigt, so wird das erste gefundene genutzt.

Jede Regel kann durch Bedingungen erweitert werden. Dies k¨onnen einerseits textuelle Vor- und Nachbedingungen sein, andererseits d¨urfen durch Graphen dargestellte negati-ve Anwendbarkeitsbedingungen (NACs) negati-verwendet werden, die negati-verbotene Graphmuster darstellen. Die textuellen Bedingungen werden in OCL oder Xcore bzw. Xbase spezifi-ziert. NACs werden durch Graphen dargestellt. Sie stellen Verbote dar. Dies bedeutet, dass sie eine Art Graphtest spezifizieren, der zur Ausf¨uhrung der Regel fehlschlagen muss. Innerhalb der NACs ist nur die Verwendung einwertiger Knoten zul¨assig, da es ausreicht, wenn ein Knoten das modellierte Verbot erf¨ullt. Zudem sind die Knoten und Kanten der NACs statuslos.

Die Ausf¨uhrung der Regeln kann mit Kontrollfl¨ussen gesteuert werden. Sie werden als Xcore-Operationen programmiert. Diese rufen geeignet die durch Regeln implementier-ten Operationen auf. Dabei sind alle g¨angigen Konstrukte wie Schleifen und Bedingungen verf¨ugbar. Zudem besteht die M¨oglichkeit, einfache oder prozedurale Operationen direkt in Xcore zu implementieren. Diese k¨onnen durch einen Operationsaufruf innerhalb der Regeln genutzt werden. Dies kann der reine Aufruf der Operation sein oder die Zuwei-sung ihres R¨uckgabewertes an ein Attribut. Damit arbeiten die Xcore-Operationen und die Regeln symbiotisch.

6 Design der Sprache f¨ ur

Graphtransformationsregeln

Nach der informellen Einf¨uhrung soll die Sprache der Graphtransformationsregeln in ModGraph nun formal dargestellt werden. Bereits in Kapitel 2, Abschnitt 2.3, wur-de gezeigt, welche syntaktischen und semantischen Komponenten n¨otig sind, um eine (ausf¨uhrbare) Sprache vollst¨andig zu beschreiben. Dieser Sprachdefinition folgend, wird hier zuerst die Syntax der Sprache f¨ur Graphtransformationsregeln in ModGraph darge-stellt. Ihre dynamische Semantik wird gesondert in Abschnitt 6.2 untersucht, da sie die gesamte Ausf¨uhrungslogik der Sprache beinhaltet.

Ziel dieses Kapitels ist die pr¨azise Beschreibung der ausf¨uhrbaren Sprache zur Spezi-fikation der Graphtransformationsregeln.

6.1 Syntax der Sprache f¨ ur Graphtransformationsregeln

In diesem Abschnitt wird zun¨achst das Metamodell der Sprache erl¨autert. Darauffolgend wird in Abschnitt 6.1.2 die konkrete Syntax anhand der im Editor f¨ur Graphtransforma-tionen zur Verf¨ugung stehenden Elemente erkl¨art. Hier wird gleichzeitig die lexikalische Syntax betrachtet.