Post on 19-Oct-2020
transcript
Konzeption und Implementierung eines
Generators
fur visuelle Sprachumgebungen in Eclipse
basierend auf Graphtransformationen
Stefan Hansgen
Diplomarbeit
an der Fakultat fur Elektrotechnik und Informatik
der Technischen Universitat Berlin
Gutachter: Prof. Dr. H. Ehrig und Dr. G. Taentzer
10. Juni 2005
Zusammenfassung
In dieser Diplomarbeit wird ein Generator fur visuelle Umgebungen konzipiert
und implementiert. Editieroperationen entsprechen einem Graphtransformati-
onschritt.
Auf der beiliegenden CD-ROM befindet sich die Eclipse Umgebung zum
Starten des Generators und des Editors, das aktuelle Generator-Plugin mit Bei-
spielalphabeten fur Petrinetze, Aktivitatendiagramme und Automaten.
Die selbstandige und eigenhandige Anfertigung
dieser Diplomarbeit versichere ich an Eides statt.
Berlin, den 10. Juni 2005
Unterschrift
Danksagung
Mein Dank gilt den Betreuern Frau Dr.-Ing. Gabriele Taentzer und Herr Dipl.-
Inf. Karsten Ehrig fur die konstruktive Unterstutzung bei der Erstellung dieser
Arbeit.
Daruberhinaus mochte ich mich bei Frau Dipl.-Inf. (FH) Olga Runge fur
die vielen zahlreichen Hinweise bei der Anbindung des AGG Systems an den
generierten Editor.
Meiner Familie mochte ich fur die Unterstutzung und die Geduld wahrend
der Erstellung dieser Arbeit danken.
Inhaltsverzeichnis
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Aufbau des Dokumentes . . . . . . . . . . . . . . . . . . . . . . 2
2 Grundlagen 3
2.1 Visuelle Sprache . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 TIGER Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 Aufbau einer VL-Spezifikation in TIGER . . . . . . . . 7
2.3.2 GTXL . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 AGG als Graphtransformationsmaschine . . . . . . . . . 10
2.4 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 GEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2 EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.3 JET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.4 GMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Anforderungen 19
3.1 Ziel der Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . 19
i
ii INHALTSVERZEICHNIS
3.2 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . 19
3.2.1 Anforderung an den Generator . . . . . . . . . . . . . . 20
3.2.2 Anforderung an den generierten Editor . . . . . . . . . . 20
3.3 Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . 22
4 Entwurf und Implementierung 23
4.1 Paketstruktur des Generators . . . . . . . . . . . . . . . . . . . 23
4.2 Der Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Der Generierungsprozess fur die Editordateien . . . . . . . . . . 27
4.3.1 Generierung mittels JET uber dem JetGateway . . . . . 28
4.3.2 Generierung von einfachen Dateien . . . . . . . . . . . . 29
4.3.3 Generierung der Controller und der Dialoge . . . . . . . 29
4.3.4 Generierung von Node / Edge Dateien . . . . . . . . . . 30
4.3.5 Generierung der Figuren Klassen . . . . . . . . . . . . . 30
4.4 Datenstruktur zur Kapselung des Alphabets . . . . . . . . . . . 31
4.4.1 Figuren nach Draw2D . . . . . . . . . . . . . . . . . . 33
4.5 Der Regelanalysierer . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5.1 Struktur des Regelanalysierers . . . . . . . . . . . . . . . 39
4.5.2 Analyse der Regeln . . . . . . . . . . . . . . . . . . . . . 40
4.6 Der generierte Editor . . . . . . . . . . . . . . . . . . . . . . . . 42
4.6.1 Paketstruktur . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6.2 Aufbau des Editors . . . . . . . . . . . . . . . . . . . . . 44
4.6.3 Interner Aufbau des Editors . . . . . . . . . . . . . . . . 44
4.6.4 Anbindung von AGG an den Editor . . . . . . . . . . . 45
4.7 Benutzte Technologien . . . . . . . . . . . . . . . . . . . . . . . 48
5 TestEditoren 49
INHALTSVERZEICHNIS iii
5.1 Editor fur Petrinetze . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.1 Alphabet . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.2 Grammatik . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1.3 Editoraufbau . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2 Editor fur einfache Aktivitatendiagramme . . . . . . . . . . . . 53
5.2.1 VL-Spezifikation . . . . . . . . . . . . . . . . . . . . . . 54
5.3 Editor fur Automaten . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.1 VL-Spezifikation . . . . . . . . . . . . . . . . . . . . . . 56
5.3.2 Anbindung einer externen Schnittstelle . . . . . . . . . . 56
6 Zusammenfassung und Ausblick 57
6.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.1 Erstellung von Figuren . . . . . . . . . . . . . . . . . . . 58
6.2.2 Anpassungen des Regelanalysierers . . . . . . . . . . . . 58
7 Benutzerhandbuch 59
7.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.2 Schritte zur Generierung eines Editors . . . . . . . . . . . . . . 60
7.3 Allgemeines zur VL-Spezifikation . . . . . . . . . . . . . . . . . 61
7.3.1 Uberblick uber das TIGER Alphabet . . . . . . . . . . 61
7.3.2 Erstellung von Grammatikregeln . . . . . . . . . . . . . 63
7.4 Alphabetdefinition fur Petrinetze . . . . . . . . . . . . . . . . . 63
7.4.1 NodeSymbolTypes . . . . . . . . . . . . . . . . . . . . . 64
7.4.2 AttributeTypes . . . . . . . . . . . . . . . . . . . . . . . 64
7.4.3 EdgeSymbolTypes . . . . . . . . . . . . . . . . . . . . . 66
7.4.4 LinkTypes . . . . . . . . . . . . . . . . . . . . . . . . . . 67
iv INHALTSVERZEICHNIS
7.4.5 Speichern des Alphabets . . . . . . . . . . . . . . . . . . 68
7.5 Erstellung der Grammatikregeln fur Petrinetze . . . . . . . . . . 69
7.6 Start des Generators . . . . . . . . . . . . . . . . . . . . . . . . 70
7.7 Start des Editors . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.7.1 Aufbau des Editors . . . . . . . . . . . . . . . . . . . . . 72
Literaturverzeichnis 73
A Alphabet fur Petrinetze 77
Kapitel 1
Einleitung
1.1 Motivation
Einfach gesagt ist ein Generator ein Programm, das Code fur ein anderes er-
zeugt. Code-Generatoren spielen heutzutage eine immer großere Rolle in der
Informatik, da sie dabei helfen sich wiederkehrende Codierungsaufgabe zu er-
leichtern. Daruberhinaus bieten Code-Generatoren folgende Vorteile [Her03]:
• Produktivitat: viele Zeilen Code konnen innerhalb von wenigen Sekun-
den kreiert werden
• Qualitat: generierter Code hat eine gleichformige Qualitat uber dem ge-
samten System
• Konsistenz: Konsistenz bezuglich Signaturen und Variablennamen ist
stets gegeben.
• Abstraktion: Einige Generator nehmen ein abstraktes Modell als Input
fur das zu generierende System. Dadurch wird das System portierbar und
kann in mehreren Sprachen erzeugt werden.
1
2 Einleitung
1.2 Aufbau des Dokumentes
Die Diplomarbeit ist in folgende Abschnitte gegliedert: Kapitel 2 fuhrt die
Grundlagen zum Verstandnis des Generators fur visuelle Sprachumgebumgen
ein. In Kapitel 3 werden die Anforderung an den Generator und dessen Kom-
ponenten erlautert, die in Kapitel 4 entworfen werden. In Kapitel 5 wird
der Generator anhand von drei Sprachen getestet, das sind Petrinetze, einfa-
che Aktivitatendiagramme und Automaten. In Kapitel 6 gibt eine Zusam-
menfassung und einen Ausblick bezuglich 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.
Kapitel 2
Grundlagen
In diesem Kapitel sollen die Grundlagen, welche zum Verstandnis der Funktions-
weise des Generators und des Editors notwendig sind, naher erlautert werden.
2.1 Visuelle Sprache
Eine visuelle Sprache ist eine Sprache uber einem visuellen Alphabet, das aus
Symbolen und Verknupfungen zwischen diesen besteht. Ein visuelles Alphabet
besteht aus einer abstrakten, einer konkreten Syntax, die sich aus dem abstrak-
ten Teil und dem visuellen Teil zusammensetzt, und einer Grammatik. Durch die
Grammatik kann die Anzahl an moglichen Diagrammen eingeschrankt werden.
Neben diesen konstruktiven Ansatz, gibt es noch den der Metamodellierung.
Visuelle Sprachen und visuelle Umgebungen gewinnen heutzutage in der Soft-
wareentwicklung immer mehr an Bedeutung. So werden Modellierungssprachen
fur die Analyse und das Design von Softwaresystemen eingesetzt. Eine Model-
lierungssprachen, die sich in den letzten Jahren durchgesetzt hat, ist die UML.
Sie bietet diverse Moglichkeiten zur Modellierung der Analyse und des Designs.
Weitere visuelle Sprachen sind Petrinetze, VOCL und Stagecast.
Daruberhinaus gibt es Generatoren fur visuelle Sprachen, die aus einer gebenen
Spezifikation ein Werkzeug erzeugen, mit dem ein visuelles Modell der Spra-
che, also ein Diagramm, erstellt werden konnen. Dazu zahlen DiaGen[Dia],
ATOM3 und GenGED. Die erstellten Werkzeuge sind in der Regel Editoren,
3
4 Grundlagen
die syntaxgesteuert bzw. freihandig arbeiten. Der Vorteil von syntaxgesteuerten
Editoren liegt darin, dass das erzeugte Diagramm immer der visuelle Sprache
entspricht. Eine Parsierung des Diagramms entfallt dadurch, jedoch mussen die
Editierregeln bereits im Vorhinein festgelegt werden. Ein Nachteil besteht nun
darin das der Benutzer beim Layout sehr eingeschrankt 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 un-
terstutzen.
Eine Methode dafur 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 Be-
standteile des Systems erzeugt werden.
Dabei wird zwischen technologieunabhangiger, die von einer konkreter Softwa-
re - und Hardwaretechnologie abstrahiert, und technologieabhangiger Modellie-
rung unterschieden.
Die fachliche Spezifikation wird in einem PIM (Platform Independent Model)
definiert, das eine formale an die Domane angepasste Modellierungssprache ver-
wendet. Als Modellierungssprache kann eine mit einem UML Profil entwickel-
te sein. Dieses Modell ist somit unabhangig von irgendeiner Zielplattform wie
CORBA oder J2EE sein. Dabei wird nichts uber 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-
2.3 TIGER Projekt 5
handelt werden und mittels Transformation ein weiteres PSM generiert werden,
das naher an der Plattform ist als das vorherige PSM.
2.2.1 UML
Die UML (Unified Modelling Language) ist eine Sprache und Notation zur Spe-
zifikation, Konstruktion, Visualisierung und Dokumentation von Modellen fur
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 Anwendungsberei-
ches, des organisatorischen Umfeldes usw. berucksichtigt werden mussten. Sie
soll namlich eine Grundlage fur verschiedene Vorgehensweise sein.
Der aktuelle Standard ist die UML 2.0, die eine grundsatzliche Uberarbei-
tung erfuhr, was unter anderem die Spezifikation und das Metamodell betrifft.
Daruberhinaus wurde sie unterteilt:
• Infrastructure (Kern, Profile, Stereotypen)
• Superstructure (statische und dynamische Modellelemente)
• OCL (Einschrankungen fur definierte Modelle)
• Diagrammaustauschformat (UML-Austauschformat fur Diagram-
maustausch zwischen verschiedenen Tools)
Um die UML fur die eigenen Bedurfnisse anzupassenn, gibt es die sogenannten
UML Profile, mit denen Modellelemente aus dem UML-Metamodell verwendet
und erweitert werden konnen.
2.3 TIGER Projekt
Das Ziel dieser Diplomarbeit, die Entwicklung eines Generators fur visuel-
le Sprachumgebungen, ist ein Bestandteil des TIGER [EEHT04] Projektes
6 Grundlagen
(Transformation-based generation of modeling environments). Die Zielstellung
dieses Projektes liegt in der Entwicklung einer Toolumgebung, welche aus ei-
nem Designer und einem Generator besteht, welcher dann visulle Editoren, Si-
mulatoren, Views zur Darstellung von Analyseergebenisse oder ein Tool zur
Durchfuhrung einer Modelltransformation erzeugen kann. Dabei sollen die Vor-
teile von AGG mit der der Eclipse Technologie kombiniert werden. In
Abbildung 2.1: TIGER architecture
TIGER wird AGG wird als Graphtransformationmaschine fur getypte, at-
tributierte Graphen verwendet, mit der Graphbedingungen gepruft und Graph-
grammatiken analysiert werden konnen. Diese Analysetechniken beinhalten so-
mit syntaktische und semantische Uberprufungen.
Fur die Generierung von visuellen Modellierungsumgebungen wird GEF ver-
wendet, das in Kapitel 2.4.1 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 Modellierungs-
umgebungen erstellt werden. Das sind der Editor, mit dem ein Modell editiert
werden kann, ein Simulator, eine Analyse-Komponente und eine Modelltransfor-
mationskomponente. Fur diese Komponenten werden visuelle Editoren / Viewer
benotigt. Fur 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. Fur de-
ren Generierung wird ein VL-Alphabet und eine Syntaxgrammatik verwendet.
2.3 TIGER Projekt 7
Spater sollen weitere Grammatiken fur Simulation und Parsierung erstellt wer-
den. Zunachst beschranken wir uns auf graphartige Sprachen wie beispielsweise
Petrinetze, Automaten.
Im folgenden wird die VL-Spezifikation naher vorgestellt, die in TIGER be-
nutzt wird:
2.3.1 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 ent-
spricht.
TIGER-Alphabet
Das Alphabet (siehe Abb. 2.2) besteht aus SymbolTypes und LinkTypes. Dabei
konnen NodeSymbolTypes durch EdgeSymbolTypes uber LinkTypes miteinander
verbunden werden. Diese Beschrankung besteht aber nur fur die erste Ausbau-
stufe.
SymbolTypes, LinkTypes und AttributeTypes bilden die abstrakte Syntax des Al-
phabets und haben direkte Entsprechungen in der AGGEngine.GraGra. Dabei
werden SymbolTypes auf Nodes, LinkTypes auf Arcs abgebildet. AttributeTypes
sind Attribute von Nodes.
SymbolTypes konnen als NodeSymbolTypes (Knoten) und EdgeSymbolTypes
(Kanten) auftreten. Das konkrete Layout fur ein NodeSymbolType ist definiert
durch die Klasse ShapeFigure, deren Attribute (Farbe, Große, Art der Figur
etc.) das Aussehen der Figur festlegen. Hierbei ist es auch moglich, das ein
Knotensymbol mehrere ShapeFigures hat, z.B. kann das NodeSymbolType Ak-
tivitat durch je eine der vier moglichen visuellen Darstellungen (Startsymbol,
Endsymbol, Entscheidung oder einfache Aktivitat) reprasentiert werden. Die
Darstellung muss dann uber ein ’kind’ Attribut gesteuert werden.
AttributeTypes konnen durch Textfigures visualisiert werden. Sowohl Text-
figure als auch ShapeFigure implementieren das Interface Figure und konnen
somit uber Layoutconstraint in Beziehung zueinander gesetzt werden. Layout-
8 Grundlagen
Abbildung 2.2: Das TIGER Alphabet
Constraints konnen INSIDE, BELOW, ABOVE, LEFT, RIGHT sein.
Die EdgeSymbolTypes, deren konkretes Layout durch die Klasse Connection
implementiert wird, verbinden NodeSymbolTypes uber LinkTypes miteinander.
Connections haben Attribute fur Linienfarbe, -starke usw. und werden uber
ConnectionConstraints mit Figures verbunden.
Die LinkTypes konnen ebenfalls ein konkretes Layout haben, das eine
org.eclipse.draw2d.RotatableDecoration sein muss, d.h. entweder eine Pfeilspitze
oder auch ein Polygon.
Fur die Berechnung des Layouts werden die in GEF enthaltenden Graph-
layouter verwendet, so dass auf die Anbindung von Constraintsolver verzichtet
werden kann.
2.3 TIGER Projekt 9
Graphgrammatik
Graphgrammatiken bestehen in der Regel aus einem Startgraphen und einer
Menge von Graphtransformationsregeln. In TIGER wird das algebraische Gra-
phmodell fur getypte attributierte Graphen und derer Transformation verwen-
det.
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 2.3.3 zu finden.
Fur den zu generierenden Editor mussen Einfuge-, Losch-, Bearbeitungs- und
Verschieberegeln definiert werden.
Die Knoten in der Graphgrammatik, die ein NodeSymbolType aus dem Alpha-
bet reprasentierten, mussen 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 zusatzliche Attri-
bute definiert werden konnen. Gleiches gilt auch fur Knoten, die dann im Editor
jedoch nicht dargestellt werden.
2.3.2 GTXL
GTXL ist ein Austauschformat fur Graphtransformationssysteme[Lam04] und
wurde an der TU-Berlin entwickelt. Die Idee war, Tools fur Graphtransformati-
onssysteme ein Austauschformat zu bieten. Es basiert auf dem weit verbreiteten
Standard XML [W3C99] und integriert GXL, um den Teil, der die Graphen be-
handelt, zu beschreiben.
Im TIGER Projekt dient GTXL als Austauschformat zwischen dem Desi-
gner 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.
10 Grundlagen
2.3.3 AGG als Graphtransformationsmaschine
AGG [AGG] (Attributiertes Graph Grammatiksystem) ist ein Interpreter fur
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 eigenstandige Graphtransformationsmaschine in
Java Anwendungen eingebunden werden.
In AGG werden komplexe Datenstrukturen als Graphen modelliert, welche
uber einen Typgraphen getypt sein konnen. Sie konnen durch Java Objekte
oder andere Typen attributiert werden. Basistypen in AGG entsprechen den
primitiven Datentypen aus dem Java SDK. Daruberhinaus konnen auch selbst-
definiert Klassen eingebunden werden. Das Systemverhalten wird durch Gra-
phregeln spezifiziert, welche durch NACs (Negative Application Conditions)
eingschrankt werden konnen. Durch eine Regelanwendung wird der Graph
verandert.
Die Anwendung von Regeln folgt dem Single-Pushout-Ansatz fur Graphtrans-
formation. Algebraische Spezifikationen und Terme werden in AGG durch Java
Klassen ausgedruckt. Im nachsten Abschnitt sollen die Sprachkonstrukte von
AGG naher 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. La-
bels sind dabei Typen: ein Objekt o ist dann vom Typ l, der aus der Labelmenge
stammt. In AGG konnen zwischen zwei Knoten mehrere Arcs vom gleichen Typ
sein. Das ist ein Unterschied vom allgemeinen Verstandnis von Graphgramma-
tiken, da dort ein Arc eine Relation zwischen zwei Knoten beschreibt.
Graphobjekten konnen noch Attribute zugewiesen werden, die aus einem Na-
men, einen Typ und einem zugewiesen Wert besteht. Pro Graphobjekt konnen
mehrere Attribute deklariert werden, die auch vom gleichen Typ sein konnen. In
2.4 Eclipse 11
einem Graphen haben alle Knoten eines Typs die gleiche Attributdeklaration.
Die Werte der Attribute konnen dann naturlich unterschiedlich sein.
Eine Aktion kann als ein Ubergang von einem Zustand in einen nachsten be-
trachtet werden. In AGG werden Zustande als ein Paar von Graphen beschrie-
ben. Es gibt einen Vor - und eine Nachzustand. Erst wenn alle Vorbedingungen
in einem konkreten Graphen erfullt sind, kann ein Zustandswechsel vollzogen
werden. Darunter fallt 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
gehoren, im Graphen statt.
2.4 Eclipse
Als Entwicklungs- und Ausfuhrungsumgebung fur den Generator fur visuel-
le Sprachumgebungen wird die Eclipse Plattform [Ecl05] eingesetzt. Eclip-
se ist eine universelle Tool Platform, die fur viele Anwendungsmoglichkeiten
verwendet werden kann. Sie kann als integrierte Entwicklungsumgebung, als
Laufzeitumgebung fur eigene Applikationen eingesetzt werden. Der Hauptvor-
teil liegt vor allem darin, dass sie auf verschiedenen Plattformen eingesetzt wer-
den kann. Die Plattform kann durch die Entwicklung eigener Plugins erweitert
oder erganzt 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 fur sie entwickelt
und verbreitet werden kann. In der Regel reicht fur eine kleine Anwendung
ein einzelnes Plugin aus, wahrenddessen ein komplexes Tool sich aus mehreren
Plugins zusammensetzt. Beispielsweise setzt sich das TIGER Projekt auch aus
mehreren Plugins zusammen: ein Plugin fur den Generator und das Alphabet,
eines fur den Designer, eines fur die Beispielalphabete und Graphgrammatiken
und eines fur die Generatordokumentation. Hierbei wird deutlich, dass ein Plu-
gin nicht nur Programmcode enthalten muss, sondern auch beliebige Dateien
haben kann.
12 Grundlagen
Jedes Plugin besitzt eine Manifestdatei, in der die Kopplung zu anderen Plug-
Abbildung 2.3: Eclipse Architektur
ins geregelt wird. Uber die Erweiterung (Extensions) kann ein selbstentwickeltes
Plugin ein anderes erweitern und an eine bestimmte Stelle in Eclipse eingebun-
den werden. Durch die Plattform werden standardmaßig diverse Erweiterungen
zur Verfugung gestellt. Dabei gibt es keine Begrenzung an Erweiterungen, an
die ein Plugin angehangen werden kann. Beispielsweise kann ein Plugin als Wi-
zard oder als Editor in der Eclipse Umgebung integriert werden. Ein selbst-
entwickeltes Plugin kann nicht nur solche Erweiterungen nutzen, sondern auch
welche zur Verfugung stellen, die dann von anderen Plugins wieder erweitert
werden konnen. Das geschieht durch sogenannte Erweiterungspunkte (Extensi-
on Points), von denen ein Plugin eine beliebige Anzahl zur Verfugung stellen
kann. Dieser Erweiterungspunkt muss dann auch eine entsprechende API besit-
zen.
Standardmaßig bietet die Eclipse Plattform Plugins fur eine Java-
Entwicklungsumgebung, Resourcenverwaltung, Unterstutzung des CVS, Plugin-
Entwicklungswerkzeuge und ein ”Hilfe”-System.
Die Benutzerschnittstelle der Eclipse Plattform wird durch die Workbench
reprasentiert, die eine flexible, anpassbare Oberflache fur den Benutzer bietet.
Die Anordnung der verschiedenen Fenstern fur Editoren und Views erfolgt in
Perspectives. Fur die Darstellung der Workbench wird das SWT (Standard Wid-
2.4 Eclipse 13
get Toolkit) und JFace verwendet, das SWT benutzt und die Programmierung
von Benutzeroberflachen vereinfacht. Bei mit SWT entwickelten Programmen
wird das darunterliegende Window System berucksichtigt.
Fur eine detailierte Einfuhrung in die Eclipse Plattform sei an dieser Stelle
auf den ”Eclipse Platform Technical Overview” verwiesen [Ecl03].
Fur die Eclipse Plattform wurden bereits diverse Tools entwickelt, die im
Tools-Project vom Eclipseconsortium zusammengefaßt sind. Dies sind unter an-
derem GEF , EMF und JET als Teil von EMF , die im folgenden vorgestellt
werden.
2.4.1 GEF
GEF [GEF] (Graphical Editor Framework) ist ein Projekt des Eclipse Tool
Projektes mit dem auf einfache Weise grafische Editoren implementiert werden
konnen. Die Implementierung des Editors muss dabei auf einem schon vorhan-
denen Modell basieren. Dabei setzt GEF die Model-View-Controller Architek-
tur ein, die eine Trennung zwischen dem Modell und den sichtbaren Elementen
(View) des Editors vorsieht. Eine Anderung in der View zieht dann automatisch
eine Anderung im Modell nach sich und umgekehrt. Ein Modell in GEF ent-
spricht einem Metamodell in unserem Verstandnis. Die Kommunikation dieser
Anderungen wird durch den Controller gesteuert.
Das Framework besteht aus zwei verschiedenen Strukturen: zum einen werden
unter anderem die Klassen fur den Controller bereitgestellt und zum anderen
Klassen zum Zeichnen fur 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 zusammenhalt, was fur den Editor wichtig ist. Sie kann einen
oder mehrere GraphicalViewer beinhalten, einen CommandStack und ein ak-
tives Tool, das standardmaßig eine Selektionstool ist. Im Fall des generierten
Editors ist es genau einer. Der GraphicalViewer ist fur die Verwaltung aller
EditParts (Controller) verantwortlich. Mit den EditParts wird eine Verbindung
zwischen dem Modell und dem View hergestellt und es representiert etwas das
14 Grundlagen
sich im Modell befindet. Er erzeugt Figuren die im View sichtbar sind und pro-
pagiert Anderungen im Modell an den View. Die zweite wichtige Aufgabe der
EditParts liegt in der Durchfuhrung von grafische Editieroperation. Das bein-
haltet Anderung am Modell, die mit Commands durchgefuhrt werden, visuelles
Feedback zeigen und Delegation der eben beiden genannten Eigenschaften an
andere EditParts.
Die Ausfuhrung dieser Editieroperationen sind in EditParts nicht direkt im-
plementiert, sondern werden uber EditPolicies gehandhabt. EditPolicies bietet
bestimmte Rollen fur die EditParts. Rollen gibt es fur das Layoutmanagement
oder Erzeugen. Die Rolle wird definiert uber 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 EditPo-
licies delegiert.
Weitere Features von GEF sind die Tools, die den EditParts und EditPolicies
erlauben sich bei Operationen auf einer hoheren Ebene zu bewegen. Diese Tools
konnen in der Palette, die in der zu Anfang erwahnten EditDomain registriert
werden muss, erscheinen. Es gibt Tools zum Auswahlen, Markieren und Erzeu-
gen von Objekten. Beim Erzeugen kann noch zwischen einfachen Objekten und
Verbindungen unterschieden werden.
Mit den Klassen des Draw2D Pakets werden die Figuren eines GEF ba-
sierten 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 ubernehmen wurrde,
entfallt. Fur die Darstellung einfacher Figuren gibt es bereits fertige Klassen.
Mit Hilfe von LayoutManagern konnen diese Figuren zu komplexeren verbun-
den werden. Figuren konnen noch Ankerpunkte (AnchorPoints) besitzen, an
den dann Verbindungen andocken konnen.
2.4 Eclipse 15
2.4.2 EMF
An dieser Stelle soll ein kurzer Uberblick uber EMF gegeben werden, da fur
die Editorgenerierung JET verwendet wird, das Teil von EMF ist.
EMF ist ein Framework, mit dem ein Modell erstellt fur eigene Anwendungen
erstellt werden kann und das uber Codegenerierungseigenschaften verfugt. Dies
beihaltet die Generierung des Modellcodes bis zu einem einfachen Baumeditor,
mit dem das Modell getestet werden kann. Im generierten Quellcode ist stan-
dardmaßig ein Notification Service implementiert, den die eigene Anwendung
nutzen kann, um uber Modelanderungen 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 Fahigkeiten zur Serialisie-
rung (XMI-unterstutzt) und einen eigenen Benachrichtungsservice zum
Anzeigen von Modellanderungen bietet. Zur Codegenerierung wird hier
das JET Framework verwendet.
• EMF.Edit: Dieses Framework erweitert das Core-Framework um Eigen-
schaften zur Bearbeitung und Anzeige von in EMF definierten Modellen.
2.4.3 JET
Die Generierung der Java Dateien erfolgt mit Unterstutzung des JET Frame-
works, das mit seiner Struktur eine einfache Moglichkeit bietet, Code zu gene-
rieren. Dazu werden Templates verwendet, welche unter anderem die Struktur
des spater generierten Codes widerspiegeln. Im folgenden wird nur eine grobe
Ubersicht uber 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.
16 Grundlagen
Abbildung 2.4: Quellcodegenerierung mittels Templates
1. Translation : Zunachst werden die Templates in eine Art Zwischencode,
der normaler Java-Sourcecode ist, durch den JETEmitter ubersetzt und
danach kompiliert.
2. Generation : Aus dem kompilierten Source-Code wird nun durch den
JETEmitter der gewunschte Source-Code erzeugt und als String uberge-
ben. 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. Daruberhinaus ist
es moglich durch Platzhalter an beliebigen Stellen, eigenen Code einzufugen.
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 moglich einen Namen fur
das Paket anzugeben, in das das ubersetzte Template im .JETEmitters Projekt
gespeichert werden sollen. Ein Klassename fur 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, mussen dort angegeben werden, damit eine Kompilierung des Zwischen-
codes moglich ist.
2.4 Eclipse 17
Der Rumpf des Templates spiegelt das Aussehen des generierten Codes wider.
Dabei ist zu beachten, dass zwischen <%...%> beliebige Javaausdrucke stehen
konnen und mit <%= ...%>, das als Platzhalter dienen, der gewunschte Code
eingefugt werden kann. In Abb. 2.6 ist ein Template angegeben, mit dem eine
<%@jet 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 fur
die Felder in einer Liste ubergeben. Diese Liste wird in der lokalen Variable
myList gespeichert. In der Imports-Klausel werden nun die Klassen List und
Iterator fur die Kompilierung des Zwischencodes benotigt. Durch Iteration uber
diese Liste werden dann im zweiten Schritt (Generation)die Felder fur die Klasse
erzeugt.
2.4.4 GMF
GMF (Graphical Modeling Framework) ist der Vorschlag fur ein neues Pro-
jekt im Eclipse Technology-Project. Die beiden Projekte EMF und GEF ,
die auch Teil des Eclipse Technology-Projects sind, werden haufig zusammen
benutzt. Daraus entstand die Idee, diese Projekte zu kombinieren und deren
Starken zu nutzen.
GMF soll einen generativen Ansatz fur ein in EMF ausgedrucktes Domainmo-
dell bieten. Es soll dabei aus drei Komponenten bestehen:
18 Grundlagen
• einer Struktur zur Erstellung von Diagrammen (EMF basiert)
• einem Diagramm Generations Framework
• beispielhafte Modellierungswerkzeuge
Die Diagrammdefinition erfolgt uber ein Toolkit und soll auf einem Metamodell
basieren. Die Struktur zur Erstellung von Diagrammen soll einen Basissatz an
Diagrammkomponenten bieten, die dann als Eingabe fur einen Generator die-
nen sollen. Bestandteile eines Diagramms sind (Knoten (nodes), Kanten (edges
und Verbinder (connectors). Desweiteren soll es Editoren, Views und Naviga-
toren geben.
Wahrend der Validierungsphase soll geklart werden, welche Teile in einem Fra-
Abbildung 2.7: Uberblick uber die Konzepte von GMF
mework untergebracht werden und welche generiert werden sollen. Zunachst
sollen konkrete Beispiele fur GMF geschaffen werden, die als eine Folge von
Modellierungsumgebungen entwickelt werden, die dann ein integraler Bestand-
teil des Projektes werden sollen. Dazu zahlen die Entwicklung einer Oberflache
zur Modellierung von Ecore Modellen und die Erweiterung des UML2-Projektes
um diagrammatische Fahigkeiten. Ein high-level konzeptionelles Diagramm ist
in Abb. 2.7 zu sehen.
Diese Projekt befindet sich noch in der Validierungsphase, wodurch eine genaue
Beschreibung uber den Aufbau noch nicht moglich. Fur die Generierung soll
unter anderem auch JET benutzt werden.
Kapitel 3
Anforderungen
3.1 Ziel der Diplomarbeit
Ziel dieser Diplomarbeit ist die Konzeption und Implementierung eines Gene-
rators, der aus einer gegebenen Spezifikation fur eine visuelle Sprache einen
visuellen Editor generiert, der als Eclipse Plugin realisiert werden soll. Die
VL-Spezifikation besteht aus einem visuellen Alphabet und einer Graphgram-
matik. Dem generierten Editor soll die Model-View-Controller Architektur zu-
grunde 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 Re-
gelanwendung 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
20 Anforderungen
3.2.1 Anforderung an den Generator
Aus einer VL-Spezifikation, die der Generator als Eingabe bekommt, soll dar-
aus 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 fur graphar-
tige visuelle Sprachen erstellen. In den nachsten Ausbaustufen sollen noch
Simulations- und Analyseumgebungen folgen.
Eine VL-Spezifikation besteht aus einem visuellen Alphabet und einer Graph-
grammatik. Mit dem Alphabet werden die abstrakte Syntax und das konkrete
Layout beschrieben. Mit der Graphgrammatik sollen Regeln definiert werden,
die fur die Durchfuhrung von Editieroperationen verantwortlich sind.
Der Generator soll mit Hilfe eines Wizards gestartet werden. Dieser Wizard
soll alle benotigten 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 Grun-
doperationen wie Laden / Speichern und Erstellen einer Datei beherrschen.
3.2.2 Anforderung an den generierten Editor
Mit dem generierten Editor sollen die im Alphabet definierten SymbolTypen
editiert werden konnen. Welche Operationen fur ein SymbolType ausgefuhrt
werden kann, wird durch die Regeln in der Graphgrammatik festgelegt.
Der Editor soll uber einen Wizard verfugen, mit dem eine neue Datei fur die-
sen Editor erzeugt werden kann. Diese enthalt 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 Kontextmenu, werden andererseits durch
die Regeln in der Graphgrammatik bestimmt. Welche Regeln wo erscheinen sol-
len wird im nachsten genauer dargestellt.
Der Aufbau eines generierten Editors soll unabhangig von der visuellen Sprache
immer der gleiche sein: auf linken Seite soll sich eine Palette und auf der rech-
3.2 Funktionale Anforderungen 21
ten Seite die Zeichenflache 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 unabhangig. Dagegen gibt es Kom-
ponenten, die abhangig 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. Fur jeden
diesen NodeSymbolType soll dann eine Seite erzeugt werden. Ein Beispiel dafur
ist ein Editor fur Automaten. Im Tabulator am unteren Ende der Seite soll der
Name oder eine ID des NodeSymbolTypes erscheinen.
Regeln ...
Das Aussehen der Palette und des Kontextmenus sollen durch die Regeln be-
stimmt werden. Die Regeln sollen in verschiedene Kategorien eingeordnet wer-
den: in Einfuge-, Losch-, Bearbeitungs- und Verschieberegeln. Im folgenden soll
erlautert werden, wo welche Regeln erscheinen sollen.
In Abbildung 3.1 ist eine Unterteilung der Einfugeregeln zu sehen. Wenn es
Einfugeregeln gibt, die den Fallen 1 und 2 entsprechen, soll es Eintrage in der
Palette geben, die in zwei Bereiche unterteilt ist. Fur NodeSymbolTypes im
Bereich Symbols und fur EdgeSymbolTypes im Bereich Connections. Fur den
dritten Fall soll ein Eintrag mit dem Namen der Regel im Kontextmenu erschei-
nen.
Loschregeln soll grundsatzlich im Kontextmenu erscheinen und durch ein ro-
Abbildung 3.1: Einordnung der Einfugeregeln
22 Anforderungen
tes Kreuz als Loschregel markiert werden. Bearbeitungsregeln sollen ebenso im
Kontextmenu erscheinen. Die Anwendung von Verschieberegeln soll durch das
Verschieben eines NodeSymbolTypes auf der Zeichenflache erfolgen.
Fur ein selektiertes Objekt sollen im Kontextmenu nur die Regeln erscheinen,
die auf dem selektierten angewendet werden konnen.
3.3 Nichtfunktionale Anforderungen
Der Generator und der generierte Editor sollen als Eclipse Plugins realisiert
werden, d.h zur Ausfuhrung beider Programme wird die Eclipse Plattform und
Java benotigt. Fur die Entwicklung des Generators soll die Eclipse Plattform
auch als integrierte Entwicklungsumgebung eingesetzt werden. Der Generator
soll eine Codegenerierung fur den Editor nach Java vornehmen. Fur die Co-
degenerierung 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, konnen sie leicht in Eclipse integriert werden. Zur Durchfuhrung
von Editieroperationen (Regelanwendungen) im Editor soll die Graphtransfor-
mationsmaschine AGG verwendet werden.
Kapitel 4
Entwurf und Implementierung
Der Generator fur visuelle Sprachumgebungen besteht aus folgenden Kompo-
nenten, die im folgenden entworfen werden:
• ein Wizard, der alle Informationen sammelt und den Generator fur den
Editor startet
• eine Komponente fur den Generierungsablauf
• ein Regelanalysierer fur 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 Umwand-
lung in GEF Klassen
Zur Darstellung der Strukturen und des Verhaltens der einzelnen Komponenten
werden UML-Klassendiagramme [UML04] und UML-Sequenzdiagramme ver-
wendet. Fur die Darstellung der Sequenzdiagramme wird das EclipseUMLStu-
dio [Omo] von Omondo verwendet.
4.1 Paketstruktur des Generators
Im folgenden ist die Paketstruktur des Generators angegeben:
23
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 Regelana-
lysierer mit seinen Komponenent fur eine Analyse der Regeln aus der
Graphgrammatik.
• tiger.generator.util: Die Datenstruktur zur Kapselung des Alphabets
fur eine Abbildung nach Draw2D und GEF ist in diesem Paket zu finden.
• tiger.generator.jet: In diesem Paket gibt es Klassen, die fur die Code-
generierung mittels JET verantwortlich sind.
• tiger.generator.templates: Dieses Paket beinhaltet Templates, die
JET zur Codegenerierung benotigt.
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 hinzugefugt wur-
den. Desweiteren kann nun ein ”kind”-Attribut als AttributeType definiert
und die Referezen auf die entsprechen ShapeFigures gesetzt werden.
4.2 Der Wizard 25
• tiger.vlspec: VL Spezifikation, die das Alphabet, die Grammatiken und
den XMLHelper beinhaltet
• tiger.vlspec.alphabet: Klassen fur das Alphabet
4.2 Der Wizard
Wie in Kapitel 2.4 bereits erwahnt wurde, gibt es in Eclipse sogenannte Er-
weiterungspunkte, mit denen die Eclipse Plattform durch eigene Plugins er-
weitert werden kann. Der Generator-Wizard erweitert hier den Erweiterungs-
punkt org.eclipse.ui.newWizards und erscheint somit im New Wizard Menu von
Eclipse . Fur den Entwurf des Wizards werden bereits vorhandene Klassen
aus dem Eclipse SDK verwendet und erweitert.
Der Wizard hat die Aufgabe zwei Vorgange zu steuern: zum einen wird ein
Plugin-Project erzeugt und zum anderen wird der Generator gestartet, der dann
den Java Code fur den Editor erzeugt. Die Generierung des Plugin-Projektes
wurde bewusst nicht mit dem JET Framework durchgefuhrt, da es in Eclipse
die PDE – Plugin Development Environment gibt, die eine komfortable Erzeu-
gung 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
26 Entwurf und Implementierung
gespeichert werden, wie beispielsweise fur die Klassenpfade fur AGG , Xerces
, Colim , JGL und der Java Umgebung. Daruberhinaus werden bin und src
Verzeichnisse angelegt. Im Letzteren wird dann der Java Code fur den generier-
ten Editor gespeichert. Dieser Prozess wird im folgenden unter Einbeziehung
der einzelnen Klassen naher erlautert.
Um einen Wizard in die Eclipse Umgebung einzubinden, wird zunachst ei-
ne eigene Wizardklasse benotigt. Die Wizardklasse, EditorPluginProjectWizard
wurde von der bereits in Eclipse vorhandenen Klasse Wizard abgeleitet und
implementiert das Interface INewWizard. Dadurch kann sie an den Erweite-
rungspunkt org.eclipse.ui.newWizards angehangen werden. Diese Klasse ist fur
die Verwaltung der einzelnen Seiten eines Wizards, der eingegebenen Werte,
dessen Navigation und Beendigung zustandig.
Die eigegebenen Daten zur Pluginerzeugung werden durch die Klasse PluginDa-
ta reprasentiert, die durch die Wizardklasse erzeugt wird. Sie implementiert das
Interface IPluginData, welche alle notwendigen Methoden zur Generierung es
Editor-Plugins beinhaltet. Fur den Generator werden fur den jetzigen Stand nur
folgende Informationen benotigt: Projektname, Ort der Alphabetspezifikation
und eine eigene Dateiendung, welche nur eine Seite des Wizards benotigen.
Diese Seite wird durch die Klasse EditorProjectPage implementiert, die die An-
ordnung der Textfelder und Labels arrangiert. Sie erweitert die Klasse Editor-
ProjectPage, fur die bereits Moglichkeiten zur Eingabe eines Projektnames und
eines Ortes fur ein Projekt bereitgestellt werden.
Der Start des Generierungsprozesses erfolgt erst durch Klicken des Finish But-
tons. 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. Zunachst wird ein leeres Projekt angelegt,
welches eine Java und Plugin Nature erhalt, so dass dort vorhandene Java
Dateien kompiliert werden konnen. Danach werden wie in einem regularen Ja-
va 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
4.3 Der Generierungsprozess fur die Editordateien 27
Abbildung 4.3: Ablauf der Generierung des Plugin Projektes
Erweiterungsabschnitts fur den Editor sowie Hinzufugen des Runtimes und De-
pendenciesbereiches. Nachdem dieser erste Generierungsschritt abgeschlossen
wurde, beginnt nun die Generierung der Dateien fur den Editor.
4.3 Der Generierungsprozess fur die Editorda-
teien
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 waren einerseits das
JetGateway und die Datenstruktur, die das Alphabet kapselt. Nachdem diese
Datenstruktur durch das Alphabet initialisiert wurde, konnen die Grammati-
kregeln analysiert und entsprechend die Ergebnisse in der Klasse AnalysedRules
abgelegt werden. Damit stehen alle notwendigen Daten zur Generierung der
28 Entwurf und Implementierung
Editordateien bereit.
Der Ablauf der Generierung richtet sich danach, welche Informationen je Tem-
plate 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 ubergeben. Uber diese drei Klas-
sen sind dann alle Information fur 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 naher erlautert werden sollen. All die-
sen Methoden ist gemein, dass sie ein oder mehrere HashMaps haben, die als
Schlussel den Paketnamen und als Wert eine Liste von Namen von Templates
enthalt (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 fur die Generierung
4.3.1 Generierung mittels JET uber dem JetGateway
Zur Generierung des Java Quellcodes wird die Klasse JETEmitter aus dem
EMF Framework verwendet, deren Steuerung durch die Klassen JetGateway
ubernommen wird. In den oben genannten Methoden werden im JetGateway
fur jede zu generierende Datei der Paketname, der Name des Templates ge-
setzt. Danach wird der absolute Pfad fur dieses Template gesucht und dem
JETEmitter ubergeben, da sonst das Template nicht gefunden werden kann.
Dieser ubersetzt dann das Template wie in Kapitel 2.4.3 beschrieben wurde und
gibt einen String zuruck. Dieser String wird dann durch die Methode save() des
4.3 Der Generierungsprozess fur die Editordateien 29
JetGateways an die richtige Stelle im EditorPlugin unter Berucksichtigung des
ubergebenen Paketnames gespeichert. Dabei wird ersteinmal uberpruft, ob der
Ordner bereits existiert, sonst wird dieser neu erzeugt.
4.3.2 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 generateSim-
ple() erledigt, die in start() aufgerufen wird.
In diese Kategorie fallen zum Beispiel die Dateien fur den Wizard, die Editor-
klassen, die die Schnittstelle zwischen Eclipse und GEF darstellen und die
eigene EditDomain. Desweiteren wird ein EditPart generiert, der die Zeichen-
flache des Editors darstellt. Wenn im Alphabet kein NodeSymbolType definiert
wurde, der ein Container sein soll, dann bekommt dieser EditPart die Graph-
grammatik als Modell ubergeben, ansonsten ist es der Node, der den Container
reprasentiert.
4.3.3 Generierung der Controller und der Dialoge
An dieser Stelle wird fur jeden SymbolType je ein EditPart (Controller) gene-
riert. 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.
Fur die EditParts gibt es genau ein Template, aus dem alle generiert wer-
den konnen. Im Template (Editpart.javajet) muss dabei unterschieden wer-
den zwischen Knoten - und Kantensymbolen, da diese unterschiedliche Ba-
sisklassen haben, dies wren org.eclipse.gef.editparts.AbstractGraphicalEditPart
und org.eclipse.gef.editparts.AbstractConnectionEditPart.
Fur jeden SymbolType wird danach noch ein Dialog mit des Templates Dia-
log.javajet erzeugt, wenn dieser AttributeTypes besitzt. Die Anzahl der Eintrage
an TextFelder und Labels richtet sich dabei nach der Anzahl der AttributeTypes.
Dem JETEmitter wird bei diesem Generierungsschritt immer ein Objekt vom
30 Entwurf und Implementierung
Typ SymbolData ubergeben.
4.3.4 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
fur die Durchfuhrung einer Regelanwendung verantwortlich sind.
Dazu zahlen die EditPolicies zum Erzeugen und Commands zum Loschen von
Knoten und Kanten.
4.3.5 Generierung der Figuren Klassen
Jede Figur aus dem Alphabet (sowohl ShapeFigure als auch Connection)
ist spater im Editor durch eine eigene Klasse reprasentiert. Das Paket
tiger.templates.figure enthalt dafur Templates, die wie folgt benutzt werden:
• ShapeFigures werden mit nodefigure.javajet erzeugt
• wenn mehrere ShapeFigures zu einem NodeSymbolType gehoren und die-
ser zusatzlich uber ein ”kind”-Attribut verfugt, wird eine abstrakte Figu-
renklasse mit dem Template abstract.javajet erzeugt
• Connections werden mit edgefigure.javajet erzeugt abstract.javajet fur alle
ShapeFigures erzeugt
In der abstrakten Klasse werden Labels fur die Attribute des NodeSymbolTypes
erzeugt, wenn das visibility Attribut auf true gesetzt ist. Damit ist sicherge-
stellt, dass in jeder abgeleiteten Klass das Label vorhanden ist. Die Anzeige wird
dann letztendlich in der entsprechende abgeleiteten Figurenklasse geregelt.
4.4 Datenstruktur zur Kapselung des Alphabets 31
4.4 Datenstruktur zur Kapselung des Alpha-
bets
Diese Datenstruktur kapselt die Klassen des Alphabets fur die Abbildung der
Alphabetinformation in GEF und Draw2D konforme Klassen. Diese Vorge-
hensweise hat sich als nutzlich herausgestellt, da in den Templates nur primitive
Datentypen und String-Objekte ubergeben werden konnen. Aus diesem Grund
werden benotigte Ausdrucke bereits in diesen Klassen berechnet und eventuell
als ein zusammengesetzter String zuruckgegeben. Dadurch konnte die Komple-
xitat der Templates verringert und deren Ubersichtlichkeit bewahrt bleiben und
eine Wartung ist auch leichter moglich.
In Abbildung 4.5 ist eine Ubersicht uber diese Datenstruktur in Form eines
Abbildung 4.5: Datenstruktur zur Kapselung des Alphabets im Generator
Klassendiagramms gegeben. Es gibt eine Klasse AllSymbolData, die grundle-
gende Informationen wie Pluginname, Projektname und den Namen der VL-
Spezifikation enthalt. 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 gepruft, ob dieser SymbolType Attribute und Figuren hat.
32 Entwurf und Implementierung
Wenn dies der Fall ist wird fur ein Attribut eine Instanz der Klasse AttributeFi-
gure erzeugt, die ein AttributeType und eine TextFigure kapselt. Fur die Figur
des SymbolTypes wird entsprechend eine Instanz der Klasse NodeFigureData
oder EdgeFigureData erzeugt in Abhangigkeit davon, ob es sich um eine Shape-
Figure oder eine Connection handelt.
In Abbildung 4.6 wird eine Ubersicht uber 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.
Zuruck zur SymbolData Klasse, deren Informationen unter anderem zur Erstel-
-symbol[1] : SymbolType
SymbolData
+getName() : String
SymbolType
-figure : ShapeFigure
NodeFigureData
-figure : Connection
EdgeFigureData
+getPosition() : Point+getName() : String
«Schnittstelle»Figure
-kind : Enumeration
LayoutConstraint*
-first 1
*
-second1
-name : String-shape : Shape-borderColor : Color-fillColor : Color-defaultSize : Dimension
ShapeFigure
-name : String-datatype : Enumeration
AttributeType-name : String-font : Font-fontColor : Color-isVisible : Boolesch
TextFigure
*
-textLayout
0..1
-attrType : AttributeType
AttributeData
-figure : TextFigure
AttributeFigure
-name : String-strokeColor : Color-strokeWidth : ganz-strokeStyle : Style
Connection
-kind : Enumeration
ConnectionConstraint*1
1
*
1
*
1
*
1
*
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 uber end mit dem gekapselten SymbolType verbunden sind, und den
EdgeSymbolType, der uber begin verbunden ist, zuruck. Der Name des
4.4 Datenstruktur zur Kapselung des Alphabets 33
LinkTypes sollte dabei ”source” oder ”target” enthalten.
• getTargetConnection(): Funktioniert ahnlich der Methode getSource-
Connection(), nur dass hier LinkTypenamen ”target” oder ”end” beruck-
sichtigt werden.
• getSymbolFigures(): liefert eine Liste aller Figuren, die zu einem Symbol-
Type gehoren, zuruck
4.4.1 Figuren nach Draw2D
Im folgenden soll naher erlautert werden, in welcher Weise die konkreten Layout-
informationen aus dem TIGER Alphabet nach Draw2D abgebildet werden.
Fur die visuelle Darstellung von SymbolTypes im generierten Editor mussen
die Figuren Klassen aus Draw2D verwendet werden, da das von GEF so gefor-
dert wird. Draw2D verfugt im Vergleich zu SWT nur uber 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 Lay-
outmanager aus Draw2D umsetzen. Bevor die Beschreibung der Umsetzung
erfolgt, soll zunachst einmal der Aufbau einer Draw2D Figur und die Verbin-
dung 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 Fi-
gur aus einer unsichtbaren rechteckigen Containerfigur (gestrichelter Rahmen),
die alle anderen Figuren beinhaltet. Diese muss im Alphabet nicht spezifiziert
werden. Alle anderen mussen dagegen im Alphabet angegeben werden, wobei
die Textfigures eine besondere Rolle spielen, da ihr visibility Attribut zusatzlich
34 Entwurf und Implementierung
Abbildung 4.7: Aufbau einer Figur mit Draw2D
uber ihre Sichtbarkeit entscheidet.
Auf der linken Seite in Abb.4.7 ist eine Figur fur eine Stelle zu sehen, in deren
Mitte die Anzahl der Tokens und unterhalb der Name angezeigt wird. Diese Fi-
gur 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 reprasentieren, werden folgender-
maß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 dafur eine eigene Figurenklasse, die von org.eclipse.draw2d.Figure
erbt, implementiert werden. Dazu wird vom Generator innerhalb der Figuren-
klasse eine innere Klasse erzeugt, mit der ein Polygon gezeichnet werden kann.
4.4 Datenstruktur zur Kapselung des Alphabets 35
Vorgehensweise bei der Erstellung von Figurenklassen aus dem Al-phabet 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 konnen. Figure stellt hierbei das
Interface Figure aus dem Alphabet dar. Bei der Erstellung von Figurenklassen
mittels Draw2D mussen drei Schritte zur korrekten Darstellung einer Figur
im Editor, vollzogen werden.
Abbildung 4.8: Figure Aufbau durch den Generator auswertbar
1. Alle Figuren mussen im Konstruktor erstellt und durch LayoutManager
angeordnet werden. Dies beinhaltet auch das Setzen von Farben, Schriften
usw..
2. die Große der Figuren muss in der uberschriebenen Methode getPrefer-
redSize() von Draw2D zur Laufzeit des Editors berechnet werden
3. die berechnete Große wird durch Uberschreiben der validate() Methode
gesetzt
Fur jede ShapeFigure aus dem Alphabet wird eine eigene Figurenklasse erzeugt.
Der Generator nimmt zunacht einmal die gekapselte ShapeFigure aus der Klasse
NodeFigureData als Basisfigur, bei der die Analyse gestartet wird. Wenn ein No-
deSymbolType mehrere ShapeFigures hat, wird dies fur jede getan. Es hat sich
36 Entwurf und Implementierung
wahrend des Entwurfs als hilfreich herausgestellt zuerst alle vertikal bezuglich
der Basisfigur angeordneten Figuren zu betrachten. Dafur gibt es eine Methode
getVerticalElements(), die eine Liste von vertikal angeordneten Figuren zuruck-
gibt. Standardmaßig wird die Basisfigur in diese Liste mitaufgenommen. Alle
LayoutConstraints, die zu der Basisfigur gehoren, werden danach betrachtet,
wobei die Basisfigur uber second mit dem Layoutconstraint verbunden sein
muss. Wird eine Figur gefunden, die sich uber (LayoutConstraint.ABOVE) der
Basisfigur befindet, wird sie in der Liste vor der Basisfigur eingefugt, ansonsten
bei (LayoutConstraint.BELOW) hinter der Basisfigur.
Fur die horizontal angeordneten Figuren wird das gleiche Verfahren angewen-
det mit Hilfe der Methode getHorizontalElements(), außer dass die Basisfigur
nicht in die Liste mitaufgenommen wird. Hierbei muss die Basisfigur wieder uber
second mit den LayoutConstraints verbunden sein und die LayoutConstraints
RIGHT und LEFT werden berucksichtigt. Auch hier ist die Liste geordnet:
Wenn ein Element rechts steht wird es in der Liste vorn eingefugt ansonsten
hinten.
Schließlich wird noch mit Hilfe der Methode isInside() gepruft, ob die Basis-
figur eine innere Figur hat, indem nach dem LayoutConstraint INSIDE gesucht
wird.
Der eben genannte Ablauf wird fur die Erstellung des Konstruktors einer Figu-
renklasse verwendet wie es in Punkt 1 beschrieben worden ist.
Die Berechnung der Figurengroße (siehe Punkt 2) richtet sich nach der An-
zahl und Anordnung der Figuren bezuglich einer Basisfigur. Die Große berechnet
sich aus der Hohe und der Breite, wobei sich die Hohe aus den einzelnen Figu-
ren berechnet, die man mit getVerticalElements() bekommt und die Breite aus
den einzelnen Figuren, die man durch getHorizontalElements() erhalt. Dafur
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 Große vor der
Große der Gesamtfigur berechnet werden, Im Fall einer TextFigure, bei der sich
die Große zur Editorlaufzeit noch andern kann, wird der Ausdruck zur Berech-
nung der Große der inneren Figur in der Klasse NodeFigureData mit der Me-
4.4 Datenstruktur zur Kapselung des Alphabets 37
thode getInside() vorgenommen, die den Ausdruck als einen String zuruckgibt,
so dass dieser nur noch im Template eingetragen werden muss. Bei Aktivitaten-
diagrammen steht in einer einfachen Aktivitat der Name in der Mitte der Figur.
Dieser kann sich zur Editorlaufzeit andern, so dass die Figur vergroßert bzw.
verkleinert werden soll.
Um die Große der Gesamtfigur zu begrenzen, wurde ein zusatzliches Attribut
maximumSize : Dimension in der Alphabetklasse ShapeFigure definiert, mit
dem eine maximale Große der Gesamtfigur bestimmt werden kann. Wenn der
Text nun großer ist als die Gesamtfigur, wird dieser an einer bestimmten Stel-
le 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 erwahnt, die validate() Methode uberschrieben werden. Darin wird
dann die DefaultSize nochmal explizit gesetzt.
Die Erstellung der Connections ahnelt dem der ShapeFigures. Fur je-
de Connection wird ebenfalls eine eigene Klasse erzeugt, die immer von
org.eclipse.draw2d.PolylineConnection erbt. Die Verwendung von Layoutman-
angern entfallt bei Connections. Um Figuren an einer Connection auszu-
richten gibt es im Alphabet verschiedene ConnectionConstraints ( AT SRC,
AT CENTER, AT TARGET ), mit denen Figuren (ShapeFigures und TextFigu-
res) in Beziehung zu den Connections gesetzt werden konnen. In Draw2D wird
dies durch die Klasse ConnectionLocator erledigt, der genau die Moglichkeiten
der ConnectionConstraints aus dem Alphabet unterstutzt, was die Ausrichtung
einer TextFigure bezuglich einer Connection betrifft. Zwischen ShapeFigures
und Connections wurde bis jetzt das ConnectionConstraint AT CENTER ge-
nommen. Fur ShapeFigures mussen diese ConnectionConstraints in Draw2D
konforme AnchorPoints umgewandelt werden. Anchorpoints werden in dieser
Ausbaustufe vom Generator noch nicht unterstutzt. Durch den Generator wer-
den die beiden in Draw2D implementierten Anker EllipseAnchor fur Kreise
und Ellipsen und ChopboxAnchor fur 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
38 Entwurf und Implementierung
Figuren wie dem Polygon kann es passieren, dass sich eine Connection nicht am
Rand der Figur gezeichnet wird.
Fur eine Connection konnen Layoutinformationen fur Linienfarbe, Linienart
und Linienstarke gesetzt werden. Es werden alle in der Connectionklasse defi-
nierten Linienarten durch den Generator unterstutzt.
LinkTypes, die in der ersten Ausbaustufe des Generators Node-
SymbolTypes und EdgeSymbolTypes miteinander verbinden, konnen
uber ein konkretes LinkLayout verfugen. Das kann eine Raute oder
auch eine Pfeilspitze sein, deren Full- und Rahmenfarbe durch das
Alphabet definiert werden konnen. Diese beide Layoutmoglichkeiten
werden durch die Klassen org.eclipse.draw2d.PolygonDecoration und
org.eclipse.draw2d.PolylineDecoration unterstutzt und sind immer an eine
org.eclipse.draw2d.PolylineConnection gebunden. Daher wird das LinkLayout
immer in der Figurenklasse definiert, die eine Connection reprasentiert.
4.5 Der Regelanalysierer
Eine Analyse der Regeln aus der Graphgrammatik ist fur die Durchfuhrung
von Editieroperationen im Editor notwendig. Durch sie kann namlich festgelegt
werden, ob eine Editieroperation uber die Palette oder das Kontextmenu durch-
gefuhrt werden soll. Ein entsprechender Eintrag wird dann in der Palette oder
im Kontextmenu erzeugt. Zur besseren Analyse werden die Regeln in Einfuge,
Losch, Bearbeitungs, Verschiebe - oder sonstige Regeln durch den Regelanaly-
sierer eingeteilt.
Die Festlegung zu dieser Einteilung fiel wahrend der Entwicklung dieser
Komponente durch den Autor und hatte folgenden Hintergrund: Einfugeregeln
benotigen fast immer ein Dialog zum Setzen von Attributwerten. Die linke Re-
gelseite 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 Loschregeln konnen die zu loschenden Knoten durch Analyse der beiden
4.5 Der Regelanalysierer 39
Regelseiten identifiziert werden, denn sie haben kein Mapping mit der rechten
Regelseite.
Bei Bearbeitungsregeln wird stets ein Dialog benotigt, damit die Attributwerte
eines selektierten Objektes (Knoten oder Kante) geandert werden konnen. Im
Gegensatz dazu benotigen die Verschiebe-Regeln keinen Dialog, da hier nur die
Position eines Knotens verandert wird. Sollte es fur Kanten eine solche Regel
gibt, wird diese vom Regelanalysierer ignoriert.
4.5.1 Struktur des Regelanalysierers
Ziel der Regelanalyse ist es, alle benotigten Informationen einer Regel so auf-
zubereiten, dass diese in den Templates schnell und einfach abgefragt werden
konnen. Dazu wurde die Struktur in Abb. 4.9 entworfen. Die Klasse RuleAna-
Abbildung 4.9: Struktur fur den Analysierer
lyser bekommt vom Generator alle Regeln aus der Graphgrammtik ubergeben.
Sie bietet diverse Methoden zur Regelanalyse, welche durch den Generator auf-
gerufen werden, um die Regeln zu analysieren. Fur jeden SymbolType wird dabei
eine Methode pro Kategorie aufgerufen. Bei Regeln, die nicht in diese Kategorien
passen wird ein Standardverfahren angewendet. Fur jede Kategorie gibt es ei-
ne Methode, die die Analyse vornimmt, z.B. analyseInsertingRules(type:String).
Hier wird der Typ von jedem SymbolType ubergeben.
Der Regelanalysierer hat eine Referenz auf genau eine Instanz der Klasse Ana-
lysedRules, in der die Analyseergebnisse abgelegt werden. Fur jede Kategorie
gibt es auch eine entsprechende java.util.Map, in der Typ des entsprechenden
SymbolTypes als Schlussel und eine Liste der dazugehorigen analysierten Re-
40 Entwurf und Implementierung
geln halt.
Fur die analysierten Regeln wurde eine eigene Klasse entworfen, die unter ande-
rem den Regelnamen, die Anzahl der Mappings und deren beteiligte Typen und
eine Abbildung von den Inputparametern zu den Attributen enthalt. Dazu gibt
es eine Klasse NodeType, die einen Typ und alle dazugehorigen Inputparameter
speichert, damit spater auch nachvollzogen werden kann, welche Inputparameter
an welche Attribute gebunden sind, wurde eine Klasse ParmeterMap entworfen.
Dort werden die Inputparameter mit den Attributen assoziiert.
4.5.2 Analyse der Regeln
Die Schlusselworter, die zur Einteilung der Regeln benotigt werden, sind in ent-
sprechende Arrays in der Klasse RuleAnalyser abgelegt. Jde Methode, die der
Analyse einer Regel dient, bekommt den Typ eines SymbolType als String uber-
geben. Innerhalb dieser Methode wird fur 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
Schlusselworter zur Einordnung in die entsprechende Kategorie dienen.
Einfugeregeln
Zu den Einfugeregeln zahlen alle Regeln, deren Namen die Schlusselworter add,
insert, create und den ubergegeben Typ enthalten. Bei ihnen wird zunachst die
linke Regelseite betrachtet. Wenn sie leer ist, wird sie in der Klasse RuleData
als Basisregel markiert. Dabei ist die Festlegung einer Basisregel fur eine Regel
abhangig davon, ob ein Knoten oder eine Kante eingefugt wird. Regeln, die
einen Knoten einfugen sind dann Basisregeln, wenn deren linke Seite leer ist.
Bei Regeln die eine Kante einfugen, mussen 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
Kontextmenu aufgenommen. Dazu ist es wichtig den Typ dieses Knotens zu
4.5 Der Regelanalysierer 41
wissen, da dieser mit dem im Editor selektierten Objekt ubereinstimmen muss.
Wenn auf der linken Seite mehrere Elemente stehen, werden alle Knoten
ignoriert, deren Typ nicht dem ubergebenen Typ entsprechen. Wenn dies
jedoch mehere Knoten sind, wird es schwierig diesen Knoten fur das Mapping
zwischen selektiertem Objekt im Editor und Knoten der linken Regelseite zu
bestimmen.
Danach wird im AttributeContext einer Regel geschaut, ob es Inputparameter
fur sie gibt. Es wird dann in alle Knoten der rechten Regelseite geschaut, welche
Attribute eines Knotens an diese Inputparameter gebunden sind. Fur jeden
betreffenden Knoten wird eine Instanz der Klasse NodeType erzeugt, die den
Typ des Knotens und die ParameterMap enthalt, in denen die Inputparameter
mit den Attributen und dem entsprechenden Datentyp assoziiert sind.
Fur jeden Knoten, dessen Attribute an Inputparameter gebunden sind, wird
ein Dialog geoffnet. Dabei erscheint der Name des Inputparameters als Label
im Dialog.
Loschregeln
Vom Regelanalysierer werden alle Regeln als Loschregeln identifiziert, die die
Schlusselworter delete, remove, destroy enthalten. Loschregeln sind dadurch ge-
kennzeichnet, dass die linke Regelseite großer als die rechte Seit und die zu
loschenden Knoten und Kanten auf der linken Seite nicht an einem Mapping
mit der rechten Seite beteiligt sind.
Wie bei den Einfugeregeln gibt es auch bei den Loschregeln 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 Ana-
lyse beginnt also mit der Festlegung, ob es eine Basisregel ist oder nicht. Danach
wird der Knoten auf der linken Seite gesucht, der dem ubergebeben Typ ent-
spricht und nicht am Mapping mit der rechten Seite beteiligt ist.
Desweiteren wird auch hier uberpruft, ob es Inputparameter gibt. Wenn ja, wird
hier wie bei den Einfugeregeln verfahren.
42 Entwurf und Implementierung
Bearbeitungsregeln
Bearbeitungsregeln sollten die Schlusselworter edit,change und den ubergebe-
nen Typ enthalten. Mit den Bearbeitungsregeln werden Attributwerte einzelner
Knoten geandert. Fur jeden NodeSymbolType, der Attribute hat, wird auch ein
Dialog mit entsprechenden Feldern generiert. Die Regel wird dahingehend un-
tersucht, welcher Dialog fur den Knoten, deren Attribute geandert werden soll,
geoffnet werden soll. Dazu werden der Typ des Knotens und die Attribute her-
ausgesucht, die an Inputparameter gebunden sind.
Im Template fur die Bearbeitungsregeln gibt es dann eine Methode, die den Typ
ubergeben bekommt und den Knoten aus der linken Regelseite heraussuchte, um
ein Mapping zwischen dem selektierten und diesem Regelknoten herzustellen.
Verschieberegeln
Fur Verschieberegeln gibt es nur ein Schlusselwort, namlich move. Verschiebe-
regeln zeichnen sich dadurch aus, dass nur die Posiitionskoordinaten geandert
werden. Es ist festgelegt, dass fur Positionskoordinaten x und y vom Typ Inte-
ger verwendet werden. Daher wird bei der Analyse nur nachgeschaut, ob es eine
Regel mit dem entsprechenden Schlusselwort und dem ubergebenen Typ gibt.
Eine Uberprufung von Inputparametern, die einen Dialog benotigen 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 Uber-
blick uber 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.
4.6 Der generierte Editor 43
4.6.1 Paketstruktur
Die Paketstruktur spiegelt die Paketstruktur der Templates aus dem Generator
wider. (Das Sternchen steht fur den entsprechenden Paketname, der sich aus
dem Projektname ergibt):
Abbildung 4.10: Paketstruktur des generierten Editors
• *.action: Dieses Paket enthalt alle Eintrage des Kontextmenus
• *.commands: In diesem Paket sind alle Klasssen zu finden die fur eine
Regelanwendung verantwortlich sind
• *.editparts: Hier sind alle Controller (EditParts) abgelegt. Fur 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 GEF-
basierten Editors in Eclipse regeln.
• *.figure: Enthalt die Figurenklassen fur je eine ShapeFigure / einer
Connection
• *.model: Enthalt interne benotigte Klassen.
44 Entwurf und Implementierung
• *.wizard: Implementierung des Wizards, der eine neue Datei mit dem
Startgraphen erzeugt.
4.6.2 Aufbau des Editors
Der Editor besteht aus einer Palette auf der linke und einer Zeichenflache auf
der rechte Seite (siehe Abb. ). In der Palette gibt es eine Unterteilung in Sym-
bols (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 Kontextmenu kann uber die rechte Maustaste geoffnet werden. Die An-
zahl der Eintrage ist abhangig vom selektierten Objekt. Im Kontextmenu sind
Erzeugende, Loschende und Editierregeln mit deren Regelnamen zu sehen.
4.6.3 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 dafur verantwortlich. Ein Editor besteht
in der Regel aus einer Seite, es denn es gibt eine Art Container, denn dann
gibt es fur jeden Container eine Seite. Fur jede Seite wird wird eine eigene
EditDomain angelegt, die einen CommandStack zur Verwaltung der Commands
fur die Regelanwendungen initialisiert und einen GraphicalViewer erstellt, der
fur die Verwaltung der EditParts verantwortlich ist. Daruberhinaus 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 Kontextmenu angezeigt werden konnen. Aktion
dienen zum Aufruf von Commands aus dem Kontextmenu heraus. Diese Klasse
implementiert Methoden zum Laden und Speichern der vom Wizard erstellten
Editordatei.
4.6 Der generierte Editor 45
4.6.4 Anbindung von AGG an den Editor
Da die Klasse Editor.java fur das Laden und Speichern einer Graphgrammatik
verantwortlich ist, wird in ihr auch in ihr eine Instanz einer GraGra gehalten.
Daruberhinaus wird eine Instanz der Klasse GraTra erzeugt, die diese Instanz
der GraGra enthalt und uber 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 zu-
griffen werden.
Fur jeden SymbolType, fur 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 halt. Die Controller implementieren das Interface
AttrEvent aus AGG , so dass Anderung an den Attributewerten auf den View
propagiert werden konnen. Sobald sich ein Attributwert eines Node andert, wer-
den die Anderungen durch die EditParts abgefangen.
An diesen EditParts werden weiterhin diverse EditPolicies registriert, mit de-
nen man verschiedenste Commands erzeugen kann, mit denen Regeln fur das
Loschen, Bewegen und Einfugen von SymbolTypen angewendet werden konnen
(siehe Abb. 4.11).
Anwendung einer Regel im Editor
Die Regelanwendungen werden durch die Commands gesteuert. Der Regelna-
me, die GraphGrammatik und die im Editor selektierten Objekte werden dabei
uber die entsprechende EditPolicy abgefragt und dem erzeugte Command uber-
geben. Fur alle Commands gibt es zwei durch den Editor generierten abstrakte
Basisklassen NodeCommand und EdgeCommand, in denen die GraphGramma-
tik, der erzeugte Match und die zu anwendene Regel gehalten werden. In diesen
beiden Klassen befindet sich eine execute Methode, die die Durchfuhrung eines
Transformationsschrittes regelt. Alle Commands, die ein NodeSymbolType edi-
tieren erben von NodeCommand und alle die EdgeSymbolTypes editieren erben
46 Entwurf und Implementierung
Abbildung 4.11: Schematischer Ablauf einer Regelanwendung im Editor
von EdgeCommand. Es gibt Commands zum Erzeugen, Loschen, Editieren und
Bewegen von Objekten. Beim Erzeugen von den Commands in den EditPolicies
wird ein Regelname ubergeben. Dieser kommt vom Kontextmenu oder auch aus
der Palette. Daruberhinaus wird dem erzeugten Command die GraTra Instanz
aus der EditDomain ubergeben.
Nachdem alle notwendigen Daten im Command gesetzt wurden, wird die execute
Methode des Commands aufgerufen. In einem Command konnen eine oder meh-
rere Regeln behandelt werden. Regeln, die beispielsweise einen Knoten loschen
unabhangig vom Typ, befinden sich alle in der Klasse NodeDelete.java.
Es werden zunachst alle Inputparameter mit Hilfe von Dialogen gesetzt, die
zur Durchfuhrung einer Regel benotigt werden. Danach wird die Regel aus der
GraphGrammatik uber den gegeben Name geholt und uber den AttrContext
werden die durch die Dialoge gesammelten Werte den entsprechenden Attri-
buten zugewiesen. Als letzter Schritt vor dem Transformationsschritt wird ein
Match erzeugt und das selektierte Objekt aus dem Editor auf einen entspre-
chenden Node auf der linken Regelseite gemappt. Dafur gibt es eine vom Autor
entwickelte Methode, die das regelt. Die Parameter fur 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
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.
Zunachst 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) fur den Transformationsschritt gepruft. Bei Auftreten eines Feh-
lers werden entsprechende Fehlermeldungen uber einen Dialog dem Benutzer
mitgeteilt. Daraufhin folgt noch eine Prufung des Matches mit Hilfe der Me-
thode isValid(). Danach wird der Transformationsschritte durch Aufruf von
GraTra.apply(Match m) durchgefuhrt. Bei korrekter Durchfuhrung wird ein
entsprechender Event (GraTraEvent.SPEP COMPLETED)von AGG gewor-
fen, der vom EditPart, der den GraTraEventListener registriert hat, abgefangen
und eine entsprechende Aktualisierung des Views vorgenommen. Der GraTraE-
ventListener wird vom obersten EditPart implementiert, der die Zeichenflache
des Editors darstellt. Bei einem Container halt dieser EditPart den Container-
knoten als Modell, ansonsten die GraGra. Die erzeugten Matches werden nach
Regelanwendung, egal ob erfolgreich oder nicht, wieder geloscht.
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
uber AGG , d.h das Erzeugen, Loschen und Aufruf von Methoden im außen-
stehenden 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 mussen nicht als AttributeTypes des Alphabets definiert.
48 Entwurf und Implementierung
Abbildung 4.12: Anbindung einer externen Schnittstelle an den Editor
4.7 Benutzte Technologien
Fur den Entwurf und die Implementierung wurden folgende ProgrammPakete
verwendet:
• Java in der Version 5.0 [Jav]
• AGG in der Version 1.2.6 [AGG]
– JGL
– Xerces
• Eclipse in der Version 3.1M4 [Ecl05]
• GEF in der Version 3.0.1 [GEF]
• JET , das Bestandteil von EMF [Emf] ist und in der Version 2.1.0 ver-
wendet wird.
Kapitel 5
TestEditoren
In diesem Kapitel soll der Generator anhand von drei Beispieleditoren getestet
werden. Dies soll ein Editor fur Petrinetze, einer fur einfache Aktivitatendia-
gramme und einer fur einen Automaten sein.
Fur die Editoren wird zunachst das Alphabet angegeben. Zunachst 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 fur Petrinetze
Ein Petrinetz besteht aus Stellen und Transitionen, die uber ArcTPs und Ar-
cPTs miteinander verbunden sind. In den folgenden beiden Unterabschnitten
wird ein Alphabet und eine Graphgrammatik fur Petrinetze vorgestellt.
5.1.1 Alphabet
Fur den Petrinetzeditor wird zunachst die abstrakte Syntax bestehend aus No-
deSymbolTypes, EdgeSymbolTypes und schließlich LinkTypes definiert. Im Pe-
trinetzeditor gibt es zwei NodeSymbolTypes (Place, Transition), zwei EdgeSym-
bolTypes (ArcPT, ArcTP) und vier LinkTypes (arcTPsource, arcTPtarget, ar-
cPTsource, arcPTtarget). In Abbildung 5.1 ist ein Uberblick uber das Alphabet
49
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
vollstandiges Alphabet fur Petrinetze zu finden. Dort ist die Instanziierung der
einzelnen Alphabetklassen fur ein Petrinetz zu finden. Zunachst werden dort
alle Elemente der abstrakten Syntax erzeugt und dann alle Klassen fur das kon-
krete Layout instanziiert.
In Abbildung 5.2 sind die einzelnen Figuren fur die SymbolTypen aus dem Al-
Abbildung 5.1: Alphabet fur ein Petrinetz
phabet dargestellt. Fur die Stelle wird ein Kreis definiert, dessen Attribut token
sich in der Mitte befindet und dessen Attribut name sich unterhalb des Kreises
5.1 Editor fur Petrinetze 51
befindet. Der Name der Transition wird als Rechteck dargestellt und ihr Na-
me 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
5.1.2 Grammatik
Im folgenden werden die Regeln der Graphgrammatik fur Petrinetze vorgestellt.
Fur diese Graphgrammatik ist die DanglingCondition eingeschaltet.
In Abbildung 5.3 sind die Einfugeregeln zu sehen. Es konnen Stellen und Tran-
sitionen eingefugt werden, die keine gleichen Namen haben. Durch einen Dialog
werden der Name und die Anzahl der Tokens uber einen Dialog eingegeben, die
Position wird uber die Position des Curors auf der Zeichenflache ermittelt und
gesetzt. Desweiteren konnen Verbindungen zwischen Stellen und Transitionen
eingefugt werden, wenn es bereits eine Stelle und eine Transition gibt. Uber
einen Dialog werden die Inschriften fur die Verbindungen gesetzt.
Mit den letzten beiden Regeln aus Abbildung 5.3 konnen fur ein ausgewahltes
Objekt im Editor eine Stelle mit entsprechender Verbindung / eine Transition
mit entsprechender Verbindung erzeugt werden. Neben den Einfugeregeln gibt
es Loschregeln (siehe Abb. 5.4), die die von der Einfugeregeln erzeugten Struk-
turen wieder loschen konnen. Fur jeden SymbolType gibt es Bearbeitungsregeln
(siehe Abb. 5.5), mit denen die Inschrift der beiden EdgeSymbolTypes, die Na-
men der NodeSymbolTypes und bei der Stelle noch zusatzlich die Anzahl der
Tokens geandert werden kann. Fur die beiden NodeSymbolTypes mussen noch
Verschieberegeln definiert werden (siehe Abb. 5.6, so dass sie beide uber die
Zeichenflache bewegt werden konnen. Fur die Petrinetze ist es nicht notwendig
52 TestEditoren
Abbildung 5.3: Einfugeregeln
Abbildung 5.4: Loschregeln
Abbildung 5.5: Bearbeitungsregeln
Abbildung 5.6: Verschieberegeln
einen Startgraphen zu definieren.
5.2 Editor fur einfache Aktivitatendiagramme 53
5.1.3 Editoraufbau
In Abbildung 5.7 ist der aus dem oben beschriebenen Alphabet generierte Edi-
tor fur Petrinetze zu sehen. Der Aufbau entspricht dem, den man aufgrund des
Alphabets und der Regeln erwarten konnte.
In der Palette gibt es jeweils zwei Eintrage fur Symbole und Connections, da es
fur die NodeSymbolTypes Einfugeregeln (vgl. Abb. 5.3) gibt, deren linke Seiten
leer und auf der rechten Seite der zu erzeugende NodeSymbolType zu finden
ist. Fur die beiden EdgeSymbolTypes gibt es ebenfalls zwei Regeln, die auf der
linken Seite zwei NodeSymbolTypes erhalt, die durch sie verbunden werden soll.
Deshalb gibt es fur sie auch Eintrage in der Palette.
Desweiteren werden die Einfugeregeln addEdgePlace und addEdgeTransition im
Kontextmenu aufgenommen und in Abhangigkeit des selektierten Objektes an-
gezeigt. Fur eine Transition wird die erstere und fur eine Stelle die zweite an-
gezeigt (vgl. dazu Abb.5.7).
Alle Loschregeln und Editierregeln werden ebenfalls im Kontextmenu in
Abhangigkeit vom selektiertem Objekt angezeigt. Die Verschieberegeln fur die
Stelle und die Transition werden durch Verschieben der grafischen Objekte auf
der Zeichenflache angewendet.
Fur alle Regeln konnen undo / redo Operationen angewendet werden.
Auf der rechten Seite befindet sich die Zeichenflache, auf der beliebig viele
Petrinetze gezeichnet werden konnen.
5.2 Editor fur einfache Aktivitatendiagramme
Anhand des Editors fur einfache Aktivitatendiagramme wird das syntaxgesteu-
erte Editieren von Diagrammen verdeutlich. Es gibt einen Startgraphen in der
Grammatik, ohne den kein Aktivitatendiagramm gezeichnet werden kann.
54 TestEditoren
Abbildung 5.7: Screenshot des generierten Petrinetzeditors
5.2.1 VL-Spezifikation
Alphabet
Ein Aktivitatendiagramm besteht aus einem NodeSymbolType (Activity) und
einem EdgeSymbolType (Next) in der abstrakten Syntax (siehe Abb. ??. Fur
eine Aktivitat gibt es vier verschiedene visuelle Darstellungen, die uber ein
”kind”-Attribut die visuelle Darstellung der Aktivitat bestimmen. Es gibt visu-
elle Darstellungen fur Aktivitaten, die als Startknoten, Endknoten, als einfache
Aktivitat und als Entscheidung visualisiert werden sollen. Die Definitione von
einfachen Aktivitaten und Entscheidungen ist in Abb. ?? und ?? zu sehen. Des-
weiteren hat eine Aktivitat noch eine Attribut name. Fur das Attribut name
wird eine sichtbare TextFigure definiert und fur das kind Attribut eine unsicht-
bare TextFigure (siehe dazu Abb. ??).
Graphgrammatik
Fur die Aktivitatendiagramme gibt es Einfuge, Losch, Bearbeitungs und Ver-
schieberegeln. In Abb. 5.8 sind die Einfugeregeln zu sehen. Dort ist zu sehen,
5.2 Editor fur einfache Aktivitatendiagramme 55
dass es keine linke Regelseite gibt, d.h. es wird keinen Eintrag in der Palette
zum Erzeugen von Aktivitaten geben, sondern nur im Kontextmenu. In Abb.
Abbildung 5.8: konkrete Syntaxregeln zum erstellen von einer Aktivitat undganzer Strukturen
5.9 sind alle Loschregeln fur die Aktivitaten zu sehen. Bei allen Regeln, die
Abbildung 5.9: konkrete Syntaxregeln zum loschen von Aktivitaten
im Kontextmenu erscheinen, wird in Abhangigkeit vom selektierten Objekt im
Editor gepruft, ob die Regel anwendbar ist oder nicht. Wenn sie anwendbar ist,
dann erscheint sie im Kontextmenu.
56 TestEditoren
Abbildung 5.10:
5.3 Editor fur Automaten
5.3.1 VL-Spezifikation
5.3.2 Anbindung einer externen Schnittstelle
Abbildung 5.11:
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 re-
gelbasiert und syntaxgesteuert arbeit. Fur die Regelanwendungen wurde die
Graphtransformationsmaschine AGG an den Editor angebunden. Der Genera-
tor 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 fur den Generator und als Laufzeitumgebung
fur beide eingesetzt.
Der entstandene Generator ist in der Lage aus einer VL-Spezifikation einen
funktionsfahigen Editor vollstandig zu generieren. Von der VL-Spezifikaiton
wird erwartet, dass sie in sich korrekt ist. Ein Vorschalten einer Uberprufung
wurde nicht in Betracht gezogen, da diese spater 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
58 Zusammenfassung und Ausblick
6.2.1 Erstellung von Figuren
Der Generator ist in der Lage Figuren zu erstellen, die dem Muster aus Ab-
bildung 4.8 entsprechen. Andere Anordnungen konnen noch nicht berucksichtig
werden. Um dies zu andern, muss die Klasse LayoutConstraint aus dem Al-
phabet angepasst werden. Die Ausrichtungsarten mussten sich naher an den
im Editor verwendeten Layoutmanagern orientieren. Im Moment entsprechen
die vorhandenen Konstanten im BorderLayout in Draw2D , das jedoch noch
einige andere LayoutManager unterstutzt.
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 mussen die vom Designer zur Anordnung der Figuren
benotigten Layoutmanager auch vom Generator benutzt werden konnen. Aus
diesem Grund muss die Klasse LayoutConstraint so angepasst werden, das dies
bewerkstelligt werden kann.
6.2.2 Anpassungen des Regelanalysierers
Der Regelanalysierer ist in der Lage Einfuge-, Bearbeitungs-, Losch- und Ver-
schieberegeln zu analysieren. Daruberhinaus kann er auch andere Regeln analy-
sieren, wobei noch Fehler bei der Regelanwendung im Editor auftreten konnen.
Dies betrifft vor allem das Mapping zwischen dem selektiertem Objekt im Editor
und dem Knoten auf der linken Regelseite.
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
3.0.1 und EMF Plugin in der Version 2.0.1.
7.1 Installation
Als Laufzeitumgebung fur den Generator und den Editor wird die Eclipse
Plattform verwendet und somit auch Java benutzt. Zunachst muss die Eclip-
se Plattform installiert werden. Danach mussen die EMF und GEF Plugins
installiert werden. Vom EMF Plugin wird der JetEmitter verwendet, der zur
Generierung der Editordateien benotigt wird. Das GEF Plugin wird fur den
generierten Editor benotigt.
Es gibt nun zwei Moglichkeiten, das TIGER Projekt, das den Generator, die
TIGER VL-Spezifikation und Beispieldateien fur Aktivitatendiagramme und
Petrinetze enthalt, zu installieren.
Die erste Moglichkeit besteht nun darin das Projekt uber den Eclipse internen
Installationsmechanismus zu installieren. Dazu wird der Menueintrag Menu >
Software Updates > Find and Install ... ausgewahlt. Danach muss die Option
Search for new features to install ausgewahlt und der Next Button gedruckt
werden. In der folgenden Wizard Seite muss nun eine neue Remote Site festge-
legt werden. Der Name ist dabei optional aber es muss folgende URL gesetzt
59
60 Benutzerhandbuch
werden: http://tfs.cs.tu-berlin.de/tigerprj/update. Wenn dies getan ist, muss der
neu erstellte Eintrag ausgewahlt und Next gedruckt werden. Dabei wird uber-
pruft, ob die URL erreichbar ist. Auf der nachsten Seite erscheint ein Eintrag
TIGER-Environment, der ausgewahlt werden muss. Danach muss noch eine Li-
zenzvereinbarung bestatigt werden und dann ist alles fur die Installation getan.
Eine andere Moglichkeit 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 naturlich eine neue
Eclipse Runtime-Workbench gestartet werden. In dem ausgecheckten Projekt
befinden sich dann die VL-Spezifikationen fur Petrinetze und Aktivitatendia-
gramme 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 Edi-
tors vorgestellt, die in den nachfolgenden Unterkapiteln noch naher ausgefuhr
werden.
Die Erstellung des Alphabets erfolgt spater uber den TIGER Designer, der
zum Zeitpunkt der Entstehung dieser Diplomarbeit noch nicht vollstandig im-
plementiert war. Die Grammatikregeln mussen ebenfalls noch auf andere Weise
erzeugt werden, namlich mit dem AGG Tool. Dies soll spater ebenfalls vom
Designer ubernommen werden.
1. Erstellung einer VL-Spezifikation:
(a) Alphabet fur die visuelle Sprache erstellen
(b) Regeln fur die Grammatik mit Hilfe AGG erstellen
2. Starten des TIGER Generators uber den Wizard
(a) Definition eines Namens fur das Editor Projekt
(b) Angabe des Ortes der Alphabet-Spezifikation
(c) Definition einer Dateiendung zum Starten des Editors
7.3 Allgemeines zur VL-Spezifikation 61
3. Start einer neuen Runtime-Workbench zum Testen des generierten Editors
4. Eine neue Datei uber den Wizard anlegen (enthalt den Startgraphen der
Grammatik)
5. Durch doppelklicken auf die Datei den Editor starten
7.3 Allgemeines zur VL-Spezifikation
In diesem Abschnitt wird ein Uberblick uber das TIGER Alphabet gegeben
und welche Moglichkeiten es fur die Definition eines visuellen Alphabets bietet.
7.3.1 Uberblick uber das TIGER Alphabet
In TIGER gibt es eine Klasse VLSpec, die das Alphabet und die eine Syntax-
grammatik, eine Simulationsgrammatik und einen Typgraphen fur die Syntax-
grammatik verwaltet. Daruberhinaus verfugt sie uber Methoden zum Laden und
Speichern von VL-Spezifikationen.
Das Alphabet besteht aus einer Klasse Alphabet, die alle Knoten - und Kanten-
symbole und Links enthalt. Die Knoten - und Kantensymbole werden durch die
Klassen NodeSymbolType und EdgeSymbolType reprasentiert, die das Interface
SymbolType implementieren. Ein SymbolType kann mehere Attribute besitzen,
die durch die Klasse AttributeType reprasentiert werden. Ein AttributeType hat
dabei immer einen Namen und einen Datentyp.
In der ersten Ausbaustufe gibt es die Restriktion, dass NodeSymbolTypes nur
mit EdgeSymbolTypes uber LinkTypes miteinander verbunden werden durfen.
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 Ge-
nerator konnen folgende ShapeFigures gezeichnet werden: Rectangles, Roun-
dedRectangles, Circles, Ellipses, Polygons. Fur diese Figuren kann dann noch
62 Benutzerhandbuch
eine Farbe fur den Rahmen (borderColor), eine Fullfarbe (fillColor), eine Stan-
dardgroße (defaultSize) und eine maximale Große fur die Figur (maximumSize)
fesgelegt werden. Fur die maximale Große wird zunachst die Standardgroße
verwendet. Soll diese sich von der Standardgroße unterscheiden, muss sie ex-
plizit gesetzt werden. Fur ein NodeSymbolType konnen mehrere ShapeFigures
definiert werden. Der NodeSymbolType muss dann ein ”kind”-Attribut haben,
uber das die verschiedenen ShapeFigures referenziert werden konnen.
Die EdgeSymbolTypes werden durch die Klasse Connection reprasentiert.
Eine Connection ist eine Linie, fur die verschiedene Attribute gesetzt werden
konnen. Dies sind einerseits die Linienstarke, die Linienart und die Linienfar-
be. Fur die Linienart gibt es bereits vordefinierte Konstanten wie Connecti-
on.PLAIN fur durchgezogene, Connection.DOTTED fur gepunkte und Connec-
tion.DASHED fur gestrichelte Linien.
AttributeTypes, die stets zu SymbolTypen gehoren, konnen durch die Klasse
TextFigure visualisiert werden. Dafur konnen folgende Attribute gesetzt wer-
den: ein Figurenname, eine Schrift (Schriftart, Schriftstil, Schriftgroße), eine
Schriftfarbe und ein Sichtbarkeitsattribut.
LinkTypes konnen durch die Klasse LinkLayout ein konkretes Layout erhal-
ten. Dies ist meist eine Pfeilspitze oder eine Raute. Im generierten Editor wird
das Layout fur einen LinkType an den Anfang oder das Ende einer Connection
gezeichnet, was durch den LinkType bestimmt wird. Diese Klasse besitzt Attri-
bute, mit denen die Rahmenfarbe oder die Fullfarbe festgelegt werden kann.
Neben der Festlegung der einzelnen grafischen Darstellung konnen die einzel-
nen Elemente nun noch in Beziehung zueinander gesetzt werden. Dafur gibt es
die beiden Klassen LayoutConstraint und ConnectionConstraint. Mit der erste-
ren konnen TextFigures und ShapeFigures zueinander und auch untereiander in
Beziehung gesetzt werden. Dafur gibt es eine Reihe vordefinierter Konstanten:
UNDEFINED, ABOVE, BELOW, CENTER, LEFT, RIGHT.
Fur die Ausrichtung von Connections und Figures gibt es die ConnectionCons-
traints AT SRC, AT TAR, AT CENTER.
7.4 Alphabetdefinition fur Petrinetze 63
7.3.2 Erstellung von Grammatikregeln
Fur die Durchfuhrung von Editieroperationen mussen mindestens Einfuge-
, Losch-, Bearbeitungs- und Verschieberegeln definiert werden. Regelname
mussen beim jetzigen Stand des Generators aus einem Schlusselwort, das die
Art der Regel bezeichnet und der Typ, der durch die Regeln manipuliert werden
soll. Schlusselworter fur Einfugeregeln sind: add, create, insert, fur Loschregeln:
delete, destroy, remove, fur Bearbeitungsregel: edit, rename und fur Verschie-
beregeln: move.
Einfugeregeln, die einen NodeSymbolType erzeugen und deren linke Regelseite
leer ist, erscheint in der Palette unter dem Eintrag Symbols. Wenn Einfugeregeln
fur EdgeSymbolTypes in der Palette erscheinen soll, mussen auf der linken Re-
gelseite zwei Knoten zu finden sein, die durch den EdgeSymbolType verbunden
werden sollen.
7.4 Alphabetdefinition fur 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 Klas-
se VLSpec erzeugt werden, die das Alphabet und die Graphgrammatik enthalt.
Nachdem eine Alphabetinstanz erzeugt worden ist (siehe Abb. 7.1), fahrt man
Abbildung 7.1: Erstellung einer VLSpec und eines Alphabets
mit der Erstellung der NodeSymbolTypes fort.
64 Benutzerhandbuch
7.4.1 NodeSymbolTypes
In unserem Alphabet fur Petrinetze gibt es zwei NodeSymbolTypes: eine Stelle
und eine Transition. Am Beispiel einer Stelle soll hier die Erstellung eines Node-
SymbolTypes beispielhaft erklart 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 dazugehorigen 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 NodeSymbolTy-
pe ubergeben. Danach wird eine Figur (ShapeFigure) fur diese Stelle erzeugt,
indem dem Konstruktor der NodeSymbolType, zu dem die ShapeFigure gehort,
ubergeben wird. Danach konnen visuelle Eigenschaften wie Farbe, Große und
Art der Figur (vgl. Abb. 7.2) festgelegt werden.
7.4.2 AttributeTypes
Wie eben erwahnt, hat eine Stelle zwei Attribute (einen Name und die An-
zahl der Tokens), die im Alphabet durch die Klasse AttributeType und deren
grafische Darstellung durch die Klasse TextFigure ausgedruckt werden. In Ab-
7.4 Alphabetdefinition fur Petrinetze 65
Abbildung 7.3: Definition eines Attributes und dessen Defintion der grafischenReprasentation
bildung 7.3 ist die Definition eines Attributes fur die Anzahl der Tokens zu
sehen. Dazu muss die Methode createAttributeType(String,String) an einem de-
finierten NodeSymbolType, in unserem Beispiel place, aufgerufen werden. Der
Methode mussen zwei Parameter ubergeben werden: einen Datentyp (Integer,
Float, String, ...) und einen Namen fur dieses Attribut. In unserem Beispiel
sind das Integer und tokens. Die Visualisierung eines Attributs im Editor wird
uber dessen Figur (TextFigure) geregelt, die beim Erzeugen des Attributes stan-
dardmaßig leer ist und nun noch mit Werten gefullt werden muss. Das sind ein
Name, eine Schriftart, deren Schriftfarbe und die Sichtbarkeit definiert werden.
Die Definition weiterer Attribute erfolgt analog.
Im nachsten Abschnitt wird naher 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
66 Benutzerhandbuch
(siehe Abb. 7.4). Dies geschieht in unserem Alphabet uber die Klasse Layout-
Constraint, die bereits eine Aufzahlung an moglichen Ausrichtungsmoglichkei-
ten beihaltet: INSIDE, LEFT, RIGHT, BOTTOM, ABOVE, UNDEFINED.
Der Konstruktor der Klasse LayoutConstraint erwartet drei Parameter:
1. eine Text- oder ShapeFigure, die bezuglich einer anderen ShapeFigure
ausgerichtet werden soll
2. die ShapeFigure, an der andere Figuren ausgerichtet werden sollen
3. die Art des LayoutConstraint
Fur das Beispiel in Abbildung 7.4 bedeutet dies, dass die tokenFigure sich in-
nerhalb der placeFigure befindet. Durch den Konstruktor wird auch die Lese-
richtung widergespiegelt: der erste Parameter befindet sich ’Wert des Layout-
Constraints’ zum zweiten Parameter.
Nachdem das LayoutConstraint festgelegt wurde, wird es an der Figur hinzu-
gefugt, die als erster Parameter im Konstruktor der Klasse LayoutConstraint
auftaucht.
7.4.3 EdgeSymbolTypes
Nachdem NodeSymbolTypes fur das Alphabet erstellt worden sind, kann
mit der Erzeugen von EdgeSymbolTypes fortgefahren werden, die dann
uber LinkTypes (vgl. Kap. 7.4.4) 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. Fur die Connection (die grafische Reprasentation) mussen dann noch
ein Name, die Linienfarbe, Linienstarke und die Linienart definiert werden.
Die Referenz auf die Connection wird uber die Methode getConnection()
eines EdgeSymbolTypes geholt. Fur die Linienart gibt es bereits vordefinierte
Konstanten: glatt (Connection.PLAIN), gestrichelt (Connection.DASHED)
und gepunktet (Connection.DOTTED).
7.4 Alphabetdefinition fur Petrinetze 67
Abbildung 7.5: Erstellung eines EdgeSymbolTypes und dessen Erstellung einergrafischen Darstellung
Fur EdgeSymbolTypes konnen ebenfalls AttributeTypes definiert werden, de-
ren TextFigures dann mit Hilfe von ConnectionConstraints an der Connection
ausgerichtet werden mussen. Die Erstellung von AttributeTypes erfolgt analog
zu den NodeSymbolTypes wie in Kapitel 7.4.2 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.
7.4.4 LinkTypes
In unserem Alphabet dienen LinkTypes dazu, NodeSymbolTypes und Edge-
SymbolTypes zumindest in der ersten Ausbaustufen miteinander zu verbinden.
Spater konnen auch zwei NodeSymbolTypes uber einen LinkType miteinander
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 eingefugt 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 createLinkTy-
pe(SymbolType,SymbolType) aus dem Alphabet erzeugt werden. Der erste Sym-
bolType ist der EdgeSymbolType und das zweite der NodeSymbolType. Fur die
LinkTypes kann noch ein LinkLayout festgelegt werden. Fur 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.
7.4.5 Speichern des Alphabets
Fur 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.
7.5 Erstellung der Grammatikregeln fur Petrinetze 69
Die Graphgrammatik wird im AGG eigenen Format als *.ggx Datei abgespei-
chert.
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 befin-
det. Ein komplette Alphabetspezifikation fur 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 fur Petri-
netze
Beim Abspeichern des Alphabets werden gleichzeitig eine Graphgrammatikda-
tei (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).
Fur 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 Re-
geln besteht zunchst in der Definition eines Typgraphen. Fur alle NodeSym-
70 Benutzerhandbuch
bolTypes, die spater auf der Editorflache bewegt werden sollen, mussen 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 ei-
nem Verzeichnis befinden.
Danach muss der New-Wizard uber New > Other > TIGER-Editor Generator
Abbildung 7.9: Wizard zum Start des Generators
aufgerufen werden, in dem dann der Eintrag ’TIGER – Editor Generator’ aus-
zuwahlen ist. Darauffolgend ist der in Abb. 7.9 zu sehen, in dem ein Projektna-
me, der Ort der Alphabetspezifikation und eine eigene Dateiendung angegeben
7.7 Start des Editors 71
werden mussen. Durch Drucken auf den Finish Button wird der Generierungs-
prozess 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
uber einen Wizard (siehe Abb. 7.10), der mit New > Other > Tiger Editor Crea-
tion 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 ausgewahlt werden oder ein Name fur 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. Desweite-
ren wird ein Vorschlag fur einen Dateinamen gegeben mit der selbstdefinierten
Endung aus dem Generator-Wizard.
72 Benutzerhandbuch
7.7.1 Aufbau des Editors
An dieser Stelle soll der Aufbau des Editors kurz beschrieben werden. Auf
Abbildung 7.11: Der generierte Petrinetzeditor
der linken Seite ist die Palette zu finden, in der Eintrage zum Erzeugen von
NodeSymbolTypes und EdgeSymbolTypes zu finden sind. Auf der rechten Seite
ist die Zeichenflache zu finden, auf der ein oder mehrere Petrinetze gezeichnet
werden konnen. Die angezeigten Regeln im Kontextmenu sind abhangig vom
selektierten Objekt. In Abb. 7.11 ist das Kontextmenu fur eine selektierte Stelle
zu sehen. Es kann eine Transition inklusive einer ArcPT, diese Stelle mit der
anknupfenden ArcTP oder die Stelle bearbeitet werden. Fur die eben genannten
Operationen gibt es naturlich entsprechende Regeln in der Graphgrammatik.
7.7 Start des Editors 73
interne Struktur
In diesem Unterabschnitt die Paketstruktur und deren Inhalt des generierten
Editors kurz dargelegt werden.
• petrieditor.actions, petrieditor.commands: Aufruf der einzelnen Re-
geln zur Durchfuhrung der Editieroperationen. Erzeugung von Kontext-
menueintragen.
• petrieditor.editparts: Controller fur jeden SymbolType
• petrieditor.editpolicy: Registrierung der einzelnen Klassen aus dem pe-
trieditor.command Package bei den Controllern
• petrieditor.figure: Je eine Klasse fur ShapeFigure bzw. Connection
• petrieditor.editor: Definition der Editorhauptklasse (MultipageEditor)
und Klassen, die die Hauptklasse mit GEF verbinden
• petrieditor.model: Hilfsklassen zur Erledigung von internen Aufgaben
74 Benutzerhandbuch
Literaturverzeichnis
[AGG] AGG Homepage. http://tfs.cs.tu-berlin.de/agg.
[BHK03] Marc Born, Eckhardt Holz, and Olaf Kath. Softwareentwicklung mit
UML 2. Addision-Wesley, 2003.
[Dia] Diagen – the diagram editor generator. Available at http://
www2-data.informatik.unibw-muenchen.de/DiaGen/.
[Ecl03] Eclipse Platform Technical Overview, 2003. Available at http://
www.eclipse.org/whitepapers/eclipse-overview.pdf.
[Ecl05] Eclipse Consortium. Eclipse – Version 3.1M4, 2005. Available at
http://www.eclipse.org.
[EEHT04] K. Ehrig, C. Ermel, S. Hansgen, and G. Taentzer. Towards Graph
Transformation based Generation of Visual Editors using Eclipse. In
M. Minas, editor, Visual Languages and Formal Methods, 2004. to
appear in ENTCS.
[Emf] Editor modeling framework. Available at www.eclipse.org/emf.
[GEF] Graphical editor framework. Available at www.eclipse.org/gef.
[Her03] Jack Herrington. Code Generation in Action. Hanning, 2003.
[Jav] Java sdk – version 5.0. Available at java.sun.com.
[Lam04] L. Lambers. A New Version of GTXL: An Exchange Format for Graph
Transformation Systems. In T. Mens, A. Schurr, and G. Taentzer, edi-
75
76 LITERATURVERZEICHNIS
tors, Proc. Workshop on Graph-Based Tools (GraBaTs’04), Satellite
Event of ICGT’04, 2004. to appear in ENTCS.
[Oes04] Bernd Oestereich. Die UML 2.0 Kurzreferenz fur die Praxis. Olden-
bourg, 2004.
[Omo] Eclipseumlstudio von omondo. Available at http://www.omondo.
de/.
[Pop04] Remko Popma. JET Tutorial Part 1 (Introduction to JET), JET
Tutorial Part 2 (Write Code that Writes Code), 2004. Available at
http://www.eclipse.org/articles.
[UML04] UML – version 2.0, 2004. Available at http://www.omg.org/uml.
[W3C99] W3C. XML, 1999. Available at http://www.w3c.org/xml.
Anhang A
Alphabet fur Petrinetze
// create a new vlspec for Place/Transition nets
VLspec vlspec = new VLspec("PetriNet");
Alphabet alphabet = vlspec.getAlphabet();
//------ begin of abstract part -------------
// create a NodeSymbolType for Places
NodeSymbolType place = alphabet.createNodeSymbolType("Place");
AttributeType token = place.createAttributeType("String", "token");
AttributeType plname = place.createAttributeType("String", "name");
// create a NodeSymbolType for Transitions
NodeSymbolType transition = alphabet.createNodeSymbolType("Transition");
AttributeType trname = transition.createAttributeType("String","name");
// create an EdgeSymbolType for ArcPT (a connection between Places and Transitions)
EdgeSymbolType arcPT = alphabet.createEdgeSymbolType("ArcPT");
AttributeType arcPTinscr = arcPT.createAttributeType("Integer","arcPTinscr");
// create an EdgeSymbolType for ArcTP (a connection between Transitions and Places)
EdgeSymbolType arcTP = alphabet.createEdgeSymbolType("ArcTP");
77
78 Alphabet fur Petrinetze
AttributeType arcTPinscr = arcTP.createAttributeType("Integer","arcTPinscr");
// create a LinkType source from ArcPT to Place
LinkType arcPTsource = alphabet.createLinkType(arcPT, place,"arcPTsource");
// create a LinkType target from ArcPT to Transition
LinkType arcPTtarget = alphabet.createLinkType(arcPT, transition,"arcPTtarget");
// create a LinkType source from ArcTP to Transition
LinkType arcTPsource = alphabet.createLinkType(arcTP, transition,"arcTPsource");
// create a LinkType target from ArcTP to Place
LinkType arcTPtarget = alphabet.createLinkType(arcTP, place,"arcTPtarget");
//------ end of abstract part -------------
//------ begin of concrete part -------------
//--------------- concrete Layout for NodeSymbolTypes ------------------
// define ShapeFigure "placeFigure"
ShapeFigure placeFigure = new ShapeFigure(place);
placeFigure.setName("placeFigure");
placeFigure.setShape("Circle");
placeFigure.setBorderColor(Color.black);
placeFigure.setFillColor(Color.white);
placeFigure.setDefaultSize(new Dimension(20, 20));
placeFigure.setDefaultSize(new Dimension(60, 60));
place.addShapeFigure(placeFigure);
// TextFigure "tokenFigure" for the AttributeType "token"
TextFigure tokenFigure = token.getTextFigure();
tokenFigure.setName("tokenFigure");
79
tokenFigure.setFont(new Font("Serif", Font.PLAIN, 14));
tokenFigure.setFontColor(Color.black);
tokenFigure.setVisibility(true);
//TextFigure "plnameFigure" for the AttributeType "name"
TextFigure plnameFigure = plname.getTextFigure();
plnameFigure.setName("plnameFigure");
plnameFigure.setFont(new Font("Serif", Font.PLAIN, 14));
plnameFigure.setFontColor(Color.black);
plnameFigure.setVisibility(true);
// LayoutConstraint for the "tokenFigure" being put inside the "placeFigure"
LayoutConstraint tokenInPlace = new LayoutConstraint(tokenFigure,
placeFigure, LayoutConstraint.INSIDE);
tokenFigure.addLayoutConstraint(tokenInPlace);
// LayoutConstraint for the "plnameFigure" being put below the "placeFigure"
LayoutConstraint plnameAbovePlace = new LayoutConstraint(
plnameFigure, placeFigure, LayoutConstraint.BELOW);
plnameFigure.addLayoutConstraint(plnameAbovePlace);
// define ShapeFigure "transitionFigure"
ShapeFigure transitionFigure = new ShapeFigure(transition);
transitionFigure.setName("transitionFigure");
transitionFigure.setShape("RectangleFigure");
transitionFigure.setBorderColor(Color.black);
transitionFigure.setFillColor(Color.white);
transitionFigure.setDefaultSize(new Dimension(30, 20));
transition.addShapeFigure(transitionFigure);
// TextFigure "trnameFigure" for the AttributeType "trname"
TextFigure trnameFigure = trname.getTextFigure();
80 Alphabet fur Petrinetze
trnameFigure.setName("trnameFigure");
trnameFigure.setFont(new Font("Serif", Font.PLAIN, 14));
trnameFigure.setFontColor(Color.black);
trnameFigure.setVisibility(true);
// LayoutConstraint for the "trnameFigure" being put above the "transitionFigure"
LayoutConstraint trnameInTransition = new LayoutConstraint(
trnameFigure, transitionFigure, LayoutConstraint.ABOVE);
trnameFigure.addLayoutConstraint(trnameInTransition);
//--------------- concrete Layout for EdgeSymbolTypes ------------------
// define a Connection "arcPTConnection" for an "arcPT"
Connection arcPTConnection = arcPT.getConnection();
arcPTConnection.setName("arcPTConnection");
arcPTConnection.setStrokeColor(Color.black);
arcPTConnection.setStrokeWidth(1);
arcPTConnection.setStrokeStyle(Connection.PLAIN);
// TextFigure "arcPTinscrFigure" for the AttributeType "arcPTinscr"
TextFigure arcPTinscrFigure = arcPTinscr.getTextFigure();
arcPTinscrFigure.setName("arcPTinscrFigure");
arcPTinscrFigure.setFont(new Font("Serif", Font.PLAIN, 14));
arcPTinscrFigure.setFontColor(Color.black);
arcPTinscrFigure.setVisibility(true);
// ConnectionConstraint for ArcPT inscription (at center of arc)
ConnectionConstraint arcPTinscrAtCenterArcPT = new ConnectionConstraint(
arcPTinscrFigure, arcPTConnection,
ConnectionConstraint.AT_CENTER);
arcPTConnection.addConnectionConstraint(arcPTinscrAtCenterArcPT);
// define a Connection "arcTPConnection" for an "arcTP"
81
Connection arcTPConnection = arcTP.getConnection();
arcTPConnection.setName("arcTPConnection");
arcTPConnection.setStrokeColor(Color.black);
arcTPConnection.setStrokeWidth(1);
arcTPConnection.setStrokeStyle(Connection.PLAIN);
// TextFigure "arcTPinscrFigure" for the AttributeType "arcTPinscr"
TextFigure arcTPinscrFigure = arcTPinscr.getTextFigure();
arcTPinscrFigure.setName("arcTPinscrFigure");
arcTPinscrFigure.setFont(new Font("Serif", Font.PLAIN, 14));
arcTPinscrFigure.setFontColor(Color.black);
arcTPinscrFigure.setVisibility(true);
// ConnectionConstraint for ArcTP inscription (at center of arc)
ConnectionConstraint arcTPinscrAtCenterArcTP = new ConnectionConstraint(
arcTPinscrFigure, arcTPConnection,
ConnectionConstraint.AT_CENTER);
arcTPConnection.addConnectionConstraint(arcTPinscrAtCenterArcTP);
//--------------- concrete Layout for LinkTypes ------------------
// LinkLayout for "arcPTtarget"
LinkLayout arcPTtargetLinkLayout = arcPTtarget.getLinkLayout();
PolygonDecoration trianglePT = new PolygonDecoration();
arcPTtargetLinkLayout.setMarker(trianglePT);
arcPTtargetLinkLayout.setBorderColor(Color.black);
arcPTtargetLinkLayout.setFillColor(Color.black);
// LinkLayout for "arcTPtarget"
LinkLayout arcTPtargetLinkLayout = arcTPtarget.getLinkLayout();
PolygonDecoration triangleTP = new PolygonDecoration();
arcTPtargetLinkLayout.setMarker(triangleTP);
arcTPtargetLinkLayout.setBorderColor(Color.black);
82 Alphabet fur Petrinetze
arcTPtargetLinkLayout.setFillColor(Color.black);