Konzeption und Implementierung eines Generators für visuelle Sprachumgebungen in Eclipse basierend auf Graphtransformationen.

Transkript

1 Konzeption und Implementierung eines Generators für visuelle Sprachumgebungen in Eclipse basierend auf Graphtransformationen Stefan Hänsgen Diplomarbeit an der Fakultät für Elektrotechnik und Informatik der Technischen Universität Berlin Gutachter: Prof. Dr. H. Ehrig und Dr. G. Taentzer 10. Juni 2005

2

3 Zusammenfassung In dieser Diplomarbeit wird ein Generator für visuelle Umgebungen konzipiert und implementiert. Editieroperationen entsprechen einem Graphtransformationschritt. Auf der beiliegenden CD-ROM befindet sich die Eclipse Umgebung zum Starten des Generators und des Editors, das aktuelle Generator-Plugin mit Beispielalphabeten für Petrinetze, Aktivitätendiagramme und Automaten.

4

5 Die selbständige und eigenhändige Anfertigung dieser Diplomarbeit versichere ich an Eides statt. Berlin, den 10. Juni 2005 Unterschrift

6

7 Danksagung Mein Dank gilt den Betreuern Frau Dr.-Ing. Gabriele Taentzer und Herr Dipl.- Inf. Karsten Ehrig für die konstruktive Unterstützung bei der Erstellung dieser Arbeit. Darüberhinaus möchte ich mich bei Frau Dipl.-Inf. (FH) Olga Runge für die vielen zahlreichen Hinweise bei der Anbindung des AGG Systems an den generierten Editor. Meiner Familie möchte ich für die Unterstützung und die Geduld während der Erstellung dieser Arbeit danken.

8

9 Inhaltsverzeichnis 1 Einleitung Motivation Aufbau des Dokumentes Grundlagen Visuelle Sprache MDA UML TIGER Projekt Aufbau einer VL-Spezifikation in TIGER GTXL AGG als Graphtransformationsmaschine Eclipse GEF EMF JET GMF Anforderungen Ziel der Diplomarbeit i

10 ii INHALTSVERZEICHNIS 3.2 Funktionale Anforderungen Anforderung an den Generator Anforderung an den generierten Editor Nichtfunktionale Anforderungen Entwurf und Implementierung Paketstruktur des Generators Der Wizard Der Generierungsprozess für die Editordateien Generierung mittels JET über dem JetGateway Generierung von einfachen Dateien Generierung der Controller und der Dialoge Generierung von Node / Edge Dateien Generierung der Figuren Klassen Datenstruktur zur Kapselung des Alphabets Figuren nach Draw2D Der Regelanalysierer Struktur des Regelanalysierers Analyse der Regeln Der generierte Editor Paketstruktur Aufbau des Editors Interner Aufbau des Editors Anbindung von AGG an den Editor Benutzte Technologien TestEditoren 49

11 INHALTSVERZEICHNIS iii 5.1 Editor für Petrinetze Alphabet Grammatik Editoraufbau Editor für einfache Aktivitätendiagramme VL-Spezifikation Editor für Automaten VL-Spezifikation Anbindung einer externen Schnittstelle Zusammenfassung und Ausblick Zusammenfassung Ausblick Erstellung von Figuren Anpassungen des Regelanalysierers Benutzerhandbuch Installation Schritte zur Generierung eines Editors Allgemeines zur VL-Spezifikation Überblick über das TIGER Alphabet Erstellung von Grammatikregeln Alphabetdefinition für Petrinetze NodeSymbolTypes AttributeTypes EdgeSymbolTypes LinkTypes

12 iv INHALTSVERZEICHNIS Speichern des Alphabets Erstellung der Grammatikregeln für Petrinetze Start des Generators Start des Editors Aufbau des Editors Literaturverzeichnis 73 A Alphabet für Petrinetze 77

13 Kapitel 1 Einleitung 1.1 Motivation Einfach gesagt ist ein Generator ein Programm, das Code für ein anderes erzeugt. Code-Generatoren spielen heutzutage eine immer größere Rolle in der Informatik, da sie dabei helfen sich wiederkehrende Codierungsaufgabe zu erleichtern. Darüberhinaus bieten Code-Generatoren folgende Vorteile [Her03]: Produktivität: viele Zeilen Code können innerhalb von wenigen Sekunden kreiert werden Qualität: generierter Code hat eine gleichförmige Qualität über dem gesamten System Konsistenz: Konsistenz bezüglich Signaturen und Variablennamen ist stets gegeben. Abstraktion: Einige Generator nehmen ein abstraktes Modell als Input für das zu generierende System. Dadurch wird das System portierbar und kann in mehreren Sprachen erzeugt werden. 1

14 2 Einleitung 1.2 Aufbau des Dokumentes Die Diplomarbeit ist in folgende Abschnitte gegliedert: Kapitel 2 führt die Grundlagen zum Verständnis des Generators für visuelle Sprachumgebumgen ein. In Kapitel 3 werden die Anforderung an den Generator und dessen Komponenten erläutert, die in Kapitel 4 entworfen werden. In Kapitel 5 wird der Generator anhand von drei Sprachen getestet, das sind Petrinetze, einfache Aktivitätendiagramme und Automaten. In Kapitel 6 gibt eine Zusammenfassung und einen Ausblick bezüglich dieser Diplomarbeit und in Kapitel 7 ist ein Benutzerhandbuch, das anhand der Petrinetze die Erstellung einer VL-Spezifikation, die Handhabung des Generators und den generierten Editor behandelt.

15 Kapitel 2 Grundlagen In diesem Kapitel sollen die Grundlagen, welche zum Verständnis der Funktionsweise des Generators und des Editors notwendig sind, näher erläutert werden. 2.1 Visuelle Sprache Eine visuelle Sprache ist eine Sprache über einem visuellen Alphabet, das aus Symbolen und Verknüpfungen zwischen diesen besteht. Ein visuelles Alphabet besteht aus einer abstrakten, einer konkreten Syntax, die sich aus dem abstrakten Teil und dem visuellen Teil zusammensetzt, und einer Grammatik. Durch die Grammatik kann die Anzahl an möglichen Diagrammen eingeschränkt werden. Neben diesen konstruktiven Ansatz, gibt es noch den der Metamodellierung. Visuelle Sprachen und visuelle Umgebungen gewinnen heutzutage in der Softwareentwicklung immer mehr an Bedeutung. So werden Modellierungssprachen für die Analyse und das Design von Softwaresystemen eingesetzt. Eine Modellierungssprachen, die sich in den letzten Jahren durchgesetzt hat, ist die UML. Sie bietet diverse Möglichkeiten zur Modellierung der Analyse und des Designs. Weitere visuelle Sprachen sind Petrinetze, VOCL und Stagecast. Darüberhinaus gibt es Generatoren für visuelle Sprachen, die aus einer gebenen Spezifikation ein Werkzeug erzeugen, mit dem ein visuelles Modell der Sprache, also ein Diagramm, erstellt werden können. Dazu zählen DiaGen[Dia], ATOM 3 und GenGED. Die erstellten Werkzeuge sind in der Regel Editoren, 3

16 4 Grundlagen die syntaxgesteuert bzw. freihändig arbeiten. Der Vorteil von syntaxgesteuerten Editoren liegt darin, dass das erzeugte Diagramm immer der visuelle Sprache entspricht. Eine Parsierung des Diagramms entfällt dadurch, jedoch müssen die Editierregeln bereits im Vorhinein festgelegt werden. Ein Nachteil besteht nun darin das der Benutzer beim Layout sehr eingeschränkt wird. 2.2 MDA Die Entwicklung von Methoden und Werkzeugen zur effizienten Produktion von qualitativ hochwertigen IT-Systemen hat enorm an Bedeutung gewonnen. Sie sollen diese Systeme von der Anforderungsanalyse bis zur Inbetriebnahme unterstützen. Eine Methode dafür soll die MDA (Model Driven Architecture) sein [BHK03]. Grundgedanke dieser Technologie ist, dass konstruktive Modelle ins Zentrumm aller Phasen der Systementwicklung gestellt werden, d.h. ein Modell soll nicht nur ein abstrakte Beschreibung des zu realisierenden Systems sein, sondern aus diesen Modellen sollen automatisch andere Modelle generiert und einzelne Bestandteile des Systems erzeugt werden. Dabei wird zwischen technologieunabhängiger, die von einer konkreter Software - und Hardwaretechnologie abstrahiert, und technologieabhängiger Modellierung unterschieden. Die fachliche Spezifikation wird in einem PIM (Platform Independent Model) definiert, das eine formale an die Domäne angepasste Modellierungssprache verwendet. Als Modellierungssprache kann eine mit einem UML Profil entwickelte sein. Dieses Modell ist somit unabhängig von irgendeiner Zielplattform wie CORBA oder J2EE sein. Dabei wird nichts über den Abstraktionsgrad einer Plattform ausgesagt. Eine Plattform kann dabei J2EE oder auch ein konkreter Applikationsserver sein. Mittels Modelltransformation soll das PIM in ein PSM transformiert werden. Die Transformation soll weitgehend automatisiert mit Hilfe von Generatoren gesteuert werden. PIM und PSM sind relative Konzepte, d.h. ein PSM kann wiederum als PIM ge-

17 2.3 TIGER Projekt 5 handelt werden und mittels Transformation ein weiteres PSM generiert werden, das näher an der Plattform ist als das vorherige PSM UML Die UML (Unified Modelling Language) ist eine Sprache und Notation zur Spezifikation, Konstruktion, Visualisierung und Dokumentation von Modellen für Softwaresysteme [Oes04]. Sie wurde von der OMG (Object Management Group) standardisiert und weiterentwickelt. Die OMG ist ein Industriekonsortium, das aus diversen Unternehmen wie IBM, HP, SUN, Oracle, DaimlerChrysler und anderen besteht. Die UML ist eine Modellierungssprache, jedoch stellt sie keine Methodik dar, da dazu spezifische Rahmenbedingungen des Anwendungsbereiches, des organisatorischen Umfeldes usw. berücksichtigt werden müssten. Sie soll nämlich eine Grundlage für verschiedene Vorgehensweise sein. Der aktuelle Standard ist die UML 2.0, die eine grundsätzliche Überarbeitung erfuhr, was unter anderem die Spezifikation und das Metamodell betrifft. Darüberhinaus wurde sie unterteilt: Infrastructure (Kern, Profile, Stereotypen) Superstructure (statische und dynamische Modellelemente) OCL (Einschränkungen für definierte Modelle) Diagrammaustauschformat (UML-Austauschformat für Diagrammaustausch zwischen verschiedenen Tools) Um die UML für die eigenen Bedürfnisse anzupassenn, gibt es die sogenannten UML Profile, mit denen Modellelemente aus dem UML-Metamodell verwendet und erweitert werden können. 2.3 TIGER Projekt Das Ziel dieser Diplomarbeit, die Entwicklung eines Generators für visuelle Sprachumgebungen, ist ein Bestandteil des TIGER [EEHT04] Projektes

18 6 Grundlagen (Transformation-based generation of modeling environments). Die Zielstellung dieses Projektes liegt in der Entwicklung einer Toolumgebung, welche aus einem Designer und einem Generator besteht, welcher dann visulle Editoren, Simulatoren, Views zur Darstellung von Analyseergebenisse oder ein Tool zur Durchführung einer Modelltransformation erzeugen kann. Dabei sollen die Vorteile von AGG mit der der Eclipse Technologie kombiniert werden. In Abbildung 2.1: TIGER architecture TIGER wird AGG wird als Graphtransformationmaschine für getypte, attributierte Graphen verwendet, mit der Graphbedingungen geprüft und Graphgrammatiken analysiert werden können. Diese Analysetechniken beinhalten somit syntaktische und semantische Überprüfungen. Für die Generierung von visuellen Modellierungsumgebungen wird GEF verwendet, das in Kapitel beschrieben wird. Das Projekt besteht aus zwei Komponenten: einerseits ein Designer, mit dem eine VL-Spezifikation erstellt werden kann, und andererseits einem Generator, mit dem die Modellierungsumgebungen erstellt werden. Das sind der Editor, mit dem ein Modell editiert werden kann, ein Simulator, eine Analyse-Komponente und eine Modelltransformationskomponente. Für diese Komponenten werden visuelle Editoren / Viewer benötigt. Für die Kommunikation zwischen dem Designer und dem Generator wird GTXL als Austauschformat verwendet. In der ersten Ausbaustufe werden anstatt von Modellierungsumgebungen nur Diagrammeditoren erstellt, die auf Graphtransformation basieren. Für deren Generierung wird ein VL-Alphabet und eine Syntaxgrammatik verwendet.

19 2.3 TIGER Projekt 7 Später sollen weitere Grammatiken für Simulation und Parsierung erstellt werden. Zunächst beschränken wir uns auf graphartige Sprachen wie beispielsweise Petrinetze, Automaten. Im folgenden wird die VL-Spezifikation näher vorgestellt, die in TIGER benutzt wird: Aufbau einer VL-Spezifikation in TIGER Eine mit TIGER erstellte VL-Spezifikation besteht aus zwei Teilen: zum einen dem Alphabet und der Syntaxgrammatik, die einer AGGEngine.GraGra entspricht. TIGER-Alphabet Das Alphabet (siehe Abb. 2.2) besteht aus SymbolTypes und LinkTypes. Dabei können NodeSymbolTypes durch EdgeSymbolTypes über LinkTypes miteinander verbunden werden. Diese Beschränkung besteht aber nur für die erste Ausbaustufe. SymbolTypes, LinkTypes und AttributeTypes bilden die abstrakte Syntax des Alphabets und haben direkte Entsprechungen in der AGGEngine.GraGra. Dabei werden SymbolTypes auf Nodes, LinkTypes auf Arcs abgebildet. AttributeTypes sind Attribute von Nodes. SymbolTypes können als NodeSymbolTypes (Knoten) und EdgeSymbolTypes (Kanten) auftreten. Das konkrete Layout für ein NodeSymbolType ist definiert durch die Klasse ShapeFigure, deren Attribute (Farbe, Größe, Art der Figur etc.) das Aussehen der Figur festlegen. Hierbei ist es auch möglich, das ein Knotensymbol mehrere ShapeFigures hat, z.b. kann das NodeSymbolType Aktivität durch je eine der vier möglichen visuellen Darstellungen (Startsymbol, Endsymbol, Entscheidung oder einfache Aktivität) repräsentiert werden. Die Darstellung muss dann über ein kind Attribut gesteuert werden. AttributeTypes können durch Textfigures visualisiert werden. Sowohl Textfigure als auch ShapeFigure implementieren das Interface Figure und können somit über Layoutconstraint in Beziehung zueinander gesetzt werden. Layout-

20 8 Grundlagen Abbildung 2.2: Das TIGER Alphabet Constraints können INSIDE, BELOW, ABOVE, LEFT, RIGHT sein. Die EdgeSymbolTypes, deren konkretes Layout durch die Klasse Connection implementiert wird, verbinden NodeSymbolTypes über LinkTypes miteinander. Connections haben Attribute für Linienfarbe, -stärke usw. und werden über ConnectionConstraints mit Figures verbunden. Die LinkTypes können ebenfalls ein konkretes Layout haben, das eine org.eclipse.draw2d.rotatabledecoration sein muss, d.h. entweder eine Pfeilspitze oder auch ein Polygon. Für die Berechnung des Layouts werden die in GEF enthaltenden Graphlayouter verwendet, so dass auf die Anbindung von Constraintsolver verzichtet werden kann.

21 2.3 TIGER Projekt 9 Graphgrammatik Graphgrammatiken bestehen in der Regel aus einem Startgraphen und einer Menge von Graphtransformationsregeln. In TIGER wird das algebraische Graphmodell für getypte attributierte Graphen und derer Transformation verwendet. Eine Regel besteht aus zwei Graphen einem auf der linken und einem auf der rechte Seite der Regel. Eine Regel kann angewendet werden, wenn sich ein Bild der linken Regelseite im Graphen befindet. Ein genauere Beschreibung ist in Kapitel zu finden. Für den zu generierenden Editor müssen Einfüge-, Lösch-, Bearbeitungs- und Verschieberegeln definiert werden. Die Knoten in der Graphgrammatik, die ein NodeSymbolType aus dem Alphabet repräsentierten, müssen neben den im Alphabet definierten Attributen noch zwei Attribute x, y vom Typ int haben, so dass die Position auch abgespeichert werden kann und damit erhalten bleibt. Dadurch wird ersichtlich, dass in der Graphgrammatik noch zusätzliche Attribute definiert werden können. Gleiches gilt auch für Knoten, die dann im Editor jedoch nicht dargestellt werden GTXL GTXL ist ein Austauschformat für Graphtransformationssysteme[Lam04] und wurde an der TU-Berlin entwickelt. Die Idee war, Tools für Graphtransformationssysteme ein Austauschformat zu bieten. Es basiert auf dem weit verbreiteten Standard XML [W3C99] und integriert GXL, um den Teil, der die Graphen behandelt, zu beschreiben. Im TIGER Projekt dient GTXL als Austauschformat zwischen dem Designer und dem Generator. In der aktuellen Version wird aber nur das Alphabet in GTXL abgespeichert. Die Graphgrammatik wird noch in einem AGG eigenen Format abgelegt.

22 10 Grundlagen AGG als Graphtransformationsmaschine AGG [AGG] (Attributiertes Graph Grammatiksystem) ist ein Interpreter für attributierte Graphtransformation, das an der TU-Berlin entwickelt wurde. Es wird einerseits eine GUI zum Editieren von Graphen und Regeln bereitgestellt und andererseits kann es als eigenständige Graphtransformationsmaschine in Java Anwendungen eingebunden werden. In AGG werden komplexe Datenstrukturen als Graphen modelliert, welche über einen Typgraphen getypt sein können. Sie können durch Java Objekte oder andere Typen attributiert werden. Basistypen in AGG entsprechen den primitiven Datentypen aus dem Java SDK. Darüberhinaus können auch selbstdefiniert Klassen eingebunden werden. Das Systemverhalten wird durch Graphregeln spezifiziert, welche durch NACs (Negative Application Conditions) eingschränkt werden können. Durch eine Regelanwendung wird der Graph verändert. Die Anwendung von Regeln folgt dem Single-Pushout-Ansatz für Graphtransformation. Algebraische Spezifikationen und Terme werden in AGG durch Java Klassen ausgedrückt. Im nächsten Abschnitt sollen die Sprachkonstrukte von AGG näher vorgestellt werden. Sprachkonstrukte in AGG Ein Graph in AGG besteht aus zwei disjunkten Mengen: Nodes und Arcs, die auch als Graphobjekte bezeichnet werden. Ein Arc ist eine gerichtete Kante zwischen zwei Knoten. Eine weitere Klassifikation der Graphobjekte kann durch Labels vorgenommen werden, die aus einer Labelmenge genommen werden. Labels sind dabei Typen: ein Objekt o ist dann vom Typ l, der aus der Labelmenge stammt. In AGG können zwischen zwei Knoten mehrere Arcs vom gleichen Typ sein. Das ist ein Unterschied vom allgemeinen Verständnis von Graphgrammatiken, da dort ein Arc eine Relation zwischen zwei Knoten beschreibt. Graphobjekten können noch Attribute zugewiesen werden, die aus einem Namen, einen Typ und einem zugewiesen Wert besteht. Pro Graphobjekt können mehrere Attribute deklariert werden, die auch vom gleichen Typ sein können. In

23 2.4 Eclipse 11 einem Graphen haben alle Knoten eines Typs die gleiche Attributdeklaration. Die Werte der Attribute können dann natürlich unterschiedlich sein. Eine Aktion kann als ein Übergang von einem Zustand in einen nächsten betrachtet werden. In AGG werden Zustände als ein Paar von Graphen beschrieben. Es gibt einen Vor - und eine Nachzustand. Erst wenn alle Vorbedingungen in einem konkreten Graphen erfüllt sind, kann ein Zustandswechsel vollzogen werden. Darunter fällt auch das finden eines Matches der linken Regelseite im konkreten Graphen. Ein Graphtransformationsschritt ist eine Regelanwendung auf einen konkreten Match. Dabei findet eine Manipulation der Nodes und Arcs, die zu dem Match gehören, im Graphen statt. 2.4 Eclipse Als Entwicklungs- und Ausführungsumgebung für den Generator für visuelle Sprachumgebungen wird die Eclipse Plattform [Ecl05] eingesetzt. Eclipse ist eine universelle Tool Platform, die für viele Anwendungsmöglichkeiten verwendet werden kann. Sie kann als integrierte Entwicklungsumgebung, als Laufzeitumgebung für eigene Applikationen eingesetzt werden. Der Hauptvorteil liegt vor allem darin, dass sie auf verschiedenen Plattformen eingesetzt werden kann. Die Plattform kann durch die Entwicklung eigener Plugins erweitert oder ergänzt werden und daher nur einen kleinen Laufzeitkern besitzt, der die Kommunikation der Plugins untereinandern regelt (siehe Abb. 2.3). Ein Plugin ist die kleinste Einheit der Eclipse Plattform, die für sie entwickelt und verbreitet werden kann. In der Regel reicht für eine kleine Anwendung ein einzelnes Plugin aus, währenddessen ein komplexes Tool sich aus mehreren Plugins zusammensetzt. Beispielsweise setzt sich das TIGER Projekt auch aus mehreren Plugins zusammen: ein Plugin für den Generator und das Alphabet, eines für den Designer, eines für die Beispielalphabete und Graphgrammatiken und eines für die Generatordokumentation. Hierbei wird deutlich, dass ein Plugin nicht nur Programmcode enthalten muss, sondern auch beliebige Dateien haben kann.

24 12 Grundlagen Jedes Plugin besitzt eine Manifestdatei, in der die Kopplung zu anderen Plug- Abbildung 2.3: Eclipse Architektur ins geregelt wird. Über die Erweiterung (Extensions) kann ein selbstentwickeltes Plugin ein anderes erweitern und an eine bestimmte Stelle in Eclipse eingebunden werden. Durch die Plattform werden standardmäßig diverse Erweiterungen zur Verfügung gestellt. Dabei gibt es keine Begrenzung an Erweiterungen, an die ein Plugin angehangen werden kann. Beispielsweise kann ein Plugin als Wizard oder als Editor in der Eclipse Umgebung integriert werden. Ein selbstentwickeltes Plugin kann nicht nur solche Erweiterungen nutzen, sondern auch welche zur Verfügung stellen, die dann von anderen Plugins wieder erweitert werden können. Das geschieht durch sogenannte Erweiterungspunkte (Extension Points), von denen ein Plugin eine beliebige Anzahl zur Verfügung stellen kann. Dieser Erweiterungspunkt muss dann auch eine entsprechende API besitzen. Standardmäßig bietet die Eclipse Plattform Plugins für eine Java- Entwicklungsumgebung, Resourcenverwaltung, Unterstützung des CVS, Plugin- Entwicklungswerkzeuge und ein Hilfe -System. Die Benutzerschnittstelle der Eclipse Plattform wird durch die Workbench repräsentiert, die eine flexible, anpassbare Oberfläche für den Benutzer bietet. Die Anordnung der verschiedenen Fenstern für Editoren und Views erfolgt in Perspectives. Für die Darstellung der Workbench wird das SWT (Standard Wid-

25 2.4 Eclipse 13 get Toolkit) und JFace verwendet, das SWT benutzt und die Programmierung von Benutzeroberflächen vereinfacht. Bei mit SWT entwickelten Programmen wird das darunterliegende Window System berücksichtigt. Für eine detailierte Einführung in die Eclipse Plattform sei an dieser Stelle auf den Eclipse Platform Technical Overview verwiesen [Ecl03]. Für die Eclipse Plattform wurden bereits diverse Tools entwickelt, die im Tools-Project vom Eclipseconsortium zusammengefaßt sind. Dies sind unter anderem GEF, EMF und JET als Teil von EMF, die im folgenden vorgestellt werden GEF GEF [GEF] (Graphical Editor Framework) ist ein Projekt des Eclipse Tool Projektes mit dem auf einfache Weise grafische Editoren implementiert werden können. Die Implementierung des Editors muss dabei auf einem schon vorhandenen Modell basieren. Dabei setzt GEF die Model-View-Controller Architektur ein, die eine Trennung zwischen dem Modell und den sichtbaren Elementen (View) des Editors vorsieht. Eine Änderung in der View zieht dann automatisch eine Änderung im Modell nach sich und umgekehrt. Ein Modell in GEF entspricht einem Metamodell in unserem Verständnis. Die Kommunikation dieser Änderungen wird durch den Controller gesteuert. Das Framework besteht aus zwei verschiedenen Strukturen: zum einen werden unter anderem die Klassen für den Controller bereitgestellt und zum anderen Klassen zum Zeichnen für Figuren aus dem sogenannten Draw2D Paket. Ein GEF Editor wird in der Regel an eine Klasse, die die Schnittstelle IEditor- Part aus Eclipse implementiert. In dieser Klasse wird dann eine EditDomain erzeugt, die alles zusammenhält, was für den Editor wichtig ist. Sie kann einen oder mehrere GraphicalViewer beinhalten, einen CommandStack und ein aktives Tool, das standardmäßig eine Selektionstool ist. Im Fall des generierten Editors ist es genau einer. Der GraphicalViewer ist für die Verwaltung aller EditParts (Controller) verantwortlich. Mit den EditParts wird eine Verbindung zwischen dem Modell und dem View hergestellt und es representiert etwas das

26 14 Grundlagen sich im Modell befindet. Er erzeugt Figuren die im View sichtbar sind und propagiert Änderungen im Modell an den View. Die zweite wichtige Aufgabe der EditParts liegt in der Durchführung von grafische Editieroperation. Das beinhaltet Änderung am Modell, die mit Commands durchgeführt werden, visuelles Feedback zeigen und Delegation der eben beiden genannten Eigenschaften an andere EditParts. Die Ausführung dieser Editieroperationen sind in EditParts nicht direkt implementiert, sondern werden über EditPolicies gehandhabt. EditPolicies bietet bestimmte Rollen für die EditParts. Rollen gibt es für das Layoutmanagement oder Erzeugen. Die Rolle wird definiert über die Requests, die eine EditPolicy versteht. Requests, die nicht zu einer Rolle passen werden ignoriert. Bei der Installation einer EditPolicy an einem EditPart wird eine Rolle definiert und eine Klasse angegeben, die eine EditPolicy erweitert, die dieser Rolle entspricht. Requests sollen mit einem EditPart kommunizieren und werden an die EditPolicies delegiert. Weitere Features von GEF sind die Tools, die den EditParts und EditPolicies erlauben sich bei Operationen auf einer höheren Ebene zu bewegen. Diese Tools können in der Palette, die in der zu Anfang erwähnten EditDomain registriert werden muss, erscheinen. Es gibt Tools zum Auswählen, Markieren und Erzeugen von Objekten. Beim Erzeugen kann noch zwischen einfachen Objekten und Verbindungen unterschieden werden. Mit den Klassen des Draw2D Pakets werden die Figuren eines GEF basierten Editors erzeugt. Der großte Vorteil liegt in der Nutzung der bereits vorhanden effizienten Layoutalgorithmen, so dass die Implementierung eines Constraintsolvers, der sonst die Berechnung des Layouts übernehmen wurrde, entfällt. Für die Darstellung einfacher Figuren gibt es bereits fertige Klassen. Mit Hilfe von LayoutManagern können diese Figuren zu komplexeren verbunden werden. Figuren können noch Ankerpunkte (AnchorPoints) besitzen, an den dann Verbindungen andocken können.

27 2.4 Eclipse EMF An dieser Stelle soll ein kurzer Überblick über EMF gegeben werden, da für die Editorgenerierung JET verwendet wird, das Teil von EMF ist. EMF ist ein Framework, mit dem ein Modell erstellt für eigene Anwendungen erstellt werden kann und das über Codegenerierungseigenschaften verfügt. Dies beihaltet die Generierung des Modellcodes bis zu einem einfachen Baumeditor, mit dem das Modell getestet werden kann. Im generierten Quellcode ist standardmäßig ein Notification Service implementiert, den die eigene Anwendung nutzen kann, um über Modeländerungen benachrichtigt zu werden. Außerdem wird ein Persistenzmechanismus integriert, der es erlaubt das Modell in einem XMI-konformen Format zu speichern. EMF besteht aus zwei Frameworks: Core: Der Kern von EMF beinhaltet eine eigenes Metamodell (Ecore), mit dem die Modelle beschrieben werden und Fähigkeiten zur Serialisierung (XMI-unterstützt) und einen eigenen Benachrichtungsservice zum Anzeigen von Modelländerungen bietet. Zur Codegenerierung wird hier das JET Framework verwendet. EMF.Edit: Dieses Framework erweitert das Core-Framework um Eigenschaften zur Bearbeitung und Anzeige von in EMF definierten Modellen JET Die Generierung der Java Dateien erfolgt mit Unterstützung des JET Frameworks, das mit seiner Struktur eine einfache Möglichkeit bietet, Code zu generieren. Dazu werden Templates verwendet, welche unter anderem die Struktur des später generierten Codes widerspiegeln. Im folgenden wird nur eine grobe Übersicht über JET gegeben. Um tiefer in das Framework vorzudringen, soll an die beiden Tutorials in [Pop04] verwiesen werden. Der Generierungsprozess ist in zwei sequentiell ablaufende Schritte unterteilt: in Translation und in Generation.

28 16 Grundlagen Abbildung 2.4: Quellcodegenerierung mittels Templates 1. Translation : Zunächst werden die Templates in eine Art Zwischencode, der normaler Java-Sourcecode ist, durch den JETEmitter übersetzt und danach kompiliert. 2. Generation : Aus dem kompilierten Source-Code wird nun durch den JETEmitter der gewünschte Source-Code erzeugt und als String übergeben. Der Entwickler muss nun noch die Speicherung an den richtigen Ort regeln. Aufbau eines Templates Ein Template besteht aus einem Kopf und aus einem Rumpf. Darüberhinaus ist es möglich durch Platzhalter an beliebigen Stellen, eigenen Code einzufügen. Der Kopf hat in einem JET Template den wie in Abb. 2.5 gezeigten Aufbau: Ein Template muss immer mit der JET Direktive beginnen, damit es vom <%@jet package="..." class="..." imports="..."%> Abbildung 2.5: Kopf eines JET Templates JETEmitter als solches erkannt wird. Daneben ist es möglich einen Namen für das Paket anzugeben, in das das übersetzte Template im.jetemitters Projekt gespeichert werden sollen. Ein Klassename für den Zwischencode kann noch angegeben werden, ist aber nicht notwendig. Am wichtigsten sind die Importe, denn alle Klassen, die im Template verwendet werden, selbst jene aus der Java SDK, müssen dort angegeben werden, damit eine Kompilierung des Zwischencodes möglich ist.

29 2.4 Eclipse 17 Der Rumpf des Templates spiegelt das Aussehen des generierten Codes wider. Dabei ist zu beachten, dass zwischen <%...%> beliebige Javaausdrücke stehen können und mit <%=...%>, das als Platzhalter dienen, der gewünschte Code eingefügt werden kann. In Abb. 2.6 ist ein Template angegeben, mit dem eine package="test" imports="java.util.*"%> <%List mylist = (List) argument;%> public class TestClass { <%for(iterator it = mylist.iterator; it.hasnext();){%> private String <%=it.next()%>; <%}%>... } Abbildung 2.6: Kopf und Rumpf eines JET Templates Klasse TestClass erzeugt werden soll. Dieses Template bekommt die Namen für die Felder in einer Liste übergeben. Diese Liste wird in der lokalen Variable mylist gespeichert. In der Imports-Klausel werden nun die Klassen List und Iterator für die Kompilierung des Zwischencodes benötigt. Durch Iteration über diese Liste werden dann im zweiten Schritt (Generation)die Felder für die Klasse erzeugt GMF GMF (Graphical Modeling Framework) ist der Vorschlag für ein neues Projekt im Eclipse Technology-Project. Die beiden Projekte EMF und GEF, die auch Teil des Eclipse Technology-Projects sind, werden häufig zusammen benutzt. Daraus entstand die Idee, diese Projekte zu kombinieren und deren Stärken zu nutzen. GMF soll einen generativen Ansatz für ein in EMF ausgedrücktes Domainmodell bieten. Es soll dabei aus drei Komponenten bestehen:

30 18 Grundlagen einer Struktur zur Erstellung von Diagrammen (EMF basiert) einem Diagramm Generations Framework beispielhafte Modellierungswerkzeuge Die Diagrammdefinition erfolgt über ein Toolkit und soll auf einem Metamodell basieren. Die Struktur zur Erstellung von Diagrammen soll einen Basissatz an Diagrammkomponenten bieten, die dann als Eingabe für einen Generator dienen sollen. Bestandteile eines Diagramms sind (Knoten (nodes), Kanten (edges und Verbinder (connectors). Desweiteren soll es Editoren, Views und Navigatoren geben. Während der Validierungsphase soll geklärt werden, welche Teile in einem Fra- Abbildung 2.7: Überblick über die Konzepte von GMF mework untergebracht werden und welche generiert werden sollen. Zunächst sollen konkrete Beispiele für GMF geschaffen werden, die als eine Folge von Modellierungsumgebungen entwickelt werden, die dann ein integraler Bestandteil des Projektes werden sollen. Dazu zählen die Entwicklung einer Oberfläche zur Modellierung von Ecore Modellen und die Erweiterung des UML2-Projektes um diagrammatische Fähigkeiten. Ein high-level konzeptionelles Diagramm ist in Abb. 2.7 zu sehen. Diese Projekt befindet sich noch in der Validierungsphase, wodurch eine genaue Beschreibung über den Aufbau noch nicht möglich. Für die Generierung soll unter anderem auch JET benutzt werden.

31 Kapitel 3 Anforderungen 3.1 Ziel der Diplomarbeit Ziel dieser Diplomarbeit ist die Konzeption und Implementierung eines Generators, der aus einer gegebenen Spezifikation für eine visuelle Sprache einen visuellen Editor generiert, der als Eclipse Plugin realisiert werden soll. Die VL-Spezifikation besteht aus einem visuellen Alphabet und einer Graphgrammatik. Dem generierten Editor soll die Model-View-Controller Architektur zugrunde liegen, wobei der Controller mit Hilfe von GEF und der View mit Hilfe von Draw2D implementiert werden soll. In den generierten Editor soll AGG eingebunden werden, das dann die Graphgrammatik (Modell) einliest und die Regelanwendungen steuert. Jede Editieroperation im Editor soll dann einer Regelanwendung mit AGG entsprechen. 3.2 Funktionale Anforderungen In diesem Abschnitt werden alle funktionalen Anforderungen vorgestellt, die an den Generator und an den generierten Editor gestellt werden. 19

32 20 Anforderungen Anforderung an den Generator Aus einer VL-Spezifikation, die der Generator als Eingabe bekommt, soll daraus ein visueller Editor generiert werden. Da der Generator ein Bestandteil des TIGER Projektes sein soll, wird die VL-Spezifikation auch mit Hilfe von TIGER erstellt. In der ersten Ausbaustufe soll er nur Editoren für graphartige visuelle Sprachen erstellen. In den nächsten Ausbaustufen sollen noch Simulations- und Analyseumgebungen folgen. Eine VL-Spezifikation besteht aus einem visuellen Alphabet und einer Graphgrammatik. Mit dem Alphabet werden die abstrakte Syntax und das konkrete Layout beschrieben. Mit der Graphgrammatik sollen Regeln definiert werden, die für die Durchführung von Editieroperationen verantwortlich sind. Der Generator soll mit Hilfe eines Wizards gestartet werden. Dieser Wizard soll alle benötigten Informationen sammeln, daraus ein leeres Plugin Projekt erstellen und den Generator mit diesen Informationen starten. Aus dieser VL- Spezifikation soll dann ein Editor generiert werden, mit dem ein visuelles Modell erstellt werden kann, das der VL-Spezifikation entspricht. Der Editor soll Grundoperationen wie Laden / Speichern und Erstellen einer Datei beherrschen Anforderung an den generierten Editor Mit dem generierten Editor sollen die im Alphabet definierten SymbolTypen editiert werden können. Welche Operationen für ein SymbolType ausgeführt werden kann, wird durch die Regeln in der Graphgrammatik festgelegt. Der Editor soll über einen Wizard verfügen, mit dem eine neue Datei für diesen Editor erzeugt werden kann. Diese enthält dann den Typgraphen und den Startgraphen, der in der Graphgrammatik definiert wurde. Das Aussehen des Editors wird einerseits durch das Alphabet und das Aussehen seiner Komponenten wie Palette und Kontextmenü, werden andererseits durch die Regeln in der Graphgrammatik bestimmt. Welche Regeln wo erscheinen sollen wird im nächsten genauer dargestellt. Der Aufbau eines generierten Editors soll unabhängig von der visuellen Sprache immer der gleiche sein: auf linken Seite soll sich eine Palette und auf der rech-

33 3.2 Funktionale Anforderungen 21 ten Seite die Zeichenfläche befinden. Diese beiden Komponenten werden zu einer Seite zusammengefaßt und deren unteren Ende der Name der VL-Spezifikation steht. In der Regel besteht ein generierter Editor aus einer Seite. Dieser Aufbau ist von der visuellen Sprache unabhängig. Dagegen gibt es Komponenten, die abhängig vom Alphabet und den Graphgrammatikregeln sind. Die Anzahl der oben eben beschriebenen Seiten kann durch Definition eines Containers variiert, der durch ein NodeSymbolType dargestellt wird. Für jeden diesen NodeSymbolType soll dann eine Seite erzeugt werden. Ein Beispiel dafür ist ein Editor für Automaten. Im Tabulator am unteren Ende der Seite soll der Name oder eine ID des NodeSymbolTypes erscheinen. Regeln... Das Aussehen der Palette und des Kontextmenüs sollen durch die Regeln bestimmt werden. Die Regeln sollen in verschiedene Kategorien eingeordnet werden: in Einfüge-, Lösch-, Bearbeitungs- und Verschieberegeln. Im folgenden soll erläutert werden, wo welche Regeln erscheinen sollen. In Abbildung 3.1 ist eine Unterteilung der Einfügeregeln zu sehen. Wenn es Einfügeregeln gibt, die den Fällen 1 und 2 entsprechen, soll es Einträge in der Palette geben, die in zwei Bereiche unterteilt ist. Für NodeSymbolTypes im Bereich Symbols und für EdgeSymbolTypes im Bereich Connections. Für den dritten Fall soll ein Eintrag mit dem Namen der Regel im Kontextmenü erscheinen. Löschregeln soll grundsätzlich im Kontextmenü erscheinen und durch ein ro- Abbildung 3.1: Einordnung der Einfügeregeln

34 22 Anforderungen tes Kreuz als Löschregel markiert werden. Bearbeitungsregeln sollen ebenso im Kontextmenü erscheinen. Die Anwendung von Verschieberegeln soll durch das Verschieben eines NodeSymbolTypes auf der Zeichenfläche erfolgen. Für ein selektiertes Objekt sollen im Kontextmenü nur die Regeln erscheinen, die auf dem selektierten angewendet werden können. 3.3 Nichtfunktionale Anforderungen Der Generator und der generierte Editor sollen als Eclipse Plugins realisiert werden, d.h zur Ausführung beider Programme wird die Eclipse Plattform und Java benötigt. Für die Entwicklung des Generators soll die Eclipse Plattform auch als integrierte Entwicklungsumgebung eingesetzt werden. Der Generator soll eine Codegenerierung für den Editor nach Java vornehmen. Für die Codegenerierung soll der JETEmitter aus dem JET Framework, das ein Teil von EMF ist, verwendet werden. Da beide Programme als Eclipse Plugins realisiert und in Java implementiert werden sollen, können sie leicht in Eclipse integriert werden. Zur Durchführung von Editieroperationen (Regelanwendungen) im Editor soll die Graphtransformationsmaschine AGG verwendet werden.

35 Kapitel 4 Entwurf und Implementierung Der Generator für visuelle Sprachumgebungen besteht aus folgenden Komponenten, die im folgenden entworfen werden: ein Wizard, der alle Informationen sammelt und den Generator für den Editor startet eine Komponente für den Generierungsablauf ein Regelanalysierer für die Analyse der Graphgrammatik ein JetGateway, das eine Verbindung zwischen dem Generator und dem JETEmitter schaffen soll eine Komponente zur Kapselung der Alphabetklassen und deren Umwandlung in GEF Klassen Zur Darstellung der Strukturen und des Verhaltens der einzelnen Komponenten werden UML-Klassendiagramme [UML04] und UML-Sequenzdiagramme verwendet. Für die Darstellung der Sequenzdiagramme wird das EclipseUMLStudio [Omo] von Omondo verwendet. 4.1 Paketstruktur des Generators Im folgenden ist die Paketstruktur des Generators angegeben: 23

36 24 Entwurf und Implementierung Abbildung 4.1: Paketstruktur des Generators tiger.generator: Dieses Paket beihaltet die Generatorhauptklasse zur Steuerung des Generierungsprozesses. tiger.generator.analyzer: In diesem Paket befindet sich der Regelanalysierer mit seinen Komponenent für eine Analyse der Regeln aus der Graphgrammatik. tiger.generator.util: Die Datenstruktur zur Kapselung des Alphabets für eine Abbildung nach Draw2D und GEF ist in diesem Paket zu finden. tiger.generator.jet: In diesem Paket gibt es Klassen, die für die Codegenerierung mittels JET verantwortlich sind. tiger.generator.templates: Dieses Paket beinhaltet Templates, die JET zur Codegenerierung benötigt. Die folgenden Pakete beinhalten die VL-Spezifikation, deren Alphabet an einigen Stellen erweitert wurde. Dies betrifft die Klasse ShapeFigure, bei der noch zwei Attribute (defaultsize und maximumsize hinzugefügt wurden. Desweiteren kann nun ein kind -Attribut als AttributeType definiert und die Referezen auf die entsprechen ShapeFigures gesetzt werden.

37 4.2 Der Wizard 25 tiger.vlspec: VL Spezifikation, die das Alphabet, die Grammatiken und den XMLHelper beinhaltet tiger.vlspec.alphabet: Klassen für das Alphabet 4.2 Der Wizard Wie in Kapitel 2.4 bereits erwähnt wurde, gibt es in Eclipse sogenannte Erweiterungspunkte, mit denen die Eclipse Plattform durch eigene Plugins erweitert werden kann. Der Generator-Wizard erweitert hier den Erweiterungspunkt org.eclipse.ui.newwizards und erscheint somit im New Wizard Menu von Eclipse. Für den Entwurf des Wizards werden bereits vorhandene Klassen aus dem Eclipse SDK verwendet und erweitert. Der Wizard hat die Aufgabe zwei Vorgänge zu steuern: zum einen wird ein Plugin-Project erzeugt und zum anderen wird der Generator gestartet, der dann den Java Code für den Editor erzeugt. Die Generierung des Plugin-Projektes wurde bewusst nicht mit dem JET Framework durchgeführt, da es in Eclipse die PDE Plugin Development Environment gibt, die eine komfortable Erzeugung von solchen Projekten erlaubt. Die Erzeugung des Plugin Projektes um- Abbildung 4.2: Klassendiagramm des Wizards fasst die Manifestdatei plugin.xml, worin alle plugin spezifischen Informationen

38 26 Entwurf und Implementierung gespeichert werden, wie beispielsweise für die Klassenpfade für AGG, Xerces, Colim, JGL und der Java Umgebung. Darüberhinaus werden bin und src Verzeichnisse angelegt. Im Letzteren wird dann der Java Code für den generierten Editor gespeichert. Dieser Prozess wird im folgenden unter Einbeziehung der einzelnen Klassen näher erläutert. Um einen Wizard in die Eclipse Umgebung einzubinden, wird zunächst eine eigene Wizardklasse benötigt. Die Wizardklasse, EditorPluginProjectWizard wurde von der bereits in Eclipse vorhandenen Klasse Wizard abgeleitet und implementiert das Interface INewWizard. Dadurch kann sie an den Erweiterungspunkt org.eclipse.ui.newwizards angehangen werden. Diese Klasse ist für die Verwaltung der einzelnen Seiten eines Wizards, der eingegebenen Werte, dessen Navigation und Beendigung zuständig. Die eigegebenen Daten zur Pluginerzeugung werden durch die Klasse PluginData repräsentiert, die durch die Wizardklasse erzeugt wird. Sie implementiert das Interface IPluginData, welche alle notwendigen Methoden zur Generierung es Editor-Plugins beinhaltet. Für den Generator werden für den jetzigen Stand nur folgende Informationen benötigt: Projektname, Ort der Alphabetspezifikation und eine eigene Dateiendung, welche nur eine Seite des Wizards benötigen. Diese Seite wird durch die Klasse EditorProjectPage implementiert, die die Anordnung der Textfelder und Labels arrangiert. Sie erweitert die Klasse Editor- ProjectPage, für die bereits Möglichkeiten zur Eingabe eines Projektnames und eines Ortes für ein Projekt bereitgestellt werden. Der Start des Generierungsprozesses erfolgt erst durch Klicken des Finish Buttons. Dabei wird eine neue Instanz der Klasse EditorProjectCreationOperation erzeugt, die Zugriff auf PluginData hat und daraus durch Aufruf der execute Methode das Plugin Projekt generiert. Eine genaue Schilderung des Ablaufs der execute ist in Abb. 4.3 zu sehen. Zunächst wird ein leeres Projekt angelegt, welches eine Java und Plugin Nature erhält, so dass dort vorhandene Java Dateien kompiliert werden können. Danach werden wie in einem regulären Java Projekt in Eclipse die Klassenpfade gesetzt. Danach erfolgt die Erstellung der Manifestdatei (plugin.xml), die sich in folgende Unterschritte gliedert (vgl. Abb. 4.3: Erstellung von Version, ID und Pluginklassenname, Erstellung des

39 4.3 Der Generierungsprozess für die Editordateien 27 Abbildung 4.3: Ablauf der Generierung des Plugin Projektes Erweiterungsabschnitts für den Editor sowie Hinzufügen des Runtimes und Dependenciesbereiches. Nachdem dieser erste Generierungsschritt abgeschlossen wurde, beginnt nun die Generierung der Dateien für den Editor. 4.3 Der Generierungsprozess für die Editordateien Der Generator zur Erzeugung des Editorquellcodes wird durch den in Kapitel 4.2 beschriebenen Wizard gestartet. Bei der Erzeugung des Generatorobjektes werden alle notwendigen Komponenten initialisiert. Das wären einerseits das JetGateway und die Datenstruktur, die das Alphabet kapselt. Nachdem diese Datenstruktur durch das Alphabet initialisiert wurde, können die Grammatikregeln analysiert und entsprechend die Ergebnisse in der Klasse AnalysedRules abgelegt werden. Damit stehen alle notwendigen Daten zur Generierung der

40 28 Entwurf und Implementierung Editordateien bereit. Der Ablauf der Generierung richtet sich danach, welche Informationen je Template gebraucht werden und nicht nach der Paketstruktur. Einem Template wird dabei entweder eine Instanz der Klasse AllSymbolData,SymbolData oder Node / EdgeFigureData zur Generierung einer Datei übergeben. Über diese drei Klassen sind dann alle Information für jedes Template abrufbar. Der Generierungsprozess wird durch die Klasse Generator gesteuert. Dort gibt es eine Methode start(), die durch im Wizard aufgerufen wird. Sie ruft mehrere Methoden auf, die im folgenden näher erläutert werden sollen. All diesen Methoden ist gemein, dass sie ein oder mehrere HashMaps haben, die als Schlüssel den Paketnamen und als Wert eine Liste von Namen von Templates enthält (siehe Abb. 4.4). Es wird dort auch ersichtlich, dass nur die Namen der Templates angegeben wird ohne deren Endung.javajet, da dieser noch in der zu erzeugenden *.java Datei verwendet wird. Map packagefiles = new HashMap(); List files = new LinkedList(); files.add("page"); files.add("editor"); packagefiles.put("editor",files); Abbildung 4.4: Beispiel einer Map für die Generierung Generierung mittels JET über dem JetGateway Zur Generierung des Java Quellcodes wird die Klasse JETEmitter aus dem EMF Framework verwendet, deren Steuerung durch die Klassen JetGateway übernommen wird. In den oben genannten Methoden werden im JetGateway für jede zu generierende Datei der Paketname, der Name des Templates gesetzt. Danach wird der absolute Pfad für dieses Template gesucht und dem JETEmitter übergeben, da sonst das Template nicht gefunden werden kann. Dieser übersetzt dann das Template wie in Kapitel beschrieben wurde und gibt einen String zurück. Dieser String wird dann durch die Methode save() des

41 4.3 Der Generierungsprozess für die Editordateien 29 JetGateways an die richtige Stelle im EditorPlugin unter Berücksichtigung des übergebenen Paketnames gespeichert. Dabei wird ersteinmal überprüft, ob der Ordner bereits existiert, sonst wird dieser neu erzeugt Generierung von einfachen Dateien Im Sinn des Generators sind einfache Dateien solche, aus deren Templates genau eine Datei im Editor erzeugt wird. Dies wird durch die Methode generatesimple() erledigt, die in start() aufgerufen wird. In diese Kategorie fallen zum Beispiel die Dateien für den Wizard, die Editorklassen, die die Schnittstelle zwischen Eclipse und GEF darstellen und die eigene EditDomain. Desweiteren wird ein EditPart generiert, der die Zeichenfläche des Editors darstellt. Wenn im Alphabet kein NodeSymbolType definiert wurde, der ein Container sein soll, dann bekommt dieser EditPart die Graphgrammatik als Modell übergeben, ansonsten ist es der Node, der den Container repräsentiert Generierung der Controller und der Dialoge An dieser Stelle wird für jeden SymbolType je ein EditPart (Controller) generiert. Wenn sich um einen NodeSymbolType handelt, der als Container auftritt, wird an dieser Stelle kein EditPart erzeugt, sondern ein EditPart wie im vorigen Abschnitt beschrieben. Die Erzeugung dieser Dateien wird durch die Methode generatecontrolleranddialogs geregelt. Für die EditParts gibt es genau ein Template, aus dem alle generiert werden können. Im Template (Editpart.javajet) muss dabei unterschieden werden zwischen Knoten - und Kantensymbolen, da diese unterschiedliche Basisklassen haben, dies wren org.eclipse.gef.editparts.abstractgraphicaleditpart und org.eclipse.gef.editparts.abstractconnectioneditpart. Für jeden SymbolType wird danach noch ein Dialog mit des Templates Dialog.javajet erzeugt, wenn dieser AttributeTypes besitzt. Die Anzahl der Einträge an TextFelder und Labels richtet sich dabei nach der Anzahl der AttributeTypes. Dem JETEmitter wird bei diesem Generierungsschritt immer ein Objekt vom

42 30 Entwurf und Implementierung Typ SymbolData übergeben Generierung von Node / Edge Dateien Bei einigen Dateien ist es notwendig zwischen Knoten und Kantensymbolen zu unterscheiden. Das betrifft unter anderem die EditPolicies und Commands, die für die Durchführung einer Regelanwendung verantwortlich sind. Dazu zählen die EditPolicies zum Erzeugen und Commands zum Löschen von Knoten und Kanten Generierung der Figuren Klassen Jede Figur aus dem Alphabet (sowohl ShapeFigure als auch Connection) ist später im Editor durch eine eigene Klasse repräsentiert. Das Paket tiger.templates.figure enthält dafür Templates, die wie folgt benutzt werden: ShapeFigures werden mit nodefigure.javajet erzeugt wenn mehrere ShapeFigures zu einem NodeSymbolType gehören und dieser zusätzlich über ein kind -Attribut verfügt, wird eine abstrakte Figurenklasse mit dem Template abstract.javajet erzeugt Connections werden mit edgefigure.javajet erzeugt abstract.javajet für alle ShapeFigures erzeugt In der abstrakten Klasse werden Labels für die Attribute des NodeSymbolTypes erzeugt, wenn das visibility Attribut auf true gesetzt ist. Damit ist sichergestellt, dass in jeder abgeleiteten Klass das Label vorhanden ist. Die Anzeige wird dann letztendlich in der entsprechende abgeleiteten Figurenklasse geregelt.

43 4.4 Datenstruktur zur Kapselung des Alphabets Datenstruktur zur Kapselung des Alphabets Diese Datenstruktur kapselt die Klassen des Alphabets für die Abbildung der Alphabetinformation in GEF und Draw2D konforme Klassen. Diese Vorgehensweise hat sich als nützlich herausgestellt, da in den Templates nur primitive Datentypen und String-Objekte übergeben werden können. Aus diesem Grund werden benötigte Ausdrücke bereits in diesen Klassen berechnet und eventuell als ein zusammengesetzter String zurückgegeben. Dadurch konnte die Komplexität der Templates verringert und deren Übersichtlichkeit bewahrt bleiben und eine Wartung ist auch leichter möglich. In Abbildung 4.5 ist eine Übersicht über diese Datenstruktur in Form eines Abbildung 4.5: Datenstruktur zur Kapselung des Alphabets im Generator Klassendiagramms gegeben. Es gibt eine Klasse AllSymbolData, die grundlegende Informationen wie Pluginname, Projektname und den Namen der VL- Spezifikation enthält. Im Gegensatz zu den anderen Klassen dieser Struktur gibt es keine direkte Entsprechung im Alphabet. Die Klasse SymbolData kapselt einen SymbolType aus dem Alphabet. Bei der Initialisierung wird geprüft, ob dieser SymbolType Attribute und Figuren hat.

44 32 Entwurf und Implementierung Wenn dies der Fall ist wird für ein Attribut eine Instanz der Klasse AttributeFigure erzeugt, die ein AttributeType und eine TextFigure kapselt. Für die Figur des SymbolTypes wird entsprechend eine Instanz der Klasse NodeFigureData oder EdgeFigureData erzeugt in Abhängigkeit davon, ob es sich um eine Shape- Figure oder eine Connection handelt. In Abbildung 4.6 wird eine Übersicht über die Klassen und welche Klassen des Alphabets gezeigt, durch die sie gekapselt werden. Die Klasse LinkTypeData kapselt einen LinkType und kann dadurch auch auf das Layout des LinkTypes zugreifen. Zurück zur SymbolData Klasse, deren Informationen unter anderem zur Erstel- 1 1 SymbolData -symbol[1] : SymbolType 1 SymbolType +getname() : String * EdgeFigureData -figure : Connection Connection -name : String -strokecolor : Color -strokewidth : ganz -strokestyle : Style 1 * ConnectionConstraint -kind : Enumeration * 1 1 -second * NodeFigureData -figure : ShapeFigure ShapeFigure -name : String -shape : Shape -bordercolor : Color -fillcolor : Color -defaultsize : Dimension «Schnittstelle» Figure +getposition() : Point +getname() : String -first 1 * * LayoutConstraint -kind : Enumeration * AttributeFigure -figure : TextFigure AttributeType -name : String -datatype : Enumeration -textlayout * 0..1 TextFigure -name : String -font : Font -fontcolor : Color -isvisible : Boolesch AttributeData -attrtype : AttributeType Abbildung 4.6: Datamanagement Klassen lung der EditParts und den Dialog im Editor dienen (vgl. Kapitel 4.3). getsourceconnection(): gibt eine Liste mit den Namen der LinkTypes, die über end mit dem gekapselten SymbolType verbunden sind, und den EdgeSymbolType, der über begin verbunden ist, zurück. Der Name des

45 4.4 Datenstruktur zur Kapselung des Alphabets 33 LinkTypes sollte dabei source oder target enthalten. gettargetconnection(): Funktioniert ähnlich der Methode getsource- Connection(), nur dass hier LinkTypenamen target oder end berücksichtigt werden. getsymbolfigures(): liefert eine Liste aller Figuren, die zu einem Symbol- Type gehören, zurück Figuren nach Draw2D Im folgenden soll näher erläutert werden, in welcher Weise die konkreten Layoutinformationen aus dem TIGER Alphabet nach Draw2D abgebildet werden. Für die visuelle Darstellung von SymbolTypes im generierten Editor müssen die Figuren Klassen aus Draw2D verwendet werden, da das von GEF so gefordert wird. Draw2D verfügt im Vergleich zu SWT nur über einen kleinen Satz an Figuren Klassen, d.h. eine komplexe Figur besteht aus vielen kleinen Figuren, die in einer bestimmten Weise angeordnet sind. Die Anordnung der Figuren wird im Alphabet durch die Klasse LayoutConstraint geregelt. Ein Layoutconstraint kann dabei folgende Werte haben: UNDEFINED, RIGHT, LEFT, ABOVE, BOTTOM, INSIDE. Der Generator muss nun diese LayoutConstraints analysieren, auswerten und mit den durch die Layoutconstraints definierte Anordnung mit Hilfe der Layoutmanager aus Draw2D umsetzen. Bevor die Beschreibung der Umsetzung erfolgt, soll zunächst einmal der Aufbau einer Draw2D Figur und die Verbindung zum Alphabet anhand einer Stelle eines Petrinetzes gezeigt werden. Aufbau einer Figur Wie in Abb. 4.7 zu sehen ist besteht solch eine mit Draw2D gezeichnete Figur aus einer unsichtbaren rechteckigen Containerfigur (gestrichelter Rahmen), die alle anderen Figuren beinhaltet. Diese muss im Alphabet nicht spezifiziert werden. Alle anderen müssen dagegen im Alphabet angegeben werden, wobei die Textfigures eine besondere Rolle spielen, da ihr visibility Attribut zusätzlich

46 34 Entwurf und Implementierung Abbildung 4.7: Aufbau einer Figur mit Draw2D über ihre Sichtbarkeit entscheidet. Auf der linken Seite in Abb.4.7 ist eine Figur für eine Stelle zu sehen, in deren Mitte die Anzahl der Tokens und unterhalb der Name angezeigt wird. Diese Figur wird mit Hilfe der Klasse org.eclipse.draw2d.ellipse und die anderen beiden TextFigures mit Hilfe von org.eclipse.draw2d.label visualisiert. Auf der rechten Seite von Abb. 4.7 sind die korrespondierenden Alphabetklassen angegeben. Dort wird die Anordnung durch je ein Layoutconstraint zwischen der jeweiligen TextFigure und ShapeFigure beschrieben. Der Generator kann folgende ShapeFigures mit Draw2D zeichnen: Rectangles, RoundedRectangles, Circles, Ellipses, Polygons. Abbildung der Alphabetfigurenklassen nach Draw2D Die Alphabetklassen, die das konkrete Layout repräsentieren, werden folgendermaßen nach Draw2D abgebildet: ShapeFigure eine Kindklasse vonorg.eclipse.draw2d.shape Connection org.eclipse.draw2d.polylineconnection TextFigure org.eclipse.draw2d.label Eine Ausnahme bilden hier die Polygone. Wenn eine ShapeFigure ein Polygon sein soll, muss dafür eine eigene Figurenklasse, die von org.eclipse.draw2d.figure erbt, implementiert werden. Dazu wird vom Generator innerhalb der Figurenklasse eine innere Klasse erzeugt, mit der ein Polygon gezeichnet werden kann.

47 4.4 Datenstruktur zur Kapselung des Alphabets 35 Vorgehensweise bei der Erstellung von Figurenklassen aus dem Alphabet mit Draw2D Der Generator kann den in Abb. 4.8 dargestellten Figurenaufbau aus einem Alphabet umsetzen. Der Rahmen soll dabei eine ShapeFigure darstellen, an der die anderen Figuren ausgerichtet weren können. Figure stellt hierbei das Interface Figure aus dem Alphabet dar. Bei der Erstellung von Figurenklassen mittels Draw2D müssen drei Schritte zur korrekten Darstellung einer Figur im Editor, vollzogen werden. Abbildung 4.8: Figure Aufbau durch den Generator auswertbar 1. Alle Figuren müssen im Konstruktor erstellt und durch LayoutManager angeordnet werden. Dies beinhaltet auch das Setzen von Farben, Schriften usw.. 2. die Größe der Figuren muss in der überschriebenen Methode getpreferredsize() von Draw2D zur Laufzeit des Editors berechnet werden 3. die berechnete Größe wird durch Überschreiben der validate() Methode gesetzt Für jede ShapeFigure aus dem Alphabet wird eine eigene Figurenklasse erzeugt. Der Generator nimmt zunächt einmal die gekapselte ShapeFigure aus der Klasse NodeFigureData als Basisfigur, bei der die Analyse gestartet wird. Wenn ein NodeSymbolType mehrere ShapeFigures hat, wird dies für jede getan. Es hat sich

48 36 Entwurf und Implementierung während des Entwurfs als hilfreich herausgestellt zuerst alle vertikal bezüglich der Basisfigur angeordneten Figuren zu betrachten. Dafür gibt es eine Methode getverticalelements(), die eine Liste von vertikal angeordneten Figuren zurückgibt. Standardmäßig wird die Basisfigur in diese Liste mitaufgenommen. Alle LayoutConstraints, die zu der Basisfigur gehören, werden danach betrachtet, wobei die Basisfigur über second mit dem Layoutconstraint verbunden sein muss. Wird eine Figur gefunden, die sich über (LayoutConstraint.ABOVE) der Basisfigur befindet, wird sie in der Liste vor der Basisfigur eingefügt, ansonsten bei (LayoutConstraint.BELOW) hinter der Basisfigur. Für die horizontal angeordneten Figuren wird das gleiche Verfahren angewendet mit Hilfe der Methode gethorizontalelements(), außer dass die Basisfigur nicht in die Liste mitaufgenommen wird. Hierbei muss die Basisfigur wieder über second mit den LayoutConstraints verbunden sein und die LayoutConstraints RIGHT und LEFT werden berücksichtigt. Auch hier ist die Liste geordnet: Wenn ein Element rechts steht wird es in der Liste vorn eingefügt ansonsten hinten. Schließlich wird noch mit Hilfe der Methode isinside() geprüft, ob die Basisfigur eine innere Figur hat, indem nach dem LayoutConstraint INSIDE gesucht wird. Der eben genannte Ablauf wird für die Erstellung des Konstruktors einer Figurenklasse verwendet wie es in Punkt 1 beschrieben worden ist. Die Berechnung der Figurengröße (siehe Punkt 2) richtet sich nach der Anzahl und Anordnung der Figuren bezüglich einer Basisfigur. Die Größe berechnet sich aus der Höhe und der Breite, wobei sich die Höhe aus den einzelnen Figuren berechnet, die man mit getverticalelements() bekommt und die Breite aus den einzelnen Figuren, die man durch gethorizontalelements() erhält. Dafür wird ein Ausdruck als String erzeugt, was durch die Methoden getwidth() und getheight() aus der Klasse NodeFigureData geregelt wird. Wenn die Basisfigur noch eine innere Figure hat, muss deren Größe vor der Größe der Gesamtfigur berechnet werden, Im Fall einer TextFigure, bei der sich die Größe zur Editorlaufzeit noch ändern kann, wird der Ausdruck zur Berechnung der Größe der inneren Figur in der Klasse NodeFigureData mit der Me-

49 4.4 Datenstruktur zur Kapselung des Alphabets 37 thode getinside() vorgenommen, die den Ausdruck als einen String zurückgibt, so dass dieser nur noch im Template eingetragen werden muss. Bei Aktivitätendiagrammen steht in einer einfachen Aktivität der Name in der Mitte der Figur. Dieser kann sich zur Editorlaufzeit ändern, so dass die Figur vergrößert bzw. verkleinert werden soll. Um die Größe der Gesamtfigur zu begrenzen, wurde ein zusätzliches Attribut maximumsize : Dimension in der Alphabetklasse ShapeFigure definiert, mit dem eine maximale Größe der Gesamtfigur bestimmt werden kann. Wenn der Text nun größer ist als die Gesamtfigur, wird dieser an einer bestimmten Stelle abgeschnitten und durch drei Punkte ersetzt, was durch Draw2D geregelt wird. Damit die Basisfigur mit ihrer DefaultSize angezeigt werden kann, muss wie in Punkt 3 erwähnt, die validate() Methode überschrieben werden. Darin wird dann die DefaultSize nochmal explizit gesetzt. Die Erstellung der Connections ähnelt dem der ShapeFigures. Für jede Connection wird ebenfalls eine eigene Klasse erzeugt, die immer von org.eclipse.draw2d.polylineconnection erbt. Die Verwendung von Layoutmanangern entfällt bei Connections. Um Figuren an einer Connection auszurichten gibt es im Alphabet verschiedene ConnectionConstraints ( AT SRC, AT CENTER, AT TARGET ), mit denen Figuren (ShapeFigures und TextFigures) in Beziehung zu den Connections gesetzt werden können. In Draw2D wird dies durch die Klasse ConnectionLocator erledigt, der genau die Möglichkeiten der ConnectionConstraints aus dem Alphabet unterstützt, was die Ausrichtung einer TextFigure bezüglich einer Connection betrifft. Zwischen ShapeFigures und Connections wurde bis jetzt das ConnectionConstraint AT CENTER genommen. Für ShapeFigures müssen diese ConnectionConstraints in Draw2D konforme AnchorPoints umgewandelt werden. Anchorpoints werden in dieser Ausbaustufe vom Generator noch nicht unterstützt. Durch den Generator werden die beiden in Draw2D implementierten Anker EllipseAnchor für Kreise und Ellipsen und ChopboxAnchor für alle anderen Figuren verwendet. Durch diese beiden Klassen wird ein Anker in der Mitte einer Figur definiert. Die Connection startet / endet am Rand der entsprechenden Figur. Bei anderen

50 38 Entwurf und Implementierung Figuren wie dem Polygon kann es passieren, dass sich eine Connection nicht am Rand der Figur gezeichnet wird. Für eine Connection können Layoutinformationen für Linienfarbe, Linienart und Linienstärke gesetzt werden. Es werden alle in der Connectionklasse definierten Linienarten durch den Generator unterstützt. LinkTypes, die in der ersten Ausbaustufe des Generators Node- SymbolTypes und EdgeSymbolTypes miteinander verbinden, können über ein konkretes LinkLayout verfügen. Das kann eine Raute oder auch eine Pfeilspitze sein, deren Füll- und Rahmenfarbe durch das Alphabet definiert werden können. Diese beide Layoutmöglichkeiten werden durch die Klassen org.eclipse.draw2d.polygondecoration und org.eclipse.draw2d.polylinedecoration unterstützt und sind immer an eine org.eclipse.draw2d.polylineconnection gebunden. Daher wird das LinkLayout immer in der Figurenklasse definiert, die eine Connection repräsentiert. 4.5 Der Regelanalysierer Eine Analyse der Regeln aus der Graphgrammatik ist für die Durchführung von Editieroperationen im Editor notwendig. Durch sie kann nämlich festgelegt werden, ob eine Editieroperation über die Palette oder das Kontextmenü durchgeführt werden soll. Ein entsprechender Eintrag wird dann in der Palette oder im Kontextmenü erzeugt. Zur besseren Analyse werden die Regeln in Einfüge, Lösch, Bearbeitungs, Verschiebe - oder sonstige Regeln durch den Regelanalysierer eingeteilt. Die Festlegung zu dieser Einteilung fiel während der Entwicklung dieser Komponente durch den Autor und hatte folgenden Hintergrund: Einfügeregeln benötigen fast immer ein Dialog zum Setzen von Attributwerten. Die linke Regelseite ist entweder leer oder hat einen oder mehrere Knoten, die dann erhalten bleiben. Daneben ist die Anzahl der Knoten und Kanten der linke Seite kleiner gleich der rechten Seite. Bei Löschregeln können die zu löschenden Knoten durch Analyse der beiden

51 4.5 Der Regelanalysierer 39 Regelseiten identifiziert werden, denn sie haben kein Mapping mit der rechten Regelseite. Bei Bearbeitungsregeln wird stets ein Dialog benötigt, damit die Attributwerte eines selektierten Objektes (Knoten oder Kante) geändert werden können. Im Gegensatz dazu benötigen die Verschiebe-Regeln keinen Dialog, da hier nur die Position eines Knotens verändert wird. Sollte es für Kanten eine solche Regel gibt, wird diese vom Regelanalysierer ignoriert Struktur des Regelanalysierers Ziel der Regelanalyse ist es, alle benötigten Informationen einer Regel so aufzubereiten, dass diese in den Templates schnell und einfach abgefragt werden können. Dazu wurde die Struktur in Abb. 4.9 entworfen. Die Klasse RuleAna- Abbildung 4.9: Struktur für den Analysierer lyser bekommt vom Generator alle Regeln aus der Graphgrammtik übergeben. Sie bietet diverse Methoden zur Regelanalyse, welche durch den Generator aufgerufen werden, um die Regeln zu analysieren. Für jeden SymbolType wird dabei eine Methode pro Kategorie aufgerufen. Bei Regeln, die nicht in diese Kategorien passen wird ein Standardverfahren angewendet. Für jede Kategorie gibt es eine Methode, die die Analyse vornimmt, z.b. analyseinsertingrules(type:string). Hier wird der Typ von jedem SymbolType übergeben. Der Regelanalysierer hat eine Referenz auf genau eine Instanz der Klasse AnalysedRules, in der die Analyseergebnisse abgelegt werden. Für jede Kategorie gibt es auch eine entsprechende java.util.map, in der Typ des entsprechenden SymbolTypes als Schlüssel und eine Liste der dazugehörigen analysierten Re-

52 40 Entwurf und Implementierung geln hält. Für die analysierten Regeln wurde eine eigene Klasse entworfen, die unter anderem den Regelnamen, die Anzahl der Mappings und deren beteiligte Typen und eine Abbildung von den Inputparametern zu den Attributen enthält. Dazu gibt es eine Klasse NodeType, die einen Typ und alle dazugehörigen Inputparameter speichert, damit später auch nachvollzogen werden kann, welche Inputparameter an welche Attribute gebunden sind, wurde eine Klasse ParmeterMap entworfen. Dort werden die Inputparameter mit den Attributen assoziiert Analyse der Regeln Die Schlüsselwörter, die zur Einteilung der Regeln benötigt werden, sind in entsprechende Arrays in der Klasse RuleAnalyser abgelegt. Jde Methode, die der Analyse einer Regel dient, bekommt den Typ eines SymbolType als String übergeben. Innerhalb dieser Methode wird für jede Regel aus der Graphgrammatik, wenn sie in eine der Kategorien passen, ein RuleData-Objekt erzeugt. Im folgenden wird bei den einzelnen Regeln mitangegeben, welche Schlüsselwörter zur Einordnung in die entsprechende Kategorie dienen. Einfügeregeln Zu den Einfügeregeln zählen alle Regeln, deren Namen die Schlüsselwörter add, insert, create und den übergegeben Typ enthalten. Bei ihnen wird zunächst die linke Regelseite betrachtet. Wenn sie leer ist, wird sie in der Klasse RuleData als Basisregel markiert. Dabei ist die Festlegung einer Basisregel für eine Regel abhängig davon, ob ein Knoten oder eine Kante eingefügt wird. Regeln, die einen Knoten einfügen sind dann Basisregeln, wenn deren linke Seite leer ist. Bei Regeln die eine Kante einfügen, müssen auf der linken Seite zwei Knoten vorhanden sein. Alle Basisregeln werden dann in die Palette des Editors eingetragen. Wenn auf der linken Seite genau ein Knoten vorhanden ist und dieser durch ein Mapping mit der rechten Regelseite verbunden ist, wird diese Regel in das Kontextmenü aufgenommen. Dazu ist es wichtig den Typ dieses Knotens zu

53 4.5 Der Regelanalysierer 41 wissen, da dieser mit dem im Editor selektierten Objekt übereinstimmen muss. Wenn auf der linken Seite mehrere Elemente stehen, werden alle Knoten ignoriert, deren Typ nicht dem übergebenen Typ entsprechen. Wenn dies jedoch mehere Knoten sind, wird es schwierig diesen Knoten für das Mapping zwischen selektiertem Objekt im Editor und Knoten der linken Regelseite zu bestimmen. Danach wird im AttributeContext einer Regel geschaut, ob es Inputparameter für sie gibt. Es wird dann in alle Knoten der rechten Regelseite geschaut, welche Attribute eines Knotens an diese Inputparameter gebunden sind. Für jeden betreffenden Knoten wird eine Instanz der Klasse NodeType erzeugt, die den Typ des Knotens und die ParameterMap enthält, in denen die Inputparameter mit den Attributen und dem entsprechenden Datentyp assoziiert sind. Für jeden Knoten, dessen Attribute an Inputparameter gebunden sind, wird ein Dialog geöffnet. Dabei erscheint der Name des Inputparameters als Label im Dialog. Löschregeln Vom Regelanalysierer werden alle Regeln als Löschregeln identifiziert, die die Schlüsselwörter delete, remove, destroy enthalten. Löschregeln sind dadurch gekennzeichnet, dass die linke Regelseite größer als die rechte Seit und die zu löschenden Knoten und Kanten auf der linken Seite nicht an einem Mapping mit der rechten Seite beteiligt sind. Wie bei den Einfügeregeln gibt es auch bei den Löschregeln Basisregeln. Eine Basisregel ist hier dadurch gekennzeichnet, dass auf der linken Seite nur ein Knoten und auf rechten Seite dann kein Knoten mehr vorhanden ist. Die Analyse beginnt also mit der Festlegung, ob es eine Basisregel ist oder nicht. Danach wird der Knoten auf der linken Seite gesucht, der dem übergebeben Typ entspricht und nicht am Mapping mit der rechten Seite beteiligt ist. Desweiteren wird auch hier überprüft, ob es Inputparameter gibt. Wenn ja, wird hier wie bei den Einfügeregeln verfahren.

54 42 Entwurf und Implementierung Bearbeitungsregeln Bearbeitungsregeln sollten die Schlüsselwörter edit,change und den übergebenen Typ enthalten. Mit den Bearbeitungsregeln werden Attributwerte einzelner Knoten geändert. Für jeden NodeSymbolType, der Attribute hat, wird auch ein Dialog mit entsprechenden Feldern generiert. Die Regel wird dahingehend untersucht, welcher Dialog für den Knoten, deren Attribute geändert werden soll, geöffnet werden soll. Dazu werden der Typ des Knotens und die Attribute herausgesucht, die an Inputparameter gebunden sind. Im Template für die Bearbeitungsregeln gibt es dann eine Methode, die den Typ übergeben bekommt und den Knoten aus der linken Regelseite heraussuchte, um ein Mapping zwischen dem selektierten und diesem Regelknoten herzustellen. Verschieberegeln Für Verschieberegeln gibt es nur ein Schlüsselwort, nämlich move. Verschieberegeln zeichnen sich dadurch aus, dass nur die Posiitionskoordinaten geändert werden. Es ist festgelegt, dass für Positionskoordinaten x und y vom Typ Integer verwendet werden. Daher wird bei der Analyse nur nachgeschaut, ob es eine Regel mit dem entsprechenden Schlüsselwort und dem übergebenen Typ gibt. Eine Überprüfung von Inputparametern, die einen Dialog benötigen wird hier nicht weiter vorgenommen. Sonstige Regeln 4.6 Der generierte Editor Da der generierte Editor mit Hilfe von GEF implementiert wurde, basiert er auch auf der Model-View-Controller Architektur. Im folgenden wird ein Überblick über die Paketstruktur des generierten Editors gegeben. Danach wird die GUI des Editors und kurz sein interner Aufbau beschrieben. Schließlich erfolgt eine detailierte Beschreibung der Einbindung von AGG in den Editor.

55 4.6 Der generierte Editor Paketstruktur Die Paketstruktur spiegelt die Paketstruktur der Templates aus dem Generator wider. (Das Sternchen steht für den entsprechenden Paketname, der sich aus dem Projektname ergibt): Abbildung 4.10: Paketstruktur des generierten Editors *.action: Dieses Paket enthält alle Einträge des Kontextmenüs *.commands: In diesem Paket sind alle Klasssen zu finden die für eine Regelanwendung verantwortlich sind *.editparts: Hier sind alle Controller (EditParts) abgelegt. Für jeden SymbolType einer. *.editpolicy: Dieses Paket beinhaltet alle an den EditParts registrierten EditPolicies, die dem Aufruf der Klassen aus dem Command-Paket dienen. *.editor: Hier sind Klassen definiert, die die Integration des GEFbasierten Editors in Eclipse regeln. *.figure: Enthält die Figurenklassen für je eine ShapeFigure / einer Connection *.model: Enthält interne benötigte Klassen.

56 44 Entwurf und Implementierung *.wizard: Implementierung des Wizards, der eine neue Datei mit dem Startgraphen erzeugt Aufbau des Editors Der Editor besteht aus einer Palette auf der linke und einer Zeichenfläche auf der rechte Seite (siehe Abb. ). In der Palette gibt es eine Unterteilung in Symbols (NodeSymbolTypes) und Connections (EdgeSymbolType). Es werden nur erzeugende Regeln erscheinen (vgl. Fall 1 und 2 aus Abb. 3.1). Wenn ein Container definiert wurde, erscheint dort der Name des Containers, sonst gibt es nur eine Seite mit dem Name der VL-Spezifikation. Ein Kontextmenü kann über die rechte Maustaste geöffnet werden. Die Anzahl der Einträge ist abhängig vom selektierten Objekt. Im Kontextmenü sind Erzeugende, Löschende und Editierregeln mit deren Regelnamen zu sehen Interner Aufbau des Editors Das Editor Plugin ist ebenfalls mittels des Erweiterungspunktes org.eclipse.ui.editors in Eclipse eingebunden. Die Klasse Editor.java, die von einem MultiPageEditor erbt, ist dafür verantwortlich. Ein Editor besteht in der Regel aus einer Seite, es denn es gibt eine Art Container, denn dann gibt es für jeden Container eine Seite. Für jede Seite wird wird eine eigene EditDomain angelegt, die einen CommandStack zur Verwaltung der Commands für die Regelanwendungen initialisiert und einen GraphicalViewer erstellt, der für die Verwaltung der EditParts verantwortlich ist. Darüberhinaus wird in der Editor.java ein DelegationCommandStack, der die CommandStacks aus den einzelnen EditDomains verwaltet, und eine ActionRegistry erstellt, mit der Aktionen definiert und im Kontextmenü angezeigt werden können. Aktion dienen zum Aufruf von Commands aus dem Kontextmenü heraus. Diese Klasse implementiert Methoden zum Laden und Speichern der vom Wizard erstellten Editordatei.

57 4.6 Der generierte Editor Anbindung von AGG an den Editor Da die Klasse Editor.java für das Laden und Speichern einer Graphgrammatik verantwortlich ist, wird in ihr auch in ihr eine Instanz einer GraGra gehalten. Darüberhinaus wird eine Instanz der Klasse GraTra erzeugt, die diese Instanz der GraGra enthält und über den Lebenszyklus des Editors erhalten bleibt. Beim Erzeugen einer neuen Seite beim Start des Editors wird eine eigene Edit- Domain (GraTraEditDomain) erzeugt, die die beim Laden erzeugte GraTra und somit auch die GraphGrammatik mit den Regeln beihaltet. Bei der Erzeugung der Commands in den EditPolicies kann nun auf diese Instanz der GraTra zugriffen werden. Für jeden SymbolType, für den es im Alphabet eine direkte Entsprechung in AGG in Form eines Node gibt, wird ein EditPart (Controller) generiert, der solch einen Node als Modell hält. Die Controller implementieren das Interface AttrEvent aus AGG, so dass Änderung an den Attributewerten auf den View propagiert werden können. Sobald sich ein Attributwert eines Node ändert, werden die Änderungen durch die EditParts abgefangen. An diesen EditParts werden weiterhin diverse EditPolicies registriert, mit denen man verschiedenste Commands erzeugen kann, mit denen Regeln für das Löschen, Bewegen und Einfügen von SymbolTypen angewendet werden können (siehe Abb. 4.11). Anwendung einer Regel im Editor Die Regelanwendungen werden durch die Commands gesteuert. Der Regelname, die GraphGrammatik und die im Editor selektierten Objekte werden dabei über die entsprechende EditPolicy abgefragt und dem erzeugte Command übergeben. Für alle Commands gibt es zwei durch den Editor generierten abstrakte Basisklassen NodeCommand und EdgeCommand, in denen die GraphGrammatik, der erzeugte Match und die zu anwendene Regel gehalten werden. In diesen beiden Klassen befindet sich eine execute Methode, die die Durchführung eines Transformationsschrittes regelt. Alle Commands, die ein NodeSymbolType editieren erben von NodeCommand und alle die EdgeSymbolTypes editieren erben

58 46 Entwurf und Implementierung Abbildung 4.11: Schematischer Ablauf einer Regelanwendung im Editor von EdgeCommand. Es gibt Commands zum Erzeugen, Löschen, Editieren und Bewegen von Objekten. Beim Erzeugen von den Commands in den EditPolicies wird ein Regelname übergeben. Dieser kommt vom Kontextmenü oder auch aus der Palette. Darüberhinaus wird dem erzeugten Command die GraTra Instanz aus der EditDomain übergeben. Nachdem alle notwendigen Daten im Command gesetzt wurden, wird die execute Methode des Commands aufgerufen. In einem Command können eine oder mehrere Regeln behandelt werden. Regeln, die beispielsweise einen Knoten löschen unabhängig vom Typ, befinden sich alle in der Klasse NodeDelete.java. Es werden zunächst alle Inputparameter mit Hilfe von Dialogen gesetzt, die zur Durchführung einer Regel benötigt werden. Danach wird die Regel aus der GraphGrammatik über den gegeben Name geholt und über den AttrContext werden die durch die Dialoge gesammelten Werte den entsprechenden Attributen zugewiesen. Als letzter Schritt vor dem Transformationsschritt wird ein Match erzeugt und das selektierte Objekt aus dem Editor auf einen entsprechenden Node auf der linken Regelseite gemappt. Dafür gibt es eine vom Autor entwickelte Methode, die das regelt. Die Parameter für dieses Methode werden durch den Regelanalysierer bestimmt. Das sind einmal der Typ des Node als String auf den gemappt werden soll und ob dieser ein Mapping mit der rechten

59 4.6 Der generierte Editor 47 Regelseite hat oder nicht als booleschen Wert. Dann wird der entsprechende Knoten aus der linken Regelseite genommen und mit dem selektierten Objekt im Editor gemappt. Schließlich wird nun die execute Methode aus der Superklasse aufgerufen. Zunächst wird aus dem partiellen Match zwischen linker Regelseite und dem Hostgraphen durch Aufruf von nextcompletion() am Match ein totaler Match gemacht. An dieser Stelle werden also die Vorbedingungen (z.b. die Dangling Condition) für den Transformationsschritt geprüft. Bei Auftreten eines Fehlers werden entsprechende Fehlermeldungen über einen Dialog dem Benutzer mitgeteilt. Daraufhin folgt noch eine Prüfung des Matches mit Hilfe der Methode isvalid(). Danach wird der Transformationsschritte durch Aufruf von GraTra.apply(Match m) durchgeführt. Bei korrekter Durchführung wird ein entsprechender Event (GraTraEvent.SPEP COMPLETED)von AGG geworfen, der vom EditPart, der den GraTraEventListener registriert hat, abgefangen und eine entsprechende Aktualisierung des Views vorgenommen. Der GraTraEventListener wird vom obersten EditPart implementiert, der die Zeichenfläche des Editors darstellt. Bei einem Container hält dieser EditPart den Containerknoten als Modell, ansonsten die GraGra. Die erzeugten Matches werden nach Regelanwendung, egal ob erfolgreich oder nicht, wieder gelöscht. Anbindung einer externen Schnittstelle Neben der Nutzung einer Graphgrammatik als Modell, kann noch ein Modell in Form von Java Klassen angebunden werden. Dies wird im folgenden als außenstehendes Modell bezeichnet, um eine Verwechslung zu vermeiden. Die Kommunikation zwischen dem außenstehende Modell und dem Editor erfolgt über AGG, d.h das Erzeugen, Löschen und Aufruf von Methoden im außenstehenden Modell wird durch eine Regelanwendung gesteuert. Im Knoten eines Graphen werden jeweils ein oder mehrere Objekte des außenstehende Modells als Attribut gehalten. Die Anbindung eines außenstehenden Modells muss nur bei der Definition der Regeln erfolgen und nicht im Alphabet, d.h. die Typen des Modells müssen nicht als AttributeTypes des Alphabets definiert.

60 48 Entwurf und Implementierung Abbildung 4.12: Anbindung einer externen Schnittstelle an den Editor 4.7 Benutzte Technologien Für den Entwurf und die Implementierung wurden folgende ProgrammPakete verwendet: Java in der Version 5.0 [Jav] AGG in der Version [AGG] JGL Xerces Eclipse in der Version 3.1M4 [Ecl05] GEF in der Version [GEF] JET, das Bestandteil von EMF [Emf] ist und in der Version verwendet wird.

61 Kapitel 5 TestEditoren In diesem Kapitel soll der Generator anhand von drei Beispieleditoren getestet werden. Dies soll ein Editor für Petrinetze, einer für einfache Aktivitätendiagramme und einer für einen Automaten sein. Für die Editoren wird zunächst das Alphabet angegeben. Zunächst wird immer der abstrakte Teil gezeigt und dann der mit der konkreten Syntax. Anschließend folgen die Grammatikregeln und dann ein Screenshot des entsprechenden Editors. 5.1 Editor für Petrinetze Ein Petrinetz besteht aus Stellen und Transitionen, die über ArcTPs und ArcPTs miteinander verbunden sind. In den folgenden beiden Unterabschnitten wird ein Alphabet und eine Graphgrammatik für Petrinetze vorgestellt Alphabet Für den Petrinetzeditor wird zunächst die abstrakte Syntax bestehend aus NodeSymbolTypes, EdgeSymbolTypes und schließlich LinkTypes definiert. Im Petrinetzeditor gibt es zwei NodeSymbolTypes (Place, Transition), zwei EdgeSymbolTypes (ArcPT, ArcTP) und vier LinkTypes (arctpsource, arctptarget, arcptsource, arcpttarget). In Abbildung 5.1 ist ein Überblick über das Alphabet 49

62 50 TestEditoren gegeben. Im oberen Teil befindet sich die abstrakte und im unteren die konkrete Syntax (hellblau markiert). Die gestrichelten Linien zeigen an, welche Teile aus der abstrakten Syntax mit welchem Layout verbunden ist. Im Anhang A ist ein vollständiges Alphabet für Petrinetze zu finden. Dort ist die Instanziierung der einzelnen Alphabetklassen für ein Petrinetz zu finden. Zunächst werden dort alle Elemente der abstrakten Syntax erzeugt und dann alle Klassen für das konkrete Layout instanziiert. In Abbildung 5.2 sind die einzelnen Figuren für die SymbolTypen aus dem Al- Abbildung 5.1: Alphabet für ein Petrinetz phabet dargestellt. Für die Stelle wird ein Kreis definiert, dessen Attribut token sich in der Mitte befindet und dessen Attribut name sich unterhalb des Kreises

63 5.1 Editor für Petrinetze 51 befindet. Der Name der Transition wird als Rechteck dargestellt und ihr Name befindet sich oberhalb des Rechtecks. Die beiden EdgeSymbolTypes werden durch Linien dargestellt und ihre Inschrift in der Mitte der Linie platziert. Die Pfeilspitze, die das konkrete Layout des LinkTypes darstellt, wird an das Ende der Linie gepackt. Abbildung 5.2: konkretes Aussehen der einzelnen Figuren Grammatik Im folgenden werden die Regeln der Graphgrammatik für Petrinetze vorgestellt. Für diese Graphgrammatik ist die DanglingCondition eingeschaltet. In Abbildung 5.3 sind die Einfügeregeln zu sehen. Es können Stellen und Transitionen eingefügt werden, die keine gleichen Namen haben. Durch einen Dialog werden der Name und die Anzahl der Tokens über einen Dialog eingegeben, die Position wird über die Position des Curors auf der Zeichenfläche ermittelt und gesetzt. Desweiteren können Verbindungen zwischen Stellen und Transitionen eingefügt werden, wenn es bereits eine Stelle und eine Transition gibt. Über einen Dialog werden die Inschriften für die Verbindungen gesetzt. Mit den letzten beiden Regeln aus Abbildung 5.3 können für ein ausgewähltes Objekt im Editor eine Stelle mit entsprechender Verbindung / eine Transition mit entsprechender Verbindung erzeugt werden. Neben den Einfügeregeln gibt es Löschregeln (siehe Abb. 5.4), die die von der Einfügeregeln erzeugten Strukturen wieder löschen können. Für jeden SymbolType gibt es Bearbeitungsregeln (siehe Abb. 5.5), mit denen die Inschrift der beiden EdgeSymbolTypes, die Namen der NodeSymbolTypes und bei der Stelle noch zusätzlich die Anzahl der Tokens geändert werden kann. Für die beiden NodeSymbolTypes müssen noch Verschieberegeln definiert werden (siehe Abb. 5.6, so dass sie beide über die Zeichenfläche bewegt werden können. Für die Petrinetze ist es nicht notwendig

64 52 TestEditoren Abbildung 5.3: Einfügeregeln Abbildung 5.4: Löschregeln Abbildung 5.5: Bearbeitungsregeln Abbildung 5.6: Verschieberegeln einen Startgraphen zu definieren.

65 5.2 Editor für einfache Aktivitätendiagramme Editoraufbau In Abbildung 5.7 ist der aus dem oben beschriebenen Alphabet generierte Editor für Petrinetze zu sehen. Der Aufbau entspricht dem, den man aufgrund des Alphabets und der Regeln erwarten konnte. In der Palette gibt es jeweils zwei Einträge für Symbole und Connections, da es für die NodeSymbolTypes Einfügeregeln (vgl. Abb. 5.3) gibt, deren linke Seiten leer und auf der rechten Seite der zu erzeugende NodeSymbolType zu finden ist. Für die beiden EdgeSymbolTypes gibt es ebenfalls zwei Regeln, die auf der linken Seite zwei NodeSymbolTypes erhält, die durch sie verbunden werden soll. Deshalb gibt es für sie auch Einträge in der Palette. Desweiteren werden die Einfügeregeln addedgeplace und addedgetransition im Kontextmenü aufgenommen und in Abhängigkeit des selektierten Objektes angezeigt. Für eine Transition wird die erstere und für eine Stelle die zweite angezeigt (vgl. dazu Abb.5.7). Alle Löschregeln und Editierregeln werden ebenfalls im Kontextmenü in Abhängigkeit vom selektiertem Objekt angezeigt. Die Verschieberegeln für die Stelle und die Transition werden durch Verschieben der grafischen Objekte auf der Zeichenfläche angewendet. Für alle Regeln können undo / redo Operationen angewendet werden. Auf der rechten Seite befindet sich die Zeichenfläche, auf der beliebig viele Petrinetze gezeichnet werden können. 5.2 Editor für einfache Aktivitätendiagramme Anhand des Editors für einfache Aktivitätendiagramme wird das syntaxgesteuerte Editieren von Diagrammen verdeutlich. Es gibt einen Startgraphen in der Grammatik, ohne den kein Aktivitätendiagramm gezeichnet werden kann.

66 54 TestEditoren Abbildung 5.7: Screenshot des generierten Petrinetzeditors VL-Spezifikation Alphabet Ein Aktivitätendiagramm besteht aus einem NodeSymbolType (Activity) und einem EdgeSymbolType (Next) in der abstrakten Syntax (siehe Abb.??. Für eine Aktivität gibt es vier verschiedene visuelle Darstellungen, die über ein kind -Attribut die visuelle Darstellung der Aktivität bestimmen. Es gibt visuelle Darstellungen für Aktivitäten, die als Startknoten, Endknoten, als einfache Aktivität und als Entscheidung visualisiert werden sollen. Die Definitione von einfachen Aktivitäten und Entscheidungen ist in Abb.?? und?? zu sehen. Desweiteren hat eine Aktivität noch eine Attribut name. Für das Attribut name wird eine sichtbare TextFigure definiert und für das kind Attribut eine unsichtbare TextFigure (siehe dazu Abb.??). Graphgrammatik Für die Aktivitätendiagramme gibt es Einfüge, Lösch, Bearbeitungs und Verschieberegeln. In Abb. 5.8 sind die Einfügeregeln zu sehen. Dort ist zu sehen,

67 5.2 Editor für einfache Aktivitätendiagramme 55 dass es keine linke Regelseite gibt, d.h. es wird keinen Eintrag in der Palette zum Erzeugen von Aktivitäten geben, sondern nur im Kontextmenü. In Abb. Abbildung 5.8: konkrete Syntaxregeln zum erstellen von einer Aktivität und ganzer Strukturen 5.9 sind alle Löschregeln für die Aktivitäten zu sehen. Bei allen Regeln, die Abbildung 5.9: konkrete Syntaxregeln zum löschen von Aktivitäten im Kontextmenü erscheinen, wird in Abhängigkeit vom selektierten Objekt im Editor geprüft, ob die Regel anwendbar ist oder nicht. Wenn sie anwendbar ist, dann erscheint sie im Kontextmenü.

68 56 TestEditoren Abbildung 5.10: 5.3 Editor für Automaten VL-Spezifikation Anbindung einer externen Schnittstelle Abbildung 5.11:

69 Kapitel 6 Zusammenfassung und Ausblick 6.1 Zusammenfassung In dieser Diplomarbeit wurde ein Generator konzipiert und implementiert, der aus einer gegebenen VL-Spezifikation einen grafischen Editor erzeugt, der regelbasiert und syntaxgesteuert arbeit. Für die Regelanwendungen wurde die Graphtransformationsmaschine AGG an den Editor angebunden. Der Generator und der generierte sind als Eclipse Plugins realisiert, so dass sie leicht in die Eclipse Umgebung eingebunden werden konnte. Die Eclipse Umgebung wurde als Entwicklungsumgebung für den Generator und als Laufzeitumgebung für beide eingesetzt. Der entstandene Generator ist in der Lage aus einer VL-Spezifikation einen funktionsfähigen Editor vollständig zu generieren. Von der VL-Spezifikaiton wird erwartet, dass sie in sich korrekt ist. Ein Vorschalten einer Überprüfung wurde nicht in Betracht gezogen, da diese später vom TIGER -Designer kommt, der nur korrekte VL-Spezifikationen erstellen kann. 6.2 Ausblick Der entstandene Generator stellt nur eine erste Ausbaustufe dar und muss somit noch erweitert werden. Dies betrifft folgende Punkte: 57

70 58 Zusammenfassung und Ausblick Erstellung von Figuren Der Generator ist in der Lage Figuren zu erstellen, die dem Muster aus Abbildung 4.8 entsprechen. Andere Anordnungen können noch nicht berücksichtig werden. Um dies zu ändern, muss die Klasse LayoutConstraint aus dem Alphabet angepasst werden. Die Ausrichtungsarten müssten sich näher an den im Editor verwendeten Layoutmanagern orientieren. Im Moment entsprechen die vorhandenen Konstanten im BorderLayout in Draw2D, das jedoch noch einige andere LayoutManager unterstützt. Um eine optimale Anordnung der Figuren zu erhalten, kann es erforderlich sein von vorhandenen LayoutManager-Klassen abzuleiten und neue zu bilden. Im Designer wurden die Figuren bereits entworfen, die der Generator auch so umsetzen muss. Daher müssen die vom Designer zur Anordnung der Figuren benötigten Layoutmanager auch vom Generator benutzt werden können. Aus diesem Grund muss die Klasse LayoutConstraint so angepasst werden, das dies bewerkstelligt werden kann Anpassungen des Regelanalysierers Der Regelanalysierer ist in der Lage Einfüge-, Bearbeitungs-, Lösch- und Verschieberegeln zu analysieren. Darüberhinaus kann er auch andere Regeln analysieren, wobei noch Fehler bei der Regelanwendung im Editor auftreten können. Dies betrifft vor allem das Mapping zwischen dem selektiertem Objekt im Editor und dem Knoten auf der linken Regelseite.

71 Kapitel 7 Benutzerhandbuch Auf der beiliegenden CD-ROM befinden sich das TIGER Plugin im zip-format, die Eclipse Umgebung in der Version 3.1M4, das GEF Plugin in der Version und EMF Plugin in der Version Installation Als Laufzeitumgebung für den Generator und den Editor wird die Eclipse Plattform verwendet und somit auch Java benutzt. Zunächst muss die Eclipse Plattform installiert werden. Danach müssen die EMF und GEF Plugins installiert werden. Vom EMF Plugin wird der JetEmitter verwendet, der zur Generierung der Editordateien benötigt wird. Das GEF Plugin wird für den generierten Editor benötigt. Es gibt nun zwei Möglichkeiten, das TIGER Projekt, das den Generator, die TIGER VL-Spezifikation und Beispieldateien für Aktivitätendiagramme und Petrinetze enthält, zu installieren. Die erste Möglichkeit besteht nun darin das Projekt über den Eclipse internen Installationsmechanismus zu installieren. Dazu wird der Menüeintrag Menu > Software Updates > Find and Install... ausgewählt. Danach muss die Option Search for new features to install ausgewählt und der Next Button gedrückt werden. In der folgenden Wizard Seite muss nun eine neue Remote Site festgelegt werden. Der Name ist dabei optional aber es muss folgende URL gesetzt 59

72 60 Benutzerhandbuch werden: Wenn dies getan ist, muss der neu erstellte Eintrag ausgewählt und Next gedrückt werden. Dabei wird überprüft, ob die URL erreichbar ist. Auf der nächsten Seite erscheint ein Eintrag TIGER-Environment, der ausgewählt werden muss. Danach muss noch eine Lizenzvereinbarung bestätigt werden und dann ist alles für die Installation getan. Eine andere Möglichkeit besteht darin, das Projekt aus dem CVS von der TIGER Homepage auszuchecken und als Projekt in die Eclipse Umgebung zu importieren. Um das Projekt zu benutzen, muss dann natürlich eine neue Eclipse Runtime-Workbench gestartet werden. In dem ausgecheckten Projekt befinden sich dann die VL-Spezifikationen für Petrinetze und Aktivitätendiagramme und die VL-Spezifikation als Java Source Code, mit sie erstellt wurden. 7.2 Schritte zur Generierung eines Editors In diesem Abschnitt wird kurz die einzelnen Schritte zur Generierung eines Editors vorgestellt, die in den nachfolgenden Unterkapiteln noch näher ausgeführ werden. Die Erstellung des Alphabets erfolgt später über den TIGER Designer, der zum Zeitpunkt der Entstehung dieser Diplomarbeit noch nicht vollständig implementiert war. Die Grammatikregeln müssen ebenfalls noch auf andere Weise erzeugt werden, nämlich mit dem AGG Tool. Dies soll später ebenfalls vom Designer übernommen werden. 1. Erstellung einer VL-Spezifikation: (a) Alphabet für die visuelle Sprache erstellen (b) Regeln für die Grammatik mit Hilfe AGG erstellen 2. Starten des TIGER Generators über den Wizard (a) Definition eines Namens für das Editor Projekt (b) Angabe des Ortes der Alphabet-Spezifikation (c) Definition einer Dateiendung zum Starten des Editors

73 7.3 Allgemeines zur VL-Spezifikation Start einer neuen Runtime-Workbench zum Testen des generierten Editors 4. Eine neue Datei über den Wizard anlegen (enthält den Startgraphen der Grammatik) 5. Durch doppelklicken auf die Datei den Editor starten 7.3 Allgemeines zur VL-Spezifikation In diesem Abschnitt wird ein Überblick über das TIGER Alphabet gegeben und welche Möglichkeiten es für die Definition eines visuellen Alphabets bietet Überblick über das TIGER Alphabet In TIGER gibt es eine Klasse VLSpec, die das Alphabet und die eine Syntaxgrammatik, eine Simulationsgrammatik und einen Typgraphen für die Syntaxgrammatik verwaltet. Darüberhinaus verfügt sie über Methoden zum Laden und Speichern von VL-Spezifikationen. Das Alphabet besteht aus einer Klasse Alphabet, die alle Knoten - und Kantensymbole und Links enthält. Die Knoten - und Kantensymbole werden durch die Klassen NodeSymbolType und EdgeSymbolType repräsentiert, die das Interface SymbolType implementieren. Ein SymbolType kann mehere Attribute besitzen, die durch die Klasse AttributeType repräsentiert werden. Ein AttributeType hat dabei immer einen Namen und einen Datentyp. In der ersten Ausbaustufe gibt es die Restriktion, dass NodeSymbolTypes nur mit EdgeSymbolTypes über LinkTypes miteinander verbunden werden dürfen. Die LinkTypes sind stets gerichtet und besitzen dadurch einen eindeutigen Quell - und ZielSymbolType. Der QuellSymbolType ist in der ersten Ausbaustufe eben immer ein EdgeSymbolType. Die grafische Darstellung der NodeSymbolTypes wird durch die Klasse Shape- Figure realisiert, in der das Aussehen der Figur festgelegt wird. Mit dem Generator können folgende ShapeFigures gezeichnet werden: Rectangles, RoundedRectangles, Circles, Ellipses, Polygons. Für diese Figuren kann dann noch

74 62 Benutzerhandbuch eine Farbe für den Rahmen (bordercolor), eine Füllfarbe (fillcolor), eine Standardgröße (defaultsize) und eine maximale Größe für die Figur (maximumsize) fesgelegt werden. Für die maximale Größe wird zunächst die Standardgröße verwendet. Soll diese sich von der Standardgröße unterscheiden, muss sie explizit gesetzt werden. Für ein NodeSymbolType können mehrere ShapeFigures definiert werden. Der NodeSymbolType muss dann ein kind -Attribut haben, über das die verschiedenen ShapeFigures referenziert werden können. Die EdgeSymbolTypes werden durch die Klasse Connection repräsentiert. Eine Connection ist eine Linie, für die verschiedene Attribute gesetzt werden können. Dies sind einerseits die Linienstärke, die Linienart und die Linienfarbe. Für die Linienart gibt es bereits vordefinierte Konstanten wie Connection.PLAIN für durchgezogene, Connection.DOTTED für gepunkte und Connection.DASHED für gestrichelte Linien. AttributeTypes, die stets zu SymbolTypen gehören, können durch die Klasse TextFigure visualisiert werden. Dafür können folgende Attribute gesetzt werden: ein Figurenname, eine Schrift (Schriftart, Schriftstil, Schriftgröße), eine Schriftfarbe und ein Sichtbarkeitsattribut. LinkTypes können durch die Klasse LinkLayout ein konkretes Layout erhalten. Dies ist meist eine Pfeilspitze oder eine Raute. Im generierten Editor wird das Layout für einen LinkType an den Anfang oder das Ende einer Connection gezeichnet, was durch den LinkType bestimmt wird. Diese Klasse besitzt Attribute, mit denen die Rahmenfarbe oder die Füllfarbe festgelegt werden kann. Neben der Festlegung der einzelnen grafischen Darstellung können die einzelnen Elemente nun noch in Beziehung zueinander gesetzt werden. Dafür gibt es die beiden Klassen LayoutConstraint und ConnectionConstraint. Mit der ersteren können TextFigures und ShapeFigures zueinander und auch untereiander in Beziehung gesetzt werden. Dafür gibt es eine Reihe vordefinierter Konstanten: UNDEFINED, ABOVE, BELOW, CENTER, LEFT, RIGHT. Für die Ausrichtung von Connections und Figures gibt es die ConnectionConstraints AT SRC, AT TAR, AT CENTER.

75 7.4 Alphabetdefinition für Petrinetze Erstellung von Grammatikregeln Für die Durchführung von Editieroperationen müssen mindestens Einfüge-, Lösch-, Bearbeitungs- und Verschieberegeln definiert werden. Regelname müssen beim jetzigen Stand des Generators aus einem Schlüsselwort, das die Art der Regel bezeichnet und der Typ, der durch die Regeln manipuliert werden soll. Schlüsselwörter für Einfügeregeln sind: add, create, insert, für Löschregeln: delete, destroy, remove, für Bearbeitungsregel: edit, rename und für Verschieberegeln: move. Einfügeregeln, die einen NodeSymbolType erzeugen und deren linke Regelseite leer ist, erscheint in der Palette unter dem Eintrag Symbols. Wenn Einfügeregeln für EdgeSymbolTypes in der Palette erscheinen soll, müssen auf der linken Regelseite zwei Knoten zu finden sein, die durch den EdgeSymbolType verbunden werden sollen. 7.4 Alphabetdefinition für Petrinetze Im folgenden wird die Erzeugung des Alphabets durch die Instanziierung der einzelnen Alphabetklassen im Detail beschrieben. Bevor ein Alphabet definiert werden kann muss ersteinmal eine Instanz der Klasse VLSpec erzeugt werden, die das Alphabet und die Graphgrammatik enthält. Nachdem eine Alphabetinstanz erzeugt worden ist (siehe Abb. 7.1), fährt man Abbildung 7.1: Erstellung einer VLSpec und eines Alphabets mit der Erstellung der NodeSymbolTypes fort.

76 64 Benutzerhandbuch NodeSymbolTypes In unserem Alphabet für Petrinetze gibt es zwei NodeSymbolTypes: eine Stelle und eine Transition. Am Beispiel einer Stelle soll hier die Erstellung eines Node- SymbolTypes beispielhaft erklärt werden. Eine Stelle besteht dabei aus einem Kreis in dessen Mitte die Anzahl der Tokens und unterhalb der Name der Stelle steht. In Abbildung 7.2 ist die Erzeugung einer Stelle und der dazugehörigen Shape- Abbildung 7.2: Erstellung einer Stelle und deren Figur Figure gezeigt. Ein NodeSymbolType wird mit Hilfe der Methode createnode- SymbolType(String) erstellt. Als Parameter wird der Name des NodeSymbolType übergeben. Danach wird eine Figur (ShapeFigure) für diese Stelle erzeugt, indem dem Konstruktor der NodeSymbolType, zu dem die ShapeFigure gehört, übergeben wird. Danach können visuelle Eigenschaften wie Farbe, Größe und Art der Figur (vgl. Abb. 7.2) festgelegt werden AttributeTypes Wie eben erwähnt, hat eine Stelle zwei Attribute (einen Name und die Anzahl der Tokens), die im Alphabet durch die Klasse AttributeType und deren grafische Darstellung durch die Klasse TextFigure ausgedrückt werden. In Ab-

77 7.4 Alphabetdefinition für Petrinetze 65 Abbildung 7.3: Definition eines Attributes und dessen Defintion der grafischen Repräsentation bildung 7.3 ist die Definition eines Attributes für die Anzahl der Tokens zu sehen. Dazu muss die Methode createattributetype(string,string) an einem definierten NodeSymbolType, in unserem Beispiel place, aufgerufen werden. Der Methode müssen zwei Parameter übergeben werden: einen Datentyp (Integer, Float, String,...) und einen Namen für dieses Attribut. In unserem Beispiel sind das Integer und tokens. Die Visualisierung eines Attributs im Editor wird über dessen Figur (TextFigure) geregelt, die beim Erzeugen des Attributes standardmäßig leer ist und nun noch mit Werten gefüllt werden muss. Das sind ein Name, eine Schriftart, deren Schriftfarbe und die Sichtbarkeit definiert werden. Die Definition weiterer Attribute erfolgt analog. Im nächsten Abschnitt wird näher die Ausrichtung der TextFigures zu Shape- Figures mittels LayoutConstraints beschrieben. LayoutConstraints Abbildung 7.4: Anordnung einer Textfigur zur Figur des NodeSymbolTypes Nachdem ein AttributeType und ein NodeSymbolType definiert worden sind, muss noch die Ausrichtung der TextFigure zur ShapeFigure festgelegt werden

78 66 Benutzerhandbuch (siehe Abb. 7.4). Dies geschieht in unserem Alphabet über die Klasse Layout- Constraint, die bereits eine Aufzählung an möglichen Ausrichtungsmöglichkeiten beihaltet: INSIDE, LEFT, RIGHT, BOTTOM, ABOVE, UNDEFINED. Der Konstruktor der Klasse LayoutConstraint erwartet drei Parameter: 1. eine Text- oder ShapeFigure, die bezüglich einer anderen ShapeFigure ausgerichtet werden soll 2. die ShapeFigure, an der andere Figuren ausgerichtet werden sollen 3. die Art des LayoutConstraint Für das Beispiel in Abbildung 7.4 bedeutet dies, dass die tokenfigure sich innerhalb der placefigure befindet. Durch den Konstruktor wird auch die Leserichtung widergespiegelt: der erste Parameter befindet sich Wert des Layout- Constraints zum zweiten Parameter. Nachdem das LayoutConstraint festgelegt wurde, wird es an der Figur hinzugefügt, die als erster Parameter im Konstruktor der Klasse LayoutConstraint auftaucht EdgeSymbolTypes Nachdem NodeSymbolTypes für das Alphabet erstellt worden sind, kann mit der Erzeugen von EdgeSymbolTypes fortgefahren werden, die dann über LinkTypes (vgl. Kap ) mit den NodeSymbolTypes verbunden werden. Abbildung 7.5 zeigt die Erstellung eines EdgeSymbolTypes und dessen grafische Darstellung (Connection). Sie wird durch Aufruf der Methode createedgesymboltype(string) erstellt, wobei ein Name als Parameter erwartet wird. Für die Connection (die grafische Repräsentation) müssen dann noch ein Name, die Linienfarbe, Linienstärke und die Linienart definiert werden. Die Referenz auf die Connection wird über die Methode getconnection() eines EdgeSymbolTypes geholt. Für die Linienart gibt es bereits vordefinierte Konstanten: glatt (Connection.PLAIN), gestrichelt (Connection.DASHED) und gepunktet (Connection.DOTTED).

79 7.4 Alphabetdefinition für Petrinetze 67 Abbildung 7.5: Erstellung eines EdgeSymbolTypes und dessen Erstellung einer grafischen Darstellung Für EdgeSymbolTypes können ebenfalls AttributeTypes definiert werden, deren TextFigures dann mit Hilfe von ConnectionConstraints an der Connection ausgerichtet werden müssen. Die Erstellung von AttributeTypes erfolgt analog zu den NodeSymbolTypes wie in Kapitel beschrieben. In Abbildung Abbildung 7.6: Definition eines ConnectionConstraints 7.6 ist die Definition eines ConnectionConstraint zwischen einer TextFigure des AttributeTypes arcptinscrfigure und einer Connection arcptconnection zu sehen. Der Konstruktor hat den gleichen Aufbau und Intention wie die LayoutConstraints, jedoch muss das ConnectionConstraint anders als bei den LayoutConstraints an die Connection angehangen werden LinkTypes In unserem Alphabet dienen LinkTypes dazu, NodeSymbolTypes und Edge- SymbolTypes zumindest in der ersten Ausbaustufen miteinander zu verbinden. Später können auch zwei NodeSymbolTypes über einen LinkType miteinander

80 68 Benutzerhandbuch verbunden werden. Im Petrinetzbeispiel soll eine Verbindung zwischen einer Stelle und einer Tran- Abbildung 7.7: Erstellung von LinkTypes und deren Layout sition eingefügt werden. Konkret heißt dies, dass die NodeSymbolTypes Place und Transition mit einem EdgeSymbolType ArcPT verbunden werden. Um die NodeSymbolTypes mit dem EdgeSymbolType zu verbinden, werden zwei Link- Types arcptsource, arcpttarget erstellt, die mit der Methode createlinktype(symboltype,symboltype) aus dem Alphabet erzeugt werden. Der erste SymbolType ist der EdgeSymbolType und das zweite der NodeSymbolType. Für die LinkTypes kann noch ein LinkLayout festgelegt werden. Für arcpttarget wird eine Spitze definiert (siehe Abb. 7.7). Ein LinkLayout kann eine Pfeilspitze oder eine Raute sein. Dazu werden die Klassen Polyline - oder PolygonDecoration aus dem Draw2D Paket verwendet Speichern des Alphabets Für die Speicherung des Alphabets gibt es die Methode save(filename:string) aufzurufen, die die aktuelle VL-Spezifikation im GTXL -Format abespeichert. Diese Methode befindet sich in der Klasse VLSpec. In der jetzigen Ausbaustufe werden die Graphgrammatik und das Alphabet noch getrennt abgespeichert.

81 7.5 Erstellung der Grammatikregeln für Petrinetze 69 Die Graphgrammatik wird im AGG eigenen Format als *.ggx Datei abgespeichert. Damit dies auch funktioniert ist es wichtig, dass sich die Dateien gxl.dtd und gtxl.dtd im gleichen Verzeichnis befinden, in dem sich auch die *.gtxl Datei befindet. Ein komplette Alphabetspezifikation für Petrinetze (PetriNetVLSpec.gtxl) ist im TIGER Projekt zu finden, wenn es aus dem CVS ausgecheckt wurde, ansonsten im Plugin TIGER Examples. Dort befinden sich auch die beiden *.dtd Dateien. 7.5 Erstellung der Grammatikregeln für Petrinetze Beim Abspeichern des Alphabets werden gleichzeitig eine Graphgrammatikdatei (Endung.ggx) erstellt. Diese Datei kann in AGG [AGG] geladen werden. In der GUI sind im Bereich der NodeTypes die im Alphabet definierten Node - und EdgeSymbolTypes und im Bereich der EdgeTypes die im Alphabet definierten LinkTypes zu finden (siehe Abb. 7.8). Für die Handhabung der AGG-Umgebung sei auf die Dokumentation auf der Abbildung 7.8: Generierte GraphGrammatik in AGG AGG Website [AGG] verwiesen. Das weitere Vorgehen zur Definition von Regeln besteht zunchst in der Definition eines Typgraphen. Für alle NodeSym-

82 70 Benutzerhandbuch boltypes, die später auf der Editorfläche bewegt werden sollen, müssen zu den bestehenden Attributen noch Positionsattribute (x,y) vom Typ int definiert werden. Dies ist notwendig damit die Position jedes NodeSymbolTypes nach dem Speichern erhalten bleiben. 7.6 Start des Generators Bevor der Generator gestartet werden kann, muss sichergestellt werden, dass sich die Graphgrammatik, gtxl.dtd, gxl.dtd und die Alphabetspezifikation in einem Verzeichnis befinden. Danach muss der New-Wizard über New > Other > TIGER-Editor Generator Abbildung 7.9: Wizard zum Start des Generators aufgerufen werden, in dem dann der Eintrag TIGER Editor Generator auszuwählen ist. Darauffolgend ist der in Abb. 7.9 zu sehen, in dem ein Projektname, der Ort der Alphabetspezifikation und eine eigene Dateiendung angegeben

83 7.7 Start des Editors 71 werden müssen. Durch Drücken auf den Finish Button wird der Generierungsprozess gestartet. 7.7 Start des Editors Um das erzeugte Plugin zu testen, muss eine neue Eclipse-Runtime-Workbench gestartet werden. Bevor der Editor gestartet werden kann, muss ersteinmal eine Datei erzeugt werden, mit der der Editor gestartet werden kann. Dies geschieht über einen Wizard (siehe Abb. 7.10), der mit New > Other > Tiger Editor Creation Wizard. Beim Aufklappen dieses Wizards erscheint der Name des Editor Plugins und die Bezeichnung Diagram. Danach kann ein bereits bestehendes Abbildung 7.10: Wizard zum Erzeugen einer Datei zum Starten des Editors leeres Projekt ausgewählt werden oder ein Name für eine neues leeres Projekt angegeben werden. Dieses wird dann durch diesen Wizard erzeugt. Danach muss eine leeres Projekt angegeben werden. Dies kann ein bereits bestehendes sein oder ein neues, das dann erst durch diesen Wizard generiert wird. Desweiteren wird ein Vorschlag für einen Dateinamen gegeben mit der selbstdefinierten Endung aus dem Generator-Wizard.