• Keine Ergebnisse gefunden

4.2 Ans¨ atze und Werkzeuge zur graphbasierten Transformation

4.2.4 Andere Ans¨ atze

In diesem Abschnitt werden weitere Ans¨atze zur Graphtransformation behandelt, die sich in keine der eben eingef¨uhrten Kategorien eingliedern lassen.

GReAT,ein Akronym f¨ur

”Graph REwriting And Transformation“, ist eine grafische Sprache, die es erlaubt, Graphtransformationen zwischen verschiedenen dom¨ anenspezi-fischen Modellierungssprachen zu erstellen. Sie wird hier anhand von Agrawal et al. [5]

und Balasubramanian et al. [9] erl¨autert. GReAT besteht aus drei Sprachen: die erste Sprache dient der Spezifikation von Graphmustern, die zweite der Erstellung von Trans-formationsregeln und die dritte Sprache wird zur Sequenzierung beziehungsweise zur Spezifikation von Kontrollfl¨ussen verwendet. Die Ein- und Ausgabemodelle der Transfor-mation werden zus¨atzlich durch UML-Klassendiagramme definiert, die als Metamodelle agieren. Zudem erlaubt GReAT die Erstellung von heterogenen Klassendiagrammen, die die Beziehungen zwischen Ein- und Ausgabemodellen herstellen.

Eine Transformation wird in GReAT ¨uber einer Menge von Ein- und Ausgabemodellen und einem heterogenen Klassendiagramm spezifiziert. Die Transformationsregel selbst setzt sich aus mehreren Bestandteilen zusammen, die im Folgenden skizziert werden.

Das Graphmuster der Regel ist aus Knoten, die ¨uber Klassen des zugeh¨origen Eingabe-modells, und Kanten, die ¨uber Assoziationen dieses Modells typisiert sind, aufgebaut.

Beiden d¨urfen beliebig Kardinalit¨aten zugewiesen werden. Es besteht die M¨oglichkeit NACs zu spezifizieren. All diese Knoten und Kanten werden zur Mustersuche f¨ur den Wirtsgraphen verwendet. Die Aktionen innerhalb der Regel definieren, ob ein Element gebunden, gel¨oscht oder erzeugt werden soll. Eingangs- bzw. Ausgangsinterfaces be-stehen aus Ports und dienen zur ¨Ubergabe von Graphobjekten an die Regel bzw. zur Weitergabe von Graphobjekten an andere Regeln.

Ein W¨achter ist ein boolscher Ausdruck, der bestimmt, ob die Aktionen der Regel nach einer erfolgreichen Mustersuche auf dem Wirtsgraphen ausgef¨uhrt werden sollen. Durch Attributabbildungen k¨onnen ¨ubereinstimmende Attribute der Knoten und Kanten neue Werte erhalten. Zus¨atzliche Bedingungen legen fest, welche w¨ahrend der Mustersuche gefundenen ¨Ubereinstimmungen im Wirtsgraphen transformiert werden.

Die Sprache zur Kontrollflussspezifikation stellt verschiedene M¨oglichkeiten bez¨uglich der Ausf¨uhrungsreihenfolge der Regel bereit. Die sequenzielle und rekursive Ausf¨uhrung entsprechen den aus Programmiersprachen bekannten Kontrollstrukturen. Zus¨atzlich kann eine Regel nichtdeterministisch, hierarchisch oder bedingt ausgef¨uhrt werden. Nicht-deterministische Ausf¨uhrung bedeutet, dass eine Regel aus einer vorgegebenen Regel-menge ausgew¨ahlt wird. Hierarchische Ausf¨uhrung bedeutet, dass die Regeln zuvor in hierarchisch aufgebaute, strukturierte Bl¨ocke gruppiert wurden. Es existieren zwei Arten von Bl¨ocken, die sich in der Verarbeitung der ihnen ¨ubergebenen Graphobjekte unter-scheiden. Die bedingte Anwendung besteht aus Testbl¨ocken, die wiederum verschiedene Fallunterscheidungsbl¨ocke beinhalten, die solange ausgef¨uhrt werden, bis der erste Fall erfolgreich ist.7

Zur Ausf¨uhrung der Transformationen stehen ein Interpreter, ein darauf aufbauender Debugger und ein C++-Generator zur Quelltextgenerierung zur Verf¨ugung. Diese sind auch in der aktuellen Version von GReAT enthalten. Sie findet sich unter http://www.

isis.vanderbilt.edu/tools/GReAT.

GrGen.NET ist ein dom¨anen-unabh¨angiges Graphersetzungssystem. Es basiert auf dem algebraischen Ansatz, ist jedoch am Karlsruher Institute of Technology (KIT) entstanden und l¨asst sich, wie im Folgenden klar wird, nicht den Berliner Ans¨atzen aus Abschnitt 4.2.1 zuordnen. Bei der Entwicklung von GrGen.NET standen die Aus-drucksm¨achtigkeit der Sprache, die Ausf¨uhrungsgeschwindigkeit und die Benutzerfreund-lichkeit sowie die korrekte Umsetzung des algebraischen Ansatzes, genauer des SPO-Ansatzes (siehe [66], Kap. 4), im Mittelpunkt. Es wird hier anhand von Jakumeit et al.[43] und Geiß et al. [35] betrachtet.

GrGen.NET setzt sich aus zwei Komponenten zusammen: dem Graphersetzungssys-tem GrGen und einer Umgebung zum Rapid Prototyping, die sich wiederum aus der Konsole GrShell und dem Graph-Viewer yComp zusammensetzt.

Die Einbindung von GrGen bietet - in Verbindung mit seiner Ausf¨uhrungsumgebung libGr - die Basisfunktionalit¨at des Systems. Zur Beschreibung von Graphen nutzt GrGen attribuierte, getypte und gerichtete Multigraphen, die Mehrfachvererbung auf Knoten-und Kantentypen sowie gerichtete Knoten-und ungerichtete Kanten erlauben. Die Definition der Typen erfolgt dabei gesondert. Die Graphtransformation selbst wird in einer textuellen DSL dargestellt. Graphtransformationen in GrGen bieten Graphtests - die je aus einem zu pr¨ufenden Graphmuster bestehen - und Graphtransformationsregeln an. Dabei ist auch hier eine Regel aus einem Test (einem Graphmuster) und einem Anwendungsteil aufgebaut. Das Graphmuster beinhaltet typisierte Knoten und Kanten. (Bei Kanten ist die Typ-Angabe optional.) Dabei ist die zus¨atzliche Spezifikation von NACs, Typ-und Attributbedingungen m¨oglich. Zur weiteren Einschr¨ankung ihrer Anwendbarkeit sind die Transformationen parametrisierbar, so dass bestimmte Objekte innerhalb des Graphmusters bereits vorgegeben sind. Des Weiteren es ist m¨oglich, die Mustersuche homomorph zu gestalten, um zwei Knoten im Graphmuster auf dasselbe Objekt im Wirtsgraphen abzubilden.

7Dies ist analog zu den Mehrfachverzweigungen mit switch-case in objektorientierten Programmier-sprachen zu sehen.

Bez¨uglich des Anwendungsteils einer Regel unterscheidet GrGen Modifikations- und Ersetzungs-Bl¨ocke. Ein Modifikations-Block erh¨alt bei seiner Anwendung alle Graphele-mente, die nicht explizit gel¨oscht werden sollen. Bei Anwendung eines Ersetzungs-Blocks werden nur die explizit auf der rechten Seite angegebenen Elemente erhalten. Kommen in einem Ersetzungs-Block neue Elemente vor, so wird dies als Deklaration der Elemente aufgefasst und sie werden erzeugt. Zudem k¨onnen in beiden Blockarten Attributwerte neu berechnet und Elementen ein neuer Typ zugewiesen werden. Bei der Erzeugung neu-er Elemente kann dneu-eren Typ dynamisch festgelegt wneu-erden, indem ein Typ eines andneu-eren bei der Mustersuche gebundenen Elements verwendet wird. Zus¨atzlich kann jede Regel Elemente, die nicht gel¨oscht wurden, zur¨uckgeben.

GrGen bietet M¨oglichkeiten zur Steuerung der Ausf¨uhrung der Regeln an. Dazu wer-den logische und regul¨are Ausdr¨ucke verwendet. Außerdem k¨onnen innerhalb der Kon-trollflusssprache Variablen deklariert werden, die den R¨uckgabewert einer Regel spei-chern und diesen gegebenenfalls als Parameter an eine andere Regel ¨ubergeben.

Der GrGen-Generator liest Dateien, die Graph-Modelle und Graphtransformations-regeln beinhalten, ein und erzeugt daraus effiziente C#-Programme. Diese Programme nutzen die GrGen-Laufzeit-Bibliotheken, welche unter anderem eine Sprache zur Kon-trolle der Regelanwendung anbietet. Graphmodelle, Regeln und Sequenzen von Regeln k¨onnen von jeder .NET-Sprache aus aufgerufen werden. Des Weiteren bietet GrGen.NET einen grafischen Debugger und die interaktive oder dateibasierte Ausf¨uhrung der Regeln, die auch schrittweise erfolgen kann.

Die aktuelle Version von GrGen.NET sowie die Dokumentation des Werkzeugs finden sich unter http://www.info.uni-karlsruhe.de/software/grgen/.

Viatra2oder VIsual Automated model TRAnsformations 2 vereint Graphtransforma-tionen mit abstrakten Zustandsautomaten, um graphbasierte Modelle zu manipulieren.

Viatra2 wird im Folgenden anhand von V´arr´o und Balogh [76, 10] beschrieben.

Hauptziel bei der Entwicklung des Viatra2-Transformations-Rahmenwerks ist die Un-terst¨utzung von pr¨aziser modellbasierter Systementwicklung unter Zuhilfenahme von unsichtbar bleibenden formalen Methoden. Viatra2 besteht selbst aus drei textuellen DSLs: Die erste dient der Metamodellierung, die zweite der Musterspezifikation und die verbleibende dritte der regelbasierten Modelltransformation mit Graphtransformations-regeln und abstrakten Zustandsautomaten.

Die Metamodellierungssprache von Viatra2 baut auf dem

”Visual and Precise Me-tamodelling“-Ansatz von V´arr´o und Pataricza [77] auf, der Modelle einheitlich mittels Modellelementen, die in Entit¨aten und Beziehungen unterschieden werden, darstellt. Da f¨ur diesen Ansatz lediglich eine abstrakte Syntax definiert wurde, wird die passende kon-krete Syntax namens Viatra Textual Metamodeling Language (VTML) durch Viatra2 bereitgestellt. In VTML ist jedes Element mittels eines qualifizierten Namens modellweit eindeutig bezeichnet und zudem durch seinen Namen eindeutig innerhalb seines Con-tainers. VTML unterst¨utzt die Vererbung von Modellelementen und deren Typisierung mittels anderer Modellelemente. Zudem sind Entit¨aten immer innerhalb eines Contai-ners. Referenzen k¨onnen Kardinalit¨aten zugeordnet werden und sie d¨urfen beliebige Mo-dellelemente als Quelle und Ziel aufweisen. Durch diesen Aufbau k¨onnen MOF-Modelle simuliert werden. Viatra2 wird zudem in den Kontext der f¨ur den ModGraph-Ansatz

relevanten Werkzeuge aufgenommen.

Die Sprache Viatra Textual Command Language (VTCL) zur Spezifikation von Mo-delltransformationen in Viatra2 beinhaltet Graphmuster, die als atomare Einheit aufge-fasst werden und Bedingungen an ein Modell stellen. VTCL unterst¨utzt dabei einfache und negative Graphmuster, die in einer Prolog-¨ahnlichen Syntax spezifiziert werden. Dies bedeutet, dass alle Graphmuster einen Namen, Parameter und einen Rumpf besitzen.

Der Rumpf darf wiederum Elemente aus VTML sowie negative Graphmuster enthal-ten. Dabei darf ein negatives Graphmuster kein weiteres negatives Muster beinhalenthal-ten.

Zudem k¨onnen Bedingungen innerhalb des Musters gestellt werden. Ein Graphmuster kann ein anderes aufrufen oder mehrere alternative R¨umpfe spezifizieren. Letzteres ist insbesondere bei der Nutzung rekursiver Graphmuster von Bedeutung: Der erste Rumpf enth¨alt normalerweise das Abbruchkriterium, alle weiteren bilden rekursive Aufrufe.

Die Sprache zur Erstellung von Modelltransformationen enth¨alt sowohl M¨oglichkeiten zur Modell-zu-Modell-Transformation, als auch zur Modell-zu-Text-Transformation. Bei einer Modell-zu-Modell-Transformation werden Graphtransformationsregeln zur Spezi-fikation von elementaren Modellmanipulationen und abstrakte Zustandsautomaten als Kontrollfl¨usse zur Steuerung der Regelausf¨uhrung verwendet.

Viatra2 bietet eine textuelle Darstellung der klassischen Regelnotation an. Zudem exis-tiert eine eine zusammengef¨uhrte Notation (siehe Abschnitt 2.6). Bei Nutzung der klas-sischen Notation wird die linke Regelseite durch eines der soeben erkl¨arten Graphmuster dargestellt. Hier besteht die M¨oglichkeit, dass Transformationsregeln sich Graphmuster teilen. Sie dienen als Vorbedingung, w¨ahrend die rechte Seite klassisch als Nachbedin-gung aufgefasst wird. Rechte Seiten enthalten keine negativen Graphmuster. Beide Seiten d¨urfen weitere eigenst¨andig definierte Muster aufrufen. Zudem darf eine Regel Aktionen beinhalten, die nach einer erfolgreichen Transformation ausgef¨uhrt werden.

Abgesehen von klassischen Transformationen ¨uber in VTML definierten Modellen un-terst¨utzt Viatra2 generische Transformationen. Diese agieren auf den im

”Visual and Precise Metamodelling“-Ansatz definierten Elementen: Entit¨at und Beziehung.

Kontrollstrukturen werden in Viatra2 mit Hilfe von abstrakten Zustandsautomaten dargestellt. Diese k¨onnen Graphtransformationen (wiederholt) aufrufen. Sie bieten zu-dem eine M¨oglichkeit der Definition von Variablen und des Aufrufs beliebiger Java-Methoden. Dar¨uber hinaus k¨onnen sehr einfache Modellmanipulationen mittels der Zu-standsautomaten spezifiziert werden.

Modell-zu-Text-Transformationen werden in Viatra durch print-Anweisungen reali-siert, die programmiersprachliche Ausdr¨ucke oder Text enthalten. Diese werden gem¨aß der vorgegebenen Programmiersprache formatiert. Die Anweisungen werden innerhalb der Zustandsautomaten in die Transformation eingebunden.

Viatra2 ist als Eclipse-Plugin verf¨ugbar. Download und Dokumentation finden sich unter http://www.eclipse.org/viatra2/.