Konzeption und Implementierung eines Generators fur

Konzeption und Implementierung eines

Generators fur Animationsumgebungen

fur visuelle Modellierungssprachen

Karsten Ehrig

Diplomarbeit

an der Fakultat fur Elektrotechnik und Informatik

der Technischen Universitat Berlin

Gutachter: Prof. Dr. H. Ehrig und Dr. G. Taentzer

3. September 2003

Zusammenfassung

In visuellen Modellen lassen sich mit Hilfe von anwendungsorientierten Sich-

ten ausgewahlte Verhaltensablaufe simulieren. Grundlage fur die Simulation ist

eine Simulationsgrammatik, welche diskrete Zustandsubergangsschritte im vi-

suellen Modell (z.B. Petri-Netz) definiert.

Ziel der Diplomarbeit ist die Konzeption und Implementierung einer Anima-

tionskomponente, welche Animationsablaufe auf der Basis von Simulationsre-

geln mittels Graphtransformationen generiert. In dieser Komponente sollen die

diskreten Zustandsubergangsschritte zu kontinuierlichen Animationsablaufen in

einem Szenario-Layout erweitert werden. Mehrere Animationsablaufe konnen

dann sowohl einzeln als auch parallel in einem SVG-Viewer dargestellt werden.

Bestandteil der Diplomarbeit ist ein konkretes Anwendungsszenario zur Ani-

mation von Petrinetzen.

Der Diplomarbeit liegt eine CD-ROM bei, welche das komplette GenGED

Programmsystem mit Dokumentation und Installationsanleitung enthalt.

Die selbstandige und eigenhandige Anfertigung

dieser Diplomarbeit versichere ich an Eides statt.

Berlin, den 3. September 2003

Unterschrift

Danksagung

Mein Dank gilt den Betreuern Frau Dipl.-Inf. Claudia Ermel und Frau Dr. Ing.

Gabi Taentzer fur die liebevolle Betreuung und konstruktive Unterstutzung.

Außerdem mochte ich mich bei Herrn Dipl.-Inf. Ingo Weinhold, Frau Dr.

Ing. Rosi Bardohl und Frau Dipl.-Inf. (FH) Olga Runge fur die zahlreichen

Hilfestellungen bezuglich der Konzeption und Implementierung des GenGED

und AGG Systems bedanken.

Desgleichen mochte ich meiner Familie fur deren Unterstutzung danken.

Inhaltsverzeichnis

1 Einleitung 1

2 Grundlagen 3

2.1 Visuelle Sprache . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 GenGED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Visuelles Alphabet . . . . . . . . . . . . . . . . . . . . . 5

2.2.2 Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.3 Syntax Grammatik . . . . . . . . . . . . . . . . . . . . . 7

2.2.4 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.5 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.6 AGG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.7 ParCon . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.1 Animationselemente . . . . . . . . . . . . . . . . . . . . 13

2.3.2 SVG-Viewer . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Konzeption 17

3.1 Ziel der Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Anforderungen an den Animationsgenerator . . . . . . . . . . . 17

ii INHALTSVERZEICHNIS

3.3 Konzeption eines effizienten Layouters fur die GenGED Umge-

bung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4 Konzeption der Animationsgenerierung . . . . . . . . . . . . . . 20

3.4.1 Animationsregeleditor . . . . . . . . . . . . . . . . . . . 20

3.4.2 Animationsumgebung . . . . . . . . . . . . . . . . . . . . 21

3.4.3 Eigenstandige Animationskomponente . . . . . . . . . . 22

3.4.4 Schnittstelle zwischen der Animationsumgebung und der

eigenstandigen Animationskomponente . . . . . . . . . . 23

3.4.5 Generierung eines kontinuierlichen Animationsablaufes in

der GenGED Umgebung . . . . . . . . . . . . . . . . . 23

3.4.6 Anwendung auf Petrinetze . . . . . . . . . . . . . . . . . 25

3.4.7 VL-Umgebung in GenGED . . . . . . . . . . . . . . . 25

4 Entwurf 29

4.1 Ablauf der Animationserstellung . . . . . . . . . . . . . . . . . . 30

4.2 GenGED Layouter . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Animationsregeleditor . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.1 Animationsregel . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.2 Definition einer Animationsoperation . . . . . . . . . . . 35

4.3.3 Baummodell . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.4 Zeitleiste . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3.5 Animationsregelspezifikation . . . . . . . . . . . . . . . . 40

4.4 VL-Spezifikationseditor . . . . . . . . . . . . . . . . . . . . . . . 42

4.4.1 Animationsschrittdefinition . . . . . . . . . . . . . . . . 43

4.4.2 Animationsausdruck . . . . . . . . . . . . . . . . . . . . 47

4.5 VL-Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48


INHALTSVERZEICHNIS iii

4.5.2 Simulation als Basis fur die Animation . . . . . . . . . . 51

4.5.3 Auswertung der Animationsoperationen . . . . . . . . . 52

4.6 Eigenstandige Animationskomponente . . . . . . . . . . . . . . 53

4.6.1 Animationsgenerierung . . . . . . . . . . . . . . . . . . . 54

4.6.2 SVG-Animationsdatei . . . . . . . . . . . . . . . . . . . 55

5 Implementierung 59

5.1 Paketstruktur und -versionen . . . . . . . . . . . . . . . . . . . 59

5.2 Grafische Benutzerschnittstellen . . . . . . . . . . . . . . . . . . 61

5.2.1 Animationsregeleditor . . . . . . . . . . . . . . . . . . . 62

5.2.2 VL-Spezifikationseditor . . . . . . . . . . . . . . . . . . . 64


5.3 GenGED Layouter fur Petrinetze . . . . . . . . . . . . . . . . . 66

5.4 Eigenstandige Animationskomponente . . . . . . . . . . . . . . 67

6 Benutzerhandbuch 69

6.1 Installation und Start . . . . . . . . . . . . . . . . . . . . . . . . 69

6.1.1 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . 70

6.1.2 Ubersetzen des Quellcodes . . . . . . . . . . . . . . . . . 70

6.1.3 Programmstart . . . . . . . . . . . . . . . . . . . . . . . 71

6.2 Ablauf der Animationserstellung . . . . . . . . . . . . . . . . . . 71

6.3 Animationsregeleditor . . . . . . . . . . . . . . . . . . . . . . . 72

6.3.1 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.3.2 Definition von Animationsoperationen . . . . . . . . . . 75

6.4 VL-Spezifikationseditor . . . . . . . . . . . . . . . . . . . . . . . 76

6.4.1 Animationsausdruck . . . . . . . . . . . . . . . . . . . . 77

6.5 Animationsumgebung . . . . . . . . . . . . . . . . . . . . . . . . 79

iv INHALTSVERZEICHNIS

7 Ergebnisse und Ausblick 83

7.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Literaturverzeichnis 86

Kapitel 1

Einleitung

Zu animieren bedeutet, etwas zum Leben zu erwecken. [FvDFH97]

Lebendige Ablaufe werden vom Betrachter durch Fusion von Bildsequen-

zen wahrgenommen, welche zusammen einen kontinuierlichen Ablauf ergeben.

Grundlage fur die Animation sind diskrete Bildfolgen, vergleichbar mit Fotogra-

fien eines Szenarios, in bestimmten Zeitintervallen. Eine Animation entsteht,

wenn der Zeitraum zwischen zwei Bildern einer diskreten Bildsequenz durch

einen dynamischen Ablauf erganzt wird. Dies geschieht, indem Zwischenbilder

generiert werden, welche zusammen mit dem diskreten Anfangs- und Endbild

einen kontinuierlichen Ablauf ergeben. Der Ablauf wird dann als kontinuierlich

von Betrachter wahrgenommen, wenn das menschliche Auge nicht mehr in der

Lage ist, zwischen den einzelnen Bildern zu differenzieren.

Die Animation ist nicht nur auf die Modellierung eines Bewegungsablaufes

beschrankt: Anderung der Form, der Farbe oder der Struktur eines grafischen

Objektes konnen ebenfalls animiert werden.

Die Geschichte der Animation begann mit der Hohlenmalerei ca. 20.000 Jah-

re vor unserer Zeit: Arme und Beine von Tieren und Menschen wurden mehr-

fach gezeichnet und deuteten eine Bewegung an. Zu Beginn des 19. Jahrhun-

derts wurden Bilder auf Scheiben positioniert. Wenn die Scheiben entsprechend

schnell gedreht wurden, konnte der Betrachter die Bilder nicht mehr einzeln

wahrnehmen und es entstand ein kontinuierlicher Ablauf. Das gleiche Prinzip

2 Einleitung

liegt dem klassischen Filmprojektor zugrunde, wobei auch hier dem Betrachter

in schneller Abfolge Bildsequenzen vorgefuhrt werden.

Großere Bedeutung kam der Animation mit dem Beginn des Computerzeital-

ters zu: Der Computer ermoglicht die Verarbeitung großer Datenmengen und die

Generierung von realitatsnahen Animationsablaufen. Als neue Anwendungsge-

biete ergeben sich hierdurch die Animation modellspezifischer Verhaltensweisen

zur Demonstration in Forschung und Lehre. Komplexe Ablaufe konnen in einem

animierten Szenario einem breiten Publikum verstandlich gemacht werden.

Beispielsweise konnte der Produktionsablauf einer ‘Munzpragemaschine’

durch ein Modell veranschaulicht werden. Aus diesem Modell sind fur einen Be-

trachter die Komponenten der Munzpragemaschine ersichtlich. Nicht ersichtlich

ist allerdings aus dem Modell, wie der konkrete Ablauf einer Munzpragung ist.

Dieser wird erst durch die Animation des Modells verdeutlicht, indem z.B. der

Ablauf der Munzpragung vom Rohling bis zur fertigen Munze animiert wird.

In diesem Fall ergibt sich eine anwendungsorientierte Sicht (Szenario-

View) eines abstrakten Verhaltensmodells (Behavior-Model). Das ab-

strakte Modell kann dabei das Verhalten der Munzpragemaschine mit Hilfe

von formalen Spezifikationstechniken (z.B. mit Petrinetzen) modellieren.

Ermel und Bardohl haben in [EB03] konzipiert, wie das Verhaltensmodell kon-

zistenzbewahrend in verschiedene anwendungsorientierte Sichten uberfuhrt und

dort animiert werden kann. Animation bedeutet hierbei eine Simulation im

sichtspezifischen Layout.

In der Literatur existieren bereits mehrere Arbeiten zur 3D-Visualisierung

und Animation von Petrinetzen [Kat98, KP03, RS95]. Die Softwarevisualisie-

rung in Form von Programmanimationen und Algorithmenanimationen (z.B.

von Sortieralgorithmen) gewinnt in der Softwareentwicklung an zunehmender

Bedeutung [Die03].

Kapitel 2

Grundlagen

Im folgenden werden die grundlegenden Konzepte von visuellen Modellie-

rungstechniken erlautert, welche die Grundlage fur einen Generator fur

Animationsumgebungen darstellen.

2.1 Visuelle Sprache

Eine visuelle Sprache ‘Visual Language (VL)’ ist eine Sprache uber einem vi-

suellen Alphabet, welches aus Symbolen und Verknupfungen besteht. Die Sym-

bolen konnen dabei sowohl bildliche als auch textuelle Bestandteile beinhalten.

Zu den visuellen Modellierungssprachen gehoren die Unified Mo-

delling Language (UML) [UML02], Petrinetze [Rei82], Statecharts, Entity-

Relationship-Diagramme und Graphtransformationssysteme. Mit der UML las-

sen sich strukturelle und verhaltensorientierte Aspekte von objektorientierten

Softwaresystemen beschreiben. Hierzu stellt die UML verschiedenste Model-

lierungstechniken zu Verfugung, wie z.B. Klassendiagramme und Sequenzdia-

gramme. Die abstrakte Syntax von UML ist in [UML02] beschrieben. Aller-

dings existieren auf semantischer Ebene bislang nur informelle Beschreibungen.

Aus diesem Grund bietet es sich an, Petrinetze als formale visuelle Modellie-

rungssprache zu benutzen, welche auf syntaktischer und semantischer Ebene

prazise definiert ist. Hierbei besteht ein formaler Zusammenhang zwischen Pe-

trinetzen und Graphgrammatiken, welcher als Basis fur eine Animationssicht in

4 Grundlagen

GenGED verwendet werden kann [BEP02]. Statecharts und Graphtransforma-

tionssysteme bieten ebenfalls formale Ansatze, die hier nicht naher betrachtet

werden sollen.

Eine visuelle Sprache besteht aus einem visuellen Alphabet, welches auf ab-

strakter Ebene eine Menge von visuellen Symbolen und Verknupfungen zwischen

diesen definiert. Weiterhin konnen Regeln die Menge der erlaubten visuellen

Diagramme uber dem visuellen Alphabet einschranken, so dass nur sinnvolle

Diagramme erzeugt werden konnen. Die Regeln werden zu einer Grammatik

uber dem visuellen Alphabet zusammengefasst. Ein visuelles Modell besteht

aus einer Menge von VL Diagrammen, welche z.B. wahrend einer Animation

die verschiedenen Zustande eines Systems reprasentieren konnen.

Visuelle Sprachen lassen sich auch deskriptiv beschreiben, wie z.B. UML

durch das UML-Metamodell.

2.2 GenGED

Mit GenGED [BEWE03] wurde eine Technik und ein Werkzeug an der TU-

Berlin entwickelt, welches automatisch zu einer gegebenen visuellen Sprache eine

visuelle Umgebung generiert, um visuelle Modelle zu erstellen, zu editieren, zu

parsieren und zu simulieren [Bar00, Sch99, Nie99, Wei01, BEE+02]. Der Ablauf

zur Erstellung einer visuellen Spezifikation mit der GenGED Umgebung ist in

Abb. 2.1 dargestellt.

Alphabet

Syntax Grammar

Simulation Grammar

Parse Grammar 0−1

0−1

VL−SpecificationParse Specification

*Simulation Specification

Abbildung 2.1: GenGED Umgebung

Ausgangspunkt in GenGED ist die visuelle Definition eines visuellen Alpha-

bets. Uber dem Alphabet kann eine Syntax-, Parsierungs und Simulationsgram-

2.2 GenGED 5

matik definiert werden. Die Simulationsgrammatik stellt dabei die grundlegen-

den Regeln fur diskrete Zustandsubergange im visuellen Modell bereit (siehe

Kap. 2.2.4).

2.2.1 Visuelles Alphabet

In Abb. 2.2 ist die visuelle Definition eines visuellen Alphabets in GenGED

am Beispiel eines Alphabetes fur Stellen-Transitions-Netze ‘Place Transition

Net (P/T-Net)’ dargestellt [EBE01].

Das Alphabet besteht aus einer abstrakten und einer konkreten Syntax:

Die abstrakte Syntax ist ein Graph und definiert mit Symbolen (Rechtecke in

Abb. 2.2) und Verknupfungen zwischen den Symbolen (Pfeile) den logischen

Teil eines Alphabets. Das Layout des Alphabets wird in der konkreten Syn-

tax durch grafische Symbole und Link-Constraints definiert, wobei die Link-

Constraints die Anordnung der grafischen Symbole definieren. Es besteht eine

eindeutige Zuordnung von abstrakten Syntaxelementen zu konkreten Synta-

xelementen, welche durch gestrichelte Pfeile in Abb. 2.2 angedeutet ist. Zur

Vereinfachung wurden die Kantenbeschriftungen von Stellen-Transitionsnetzen

nicht mit in das Alphabet aufgenommen.

Transition

String

ArcTP

Place

String

pn

spt ArcPT

stp

tpt

ttptok

ConcreteSyntax

AbstractSyntax TrNamePlName

tn

aop

Token

aop

String,12pt,HelveticaString,12pt,Helvetica

Abbildung 2.2: Alphabet fur Stellen-Transitions-Netze[EBE01]

6 Grundlagen

2.2.2 Diagramm

Ein Beispiel fur ein Diagramm uber dem Petrinetz Alphabet in konkreter Syntax

ist das in der Literatur weit verbreitete ‘Producer-Consumer-System’ (Abb. 2.3).

produce

deliverready to

deliverfilled

buffer

emptybuffer

removeconsume

ready toconsume

removeready to

produceready to

Abbildung 2.3: Producer-Consumer-System [EBE01]

Abb. 2.3 stellt dabei die Ausgangssituation dar. Durch schalten der Transition

‘produce’ wird der Token von der Stelle ‘ready to produce’ entfernt und auf die

Stelle ‘ready to deliver’ gelegt. Eine Simulation (siehe Kap. 2.2.4) wurde genau

diesen konkreten Zustandsubergang demonstrieren, indem der Token von der

einen Stelle zur anderen springt. Bei der Animation (siehe Kap. 2.2.5) hingegen

fuhrt der Token eine kontinuierliche Bewegung uber die Transition ‘produce’

aus, so dass dem Betrachter das Schaltverhalten des Petrinetzes in anschaulicher

Weise vermittelt wird.

Das Petri-Netz-Diagramm in GenGED fur einen Ausschnitt des Producer-

Consumer-Systems ist in Abb. 2.4 dargestellt.

In Abb. 2.4 sind die Verknupfungen zwischen abstrakter GenGED Syntax,

als Satz uber dem GenGED Alphabet in Abb. 2.2 und einem Ausschnitt der

konkreten Syntax aus Abb. 2.3 mit gestrichelten Pfeilen dargestellt.

2.2.3 Syntax Grammatik

Das Editieren von Diagrammen wird durch die Anwendung von Syntax-Regeln

realisiert. Syntax-Regeln sind Graphregeln zu einem Alphabet, die das Einfugen

2.2 GenGED 7

ArcPT

Transition

ArcTP

Place

ArcPT

ArcTP

Place

Transition

ready to

TrName TrName

PlName

PlName

deliver

SyntaxAbstract

SyntaxConcrete

deliverproduce

ready toproduce

Token

Abbildung 2.4: Diagramm uber dem Stellen-Transitions-Netz-Alphabet [EBE01]

bzw. Modifizieren von Symbolen in ein Diagramm spezifizieren. Eine Graphre-

gel besteht aus einer linken Seite ‘L’ und einer rechten Seite ‘R’. Sie beschreibt,

dass bei Anwendung dieser Regel auf ein Diagramm der Teil des Diagramms,

der mit der linken Seite ‘L’ matcht, in die rechte Seite transformiert wird. Die

Graphtransformationsalgorithmen werden dabei vom externen Tool AGG (sie-

he Kap. 2.2.6) bereitgestellt.

Abb. 2.5 zeigt eine Syntax Grammatik fur die Sprache der Stellen-Transitions-

Netze, welche auf dem Alphabet fur Stellen-Transitions-Netze beruht (siehe

Abb. 2.2). Der Startsatz der Syntax Grammatik ist leer. Die erste Regel fugt

eine Stelle mit Stellennamen ein. Die NAC (Negative Application Condition)

schrankt die Regel insofern ein, dass die einzufugende Stelle mit dem jeweiligen

Stellennamen vor der Regelanwendung nicht existieren darf. Die zweite Regel

fugt analog eine Transition ein. Die nachsten zwei Regeln fugen jeweils einen

Pfeil (Arc) zwischen eine Stelle und einer Transition (‘ArcPT’) bzw. zwischen

einer Transition und einer Stelle (‘ArcTP’) ein. Die letzte Regel fugt einen Token

in eine Stelle ein.

8 Grundlagen

addToken

PlName

Place

PlName

TrName TransTrName

RL

Place

Trans

Trans

ArcPT

ArcTPArcTP

Place

Trans

Place

Trans

tn

R

NAC

ArcPT

L R

Place

NAC

Trans

LNAC

NAC RL

insTrans(tn)

Place

Place

pn

Trans

pninsPlace(pn)

Place

RL

Place

Place

pn

pn

Token

tntntn

Trans

insArcPT

insArcTP

Abbildung 2.5: Syntax Grammatik fur die Sprache der Stellen-Transitions-Netze[EBE01]

Abb. 2.6 zeigt die Anwendung der Regel ‘InsArcPT’ auf ein Diagramm ‘G’ mit

dem Matchmorphismus ‘m’. Die Regel fugt einen Pfeil (‘ArcPT’) zwischen einer

Stelle und einer Transition ein, wodurch aus dem Diagramm ‘G’ das Diagramm

‘H’ entsteht.

Eine visueller Satz uber dem visuellen Alphabet der Stellen-Transitions-Netze

entsteht durch Anwendung der Regeln der Syntax Grammatik. Die Menge aller

auf diese Weise ableitbaren visuellen Satze bildet die visuelle Sprache (visual

2.2 GenGED 9

PlName

1:Token

2:Token

InsArcPT

m

TrName

p1t2

PlName

1:Token

2:Token

HG

RL

TrName

p1 t2

2:Transition1:Place

1:Place

1:Place

3:ArcPT

2:Transition

2:Transition

3:ArcPT

1:Place2:Transition

Abbildung 2.6: Anwendung der Regel ‘InsArcPT’ [EBE01]

language ‘VL’) der Stellen-Transitions-Netze.

2.2.4 Simulation

In der GenGED Umgebung wurde im Rahmen einer Diplomarbeit ein Ge-

nerator fur Simulationsumgebungen implementiert [Wei01]. Intention der

Simulation ist die Modellierung von dynamischem Verhalten eines Systems. Bei

Petrinetzen ist dies das Tokengame. Grundlage fur die Simulation ist eine Si-

mulationsgrammatik, welche diskrete Zustandsubergangsschritte im visuellen

Modell definiert.

In Abb. 2.7 ist eine Simulationsregel fur ‘produce’ angegeben. Simulationsre-

geln sind, wie auch die Syntaxregeln, Graphregeln zu dem visuellen Alphabet.

Die Menge der Simulationsregeln bildet die Simulationsgrammtik uber dem vi-

suellen Alphabet. Der Match ist eindeutig wegen der Einbettung und Eindeu-

10 Grundlagen

L R

produceproduce

Abbildung 2.7: Simulationsregel fur ‘produce’

tigkeit von Transitionsnamen. Die Simulationsregel ‘produce’ (s. Abb. 2.7) ist

daher nicht anwendbar auf das Diagramm (a), aber anwendbar auf das Dia-

gramm (b) in Abb. 2.8.

t

(a)

produce

(b)

Abbildung 2.8: Simulationsregel ‘produce’ nicht anwendbar auf Diagramm (a),aber anwendbar auf Diagramm (b)

2.2.5 Animation

Nachteil der Simulation ist, dass kein fließender Ubergang von einem Zustand in

den nachsten erfolgt. Diese Lucke soll durch die Animation in dieser Diplomar-

beit geschlossen werden. Bestandteil der Diplomarbeit ist daher die Erweiterung

der GenGED Umgebung um einen Generator fur Animationsumgebun-

gen.

Bezogen auf die Modellierung mit Stellen-Transitions-Netzen ergeben sich

dann folgende Moglichkeiten:

2.2 GenGED 11

• Das Tokengame bei Petrinetzen kann durch kontinuierliche Bewegung

der Token im Netz animiert werden. Hierzu muss ein gegebenes Pe-

trinetz zunachst in ein Graphtransformationssystem uberfuhrt werden.

Dies kann z.B. durch XML-Formattransformation [Ehr02] aus dem XML-

Austauschformat des Petri-Netz-Kerns [KW99] und einem gegebenen

GenGED Petri-Netz-Alphabet erfolgen.

• Das Verhalten von Petrinetzen kann in ein anwendungsspezifisches Lay-

out transformiert und dann animiert werden. Hierzu muss ein Layout des

Modells in einer anwendungsspezifischen Sicht (Application Do-

main) definiert werden [BEE+02]. Eine anwendungsspezifische Sicht des

Producer-Consumer-Systems, in der die Mutter ihrem Sohn einen Kuchen

backt (produce), ihn an ihren Sohn ausliefert (deliver), der Sohn den Ku-

chen vom Tisch aufnimmt (remove) und isst (consume), ist in Abb. 2.9

dargestellt.

produce

deliverremove

consume

Abbildung 2.9: Szenario Sicht des Producer-Consumer-Modells [EBE01]

2.2.6 AGG

GenGED benutzt den visuellen Interpreter fur attributierte Graphtransforma-

tion mit Integration von Java Programmen AGG [TRS03], welcher ebenfalls an

12 Grundlagen

der TU-Berlin entwickelt wurde [ERT99].

AGG ist eine universelle Graphtransformationsmaschine, welche in Java Ap-

plikationen eingebunden werden kann. Komplexe Datenstrukturen konnen als

Graphen modelliert werden, welche uber Typgraphen getypt werden konnen.

Das Verhalten eines Systems wird durch Graphregeln beschrieben, welche ne-

gative Anwendungsbedingungen (negativ application conditions (NACs)) bein-

halten konnen. Ein Graph wird durch die Anwendung einer Graphregel trans-

formiert. Dabei konnen Graphen beliebige Java Klassen als Attribute besitzen.

AGG stellt eine eigene visuelle Entwicklungsumgebung mit grafischen Edi-

toren fur Graphen und Graphregeln bereit. Ausserdem wird die visuelle Inter-

pretation und Validation unterstutzt.

Zur Zeit ist AGG in der Version 1.1.0 als Biblithek in GenGED inte-

griert. Dabei wird die Transformation und Parsierung von VL Diagrammen in

GenGED unterstutzt. Hierzu werden die GenGED Datenstrukturen in AGG

Datenstrukturen konvertiert, mit welchen die Transformation bzw. Parsierung

durchgefuhrt werden kann. Das transformierte Diagramm wird anschließend

wieder zuruckkonvertiert und der verwendete Match, Comatch und Morphis-

mus zur spateren Auswertung protokolliert.

2.2.7 ParCon

Zur Losung von grafischen Constraints benutzt GenGED den Constraintssol-

ver ParCon [Gri96]. ParCon wurde 1996 von Peer Griebel an der Universitat

Paderborn im Rahmen seiner Dissertation konzipiert und in der Programmier-

sprache C implementiert. Insbesondere wurde ParCon konzipiert zweidimen-

sionale grafische Constraints zu losen.

Zu Beginn werden ParCon alle beteiligten Constraints und eine initiale Va-

riablenbelegung ubergeben. Der Solver versucht dann das ‘Constraint Satisfac-

tion Problem (CSP)’ zu losen. Wird eine Losung gefunden, so gibt der Solver

die neue Variablenbelegung zuruck. Anschliessend konnen einzelne oder alle Va-

riablen neu belegt werden. Dabei wird nach dem ‘Least Astonishment’ Prinzip

gearbeitet, d.h. es wird versucht, zuerst alltere Variablen neu zu belegen. Aus-

2.3 SVG 13

serdem konnen Constraints unterschiedliche Prioritaten zugeordnet werden.

Leider hat sich das Losen von grafischen Constraints in GenGED zum Lay-

outen von grafischen Symbolen als zeitlich sehr ineffizient erwiesen, sodass fur

das Layouten von Petri-Netzen in GenGED andere Wege gefunden werden

mussten.

Ein weiteres Problem ist, dass ParCon die einzige Komponente des Gen-

GED Systems ist, welche nicht in Java implementiert ist. Weiterhin ist Par-

Con nur fur die Betriebssysteme Linux und Sun OS(TM) verfugbar, weshalb

das GenGED System bislang nur unter diesen Betriebssystemen lauffahig ist.

2.3 SVG

Da die Animation von grafischen Objekten bereits ein weit verbreitetes und

erforschtes Gebiet ist, bietet es sich an, auf ein bereits vorhandenes Format

zuruckzugreifen:

Eine Empfehlung des World-Wid-Web-Konsortiums ‘W3C’ ist das XML-

basierte grafische Austauschformat fur skalierbare Vektor-Grafiken SVG

[W3C01], welches unter anderem die Animation aller primitiven grafischen Ob-

jekte unterstutzt (z.B. Rechteck, Kreis, Ellipse, Linie, Text, Polygon, Bilder in

GIF- und JPEG-Format).

SVG ist eine Sprache, welche zweidimensionale Vektorgrakiken in XML

[WWW02] beschreibt. SVG erlaubt drei Typen von grafischen Objekten: vek-

torgrafische Objekte (welche aus Pfaden von Linien oder Kurven bestehen),

Bilder und Texte. Grafische Objekte konnen zu anderen grafischen Objek-

ten gruppiert und transformiert werden. SVG ist dynamisch und interaktiv:

Das Document Object Model (DOM) fur SVG erlaubt die Definition von

Animations-Elementen fur jedes grafische Objekt, welche den grafischen Objek-

ten dynamische Verhaltensweisen zuordnen. Dabei reagiert SVG interaktiv auf

Benutzeraktionen, indem z.B. Mauskoordinaten abgefragt werden.

14 Grundlagen

2.3.1 Animationselemente

Die Animationselemente unter SVG wurden in Kooperation mit der ‘W3C Syn-

chronized Multimedia (SYMM) Working Group’ entworfen, welche die ‘Syn-

chronized Multimedia Integration Language (SMIL) 1.0 Specification’ entwi-

ckelt haben [Hos98].

Die SYMM Arbeitsgruppe hat in Zusammenarbeit mit der SVG Arbeitsgrup-

pe die ‘SMIL Animation’ Spezifikation herausgegeben [SC00], welche universelle

Animationseigenschaften fur XML basierte Dokumente spezifiziert. SVG hat die

Animationseigenschaften der ‘SMIL Animation’ Spezifikation ubernommen und

einige SVG spezifische Eigenschaften hinzugefugt.

SVG stellt die folgenden vier Animationselemente bereit, welche in

der ‘SMIL Animation’ Spezifikation definiert sind [SC00]:

• ‘animate’ erlaubt skalaren Attribute und Eigenschaften verschiedene Wer-

te uber die Zeit zuzuorden. Um ein Objekt zu bewegen, reicht es beispiels-

weise aus, die ‘X’ und ‘Y’ Attribute der Objektposition uber die Zeit zu

verandern.

• ‘set’ ist ein vereinfachtes ‘animate’ Attribute, welches die Animationswer-

te von nicht nummerischen Attributen und Eigenschaften verandert. Als

Beispiel sei hier die ‘visibility’ Eigenschaft genannt, welche die Sichtbar-

keit eines Objektes beeinflusst.

• ‘animateMotion’ bewegt ein Element entlang eines Pfades, der analog der

SVG Pfad Definition zu spezifizieren ist. Mit dem Pfad-Ausdruck lassen

sich Objekte beispielsweise entlang einer Bezier-Kurve gewegen.

• ‘animateColor’ modifiziert den Farbwert von Objektattributen oder -

eigenschaften uber die Zeit.

Abb. 2.10 zeigt eine SVG-Animationsdatei, welche die Verwendung des ‘ani-

mate’ Elements zeigt, indem Attribute eines Rechtecks uber die Zeit verandert

werden. Die SVG-Animationsdatei beginnt mit einer Referenz auf die ‘Docu-

ment Type Definition (DTD)’ der verwendeten SVG-Dokument-Typdefinition.

2.3 SVG 15

<?xml version="1.0" standalone="no"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN""http://www.w2.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">

<svg width="8cm" height="3cm" viewBox"0 0 800 300"xmlns="http://www.w3.org/2000/svg">

<rect id="RectElement" x="300" y="100" width="300" height="100"fill="rgb(255,255,0)"><animate attributeName="x" attributeType"XML"

begin="0s" dur="9s" fill="freeze" from="300" to="0"/><animate attributeName="y" attributeType"XML"

begin="0s" dur="9s" fill="freeze" from="100" to="0"/><animate attributeName="width" attributeType"XML"

begin="0s" dur="9s" fill="freeze" from="300" to="800"/><animate attributeName="height" attributeType"XML"

begin="0s" dur="9s" fill="freeze" from="100" to="300"/></rect>

</svg>

Abbildung 2.10: Beispiel einer SVG Animationsdatei

Das Element ‘svg’ hat die Attribute ‘width’ und ‘height’, welche die Breite und

Hohe des Darstellungsbereichs angeben. Das Attribute ‘viewBox’ beinhaltet den

Bereich der Benutzerkoordinaten, welcher sich im sichtbaren Bereich befindet.

Dargestellt wird ein Rechteck ‘rect’, welches sich zu Beginn an der Position

‘x=300’, ‘y=100’ mit der Breite ‘width=300’ und Hohe ‘height=100’ und der

Fullfarbe ‘rbg(255,255,0)’ befindet. Vom Zeitpunkt ‘begin=0s’ uber die Dauer

‘dur=9s’ werden die Werte der Attribute ‘x’, ‘y’, ‘width’ und ‘height’ in linearer

Beziehung vom Startwert ‘from’ zum Zielwert ‘to’ verandert. Dabei verandert

das Rechteck in der Art seine Große, dass es am Ende der Animation den ge-

samten sichtbaren Bereich einnimmt. Das Attribut ‘fill=freeze’ gibt dabei an,

dass die Werte der veranderten Attribute nach Ende der Animation den Wert

beibehalten.

2.3.2 SVG-Viewer

Zum Anzeigen von animierten SVG-Dateien eignen sich sogenannte SVG-

Viewer, welche das Anzeigen und die Animation von SVG-Dateien bereitstel-

len.

Als SVG-Viewer sind verfugbar:

16 Grundlagen

• Das SVG Toolkit [SVG02] enthalt einen SVG-Viewer, der auch die

Animation von grafischen Objekten unterstutzt. Der Source-Code ist

vollstandig in Java verfugbar.

• Batik [Apa03] ist ein weiteres SVG Toolkit mit Java-Quellcode, welches

insbesondere Filtereffekte und Farbverlaufe besonders gut darstellen kann.

Animationen werden erst im Beta-Stadium unterstutzt. Beispiele hierzu

sind bislang nicht verfugbar.

• Der Adobe SVG Viewer 3.0 [Ado03] bietet den großten Funktionsum-

fang. Er ist allerdings nur als Web-Browser Plugin fur Microsoft Windows

(TM) und als Beta-Version fur Red-Hat Linux erhaltlich. Unter SuSE-

Linux lauft er bislang nicht zufriedenstellend.

Fur die Animationskomponente wird das SVG Toolkit verwendet, da es von

den frei verfugbaren SVG-Viewern den großten Umfang an Animationsopera-

tionen unterstutzt.

Kapitel 3

Konzeption

3.1 Ziel der Diplomarbeit

Ziel der Diplomarbeit ist die Konzeption und Implementierung eines Animati-

onsgenerators, welcher Animationsablaufe auf der Basis von Simulationsregeln

mittels Graphtransformationen erzeugt. In diesem Generator sollen die diskre-

ten Zustandsubergangsschritte zu kontinuierlichen Animationsablaufen in einem

Szenario-Layout erweitert werden. Mehrere Animationsablaufe konnen dann so-

wohl einzeln als auch unter geeigneten Voraussetzungen parallel in einem SVG-

Viewer dargestellt werden.

3.2 Anforderungen an den Animationsgenera-

tor

Der Animationsgenerator ist in mehrere Komponenten zu untergliedern: Eine

dieser Komponente bildet einen eigenstandigen, externen Teil der Animations-

generierung, welcher unabhangig von einer konkreten visuellen Entwicklungs-

umgebung ist. Die internen, von der Entwicklungsumgebung abhangigen Teile

sind fur die GenGED Umgebung zu konzipieren und zu implementieren. Hier-

bei sind die bestehenden Konzepte und Algorithmen der GenGED Umgebung

entsprechend zu erweitern. Der Datenaustausch zwischen den Komponenten des

Animationsgenerators ist entsprechend zu definieren und zu verifizieren.

18 Konzeption

Es sind graphische Benutzerschnittstellen zu entwerfen und in die bestehen-

de GenGED Umgebung zu integrieren, mit deren Hilfe Animationsdesigner

den Animationsgenerator verwenden konnen. Uber die graphischen Benutzer-

schnittstellen stehen dem Animationsdesigner verschiedene Komponenten zur

Verfugung, um Animationsregeln auf Grundlage von Simulationsregeln zu de-

finieren, indem den Simulationsregeln Animationsoperationen zugeordnet wer-

den. Hierbei werden dem Animationsdesigner eine Reihe von vordefinierten Ani-

mationsoperationen bereitgestellt, welche sich an die Funktionalitaten der zur

Verfugung stehenden SVG Animationselemente anlehnen. In der visuellen Ent-

wicklungsumgebung ist eine Zeitleiste zu entwerfen, in der die definierten Ani-

mationsoperationen zu jeder Animationsregel graphisch dargestellt werden und

der Animationsdesigner Beginn und Ende jeder Animationsoperation visuell

verandern kann.

Der bestehende VL-Spezifikationseditor ist um eine Umgebung zur Ani-

mationsspezifikation zu erweitern. Hierbei sollen sich Animationsregeln uber

Animationsausdrucke zu einer Animationsspezifikation zusammenfassen las-

sen, welche dann z.B. einen komplexen Animationsablauf spezifiziert. Die Ani-

mationsausdrucke sollen sich analog zu den Simulationsausdrucken im VL-

Spezifikationseditor definieren lassen.

Die VL-Umgebung ist analog zur Simulationsumgebung um eine Animations-

umgebung zu erweitern. In der Animationsumgebung lassen sich visuelle Dia-

gramme auf Grundlage einer Animationsspezifikation animieren. Die Animati-

onsumgebung tauscht dabei Animationsdaten mit dem externen Teil des Ani-

mationsgenerators aus. Die Animation lasst sich in einer SVG-Animationsdatei

speichern. Die SVG-Animationsdatei kann anschliessend in einem externen

SVG-Viewer betrachtet werden.

Der Animationsgenerator ist am Beispiel des ‘Producer-Consumer-Systems’

zu testen und zu validieren. Hierzu ist ein effizienter Layouter in GenGED

Voraussetzung. Da der bestehende Layouter in GenGED sehr ineffizient arbei-

tet, ist ein neuer Layouter fur die visuelle Sprache der Stellen-Transitions-Netze

auf Grundlage des visuellen Alphabets (siehe Kap. 2.2.1) zu konzipieren und zu

implementieren. Der konzipierte Layouter ist dabei in der Art zu gestalten, dass

3.3 Konzeption eines effizienten Layouters fur die GenGEDUmgebung 19

auf seiner Grundlage leicht neue Layouter fur neue visuelle Sprachen entwickelt

werden konnen.

Es ist ein Benutzerhandbuch zu entwerfen, das alle wesentlichen Bestandteile

der graphischen Benutzerschnittstelle dokumentiert und den Animationsdesi-

gner in die Handhabung der neu konzipierten und implementierten Komponen-

ten einfuhrt.

Da die GenGED Umgebung in Java [Sun03] implementiert ist, ist der Ani-

mationsgenerator ebenfalls in Java zu implementiert. Der Animationsgenerator

verwendet die XML basierten GenGED Formate fur visuelle Alphabete, Dia-

gramme, Simulationsgrammatiken und VL-Spezifikationen. Dabei ist die VL-

Spezifikation um eine Animationsspezifikation zu erganzen. Die graphischen

Benutzerschnittstellen sind in Java/Swing zu implementieren. Die vom Ani-

mationsdesigner erstellten Animationsdefinitionen sind im GenGED spezifi-

schen XML Format zu speichern. Die Animation ist in einem SVG basierten

Animationsformat vom Animationsgenerator zu speichern und einem externen

SVG-Viewer zur Verfugung zu stellen. Hierbei ist zu beachten, dass das SVG

Animationsformat vom verwendeten SVG-Viewer unterstutzt wird.

3.3 Konzeption eines effizienten Layouters fur

die GenGED Umgebung

Die bestehende GenGED Umgebung benutzt grafische Constraints, um die Be-

ziehungen zwischen visuellen Symbolen in der konkreten Syntax zu beschreiben.

Um das konkrete Layout eines Diagramms zu berechnen, mussen die grafischen

Constraints durch den Constraintssolver ParCon (siehe Kap. 2.2.7) gelost wer-

den. Das Losen der Constraint hat sich, auch schon fur sehr kleine Diagramme,

als sehr zeitaufwendig und ineffizient erwiesen, so dass der Layoutalgorithmus

im Rahmen dieser Arbeit neu konzipiert werden musste.

Grundlage fur einen neuen GenGED Layouter ist der Layouter von Dia-

Gen [MV95, Min01], ein Generator fur Diagramm Editoren. Der Layouter von

DiaGen ist direkt in Java implementiert und somit sehr effizient. Grafische

20 Konzeption

Constraints werden nur zum Losen von Teilproblemen verwendet, wenn der

Losungsalgorithmus nicht in Java-Code implementiert werden kann. Der Nach-

teil des Layouters ist, dass er nur fur ein konkretes visuelles Alphabet konzipiert

werden kann. Sobald das visuelle Alphabet geandert wird, muss der Layouter

angepasst werden.

Auf der Grundlage des DiaGen Layouters wird ein GenGED Layouter fur

Stellen-Transitions-Petrinetze konzipiert und in Java implementiert, der den be-

stehenden Constraintssolving-Algorithmus ersetzt. Der Petrinetz Layouter wird

fur das gegebene Petrinetz-Alphabet in GenGED (siehe Kap. 2.2.1) implemen-

tiert.

3.4 Konzeption der Animationsgenerierung

Entscheidend ist, dass die eigenstandige Animationskomponente, welche

den Animationsablauf berechnet von der visuellen Entwicklungsumgebung un-

abhangig ist. Nur so kann eine Komponente geschaffen werden, die sich in un-

terschiedliche visuelle Entwicklungsumgebungen integrieren laßt (z.B. AGG ,

GenGED, u.a.).

Hierzu muß die eigenstandige Animationskomponente unabhangig vom Lay-

outer der visuellen Entwicklungsumgebung sein. Layoutspezifische Schritte der

Animationserstellung mussen in eigenen Komponenten der jeweiligen visuellen

Entwicklungsumgebung lokalisiert sein: dem Animationsregeleditor und der

Animationsumgebung (Abb. 3.1).

3.4.1 Animationsregeleditor

Der Animationsregeleditor ist Bestandteil der jeweiligen visuellen Entwicklungs-

umgebung und erlaubt dem Benutzer, in einer GUI aus den Simulationsregeln

Animationsregeln zu generieren. Dies geschieht durch das Hinzufugen von Ani-

mationsoperationen, welche die kontinuierliche Bewegung der Objekte in einer

Simulationsregel beschreiben.

Die Gestaltung des Animationsregeleditors bleibt vollstandig der jeweiligen

3.4 Konzeption der Animationsgenerierung 21

SVG

SVG−Viewer

Offline−Animation

Visuelle Entwicklungsumgebung

kann integriert werden

Simula−tions−Regeln

Anima−tions−Regeln

Start−Diagramm

Animationsregeleditor

Layouter

Animationsumgebung

Online−Animation

Objekt−informationen

Initial:parameter

Animations−schritt

Parameterzwischen demAnimations−schritt alsSequenz vonFrames

Animations−

zu einem

eigenständige Animationskomponente

Abbildung 3.1: Komponenten der Animationsgenerierung

visuellen Entwicklungsumgebung uberlassen. Im einfachsten Fall generiert der

Animationsregeleditor ohne GUI automatisch mittels Standardregeln (z.B. li-

neare Interpolation) aus den Simulationsregeln Animationsregeln.

Ebenfalls kann der Animationsregeleditor das erneute Editieren von Anima-

tionsregeln unterstutzen, um z.B. eine Animationsoperation hinzuzufugen oder

deren Paramter zu andern (siehe Kap. 3.4.5).

3.4.2 Animationsumgebung

Die Animationsumgebung generiert zu einem Startdiagramm einen konkreten

Animationsablauf (= Animationsszenario) durch die sequenzielle Anwendung

von Animationsregeln. Dies kann sowohl durch bestimmte Regeln automatisch

oder durch Benutzeraktion in einer GUI geschehen.

22 Konzeption

Die Gestaltung der Animationsumgebung bleibt vollstandig der jeweiligen

visuellen Entwicklungsumgebung uberlassen. Im einfachsten Fall erzeugt die

Animationsumgebung ohne GUI automatisch mittels Standardregeln ein Ani-

mationsszenario.

Die Animationsumgebung kommuniziert uber eine Schnittstelle mit der ei-

genstandigen Animationskomponente. Die generierten Animationsdaten konnen

optional der Animationsumgebung zur Online-Animation zuruck ubergeben

werden. Zur Online-Animation mussen allerdings zeitkritische Aspekte beruck-

sichtigt werden, weshalb sich SVG als Datenaustauschformat zur Online-

Animation nicht eignet.

3.4.3 Eigenstandige Animationskomponente

Die eigenstandige Animationskomponente befindet sich vollstandig außerhalb

der jeweiligen visuellen Entwicklungsumgebung und ist so allgemein gestal-

tet, dass sie mit moglichst unterschiedlichen visuellen Entwicklungsumgebungen

kommunizieren kann.

Aufgabe der Animationskomponente ist, aus einem vorhandenen statischen

Objekt-Datensatz einen Animationsablauf zu generieren. Dieser wird zur

Offline-Animation in SVG gespeichert, um mittels eines externen SVG-Viewers

dargestellt oder optional zur Online-Animation der Animationsumgebung der

jeweiligen visuellen Entwicklungsumgebung bereitgestellt werden zu konnen.

Der externe SVG-Viewer kann sich sowohl in einer Web-Applikation, in einer

visuellen Entwicklungsumgebung oder auch in einer grafischen Entwicklungs-

software befinden.

Die Online-Animation stellt im Gegensatz zur Offline-Animation einen zwei-

ten eigenstandigen Weg dar. Ihre Implementierung ist nicht Bestandteil dieser

Diplomarbeit, allerdings wurde die eigenstandige Animationskomponente der-

art konzipiert, dass die Erweiterung zur Online-Animation einfach vollzogen

werden kann.


3.4.4 Schnittstelle zwischen der Animationsumgebung

und der eigenstandigen Animationskomponente

Initial erhalt die eigenstandige Animationskomponente von der Animationsum-

gebungfolgende Daten:

• Objektparameter, wie Position, Große und Identifier, der initialen visuel-

len Objekte.

Fur jeden Animationsschritt (sprich: Regelanwendung) bekommt die Anima-

tionskomponente folgende Daten:

• Animationsparameter, wie Positionsanderung, Farbanderung oder

Großenanderung, fur den Animationsschritt in Form von Animationsope-

rationen.

• Objektparameter nach dem Animationsschritt, in Form von Layoutinfor-

mationen (wie z.B. Positionsanderungen), welche vom Layouter der jewei-

ligen visuellen Entwicklungsumgebung berechnet wurden.

Zur Online-Animation erhalt die Animationsumgebung von der eigenstandi-

gen Animationskomponente folgende Daten:

• Kontinuierliche Bewegungsabfolge der beteiligten Objekte im entsprechen-

den Animationsschritt als eine Sequenz von Frames.

3.4.5 Generierung eines kontinuierlichen Animationsab-

laufes in der GenGED Umgebung

Gegeben ist eine Menge von Animationsregeln (Simulationsregeln im konkre-

ten Layout der Anwendung attributiert mit Animationsoperationen) und ein

Diagramm (aktueller Zustand eines visuellen Modells).

Ein Animationsschritt (Abb. 3.2) wird bei der Anwendung einer Animations-

regel auf das Diagramm generiert.

24 Konzeption

regel

L R

MatchCo−Match

Mapping

Animationsoperation

D

Trans−TransformationsschrittAbleitung/

D’

Animations−

formation

Abbildung 3.2: Animationsschritt

Von AGG wird ein Match von der linken Regelseite (L) einer Animationsre-

gel in das Diagramm (D) berechnet. Ein Mapping in dem Match ist dann die

Abbildung eines Objektes aus L auf ein Objekt in D. Dabei werden die Ani-

mationsoperationen an die entsprechenden Objekte in D gebunden und damit

auch die Startpositionen ermittelt. Als nachstes wird von AGG die Ableitung

D’ auf dem Diagramm D unter Anwendung der Animationsregel berechnet. Das

konkrete Layout von D’ wird vom GenGED Layouter berechnet. Aus D’ lassen

sich nun weitere Parameter fur die Animationsoperationen entnehmen (z.B. fur

die Berechnung der Zielposition des Objekts bei einer Move-Operation oder eine

Farbe bei einer Change-Color-Operation). D’ dient dann als Ausgangsdiagramm

zur Generierung des nachsten Animationsschritts.

Die statischen Objektparameter vor und nach jedem Animationsschritt wer-

den von der GenGED Animationsumgebung an die externe Animationskom-

ponente ubergeben, welche dann den konkreten Animationsablauf berechnet.


3.4.6 Anwendung auf Petrinetze

Bestandteil der Diplomarbeit ist ein konkretes Anwendungsszenario zur Ani-

mation von Petrinetzen:

• Das Tokengame bei Petrinetzen kann durch kontinuierliche Bewegung

der Token im Netz animiert werden. Hierzu muss ein gegebenes Pe-

trinetz zunachst in ein Graphtransformationssystem uberfuhrt werden.

Dies kann z.B. durch XML-Formattransformation [Ehr02] aus dem XML-

Austauschformat des Petri-Netz-Kerns [KW99] und einem gegebenen

GenGED Petri-Netz-Alphabet erfolgen.

• Das Verhalten von Petrinetzen kann in ein anwendungsspezifisches Lay-

out transformiert und dann animiert werden. Diese sogenannte View-

Transformation muss in der derzeitigen Konzeption von Hand vollzogen

werden. Geplant fur eine spatere Version ist ein sogenannter ‘View Com-

piler’, welcher das Verhaltensmodell konsistenzbewahrend in eine anwen-

dungsorientierte Sicht uberfuhrt [EB03]. Dieser ‘View Compiler’ ist nicht

Bestandteil dieser Diplomarbeit. Er laßt sich allerdings in die bestehenden

Konzepte integrieren.

3.4.7 VL-Umgebung in GenGED

Die bestehende VL-Umgebung von GenGED wird um eine Animationsumge-

bung erweitert (Abb. 3.3).

Grundlage fur die Animation ist eine modellspezifische Simulationsgramma-

tik, welche im Grammatik-Editor der alten GenGED Umgebung erstellt wer-

den kann. Fur Petrinetze ist die automatische Generierung der jeweiligen Schalt-

regeln fur ein bestimmtes Petrinetz geplant. Im Animationsregeleditor wird die

Grammatik um Animationsoperationen erweitert. Dieser Erweiterungen werden

zusammen mit einer Referenz zur Grammatik in der Animationsregelspezifika-

tion gespeichert.

Der bestehende VL-Spezifikationseditor wird um Dialogelemente zur Definiti-

on von Animationsschritten erweitert, in der analog zur Simulation [Wei01]

26 Konzeption

AllgemeineSimulations−Grammatik Grammatik

Simulations−Modellspez.

Animationsregeleditor Spezifi−kation

Simulation Parsierung General AnimationSyntax

VL−Spezifikations−Editor

Simula− Anima− Animations−

VL−Umgebung

eigenständige AnimationskomponenteSVG−FileSVG−Viewer

Animations−Regel−

Simulations−umgebung umgebungtions

SchrittetionsSchritte

Abbildung 3.3: Neue GenGED VL-Umgebung

Animationsregeln zu einem Animationsschritt zusammengefasst werden. Da-

bei werden analog zur Simulation Ausdrucke formuliert, welche Regeln fest-

legen, in welcher Reihenfolge und in welcher Haufigkeit einzelne Animations-

regeln in einem Animationsschritt angewendet werden. Benotigt werden diese

Ausdrucke bei der Simulation z.B. zur Definition von abstrakten Simulations-

regeln bei hierarchischen Statecharts [Wei01]. Bei der Animation besteht der

einfachste Animationsschritt genau aus der Anwendung einer Animationsregel.

Bei Petrinetzen entspricht dies genau dem Schaltverhalten einer Transition.

Mehrere Animationsregeln lassen sich durch Ausdrucke zu einem Animations-

szenario kombinieren. Bei Petrinetzen last sich z.B. eine sequenzielle Schaltung

von Transitionen durch einen AND-Ausdruck uber mehrere Animationsregeln

modellieren. Dabei bilden ein oder mehrere geschachtelte Ausdrucke uber den

Animationsregeln einen Animationsschritt.

Die Animationsschritte werden mittels einer ‘Animationsschrittspezifikation’


in die bestehende VL-Spezifikation integriert. Die VL-Spezifikation wird als VL-

Spezifikationsdatei gespeichert, um anschließend in die ‘VL-Umgebung’ geladen

werden zu konnen. Diese wird, analog zur Simulationsumgebung [Wei01], um

eine Animationsumgebung erweitert, welche eine Simulation durchfuhrt, im Hin-

tergrund die Animationsoperationen auswertet und die eigenstandige Animati-

onskomponente mit den entsprechenden Daten versorgt.

Anschließend erstellt die eigenstandige Animationskomponente ein SVG-File,

welches alle SVG-Objektinformationen und die zugehorigen SVG-Animations-

Elemente enthalt. Die Animation wird in einem externen SVG-Viewer darge-

stellt, welcher optional auch in eine beliebige visuelle Entwicklungsumgebung

integriert werden kann.

Als weiterer optionaler Schritt konnte die Animationskomponente der Anima-

tionsumgebung einen kontinuierlichen Animationsablauf ubermitteln, welcher in

der GenGED Animationsumgebung dargestellt wird.

28 Konzeption

Kapitel 4

Entwurf

Der Generator fur Animationsumgebungen besteht aus folgenden Kom-

ponenten, welche im folgenden entworfen werden:

• GenGED Layouter.

• Animationsregeleditor in GenGED.

• Erweiterung des bestehenden VL-Spezifikationseditors in GenGED.

• Erweiterung der bestehenden VL-Umgebung in GenGED um eine Ani-

mationsumgebung.

• Eigenstandige Animationskomponente.

Die Struktur der einzelnen Komponenten wird mit UML-Klassendiagrammen

und UML-Sequenzdiagrammen veranschaulicht [UML02]. Hierzu wurde das

Reengineering Tool von EclipseUML [OMO03] als Plugin zu der Eclipse-

Umgebung [Ecl03] benutzt. Aufgrund der Große der einzelnen Komponen-

ten stellen die Klassendiagramme einen Ausschnitt der verwendeten Klassen

dar. Hierbei wird besonders die Integration der Komponenten in die bestehen-

de GenGED Umgebung hervorgehoben, indem die verwendeten Klassen mit

absoluten Namen angegeben werden (z.B. ‘genged::alphabet::GraphicObject’).

Ebenfalls werden die Beziehungen zu den wichtigsten Basis Java Klassen [Sun03]

und den Klassen von DiaGen [Min01] (fur den Petrinetz-Layouter) hervorge-

hoben.

30 Entwurf

4.1 Ablauf der Animationserstellung

Folgender Ablauf ergibt sich fur den Benutzer fur die Animationserstellung in

der GenGED Umgebung.

Mit der bisherigen GenGED Umgebung werden erstellt:

1. Ein visuelles Alphabet.

2. Eine modellspezifische Simulationsgrammatik.

3. Ein Start-Diagramm uber dem Alphabet.

Fur die Animationsgenerierung ergibt sich folgender Arbeitsablauf:

1. Animationsregeleditor in GenGED:

(a) Laden der modellspezifischen Simulationsgrammatik.

(b) Definition von Animationsoperationen zu den Regeln der Simulati-

onsgrammatik.

(c) Speichern der Animationsgrammatik (d.h. Simulationsgrammatik

mit Animationsoperationen) als Animationsregelspezifikation.

2. VL-Spezifikationseditor in GenGED:

(a) Erstellen bzw. Laden einer VL-Spezifikation.

(b) Laden der Animationsregelspezifikation.

(c) Definition der Animationsschritte.

(d) Speichern der neu erstellten bzw. erweiterten VL-Spezifikation.

3. VL-Umgebung in GenGED:

(a) Laden der VL-Spezifikation.

(b) Aktivieren der Animationsumgebung.

(c) Laden des Start-Diagramms in die Animationsumgebung.

(d) Ausfuhren der Animationsschritte in der Animationsumgebung.

4.2 GenGED Layouter 31

(e) Speichern des generierten Animationsablaufes in SVG.

4. SVG-Viewer:

(a) Laden der SVG-Datei in den SVG-Viewer.

(b) Betrachten der Animation.

Der Arbeitsablauf kann an jeder Stelle unterbrochen werden und es kann zu

einem vorherigen Punkt zuruckgekehrt werden.

4.2 GenGED Layouter

Fur eine Animation ist ein effizienter Layouter Voraussetzung. Auf der Basis

des DiaGen Layouters wird ein Layouter fur Stellen-Transitions Petrinetze

implementiert. Die Basis fur den Layouter stellt das Petrinetz-Alphabet (sie-

he Kap. 2.2.1) dar: Mittels Java-Code wird ein Layoutalgorithmus speziell fur

das Petrinetz-Alphabet implementiert. Der Layouter ist dabei direkt mit den

grafischen Objekten der Alphabet-Symbole assoziiert, so dass Anderungen im

Alphabet sofort Anderungen im Layouter implizieren.

Abbildung 4.1: Klassendiagramm Petrinetz-Layouter

Abb. 4.1 zeigt einen Ausschnitt aus dem UML-Klassendiagramm des

Petrinetz-Layouters. Basisklasse der Petrinetz-Layouters ist ‘PetriLayouter’,

32 Entwurf

welche das Interface ‘genged::constsolver::Layouter’ implementiert. Durch die

Implementierung des Constraint-Solver Layouters behandelt das GenGED Sys-

tem den Java-Code Layouter wie den Constraint-Solver ParCon. Auf diese

Weise laßt sich der neue Layouter in das alte GenGED System ohne großere

Anderungen integrieren.

Die grafischen Objekte eines Stellen-Transitions-Petrinetzes werden durch die

Klassen ‘Token’, ‘Place’, ‘Arc’ und ‘Transition’ reprasentiert. Die Klasse ‘Arc’

ist dabei die Basisklasse fur Verknupfungen zwischen Stellen (‘Place’) und Tran-

sitionen (‘Transition’) durch Pfeile (‘Arc’). Alle grafischen Objekte befinden sich

in einem Wurzelknoten (‘RootNode’), welcher von der DiaGen Klasse ‘Com-

positeNode’ abstammt und damit einen zusammengesetzten Knoten mit Un-

terknoten reprasentiert. Vorteil dieses hierarchischen Entwurfs ist u.a., dass die

Gesamtgroße des layouteten Diagramms im ‘RootNode’ festgelegt werden kann.

Die Klasse ‘Symbol’ implementiert die DiaGen Klasse ‘ParamOwner’ und stellt

damit die Basisfunktionen zum DiaGen Parameteraustausch bereit.

Abbildung 4.2: Klassendiagramm Petrinetz-Layouter ‘ArcPT’ und ‘ArcTP’

Abb. 4.2 zeigt einen Ausschnitt aus dem UML-Klassendiagramm fur die Pfeile

‘Arc’ zwischen den Stellen ‘Place’ und Transitionen ‘Transition’ im Petrinetz

Layouter. Die Klasse ‘ArcPT’ reprasentiert einen Pfeil von einer Stelle (‘Place’)

4.3 Animationsregeleditor 33

zu einer Transition (‘Transition’). Dabei darf der Pfeil hochstens mit einer Stelle

als Quelle (‘source’) und hochstens einer Transition als Ziel (‘target’) verbunden

sein. Wenn der Pfeil genau mit einer Stelle und einer Transition verbunden ist,

dann ist er fertig initialisiert und kann layoutet werden. Analoges gilt fur die

Klasse ‘ArcTP’ fur den Pfeil von einer Transition zu einer Stelle.

4.3 Animationsregeleditor

Der Animationsregeleditor ist Bestandteil der GenGED Umgebung. In Abb.

4.3 ist das Klassendiagramm der Basisklassen des Animationsregeleditors dar-

gestellt. Der Animationsregeleditor (‘AnimRuleEditor’) stammt von der Gen-

GED Editor Basisklasse ‘genged::gengededitor::AbstractEditor’ ab, welche wie-

derum die Klasse ‘javax::swing::JPanel’ um GenGED spezifische Editorbe-

standteile erweitert [Nie99, Sch99]. Die Darstellung der Animationsregeln wird

von ‘AnimRuleDisplay’ ubernommen (siehe Kap. 4.3.1), welche mit der Zei-

chenumgebung ‘AnimRuleDrawArea’ Daten austauscht.

4.3.1 Animationsregel

In den Animationsregeleditor wird eine modellspezifische Simulationsgrammatik

geladen. Die Regeln der Simulationsgrammtik werden als Animationsregeln von

‘AnimRuleDisplay’ dargestellt. Dabei werden die linke Seite ‘L’ und die rechte

Seite ‘R’ einer Animationsregel gemeinsam in einem Diagramm dargestellt:

Abb. 4.4 erlautert dies am Beispiel der Regel ‘produce’ des ‘Producer-

Consumer-Systems’ (s. Abb. 2.3). Alle grafischen Symbole der linken Regelseite

‘L’ werden in die Animationsregeldarstellung ubernommen. Dabei werden al-

le grafischen Symbole der linken Regelseite, welche nicht im Regelmorphismus

enthalten sind, grafisch hervorgehoben. In Abb. 4.4 trifft dies auf den schwar-

zen Token der linken Regelseite ‘L’ zu, welcher durch eine doppelte Umrandung

in der Animationsregeldarstellung hervorgehoben wird. Alle grafischen Symbo-

le der rechten Regelseite ‘R’, welche nicht im Regelmorphismus sind, werden

ebenfalls in die Animationsregeldarstellung ubernommen, grafisch hervorgeho-

34 Entwurf

Abbildung 4.3: Klassendiagramm des Animationsregeleditors

ben (weißer Token in Abb. 4.4) und mittels grafischen Constraints verknupft.

Die Animationsregeldarstellung ist ein eigenes Diagramm und wird von der

‘AnimRuleDrawArea’ als solches behandelt, wodurch die GenGED internen

Algorithmen zur Diagrammdarstellung verwendet werden konnen.

Alle hervorgehobenen Symbole reprasentieren die Symbole, welche sich

wahrend der Animation verandern. Dabei wird die kontinuierliche Zu-

standsanderung der Symbole durch Animationsoperationen beschrieben,

welche an die Simulationsregeln als Attribute gekoppelt werden (siehe Kap.

3.4.5).


L

produce

R

produceRegelmorphismus

produce

Darstellung der Animationsregel

Abbildung 4.4: Darstellung der Animationsregel fur ‘produce’

4.3.2 Definition einer Animationsoperation

Dem Benutzer werden im Menu des Animationsregeleditors verschiedene Ak-

tionen zur Definition von Animationsoperationen angeboten. Dabei bezieht sich

eine Animationsoperation immer auf ein hervorgehobenes Symbol der Anima-

tionsregeldarstellung (siehe Kap. 4.3.1) und beschreibt dessen kontinuierliche

Bewegung wahrend eines Animationsablaufes (siehe Kap. 3.4.5).

Die definierten Animationsoperationen werden im Baummodell (siehe Kap.

4.3.3) eingefugt und ihre Dauer in der Zeitleiste (siehe Kap. 4.3.4) grafisch

dargestellt.

In Anlehnung an die Animationsfunktionen, die im SVG-Viewer zur

Verfugung stehen, werden folgende Animationsoperationen definiert:

36 Entwurf

LinearMove

Die Animationsoperation ‘LinearMove’ beschreibt eine lineare Bewegung uber

Referenzobjekte eines grafischen Symbols. Nachdem der Benutzer uber das

Menu die ‘LinearMove’ Aktion aktiviert hat, selektiert er ein hervorgehobenes

Symbol aus der Animationsregeldarstellung. Danach selektiert er nacheinander

die Referenzobjekte, uber die sich das Symbol bewegen soll. Der selektierte Pfad

wird dabei grafisch dargestellt.

Visibility

Die Animationsoperation ‘Visibility’ beschreibt eine Sichtbarkeitsanderung ei-

nes grafischen Symbols, in der Form, dass das Symbol fur die Dauer der Aktion

nicht angezeigt wird. Nachdem der Benutzer uber das Menu die ‘Visibility’

Aktion aktiviert hat, selektiert er ein hervorgehobenes Symbol aus der Anima-

tionsregeldarstellung.

ChangeColor

Die Animationsoperation ‘ChangeColor’ beschreibt eine kontinuierliche

Farbanderung eines grafischen Symbols. Nachdem der Benutzer uber das

Menu die ‘ChangeColor’ Aktion aktiviert hat, selektiert er ein hervorgehobe-

nes Symbol aus der Animationsregeldarstellung und die neue Farbe aus einem

‘ChangeColor’-Dialogfenster.

Resize

Die Animationsoperation ‘Resize’ beschreibt eine kontinuierliche Großenande-

rung eines grafischen Symbols. Nachdem der Benutzer uber das Menu die ‘Re-

size’ Aktion aktiviert hat, selektiert er ein hervorgehobenes Symbol aus der

Animationsregeldarstellung und gibt die Großenanderung in Prozent in einem

Dialogfenster ein.


Sequenzdiagramm zur Definition einer Animationsoperation

Abbildung 4.5: Sequenzdiagramm zur Definition einer Animationsoperation

Abb. 4.5 zeigt ein Sequenzdiagramm zur Definition einer Animationsoperati-

on. Der Benutzer (User) selektiert ein Objekt in der Zeichenumgebung (‘Anim-

RuleDrawArea’). Die Zeichenumgebung ruft die Methode ‘proceedVisibilityAc-

tion(GraphicObject)’ des Animationsregeleditors (‘:AnimRuleEditor’) auf, wo-

38 Entwurf

mit in diesem Fall die ‘Visibility’ Aktion fortgesetzt wird. Der Animations-

regeleditor erzeugt daraufhin eine neue Animationsoperation ‘AnimRuleOpe-

ration’ und ruft in der Klasse ‘TimeLineDisplay’ die Methode ‘createTimeLi-

nePanel(AnimRuleOperation)’ auf, um die neue Animationsoperation in die

Zeitleiste einzufugen. Das ‘TimeLineDisplay’ erzeugt daraufhin das gewunsch-

te ‘TimeLinePanel’. Anschließend bewegt der Benutzer das ‘TimeLinePanel’

bei gedruckter Maustaste ‘mousePressed(MouseEvent)’ und andert damit die

Startzeit (‘setStartTime(float)’) und Dauer (‘setDuration(float)’) der Anima-

tionsoperation. Der Benutzer kann nun eine weitere Animationsoperation de-

finieren, andern oder loschen (im Sequenzdiagramm nicht dargestellt). Nach

Abschluss der Animationsdefinition speichert der Benutzer die Animationsre-

gelspezifikation, indem er die ‘SaveFile’ Editoraktion auslost.

4.3.3 Baummodell

Die Animationsregeln werden in einer Baumstruktur dem Benutzer angezeigt.

Dabei werden zu jeder Animationsregel die Animationsoperationen gezeigt, die

zu einem Symbol dieser Regel in der Animationsregeldarstellung (siehe Kap.

4.3.1) definiert wurden.

Abbildung 4.6: Klassendiagramm zum Baummodell des Animationsregeleditors

Das Klassendiagramm zum Baummodell (‘TreeModel’) des Animationsrege-


leditors ist in Abb. 4.6 dargestellt. Das Baummodell ‘AnimGramModel’ wurde

von der Baumdarstellung der Simulationsgrammatik im Grammatik-Editor ab-

geleitet. Es stammt wiederum von einer GenGED Basisklasse ab, welche ih-

rerseits von der Java Swing Klasse ‘DefaultTreeModel’ abstammt. Analoges gilt

fur das ‘AnimGramSelectionModel’, welches die Interaktionsroutinen mit dem

Anwender, z.B. bei Selektion eines Elementes, bereitstellt.

4.3.4 Zeitleiste

Bestandteil des Animationsregeleditors ist eine Zeitleiste (‘TimeLine’), in der

jede Animationsoperation (siehe Kap. 4.3.2) als Balken innerhalb einer Zeit-

leiste dargestellt wird. Der Anwender kann diesen Balken mit der Maus inner-

halb der Zeitleiste bewegen und somit die Anfangszeit der Animationsoperation

festlegen. Durch Anderung der Balkenlange kann der Anwender die Dauer der

Animationsoperation festlegen.

Abbildung 4.7: Klassendiagramm zur Zeitleiste des Animationsregeleditors

Das Klassendiagramm zur Zeitleiste des Animationsregeleditors ist in Abb.

4.7 dargestellt. Der Animationsregeleditor (‘AnimRuleEditor’) initialisiert das

‘TimeLineDisplay’, welches die Basisklasse fur die Zeitleiste darstellt. Die Klasse

40 Entwurf

‘TimeLineDisplay’ initialisiert die Klasse ‘TimeLineBar’, welche die eigentliche

Zeitleiste darstellt. Jeder Balken wird durch ein ‘TimeLinePanel’ reprasentiert,

welchem jeweils eine Animationsoperation (‘AnimRuleOperation’) zugeordnet

ist.

4.3.5 Animationsregelspezifikation

Die Animationsregeln, welche im Animationsregeleditor definiert wurden, wer-

den in der Animationsregelspezifikation gespeichert.

Abbildung 4.8: Klassendiagramm zur Animationsregelspezifikation

Das Klassendiagramm zur Animationsregelspezifikation ist in Abb. 4.8 darge-

stellt. Die Animationsregelspezifikation (‘AnimRuleSpec’) implementiert das In-


terface (‘GGStorable’), welches die notwendigen Operationen zur Persistenz lie-

fert. Die Spezifikation beinhaltet beliebig viele Animationsoperationen (‘Anim-

RuleOperation’), welche sich jeweils auf ein grafisches Objekt beziehen, das

durch ‘AnimRuleRefObject’ referenziert wird. Die Referenz bezieht sich auf ein

grafisches Objekt als Basisklasse fur ‘SymbolObject’ und ‘DatatypeObject’. Re-

ferenziert werden der Identifier des grafischen Objektes, welcher innerhalb eines

Diagramms eindeutig ist. Da eine Regel eine linke (Domain) und eine rechte Sei-

te (Codomain) besitzt, muss zusatzlich zur Regel auch noch die Seite referenziert

werden. Die boolsche Variable ‘domain’ hat dabei den Wert ‘wahr’, wenn die

Referenz sich auf die linke Regelseite (Domain) bezieht. Anderenfalls hat sie

den Wert ‘falsch’. Die Klasse ‘AnimRuleOperation’ ist die Basisklasse fur alle

Animationsoperationsdefinitionen (siehe Kap. 4.3.2). Die Animationsoperatio-

nen ‘AnimRuleLinearMove’ und ‘AnimRuleVisibility’ stammen von ‘AnimRu-

leOperation’ ab und implementieren die Animationsoperationen ‘LinearMove’

und ‘Visibility’ (siehe Kap. 4.3.2). Analoges gilt fur die Animationsoperationen

‘ChangeColor’ und ‘Resize’, welche hier nicht dargestellt sind.

Abb. 4.9 zeigt einen Ausschnitt aus der Animationsregelspezifikation fur die

Regel ‘produce’ des ‘Producer-Consumer-Systems’ (siehe Kap. 2.2.2 und 2.2.4)

im XML-basierten GenGED Format [Wei01]. Die Simulationsgrammatik wird

mit dem Dateinamen in dem Element ‘<SimulationGrammar>’ referenziert. Im

Element ‘<GraphTransformationSystem>’ werden die Referenzen der Regelna-

men zu den Regel-IDs hergestellt. Anschließend sind zwei Animationsoperatio-

nen ausgelistet: Das Element beginnt mit dem Klassennamen der Operation

(z.B. ‘<AnimRuleLinearMove .../>’). Zuerst folgen die allgemeinen Attribute,

wie Startzeit (‘StartTime’) und Dauer (‘Duration’) und die Referenz auf den

Regelnamen (‘RuleName’). Danach folgt die Referenz auf das Startobjekt, auf

welches sich die Animationsoperation bezieht (Element ‘<SourceObject .../>’).

Die Referenz erfolgt durch das ‘AnimRuleRefObject’. Im Anschluss folgt bei

‘LinearMove’ die Pfadliste der Referenzobjekte.

Analog lassen sich Animationsoperationen fur ‘deliver’, ‘remove’ und

‘consume’ spezifizieren. Die Animationsregelspezifikation fur das ‘Producer-

Consumer-System’ enthalt dann samtliche Animationsoperationen fur alle Re-

42 Entwurf

<?xml version="1.0" encoding="UTF-8"?><Document>

<AnimationRuleSpecification name="ProducerConsumer"><SimulationGrammar filename="ProducerConsumerSimulation.gra">

<GraphTransformationSystem name="ProducerConsumerSimulation"><Rule ID="1" name="produce"/><Rule ID="2" name="deliver"/><Rule ID="3" name="remove"/><Rule ID="4" name="consume"/>

</GraphTransformationSystem></SimulationGrammar><AnimRuleOperation>

<AnimRuleLinearMove Duration="3.0" RuleName="produce"StartTime="0.0" name="Linear Move"><SourceObject RuleName="produce" domain="true"

identifier="Inst:Token" name="AnimRuleRefObject"/><SourceColor alpha="255" blue="0" green="0" red="255"/><AnimRuleRefObjects>

<AnimRuleRefObject RuleName="produce" domain="true"identifier="Inst:Token" name="AnimRuleRefObject"/>

<AnimRuleRefObject RuleName="produce" domain="true"identifier="Inst:Transition" name="AnimRuleRefObject"/>

</AnimRuleRefObjects></AnimRuleLinearMove>

</AnimRuleOperation><AnimRuleOperation>

<AnimRuleVisibility Duration="3.0" RuleName="produce"StartTime="3.0" name="Visibility"><SourceObject RuleName="produce" domain="true"

identifier="Inst:Token" name="AnimRuleRefObject"/><SourceColor alpha="255" blue="0" green="0" red="255"/>

</AnimRuleVisibility></AnimRuleOperation>

</AnimationRuleSpecification></Document>

Abbildung 4.9: Ausschnitt aus der Animationsregelspezifikation fur ‘produce’

geln aus der Simulationsgrammatik.

4.4 VL-Spezifikationseditor

Der bestehende GenGED VL-Spezifikationseditor wird um eine Animations-

schrittdefinitionsumgebung erweitert, welche analog zur Simulationsschrittdefi-

nitionsumgebung Animationsschritte definiert (siehe Kap. 3.4.7).

Abb. 4.10 zeigt einen Ausschnitt aus dem Klassendiagramm des VL-

Spezifikationseditors. Erweitert wird der Editor um eine ‘AnimationPane’, wel-

che analog zur ‘SimulationPane’ die Editorumgebung zur Definition der Ani-

mationsschritte bereitstellt.

4.4 VL-Spezifikationseditor 43

Abbildung 4.10: Klassendiagramm des VL-Spezifikationseditors

4.4.1 Animationsschrittdefinition

Die Animationsschrittdefinitionen werden in einer Animationsschrittspezifi-

kation zusammengefasst, welche in die bestehende GenGED VL-Spezifikation

integriert wird.

Abbildung 4.11: Klassendiagramm zur Animationsschrittspezifikation

44 Entwurf

Abb. 4.11 zeigt einen Ausschnitt aus dem Klassendiagramm der Anima-

tionsschrittspezifikation. Die Animationsschrittspezifikation (‘AnimStepSpecifi-

cation’) referenziert dabei eine Animationsregelspezifikation (‘AnimRuleSpec’)

(siehe Kap. 4.3.5) und wird in die bestehende VL-Spezifikation (‘VLSpecifika-

tion’) integriert, welche das Interface ‘GGStorable’ implementiert und somit

abgespeichert werden kann. In der Animationsschrittspezifikation sind beliebig

viele Animationsschritte (‘AnimStep’) enthalten. Die eigentliche Auswertung

der Animationsschritte wahrend einer Animation geschieht durch den Animati-

onsevaluierer (‘AEEvaluator’), welcher mit der Graphtransformationsmaschine

AGG, reprasentiert durch das Interface ‘GGAlgebraTransformer’, korrespon-

diert (siehe Kap. 3.4.5). Wahrend der Graphtransformation ubergibt die Klasse

‘AEEvaluator’ die animationsspezifischen Daten der eigenstandigen Animati-

onskomponente (‘AnimComponent’, siehe Kap. 4.6).

Sequenzdiagramm zur Erstellung einer Animationsschrittspezifika-tion

In Abb. 4.12 ist ein Sequenzdiagramm dargestellt, indem der Benutzer (User)

eine neue Animationsschrittspezifikation erstellt, indem er durch Selektion des

entsprechenden Menupunktes bzw. Toolbuttons eine ‘NewAnimationSpec’ Edi-

toraktion auslost. Daraufhin erzeugt der VL-Spezifikationseditor eine neue Ani-

mationsschrittspezifikation (‘AnimStepSpecification’), in welche solange Anima-

tionsschritte eingefugt werden, bis die Animationschrittspezifikation komplett

ist. Hierzu wird zu jedem Animationsschritt jeweils eine neue Klasse ‘Anim-

Step’ erzeugt. Nachdem der Benutzer die VL-Spezifikation abgeschlossen hat,

speichert er die VL-Spezifikation, indem er die Editoraktion ‘SaveFile’ auslost.

Persistenz

Abb. 4.13 zeigt eine VL-Spezifikation mit Animationsschrittdefinition fur

die Regel ‘produce’ des ‘Producer-Consumer-Systems’ (siehe Kap. 2.2.2 und

2.2.4) im XML-basierten GenGED Format [Wei01]. Unter dem Element

‘<AnimSteps ...>’ werden die Animationsschritte eingefugt. Der Animati-

onsschritt ‘<AnimStep name=‘produce’>’ besteht nur aus einer Regelanwen-


Abbildung 4.12: Sequenzdiagramm zur Erstellung einer Animationsschrittspe-zifikation

dung, welche mit ‘rule=13’ auf die Regel-ID von der Simulationsregel ‘pro-

duce’ referenziert wurde. Bezuglich der Simulationsgrammatik werden die Si-

mulationsregeln uber ihren Namen referenziert. Uber ‘<AnimRuleSpec filena-

me=ProducerConsumer.anm />’ ist die Animationsregelspezifikation referen-

ziert, welche in der Animationschrittdefinition verwendet wird. Die ubrigen Ele-

mente entsprechen der bisherigen VL-Spezifikation: Die ‘VLSpecOptions’ legen

fur die VL-Spezifikation fest, ob das verwendete Alphabet und die Grammatiken

uber Referenzen oder als komplette Datensatze in die VL-Spezifikation einge-

bunden werden. Mit ‘<SyntaxAlphabet filename=PetriAlphabet.alp>’ wird das

der gesamten VL-Spezifikation zugrundelegende visuelle Alphabet referenziert.

Die Symbole des Alphabets werden dabei als ‘NodeTypes’ und die Operatio-

46 Entwurf

<?xml version="1.0" encoding="UTF-8"?><Document>

<VLSpecification name="ProducerConsumer"><VLSpecOptions includeAlphabet="reference"

includeAnimGrammars="reference"includeParsingGrammar="reference"includeSimulationGrammars="reference"includeSyntaxGrammar="reference"/>

<SyntaxAlphabet filename="PetriAlphabet.alp"><GraphTransformationSystem>

<Types><NodeType ID="1" name="Place">

<AttrType ID="2" attrname="PlName" typename="string"/></NodeType><NodeType ID="3" name="Transition">

<AttrType ID="4" attrname="TrName" typename="string"/></NodeType><NodeType ID="5" name="ArcPT"/><NodeType ID="6" name="ArcTP"/><NodeType ID="7" name="Token"/><EdgeType ID="8" name="spt" source="5" target="1"/><EdgeType ID="9" name="tpt" source="5" target="3"/><EdgeType ID="10" name="ttp" source="6" target="1"/><EdgeType ID="11" name="stp" source="6" target="3"/><EdgeType ID="12" name="tok" source="7" target="1"/>

</Types></GraphTransformationSystem>

</SyntaxAlphabet><AnimationStepSpecification name="TestA">

<AnimRuleSpec filename="ProducerConsumer.anm"/><SimulationGrammar filename="ProducerConsumerSimulation.gra">

<GraphTransformationSystem name="ProducerConsumerSimulation"><Rule ID="13" name="produce"/><Rule ID="14" name="deliver"/><Rule ID="15" name="remove"/><Rule ID="16" name="consume"/>

</GraphTransformationSystem></SimulationGrammar><AnimSteps>

<AnimStep name="produce"><Parameters/><AnimStepExpression>

<RuleAnimStepExpression rule="13"><ParameterAssignment/>

</RuleAnimStepExpression></AnimStepExpression>

</AnimStep></AnimSteps>

</AnimationStepSpecification></VLSpecification>

</Document>

Abbildung 4.13: VL-Spezifikation mit Animationsschrittdefinition

nen als ‘EdgeTypes’ aufgefuhrt. Dabei wird jeder Operation uber ‘source’ und

‘target’ ein Quell- und Zielsymbol zugeordnet.


4.4.2 Animationsausdruck

Ein Animationsschritt wird uber einem Animationsausdruck definiert. Im ein-

fachsten Fall besteht dieser Ausdruck nur aus einer Regelanwendung (siehe Abb.

4.13). Es lassen sich analog zu den Simulationsausdrucken [Wei01] folgende Ani-

mationsausdrucke im VL-Spezifikationseditor definieren:

• Startsymbol: Expression. Die Definition eines Ausdrucks beginnt immer

mit einer Expression, aus beliebige Ausdrucke abgeleitet werden konnen.

• Expression→ RULE. Eine Expression kann direkt in eine Animationsregel

RULE abgeleitet werden. Wenn sich wahrend der Animation eine gultige

Transformation mit der Animationsregel durchfuhren lasst, wird ‘wahr’

und anderenfalls ‘falsch’ zur weiteren Auswertung zuruckgeliefert.

• Expression → AND Expressions. Eine Expression kann in eine sequenzi-

elle Liste von Expressions abgeleitet werden, wobei alle Expressions aus-

gewertet werden, bis eine Expression den Wert ‘falsch’ zuruckliefert. Der

Ruckgabewert des AND-Ausdrucks ist ‘wahr’, wenn die Auswertung von

alle Expressions ‘wahr’ ergeben hat, anderenfalls ist er ‘falsch’.

• Expression → OR Expressions. Eine Expression kann in eine sequenzielle

Liste von Expressions abgeleitet werden, wobei so lange eine Expressi-

on aus der Liste der Expressions ausgewertet wird, bis eine Expression

den Wert ‘wahr’ zuruckliefert. Der Ruckgabewert des OR-Ausdrucks ist

‘wahr’, wenn die Auswertung einer Expression ‘wahr’ ergeben hat, ande-

renfalls ist er ‘falsch’.

• Expression → WHILE Condition Do. Eine Expression kann in einen

WHILE-Ausdruck abgeleitet werden, wobei ‘Condition’ und ‘Do’ jeweils

eine Expression darstellen. Die Expression ‘Do’ wird solange ausgewer-

tet, wie ‘Condition’ den Wert ‘wahr’ zuruckliefert. Zu beachten ist, dass

an dieser Stelle eine Endlosscheife entsteht, wenn ‘Condition’ immer den

Wert ‘wahr’ zuruckliefert.

48 Entwurf

• Expression → IF Condition Then Else. Eine Expression kann in einen IF-

Ausdruck abgeleitet werden, wobei ‘Condition’, ‘Then’ und ‘Else’ jeweils

eine Expression darstellen. Wenn die Auswertung von ‘Condition’ den

Wert ‘wahr’ zuruckliefert, wird ‘Then’ ausgewertet, anderenfalls ‘Else’.

4.5 VL-Umgebung

Die bestehende VL-Umgebung von GenGED wird um eine Animationsumge-

bung (‘AnimationEnvironment’) erweitert (siehe Kap. 3.4.7).

Abbildung 4.14: Klassendiagramm zur VL-Umgebung

Abb. 4.14 zeigt einen Ausschnitt aus dem Klassendiagramm der VL-

Umgebung. Die Klasse ‘VLEnvironment’ verwaltet vier Editoren, die in die

VL-Umgebung integriert sind: ‘DiagramEditor’, ‘VLEditor’, ‘SimulationEnvi-

ronment’ und ‘AnimationEnvironment’. Dabei stammen alle Klassen bis auf

‘AnimationEnvironment’ aus der bisherigen GenGED Umgebung, wobei ‘Dia-

gramEditor’ und ‘VLEditor’ eine Umgebung zum Erstellen und Editieren von

Diagrammen und ‘SimulationEnvironment’ eine Umgebung fur die Simulation

bereitstellen.


Die Animationsumgebung stellt als Teil der VL-Umgebung die Umgebung fur

die Animation bereit (siehe Kap. 3.4.7).

4.5 VL-Umgebung 49

Abbildung 4.15: Klassendiagramm zur Animationsumgebung

Abb. 4.15 zeigt einen Ausschnitt aus dem Klassendiagramm der Animations-

umgebung. Die Basisklasse ‘AnimationEnvironment’ implementiert einen eige-

nen Editor mit der GenGED Editor Basisklasse ‘AbstractEditor’, welcher in die

VL-Umgebung integriert wird (siehe Kap. 4.5). Nachdem die VL-Spezifikation

in die VL-Umgebung geladen wurde, werden die Animationsschritte (‘Anim-

Step’) im Baummodell (‘AnimEnvModel’) der Animationsumgebung grafisch

dargestellt, welches vom GenGED Standard-Baummodell (‘GenGEdDefault-

TreeModel’) abstammt.

Die Animationsumgebung korrespondiert mit dem ‘StepEvaluator’, welcher

eine Hilfsklasse zur interaktiven Animationsschrittausfuhrung darstellt: Der

‘StepEvaluator’ fuhrt die Animationsschritte (‘AnimStep’) in Java Threads

aus, wodurch die Animationsschrittausfuhrung von der Animationsumgebung

aus kontrolliert und ggf. unterbrochen werden kann. Der ‘StepEvaluator’ be-

nutzt den ‘AEEvaluator’ als Basisklasse zur Auswertung der Animationsopera-

tionen.

In der Abb. 4.16 ist ein Sequenzdiagramm dargestellt, welches den Ablauf

50 Entwurf

Abbildung 4.16: Sequenzdiagramm zur Animationsschrittauswertung in derAnimationsumgebung

einer Animationsschrittauswertung in der Animationsumgebung graphisch dar-

stellt. Voraussetzung ist, das der Benutzer eine VL-Spezifikation mit Anima-

tionsschrittspezifikation und ein Start-Diagramm in die VL-Umgebung geladen

und die Animationsumgebung aktiviert hat. Zu Beginn ruft der Benutzer (User)

die ‘ResetAnimation’ Editoraktion auf, um die Animationsauswertung auf den

Initialzustand zuruckzusetzen, falls er vorher schon Animationsschritte aus-

gefuhrt hat. Die Animationsumgebung (‘AnimationEnvironment’) ruft zur In-

itialisierung die Methode ‘initAnimOperationEvaluation’ aus der Klasse ‘AEE-

valuator’ auf, welche alle initialen grafischen Objekte (‘ACObjects’) bei der

Animationskomponente (‘AnimComponent’) mit der Methode ‘addACObject()’

4.5 VL-Umgebung 51

registriert. Der Benutzer fuhrt nun einen oder mehrere Animationsschritte aus,

indem er durch selektion des entsprechenden Toolbuttons bzw. Menupunktes

eine ‘Step’ Editoraktion auslost. Fur jeden Animationsschritt erzeugt die Ani-

mationsumgebung einen neuen ‘StepEvaluator’, welcher den Animationsschritt

in Java Threads ausfuhrt. Die Methode ‘evaluate’ fuhrt die Auswertung im

‘AEEvaluator’ durch. Der ‘AEEvaluator’ wertet die Animationsoperationen mit

‘evaluateAnimOperations()’ wahrend der Ausfuhrung des Animationsschritts

im Hintergrund aus und registriert die entsprechend Operationen mit ‘addA-

COperation()’ bei der Animationskomponente. Neu hinzugekommene grafische

Objekte werden ebenfalls bei der Animationskomponente registriert, was hier

nicht dargestellt ist. Nachdem die Ausfuhrung der Animationsschritte beendet

ist, lost der Benutzer die ‘SVGExport’ Editoraktion aus. Die Animationsumge-

bung ruft die Methode ‘exportSVG(filename)’ der Animationskomponente auf.

Die Animationskomponente wertet nun alle registrierten graphischen Objekte

mit zugehorigen Animationsoperationen aus und speichert die Animation als

Offline-Animation in einer SVG-Animationsdatei.

4.5.2 Simulation als Basis fur die Animation

Grundlage fur die Animation ist die Simulation, d.h. der diskrete Ubergang vom

Start-Diagramm zum transformierten Diagramm (siehe Kap. 3.4.5). Als Ent-

wurfsentscheidung erweitert die Animation nicht die Simulationsklassen, son-

dern stellt einen eigenen Bereich dar (siehe Kap. 3.4.7), welcher die gesamte

Funktionalitat der Simulation besitzt und entsprechend fur die Animation er-

weitert.

In der Animationsumgebung (siehe Kap. 4.5.1) wird bei der Ausfuhrung eines

Animationsschrittes (der mehrere Animationsregeln beinhalten kann) der Ani-

mationsschritt zunachst wie ein Simulationsschritt behandelt. Das ist moglich,

da ein Animationsschritt wie ein Simulationsschritt mit zusatzlichen Anima-

tionsoperationen (welche das dynamische Verhalten reprasentieren) behandelt

werden kann. Wahrend der Animation wird bei jeder Regelanwendung der Re-

gelmorphismus (‘RuleMorphism’), der ‘Match’ und der ‘Comatch’ in der Klasse

‘AEEvaluator’ (siehe Kap. 4.5.1) mitprotokolliert und anschließend ausgewertet

52 Entwurf

(siehe Abb. 4.17).

L R

D’DDiagramm:

Regel:

Match Comatch

Regelmorphismus

Transformation

Abbildung 4.17: Transformation

Dabei liefert der ‘Match’ die Zuordnung der grafischen Objekte aus der linken

Regelseite L zu den grafischen Objekten in Start-Diagramm D. Analog liefert

der ‘Comatch’ die Zuordnung der grafischen Objekte aus der rechten Regelseite

R zu dem transformierten Diagramm D’.

4.5.3 Auswertung der Animationsoperationen

Die Animationsoperationen beziehen sich immer auf grafische Objekte in einer

Animationsregel, welche mittels Referenzobjekten der Animationsregel zugeord-

net werden (siehe Kap. 4.3.5). Bei der Animation mussen die Animationsopera-

tionen allerdings auf die grafischen Objekte im Diagramm angewendet werden.

Aus diesem Grund wird die Zuordnung wahrend der Graphtransformation mit-

protokolliert (siehe Kap. 4.5.2). Anschließend werden der eigenstandigen Ani-

mationskomponente (siehe Kap. 4.6) die Daten der Animationsoperationen zur

Auswertung ubergeben.

Dabei wird jedes referenzierte ‘SymbolObject’ und ‘DatatypeObject’ (siehe

Kap. 4.3.5) ausgewertet: Eine Animationsoperation wird auf alle primitiven

grafischen Objekte, welche sich im referenzierten ‘SymbolObject’ bzw. ‘Dataty-

peObject’ befinden, angewendet.

Absolute Koordinaten der grafischen Objekte durfen allerdings erst nach dem

Layouten des transformierten Diagramms ausgewertet werden, da erst durch

den Layouter die grafischen Objekte an ihre richtige Position gebracht werden.

Durch die Anwendung von Referenzobjekten wird dieses Problem großtenteils

4.6 Eigenstandige Animationskomponente 53

umgangen. Problematisch gestaltet sich nur die Auswertung der ‘LinearMo-

ve’ Operation, da bei dieser Operation der Weg des zu animierende grafischen

Objektes uber Referenzobjekte festgelegt wird. Da auf die Position des Referen-

zobjektes und nicht auf die Position eines beliebigen primitiven grafischen Ob-

jektes in dem ‘SymbolObject’ bzw. ‘DatatypeObject’ referenziert wurde, wird

der eigenstandigen Animationskomponente die absolute Position des Referenz-

objektes ubergeben. Dies kann aus o.g. Grunden erst nach dem Layoutvorgang

geschehen.

4.6 Eigenstandige Animationskomponente

Die eigenstandige Animationskomponente reprasentiert den externen Teil des

Generators fur Animationsumgebungen. Sie ist unabhangig von einer konkreten

visuellen Entwicklungsumgebung und bekommt vom internen Teil des Genera-

tors die relevanten Daten zur Animation. Zur Offline-Animation speichert die

Animationskomponente die Animationsdaten in einem SVG-File, welches von

einem externen SVG-Viewer dargestellt werden kann (siehe Kap. 2.3.2).

Abbildung 4.18: Klassendiagramm zur Animationskomponente

Abb. 4.18 zeigt das grundlegende Klassenmodell der eigenstandigen Anima-

tionskomponente. Die Basisklasse ‘AnimComponent’ stellt dabei der visuellen

Entwicklungsumgebung die benotigten Operationen bereit. Grafische Objekte

54 Entwurf

werden durch die Basisklasse ‘ACObject’ reprasentiert. An grafischen Objekten

stehen u.a. ‘ACRectObject’ (Rechteckobjekt), ‘ACLineObject’ (Linienobjekt),

‘ACCircleObject’ (Kreisobjekt), ‘ACEllipseObject’ (Ellipsenobjekt) und ‘AC-

TextObject’ (Textobjekt) zur Verfugung. Eine Animationsoperation wird durch

die Basisklasse ‘ACOperation’ reprasentiert, welche mit einem ‘ACObject’ as-

soziert ist, auf welches sich die Operation bezieht. An Animationsoperationen

stehen u.a. ‘ACLinearMoveOperation’ (LinearMove) und ‘ACVisibilityOperati-

on’ (Visibility) zur Verfugung (siehe Kap. 4.3.2).

4.6.1 Animationsgenerierung

Zu Beginn wird die Animationskomponente initialisiert, indem die visuelle Ent-

wicklungsumgebung alle verwendeten grafischen Objekte bei der Animations-

komponente registriert. Anschließend registriert die visuelle Entwicklungsum-

gebung die Animationsoperationen bei der Animationskomponente. Nach be-

endeter Registrierung kann die visuelle Entwicklungsumgebung die Methode

‘exportSVG(String dateiname)’ der Klasse ‘AnimComponent’ aufrufen und die

Animationskomponente erzeugt selbststandig aus den erhaltenen Daten eine

SVG-Datei (siehe Kap. 2.3). Die Animation kann dann als Offline-Animation in

einem externen SVG-Viewer betrachtet werden.

Folgende Besonderheiten ergeben sich fur die Auswertung von mehreren se-

quenziellen Regeln bei der Offline-Animation:

• Zu Beginn werden alle grafischen Objekte des Start-Diagramms registriert.

• Grafische Objekte, die spater hinzukommen, werden mit einer internen

‘Visibility’ Animationsoperation versehen, welche sie bis zum jeweiligen

Zeitpunkt versteckt halt.

• Die Anfangszeiten von Animationsoperationen aus fruhreren Regeln wer-

den zu den Anfangszeiten von Animationsoperationen aus spateren Regeln

aufaddiert.

Online-Animation: Optional kann die Animationskomponente der visuellen


Entwicklungsumgebung konkrete Animationsdaten als kontinuierliche Positio-

nen und Parameter der grafischen Objekte liefern, wodurch die Animation als

Online-Animation in der visuellen Entwicklungsumgebung dargestellt werden

kann. Die Implementierung der Online-Animation ist allerdings nicht mehr Be-

standteil dieser Diplomarbeit. Die Animationskomponente kann aber leicht fur

die Online-Animation erweitert werden.

4.6.2 SVG-Animationsdatei

Die eigenstandige Animationskomponente erzeugt bei der Offline-Animation ei-

ne SVG-Animationsdatei. Dabei wird jedes grafische Objekt durch ein SVG-

Element reprasentiert. Dynamische Verhaltensweisen werden den grafischen Ob-

jekten durch zusatzliche Animationselemente zugewiesen.

Folgende grafische Grundelemente werden verwendet:

• <rect x="100" y="200" width="10" height="20"

style="fill:white; stroke:black"/>

Zeichnet ein Rechteck mit der linken oberen Ecke an der Position

‘(100,200)’, der Breite ‘10’ und der Hohe ‘20’ mit schwarzem Rand und

weißer Fullfarbe.

• <ellipse cx="100" cy="200" rx="10" ry="20"


Zeichnet eine Ellipse mit dem Mittelpunkt an der Position ‘(100,200)’ und

den Diagonalen ‘rx=10, ry=20’ mit schwarzem Rand und weißer Fullfarbe.

• <circle cx="100" cy="200" r="10"


Zeichnet einen Kreis mit dem Mittelpunkt an der Position ‘(100,200)’ und

dem Radius ‘r=10’ mit schwarzem Rand und weißer Fullfarbe.

• <line x1="100" y1="200" x2="150" y2="250"

stroke="black"/>

56 Entwurf

Zeichnet eine Linie mit dem Startpunkt ‘(100,200)’ und dem Endpunkt

‘(150,250)’ mit schwarzer Farbe.

• <text x="100" y="200">ready to remove</text>

Stellt den Text ‘ready to remove’ an Position ‘(100,200)’ dar.

Die Animationsoperationen werden in folgende Weise in Animati-

onselemente ubersetzt:

• LinearMove: Uber ‘animate’ Elemente werden die X- und Y-Positionen

uber die Zeit verandert. Beispielsweise verandert folgendes Animationsele-

ment die X-Position eines Objektes (‘attributeName=x’) in linearer Weise

von ‘from=10’ nach ‘to=20’. Startzeit ist dabei nach eine Sekunde (‘be-

gin=1.0’), die Dauer ist zwei Sekunden (‘dur=2.0’). Die Animation wird

einmal durchgefuhrt (‘repeatCount=1’) und bleibt nicht an der Zielposi-

tion stehen (‘fill=remove’).

<animate attributeName="x" attributeType="XML" begin="1.0"

dur="2.0" fill="remove" from="10"

repeatCount="1" to="20"/>

• ChangeColor: Uber das ‘animateColor’ wird die Farbe des Objektes

uber die Zeit als linearer Farbverlauf dargestellt. Folgendes ‘animateCo-

lor’ Element erzeugt einen Farbverlauf. Startfarbe ist dabei rot (Rot-

Grun-Blau-Kodierung ‘rbg(255,0,0)’). Zielfarbe ist schwarz (Rot-Grun-

Blau-Kodierung ‘rbg(0,0,0)’).

<animateColor attributeName="fill" attributeType="CSS"

begin="1.0" dur="2.0" from="rgb(255,0,0)"

to="rgb(0,51,51)" fill="remove"/>

• Resize: Uber ‘animate’ Elemente (siehe ‘LinearMove’) werden die Attri-

bute fur Breite und Hohe uber die Zeit verandert, indem der Zielwert mit

dem Zoomfaktor multipliziert wird.


• Visibility: Durch das ‘set’ Element wird dem Attribute ‘visibility’ der

Wert ‘hidden’ zugewiesen.

<set attributeName="visibility" attributeType="CSS"

begin="1.0" dur="2.0" to="hidden"

fill="remove"/>

Abb. 4.19 zeigt eine SVG-Animationsdatei mit Animationsdefinitionen fur

zwei Kreise, die jeweils einen Token in einem Petrinetz reprasentieren.

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"

"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd"><svg height="15cm" viewBox="0,0,810,461" width="20cm">

<circle cx="171" cy="325" id="LHS.Inst1:Token.Inst:Circle"r="4" style="stroke:black; fill:rgb(0,51,51)">

<animate attributeName="cx" attributeType="XML" begin="0.0"dur="3.0" fill="freeze" from="170.0" repeatCount="1" to="80.0"/>

<animate attributeName="cy" attributeType="XML" begin="0.0"dur="3.0" fill="freeze" from="324.0" repeatCount="1" to="219.0"/>

<set attributeName="visibility" attributeType="CSS" begin="3.0"dur="3.0" fill="remove" to="hidden"/>

</circle><circle cx="68" cy="71" id="RHS.Inst3:Token.Inst:Circle"

r="4" style="stroke:black; fill:rgb(0,51,51)"><animate attributeName="cx" attributeType="XML" begin="3.0"

dur="3.0" fill="freeze" from="80.0" repeatCount="1" to="183.0"/><animate attributeName="cy" attributeType="XML" begin="3.0"

dur="3.0" fill="freeze" from="219.0" repeatCount="1" to="130.0"/><set attributeName="visibility" attributeType="CSS" begin="0.0"

dur="3.0" fill="remove" to="hidden"/></circle>

</svg>

Abbildung 4.19: SVG-Animationsdatei

Die SVG-Animationsdatei beginnt mit einer Referenz zur SVG-DTD (Doku-

ment Type Definition), welche die grundlegende SVG-Sprachdefinition festlegt.

Im Element ‘svg’ sind als Attribute die Hohe und die Breite des Animations-

fensters angegeben. Ausserdem wird eine ‘viewBox’ spezifiziert, welche das Ko-

ordinatenspektrum festlegt, welches sich genau im sichtbaren Bereich befindet.

Das ‘circle’ Element definiert ein grafisches Objekt vom Typ ‘Kreis’ mit den

Attributen ‘cx’ und ‘cy’ fur die X- und Y-Position des Kreismittelpunktes. Mit

dem Attribut ‘id’ wird dem Kreis ein eindeutiger Identifier zugeordnet, womit

er jederzeit identifiziert werden kann. Das Attribut ‘r’ bezeichnet den Kreisradi-

us und ‘style’ legt verschiedene Attribute fur das Erscheinungsbild des Kreises

58 Entwurf

fest. Innerhalb des ‘circle’ Elements befinden sich jeweils zwei ‘animate’ Ele-

mente, welche eine lineare Animationsbewegung beschreiben. Sie beziehen sich

dabei jeweils auf dem Kreisparameter, welcher mit dem Attribute ‘attributeNa-

me’ referenziert wird. Die Attribute ‘begin’ und ‘dur’ legen Beginn und Dauer

der Animation fest. Die lineare Bewegung startet an der Position, die durch

‘from’ referenziert wird und endet bei der Position, die durch ‘to’ referenziert

wird. Das Attribut ‘repeatCount=1’ beschreibt, dass die Animation genau ein-

mal durchgefuhrt wird. Durch das Attribut ‘fill=freeze’ wird erreicht, dass das

Objekt nach der Animation an der Zielposition sichtbar bleibt. Die ‘Visibility’

Animationsoperation wird in analoger Weise vom ‘set’ Element definiert. Das

Attribut ‘to=hidden’ definiert dabei, dass das Objekt nicht angezeigt wird.

Abb. 4.20 zeigt die Animation der Token am Beispiel des Schaltvorgangs der

‘produce’ Transition: Zuerst bewegt sich der Anfangstoken entlang des gestri-

chelten Pfeils zum Mittelpunkt der Transition. Danach verschwindet er und der

Zieltoken erscheint an der gleichen Position, um sich anschließend zur unteren

Stelle entlang des gestrichelten Pfeils zu bewegen.

produce

Abbildung 4.20: Tokenanimation am Beispiel von ‘produce’

Kapitel 5

Implementierung

Aufgrund des Umfangs der einzelnen Komponenten ist es nicht sinnvoll, jede

einzelne Klasse mit allen Methoden umfassend zu besprechen. Hierzu sei auf die

API (Application Programing Interface) Dokumentation auf beiliegender CD-

ROM verwiesen. Die CD-ROM enthalt das komplette GenGED System. Eben-

falls enthalt die CD-ROM den kompletten Quellcode aller Komponenten. Ein

Installationsprogramm und ein Makefile zum Kompilieren der Komponenten ist

ebenfalls vorhanden. Fur eine ausfuhrliche Beschreibung sei auf die README-

Datei der beiliegenden CD-ROM verwiesen.

5.1 Paketstruktur und -versionen

Folgende Programmpakete werden verwendet:

• Java Version 1.4 [Sun03].

• DiaGen Version 2.1 [Min01].

• ‘CSIRO SVG Toolkit’ mit der Versionsnummer: ‘20020312’ (Release vom

12.03.2002) [SVG02].

• Die bisherige GenGED Version 0.9 [BEWE03], welche folgende Pro-

grammpakete benutzt:

60 Implementierung

– AGG Version 1.1.0 [TRS03];

– Colim Version 1.0 [Wol97];

– JGL – Java Generic Library – Version 3.1.0 [RS01];

– ParCon Version 11.8 [Gri96];

– Xerces Version 1.2.0 [Apa01].

Im Rahmen dieser Diplomarbeit wurde das GenGED System zur

Version 1.0 erweitert. Es ist in Java Version 1.4 implementiert und

beinhaltet zum gegenwartigen Stand folgende Programmpakete:

• AGG Version 1.1.0 [TRS03];

• Colim Version 1.0 [Wol97];

• DiaGen Version 2.1 [Min01];

• JGL – Java Generic Library – Version 3.1.0 [RS01];

• ParCon Version 11.8 [Gri96];

• Xerces Version 1.2.0 [Apa01].

Ausserdem verwendet das GenGED System die ‘Eigenstandige Animati-

onskomponente – Version 1.0’, welche in dieser Diplomarbeit neu konzipert

und in Java Version 1.4 implementiert wurde.

Bis auf den Constraintssolver ParCon, welcher nur als kompiliertes Pro-

gramm fur Linux oder Sun OS(TM) erhaltlich ist, sind alle verwendeten Pro-

grammpakete in Java implementiert und mit der aktuellen Java Version 1.4

kompatibel.

Zur Darstellung der SVG-Animationsdatei wird in dieser Diplomarbeit das

CSIRO SVG Toolkit in der derzeit aktuellen Version vom 12.03.2002 (Ver-

sionsnummer: 20020312) verwendet, welches frei inklusive Quellcode erhaltlich

ist [SVG02].

Die Paketstruktur der neu implementierten Komponenten gliedert

sich in folgende Teile:

5.2 Grafische Benutzerschnittstellen 61

• animcomp: Die eigenstandige Animationskomponente.

– animcomp.object: Grafische Objekte.

– animcomp.operation: Animationsoperationen.

– animcomp.svg: SVG-Export (Offline-Animation).

• genged.petrilayouter: Der Petrinetz Layouter.

• genged.animrule: Die GenGED Animationsoperationen mit der zu-

gehorigen Animationsregelspezifikation.

• genged.animstep: Die Animationsschrittspezifikation mit den Kompo-

nenten zur Transformationsauswertung.

• genged.gui.animation: Die GUI-Komponenten zur Definition eines Ani-

mationsschritts im VL-Spezifikationseditor.

• genged.gengededitor.animeditor: Der Animationsregeleditor.

• genged.gengededitor.animenvironment: Die Animationsumgebung

als Editorkomponente der VL-Umgebung.

• genged.gengededitor.vlenvironment: Erweiterung der VL-Umgebung

um die Animationsumgebung.

• genged.gengededitor.vlspeceditor: Erweiterung um die Animations-

schrittdefinition.

5.2 Grafische Benutzerschnittstellen

Im folgenden werden die Implementierungen der einzelnen grafischen Benut-

zerschnittstellen anhand des Beispieles der Regel ‘produce’ des ‘Producer-

Consumer-Systems’ vorgestellt.

62 Implementierung

5.2.1 Animationsregeleditor

Abb. 5.1 zeigt den Animationsregeleditor mit geladener Simulationsgramma-

tik fur das ‘ProducerConsumerSystem’ (siehe Kap. 2.2.2 und 2.2.4). In der

Baumdarstellung (links) werden die Regeln ‘produce’, ‘deliver’, ‘remove’ und

‘consume’ angezeigt.

Abbildung 5.1: Animationsregeleditor mit Regel ‘produce’

Selektiert ist die Regel ‘produce’, welche im Animationsregel-Display (rechts

oben) in der kombinierten Animationsregeldarstellung (siehe Kap. 4.3.1) prasen-

tiert wird. Dargestellt ist der Token der linken Regelseite (‘LHS:Inst:Token’),

welcher sich in der Stelle mit dem Namen ‘ready to produce’ befindet. Im

Editor ist er rot gezeichet, um ihn als ein veranderliches Element der lin-

ken Regelseite hervorzuheben. Außerdem ist der Token der rechten Regelseite

(‘RHS:Inst:Token’), welcher sich in der Stelle mit dem Namen ‘ready to deliver’

befindet, als veranderliches Element der rechten Regelseite grun hervorgehoben.


Unter dem Animationsregel-Display befindet sich die Zeitleiste (TimeLine),

welche zwei Animationsoperationen fur den linken Token und zwei fur den rech-

ten Token als Balken (in der Farbe der Token) grafisch darstellt. Der Benutzer

kann diese Balken horizontal bewegen und damit den Beginn der Animations-

operationen festlegen. Außerdem kann er die Balkenlange andern, indem er den

Balken am rechten Ende selektiert und mit der Maus kleiner oder großer zieht.

Somit legt er die Dauer der Animationsoperationen fest. Zusatzlich sind die

Animationsoperationen auch noch in der Baumdarstellung (links) aufgefuhrt.

In der Baumdarstellung ist gerade die Animationsoperation ‘LinearMove’

fur den linken Token selektiert. Zu dieser LinearMove-Operation wird im

Animationsregel-Display der Pfad, den der Token bei der Animation zuruck-

legt, durch einen blauen Pfeil angezeigt. In diesem Fall hat der Benutzer einen

Pfad zu der Stelle ‘produce’ festgelegt, indem er, nachdem er die LinearMove-

Aktion im Menu unter ‘Animate’ aktiviert hatte, zuerst das Startobjekt (den

Token) und dann das Zielobjekt (die Transition) mit der linken Maustaste se-

lektiert hat. Die Pfaddefinition wurde mit einem Doppelklick abgeschlossen.

Ansonsten hatten nacheinander auch noch andere Objekte als Pfadpositionen

selektiert werden konnen.

Zusammenfassend besteht die Animationsdefinition fur die Regel

‘produce’ aus folgenden Animationsoperationen:

• Bewege den Token der linken Regelseite (‘LHS:Inst:Token’) von der Stelle

mit dem Namen ‘ready to produce’ zu der Transition vom Zeitpunkt 0

Sekunden bis zum Zeitpunkt 3 Sekunden (gerechnet ab Beginn der Re-

gelanwendung).

• Verstecke den Token der linken Regelseite (‘LHS:Inst:Token’) vom Zeit-

punkt 3 Sekunden bis zum Zeitpunkt 6 Sekunden.

• Bewege den Token der rechten Regelseite (‘RHS:Inst:Token’) von der

Transition zur der Stelle mit dem Namen ‘ready to deliver’ vom Zeitpunkt

3 Sekunden bis zum Zeitpunkt 6 Sekunden.

• Verstecke den Token der rechten Regelseite (‘RHS:Inst:Token’) vom Zeit-

64 Implementierung

punkt 0 Sekunden bis zum Zeitpunkt 3 Sekunden.

Damit ist die Animationsdefinition fur die Regel ‘produce’ abgeschlossen und

sie kann in der Animationsregelspezifikation gespeichert werden. In gleicher

Weise lassen sich Animationsoperationen fur die Regeln ‘deliver’, ‘remove’ und

‘consume’ definieren, welche ebenfalls in der Animationsregelspezifikation ge-

speichert werden. Ein Beispiel fur eine Animationsregelspezifikation mit der

Regel ‘produce’ ist im Kap. 4.3.5 aufgefuhrt.

5.2.2 VL-Spezifikationseditor

Abb. 5.2 zeigt den VL-Spezifikationseditor mit geladener Animationsregelspe-

zifikation fur das ‘Producer-Consumer-System’ (siehe Kap. 5.2.1).

Abbildung 5.2: VL-Spezifikationseditor

Nachdem das Petrinetz-Alphabet in den alten Syntax-Teil des VL-

Spezifikationseditors geladen wurde, konnte eine neue Animationsschrittspezi-

fikation angelegt werden, indem im Menu ‘Edit’ ‘New animation specification’

gewahlt wurde. Die Animationsschrittspezifikation wurde mit ‘ProducerConsu-

mer’ benannt. Anschließend wurde die Animationsregelspezifikation durch einen

Mausklick auf den Button ‘Open’ geladen. Der Spezifikationsname wird im Edi-

tor angezeigt. Zuletzt wurde ein Animationsschritt ‘produce’ definiert, der genau


die Animationsregel ‘produce’ ausfuhrt. Analog werden Animationsschritte fur

‘deliver’, ‘remove’ und ‘consume’ definiert. Ebenfalls ist es moglich einen Anima-

tionsschritt zu definieren, der einen sequenziellen Ablauf der Animationsregeln

‘produce’, ‘deliver’, ‘remove’ und ‘consume’ spezifiziert. Hierzu wird ein AND-

Animationsausdruck definiert, welcher die vier Regeln beinhaltet (siehe Kap.

4.4.2).

Die gesammelten Definitionen werden in der VL-Spezifikation gespeichert.

Hierzu wurde die VL-Spezifikation um die Animationsschrittspezifikation erwei-

tert. Ein Beispiel fur eine VL-Spezifikation mit Animationsschrittspezifikation

fur ‘produce’ ist im Kap. 4.4.1 aufgefuhrt.


Abb. 5.3 zeigt die Animationsumgebung als Teileditor der VL-Umgebung, in-

der der eigentliche Animationsablauf stattfindet. In die VL-Umgebung wurde

die VL-Spezifikation fur die Animation des ‘ProducerConsumerSystems’ (sie-

he Kap. 5.2.2) geladen und die Animationsumgebung durch einen Toolbutton

aktiviert.

Ausserdem wurde in der Animationsumgebung noch ein Start-Diagramm fur

die Animation geladen: in unserem Fall das ‘ProducerConsumerSystem’ im in-

itialen Zustand mit jeweils einem Token auf den Stellen mit den Namen ‘ready

to produce’, ‘buffer empty’ und ‘ready to remove’.

Im linken Teil der Animationsumgebung werden die zuvor in der VL-

Spezifikation definierten Animationsschritte angezeigt, in unserem Fall die Ani-

mationsschritte ‘produce’, ‘deliver’, ‘remove’ und ‘consume’.

Jetzt kann z.B. der Animationsschritt ‘produce’ ausgefuhrt werden, indem

der Toolbutton ‘Execute an animation step’ angeklickt wird. In der Offline-

Animation, die momentan implementiert ist, findet in der Animationsumgebung

eine Simulation statt. D.h. in unserem Fall springt der Token in der Animations-

umgebung von der Stelle mit dem Namen ‘ready to produce’ zu der Stelle mit

dem Namen ‘ready to deliver’. In der Klasse ‘genged::animstep::AEEvaluator’

werden u.a. in den Methoden ‘evaluateMatch()’ und ‘evaluateComatch()’ die

66 Implementierung

Abbildung 5.3: Animationsumgebung

Daten aus den Transformationen der Simulation ausgewertet (siehe Kap. 4.5.2)

und die an der Animation beteiligten Objekte und Operationen bei der ei-

genstandige Animationskomponente registriert (siehe Kap. 4.5.3). Durch ak-

tivieren des Button ‘Export animation step to SVG’ erzeugt die eigenstandi-

ge Animationskomponente eine SVG-Animationsdatei, welche in einem SVG-

Viewer ausgefuhrt werden kann.

Abb. 5.4 zeigt einen Ausschnitt aus dem Ablauf der Animation der Regel

‘produce’ im SVG-Viewer des SVG-Toolkits [SVG02]. Ein Beispiel fur eine SVG-

Animationsdatei fur ‘produce’ ist im Kap. 4.6 aufgefuhrt.

5.3 GenGED Layouter fur Petrinetze

Fur das GenGED Alphabet fur Stellen-Transitions Petrinetze (siehe Kap.

2.2.1) ist ein effizienter Layouter auf Grundlage des Entwurfs (siehe Kap. 4.2)

implementiert. Der Layouter ist vollstandig in Java implementiert und benotigt


Abbildung 5.4: Animation im SVG-Viewer

keinen externen Constraintsolver.

Der Layouter ist speziell fur das gegebene Petrinetz Alphabet konzipiert.

Sobald das Alphabet verandert wird, muss die Implementierung des Layouters

angepasst werden. Auf Grundlage des Petrinetz-Layouters konnen Layouter fur

andere GenGED Alphabete implementiert werden.

Der Einsatz von VL-spezifischen Layoutern wird als Zwischenlosung angese-

hen. Momentan wird an der Verbesserung der Leistungsfahigkeit des in Gen-

GED verwendeten Constraintsolvers gearbeitet, so dass das Layout von VL-

Diagrammen in Form von VL-Constraints definiert werden kann.

5.4 Eigenstandige Animationskomponente

Die Einbindung der eigenstandigen Animationskomponente in die visuelle Ent-

wicklungsumgebung besteht aus folgenden Schritten:

68 Implementierung

• Registrierung aller beteiligten grafischen Objekte. Hierzu wer-

den jeweils Instanzen der Objektklassen, welche sich im Package ‘anim-

comp::object’ befinden, von der visuellen Entwicklungsumgebung erzeugt

und mit der entsprechenden Methode der Klasse ‘AnimComponent’ regis-

triert.

• Registrierung aller beteiligten Animationsoperationen. Hierzu

werden jeweils Instanzen der Objektklassen, welche sich im Package ‘anim-

comp::operation’ befinden, von der visuellen Entwicklungsumgebung er-

zeugt und mit der entsprechenden Methode der Klasse ‘AnimComponent’

registriert.

• Offline-Animation: Durch Aufruf der Methode ‘exportSVG(String fi-

lename)’ aus der Klasse ‘AnimComponent’ wird durch die Animations-

komponente eine SVG-Animationsdatei erzeugt, welche in einem externen

SVG-Viewer dargestellt werden kann.

• Online-Animation: Die Online-Animation wurde im Rahmen dieser Di-

plomarbeit nicht mehr implementiert.

Bezuglich der Beschreibung der einzelnen Methoden sei auf die API Doku-

mentation der beiligenden CD-ROM verwiesen.

Kapitel 6

Benutzerhandbuch

Das Benutzerhandbuch ist eine Erganzung der vorhandenen Benutzer-

handbucher fur das bestehende GenGED System auf der GenGED Homepage

[BEWE03]. Es beschreibt alle neuen Komponenten und die Erweiterungen des

bestehenden GenGED Systems.

Als Beispiel wird hierbei das ‘Kuchen-Szenario’ als anwendungsorientierte

Sicht (Szenario-View) des ‘Producer-Consumer-Systems’ verwendet (siehe Kap.

2.2.5).

6.1 Installation und Start

GenGED wurde unter den Betriebssystemen SuSE Linux(TM) [SuS03] und So-

laris(TM) (SunOS(TM)) entwickelt und getestet. Teile des GenGED Systems

benutzen den Constraintsolver ParCon [Gri96], welcher nur fur Linux und So-

laris erhaltlich ist. Unter SuSE Linux(TM) mussen die alten C-Bibliotheken

(Alte Version 5) zur Installation von ParCon installiert werden, welche sich

bei SuSE Linux(TM) im Paket ‘shlibs5’ befinden.

Bezuglich der Hardware werden keine besonderen Voraussetzungen gefordert.

Damit GenGED zufriedenstellend lauft, wird ein Hauptspeicher von mindes-

tens 256MB RAM empfohlen.

Das GenGED Paket enthalt alle verwendeten Bibliotheken inklusive des

70 Benutzerhandbuch

Constraintsolvers ParCon als Binarcode fur Linux und Solaris(TM). Voraus-

setzung ist nur eine lauffahige Java Entwicklungsumgebung (SDK) ab der Ver-

sion 1.4 [Sun03], um den Quellcode zu ubersetzen. Ansonsten ist das Java Run-

time Environment ab der Version 1.4 ausreichend.

6.1.1 Konfiguration

Um die GenGED Installation an das aktuelle System anzupassen, muss das

Shellskript ‘configure’ mit

$ ./configure

im GenGED Stammverzeichnis ausgefuhrt werden.

6.1.2 Ubersetzen des Quellcodes

Das Makefile fur GNU-Make wird vom ‘configure’ Shellskript generiert.

Es definiert folgende Ziele:

• genged: Ubersetzt die GenGED Java Klassen. Die kompilierten Dateien

werden unter ‘./bin/genged’ erzeugt.

• animcomp: Ubersetzt die Java Klassen der eigenstandigen Animations-

komponente. Die kompilierten Dateien werden unter ‘./bin/animcomp’

erzeugt.

• doc: Erzeugt die API Dokumentation aus den Kommentaren im Quellco-

de mittels ‘javadoc’.

• world: Synonym fur ‘make genged animcomp doc’.

• clean: Loscht samtliche von ‘make world’ erzeugten Dateien.

• clean genged: Loscht samtliche von ‘make genged’ erzeugten Dateien.

• clean animcomp: Loscht samtliche von ‘make animcomp’ erzeugten Da-

teien.

6.2 Ablauf der Animationserstellung 71

• (default): Synonym fur ‘make genged animcomp’.

6.1.3 Programmstart

Der Start des GenGED Systems erfolgt durch Aufruf von

$ ./bin/GenGEd

im GenGED Stammverzeichnis.

Das Skript startet selbststandig den Java-Interpreter. Wird der Parameter

‘−−vlenvironment’ ubergeben, so wird nur die VL-Umgebung von GenGED

gestartet.

6.2 Ablauf der Animationserstellung

Folgender Ablauf ergibt sich fur den Benutzer fur die Animationserstellung in

der GenGED Umgebung.

Mit der bisherigen GenGED Umgebung werden erstellt:

1. Ein visuelles Alphabet.

2. Eine modellspezifische Simulationsgrammatik.

3. Ein Start-Diagramm uber dem Alphabet.

Fur die Animationsgenerierung ergibt sich folgender Arbeitsablauf:

1. Animationsregeleditor in GenGED:

(a) Laden der modellspezifischen Simulationsgrammatik.

(b) Definition von Animationsoperationen zu den Regeln der Simulati-

onsgrammatik.

(c) Speichern der Animationsgrammatik (d.h. Simulationsgrammatik

mit Animationsoperationen) als Animationsregelspezifikation.

72 Benutzerhandbuch

2. VL-Spezifikationseditor in GenGED:

(a) Erstellen bzw. Laden einer VL-Spezifikation.

(b) Laden der Animationsregelspezifikation.

(c) Definition der Animationsschritte.

(d) Speichern der neu erstellten bzw. erweiterten VL-Spezifikation.

3. VL-Umgebung in GenGED:

(a) Laden der VL-Spezifikation.

(b) Aktivieren der Animationsumgebung.

(c) Laden des Start-Diagramms in die Animationsumgebung.

(d) Ausfuhren der Animationsschritte in der Animationsumgebung.

(e) Speichern des generierten Animationsablaufes in SVG.

4. SVG-Viewer:

(a) Laden der SVG-Datei in den SVG-Viewer.

(b) Betrachten der Animation.

Der Arbeitsablauf kann an jeder Stelle unterbrochen werden und es kann zu

einem vorherigen Punkt zuruckgekehrt werden.

6.3 Animationsregeleditor

Die GUI des Animationsregeleditors ist in Abb. 6.1 dargestellt.

Der Animationsregeleditor gliedert sich in drei Bereiche:

1. Die Baumdarstellung der Animationsregeln mit den zugehorigen Anima-

tionsoperationen auf der linken Seite.

2. Die Darstellung einer Animationsregel in der Regeldarstellung rechts oben.

3. Die grafische Darstellung der zeitlichen Abfolge der Animationsoperatio-

nen in der Zeitleiste rechts unten.


Abbildung 6.1: Animationsregeleditor

6.3.1 Menu

Das Menu des Animationsregeleditors besteht aus folgenden Punk-

ten:

• File:

– New: Erzeugt eine neue Animationsregelspezifikation, indem eine

Simulationsgrammatik uber ein Dialogfenster geoffnet wird.

– Open animation rule specification: Offnet eine bestehende Ani-

mationsregelspezifikation uber ein Dialogfenster.

– Save animation rule specification: Speichert die aktuelle Anima-

tionsregelspezifikation.

– Save animation rule specification as: Speichert die aktuelle Ani-

mationsregelspezifikation unter einem neuen Dateinamen, der uber

ein Dialogfenster ausgewahlt wird.

74 Benutzerhandbuch

– Exit program: Beendet das GenGED System.

• Edit:

– Undo: Macht die letzte Benutzeraktion im Editor ruckgangig.

– Redo: Wiederholt eine ruckgangig gemachte Aktion.

– Remove: Loscht die selektierte Animationsoperation.

• Animate:

– Linear Move: Startet die Definition der ‘LinearMove’ Animations-

operation.

– Change Color: Startet die Definition der ‘ChangeColor’ Animati-

onsoperation.

– Resize: Startet die Definition der ‘Resize’ Animationsoperation.

– Visibility: Startet die Definition der ‘Visibility’ Animationsoperati-

on.

• Extras:

– Language: Legt die Landessprache fur das GenGED System fest.

– Save properties when exit: Wenn selektiert, werden die Parame-

ter bei Verlassen des GenGED Systems gespeichert.

• Help:

– Contents: Aktiviert die Online-Hilfe.

Die meisten Menuoptionen konnen auch uber die Toolbar (direkt unter dem

Menu) aktiviert werden. Dabei erscheint ein entsprechender Hilfetext zum je-

weiligen Toolbutton in der Statusleiste am unteren Rand des Editors, wenn der

Benutzer seinen Mauszeiger uber den Toolbutton bewegt.


6.3.2 Definition von Animationsoperationen

Nachdem eine Regel in der Baumdarstellung selektiert wurde, wird sie in der

Regeldarstellung angezeigt. Symbole, die bei der Regelanwendung nicht erhal-

ten bleiben, werden optisch besonders hervorgehoben. Dabei werden die An-

fangssymbole, d.h. die veranderlichen Symbole vor der Regelanwendung, rot

dargestellt. Analog werden die Symbole Endsymbole, d.h. die veranderlichen

Symbole nach der Regelanwendung, grun dargestellt. Eine Animationsoperati-

on kann nun fur ein rotes Anfangs- oder ein grunes Endsymbol definiert werden:

Hierzu wird die gewunschte Animationsoperation aus dem ‘Animate’ Menu aus-

gewahlt. Danach wird das gewunschte Anfangs- oder Endsymbol, auf das sich

die Animationsoperation beziehen soll, mit der linken Maustaste in der Re-

geldarstellung selektiert.

Die weiteren Aktionen sind spezifisch fur die entsprechende Ani-

mationsoperation:

• Linear Move: Mit der linken Maustaste wird in der Regeldarstellung

ein Pfad selektiert, uber den sich das Anfangssymbol bei der Animation

bewegen soll. Die Pfadselektion wird durch einen Doppelklick mit der

linken Maustaste abgeschlossen. Der selektierte Pfad wird durch blaue

Pfeile in der Regeldarstellung angezeigt. Analog wird der Pfad fur ein

Endsymbol ruckwarts, d.h. mit dem Endsymbol beginnend, selektiert.

• Change Color: Ein Dialogfenster erscheint, indem die Farbe ausgewahlt

wird, in die sich die Zielfarbe des Anfangssymbols bzw. die Quellfarbe des

Endsymbols bei der Animation verandern soll.

• Resize: Ein Dialogfenster erscheint, in dem die Großenanderung in Pro-

zent der aktuellen Große angegeben wird.

• Visibility: Bei dieser Operation sind keine weiteren Definitionen erfor-

derlich.

Bei der Definition von Animationsoperationen sollte beachtet werden, dass

das Layout nach Ablauf der Animation dem (per Simulationsregel) transfor-

76 Benutzerhandbuch

mierten Diagramm entspricht, wobei der Layouter dann evtl. andere Positionen,

Farben oder Großen fur die grafischen Objekte vergibt, als in den Animations-

operationen angegeben wurden. Hier kann es zu Sprungen zwischen dem Ende

der Animation und der Darstellung des transformierten Diagramms kommen,

wenn layoutspezifische Veranderungen bei der Animationsdefinition nicht be-

achtet werden. Die Einbettung der diskreten Simulationsschritte in den Anima-

tionsablauf bleibt bei jeder Animationsdefinition erhalten, so dass das Resultat

eines Simulationsschrittes bei der Animationsdefinition miteinbezogen werden

sollte. Beispielsweise sollte die Endposition eines Linear-Move-Pfades mit der

relativen Position ubereinstimmen, an der sich das Symbol nach Regelanwen-

dung befindet.

Nach dem Abschluss der Definition der Animationsoperationen erscheint die

entsprechende Operation in der Baumdarstellung der Animationsregeln und in

der Zeitleiste. Die Startzeit fur die Animationsoperation kann nun in der Zeit-

leiste durch horizontale Bewegung des Balkens mit der linken Maustaste erfol-

gen. Die Dauer einer Animationsoperation wird ebenfalls in der Zeitleiste durch

Stauchen oder Strecken des Balkens festgelegt. Hierzu selektiert der Benutzer

den Balken am rechten Ende mit der linken Maustaste.

Nach erfolgter Definition aller erforderlichen Animationsoperationen kann die

Animationsregelspezifikation in einer Datei gespeichert werden.

6.4 VL-Spezifikationseditor

Der bestehende VL-Spezifikationseditor wird um eine Dialogumgebung zur Ani-

mationsschrittdefinition erweitert.

Die GUI des VL-Spezifikationseditors ist in Abb. 6.2 dargestellt.

Nachdem ein Alphabet in die Syntax-Definition geladen wurde, kann mit

dem Menupunkt ‘New animation step specification’ im ‘Edit’ Menu eine neue

Animationsschrittdefinition erstellt werden.

Abb. 6.3 zeigt die Animationsschrittdefinition fur den Schritt ‘completeRun’

aus Abb. 6.2, welche nach Mausklick auf den ‘Edit’ Button erscheint. In der Ani-


Abbildung 6.2: Animationsschrittdefinition im VL-Spezifikationseditor

mationsschrittdefinition konnen beliebige Animationsausdrucke uber den Ani-

mationsregeln definiert werden (siehe Kap. 6.4.1). In unserem Fall wurde ein

AND-Ausdruck als Sequenz von ‘produce’, ‘deliver’, ‘remove’ und ‘consume’

definiert.

Die Dialogelemente zur Definition eines Animationsschritts sind die Gleichen

wie bei der Definition eines Simulationsschritts, weshalb sie hier nicht naher

erlautert werden.

Nach erfolgter Animationsschrittdefinition wird diese als Animationsschritt-

spezifikation in die bestehende VL-Spezifikation integriert und mit dieser ge-

speichert.

6.4.1 Animationsausdruck

Ein Animationsschritt wird uber einem Animationsausdruck definiert. Im ein-

fachsten Fall besteht dieser Ausdruck nur aus einer Regelanwendung. Es lassen

sich analog zu den Simulationsausdrucken folgende Animationsausdrucke im

VL-Spezifikationseditor definieren:

• Startsymbol: Expression. Die Definition eines Ausdrucks beginnt immer

mit einer Expression, aus beliebige Ausdrucke abgeleitet werden konnen.

78 Benutzerhandbuch

Abbildung 6.3: Definition von Animationsausdrucken im VL-Spezifikationseditor

• Expression→ RULE. Eine Expression kann direkt in eine Animationsregel

RULE abgeleitet werden. Wenn sich wahrend der Animation eine gultige

Transformation mit der Animationsregel durchfuhren lasst, wird ‘wahr’

und anderenfalls ‘falsch’ zur weiteren Auswertung zuruckgeliefert.

• Expression → AND Expressions. Eine Expression kann in eine sequenzi-

elle Liste von Expressions abgeleitet werden, wobei alle Expressions aus-

gewertet werden, bis eine Expression den Wert ‘falsch’ zuruckliefert. Der

Ruckgabewert des AND-Ausdrucks ist ‘wahr’, wenn die Auswertung von

alle Expressions ‘wahr’ ergeben hat, anderenfalls ist er ‘falsch’.

• Expression → OR Expressions. Eine Expression kann in eine sequenzielle

Liste von Expressions abgeleitet werden, wobei so lange eine Expressi-

on aus der Liste der Expressions ausgewertet wird, bis eine Expression

den Wert ‘wahr’ zuruckliefert. Der Ruckgabewert des OR-Ausdrucks ist

‘wahr’, wenn die Auswertung einer Expression ‘wahr’ ergeben hat, ande-

6.5 Animationsumgebung 79

renfalls ist er ‘falsch’.

• Expression → WHILE Condition Do. Eine Expression kann in einen

WHILE-Ausdruck abgeleitet werden, wobei ‘Condition’ und ‘Do’ jeweils

eine Expression darstellen. Die Expression ‘Do’ wird solange ausgewer-

tet, wie ‘Condition’ den Wert ‘wahr’ zuruckliefert. Zu beachten ist, dass

an dieser Stelle eine Endlosscheife entsteht, wenn ‘Condition’ immer den

Wert ‘wahr’ zuruckliefert.

• Expression → IF Condition Then Else. Eine Expression kann in einen IF-

Ausdruck abgeleitet werden, wobei ‘Condition’, ‘Then’ und ‘Else’ jeweils

eine Expression darstellen. Wenn die Auswertung von ‘Condition’ den

Wert ‘wahr’ zuruckliefert, wird ‘Then’ ausgewertet, anderenfalls ‘Else’.

6.5 Animationsumgebung

Die bestehende VL-Umgebung wird um eine Animationsumgebung erweitert.

Dabei stellt die Animationsumgebung einen eigenen Teileditor bereit, welcher

analog zur Simulationsumgebung in die VL-Umgebung integriert ist.

Abbildung 6.4: Animationsumgebung

Die GUI der Animationsumgebung ist in Abb. 6.4 dargestellt.

80 Benutzerhandbuch

Nachdem in der VL-Umgebung die VL-Spezifikation mit der Animations-

schrittspezifikation geladen wurde, kann durch den Toolbutton ‘Switch to the

animation mode’ in die Animationsumgebung gewechselt werden. In dieser wer-

den die Animationsschritte in der Baumdarstellung in der linken Editorhalfte

dargestellt. Durch den Menupunkt ‘Open Diagram’ im ‘File’ Menu wird ein

neues Start-Diagramm geladen, welches in der rechten Editorhalfte dargestellt

wird.

Das Menu der Animationsumgebung entspricht dem Menu der Simulations-

umgebung. Neu hinzugekommen sind die Toolbuttons bzw. Menupunkte ‘Ex-

port animation step to SVG.’ und ‘Reset SVG animation protocol.’

im ‘Edit’ Menu.

Momentan findet innerhalb der Animationsumgebung nur eine Simulation

statt. Hierzu selektiert der Benutzer in der Baumdarstellung einen Animati-

onsschritt und wahlt den Toolbutton ‘Execute an animation step.’ bzw. den

selbigen Menupunkt im ‘Edit’ Menu. Durch ‘Reset the animation.’ wird das

Diagramm in den Ursprungszustand zuruckgesetzt und durch ‘Stop the anima-

tion execution.’ die Transformationsberechnung im Hintergrund unterbrochen.

Die Animationsoperationen fur die ausgefuhrten Animationsschritte werden

im Hintergrund ausgewertet und der eigenstandigen Animationskomponente

ubergeben. Dabei wird die Abfolge der ausgefuhrten Animationsschritte proto-

kolliert. Durch Mausklick auf den Toolbutton ‘Export animation step to SVG.’

wird ein kontinuierlicher SVG Animationsablauf aus den protokollierten Ani-

mationsschritten erzeugt und in einer SVG-Animationsdatei gespeichert. Die

Animation kann anschließend in einem externen SVG-Viewer betrachtet wer-

den.

Durch den Toolbutton ‘Reset SVG animation protocol.’ wird die Proto-

kollierung der Animationsschritte zuruckgesetzt. Dem Benutzer wird somit

ermoglicht ab dem jeweiligen Zeitpunkt einen neuen Ablauf zu erzeugen. Ein

Animationsschritt kann einen Animationsausdruck uber mehrere Animations-

regeln enthalten. Beispielsweise erzeugt der Animationsschritt ‘completeRun’

in Abb. 6.4 ein komplettes Animationsszenario, welches die Schritte ‘produce’,

‘deliver’, ‘remove’ und ‘consume’ beinhaltet (siehe Kap. 6.4).

6.5 Animationsumgebung 81

Als Erweiterung der Animationsumgebung ist eine Online-Animation ge-

plant, wobei die Animation direkt in der Animationsumgebung dargestellt wird.

82 Benutzerhandbuch

Kapitel 7

Ergebnisse und Ausblick

Im folgenden werden die Ergebnisse der Arbeit zusammengefasst und mogliche

Verbesserungen und Erweiterungen diskutiert.

7.1 Ergebnisse

In der Diplomarbeit wurde ein Generator fur Animationsumgebungen konzipiert

und implementiert, welcher Animationsablaufe auf der Basis von Simulationsre-

geln mittels Graphtransformationen generiert. Die diskreten Zustandsubergange

bei der Simulation wurden zu kontinuierlichen Animationsablaufen erweitert.

Hierzu wurden Animationsoperationen definiert, welche die kontinuierlichen

Animationsablaufe der Symbole in der Animationsregel beschreiben. Wahrend

der Transformation eines Diagramms mit der Animationsregel werden die Ani-

mationsoperationen den Symbolen des Diagramms zugeordnet. Grundlage fur

diese Zuordnung sind ‘Match’ und ‘Comatch’ der Transformation.

Zur Animationsgenerierung wurde die visuelle Entwicklungsumgebung Gen-

GED um die entsprechenden Komponenten erweitert: Hierzu zahlen der Ani-

mationsregeleditor, die Animationsschrittdefinition in der VL-Umgebung und

die Animationsumgebung als Teileditor der VL-Umgebung.

Es wurden zwei Arten der Animation konzipiert: Bei der Offline-Animation

findet die eigentliche Animation in einem SVG-Viewer außerhalb der visuellen

84 Ergebnisse und Ausblick

Entwicklungsumgebung statt. Bei der Online-Animation, welche noch nicht im-

plementiert ist, findet die Animation direkt in der Animationsumgebung der

visuellen Entwicklungsumgebung statt.

Alle Komponenten des Generators fur Animationsumgebungen, welche nicht

von einer konkreten visuellen Entwicklungsumgebung abhangig sind, wurden in

eine eigenstandige Animationskomponente ausgelagert, welche von verschiede-

nen visuellen Entwicklungsumgebungen verwendet werden kann.

Die Animationsgenerierung in der GenGED Umgebung wurde durch das

Beispiel zur Animation von Petrinetzen am Beispiel des ‘ProducerConsumer-

Systems’ verdeutlicht. Hierzu wurde ein effizienter Petrinetz Layouter entwi-

ckelt, welcher alle Diagramme uber dem Petrinetz Alphabet in nahezu Realzeit

layouten kann.

7.2 Ausblick

In dieser Diplomarbeit wurde ein kompletter, in sich geschlossener Weg zur

Animationsgenerierung in GenGED und Darstellung als Offline-Animation in

einem SVG-Viewer konzipiert, implementiert und am Beispiel des ‘Producer-

ConsumerSystems’ demonstriert.

Folgende weitere Komponenten konnten in das bestehende Gen-

GED System integriert werden:

• Online-Animation: Die Animation findet direkt in der Animationsum-

gebung von GenGED statt. Hierzu musste die eigenstandige Animations-

komponente der Animationsumgebung einen konkreten Animationsdaten-

satz z.B. als Folge von Frames liefern, welcher von der Animationsumge-

bung dargestellt wird. Eine andere Moglichkeit ware, den SVG-Viewer

direkt in die Animationsumgebung zu integrieren. Dies ware moglich, da

der Quellcode des verwendeten SVG-Toolkits verfugbar ist [SVG02].

• Nicht dargestellte Schritte: Als Entwurfsentscheidung werden die

transformierten Diagramme nach jeder Animationsregelanwendung lay-

outet und in der Animationsumgebung dargestellt. Somit lassen sich in

7.2 Ausblick 85

einem Animationsschritt Animationsablaufe uber mehrere Animationsre-

geln definieren. Bei der Simulation wird das transformierte Diagramm erst

nach Ende eines Simulationsschrittes layoutet, wobei die Zwischenschritte

nicht dargestellt werden. Dieses Verhalten ist z.B. bei der Simulation von

hierarchischen Statecharts erwunscht [Wei01]. Bei der Animation musste

man derzeit mit ‘Visibility’ Animationsoperationen sicherstellen, dass die

Zwischenschritte nicht dargestellt werden.

• Identifier in GenGED: Die grafischen Objekte in GenGED werden

durch Identifier referenziert. Dabei ist ein Identifier genau einem grafi-

schem Objekt zugeordnet. Im alten GenGED System werden die Iden-

tifier allerdings dynamisch vergeben. D.h. es ist nicht sichergestellt, dass

nach erneutem Laden oder Modifizieren eines Diagramms die Identifier

noch die gleichen sind. Vielmehr bedient sich das alte GenGED System

intern oftmals der Moglichkeit Diagramme zu klonen, um auf der Kopie

weiterarbeiten zu konnen. Dabei ist keine eindeutige Zuordnung von al-

tem und neuen Identifier gegeben, sondern muss mitprotokolliert werden.

Zu konzipieren ware ein System, das zentral eindeutige Identifier vergibt

und persistent halt.

• Layouter in GenGED: Auf Grundlage des konzipierten und implemen-

tierten Layouters fur Petrinetze konnen weitere GenGED Layouter fur

andere Alphabete implementiert werden. Hierzu wurde auch ein Alpha-

bet fur die anwendungsspezifische Sicht des ‘ProducerConsumerSystems’

gehoren.

Aufgrund der Schwachstellen des alten GenGED Systems wurde mittlerweile

ein neues GenGED System von Ermel und Bardohl konzipiert [EB03].

Der Animationsregeleditor erhalt in der neuen GenGED Umgebung eine

modellspezifische Simulationsgrammatik, welche konkret fur das verwendete vi-

suelle Modell generiert wurde. Diese Aufgabe soll von einem ‘Compiler’ (Abb.

7.1) in der neuen GenGED Umgebung ubernommen werden. Ausserdem kann

das Verhalten von Modellen in ein anwendungsspezifisches Layout transformiert

und dann animiert werden. Diese sogenannte View-Transformation wird in der

86 Ergebnisse und Ausblick

Abbildung 7.1: Neue GenGED Umgebung [EB03]

neuen GenGED Version in einer View-Transformationsgrammatik definiert.

Literaturverzeichnis

[Ado03] Adobe. Adobe SVG Viewer. Adobe SVG Viewer – Version 3.0, 2003.

Available at http://www.adobe.com/svg/.

[Apa01] Apache. Xerces Java Parser – Version 1.2.0, 2001. Available at

http://xml.apache.org/xerces-j.

[Apa03] Apache. Batik. Java SVG Toolkit, 2003. Available at http://xml.

apache.org/batik/.

[Bar00] R. Bardohl. GenGEd – Visual Definition of Visual Languages based

on Algebraic Graph Transformation. Verlag Dr. Kovac, 2000. PhD

thesis, Technical University of Berlin, Dept. of Computer Science,

1999.

[BEE+02] R. Bardohl, K. Ehrig, C. Ermel, A. Qemali, and I. Weinhold. Spe-

cifying Visual Languages with GenGEd. In H.-J. Kreowski, editor,

Proc. of APPLIGRAPH Workshop on Applied Graph Transformation

(AGT 2002), pages 71–82, 2002.

[BEP02] R. Bardohl, C. Ermel, and J. Padberg. Formal Relationship between

Petri Nets and Graph Grammars as Basis for Animation Views in

GenGED. In Proc. IDPT 2002: Sixth World Conference on Integra-

ted Design and Process Technology. Society for Design and Process

Science (SDPS), 2002.

[BEWE03] R. Bardohl, C. Ermel, I. Weinhold, and K. Ehrig. GenGED – Ge-

neration of Graphical Environments for Design, 2003. Available at

http://tfs.cs.tu-berlin.de/genged.

88 LITERATURVERZEICHNIS

[Die03] S. Diehl. Softwarevisualisierung. Informatik Spektrum, pages 257–

260, 4. August 2003.

[EB03] C. Ermel and R. Bardohl. Scenario Animation for Visual Behavior

Models: A Generic Approach. Submission to Journal on Software and

System Modelling, 2003. Submitted.

[EBE01] C. Ermel, R. Bardohl, and H. Ehrig. Specification and Implemen-

tation of Animation Views for Petri Nets. In H. Weber, H. Ehrig,

and W. Reisig, editors, in 2nd Int. Colloquium on Petri Net Techno-

logies for Modelling Communication Based Systems, Fraunhofer Ge-

sellschaft ISST, Berlin, 2001, pages 75–92, Berlin, Germany, Sept.

2001. Researcher Group Petri Net Technology, Fraunhofer Gesell-

schaft ISST.

[Ecl03] Eclipse Consortium. Eclipse – Version 2.1, 2003. Available at http:

//www.eclipse.org.

[Ehr02] Karsten Ehrig. XML Formattransformationen fur PN/GraGra-

Tools. Petri-Net/GraGra-AG, 2002. Available at http://tfs.cs.

tu-berlin.de/lehre/SS02/PN-GRA/XML_Trafos.ps.gz.

[ERT99] C. Ermel, M. Rudolf, and G. Taentzer. The AGG-Approach: Langua-

ge and Tool Environment. In H. Ehrig, G. Engels, H.-J. Kreowski,

and G. Rozenberg, editors, Handbook of Graph Grammars and Com-

puting by Graph Transformation, volume 2: Applications, Languages

and Tools, pages 551–603. World Scientific, 1999.

[FvDFH97] James D. Foley, Andries van Dam, Steven K. Feiner, and John F.

Hughes. Computer Graphics Principles and Practice. Second Edition.

Systems Programming Series. Addison-Wesley, Boston, San Francis-

co, New York, 1997.

[Gri96] P. Griebel. Paralleles Losen von grafischen Constraints. PhD thesis,

University of Paderborn, Germany, February 1996.

LITERATURVERZEICHNIS 89

[Hos98] P. Hoschka. Synchronized Multimedia Integration Language (SMIL)

Specification – Version 1.0, 1998. Available at http://www.w3.org/

TR/REC-smil/.

[Kat98] M. Kater. SimPEP: 3D-Visualisierung und Animation paralleler Pro-

zesse. Diplomarbeit, Universitat Hildesheim, 1998.

[KP03] E. Kindler and C. Pales. 3d-visualization of petri net models: A con-

cept. In G. Juhas, R. Lorenz: Workshop Algorithmen und Werkzeuge

fur Petrinetze, 2003.

[KW99] E. Kindler and M. Weber. The Petri Net Kernel - Documentation of

the Application Interface, Revision 2.0, http: // www. informatik.

hu-berlin. de/ top/ pnk/ index. html . Forschergruppe Petrinetz-

Technologie an der Humboldt-Universitat zu Berlin, Januar 1999.

[Min01] M. Minas. DiaGen – The Diagram Editor Generator - Version 2.1,

2001. Available at http://www2.informatik.uni-erlangen.de/

DiaGen.

[MV95] M. Minas and G. Viehstaedt. Diagen: A generator for diagram edi-

tors providing direct manipulation and execution of diagrams. In

Proc. IEEE Symp. on Visual Languages, pages 203–210, Darmstadt,

Germany, September, 5-9 1995.

[Nie99] Magnus Niemann. Konzeption und Implementierung eines generi-

schen Grammatik-Editors fur visuelle Sprachen. Diplomarbeit, TU

Berlin, 1999.

[OMO03] OMONDO. EclipseUML – Version 1.21, 2003. Available at http:

//www.eclipseuml.com.

[Rei82] Wolfgang Reisig. Petrinetze. Eine Einfuhrung. Springer Verlag, 1982.

[RS95] J. L. Rasmusen and M. Singh. Mimic/CPN: a graphical animation

utility for design/cpn. Technical report, Computer Science Depart-

ment, Aarhus University, Denmark, 1995.

90 LITERATURVERZEICHNIS

[RS01] Inc. Recursion Software. JGL – Java Generic Libraries – Version

3.1.0, 2001. Available at http://www.recursionsw.com/products/

jgl/jgl.asp.

[SC00] P. Schmitz and A. Cohen. SMIL Animation, 2000. Available at

http://www.w3.org/TR/2001/REC-smil-animation-20010904/.

[Sch99] Manuel Schwarze. Konzeption und Implementierung eines generi-

schen Alphabet-Editors fur visuelle Sprachen. Diplomarbeit, TU Ber-

lin, 1999.

[Sun03] Sun Microsystems, Inc. Java – Version 1.4, 2003. Available at http:

//java.sun.com.

[SuS03] SuSE. Linux – Version 8.2, 2003. Available at http://www.suse.

com.

[SVG02] SVG Toolkit. CSIRO SVG Toolkit – Release March 12th 2002, 2002.

Available at http://www.cmis.csiro.au/svg/.

[TRS03] G. Taentzer, O. Runge, and J. Schneider. AGG – The Attribu-

ted Graph Grammar System, 2003. Available at http://tfs.cs.

tu-berlin.de/agg.

[UML02] Unified Modeling Language – version 1.4, 2002. Available at http:

//www.omg.org/uml.

[W3C01] World Wide Web Consortium W3C. W3C SVG. Scalable Vector

Graphics – Version 1.0, 2001. Available at http://www.w3.org/TR/

SVG/.

[Wei01] Ingo Weinhold. Konzeption und Implementierung eines Generators

fur Simulationsumgebungen. Diplomarbeit, TU Berlin, 2001.

[Wol97] D. Wolz. Colimit Computations for Graph Structures and Algebraic

Specification Languages. PhD Thesis, TU Berlin, FB Informatik,

1997.

LITERATURVERZEICHNIS 91

[WWW02] WWW Consortium (W3C). Extensible Markup Language Version

1.0 http: // www. w3c. org/ XML , 2002.

Documents

Konzeption und Implementierung eines Generators fur