Die sprachliche Einkleidung des logikorientierten Ansatzes

PROGRES, ein Akronym f¨ur “PROgrammed Graph REwriting Systems“ [31] (dt. pro-grammierte Graphersetzungssyteme), ist die sprachliche Einkleidung des logikorientier-ten Ansatzes. Sie wird nun basierend auf dem Handbook of Graph Grammars and Graph Transformation, Band 2, Kapitel 13 von Sch¨urr et. al [70] und Sch¨urr [68] n¨aher erl¨autert.

Die Sprache PROGRES wurde urspr¨unglich zum

”Rapid Prototyping“ mit Graph-transformationssystemen entwickelt und mit drei Designzielen erstellt: (1)

Unterschei-dung von Aktivit¨aten zur Datendefinition und Datenmanipulation sowie die Nutzung von Graphschemata zur Typpr¨ufung von Graphtransformationsregeln. (2) Kein allei-niger Verlass auf das regelbasierte Paradigma f¨ur alle Anwendungen. Zus¨atzliche Un-terst¨utzung der imperativen Programmierung mit Kontrollstrukturen. (3) Ber¨ ucksich-tigung des Nichtdeterminismus von Regeln (und Kontrollstrukturen) durch Tiefensuche und Backtracking.[68]

Um diese Ziele zu erreichen, kombiniert PROGRES regelbasierte, objektorientierte, deduktive und aktive Datenbanksysteme, sowie imperative Programmierkonzepte. Als Datenmodell dienen gerichtete, attribuierte, knoten- und kantenmarkierte Graphen. Da-bei entsteht eine hybride Sprache, die Text mit grafischen Elementen f¨ur die rechte und linke Seite einer Graphtransformationsregel vereint. Jedem grafischen Element ist ei-ne analoge textuelle Darstellung zugeordei-net, die alternativ genutzt werden kann. Die grafischen Elemente d¨urfen wiederum Textbl¨ocke zur Definition von zus¨atzlichen An-wendbarkeitsbedingungen enthalten.

Teilgraphentests und Teilgraphersetzungen bilden die atomaren Einheiten aus wel-chen sich Graphtransformationen zusammensetzen. Zudem werden Kontrollstrukturen aus der imperativen Programmierung verwendet. Diesen wird teilweise nichtdeterminis-tischer Charakter zugeordnet, so dass sie die regelorientierte Ausf¨uhrung von Graph-transformationen unterst¨utzen.

Teilgraphentests werden in PROGRES als Graphabfragen bez¨uglich eines Subgra-phen aufgefasst. Grunds¨atzlich gibt ein solcher Test einen boolschen Wert zur¨uck, der den Testerfolg widerspiegelt. Teilgraphentests d¨urfen Ein- und Ausgabeparameter bein-halten, die f¨ur Knoten oder Knotenmengen stehen. Zur Definition sind Pfade, Attribute, Kanten, Knoten und negative Knoten verf¨ugbar, auf die im Weiteren noch eingegangen wird.

Teilgraphersetzungen bilden die rechten Regelseiten der Transformation. Sie repr¨ asen-tieren atomare Transformationen und erzeugen und modifizieren schematreue Graphen.

Teilgraphersetzungen werden analog zu einem Teilgraphentest spezifiziert, allerdings las-sen sie keine negativen Knoten und Kanten zu.

Graphtransformationen bestehen demnach aus einer linken Seite, dem Teilgraphentest und einer rechten Seite der Teilgraphersetzung (siehe 2.6). Zudem k¨onnen in PROGRES lokale Einbettungs¨uberf¨uhrungsfunktionen erstellt werden, die die Verbindung des neuen Teilgraphen mit dem verbleibenden Wirtsgraphen modifizieren. Dabei k¨onnen Kanten gel¨oscht, kopiert oder ummarkiert werden.

Bei der Ausf¨uhrung einer Graphtransformation werden nach Teilgraphentest, Teilgra-phersetzung und Einbettungs¨uberf¨uhrung die Attribute transferiert. Dazu werden den eigenst¨andigen Attributen der Knoten Werte zugewiesen. Zudem sind Vor- und Nach-bedingungen an die Graphtransformationsregeln als Zusicherungen m¨oglich.

Grunds¨atzlich wird dabei jeder Graph in einer Datenbank rep¨arasentiert. Dies bedeu-tet, dass alle Operationen zur Manipulation einer Datenbank als Auswahl und Trans-formation eines Teilgraphen angesehen werden. Dies bezeichnet man als Transaktion.

Analog zu Datenbanksystemen folgen sie dem ACID-Prinzip. Im Einzelnen besteht eine Transaktion also aus der Identifikation eines Teilgraphen, die durch einen Teilgraphentest beschrieben wird und den Transformationsschritten, die durch die

Graphtransformati-onsregel beschrieben werden.

Die Ausf¨uhrung jeder Graphtransformationsregel wird durch imperative, (nicht-)de-terministische Kontrollstrukturen gesteuert. Es ist ebenso m¨oglich, ganze Teile einer PROGRES-Spezifikation als Transaktion zu markieren, so dass diese aus Regeln und deren zugeh¨origem Kontrollfluss besteht. Da bei Fehlschlagen eines Bestandteils der Transaktion diese insgesamt r¨uckg¨angig gemacht werden muss, unterst¨utzt PROGRES eine Prolog-¨ahnliche Tiefensuche und Backtracking. Ein einfacher Abbruch w¨urde hier nicht ausreichen, da die Graphsuche nichtdeterministische Anteile beinhaltet.

Bei genauerer Betrachtung der Syntax zur Spezifikation von Graphtranformations-regeln stellen sich typisierte Knoten und Kanten als Basiselemente zur Definition von Graphklassen heraus. Knoten sind ¨uber Knotenklassen typisiert. Knotenklassen defi-nieren demnach die gemeinsamen, statischen Eigenschaften der Knotentypen. Zudem vererben sie diese Eigenschaften an die Knotentypen. Knotenklassen k¨onnen Vererbungs-hierarchien aufbauen, wobei Mehrfachvererbung erlaubt ist. Zum besseren Verst¨andnis k¨onnen Knotenklassen mit abstrakten Klassen und Knotentypen mit finalen, konkreten Klassen der objektorientierten Programmierung verglichen werden. Außerdem besteht in PROGRES die M¨oglichkeit, neben einfachen Knoten Mengenknoten zu definieren.

Diese Mengenknoten k¨onnen auf der rechten Seite einer Regel lediglich identisch ersetzt werden. Zudem k¨onnen alle Knoten einer Regel optional oder obligatorisch sein.

Kanten sind als bin¨are Relationen zwischen Knoten definiert. Sie sind ebenfalls typi-siert, indem Kantentypen zwischen Knotentypen bzw. Knotenklassen definiert werden.

Kantentypen sind gerichtet, k¨onnen aber in beide Richtungen durchlaufen werden. Zu-dem sind ihnen Kardinalit¨aten zugeordnet. Diese limitieren durch Angabe oberer und unterer Schranken die Anzahl der Kanten pro Knoten. Dabei kann eins oder beliebig viele f¨ur die obere Schranke und null oder eins f¨ur die untere Schranke angegeben werden.

Knoten k¨onnen - im Gegensatz zu Kanten - typisierte Attribute beinhalten. Es exis-tieren drei M¨oglichkeiten zur Typisierung. Sie erfolgt entweder ¨uber einem der drei in PROGRES definierten Standardtypen (integer, boolean, string) oder ¨uber einem Graph-typen, d.h. einer Menge von zusammengeh¨origen Knoten- und Kantentypdeklarationen.

Dabei sollten Graphtypen bevorzugt werden. Alternativ kann ein Attribut ¨uber einem Typ, der in der Wirtsprogrammiersprache C definiert und importiert wurde, getypt werden. Zudem k¨onnen Funktionen importiert werden, die im Zusammenhang mit dem Datentyp stehen. Analog zu den Kanten d¨urfen Attribute Kardinalit¨aten aufweisen. At-tribute modellieren die atomaren Eigenschaften von Knotenobjekten. Hierzu werden drei Arten von Attributen bez¨uglich ihrer Wertzuweisung unterschieden. Intrinsische Attri-bute sind diejenigen, die ihren Wert klassisch zugewiesen bekommen. Sie k¨onnen als Schl¨usselattribute deklariert werden, d.h. sie identifizieren den Knoten eindeutig und werden indiziert. Abgeleitete Attribute berechnen ihren Wert aus den Werten anderer Attribute. Meta-Attribute beinhalten Knoteneigenschaften, die den selben Wert f¨ur al-le Instanzen des Knotentyps haben. Sie definieren objektorientiert gesprochen statische Attribute. Attribute k¨onnen zudem Integrit¨atsbedingungen an Knoten angeben.

Zur Definition von Graphtransformationsregeln stehen zus¨atzlich Pfaddeklarationen als Sprachkonstrukte zur Verf¨ugung. Diese dienen der Definition von abgeleiteten Be-ziehungen zwischen Knoten. Sie werden in Graphtests und Graphtransformationsregeln

als Anwendbarkeitsbedingungen genutzt. Pfade beinhalten Pfadausdr¨ucke, die textuel-ler oder grafischer Natur sind. Grafische Pfade k¨onnen durch alle Konstrukte, die f¨ur Graphtests (sprich linke Seiten von Regeln) zugelassen sind, beschrieben werden. Die Pfadausdr¨ucke werden in drei Kategorien unterteilt: Kantenoperatoren, Attributbedin-gungen und Restriktionen. Pfadausdr¨ucke k¨onnen mittels Operatoren zu komplexeren Pfadausdr¨ucken zusammengefasst werden. Zudem gibt es bedingte und iterierende Pfad-ausdr¨ucke.

Die Konsistenz von Graphen kann sowohl durch globale Integrit¨atsbedingungen als auch durch Bedingungen auf Knoten gepr¨uft werden. Integrit¨atsbedingungen pr¨ufen das Modell auf Konsistenz gegen¨uber Invarianten. Spezielle Integrit¨atsbedingungen enthal-ten Reparaturaktionen. Sie werden aktive Integrit¨atsbedingungen genannt. Diese Repa-raturaktionen werden automatisch ausgef¨uhrt, sobald die zugeh¨orige Bedingung verletzt ist und damit ein verbotener Graphzustand erreicht wird.

PROGRES unterst¨utzt die Definition modularer Pakete, die die Regeln und Tests gruppieren. Diese d¨urfen sich durch Import-Beziehungen referenzieren. Die Import-Be-ziehungen sorgen daf¨ur, dass ein anderes Paket auf die ¨offentlichen Resourcen eines Pakets zugreifen kann, nicht jedoch auf die privaten Resourcen.

Die Entwicklungsumgebung bietet einen syntaxgesteuerten Editor f¨ur textuelle und grafische Elemente sowie eine Validierungsfunktion, die textuelle Komponenten und Typ-vertr¨aglichkeitsregeln pr¨uft. Zur Ausf¨uhrung einer PROGRES-Spezifikation stehen ein Interpreter und ein inkrementeller Compiler zur Verf¨ugung. Der Interpreter bietet einen Debugger an, der schrittweise (vorw¨arts und r¨uckw¨arts) die Transformation ausf¨uhrt.

Der Compiler erzeugt lauff¨ahigen C- oder Java-Quelltext.