Stefan H ansgen - TU Berlin · OCL (Einschr ankungen fur de nierte Modelle) Diagrammaustauschformat (UML-Austauschformat f ur Diagram-maustausch zwischen verschiedenen Tools) Um die

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


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


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


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.


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


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


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.


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


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-


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


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-


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.


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.


• *.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.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


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


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.


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-


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).


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();


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);


arcTPtargetLinkLayout.setFillColor(Color.black);

Documents

Stefan H ansgen - TU Berlin · OCL (Einschr ankungen fur de nierte Modelle) Diagrammaustauschformat (UML-Austauschformat f ur Diagram-maustausch zwischen verschiedenen Tools) Um die