Einbinden der ModGraph-Regeln in ein Xcore-Modell

ModGraph

Abbildung 7.12:Schrittweiser Ansatz zur Generierung von Quelltext

sammen mit dem ausf¨uhrbaren Bugtracker, auf der ModGraph-Homepage⁴ herunterge-laden werden.

7.2.2 Einbinden der ModGraph-Regeln in ein Xcore-Modell

In Abschnitt 5.4 wurde bereits das Xcore-Modell des Bugtrackers generiert und manuell erweitert. Außerdem k¨onnen Xcore-Modelle auch durch das automatisierte Einf¨ugen einer Regel erweitert werden. Die Einbindung der Regeln in ein Xcore-Modell erfolgt mit ModGraph’s Xcore Compiler. Dieser generiert aus regelbasierten ModGraph-Regeln prozedurale Xcore-Operationen, die ein bestehendes Xcore-Modell direkt und nahtlos erweitern. Er ist in [81] ver¨offentlicht.

Die Transformation der Regeln nach Xcore stellt eine Modell-zu-Modell-Transforma-tion von TransformaModell-zu-Modell-Transforma-tionen dar und ist somit eine TransformaModell-zu-Modell-Transforma-tion h¨oherer Ordnung [75]. Diese k¨onnte alternativ auch mit ATL oder QVT realisiert werden (siehe Kapitel 4.1). Da es sich bei Xcore jedoch um ein textuelles Modell handelt, und ModGraph bereits Java-Quelltext generiert, wurde von dieser L¨osung abgesehen. Stattdessen wird eine templatebasierte Modell-zu-Text-Transformation realisiert, indem analog zum Java-Compiler ein Java-Compiler erstellt wird, der die Regeln in Xcore-Code ¨ubersetzt, der in das Xcore-Modell eingef¨ugt wird und damit zu einem Modellbestandteil wird. Dieser Ansatz wird genutzt, da er konziser, lesbarer und einfacher zu verwirklichen ist. Statt komplexe Transformationen ¨uber der abstrakten Syntax aufzubauen, wird eine Regel direkt in Xcores konkrete Syntax ¨ubersetzt.

Die Regeln selbst sind endogene, ¨uberschreibende Transformationseinheiten f¨ur Xcore-Modellinstanzen. Die Generierung von Quelltext einer Programmiersprache ist dabei Xcore ¨uberlassen. Es handelt sich hierbei um einen schrittweisen ¨Ubersetzungsprozess.

Dieser ist in Abbildung 7.12 dargestellt. Neben der existierenden JavaGenerierung ist -sofern Xcore dies zuk¨unftig unterst¨utzt - auch die Erzeugung von Quelltext in einer be-liebigen anderen Programmiersprache m¨oglich. Die ¨Ubersetzung der Regeln nach Xcore bringt zudem eine neue Ausf¨uhrungsm¨oglichkeit mit: Interpretierbarkeit. Xcore-Modelle k¨onnen interpretiert werden und damit ebenfalls die - aus der Regel generierten - Xcore-Operationen, deren Rumpf mit Xbase spezifiziert wird. Damit ist eine Ausf¨uhrung auf Modellebene (wie im

”unabh¨angigen Weg“ in Kapitel 7.1 beschrieben) erreicht. Die genaue Arbeitsweise der Kompilierung einer Regel nach Xcore wird im Folgenden be-trachtet.

4http://btn1x4.inf.uni-bayreuth.de/modgraph/homepage

Auflistung 7.9: Definition der Annotationen im Xcore-Modell

Annotation des Xcore-Modells

Um die ModGraph-Regeln korrekt nach Xcore ¨ubersetzen zu k¨onnen, muss das Modell um OCL-Unterst¨utzung und einige Generator-Modell-Annotationen erweitert werden.

Diese sind in Auflistung 7.9 gezeigt. Die Annotationen stellen sicher, dass der Xcore-Generator mit den korrekten Parametern arbeitet. Sie werden genau einmal in den Kopf des Xcore-Modells eingef¨ugt und sind f¨ur jedes Modell gleich. Zeilen 5-7 der Auflistung definieren die Annotationen und ihre jeweiligen Xcore-Alias. Der Alias dient der Ver-einfachung der Nutzung der Annotationen, indem durch ihn direkt auf die Annotation zugegriffen werden kann. Wie beispielsweise in Zeilen 9 & 10 gezeigt, kann durch Nutzung des Alias, hier@GenModel, die Annotation direkt angesprochen werden. Sie wird verwen-det um Eigenschaften des Generatormodells zu setzen. Dabei wird unn¨otiges Nachladen des Modells vermieden und das Zielverzeichnis der Generierung auf den src-Ordner des aktuellen Eclipse-Projekts festgelegt. Zudem wird die reflektive Operationsausf¨uhrung erlaubt. Sie wird ben¨otigt, um die OCL-Unterst¨utzung zu realisieren. Bez¨uglich OCL werden außerdem die von EMF bereitgestellten Pivot-Evaluatoren eingebunden, siehe Zeilen 5 und 11-13 der Auflistung. Diese wurden aufgrund ihrer strikten Konformit¨at zu den OMG-Standards gew¨ahlt.⁵

Annotation der Operation

In diesem Schritt wird zun¨achst das Xcore-Modell unter Zuhilfenahme seines abstrak-ten Syntaxbaumes durchsucht, bis die modellierte Operation gefunden ist. Zur Umset-zung der Regel wird diese vom ModGraph-Generator - abh¨angig von ihrem Inhalt -annotiert. Eine Generator-Modell-Annotation wird immer erzeugt. Diese wird zu Do-kumentationszwecken verwendet, indem sie die Operation als mit ModGraph generiert markiert. Zudem wird hier der zur Regel angegebene Kommentar eingef¨ugt. Sind in der Regel Vor- oder Nachbedingungen angegeben die in OCL verfasst wurden, so wird f¨ur jede Bedingung eine zus¨atzliche OCL-Annotation ben¨otigt. Betrachtet man die

Um-5N¨aheres zur OMG-Konformit¨at findet sich in der Eclipse Hilfe unter http://help.eclipse.org/

kepler/index.jspunter der Rubrik OCL

Auflistung 7.10:Ausschnitt aus dem Bugtracker Xcore-Modell: Die generierte Methode zur Re-gel changeStatus(Abbildung 7.9)

setzung der bekannten Regel changeStatus, so wird diese zun¨achst mit der Generator-Modell-Annotation versehen, die in Auflistung 7.10 in Zeilen 4 & 5 gezeigt ist. Der zur Regel angegebene Kommentar wird nach der Anmerkung der ModGraph-Generierung der Regel eingef¨ugt. Da die Regel mit einer OCL-Vorbedingung versehen ist, wird die-se in eine OCL-Annotation der Operation ¨ubersetzt, die in Zeile 6 der Auflistung 7.10 gezeigt wird.

Aufbau des Operationsrumpfes

In den Rumpf der Operation wird die Ausf¨uhrungslogik der Regel, wie in Kapitel 6.2 beschrieben, eingef¨ugt und dazu mit Xbase spezifiziert. In einem ersten Schritt wird die Methodendeklaration - sofern noch nicht geschehen - um die Ausnahmebehandlung er-weitert. Danach werden die in Xcore bzw. Xbase spezifizierten Vorbedingungen der Regel gepr¨uft. Diese sind im BeispielchangeStatusnicht vorhanden. Daher beginnt das Beispiel mit dem n¨achsten Schritt: Es werden alle zur Ausf¨uhrung der Regel ben¨otigten Variablen definiert. Dies ist in Zeilen 8 & 9 zu sehen. Im Folgenden werden die Xbase-Operationen

f¨ur die Mustersuche generiert. Dazu werden zun¨achst Hilfsvariablen angelegt, die in Zei-len 10 & 11 definiert sind. Diese dienen der tempor¨aren Ablage der ¨uber einen Link oder einen Pfad gefundenen Objekte, die unter Umst¨anden durch Bedingungen weiter eingeschr¨ankt werden. Dies ist im Beispiel nicht der Fall. Es zeigt den einfachsten Fall der Mustersuche. Beide Objekte, die durch die ungebundenen Knoten repr¨asentiert sind, werden durch einen eine einwertige Referenz instanziierenden Link gefunden und ent-halten keinerlei weitere Bedingungen. Damit werden die tempor¨aren Werte direkt an die tats¨achlichen zugewiesen (Zeilen 12 & 13). Im Falle einer komplexeren Mustersuche werden geschachtelte Schleifen generiert. Diese pr¨ufen alle Bedingungen an die Objekte.

Die Schachtelung der Schleifen spiegelt dabei den bei der Mustersuche gefundenen Baum wieder. Die erste Schleife sucht - vom gebundenen Knoten aus - die direkt erreichbaren Objekte, von welchen aus durch weitere verschachtelte Schleifen die jeweiligen Kindkno-ten gefunden werden. Die Variable enth¨alt hierbei den letzten passenden Fund. Beispiele hierzu finden sich in [81], das eine andere Version des Modell-Refacorings betrachtet. In diesem sind die Regeln ver¨andert, so dass sie zu einer komplexen Mustersuche f¨uhren.

Alternativ k¨onnen Objekte auch durch die Auswertung eines Pfades gefunden werden.

In Auflistung 7.11 werden die Xcore Umsetzungen der RegelnreportedTickets (siehe Ab-bildung 7.10) und createProject (siehe Abbildung 7.11) dargestellt. Die Zeilen 7 & 8 in Auflistung 7.11 zeigen die Auswertung der Pfades in reportedTickets. Der Pfadausdruck muss hierbei in der Regel durch (OCL) eingeleitet werden, da der ModGraph-Generator bei der Xcore-Generierung zun¨achst von Xbase-Ausdr¨ucken an den Pfaden ausgeht. Hier ist ebenso eine Schleife mit Bedingung zur Pr¨ufung der - in der Regel durch den Link reportergegebenen - Zusatzbedingung gezeigt (Zeilen 9-12). Die Pr¨ufung einer NAC wird durch Bedingungen innerhalb der innersten, zur Mustersuche genutzten, Schleife reali-siert. Sind keine Schleifen n¨otig, steht sie gesondert, wie auch in Auflistung 7.11 Zeile 24.

Hier findet die Pr¨ufung der NAC direkt nach der Bedingung an die Parameter der Re-gel statt. In beiden F¨allen wird der funktionale Aufruf findFirst verwendet. Zuerst wird gepr¨uft, ob der ¨ubergebene Nutzer Mitglied der Gruppe ist. Danach wird sichergestellt, dass bei Anlegen eines Projekts keines gleichen Namens existiert.

Wird ein Objekt nicht gefunden, muss eine Ausnahme des Typs GTFailure ausgel¨ost werden. Sind alle Objekte gefunden, werden die Attributwerte aus dem Vorzustand des Modells berechnet und in finalen Variablen, die in Xbase durch val eingeleitet werden, gespeichert. Betrachtet man wieder Auflistung 7.10, sind diese in Zeilen 16 - 20 zu sehen.

Es werden alle sp¨ater an das neu erzeugte Objekt des TypsTicketRevisionzuzuweisenden Attributwerte berechnet. Ihre Benennung erfolgt wiederum nach dem Objektbezeichner und dem Attributnamen erg¨anzt durchValue. Darauf werden die zu l¨oschenden Objekte gel¨oscht, die zu ver¨andernden, erhaltenen Objekte ver¨andert und die zu erstellenden er-zeugt. Im Beispiel wird die neue Revision des Tickets durch den Aufruf einer passenden - von Xcore im Hintergrund generierten - Fabrikmethode erstellt (Zeile 22) und deren Attribute initialisiert (Zeilen 24-28). Dazu werden die im Vorangegangenen berechne-ten Attributwerte genutzt. Im n¨achsten Schritt werden die Links - wie in der Regel angegeben - gel¨oscht oder erzeugt. Hierbei gilt dieselbe Sonderregelung wie bei der Java-Generierung: Einwertige Links, die in derselben Regel gel¨oscht und an anderer Stelle erzeugt sind, werden nicht explizit gel¨oscht. Im Beispiel sind dies Links, welche die neue

Auflistung 7.11:Ausschnitt aus dem Bugtracker Xcore-Modell: Die generierten Methoden zu den Regeln reportedTickets (Abbildung 7.10) und createProject (Abbildung 7.11)

Ticketrevision in ihren Kontext einbetten (Zeilen 30-33). Danach werden die Operatio-nen aufgerufen und die Xcore-Nachbedingungen gepr¨uft. (Die OCL-Nachbedingungen befinden sich in einer Annotation der Operation.) Zuletzt wird der R¨uckgabewert der Operation zur¨uckgegeben. Da das Beispiel changeStatus keine Nachbedingung und kei-nen R¨uckgabewert hat, endet die Operation nach der Erstellung der Links.

Damit ist die Xcore-Generierung abgeschlossen und ein ausf¨uhrbares Xcore-Modell wurde erzeugt. Es kann nun interpretiert und zur Generierung von Quelltext verwendet werden. Der von Xcore generierte Quelltext besitzt grunds¨atzlich die gleiche Struktur wie der EMF-generierte Quelltext. Er ist beispielhaft f¨ur die Operation createProject in Auflistung 7.12 gezeigt. Das Beispiel wurde gew¨ahlt, da an ihm im Folgenden die Umsetzung des funktionalen AusdrucksfindFirst gezeigt werden kann.

Auflistung 7.12: Von Xcore generierter Java-Quelltext zur Implementierung der modellier-ten Operation createProject (Abbildung 7.11) der Klasse BugTracker des Bugtracker-Xcore-Modells