Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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
4.5.1 Animationsumgebung . . . . . . . . . . . . . . . . . . . . 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.2.3 Animationsumgebung . . . . . . . . . . . . . . . . . . . . 65
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"><!-- The following illustrates the use of the ‘animate’ element
to animate a rectangle x, y, and width attributes so thatthe rectangle grows to ultimately fill the viewport. -->
<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 Konzeption der Animationsgenerierung 23
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 Konzeption der Animationsgenerierung 25
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’
3.4 Konzeption der Animationsgenerierung 27
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).
4.3 Animationsregeleditor 35
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.
4.3 Animationsregeleditor 37
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-
4.3 Animationsregeleditor 39
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-
4.3 Animationsregeleditor 41
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-
4.4 VL-Spezifikationseditor 45
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 VL-Spezifikationseditor 47
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.
4.5.1 Animationsumgebung
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
4.6 Eigenstandige Animationskomponente 55
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"
style="fill:white; stroke:black"/>
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"
style="fill:white; stroke:black"/>
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.
4.6 Eigenstandige Animationskomponente 57
• 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.
5.2 Grafische Benutzerschnittstellen 63
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
5.2 Grafische Benutzerschnittstellen 65
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.
5.2.3 Animationsumgebung
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
5.4 Eigenstandige Animationskomponente 67
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.
6.3 Animationsregeleditor 73
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 Animationsregeleditor 75
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-
6.4 VL-Spezifikationseditor 77
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.