Story-basierte Ans¨ atze

Die Werkzeuge Fujaba, MDELab und eMoflon nutzen alle drei den sog. Story-basierten Ansatz, welcher, bez¨uglich der in Abschnitt 2.6 skizzierten Ans¨atzen unter der Kategorie algorithmischer Ansatz anzusiedeln ist. Es handelt sich hierbei um einen Ansatz, der programmierte Graphersetzungssysteme nutzt. Das UML-nahe Fujaba bildet historisch gesehen den Anfang. MDELab und eMoflon realisieren den Story-basierten Ansatz f¨ur EMF auf verschiedene Arten. W¨ahrend eMoflon auf Fujaba aufbaut und dieses erweitert, ist MDELab eine Reimplementierung, die sich auf die EMF-basierte Interpretation von Modellen spezialisiert hat. Die Werkzeuge werden im Folgenden beginnend mit Fujaba erl¨autert.

Fujaba, ein Akronym f¨ur

”From Uml to Java And Back Again“, ist eine objektorien-tierte Modellierungsumgebung, die UML-Klassendiagramme zur Modellierung der sta-tischen Struktur sowie Storydiagramme zur Verhaltensmodellierung bietet. Fujaba wird haupts¨achlich an der Universit¨at Kassel entwickelt und in diesem Abschnitt anhand von Norbisrath et al. [55] und Z¨undorf [83] erkl¨art.

Fujaba verwendet UML-Klassendiagramme zur Strukturbeschreibung und Storydia-gramme zur Beschreibung des Verhaltens. Ein Storydiagramm realisiert genau eine Me-thode aus dem Klassendiagramm. Ein Storydiagramm basiert auf einem UML-Aktivit¨ ats-diagramm und stellt daher ein Kontrollflussats-diagramm dar. Der Kontrollfluss hat einen

definierten Startpunkt und einen oder mehrere definierte Endpunkte. Dazwischen be-finden sich Aktivit¨aten, die durch Kontrollflusselemente verbunden sind. Kontrollfluss-elemente sind zun¨achst Sequenzen, While-Schleifen und Wenn-Dann-Bedingungen (ana-log zu den UML-Aktivit¨atsdiagrammen). Zudem k¨onnen Ausnahmen durch spezielle Ausnahme-Kontrollflusselemente behandelt werden und R¨uckgabewerte definiert wer-den. Letztere werden am Endpunkt des Storydiagramms definiert. Hier k¨onnen unter anderem rekursiv Methoden aufgerufen werden.

Aktivit¨aten werden in der Regel einmal ausgef¨uhrt. Eine spezielle Aktivit¨at ist die For-Each-Aktivit¨at. Diese f¨uhrt ihren Inhalt und eventuell als zugeh¨orig gekennzeichnete folgende Aktivit¨aten solange aus, bis keine Anwendungsm¨oglichkeit mehr besteht.

Der einfachste Bestandteil einer Aktivit¨at in einem Storydiagramm ist ein Statement, das ein reines Java-Quelltextfragment beinhaltet. Da die Statements innerhalb der Akti-vit¨at beliebig angeordnet sein k¨onnen, ist es n¨otig, deren Ausf¨uhrungsreihenfolge durch eine fortlaufende Nummerierung sicherzustellen, sofern sie Operationsaufrufe darstellen.

Handelt es sich um eine reine Statementaktivit¨at, also ein Java-Quelltextfragment, so ist keine Nummerierung n¨otig. Zudem d¨urfen Aktivit¨aten boolsche Bedingungen ent-halten, die als Abfrage an den aktuellen Zustand des Modells dienen. Sie haben zwei ausgehende Kontrollflusskanten f¨ur den Erfolg bzw. das Scheitern dieser Bedingung. Sel-biges gilt f¨ur komplexere Aktivit¨aten. Sie werden Story-Muster genannt und beinhalten Objekt-Muster, die nichts anderes als Graphtransformationsregeln darstellen. Die Ob-jekte innerhalb der Story-Muster werden zur Laufzeit auf die aktuelle Objektstruktur abgebildet. Gelingt dies, werden die spezifizierten Aktionen ausgef¨uhrt und das Story-Muster wird ¨uber die Kante, welche den Erfolgsfall repr¨asentiert, verlassen.

Die Objekte innerhalb der Story-Muster werden in gebundene und ungebundene Ob-jekte unterschieden, die durch Links verbunden sind. ObOb-jekte sind ¨uber den Klassen im UML-Klassendiagramm typisiert, Links ¨uber deren Assoziationen. Wird ein Objekt in einem Story-Muster gebunden, so kann es in jedem darauffolgenden als gebunden ange-nommen und durch seinen Namen eindeutig identifiziert werden. Bereits zu Anfang ist das this-Objekt gebunden, welches - analog zu Java - dem Objekt entspricht, auf dem die Methode aufgerufen wurde. Das gilt ebenfalls f¨ur die Parameter der Methode. Un-gebundene Objekte werden w¨ahrend der Mustersuche gebunden. Objekte k¨onnen Attri-butbedingungen und -zuweisungen enthalten. Dar¨uber hinaus k¨onnen auf jedem Objekt - mittels Java-Statements - Methoden aufgerufen werden. Jedes Objekt und jeder Link kann erzeugt, erhalten oder - unabh¨angig von seinem Kontext - gel¨oscht werden. Ne-ben den Links d¨urfen, analog zu PROGRES, Pfade definiert werden. Fujaba stellt zur Definiton der Pfadausdr¨ucke eine eigene Ausdruckssprache bereit. Zudem besteht die M¨oglichkeit, negative Objekte und Links einzuf¨uhren. Sie bilden eine Alternative zur NAC, stellen also ebenfalls nicht erlaubte Sachverhalte dar. Fujaba bietet mehrwertige und optionale Objekte an, die lediglich erhalten oder gel¨oscht werden d¨urfen.

Fujabas grafische Modellierungsumgebung wurde zun¨achst außerhalb von Eclipse ent-wickelt. Zudem bietet Fujaba4Eclipse eine in Eclipse integrierte Variante. Fujaba erzeugt durch Modell-zu-Text-Transformationen lauff¨ahigen Java-Quelltext aus den Diagram-men. Eine M¨oglichkeit zur Interpretation der Diagramme besteht ebenso.

Fujaba und dessen Dokumentation ist unter http://www.fujaba.de/verf¨ugbar.

eMoflon nutzt und erweitert Fujaba. Es ist ein Werkzeug zur Erstellung von Werk-zeugen auf Basis von uni- und bidirektionalen Modelltransformationen. Dazu wird eine Umgebung zur Spezifikation von Klassendiagrammen, Story-basierten Graphtransfor-mationsregeln und Tripelgraphgrammatiken bereitgestellt. eMoflon wird am Fachgebiet Echtzeitsysteme (ES) der Technischen Universit¨at Darmstadt entwickelt und im Folgen-den anhand von Anjorin et al. [6] und Leblebici et al. [48] erkl¨art. eMoflon ist in zwei Frontends zur Metamodellierung und einem Backend, um Quelltext zu generieren und mit diesem zu arbeiten, modularisiert. Es stellt ein textbasiertes Frontend auf Basis von Eclipse und ein grafisches Frontend, das auf dem kommerziell UML-Werkzeug Enterprise Architect aufbaut, zur Verf¨ugung.

Das Enterprise-Architect-Frontend erlaubt das Erstellen von Metamodellen mit UML-Klassendiagrammen, nutzt Storydiagramme zur unidirektionalen Modelltransformation und Tripelgraphgrammatiken zur bidirektionalen Modelltransformation. Zudem bietet das Frontend ein Interface zum Backend: Klassendiagramme, Storydiagramme und Tri-pelgraphgrammatiken werden in einem Ecore- bzw. EMF-konformen XMI persistiert. Es dient als Austauschformat zwischen Frontend und Backend.

Das eMoflon-Backend besteht aus mehreren Eclipse-Plugins. Hier wird eine EMF kon-forme Quelltextgenerierung aus den Klassendiagrammen, den Storydiagrammen und den Tripelgraphgrammatiken erm¨oglicht.

Die Verarbeitung der Daten aus dem Frontend beginnt mit dem Laden der seriali-sierten Modelle. Im n¨achsten Schritt werden die Tripelgraphgrammatiken in eine Menge von Storydiagrammen umgewandelt. Diese erzeugten und die geladenen Storydiagramme werden zusammen mit dem Klassendiagramm in Fujaba umgewandelt. Fujaba’s Model-transformationseinheit CodeGen2, die mit EMF-kompatiblen Templates rekonfiguriert wurde, wird nun genutzt, um Quelltext zu erzeugen. Zudem wird aus dem geladenen Klassendiagramm mittels der EMF-Codegenerierung (siehe Abschnitt 3.4) Quelltext erzeugt. Die entstandenen Quelltexte werden automatisch verschmolzen, so dass ein lauff¨ahiges Programm entsteht.

Die aktuelle Version von eMoflon sowie die Dokumentation dazu finden sich unter http://www.moflon.org/.

MDELab beinhaltet, neben anderen Werkzeugen, ein Graphtransformationswerk-zeug namens SDMTools, das Ecore-Klassendiagramme zur Beschreibung der statischen Struktur nutzt. Es bietet einen grafischen Editor und einen Interpreter f¨ur Storydia-gramme, die hier anhand von Giese et al. [36] skizziert werden. MDELab wird am Hasso-Plattner-Institut in Potsdam entwickelt und ist von Beginn an f¨ur Eclipse und EMF ent-worfen worden. Es ist eine Reimplementierung von Fujaba, die UML-Klassendiagramme durch Ecore-Klassendiagramme ersetzt und OCL zur Spezifikation von Bedingungen un-terst¨utzt.⁶ Zudem ist keine Quelltext-Generierung vorgesehen, so dass Java-Statements, die sich auf generierten Quelltext beziehen w¨urden, ausfallen. Sie werden durch speziel-le Aktionsknoten ersetzt. Das Storydiagramm-Metamodell ist selbst ein Ecore-Modell.

Storydiagramme sind Instanzen dieses Metamodells und die Objekte im Storydiagramm

6Eine OCL-Integration gab es zudem in einem prototypischen Ansatz f¨ur Fujaba, der es nicht bis zum Release Stadium geschafft hat [74].

sind ¨uber einem Ecore-Klassendiagramm typisiert. Storydiagramme in MDELabs SDM-Tools sind auf Interpretation spezialisiert. Der Interpreter nutzt ausschließlich die - in dynamischem EMF verwendeten - generischen Methoden. Die Interpretation der Sto-rydiagramme ¨uber einem EMF-Modell entspricht einer endogenen, ¨uberschreibenden Transformation. Um diese anzustoßen, muss explizit eine Methode des Interpreters auf-gerufen werden. Dieser werden das Storydiagramm, das interpretiert werden soll, sowie die Parameter der Methode, die es implementiert und das Kontextobjekt ¨ubergeben.

Dies bedeutet, dass der Endanwender auf den Interpreter beschr¨ankt ist, um mit Mo-dellinstanzen zu arbeiten. Eine Generierung von Quelltext ist hier nicht vorgesehen, M¨oglichkeiten zum Debuggen sind vorhanden.

Die aktuelle Version von MDELab kann unter https://www.hpi.uni-potsdam.de/

giese/public/mdelab/heruntergeladen werden. Dort befindet sich auch die Dokumen-tation.