Vergleich der Modelle und Quelltexte

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

7.2.3 Vergleich der Modelle und Quelltexte

In diesem Abschnitt werden die in ModGraph erstellten Modelle und Quelltexte vergli-chen. Dazu werden verschiedene Implementierungen der RegelnchangeStatus(Abbildung 7.9) und createProject(Abbildung 7.11 ) betrachtet.

ModGraph-Regel und Xcore

Stellte man der ModGraph-Regel changeStatus (Abbildung 7.9) die Xcore-Operation (Auflistung 7.10) gegen¨uber, so bleibt die Regel intuitiver als der generierte Quelltext.

Sie ist klar strukturiert und weist immer denselben Aufbau auf. Zudem bietet sie durch ihre graphische Darstellung und die Farbkodierung der Knoten und Kanten eine intuitive Visualisierung des Teilgraphen und der ¨Anderungen an diesem.

Das Xcore-Modell ist klar strukturiert, textuell und unabh¨angig von der Zielsprache.

Außerdem ist es konzise und einfach genug, um f¨ur den Modellierer gut lesbar zu sein.

Dies macht sich insbesondere bemerkbar, sobald die von Xbase angebotenen funktionalen Ausdr¨ucke zum Einsatz kommen.

Vergleicht man konkret die Regel mit dem generierten Xcore-Modell, so f¨allt zun¨achst auf, dass das Xcore-Modell als textuelles Modell gelesen werden muss, um eine Idee seiner Funktionalit¨at zu bekommen, wohingegen die Regel schneller zu erfassen ist. Zu-dem ist im Xcore-Modell bereits die Mustersuche explizit angegeben (Zeilen 8-15 in Auflistung 7.10) und die Attributwerte werden in den folgenden Zeilen aus dem Vor-zustand berechnet. Beides gibt die Regel implizit vor. Zus¨atzlich sei bemerkt, dass die Xbase-Spezifikation f¨ur die Mustersuche - w¨are sie per Hand geschrieben - etwas k¨urzer gefasst werden k¨onnte. Zeilen 8-16 k¨onnten in zwei Zeilen komprimiert werden. Dies ist jedoch nur der Fall, solange keine zus¨atzlichen Bedingungen an die Knoten gestellt sind: Da der Generator allgemeinen Quelltext generiert, werden Variablendeklaratio-nen definiert, die erst nach erfolgreicher Mustersuche zugewiesen werden. Damit wird zweckm¨aßig der Erfolg der Mustersuche gepr¨uft. Ist sie erfolglos, bleiben die Variablen, welche die endg¨ultigen Objekte repr¨asentieren, null. Diese Art der Zuweisung deckt den allgemeinsten Fall ab, in welchem die Mustersuche in (unter Umst¨anden geschachtel-ten) Schleifen stattfindet. Das ist weder ¨uberraschend noch un¨ublich. Trotzdem bleibt das Xcore-Modell gut lesbar, was f¨ur die Fehlersuche durch Debuggen im Vergleich zum generierten Quelltext sehr von Vorteil ist.

Die weiteren Zeilen 22-33 in Auflistung 7.10 der Xcore-Implementierung der Operation bilden die Regel geordnet und relativ direkt ab. Lediglich der Umweg ¨uber die berech-neten Attributwerte muss in Kauf genommen werden. F¨ur das Attribut title der Regel bedeutet dies, dass die Zuweisung in der Regel sich in zwei Zuweisungen der Xcore-Operation aufspaltet: die Wertberechnung (Zeile 16) und die Zuweisung dieses Wertes (Zeile 24).

Betrachtetet man die RegelcreateProject(Abbildung7.11) und deren Xcore-Implemen-tierung in Auflistung 7.11, so scheint die Abbildung der Regel auf Xcore nahezu direkt.

Zun¨achst wird der Link zwischen den beiden Parameterknoten durch eine Bedingung ausgedruckt (Zeile 13). In einer weiteren Bedingung folgt die Pr¨ufung der NAC (Zeile 24).

Die Erzeugung des Projekts und seines Kontexts erfolgt, wenn beide Bedingungen erf¨ullt sind. Da hier keine aufw¨andige Mustersuche notwendig ist, wirkt die generierte Xcore-Operation ¨ubersichtlich und gut lesbar, dennoch bleiben die oben genannten Argumente auch hier g¨ultig. So muss sich die Xcore-Operation, im Gegensatz zur Regel, mit der Fehlerbehandlung und der genauen Spezifikation der Fabrikmethode zur Erzeugung des Projekts besch¨aftigen, was bei Modellierung der Regel implizit geschieht.

Xcore und daraus generierter Java-Quelltext

Vergleicht man den gesamten von Xcore generierten Quelltext zur Operation create-Project(...)der Klasse BugTrackeraus Auflistung 7.12 mit dem Xcore-Modell, so er-scheint dieser un¨ubersichtlicher und l¨anger, aber dennoch (im unteren Teil, der die Zuwei-sungen enth¨alt) recht ¨ahnlich. Werden keine Xbase-spezifischen funktionalen Lambda-Ausdr¨ucke verwendet, ist der Quelltext dem Modell umso ¨ahnlicher. Diese stellen also einen echten Abstraktionsgewinn gegen¨uber Java dar. Der hier betrachtete

findFirst-Aufruf ist ein Einzeiler im Xcore-Modell (Auflistung 7.11, Zeilen 23 oder 24). Jeder dieser Einzeiler sorgt in Java f¨ur den Aufruf einer Funktion (Auflistung 7.12, Zeilen 9 bzw. 20 & 21), die eigens zuvor definiert wird (Zeilen 4-8 bzw. 13-19 der Auflistung).

Hier wird der Vorteil von Xcore mit Xbase gegen¨uber Java deutlich.

Zudem werden die - in Xcore ¨ublichen - verk¨urzten Schreibweisen korrekt in Java-Ak-zessoren ¨ubersetzt. Leider ist die OCL-Unterst¨utzung in Xcore nicht ausgereift.⁶ Auf-grund dessen und zu Gunsten einer Verbesserung der Laufzeiten (siehe Kapitel 10.1.1) kann nur geraten werden, die Vor- und Nachbedingungen in Xcore bzw. Xbase zu de-finieren. Dieser Vorschlag wird im Weiteren ebenso verfolgt und findet in Kapitel 8 Verwendung.

Von ModGraph generierter Java-Quelltext

Der aus einer Regel direkt generierte Quelltext steht nicht in Konkurrenz zum Xcore-Modell. Er stellt eine alternative Verwendung dar.

Vergleicht man den generierten Java Quelltext zur RegelchangeStatus(Abbildung 5.8) und den daraus generierten Java-Code ( Auflistungen 7.3, 7.4 und 7.6), so ist der Quell-text, bereits durch die Dreiteilung un¨ubersichtlicher und l¨anger als eine Regel. Zudem befindet er sich auf einer deutlich niedrigeren Abstraktionsebene. Die Mustersuche und die Fehlerbehandung m¨ussen beispielsweise explizit erfolgen.

Vergleicht man den ModGraph-generierten Quelltext und das Xcore-Modell (Auflis-tung 7.10), so findet sich dieser (ebenso wie der direkt aus dem Xcore-Modell generierte) auf einer niedrigeren Abstraktionsebene, da auch er keine abstrakten Sprachkonstrukte wie Lambda-Ausdr¨ucke anbieten kann.

Bei Betrachtung des Xcore-generierten (Auflistung 7.12) und des von ModGraph er-stellten Quelltexts, ist der aus Xcore erzeugte zwar auf eine Klasse bzw. eine Operation beschr¨ankt, bleibt f¨ur den Nutzer jedoch wesentlich schlechter lesbar. Grund hierf¨ur ist die Nutzung zahlreicher Hilfsvariablen und -funktionen, beispielsweise um Negationen auszudr¨ucken. Der ModGraph-generierte Quelltext ist geradliniger. Er ¨ubersetzt eine Regel in Methoden, die gr¨oßtenteils auf der Java-Standardbibliothek aufbauen. Ledig-lich im f¨ur die Mustersuche generierten Code finden sich wenige Abh¨angigkeiten zu ModGraph-Bibliotheken. Damit bleibt er recht gut lesbar.

Fazit

Zusammenfassend unterst¨utzen diese Aussagen die Grundideen des ModGraph-Ansatzes.

Die Graphtransformationsregel bietet die h¨ochste Abstraktionsebene und sollte zur Spe-zifikation von komplexen strukturellen ¨Anderungen genutzt werden. Hier bietet sie einen echten Mehrwert. Das Xcore-Modell ist, wie die Regel selbst, konzise, gut lesbar und einfach zu verstehen. Dennoch bietet es eine etwas geringere Abstraktionsebene als eine

6Diese Bemerkung bezieht sich auf Eclipse Kepler SR2. Da der Generator lediglich genutzt und nicht im Rahmen von ModGraph entwickelt, wird kann nur gehofft werden, dass die Entwickler von Xcore dies schnellstm¨oglich beheben.

ModGraph-Regel, da die Mustersuche explizit ber¨ucksichtigt werden muss. Das Xcore-Modell ist zudem portabel, da Xcore in beliebige Programmiersprachen ¨ubersetzt werden k¨onnte. Der Java-Quelltext, egal ob er von Xcore oder direkt aus der Regel generiert ist, bleibt nach wie vor auf niedrigster Abstraktionsebene. Zwar ist insbesondere der von ModGraph direkt aus der Regel generierte Quelltext f¨ur den Programmierer lesbar und verst¨andlich, dennoch bietet er nicht die ¨Ubersichtlichkeit der Modelle an. Damit ist der schrittweise Transformationsansatz eine gute L¨osung.