Institut f¨
ur Informatik
Fachgebiet Softwaretechnik
Warburger Straße 100
33098 Paderborn
Kompositionale Softwareverifikation
mechatronischer Systeme
Schriftliche Arbeit
zur Erlangung des Grades
“Doktor der Naturwissenschaften”
vorgelegt von
Daniela Schilling
Rochusweg 10a
33102 Paderborn
Paderborn, Februar 2006
Zusammenfassung
Die Anspr¨
uche an die Leistungsf¨
ahigkeit und Sicherheit technischer Systeme, wie Autos oder
Flugzeuge, steigt stetig. Um den wachsenden Anforderungen gerecht zu werden istes notwendig,
dass maschinenbauliche, elektrotechnische und Softwarekomponenten zusammenarbeiten. Ein
System, dass aus solchen Komponenten zusammengesetzt ist, wird als mechatronisches System
bezeichnet.
Ein solches System kann ¨
uber Sensoren Informationen ¨
uber seine Umwelt sammeln. Es hat
aber auch die M¨
oglichkeit, mit anderen mechatronischen Systemen zu kommunizieren oder zu
kooperieren. Die Software, die f¨
ur eine solche Interaktion erforderlich ist, ist sicherheitskritisch,
d.h. ein Fehlverhalten der Software kann einen großen finanziellen Schaden verursachen und im
schlimmsten Fall auch Menschenleben kosten. Da die Software gleichzeitig aber auch sehr kom-
plex ist und zumeist einen unendlichen Zustandsraum hat, reicht Testen alleine nicht aus, um die
Korrektheit der Software nachzuweisen. Automatische Ans¨
atze zur formalen Verifikation wie
Model Checking k¨
onnen nur Systeme mit einem endlichen Zustandsraum verifizieren. Theorem-
beweiser, die einen Korrektheitsnachweis auch f¨
ur solche Systeme f¨
uhren k¨
onnen, ben¨
otigen die
Interaktion mit einem Benutzer, der mit formalen Methoden vertraut ist.
Deshalb wird in dieser Arbeit ein kompositionaler Ansatz vorgestellt, der die Software, die
zur Interaktion zwischen mehreren mechatronischen Systemen notwendig ist, automatisch for-
mal verifizieren kann. Der Ansatz baut auf den existierenden Ansatz der MECHATRONIC UML
auf. Er nutzt dabei die Tatsache aus, dass ein Systemzustand in der MECHATRONIC UML, cha-
rakterisiert durch die mechatronischen Systeme und deren laufende Interaktion, als Graph darge-
stellt werden kann. Zustands¨
uberg¨
ange wie beispielsweise das Starten oder Beenden einer Inter-
aktion k¨
onnen dann als Graphtransformationsregel beschrieben werden. Zudem k¨
onnen die hier
betrachteten strukturellen Sicherheitseigenschaften lokal nachgewiesen werden. F¨
ur eine Menge
von Graphtransformationsregeln und eine Menge von Sicherheitseigenschaften wird dann ge-
zeigt, dass die Regeln niemals einen korrekten Graphen, also einen Zustand, der alle Sicherheits-
eigenschaften erf¨
ullt, in einen inkorrekten Graphen ¨
uberf¨
uhren k¨
onnen. Die Erreichbarkeit der
Graphen wird dabei jedoch nicht ber¨
ucksichtigt. Somit wird bei der Verifikation nachgewiesen,
dass die Sicherheitseigenschaften induktive Invarianten des Systems darstellen.
iii
iv
Danke
Bevor ich meine Forschungsergebnisse der letzten Jahre pr¨
asentiere, m¨
ochte ich mich bei all
den Menschen bedanken, die mir auf dem Weg zur Promotion geholfen, mich ermutigt oder mir
freundschaftlich zur Seite gestanden haben.
Als erstes gilt mein Dank meinem Doktorvater Prof. Wilhelm Sch¨
afer. Bei Wilhelm m¨
ochte
ich mich daf¨
ur bedanken, dass er mich 2002 zur Promotion ermutigte, mir die Chance gegeben
hat mich in seiner Arbeitsgruppe mit spannenden Themen der Informatik zu besch¨
aftigen und
mir viele wertvolle Tipps gegeben hat. An dieser Stelle m¨
ochte ich mich auch bei Prof. Gregor
Engels und Prof. J¨
urgen Gausemeier daf¨
ur bedanken, dass sie meine Promotion betreut haben.
Bei meinem Kollegen Holger Giese m¨
ochte ich mich f¨
ur viele fruchtbare Diskussionen, An-
regungen und einen riesigen Berg ”spannender Bettlekt¨
ure“bedanken.
Wer mich kennt, der weiß, dass meine Computer aus Prinzip nicht das tun, was sie tun sollen
und Fehler produzieren, die nie zuvor jemand gesehen hat. Deswegen gilt mein Dank J¨
urgen
Maniera, der nie die Geduld verloren hat und am Ende jedes noch so seltsame technische R¨
atsel
l¨
osen konnte.
B¨
urokratische Probleme sind w¨
ahrend meiner Promotionszeit in Paderborn dank Jutta Haupt
nie aufgetreten. Mein Dank gilt Jutta aber vor allem f¨
ur die freundschaftliche Unterst¨
utzung und
die Dienstag-Mittagessen.
”Wer solche Kollegen hat braucht keine Feinde mehr“(Sprichwort in der Arbeitsgruppe).
Jungs, so schlimm wart ihr gar nicht. Im Gegenteil, ich m¨
ochte mich an dieser Stelle bei al-
len meinen Kollegen - Bj¨
orn Axenath, Sven Burmester, Matthias Gehrke, Holger Giese, Stefan
Henkler, Martin Hirsch, Florian Klein, Ekkart Kindler, J¨
org Niere, Ahmet Mehic, Matthias Mey-
er, Vladimir Rubin, Matthias Tichy, Robert Wagner, J¨
org Wadsack und Lothar Wendehals - f¨
ur
die gute Zusammenarbeit, gemeinsame Kinoabende und eine sch¨
one Promotionszeit bedanken.
Lothar m¨
ochte ich dar¨
uber hinaus f¨
ur drei freundschaftliche Jahre im gemeinsamen B¨
uro danken.
Matthias Gehrke, Martin Hirsch, Florian Klein, Lothar Wendehals, Matthias Meyer, Matthi-
as Tichy, Robert Wagner und Reiko Heckel m¨
ochte ich daf¨
ur danken, dass sie ein oder mehrere
Kapitel meiner Arbeit, zum Teil auch mehrfach, Korrektur gelesen und mir gute Tipps zur Ver-
besserung gegeben haben.
Bei Basil Becker und Victor Neumann m¨
ochte ich mich daf¨
ur bedanken, dass sie im Rahmen
ihrer Studienarbeiten und w¨
ahrend ihrer T¨
atigkeiten als studentische Hilfskr¨
afte meine Ideen
implementiert und in die Fujaba Real-Time Tool Suite integriert haben.
v
vi
Bei Huberta Vahle und Riccarda Vollmers sowie ihren Familien und Teams m¨
ochte ich mich
f¨
ur die gute Freundschaft bedanken und daf¨
ur, dass ich auf dem R¨
ucken ihrer Pferde nicht nur
Gl¨
uck und Erholung sondern auch so manch eine Probleml¨
osung finden konnte. Meiner besten
Freundin Silke Kaspari m¨
ochte ich f¨
ur die vergn¨
uglichen gemeinsamen Stunden und die vielen
aufmunternden Emails bedanken. Außerdem gilt Silke mein Dank, da sie viele Stunden daf¨
ur
aufgebracht hat, um die Rechtschreibung und Zeichensetzung in dieser Arbeit zu korrigieren.
Bei meinen Eltern m¨
ochte ich mich daf¨
ur bedanken, dass sie immer f¨
ur mich da waren, mich
unterst¨
utzt haben (auch dann, wenn ihnen meine Entscheidungen mal nicht gefallen haben) und
sie sich mit mir und f¨
ur mich ¨
uber Erfolge gefreut haben.
Inhaltsverzeichnis
1 Einleitung 1
1.1 Motivation...................................... 1
1.2 Anwendungsbeispiel ................................ 2
1.3 Ziel und L¨
osungsansatz............................... 3
1.4 AufbauderArbeit.................................. 7
2 Grundlagen 9
2.1 Architektur ..................................... 10
2.1.1 Die Operator-Controller-Modul Architektur . . . . . . . . . . . . . . . . 10
2.1.2 Komponentendiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Klassendiagramme............................. 13
2.2 Verhalten ...................................... 14
2.2.1 Kommunikation .............................. 14
2.2.2 Komponentenverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Modellkomposition................................. 25
2.3.1 Kommunikation und Komponenten . . . . . . . . . . . . . . . . . . . . 25
2.3.2 Kulturen und Communities . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Verifikation ..................................... 33
2.4.1 Verifikation der Kommunikation . . . . . . . . . . . . . . . . . . . . . . 33
2.4.2 Verifikation der Komponenten . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.3 Verifikation der Kulturen . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.4 Korrektheit des Gesamtsystems . . . . . . . . . . . . . . . . . . . . . . 35
2.5 Der Modellierungs- und Verifikationsprozess . . . . . . . . . . . . . . . . . . . 36
2.6 Zusammenfassung ................................. 36
3 Nachweis induktiver Invarianten 39
3.1 DieIdee....................................... 40
3.1.1 Graphtransformationssysteme . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.2 Graphmuster und Systemkorrektheit . . . . . . . . . . . . . . . . . . . . 41
3.1.3 Erreichbarkeitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.4 Nachweis induktiver Invarianten . . . . . . . . . . . . . . . . . . . . . . 44
3.1.5 Erweiterung der Idee um negative Anwendungsbedingungen . . . . . . . 50
3.2 Graphtransformationssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
vii
viii INHALTSVERZEICHNIS
3.2.1 Graphen und grundlegende Operationen darauf . . . . . . . . . . . . . . 58
3.2.2 Graphtransformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2.3 Graphtransformationsregeln mit negativer Anwendungsbedingung . . . . 66
3.2.4 Graphtransformationssysteme . . . . . . . . . . . . . . . . . . . . . . . 69
3.3 Graphmuster .................................... 69
3.4 DasSystemmodell ................................. 72
3.4.1 Graphen zur Zustandsbeschreibung . . . . . . . . . . . . . . . . . . . . 72
3.4.2 Graphtransformationen zur Beschreibung von Zustands¨
anderungen . . . 75
3.4.3 Typisierte Graphtransformationssysteme . . . . . . . . . . . . . . . . . . 80
3.5 Erweiterte Graphtransformationen . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.5.1 R¨
uckw¨
artsanwendung von Graphtransformationsregeln . . . . . . . . . . 81
3.5.2 Transformationen von Graphmustern . . . . . . . . . . . . . . . . . . . 84
3.6 Systemeigenschaften und Invarianten . . . . . . . . . . . . . . . . . . . . . . . . 85
3.6.1 Sicherheitseigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.6.2 Beschr¨
ankung auf Gegenbeispiele . . . . . . . . . . . . . . . . . . . . . 88
3.7 Nachweis von induktiven Invarianten . . . . . . . . . . . . . . . . . . . . . . . . 88
3.7.1 Theoretische Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.7.2 DerAlgorithmus .............................. 99
3.7.3 Aufwandsabsch¨
atzung ...........................100
3.8 Zusammenfassung .................................103
4 Story Patterns und Graphtransformationssysteme 105
4.1 Objektdiagramme und Graphen . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.2 Story Patterns und Graphtransformationsregeln . . . . . . . . . . . . . . . . . . 106
4.2.1 Anwendung von Story Patterns und Graphtransformationsregeln . . . . . 107
4.2.2 Negative Anwendungsbedingungen . . . . . . . . . . . . . . . . . . . . 109
4.3 Kritische Situationen und Unf¨
alle .........................110
4.4 Zusammenfassung .................................110
5 Werkzeugunterst¨
utzung 113
5.1 Werkzeugunterst¨
utzung des Modellierungs- und Verifikationsprozesses . . . . . . 114
5.1.1 Modellierung................................114
5.1.2 Verifikation.................................114
5.1.3 Codegenerierung..............................115
5.2 DasGroove-Plugin .................................115
5.2.1 Export von Story Patterns . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.2.2 Simulation und Verifikation mit Groove . . . . . . . . . . . . . . . . . . 118
5.2.3 Darstellung von Gegenbeispielen . . . . . . . . . . . . . . . . . . . . . 119
5.3 Plugin zum Nachweis von induktiven Invarianten . . . . . . . . . . . . . . . . . 120
5.3.1 Verifikation.................................121
5.3.2 Darstellung von Gegenbeispielen . . . . . . . . . . . . . . . . . . . . . 125
5.4 Evaluierung.....................................125
5.4.1 Charakteristiken des Evaluierungsbeispiels . . . . . . . . . . . . . . . . 126
INHALTSVERZEICHNIS ix
5.4.2 Evaluierung des Plugins zum automatischen Nachweises von induktiven
Invarianten .................................127
5.5 Zusammenfassung .................................130
6 Verwandte Arbeiten 131
6.1 Korrektheit per Konstruktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.2 Model Checking von Graphtransformationssystemen . . . . . . . . . . . . . . . 134
6.3 Analyse mittels Petrinetztechniken . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.3.1 Approximierte Entfaltung . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.3.2 Regelinvarianten in Graphtransformationssystemen . . . . . . . . . . . . 137
6.4 Zusammenfassung .................................138
7 Zusammenfassung und Ausblick 139
7.1 Zusammenfassung .................................139
7.2 Ausblick.......................................141
A Das Shuttle-Beispiel 153
A.1 Regeln........................................153
A.1.1 Die Regeln der Movement-Kultur .....................154
A.1.2 Die Regeln der ControlledMovement-Kultur................156
A.1.3 Die Regeln der CoordinatedMovement-Kultur...............158
A.2 VerboteneGraphmuster...............................161
A.2.1 Sicherheitseigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . 161
A.2.2 Die verbotenen Graphmuster der CoordinatedMovement-Kultur . . . . . 163
A.2.3 Kardinalit¨
aten................................164
A.2.4 Gr¨
oßen der verbotenen Graphmuster . . . . . . . . . . . . . . . . . . . . 166
B Theoretische Ergebnisse und Beweisskizzen 169
B.1 Graphmuster ....................................169
B.2 DasSystemmodell .................................170
B.3 Erweiterte Graphtransformationen . . . . . . . . . . . . . . . . . . . . . . . . . 171
B.4 Systemeigenschaften und Invarianten . . . . . . . . . . . . . . . . . . . . . . . . 173
B.5 Nachweis von induktiven Invarianten . . . . . . . . . . . . . . . . . . . . . . . . 174
C Algorithmen 177
C.1 Graphtransformationen...............................177
C.1.1 Negative Anwendungsbedingungen . . . . . . . . . . . . . . . . . . . . 177
C.1.2 Anwendung von Graphtransformationsregeln . . . . . . . . . . . . . . . 179
C.2 Erweiterte Graphtransformationen . . . . . . . . . . . . . . . . . . . . . . . . . 180
C.2.1 R¨
uckw¨
artsanwendung von Graphtransformationsregeln . . . . . . . . . . 180
C.2.2 Anwendung von Regeln auf Graphmuster . . . . . . . . . . . . . . . . . 182
C.3 ¨
Uberpr¨
ufung induktiver Invarianten . . . . . . . . . . . . . . . . . . . . . . . . 182
C.3.1 Bildung von Ergebnisgraphmustern . . . . . . . . . . . . . . . . . . . . 184
xINHALTSVERZEICHNIS
Abbildungsverzeichnis
1.1 Zwei hintereinander herfahrende Shuttles ..................... 3
2.1 Die Architektur des Operator-Controller-Moduls. Quelle: [Ge05] . . . . . . . . . 11
2.2 OCM als Komponente. Quelle: [Ge05] . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Definition des Komponententyps Shuttle ...................... 12
2.4 Zwei Instanzen der Shuttle-Komponente...................... 13
2.5 Klassendiagramm, das die Ontologie der Shuttle-Komponente beschreibt . . . . 13
2.6 Das DistanceCoordination-Koordinationsmuster . . . . . . . . . . . . . . . . . . 16
2.7 Instanz des DistanceCoordination-Musters..................... 17
2.8 Real-Time Statechart, das das Verhalten der Rolle rearRole beschreibt . . . . . . 19
2.9 Verhalten der Shuttle-Komponente......................... 21
2.10 Story Pattern moveSimple, das die Bewegung eines Shuttles von einem Track auf
den n¨
achstenbeschreibt............................... 23
2.11 Beispiel f¨
ur ein Objektdiagramm. Die Abbildung des Story Patterns aus Abbil-
dung 2.10 auf dieses Objektdiagramm ist gr¨
un hinterlegt . . . . . . . . . . . . . 24
2.12 Objektdiagramm aus Abbildung 2.11 nachdem das Story Pattern moveSimple
daraufangewendetwurde.............................. 24
2.13 Story Pattern moveSimpleNAC, das das Story Pattern moveSimple um eine ne-
gative Anwendungsbedingung erweitert . . . . . . . . . . . . . . . . . . . . . . 25
2.14 Modell bestehend aus je drei Komponenten und Koordinationsmustern . . . . . . 26
2.15 Beispiel f¨
ur eine Kulturhierarchie . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.16 Ontologie erweitert um konzeptionelle Elemente . . . . . . . . . . . . . . . . . 29
2.17 Beispiel f¨
ur die Implementierung der Verhaltensregel moveNext ......... 30
2.18 Verbotenes Story Pattern collision .......................... 30
2.19 Instanzierungsregel createDC ............................ 31
2.20 Verhaltensregel moveDC .............................. 32
2.21 Verbotenes Story Pattern impendingCollision .................... 32
3.1 Die Graphtransformationsregel moveSimple .................... 41
3.2 Verbotenes Graphmuster impendingCollisionSimplified .............. 42
3.3 Beispiel f¨
ur die Korrektheit bzw. Inkorrektheit von Graphen . . . . . . . . . . . 43
3.4 Die Regel moveSimple transformiert einen inkorrekten Graphen in einen anderen
inkorrektenGraphen ................................ 46
xi
xii ABBILDUNGSVERZEICHNIS
3.5 Die Regel moveSimple transformiert einen korrekten Graphen in einen inkorrek-
tenGraphen..................................... 47
3.6 Start- und Ergebnisgraphmuster f¨
ur die Regel moveSimple und das verbotene
Graphmuster impendingCollisionSimplified, wobei das Startgraphmuster einem
inkorrekten Graphmuster entspricht . . . . . . . . . . . . . . . . . . . . . . . . 49
3.7 Start- und Ergebnisgraphmuster f¨
ur die Regel moveSimple und das verbotene
Graphmuster impendingCollisionSimplified, wobei das Startgraphmuster einem
korrekten Graphen entspricht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.8 Graphtransformationsregel moveSimpleNAC mit negativer Anwendungsbedingung 51
3.9 Konvertierung der Regel moveSimpleNAC in die Regel moveSimpleNAC−1, so-
dass sie r¨
uckw¨
arts angewendet werden kann . . . . . . . . . . . . . . . . . . . . 53
3.10 Verbotenes Graphmuster impendingCollision mit negativer Anwendungsbedingung 53
3.11 Graphen, die in Bezug auf das verbotene Graphmuster impendingCollision inkor-
rektbzw.korrektsind................................ 54
3.12 Regel deleteDCSwitch, die eine Instanz des DistanceCoordination-Musters l¨
oscht 55
3.13 Ergebnisgraphmuster mit negativer Anwendungsbedingung . . . . . . . . . . . . 57
3.14 Startgraphmuster mit negativer Anwendungsbedingung . . . . . . . . . . . . . . 58
3.15 Beispiel f¨
ur einen beschrifteten Graphen . . . . . . . . . . . . . . . . . . . . . . 60
3.16 Graph G0, f¨
ur den ein Graphhomomorphismus in Graph Gaus Abbildung 3.15
bestimmtwerdensoll................................ 63
3.17 Beispiel f¨
ur eine Graphtransformationsregel . . . . . . . . . . . . . . . . . . . . 65
3.18 Zwei Graphen G,G0, f¨
ur die ein Auftreten der Regel aus Abbildung 3.17 existiert,
sodass o(L)⊆Gund o(R)⊆G0gilt ........................ 66
3.19 Beispiel f¨
ur einen Graphen, bei dem die Anwendung von moveSimple zu einer
kritischen Situation f¨
uhrenkann .......................... 67
3.20 Regel moveSimpleNAC, die die Regel moveSimple um negative Anwendungs-
bedingungenerweitert ............................... 68
3.21 Beispiel f¨
ur ein Graphmuster und ein Teilgraphmuster . . . . . . . . . . . . . . . 72
3.22 Einfaches Klassendiagramm und der dazugeh¨
orige Typgraph . . . . . . . . . . . 73
3.23 Regel deletePublication und ihre Anwendung auf einen Graphen im Single
bzw.DoublePushoutAnsatz............................ 77
3.24 Graphtransformationsregel deletePublication, die so angepasst wurde, dass ihre
Anwendung im DPOiso keine losen Kanten erzeugen kann . . . . . . . . . . . . 79
3.25 Regel moveSimpleNAC ............................... 82
3.26 Regel moveSimpleNAC−1stellt die inverse Regel moveSimpleNAC dar . . . . . . 83
3.27 Sicherheitseigenschaft impendingCollision ..................... 87
3.28 Regel moveSimpleNAC, deren Korrektheit im Bezug auf das verbotene Gra-
phmuster impendingCollision ¨
uberpr¨
uft werden soll . . . . . . . . . . . . . . . . 92
3.29 Ein m¨
ogliches Ergebnisgraphmuster f¨
ur die Regel moveSimpleNAC und das ver-
botene Graphmuster impendingCollision ...................... 93
3.30 Die Regel deleteDCSwitch ............................. 95
3.31 Ein m¨
ogliches Ergebnisgraphmuster f¨
ur die Regel deleteDCSwitch und das ver-
botene Muster impendingCollision ......................... 96
ABBILDUNGSVERZEICHNIS xiii
3.32 Schematische Darstellung der Erweiterung eines Graphen ˆ
L−1∈ˆ
L−1um Ele-
mente aus P..................................... 97
3.33 Schematische Darstellung der Erweiterung eines Graphen ˆ
P∈ˆ
Pum Elemente
aus L−1....................................... 97
3.34 Schematische Darstellung der Erweiterung eines Graphen ˆ
P∈ˆ
Pum Elemente
aus L−1....................................... 97
3.35 Startgraphmuster, das aus der Anwendung der inversen Regel
moveSimpleNAC−1auf das Ergebnisgraphmuster aus Abbildung 3.29 re-
sultiert........................................ 98
3.36 Algorithmus check .................................100
4.1 Klassendiagramm und entsprechender Typgraph . . . . . . . . . . . . . . . . . . 106
4.2 Objektdiagramm und entsprechender typisierter Graph . . . . . . . . . . . . . . 107
4.3 Vorw¨
artsbewegung, moveSimple, eines Shuttles als Story Pattern und als Graph-
transformationsregel ................................108
4.4 Story Pattern createDC, das die Erzeugung eines DistanceCoordination-Musters
zeigt.........................................110
4.5 Graphtransformationsregel createDC ........................111
4.6 Die kritische Situation impendingCollision als Story Pattern und ¨
aquivalentes ver-
botenesGraphmuster................................112
5.1 Startgraph des zu verifizierenden Graphtransformationssystems . . . . . . . . . . 116
5.2 Zu verifizierende Regel moveSimple ........................117
5.3 Verbotenes Story Pattern collision ..........................117
5.4 Die Regel moveSimple als Story Pattern und als Groove-Regel . . . . . . . . . . 119
5.5 Von Groove erzeugtes Gegenbeispiel in Fujaba dargestellt . . . . . . . . . . . . . 120
5.6 Durch die Merging-Funktion bestimmtes Story Pattern . . . . . . . . . . . . . . 123
5.7 Von Fujaba generiertes Gegenbeispiel, das zeigt, dass das Story Pattern move-
Simple das verbotene Graphmuster collision erzeugen kann . . . . . . . . . . . . 126
5.8 Ben¨
otigte Verifikationszeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
A.1 Die Regel member .................................154
A.2 Die Regel noMember ................................155
A.3 Die Regel moveNext ................................155
A.4 Die Regel approachSwitch .............................156
A.5 Die Regel moveSwitch ...............................156
A.6 Die Regel createPublication ............................157
A.7 Die Regel deletePublication .............................158
A.8 Die Regel createDC .................................159
A.9 Die Regel createDCSwitch .............................159
A.10 Die Regel moveDC .................................160
A.11 Die Regel deleteDC .................................160
A.12 Der Unfall collision .................................162
xiv ABBILDUNGSVERZEICHNIS
A.13 Die kritische Situation notMember .........................162
A.14 Die kritische Situation noPublication ........................163
A.15 Die kritische Situation impendingCollision .....................163
A.16 Die kritische Situation impendingCollisionSwitch .................164
A.17 Die erweiterte Ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
A.18 singleLocatedOn ..................................165
A.19 unumbigousLocatedOn ...............................165
A.20 locatedOnNext ...................................165
A.21 singleNext ......................................165
A.22 tooManyNext ....................................166
A.23 singleSuccessor ...................................166
A.24 twoWayTracks ....................................166
A.25 tooManyPredecesors ................................166
A.26 tooManySuccessors ................................167
C.1 Algorithmus extendNAC, der die negative Anwendungsbedingung der linkenRe-
gelseite erweitert, sodass die Regelanwendung die Lose-Kanten-Bedingung erf¨
ullt178
C.2 Algorithmus minimizeNAC zur Minimierung von negativen Anwendungsbedin-
gungen........................................179
C.3 Algorithmus apply, der die Anwendung einer Graphtransformationsregel unter
dem Single Pushout Approach beschreibt . . . . . . . . . . . . . . . . . . . . . 180
C.4 Algorithmus convertNAC zum Konvertieren von negativen Anwendungsbedin-
gungen........................................181
C.5 Algorithmus reverse zur Invertierung von Graphtransformationsregeln . . . . . . 182
C.6 Algorithmus applyRuleToPattern, der die Anwendung einer Graphtransformati-
onsregel auf ein Graphmuster beschreibt . . . . . . . . . . . . . . . . . . . . . . 183
C.7 Algorithmus buildTGP zur Bildung der Ergebnisgraphmuster . . . . . . . . . . . 186
C.8 Algorithmus reduceTGP zur Reduzierung der Menge der Ergebnisgraphmuster . 187
Tabellenverzeichnis
5.1 Gr¨
oße der verifizierten (verbotenen) Story Patterns . . . . . . . . . . . . . . . . 127
5.2 Vergleich der Verifikationszeiten mit und ohne Typen . . . . . . . . . . . . . . . 129
A.1 Charakteristiken der Regeln im Shuttle-System ..................161
A.2 Charakteristiken der verbotenen Graphmuster im Shuttle-Beispiel . . . . . . . . 167
xv
xvi TABELLENVERZEICHNIS
Kapitel 1
Einleitung
”The bug is always in the case you did not test“Murphy’s law.
1.1 Motivation
Technische Systeme spielen eine immer gr¨
oßere Rolle im t¨
aglichen Leben. Beispiele f¨
ur solche
Systeme reichen von der Kaffeemaschine bis hin zu Autos und Flugzeugen oder den an der Uni-
versit¨
at Paderborn entwickelten autonom fahrenden Shuttles (siehe Abschnitt 1.2). Dabei steigen
die Anspr¨
uche an die Leistungsf¨
ahigkeit, aber auch an die Sicherheit dieser Systeme, stetig. Zu
den Anspr¨
uchen an die Leistungsf¨
ahigkeit geh¨
ort, dass die Systeme zunehmend autonom agie-
ren k¨
onnen m¨
ussen. In Autos wird dies durch Fahrerassistenzsysteme realisiert und im Flugzeug
durch Autopiloten.
Um den wachsenden Anspr¨
uchen gerecht zu werden, ist es erforderlich, dass maschinen-
bauliche, elektrotechnische und Softwarekomponenten zusammenarbeiten. Ein System, das aus
solchen Komponenten zusammengesetzt ist, wird als mechatronisches System bezeichnet.
¨
Uber Sensoren erh¨
alt ein mechatronisches System Informationen ¨
uber seine Umwelt. Bei
Autos oder Shuttles liefern die Sensoren beispielsweise Informationen ¨
uber die Beschaffenheit
der Strecke. Weitere Sensoren werden dazu eingesetzt, andere Verkehrsteilnehmer oder Hinder-
nisse zu erkennen. Die durch die Sensoren erfassten Daten werden dann an Softwarekomponen-
ten weitergeleitet. Die Softwarekomponenten bestimmen anhand dieser Daten, welche Aktionen
durchzuf¨
uhren sind und steuern die entsprechenden Aktoren, die die Aktionen wie Bremsen oder
Beschleunigen durchf¨
uhren.
Neben dem Informationsgewinn ¨
uber Sensoren, k¨
onnen verschiedene mechatronische Syste-
me aber auch durch den Austausch von Daten ¨
uber ein Netzwerk miteinander interagieren.
Die Verarbeitung dieser Daten durch die Software des mechatronischen Systems darf jedoch
nicht beliebig lange dauern, sondern muss innerhalb fest vorgegebener Fristen (engl. deadline)
erfolgen. Deshalb wird die Software auch als Echtzeitsystem bezeichnet.
Aufgrund ihrer Einbettung in ein maschinenbauliches Produkt und ihrer kontrollierenden
Aufgabe sowie der harten Echtzeitrestriktionen, stellt die Software eines mechatronischen Sys-
tems ein sicherheitskritisches System dar. Eine Fehlfunktion der Software, z.B. ¨
Uberschreiten
1
2KAPITEL 1. EINLEITUNG
von Fristen oder fehlerhafte Berechnungen, resultiert im schlimmsten Fall in einem Unfall, der
zu großen finanziellen Sch¨
aden f¨
uhren oder Menschenleben kosten kann.
Die Komplexit¨
at der Software erfordert einen Entwicklungsansatz, der es erlaubt, ein ab-
straktes Modell der Software kompositional zu entwerfen, d.h. statt das System als Ganzes zu
modellieren, muss es m¨
oglich sein das System in Teile zu untergliedern, jedes Teil einzeln zu
modellieren und das Modell des Gesamtsystems dann aus diesen Teilen zusammen zuf¨
ugen.
Aufgrund des sicherheitskritischen Charakters muss es zudem m¨
oglich sein, f¨
ur das Modell be-
stimmte Sicherheitseigenschaften nachzuweisen. Dabei stellt eine Sicherheitseigenschaft eine
Eigenschaft dar, die in jedem erreichbaren Systemzustand erf¨
ullt ist.
Der Nachweis, dass das Modell der Software eines mechatronischen Systems eineMenge von
Sicherheitseigenschaften erf¨
ullt, gestaltet sich in der hier betrachteten Dom¨
ane als sehr schwie-
rig. Zwar stellen die Modelle eine Abstraktion der spezifizierten Systeme dar, jedoch sind auch
sie im Allgemeinen zu komplex, um vollst¨
andig getestet zu werden. Vollautomatische Verifikati-
onstechniken wie Model Checking machen Aussagen ¨
uber alle erreichbaren Zust¨
ande eines Mo-
dells. Allerdings skalieren solche Verfahren nicht f¨
ur Systeme mit beliebig großem bzw. unend-
lich großem Zustandsraum. Die Software eines mechatronischen Systems kann jedoch einen sehr
großen oder unendlich großen Zustandsraum besitzen. Verfahren wie Theorembeweise k¨
onnen
zwar auch zur Verifikation von solchen Systemen eingesetzt werden, sind jedoch nicht vollau-
tomatisch und erfordern Eingaben von Benutzern mit Erfahrungen im Bereich von formalen
Methoden.
1.2 Anwendungsbeispiel
Das in dieser Arbeit verwendete Anwendungsbeispiel stammt aus dem Sonderforschungsbereich
(SFB) 614 - ”Selbstoptimierende Systeme des Maschinenbaus“1. Innerhalb dieses SFBs wird ex-
emplarisch die Software f¨
ur Shuttles entwickelt, wobei jedes Shuttle ein mechatronisches System
darstellt.
Die Shuttles sind Teil eines Transportsystem, dass die Vorteile von individuellen und ¨
offentli-
chen Verkehrsmitteln verbindet. So sollen die Shuttles nicht nach fest vorgegebenen Fahrpl¨
anen
fahren, sondern Personen und G¨
uter auf Anforderung vom Start- zum Zielort bringen. Anderer-
seits sollen die Shuttles aber auch einen geringeren Energiebedarf haben als zum Beispiel Autos,
sodass sie umweltfreundlicher als der Individualverkehr sind.
Um dieses Ziel zu erreichen, fahren die Shuttles autonom und k¨
onnen selbst¨
andig und dezen-
tral Entscheidungen treffen. Die Shuttles fahren auf Schienen. Ein Satellitensystem unterst¨
utzt
die Shuttles bei der Positionsberechnung. Sowohl die Kommunikation zwischen zwei Shuttles,
als auch die Kommunikation zwischen einem Shuttle und den Bahnh¨
ofen, auf denen die Shuttles
angefordert werden k¨
onnen, erfolgt ¨
uber ein Funknetz. In Abbildung 2.14 ist ein solches System
graphisch dargestellt.
Der Antrieb der Shuttles erfolgt, ¨
ahnlich wie bei der Magnetschwebebahn, ¨
uber einen elek-
tromagnetischen Linearmotor. Die dazu notwendigen Statorwellen werden von zwischen den
Schienen eingelassenen Statoren erzeugt.
1www.sfb614.de
1.3. ZIEL UND L ¨
OSUNGSANSATZ 3
Abbildung 1.1: Zwei hintereinander herfahrende Shuttles
Um den Energieverbrauch der Shuttles zu minimieren, k¨
onnen sie Konvois bilden. Diese
Konvois sind kontaktfrei, sodass das Bilden der Konvois w¨
ahrend der Fahrt stattfinden kann. Zur
Bildung von Konvois wird der Abstand zwischen zwei Shuttles minimiert. Je kleiner der Abstand
ist, desto mehr Energie kann von den Shuttles eingespart werden, da der Luftwiderstand verrin-
gert wird. Die Abstandshaltung erfolgt zum einen ¨
uber einen Abstandssensor, der den Abstand
zum vorher fahrenden Shuttle misst und zum anderen dadurch, dass die Shuttles¨
uber das Fun-
knetz Daten austauschen. Diese Kommunikation kann jedoch nicht beliebig erfolgen, sondern
unterliegt einem fest vorgeschriebenen Protokoll (siehe Abschnitt 2.2.1).
Die Abstandssensoren haben allerdings nur eine begrenzte Reichweite und sind, besonders
in Kurven, zur Abstandshaltung alleine nicht ausreichend. Damit ein Shuttle fr¨
uhzeitig erf¨
ahrt,
welche anderen Shuttles sich in seiner N¨
ahe befinden, ist das System in ¨
uberlappende kritische
Abschnitte, ControlledArea, unterteilt. Jeder dieser kritischen Abschnitte wird von einer Ab-
schnittskontrolle, der BaseStation,¨
uberwacht. Bevor ein Shuttle in einen kritischen Abschnitt
einfahren darf, muss es sich bei der entsprechenden Abschnittskontrolle anmelden. Nach der An-
meldung muss das Shuttle in regelm¨
aßigen Abst¨
anden seine Position an die Abschnittskontrolle
senden. Diese wiederum sendet die Daten an alle anderen bei ihr gemeldeten Shuttles. F¨
allt ein
Shuttle aus und sendet seine Positionsdaten nicht, so warnt die Abschnittskontrolle die anderen
Shuttles. Die Abschnittskontrolle hat also die Aufgabe, den Shuttles mitzuteilen, welche anderen
Shuttles in der N¨
ahe sind und vor Gefahren durch defekte Shuttles zu warnen. Die Abschnitts-
kontrolle kann die einzelnen Shuttles jedoch nicht koordinieren; dies erfolgt ausschließlich durch
die Shuttles.
1.3 Ziel und L¨
osungsansatz
Die Informationsverarbeitung eines mechatronischen Systems kann als Operator-Controller-
Modul (OCM) aufgefasst werden [OHG04, HOG04, Ge05]. Ein solches Modul ist in die drei
Ebenen Controller,reflektorischer Operator und kognitiver Operator unterteilt. W¨
ahrend der Con-
troller direkten Zugriff auf die Aktoren des Systems hat, wird der reflektorische Operator dazu
verwendet, um den Controller zu steuern und die Interaktion mit anderen OCMs zu koordinie-
ren. Die Aufgabe des kognitiven Operator besteht darin Wissen ¨
uber die Umwelt und das OCM
selber zu sammeln und dazu zu nutzen, um das Verhalten des OCM besser an die gegebenen
Anforderungen anzupassen.
4KAPITEL 1. EINLEITUNG
Da die Software des reflektorischen Operators f¨
ur die Steuerung des Controllers sowie die
Interaktion des OCMs mit anderen OCMs verantwortlich ist, ist sie sicherheitskritisch. Deshalb
besteht das Ziel dieser Arbeit in der Entwicklung eines kompositionalen Modellierungs- und
Verifikationsansatzes f¨
ur die Software des reflektorischen Operators und hier besonders f¨
ur die
Koordination zwischen zwei OCMs. Der Ansatz soll eine automatische und kompositionale Ve-
rifikation der Software, modelliert durch Graphtransformationssysteme, auch dann erm¨
oglicht,
wenn diese einen unendlichen Zustandsraum besitzen und ihr Initialzustand zum Zeitpunkt der
Verifikation nicht bekannt ist.
Die Grundlage f¨
ur die Softwareentwicklung stellt dabei die MECHATRONIC UML (siehe
[BGT05, GTB+03, GBSO04, Bur05]) dar. Sie ist eine Anpassung der UML f¨
ur die Modellierung
und Verifikation der Software mechatronischer Systeme. Dabei bietet sie vor allem M¨
oglichkei-
ten, um die Interaktion zwischen verschiedenen mechatronischen Systemen zu spezifizieren und
zu verifizieren.
Jedes OCM wird in der MECHATRONIC UML als Komponente aufgefasst. Eine solche Kom-
ponente kann wiederum aus internen Komponenten bestehen. Da die Interaktion zwischen zwei
Komponenten im Allgemeinen sicherheitskritisch ist und strengen Restriktionen unterliegt, muss
sie fest vorgegebenen Protokollen folgen. In der MECHATRONIC UML werden diese Proto-
kolle in Koordinationsmustern festgehalten. Damit zwei Komponenten miteinander interagieren
k¨
onnen, m¨
ussen sie das entsprechende Protokoll ausf¨
uhren, d.h. jede der an der Interaktion betei-
ligten Komponenten muss das Protokoll komponentenintern umsetzen. Die Modellierung mittels
MECHATRONIC UML ist kompositional, d.h. jedes Koordinationsmuster kann unabh¨
angig von
anderen Koordinationsmustern entwickelt werden. Ebenso k¨
onnen die Komponenten unabh¨
angig
voneinander entwickelt werden.
Betrachtet man das Anwendungsbeispiel aus Abschnitt 1.2, so stellt jedes Shuttle und jede
BaseStation ein OCM dar, das in der MECHATRONIC UML als Komponente vom Typ Shuttle
bzw. vom Typ BaseStation modelliert wird. Fahren zwei Shuttles dicht hintereinander her, so
m¨
ussen sie, um nicht zu kollidieren, ein Protokoll zur Abstandshaltung ausf¨
uhren.
Die kompositionale Modellierung der MECHATRONIC UML l¨
asst auch eine kompositionale
Verifikation zu. F¨
ur jedes der Koordinationsmuster kann mittels Model Checking unabh¨
angig
von anderen Koordinationsmustern und Komponenten automatisch nachgewiesen werden, dass
es eine Menge von Sicherheitseigenschaften erf¨
ullt. Auch die Verifikation der Komponenten
erfolgt durch Model Checking und kann unabh¨
angig von anderen Komponenten und den Koor-
dinationsmustern erfolgen. Bei der Verifikation einer Komponente wird ¨
uberpr¨
uft, ob sich die
Komponente so verh¨
alt, wie sie es durch die Umsetzung der Protokolle aus den Koordinations-
mustern versprochen hat.
Das gesamte Modell eines Systems wird dann aus Instanzen der Komponenten und Koordina-
tionsmuster zusammengesetzt. Wurden die Komponenten und Koordinationsmuster erfolgreich
verifiziert, das gesamte Modell syntaktisch korrekt aus Instanzen der Komponenten und Koor-
dinationsmuster zusammengesetzt und erfolgt die Interaktion der Komponenten ausschließlich
¨
uber die Koordinationsmuster, so gilt, dass auch das gesamte Modell die vorgegebenen Sicher-
heitseigenschaften erf¨
ullt. Eine zus¨
atzliche Verifikation, um nachzuweisen, dass die Sicherheits-
eigenschaften auch vom gesamten Modell erf¨
ullt werden, ist nicht notwendig.
1.3. ZIEL UND L ¨
OSUNGSANSATZ 5
Der von Burmester und anderen vorgestellte Ansatz der MECHATRONIC UML garantiert
somit, dass die Interaktion mehrerer Komponenten sicher ist, wenn diese die notwendigen Ko-
ordinationsmuster miteinander ausf¨
uhren. Da mechatronische Systeme sehr dynamisch sind, ist
bei der Instanzierung einer Komponente jedoch nicht bekannt, mit welchen anderen Komponen-
teninstanzen sie zur Laufzeit interagieren muss.
Im Anwendungsbeispiel stellt jedes Shuttle eine Instanz der Komponente Shuttle dar. Die
Shuttles bewegen sich auf den Schienen und begegnen dabei anderen Shuttles, mit denen sie in-
teragieren m¨
ussen, z.B. um eine Abstandshaltung durchzuf¨
uhren. Da sich die Shuttles im Schie-
nennetz frei bewegen k¨
onnen, ist bei der Instanzierung einer Shuttle-Komponenten, also der
Inbetriebnahme eines Shuttles, nicht bekannt, welchen anderen Shuttles dieses Shuttle jemals
begegnen wird.
Außerdem gilt: Existiert zwischen zwei oder mehr Komponenteninstanzen eine Instanz eines
Koordinationsmusters, so bedeutet dies, dass die Komponenten Daten austauschen. Diese Daten
m¨
ussen von den Komponenteninstanzen verarbeitet und evtl. gespeichert werden. Jede der Kom-
ponenteninstanzen stellt ein mechatronisches System dar. In solchen Systemen stehen nur be-
grenzte Rechen- und Speicherkapazit¨
aten zur Verf¨
ugung. Das bedeutet, selbst wenn alle anderen
Komponenteninstanzen eines Systems bei der Instanzierung einer Komponente bekannt sind, so
ist es nicht m¨
oglich, zwischen jedem Komponentenpaar alle m¨
oglichen Muster zu instanzieren,
d.h. es ist nicht m¨
oglich, dass eine Komponenteninstanz mit allen anderen Komponenteninstan-
zen kommuniziert.
Eine Beschreibung, wann eine bestimmte Musterinstanz ben¨
otigt bzw. wann sie nicht mehr
ben¨
otigt wird und wie eine Instanz erzeugt oder gel¨
oscht werden muss, ist mittels der MECHA-
TRONIC UML nicht m¨
oglich.
Aus diesem Grund wird ein Ansatz ben¨
otigt, der es erlaubt, die Instanzierung und das
L¨
oschen von Koordinationsmustern zu modellieren. Um garantieren zu k¨
onnen, dass eine In-
stanz eines Koordinationsmusters immer vorhanden ist wenn sie ben¨
otigt wird, muss der Ansatz
zudem eine formale Verifikation erm¨
oglichen. Da mechatronische Systeme in der Regel zu kom-
plex sind, um als Ganzes modelliert zu werden, muss der Ansatz zus¨
atzlich eine kompositionale
Modellierung und Verifikation erlauben.
Ein solcher Ansatz wird in dieser Arbeit vorgestellt und in den existierenden Modellierungs-
und Verifikationsprozess der MECHATRONIC UML integriert.
Der in dieser Arbeit vorgestellte Ansatz basiert auf der folgenden Idee: Ein Systemzu-
stand wird durch seine Koordinationsmuster- und Komponenteninstanzen sowie durch die
existierenden Verbindungen zwischen den Instanzen charakterisiert. Eine solche Instanzsitua-
tion kann auch als Graph aufgefasst werden. In einem derartigen Graphen entspricht jede
Koordinationsmuster- und Komponenteninstanz einem Knoten und jede Verbindung zwischen
Instanzen einer Kante. Ein ¨
Ubergang von einem Systemzustand in einen anderen beschreibt dann
das Erzeugen oder das L¨
oschen von Instanzen oder deren Verbindungen. Fasst man einen Sys-
temzustand als Graphen auf, so werden bei einem Zustands¨
ubergang Knoten und Kanten erzeugt
bzw. gel¨
oscht. Wann ein Konten oder eine Kante erzeugt oder gel¨
oscht werden muss und wie ein
neu erzeugter Knoten oder eine neu erzeugte Kante in einen Graphen eingef¨
ugt wird, wird mittels
Graphtransformationsregeln definiert. Damit entspricht ein Zustands¨
ubergang einer Graphtrans-
formation.
6KAPITEL 1. EINLEITUNG
In dieser Arbeit werden zur Beschreibung von Graphtransformationen Story Patterns
[FNTZ98, Z¨
un01] verwendet. Story Patterns wurden speziell f¨
ur die objektorientierte Model-
lierung entwickelt und stellen eine Erweiterung der UML-Aktivit¨
atendiagramme dar. Der Vorteil
bei einer Verwendung einer UML-nahen Modellierungssprache liegt darin, dass der Einarbei-
tungsaufwand in diese Sprache gering ist und somit eine gr¨
oßere Akzeptanz des Ansatzes zu
erwarten ist. Da Story Patterns eine spezielle Form von Graphtransformationsregeln darstellen,
besitzen sie eine formal definierte Semantik, sodass sie mittels formaler Verifikationstechniken
¨
uberpr¨
uft werden k¨
onnen.
Fasst man einen Systemzustand als Graphen auf, so bietet dies einen weiteren Vorteil: Struk-
turelle Sicherheitseigenschaften, die vom System erf¨
ullt werden m¨
ussen, k¨
onnen ebenfalls als
Graphen aufgefasst werden. In dieser Arbeit werden Graphmuster eingef¨
uhrt, die eine spezielle
Form von Graphen darstellen, um solche strukturellen Eigenschaften zu spezifizieren. Von be-
sonderem Interesse werden dabei die so genannten verbotenen Graphmuster sein, da diese dazu
genutzt werden k¨
onnen, um kritische Situationen und Unf¨
alle zu modellieren, die nie eintreten
d¨
urfen. Auch solche Graphmuster k¨
onnen als Story Patterns beschrieben werden.
Im Anwendungsbeispiel kann ein solches verbotenes Graphmuster dazu verwendet werden,
um zu beschreiben, dass zwei Shuttles sehr dicht hintereinander herfahren, ohne jedoch ein Koor-
dinationsmuster zur Abstandshaltung miteinander auszuf¨
uhren. Dies entspricht einer kritischen
Situation, da das vordere Shuttle bei seinen Aktionen keine R¨
ucksicht auf das hintere Shuttle
nimmt und ihm beispielsweise nicht signalisiert, dass es bremsen m¨
ochte. In diesem Fall droht
eine Kollision der beiden Shuttles.
F¨
ur eine Menge von verbotenen Graphmustern soll durch formale Verifikation gezeigt wer-
den, dass die Anwendung der Graphtransformationsregeln niemals einen Graphen erzeugen
k¨
onnen, der ein solches verbotenes Graphmuster enth¨
alt. Das bedeutet, es soll gepr¨
uft werden,
dass niemals eine der durch die verbotenen Graphmuster beschriebenen kritischen Situationen
oder Unf¨
alle eintritt.
Zur Verifikation von Graphtransformationssystemen existieren zwar einige Ans¨
atze (sie-
he Kapitel 6), jedoch sind diese zumeist auf Systeme beschr¨
ankt, in denen nur endli-
che viele Zust¨
ande erreichbar sind. Die Regeln zur Instanzierung und zum L¨
oschen von
Koordinationsmuster- und Komponenteninstanzen sowie deren Verbindungen, k¨
onnen aber un-
ter Umst¨
anden unendlich viele Zust¨
ande erzeugen. Dar¨
uber hinaus ben¨
otigen die meisten dieser
Ans¨
atze den Anfangszustand des Systems. Da die Verifikation zum fr¨
uhst m¨
oglichen Zeitpunkt
im Entwicklungsprozess erfolgen soll, der Anfangszustand im Allgemeinen jedoch erst recht
sp¨
at bekannt ist, w¨
urde die Verwendung dieser Ans¨
atze den Entwicklungsprozess verz¨
ogern.
Deshalb sind die existierenden Ans¨
atze im Allgemeinen in der Dom¨
ane der mechatronischen
Systeme nicht einsetzbar.
Aus diesem Grund wird in dieser Arbeit ein Verfahren eingef¨
uhrt, dass die Verifikation von
Graphtransformationssystemen auch dann erlaubt, wenn das System unendlich viele erreichbare
Zust¨
ande besitzt. Statt wie die existierenden Verfahren f¨
ur jeden Zustand zu pr¨
ufen, ob dieser
korrekt ist, d.h. zu pr¨
ufen ob er keines der verbotenen Graphmuster enth¨
alt, pr¨
uft der hier vorge-
stellte Ansatz, ob ein inkorrekter Zustand das Resultat einer Regelanwendung auf einen korrek-
ten Graphen sein kann. Wie in der Arbeit von Heckel und Wagner (siehe [HW95] und Abschnitt
6.1) wird dazu die rechte Seite der betrachteten Graphtransformationsregel mit einem verbotenen
1.4. AUFBAU DER ARBEIT 7
Graphmuster verkn¨
upft, daraus resultiert das so genannte Ergebnisgraphmuster. Auf dieses Er-
gebnisgraphmuster wird dann die entsprechende Regel r¨
uckw¨
arts angewendet, woraus das Start-
graphmuster resultiert. Enth¨
alt dieses Startgraphmuster kein verbotenes Graphmuster, so wurde
ein Beispiel gefunden, das zeigt, dass die betrachtete Regel einen korrekten Zustand in einen
inkorrekten ¨
uberf¨
uhren kann. Dabei wird allerdings nicht betrachtet, ob der inkorrekte Zustand
ausgehend vom Startzustand des Systems erreichbar ist. Damit pr¨
uft der Ansatz f¨
ur jedes ver-
botene Graphmuster, ob sein ”Nicht-Auftreten“eine induktive Invariante des Graphtransformati-
onssystems ist. Im Gegensatz zum Ansatz von Heckel und Wagner wird jedoch die betrachtete
Regel nicht modifiziert. Zudem wird gezeigt, wie die Regelmenge in voneinander unabh¨
angi-
ge Teilmengen unterteilt werden kann. Diese Teilmengen k¨
onnen dann unabh¨
angig voneinander
verifiziert werden.
Wird ein Beispiel gefunden, in dem eine Regel einen korrekten Graphen in einen inkorrekten
¨
uberf¨
uhrt, so werden diese beiden Graphen zusammen mit der angewendeten Regel als Gegen-
beispiel zur¨
uckgeliefert. Die Generierung eines solchen Gegenbeispiels sowie seiner Darstellung
in der gleichen Notation, mit der auch das Modell entwickelt wurde, erm¨
oglicht eine einfache
Fehlerdiagnose.
In dieser Arbeit wird das Verfahren zun¨
achst formalisiert. Dies geschieht jedoch nicht auf
Ebene der Story Patterns, sondern allgemeiner f¨
ur Graphtransformationssysteme, wie sie zu-
meist in der Literatur verwendet werden. Die dabei gewonnenen Erkenntnisse werden auf Story
Pattern ¨
ubertragen und prototypisch in der Fujaba Real-Time Tool Suite2umgesetzt. Das Verfah-
ren soll dann anhand eines kleinen Ausschnitts des im vorangegangenen Abschnitts vorgestellten
Anwendungsbeispiels evaluiert werden.
Zusammen mit dem bereits existierenden Ansatz der MECHATRONIC UML und dessen Um-
setzung in der Fujaba Real-Time Tool Suite bietet der Ansatz dann die M¨
oglichkeit, die Software
eines mechatronischen Systems kompositional zu modellieren und automatisch zu verifizieren.
Damit ist es dann m¨
oglich, die Leistungsf¨
ahigkeit technischer Systeme zu erh¨
ohen, indem
Softwarekomponenten in Systeme, bestehend aus maschinenbaulichen und elektrotechnischen
Komponenten, integriert werden. Trotz der daraus resultierenden Komplexit¨
at der Software
kann der vorgestellte Ansatz ihre Korrektheit im Bezug auf bestimmte Sicherheitseigenschaf-
ten gew¨
ahrleisten.
1.4 Aufbau der Arbeit
Die Arbeit ist in die folgenden Kapitel unterteilt:
Kapitel 2 stellt die Architektur des Operator-Controller-Moduls sowie die existierenden
Modellierungs- und Verifikationskonzepte der MECHATRONIC UML dar. Neben
dem Modellierungs- und Verifikationsansatz wird in diesem Kapitel auch beschrieben, wie
die relevanten Komponenten und Koordinationsmuster eines mechatronischen Systems
sowie die Regeln zu deren Instanzierung und L¨
oschen identifiziert werden k¨
onnen. Am
Ende des Kapitels wird der Prozess vorgestellt, der die Identifikation der relevanten
2www.fujaba.de
8KAPITEL 1. EINLEITUNG
Komponenten und Koordinationsmuster, deren Modellierung und Verifikation beinhaltet.
Dieser Prozess beschreibt auch, wie die Verifikation der Regeln zum Instanzieren und
L¨
oschen von Komponenten und Koordinationsmustern sowie deren Verbindungen in den
Gesamtprozess integriert wird.
Kapitel 3 beschreibt einen Ansatz zum Nachweis von induktiven Invarianten in Graphtransformati-
onssystemen. Dieser Ansatz wird bei der Entwicklung sicherheitskritischer Software f¨
ur
mechatronische Systeme dazu verwendet, um die Regeln zum Instanzieren und L¨
oschen
von Komponenten und Koordinationsmustern zu verifizieren.
Kapitel 4 beschreibt informal die Abbildung der in Kapitel 2 eingef¨
uhrten Story Patterns auf die in
Kapitel 3 beschriebenen Graphtransformationsregeln und verbotenen Graphmuster. Die-
se Abbildung erm¨
oglicht die Verwendung des Verifikationsansatzes aus Kapitel 3 f¨
ur die
Verifikation von Story Patterns.
Kapitel 5 beschreibt die prototypische Umsetzung des gesamten Modellierungs- und Verifikations-
ansatzes. Am Ende des Kapitels erfolgt eine Evaluierung anhand des Anwendungsbei-
spiels.
Kapitel 6 fasst verwandte Arbeiten zur Verifikation von Graphtransformationssystemen zusammen.
Kapitel 7 fasst die Ergebnisse dieser Arbeit zusammen und liefert einen ¨
Uberblick ¨
uber m¨
ogliche
Erweiterungen des Ansatzes.
Kapitel 2
Grundlagen
In diesem Kapitel werden die existierenden Ans¨
atze vorgestellt, die f¨
ur die vorliegende Arbeit
als Grundlage dienen. Dar¨
uber hinaus wird gezeigt, wie der in dieser Arbeit vorgestellte Ansatz
in die existierenden Ans¨
atze integriert werden kann.
In [OHG04, HOG04, Ge05] wurde die Architektur des Operator-Controller-Moduls vorge-
stellt. Diese bietet die M¨
oglichkeit die Informationsverarbeitung eines mechatronischen Systems
zu Strukturieren.
Die Software eines mechatronischen Systems ist im Allgemeinen sehr komplex und sicher-
heitskritisch. Dies gilt insbesondere f¨
ur den Teil der Software, der f¨
ur die Steuerung der Hard-
ware sowie die Interaktion mit anderen mechatronischen Systemen verantworlich ist. Um diese
Komplexit¨
at handhaben zu k¨
onnen und eine effiziente Analyse zu erm¨
oglichen, wird eine mo-
dellbasierte Softwareentwicklung verwendet.
Bei der modellbasierten Softwareentwicklung wird sowohl die Architektur des Softwaresys-
temsals auch seinVerhalten in einemModellfestgehalten. Dabei wirdvon implementierungsspe-
zifischen Details abstrahiert. Das resultierende Modell soll mittels formaler Methoden verifiziert
werden k¨
onnen, damit Modellierungsfehler m¨
oglichst fr¨
uh im Entwicklungsprozess aufgedeckt
werden.
Die Unified Modeling Language (UML, siehe [UML05]) stellt die Standardmodellierungs-
sprache f¨
ur die modellbasierte Softwareentwicklung dar. Sie enth¨
alt verschiedene Notationen f¨
ur
die Modellierung von Softwarearchitekturen und Verhalten.
Um ein mechatronisches System spezifizieren zu k¨
onnen, muss auch echtzeitf¨
ahige Software
spezifiziert werden k¨
onnen. Dies wird durch die UML, wie sie in [UML05] definiert ist, jedoch
nicht bzw. nur unzureichend unterst¨
utzt. Deshalb ist es notwendig, einige Notationen der UML
auszuw¨
ahlen und diese zu verfeinern oder zu erweitern. Eine solche Anpassung der UML an
die Aufgaben bei der Modellierung von mechatronischen Systemen erfolgte im Rahmen des
SFB 614. Die dabei entstandene Anpassung wird als MECHATRONIC UML [BGT05, BTG04,
GBSO04, GTB+03, Bur05] bezeichnet und soll in diesem Kapitel eingef¨
uhrt werden.
In diesem Kapitel wird zun¨
achst die Modellierung der Architektur vorgestellt 2.1. Nach-
dem die Architektur der Software modelliert wurde, erfolgt in Abschnitt 2.2 die Modellierung
des Koordinationsverhaltens. Der vorgestellte Modellierungsansatz ist kompositional, sodass das
System nicht als ganzes sondern in Form kleinerer Teilsysteme (Komponenten und Koordinati-
9
10 KAPITEL 2. GRUNDLAGEN
onsmuster) modelliert wird. Die Komposition des Gesamtsystems aus diesen Teilsystemen ist
Inhalt von Abschnitt 2.3. Da die hier betrachtete Software sicherheitskritisch, auf der anderen
Seite aber auch zu komplex ist, um vollst¨
andig getestet werden zu k¨
onnen, wird in Abschnitt 2.4
ein Ansatz zur formalen, kompositionalen Verifikation vorgestellt. Der gesamte Modellierungs-
und Verifikationsprozess wird in Abschnitt 2.5 erl¨
autert.
2.1 Architektur
Die Strukturierung der Informationsverarbeitung erfolgt mittels der Architektur des Operator-
Controller-Moduls (siehe Abschnitt 2.1.1). Diese teilt ein mechatronisches System in die drei
Ebenen Controller, reflektorischer Operator und kognitiver Operator ein.
Von besonderem Interesse ist dabei die Software des reflektorischen Operators, da diese f¨
ur
die Steuerung des Controllers, der die Aktoren des Systems steuert, sowie die Interaktion mit
anderen mechatronischen Systemen verantwortlich ist.
Zur Modellierung der Softwarearchitektur des reflektorischen Operators werden
Komponenten- und Klassendiagramme verwendet.
2.1.1 Die Operator-Controller-Modul Architektur
Die Informationsverarbeitung, d.h. die Aufnahme von Daten zum Beispiel ¨
uber Sensoren sowie
deren Verarbeitung, eines mechatronischen Systems ist komplex. In [OHG04, HOG04, Ge05]
stellen Oberschelp, Hestermeyer und Giese deshalb die Architektur des Operator-Controller-
Modul (OCM) zur strukturierten und modularen Entwicklung der Informationsverarbeitung eines
mechatronischen Systems vor.
In diesem Ansatz wird ein mechatronisches System als Operator-Controller-Modul aufge-
fasst, das in die drei Ebenen Controller, reflektorischer Operator und kognitiver Operator unter-
teilt werden kann. Die Struktur eines solchen Operator-Controller-Moduls ist in Abbildung 2.1
gegeben.
Die unterste Ebene des Moduls bildet der Controller. Dieser kann die mechanischen Teile des
Gesamtsystems durch Zugriff auf die Aktoren direkt beeinflussen. Seine Aufgabe besteht darin
Signale aufzunehmen, zu verarbeiten und weiter zu geben, deshalb wird er auch als motorischer
Kreis bezeichnet. Dabei unterliegt die Verarbeitung der Signale harten Echtzeitbedingungen,
das bedeutet, dass die Verarbeitung innerhalb einer fest vorgegebenen Zeit erfolgen muss. Ist
die Verarbeitung innerhalb dieser Zeit nicht abgeschlossen, so kann das zu einer sicherheitskriti-
schen Situation f¨
uhren. Ein Controller kann aus mehreren Reglern bestehen, zwischen denen um-
geschaltet werden kann. Die Informationsverarbeitung des Controllers ist quasi-kontinuierlich,
d.h. die Sensoren nehmen kontinuierlich Daten auf und leiten diese zur Verarbeitung weiter.
¨
Uber der Controller-Ebene liegt die Ebene des reflektorischen Operators. Zu den Aufgaben
des reflektorischen Operators geh¨
ort die ¨
Uberwachung des Controllers. Der reflektorische Opera-
tor kann keinen direkten Einfluss auf die Aktorik des Systems nehmen. Er kann jedoch die Kon-
figuration des Controllers ver¨
andern und dadurch die Umschaltung der Regler bewirken. Auch
die sicherheitskritische Koordination mit anderen Operator-Controller-Modulen erfolgt ¨
uber den
2.1. ARCHITEKTUR 11
Abbildung 2.1: Die Architektur des Operator-Controller-Moduls. Quelle: [Ge05]
reflektorischen Operator. Die ¨
Uberwachungs-, Steuerungs- und Koordinationsfunktionen des re-
flektorischen Operators sind diskret und ereignisbasiert.
Auf der obersten Ebene der OCM-Architektur befindet sich der kognitive Operator. Dieser
Operator verwendet Lernverfahren, modellbasierte Optimierungsverfahren und wissensbasierte
Systeme, um Wissen ¨
uber sich und seine Umwelt zu sammeln und zur Verbesserung des eigenen
Verhaltens auszunutzen.
Der Name Operator-Controller-Modul beschreibt die Zweiteilung eines mechatronischen
Systems in den Teil, der auf die Aktorik des Systems direkt zugreifen kann, sowie den Teil
der nur indirekten Zugriff auf die Mechanik besitzt. Diese beiden Teile werden als Operator und
als Controller bezeichnet.
In dieser Arbeit werden Konzepte zur Modellierung und Verifikation des reflektorischen Ope-
rators vorgestellt, wobei die sicherheitskritische Koordination im Fokus der Arbeit liegt.
2.1.2 Komponentendiagramme
Die Software eines Operator-Controller-Moduls wird modular beschrieben. Dazu werden Teile
des Systems als Komponenten aufgefasst, die miteinander interagieren k¨
onnen. Ein Operator-
Controller-Modul stellt selber eine Komponente dar. Eine schematische Darstellung einer Kom-
ponente, die das Operator-Controller-Modul aus Abbildung 2.1 repr¨
asentiert ist in Abbildung 2.2
gegeben. Im Folgenden wird die detaillierte Darstellung von Controller, reflektorischem Opera-
tor und kognitiven Operator weggelassen und nur die Koordination des OCM mit anderen OCMs
modelliert.
Nach Szyperski [Szy02] ist ”eine Softwarekomponente eine Kompositionseinheit mit ver-
traglich festgelegten Schnittstellen und expliziten Kontextabh¨
angigkeiten. Eine Softwarekompo-
nente kann unabh¨
angig verteilt und durch Dritte mit anderen Komponenten verbunden werden.“
12 KAPITEL 2. GRUNDLAGEN
"!$#%
&
'(
*)
,+, - . /!0#,
21
3'(
Abbildung 2.2: OCM als Komponente. Quelle: [Ge05]
Das bedeutet, eine Komponente ist eine Einheit, deren Implementierung nach außen nicht
sichtbar ist. F¨
ur eine Komponente wird festgelegt, welche Nachrichten sie f¨
ur andere Kompo-
nenten bereitstellt bzw. welche Nachrichten sie von anderen Komponenten erwartet.
In einem UML-Komponentendiagramm [UML05] werden die Komponententypen festge-
legt. Das nach außen sichtbare Verhalten einer Komponente, d.h. die Interaktion mit anderen
Komponenten, wird durch ben¨
otigte Schnittstellen (engl. required interfaces) und bereitgestellte
Schnittstellen (engl. provided interfaces) beschrieben. Dabei entsprechen die ben¨
otigten Schnitt-
stellen den ”Kontextabh¨
angigkeiten“von Szyperski und die bereitgestellten Schnittstellen den
”vertraglich festgelegten Schnittstellen“. Eine ben¨
otigte Schnittstelle beschreibt, welche Nach-
richten die Komponente von anderen Komponenten erwartet. Die bereitgestellte Schnittstelle
beschreibt, welche Nachrichten die Komponente anderen Komponenten zur Verf¨
ugung stellt.
Mehrere Schnittstellen einer Komponente k¨
onnen in einem Port zusammengefasst werden.
Im Beispiel stellt jedes Shuttle eine Komponente dar. Um sich gegenseitig koordinieren zu
k¨
onnen, m¨
ussen die Shuttles sowohl Nachrichten versenden als auch empfangen k¨
onnen. Das
Senden und Empfangen von Nachrichten erfolgt ¨
uber ben¨
otigte und bereitgestellte Schnittstel-
len. Abbildung 2.3 zeigt die Komponente, die den Typ Shuttle definiert. Die Komponente besitzt
zwei ben¨
otigte Schnittstellen, dargestellt durch einen Halbkreis, und zwei bereitgestellte Schnitt-
stellen, dargestellt durch einen Kreis. Jeweils eine ben¨
otigte und eine bereitgestellte Schnittstelle
werden in einem Port zusammengefasst. Die Ports werden durch Quadrate an den R¨
andern der
Komponente repr¨
asentiert.
Abbildung 2.3: Definition des Komponententyps Shuttle
Nachdem die Komponententypen festgelegt wurden, k¨
onnen konkrete Komponen-
teninstanzen betrachtet werden. Auch Komponenteninstanzen werden in einem UML-
Komponentendiagramm dargestellt. Wird die bereitgestellte Schnittstelle einer Komponente mit
der ben¨
otigten Schnittstelle einer zweiten Komponente verbunden, so bietet die MECHATRO-
NIC UML die M¨
oglichkeit, dies abk¨
urzend durch einen Pfeil darzustellen. Dieser Pfeil verl¨
auft
2.1. ARCHITEKTUR 13
von der Komponente, die die Schnittstelle bereitstellt, zu der Komponente mit der ben¨
otigten
Schnittstelle. Tauschen zwei Komponenten in beide Richtungen Nachrichten aus, d.h. beide ha-
ben jeweils eine ben¨
otigte und eine bereitgestellte Schnittstelle, so wird abk¨
urzend ein Doppel-
pfeil verwendet. Eine solche Verbindung von zwei Komponenten wird als Konnektor bezeichnet.
Abbildung 2.4 zeigt zwei Instanzen der Shuttle-Komponente, die miteinander ¨
uber einen Kon-
nektor kommunizieren.
Abbildung 2.4: Zwei Instanzen der Shuttle-Komponente
Ein Komponententyp beschreibt, welche Schnittstellen eine Komponente bereitstellt
bzw. ben¨
otigt. Das Verhalten dieser Schnittstellen wird intern durch die in Abschnitt 2.2.1 ein-
gef¨
uhrten Real-Time Statecharts spezifiziert. Das interne Verhalten der Komponente wird durch
Instanzen interner Komponenten oder durch Real-Time Statecharts beschrieben.
Weitere interne Strukturen einer Komponente wie beispielsweise Datenstrukturen, k¨
onnen
durch UML-Klassendiagramme definiert werden.
2.1.3 Klassendiagramme
UML-Klassendiagramme [UML05] werden dazu verwendet, die interne Architektur einer Kom-
ponente zu spezifizieren, ihre Datenstrukturen festzulegen und um das interne Verhalten der
Komponenten realisieren zu k¨
onnen.
Abbildung 2.5 zeigt das Klassendiagramm, das die interne Architektur der Shuttle-
Komponente festlegt. Es definiert die Ontologie des Shuttles, d.h. in ihm wird die Sicht des
Shuttles auf seine Umgebung definiert.
Abbildung 2.5: Klassendiagramm, das die Ontologie der Shuttle-Komponente beschreibt
Im Beispiel besteht das Klassendiagramm, das die Ontologie beschreibt, aus den Klassen
Shuttle,Track und BaseStation sowie den Assoziationen locatedOn,successor und monitors.
Die locatedOn-Assoziation wird dazu benutzt, um zu beschreiben, auf welchem Track sich ein
14 KAPITEL 2. GRUNDLAGEN
Shuttle befindet. Die Kardinalit¨
aten an der Assoziation besagen, dass sich jedes Shuttle auf ge-
nau einem Track befindet. Die Tracks sind so kurz, dass sich h¨
ochstens ein Shuttle darauf befin-
den kann. Dies wird durch die Kardinalit¨
at 0. . . 1ausgedr¨
uckt. Das Schienennetz wird durch die
successor-Assoziationen modelliert. F¨
ur Weichen gibt es keine eigene Klasse. Eine Weiche wird
dadurch modelliert, dass ein Track zwei Vorg¨
anger oder zwei Nachfolger hat. Die Aufgabe der
BaseStation besteht darin, die Tracks und die auf ihnen fahrenden Shuttles zu ¨
uberwachen. Jede
BaseStation kann beliebig viele Tracks¨
uberwachen und ¨
uberwacht mindestens einen, dargestellt
durch die Kardinalit¨
at 1· · · ∗ an der monitors-Assoziation. Umgekehrt kann ein Track von belie-
big vielen BaseStations¨
uberwacht werden und wird von mindestens einer ¨
uberwacht, d.h. die
von den BaseStations¨
uberwachten Bereiche k¨
onnen sich ¨
uberlappen.
In diesem Abschnitt wurden Komponentendiagramme eingef¨
uhrt, um die Architektur eines
Softwaresystems zu modellieren. F¨
ur jede der Komponenten kann eine Menge von bereitgestell-
ten und ben¨
otigten Schnittstellen angegeben werden, die festlegen, welches Verhalten eine Kom-
ponente nach außen zeigt bzw. welches Verhalten sie von anderen Komponenten erwartet. Intern
wird eine Komponente mittels eines Klassendiagramms strukturiert, das auch die Datenstruktu-
ren der Komponente festlegt. Im folgenden Abschnitt soll betrachtet werden, wie das Verhalten
der Schnittstellen sowie das interne Verhalten einer Komponente spezifiziert werden kann.
2.2 Verhalten
Nachdem die Architektur der Software durch Komponenten- und Klassendiagramme spezifiziert
wurde, kann das interne Verhalten der Komponenten definiert werden.
Ein Teil dieses Verhaltens ist die Kommunikation zwischen zwei Komponenten. Die Schnitt-
stellen der Komponenten stellen dar, welche Nachrichten eine Komponente bereitstellt bzw. wel-
che Nachrichten sie von anderen Komponenten ben¨
otigt. Existiert zwischen zwei Komponenten-
instanzen ein Konnektor, d.h. die ben¨
otigten und bereitgestellten Schnittstellen der Komponenten
wurden miteinander verbunden, so muss garantiert werden k¨
onnen, dass entweder Nachrichten,
die von der einen Komponente versandt werden, von der anderen Komponente auch empfangen
werden oder beim Verlust oder zu sp¨
aten Eintreffen einer Nachricht kein Unfall und keine kriti-
sche Situation eintreten kann. Eine Kommunikation, die diese Eigenschaft erf¨
ullt wird als sicher
bezeichnet. Um eine solche sicher Kommunikation zu spezifizieren werden Kommunikations-
protokolle verwendet.
2.2.1 Kommunikation
Bei der Modellierung einer sicheren Kommunikation zwischen Komponenten muss zum einen
ber¨
ucksichtigt werden, dass das Senden und Empfangen von Nachrichten zwischen Kom-
ponenten Zeit ben¨
otigt. Zudem muss ber¨
ucksichtigt werden, dass Nachrichten verloren ge-
hen k¨
onnen, zum Beispiel durch ein unzuverl¨
assiges ¨
Ubertragungsmedium. Die Echtzeit-
Koordinationsmuster der MECHATRONIC UML unterst¨
utzen die Modellierung einer sicheren
Kommunikation.
2.2. VERHALTEN 15
Ein Echtzeit-Koordinationsmuster [GTB+03] (oder kurz Koordinationsmuster) besteht aus
•einer Menge von Rollen, die die Kommunikationspartner darstellen,
•einer Menge von Rolleninvarianten,
•Konnektoren, die die Rollen verbinden und
•einem Musterconstraint.
Eine Rolle beschreibt die externe Kommunikation eines Kommunikationspartners. Sie gibt
an, welche Nachrichten versendet werden, welche Nachrichten erwartet werden, in welcher Rei-
henfolge die Nachrichten versandt oder empfangen werden, wie viel Zeit mindestens verge-
hen muss oder maximal vergehen darf, wenn eine Nachricht verschickt oder empfangen wer-
den soll. Zur Spezifikation der Kommunikation werden Zustandsautomaten verwendet. Da die
in der UML eingef¨
uhrten Protokoll-Zustandsautomaten [UML05] kaum die Modellierung von
Echtzeitverhalten unterst¨
utzen, werden f¨
ur die Spezifikation der Rollen Real-Time Statecharts
verwendet (siehe unten).
Die Rollen und ihr durch Real-Time Statecharts spezifiziertes Verhalten sind eine abstrakte
Beschreibung eines Kommunikationspartners bzw. seines extern sichtbaren Kommunikationsver-
haltens. Soll eine Komponente in einer Kommunikation eine bestimmte Rolle ¨
ubernehmen, so
muss sie die entsprechende Rolle verfeinern. Das bedeutet, die Komponente muss das Kommu-
nikationsverhalten der Rolle realisieren. Nach [Gie03, GTB+03] darf dabei jedoch kein zus¨
atzli-
ches extern sichtbares Verhalten hinzugef¨
ugt werden. Zudem muss Verhalten, das durch die Rolle
garantiert wird, auch von der Komponente gezeigt werden. Außerdem muss die Komponente die
Rolleninvarianten der von ihr realisierten Rollen erf¨
ullen.
Eine Rolleninvariante ist einer bestimmten Rolle zugeordnet. Sie beschreibt eine Eigenschaft,
die von dem entsprechenden Kommunikationspartner erf¨
ullt werden muss. Durch formale Veri-
fikation kann gezeigt werden, dass eine Komponente, die eine Rolle bei der Kommunikation
¨
ubernommen hat, die entsprechende Rolleninvariante einh¨
alt (siehe Abschnitt 2.4.2). Beschrie-
ben werden Rolleninvarianten zum Beispiel durch TCTL-Formeln [ACD90].
Die Konnektoren beschreiben die Verbindung zwischen den Rollen. Sie werden wie die Rol-
len durch ein Real-Time Statechart beschrieben. Im Konnektor werden die Qualit¨
atseigenschaf-
ten (engl. quality of service) der Verbindung zwischen den Rollen spezifiziert. Die Beschreibung
enth¨
alt zum Beispiel, wie lange das Verschicken einer Nachricht ben¨
otigt oder wie zuverl¨
assig
die Verbindung ist.
Das Musterconstraint beschreibt eine Eigenschaft, die von allen Kommunikationspartnern
und den Konnektoren eingehalten werden muss. Wie die Rolleninvarianten werden auch die
Musterconstraints als TCTL-Formeln spezifiziert.
Zur Modellierung einer Komponente werden die Rollen ausgew¨
ahlt, deren Kommunikations-
verhalten die Komponente umsetzen soll. Eine Komponente kann dadurch an der Kommunikati-
on verschiedener Koordinationsmuster teilnehmen. Die Modellierung des Komponentenverhal-
tens ist Inhalt von Abschnitt 2.2.2.
Die Trennung von Kommunikations- und Komponentenverhalten erm¨
oglicht einerseits eine
Wiederverwendung der Koordinationsmuster, andererseits kann auf diese Weise eine formale
16 KAPITEL 2. GRUNDLAGEN
Verifikation durchgef¨
uhrt werden. In Abschnitt 2.3.1 wird gezeigt, wie ein komplexes Software-
system aus Komponenten- und Koordinationsmusterinstanzen zusammengesetzt werden kann.
Im Shuttle-System m¨
ussen sich beispielsweise zwei Shuttle-Instanzen gegenseitig koordinie-
ren, um hintereinander fahren zu k¨
onnen, ohne zu kollidieren [BGH+05]. F¨
ur diese Koordination
wird das DistanceCoordination-Koordinationsmuster aus Abbildung 2.6 verwendet. Dieses Ko-
ordinationsmuster besteht aus den beiden Rollen frontRole und rearRole und einem bidirektio-
nalem Konnektor. Die Rollen werden durch die beiden Quadrate im Diagramm dargestellt, das
Koordinationsmuster als gestricheltes Oval.
!
"#
$"%
&('*) +,- ./
&,'0) +12- /
&,'*) +12- /
&('*) +43526# 879:;<
!
" +7=>:;?
Abbildung 2.6: Das DistanceCoordination-Koordinationsmuster
An das Koordinationsmuster sind zwei Musterconstraints angef¨
ugt. Das Constraint
A[] not deadlock besagt, dass die Kommunikation der Rollen ¨
uber den Konnektor immer ver-
klemmungsfrei (engl. deadlock free) sein muss. Das Constraint A[] not (rearRole.convoy and
frontRole.noConvoy)verlangt, dass das vordere Shuttle nicht im Zustand noConvoy f¨
ahrt, wenn
das hintere Shuttle im Zustand convoy f¨
ahrt. Andernfalls w¨
urde das vordere Shuttle bei seinen
Aktionen nicht ber¨
ucksichtigen, dass das hintere Shuttle mit sehr geringem Abstand hinter ihm
herf¨
ahrt.
Ebenso ist an jede der beiden Rollen eine Rolleninvariante angef¨
ugt. Im Beispiel wird von
den Rollen nur verlangt, dass sie verklemmungsfrei arbeiten.
Abbildung 2.7 zeigt die Umsetzung des Koordinationsmusters durch zwei Instanzen der
Shuttle-Komponente. Wobei der Port front des Shuttless1 die frontRole realisiert und der Port
rear von Shuttle s2 die rearRole.
Damit zwei Shuttle-Komponenten kollisionsfrei hintereinander herfahren k¨
onnen, muss dass
Verhalten der Rollen so spezifiziert werden, dass die Shuttles Konvois bilden und wieder aufl¨
osen
k¨
onnen. Zudem m¨
ussen die Protokolle, die das Rollenverhalten beschreiben, so modelliert wer-
den, dass sie eventuelle Nachrichtenverluste abfangen k¨
onnen, ohne dass die beteiligten Shutt-
les kollidieren. Bisher wurde jedoch nur die Struktur des Koordinationsmusters betrachtet, das
Verhalten wurde noch nicht spezifiziert. Die Spezifikation des Rollenverhaltens, aber auch des
Verhaltens des Konnektors, erfolgt ¨
uber die im folgenden Abschnitt vorgestellten Real-Time
Statecharts.
2.2. VERHALTEN 17
! #" $%'& (
)
*,+-/.
)
0*1+$2.
4365-798:;<&
=157>8:;<&
! #" $%'& (
! #" $!?'& @$(
! #" $BA4C$;D>& E#FGHJI;D9& -EKFG$L
I;C
?$
Abbildung 2.7: Instanz des DistanceCoordination-Musters
Real-Time Statecharts
Zur Spezifikation von Protokollen und Verhalten werden in der UML-Zustandsautomaten
[UML05] verwendet. Protokolle werden durch Protokoll-Zustandsautomaten (engl. protocol
statemachines) modelliert und Verhalten durch Verhaltens-Zustandsautomaten (engl. behavioral
statemachines).
Bei der Spezifikation der Software eines mechatronischen Systems spielt die Modellie-
rung von Zeit eine besondere Rolle. UML-Zustandsautomaten bieten zur Modellierung von
Zeitverhalten jedoch nur das after-Konstrukt an. Dieses Konstrukt ist f¨
ur die Modellierung
der hier betrachteten mechatronischen Systeme nicht ausreichend. Zudem besitzen die UML-
Zustandsautomaten eine Nullzeitsemantik, d.h. die Transitionen der Zustandsautomaten k¨
onnen
schalten, ohne dass dabei Zeit vergeht. In mechatronischen Systemen, in denen das Schalten ei-
ner Transition mit der Ausf¨
uhrung von Methoden auch auf physikalischer Ebene verbunden sein
kann wie beispielsweise dem Versenden oder empfangen einer Nachricht, ist eine solche Se-
mantik nicht realisierbar. Deshalb werden in der MECHATRONIC UML Real-Time Statecharts
[GB03, BG03, BGS05b, Bur05] eingesetzt, um die Kommunikationsprotokolle und das Kompo-
nentenverhalten zu spezifizieren.
Real-Time Statecharts stellen eine Kombination aus UML-Zustandsautomaten und Timed
Automata [AD90, AD94] dar. Sie sollen an dieser Stelle nur in einem informalen ¨
Uberblick
vorgestellt werden. Eine ausf¨
uhrlichere Beschreibung ist in [Bur05, GB03] enthalten.
Real-Time Statecharts bieten verschiedene M¨
oglichkeiten um Zeit zu spezifizieren. Eine
Transition kann mit einem Intervall beschriftet werden, das angibt, wie lange das Schalten der
Transition mindestens bzw. h¨
ochstens dauert. Zeitinvarianten geben an, wann ein Zustand sp¨
ates-
tens wieder verlassen werden muss. Dazu k¨
onnen mehrere Uhren spezifiziert werden. Diese Uh-
ren werden beim Schalten bestimmter Transitionen zur¨
uckgesetzt.
Eine Transition ist aktiviert, wenn ihre Zeitbedingung (engl. time guard) erf¨
ullt ist, das
ausl¨
osende Ereignis vorliegt und die Bedingung der Transition, bestehend aus einem boolschen
Ausdruck ¨
uber Variablen und Methoden, wahr ist. Ist die aktivierte Transition zwingend (engl. ur-
gent), so muss sie sofort nach ihrer Aktivierung schalten. Nicht-zwingende Transitionen k¨
onnen
das Schalten verz¨
ogern, so lange ihre Zeitbedingung erf¨
ullt ist. Nicht-zwingende Transitionen
werden durch gestrichelte Pfeile dargestellt.
18 KAPITEL 2. GRUNDLAGEN
W¨
ahrend die Ausf¨
uhrungssemantik der Real-Time Statecharts der von Timed Automata ent-
spricht, enthalten sie auch einige Konstrukte von UML-Zustandsautomaten. Dazu geh¨
oren zum
Beispiel sowohl flache als auch tiefe Historie (engl. shallow und deep history) und parallele und
hierarchische Zust¨
ande.
F¨
ur einen Zustand k¨
onnen außerdem entry()-, do()- und exit()- Methoden definiert werden.
Enth¨
alt ein Zustand eine do()-Methode, so wird diese Methode periodisch ausgef¨
uhrt solange
der Zustand aktiviert ist. Wird der Zustand aktiviert und sofort wieder verlassen, so muss sei-
ne do()-Methode jedoch mindestens einmal ausgef¨
uhrt werden. F¨
ur jede der Methoden muss
eine maximal zul¨
assige Ausf¨
uhrungszeit (engl. worst case execution time) spezifiziert werden.
Zus¨
atzlich zu den entry()-, do()- und exit()-Methoden in den Zust¨
anden k¨
onnen die Transitionen
mit Methodenaufrufen belegt sein. In diesem Fall wird, sobald die Transition schaltet, zun¨
achst
die entsprechende Methode ausgef¨
uhrt. Wie in den Zustandsautomaten der UML werden diese
Methoden jedoch nur in den Real-Time Statecharts verwendet, die das Verhalten einer Kom-
ponente beschreiben. Statecharts mit Methodenaufrufen werden in Abschnitt 2.2.2 noch einmal
betrachtet. In UML-Protokoll-Zustandsautomaten und Real-Time Statecharts, die Protokolle mo-
dellieren, werden keine Methoden aufgerufen.
F¨
ur Real-Time Statecharts kann Code generiert werden, der auf echtzeitf¨
ahigen Plattformen
ausgef¨
uhrt werden kann. Eine solche Codegenerierung ist m¨
oglich, da f¨
ur die Real-Time State-
charts durch Abbildung auf Timed Automata eine formale Semantik definiert wurde und f¨
ur jede
Methode, die innerhalb eines Real-Time Statecharts aufgerufen wird, eine maximal zul¨
assige
Ausf¨
uhrungszeit angegeben werden muss.
In Abbildung 2.8 ist ein Beispiel f¨
ur ein Real-Time Statechart gegeben, das das Protokoll
der Rolle rearRole beschreibt. Standardm¨
aßig ist die rearRole im Zustand inactive, d.h. es
findet keine Kommunikation statt. Nichtdeterministisch wird aus diesem Zustand in den Zu-
stand active gewechselt. Die entsprechende Transition ist nicht-zwingend (sie ist gestrichelt),
deshalb kann ihr Schalten beliebig verz¨
ogert werden. raisedEvents an der Transition gibt an,
dass die folgenden Nachrichten erzeugt und versendet werden. Mit empf¨angerName.nachricht
wird spezifiziert, wer der Empf¨
anger ist und welche Nachricht ihm gesandt werden soll. Durch
frontRole.startCommunication wird der frontRole signalisiert, dass eine Kommunikation erfor-
derlich ist. Die Beschriftung der Transition mit {t0}sagt, dass beim Schalten der Transition
neben dem Versenden der Nachricht auch die Uhr t0 auf den Wert 0zur¨
uckgesetzt werden soll.
Das Intervall [0;100]legt fest, dass das Schalten der Transition maximal 100 msek dauern darf.
Nachdem der Schaltvorgang beendet ist, ist rearRole im Zustand active. In diesem Zustand
wartet die rearRole auf eine Best¨
atigung, dass die zuvor versandte Nachricht von der frontRole
empfangen wurde. Mit der Invariante t0 <500 wird spezifiziert, dass die rearRole maximal 500
msek im Zustand active auf eine Empfangsbest¨
atigung warten darf. Trifft die Empfangsbest¨
ati-
gung in dieser Zeit nicht ein, muss die rearRole davon ausgehen, dass die Nachricht m¨
oglicher-
weise verloren gegangen ist und schaltet wieder in den Zustand inactive.
Trifft die Empfangsbest¨
atigung innerhalb der erlaubten Zeit ein, so wechselt die rearRole in
den Zustand noConvoy. Ausgehend von diesem Zustand kann die rearRole der frontRole nicht-
deterministisch den Vorschlag machen, einen Konvoi zu bilden. Im Zustand wait wartet die rear-
Role dann darauf, dass die frontRole der Konvoibildung zustimmt (Nachricht startConvoy) oder
die Konvoibildung ablehnt (Nachricht convoyProposalRejected).
2.2. VERHALTEN 19
Soll ein bestehender Konvoi aufgel¨
ost werden, so schickt die rearRole die Nachricht break-
ConvoyProposal. Die frontRole kann daraufhin den Konvoi durch das Versenden der Nachricht
breakConvoy aufl¨
osen oder die Anfrage der rearRole mit breakConvoyProposalRejected zur¨
uck-
weisen.
!
"
#%$&' )(
+*,-.!/
'
/0132)/54
/326)/54
"
#%$&' )(87#
+9
+*,-./
'
/0132)/54
"
-%$:' !(;/.<6 #
/32/54
"
-%$:' !(;/.<==>
"
#%$&' )(
+*,-./
'?$:@A
1
"
#%$:' !(;/
BC<6 #
D
"
-%$:' !(E7#
9
<
"
#%$&' )(87#
+9
<6$&F@A
G
H
I
JLKL)M
"
#%$:' !(;/
BC<
"
#%$&' )(N/
-C=O>
/32/54
#
A$&'
Abbildung 2.8: Real-Time Statechart, das das Verhalten der Rolle rearRole beschreibt
Wie bei der rearRole wird auch das Verhalten der frontRole und des Konnektors mittels Real-
Time Statecharts spezifiziert.
2.2.2 Komponentenverhalten
Das Verhalten einer Komponente wird, wie das Verhalten einer Rolle, durch ein Real-Time State-
chart beschrieben. Besitzt eine Komponente Schnittstellen und Ports, die durch eine Rolle be-
schrieben werden, so muss das Komponentenverhalten das Verhalten der entsprechenden Rollen
realisieren.
Die Umsetzung des Rollenverhaltens darf jedoch nicht beliebig erfolgen [Gie03, GTB+03].
Zum einen darf die Verfeinerung kein Verhalten hinzuf¨
ugen, das nach außen sichtbar ist und
das nicht in der realisierten Rolle enthalten ist. Das bedeutet, f¨
ur jede Transition im Real-Time
Statechart des Ports, die ein Ereignis an einen anderen Port sendet oder von einem anderen Port
empf¨
angt, existiert eine Transition im Real-Time Statechart der Rolle, die das gleiche Ereignis
sendet oder empf¨
angt. Zum anderen darf bei der Umsetzung kein Verhalten entfernt werden. Das
heißt, Verhalten, das die Rolle enth¨
alt, muss auch in der Komponente enthalten sein. Oder anders
ausgedr¨
uckt, f¨
ur jede Transition im Real-Time Statechart der Rolle muss es eine Transition im
Real-Time Statechart des Ports geben, dass das gleiche Ereignis empf¨
angt oder versendet. Die
Verfeinerung stellt somit eine Simulation (siehe [CGP02] Kapitel 11) dar f¨
ur die zus¨
atzlich gel-
ten muss, dass jedes Verhalten der Rolle auch im Port realisiert ist. Die Verfeinerung stellt im
Allgemeinen jedoch keine Bi-Simulation dar. Daraus resultiert, dass bei der Realisierung einer
Rolle durch eine Komponente haupts¨
achlich Nichtdeterminismus entfernt wird.
20 KAPITEL 2. GRUNDLAGEN
Realisiert eine Komponente das Verhalten mehrerer Rollen oder besitzt sie zus¨
atzliches inter-
nes Verhalten, das nach außen nicht sichtbar ist, so muss eine Synchronisation durch ein internes
Real-Time Statechart erfolgen.
Im Gegensatz zu den Real-Time Statecharts der Rollen, beschreibt das komponenteninterne
Real-Time Statechart reaktives Verhalten, d.h. in den Zust¨
anden d¨
urfen entry()-, do()- und exit()-
Methoden verwendet werden und die Transitionen k¨
onnen mit Methodenaufrufen belegt sein.
Schaltet eine Transition, die mit einem Methodenaufruf belegt ist, so wird der Aufruf als
Seiteneffekt (engl. side effect) ausgef¨
uhrt. Ein solcher Seiteneffekt kann das Versenden von
Nachrichten an eine andere Komponente sein. Andererseits kann als Seiteneffekt eine Metho-
de ausgef¨
uhrt werden, die auf der internen Struktur der Komponente, beispielsweise auf ihrer
Ontologie, arbeitet.
Ein Beispiel f¨
ur eine solche Komponente ist die Shuttle-Komponente. Jedes Shuttle muss so-
wohl als vorderes als auch als hinteres Shuttle agieren k¨
onnen. Deshalb besitzt die Komponente
Shuttle sowohl einen Port front als auch einen Port rear. Die beiden Ports verfeinern das Ver-
halten, das in den Rollen frontRole und rearRole des DistanceCoordination-Musters spezifiziert
ist. Abbildung 2.9 zeigt die drei parallelen Zust¨
ande der Shuttle-Komponente. Der oberste Zu-
stand stellt die Umsetzung der frontRole dar, der untere die Umsetzung der rearRole. Der Zustand
in der Mitte dient zur Synchronisation der beiden Ports, sein Verhalten ist nach außen nicht sicht-
bar.Die Aufgabe des mittleren Zustands besteht darin, die beiden Ports der Komponente zu syn-
chronisieren. Dazu wird eine synchrone Kommunikation verwendet, dargestellt durch Nachrich-
ten, die entweder mit einem ”?“oder einem ”!“beginnen. Zun¨
achst ist das Shuttle im Zustand
noCoordination, d.h. es koordiniert sich mit keinem anderen Shuttle. Periodisch wird gepr¨
uft,
ob die Methode createDC anwendbar ist. Dies ist genau dann der Fall, wenn sich ein anderes
Shuttle in der N¨
ahe befindet, mit dem eine Koordination erforderlich ist. Sobald die Methode
anwendbar ist, schaltet die entsprechende Transition und st¨
oßt eine Koordination zwischen den
beiden Shuttles an, falls sich der mittlere Zustand mit dem Zustand des rear-Ports synchroni-
sieren kann. Die Synchronisation erfolgt ¨
uber das Versenden von !startDC im mittleren Zustand
und das Empfangen von ?startDC im rear-Port. Sind die beiden Shuttles soweit voneinander ent-
fernt, dass eine Koordination nicht mehr notwendig ist, so ist die Methode deleteDC anwendbar
und das Shuttle schaltet wieder in den Zustand noCoordination. Die beiden Methoden werden in
Abschnitt 2.3.2 noch einmal genauer betrachtet.
Die in Abbildung 2.9 dargestellte Spezifikation des Shuttle-Verhaltens l¨
asst nur die Koordi-
nation von jeweils zwei Shuttles zu, d.h. ein Shuttle kann niemals zeitgleich ein vorderes und
ein hinteres Shuttle sein. Somit k¨
onnen die Konvois auch nur aus zwei Shuttles bestehen. Bur-
mester verwendet das Konzept des DistanceCoordination-Musters in [Bur05], um auch Konvois
beliebiger L¨
ange zu bilden.
Das Kommunikationsverhalten der Komponente, das in ihren beiden Ports umgesetzt ist,
entspricht dem Kommunikationsverhalten der beiden Rollen rearRole und frontRole. Allerdings
wurde der Nichtdeterminismus der beiden Rollen durch die Kommunikation mit der internen
Synchronisation aufgel¨
ost. Beispielsweise kann die rearRole nichtdeterministisch aus dem Zu-
stand inactive in den Zustand active wechseln. Im rear-Port ist ein Wechsel nur dann m¨
oglich,
2.2. VERHALTEN 21
! "#%$'&
( )+* (!,.- /)0".
!12
!12 43
( 5 )6 787:9!0;
( 5 )6.- /)0". 5<#
0; #%$'&
/0=787:9!0;
>
@?A
>
7:7:9!0;(;
! "#%$'&
( 5 )6 #B
C D?A
CEF,
.- /0)G!
>
;HEF,
CI6GEF,
J* .,
0; #%$'&
C*.,=
C=787:9!0;
! "#%$K&
( 5 )+* (!,=.- /0)G! 5<#
>
*(!,
CILEF,
#B
#B
#;.M
=
N&O =.PQ" 9!+R . "(S12ATVU
W&O".PQ 9!XR ! S1YZTVU
.M
7[#L)M
!12 M.M
7[#L (
(
?A\R]S
>
=7
#! )?A2R^S
>
/.?A
.PQ 9!XR^S
>
ILEF,
C*(!,=
O".PQ 9!+R_ 9(S
>
ILGE`,
3NacbLdeH30d)df
>
*(!,
3Wgh30d0d
>
)EF,
CEF,
.PQ 9!XR^S
>
*!90B #=
b6de Ud0df
!
A.Pi 9!Bjk
C/0=787:9!0;
C D?A
C=
)l.Pi 9!Bjk
>
.mn)"E`,
C@?A
DU gU(o d
>
=7:789!0 (;
>
D?A
DU acbLde Uo df
p
DU)q
C787:9!0;
p
3q
C;H=E`,
7r#L
1\0
dWs od0d
.- /00"!
! "#%$'&
(
! "#%$K&
)6 /0=7:789!0 (;
! "#%$K&
)+* (!,=.- /0)G!
#L!;
p
dq
bLde Ud0df
>
D?A
C/.?A
B
.- /00"! ^<#
>
=
>
/0787:9!0;
C 7
7:7:9!0;(;
0; #%$'&
C*!90 #
J* .,= 5<#
>
EF,
C.mt)"EF,
>
E`,
)6 =
)+* (!,
>
uwv
9H
Abbildung 2.9: Verhalten der Shuttle-Komponente
22 KAPITEL 2. GRUNDLAGEN
wenn die Synchronisation die Nachricht startDC sendet. Da in der rearRole die Transition nicht
zwingend war, konnte das Schalten der Transition beliebig verz¨
ogert werden. Erh¨
alt der rear-Port
jedoch die Nachricht startDC so muss sie sofort schalten, da die Transition nun zwingend ist. In
den Rollen ist genau spezifiziert, wann eine bestimmte Nachricht gesendet werden muss und wie
lange dieses Senden maximal dauern darf. Die interne Synchronisation der Komponente muss
diese Zeiten respektieren.
Hybride Komponenten
Mit den bisher vorgestellten Verhaltensbeschreibungen ist es m¨
oglich, die Kommunikation zwi-
schen mehreren Komponenten zu modellieren und beispielsweise die Ontologie zu ver¨
andern.
Es ist jedoch noch nicht m¨
oglich, das bei der Kommunikation vereinbarte Verhalten auf physi-
kalischer Ebene umzusetzen. Deshalb werden in [BGO04, BGT05, Bur05] hybride Komponen-
ten eingef¨
uhrt. Hybride Komponenten werden ben¨
otigt, um die Controller (unterste Ebene der
OCM-Architektur, siehe Abbildung 2.1) zu steuern, die die entsprechenden Signale dann an die
Aktoren des Systems weiterleiten und damit auch das bei der Koordination vereinbarte Verhalten
auf physikalischer Ebene umzusetzen.
Ein Beispiel f¨
ur eine hybride Komponente ist die Komponente Control in Abbildung 2.2. Die
Ports der Komponente sind kontinuierlich, dies wird durch das ausgef¨
ullte Dreieck innerhalb des
Ports dargestellt.
Hybride Komponenten werden an dieser Stelle nur der Vollst¨
andigkeit halber genannt. Im
weiteren Verlauf der Arbeit werden jedoch nur diskrete Komponenten, wie zuvor eingef¨
uhrt,
betrachtet. Die in Kapitel 3 und ff. vorgestellte Verifikationstechnik kann jedoch auch f¨
ur hybride
Komponenten verwendet werden.
Story Diagramme
Das reaktive Verhalten der Komponenten resultiert aus den entry()-, do()- und exit()-Methoden
der Zust¨
ande sowie den Methoden, die als Seiteneffekte beim Schalten einer Transition aus-
gef¨
uhrt werden.
Solche Methoden werden in der UML durch UML-Aktivit¨
atendiagramme beschrieben. In
[Z¨
un01, FNTZ98] wurden die UML-Aktivit¨
atendiagramme zu Story Diagrammen erweitert. Sie
stellen den Kontrollfluss einer Methode graphisch dar. ¨
Uber Parameter k¨
onnen den Story Dia-
grammen Attributwerte und Objektreferenzen ¨
ubergeben werden.
Die Basisstruktur von Story Diagrammen stellen die so genannten Aktivit¨
aten dar. Aktivit¨
aten
k¨
onnen durch Transitionen verbunden werden, die die Ausf¨
uhrungsreihenfolge festlegen. Die
Ausf¨
uhrung beginnt bei einer eindeutigen initialen Aktivit¨
at. Verlassen mehrere Transitionen ei-
ne Aktivit¨
at, so m¨
ussen diese mit sich gegenseitig ausschließenden Bedingungen belegt sein. Die
Ausf¨
uhrung terminiert, wenn die Stopaktivit¨
at erreicht wurde. Die Aktivit¨
aten k¨
onnen entweder
durch Codefragmente oder durch Story Patterns beschrieben werden. Story Patterns stellen ei-
ne modellbasierte Notation dar, die auf Graphtransformationen basiert. Aus einem Story Pattern
kann Code generiert werden. In dieser Arbeit werden Story Diagramme verwendet, die aus genau
einer Aktivit¨
at bestehen und keine Attribute besitzen.
2.2. VERHALTEN 23
Ein UML-Objektdiagramm beschreibt eine bestimmt Instanzsituation, d.h. welche Objekte
zu einem bestimmten Zeitpunkt existieren und durch welche Links sie verbunden sind. Mittels
Story Patterns kann beschrieben werden, wann eine solche Instanzsituation ver¨
andert werden
soll. In ihm wird definiert, welche Objekte und Links (im Folgenden kurz Elemente genannt) bei
einer ¨
Anderung neu erzeugt oder gel¨
oscht werden sollen. Zudem kann mittels Story Patterns der
Wert von Attributen ge¨
andert werden. Elemente, die durch die Anwendung eines Story Patterns
gel¨
oscht werden, sind mit destroy gekennzeichnet und in rot dargestellt. Elemente, die durch
die Anwendung eines Story Patterns erzeugt werden, sind durch create gekennzeichnet und
in gr¨
un dargestellt. Elemente, die nicht gekennzeichnet sind, bleiben bei der Anwendung des
Story Patterns unver¨
andert erhalten.
Abbildung 2.10 zeigt ein einfaches Beispiel f¨
ur ein Story Pattern. Dieses Story Pattern, move-
Simple, beschreibt die Bewegung des Shuttles von einem Track (rt1) auf den n¨
achsten (rt2). F¨
ur
diese Vorw¨
artsbewegung des Shuttles wird die locatedOn-Kante zwischen dem Shuttle-Objekt
und dem Track-Objekt rt1 entfernt (diese Kante ist mit destroy beschriftet) und eine neue
locatedOn-Kante zwischen dem Shuttle und rt2 erzeugt (diese Kante ist mit create beschrif-
tet).
Abbildung 2.10: Story Pattern moveSimple, das die Bewegung eines Shuttles von einem Track
auf den n¨
achsten beschreibt
Ein Story Pattern kann auf eine Instanzsituation (beschrieben durch ein UML-
Objektdiagramm) angewendet werden, wenn alle ungekennzeichneten und mit destroy ge-
kennzeichneten Elemente des Story Patterns auf Elemente des Objektdiagramms abgebildet wer-
den k¨
onnen. Bei der Anwendung werden dann alle mit destroy gekennzeichneten Elemente
gel¨
oscht und die mit create beschrifteten Elemente erzeugt und zum Objektdiagramm hin-
zugef¨
ugt.
Abbildung 2.11 zeigt ein Beispiel f¨
ur ein Objektdiagramm. Das Diagramm stellt die On-
tologie eines Shuttles dar. Sie besteht aus f¨
unf Track-Objekten, die im Kreis angeordnet sind
sowie zwei Shuttle-Objekten, this und as2, wobei sich this auf Track at1 befindet und as2 auf
Track at4. Das mit this beschriftete Shuttle entspricht dem Shuttle, dessen Ontologie das Ob-
jektdiagramm darstellt. Das Story Pattern aus Abbildung 2.10 kann auf dieses Objektdiagramm
angewendet werden. Dazu wird das Objekt this :Shuttle aus dem Story Pattern mit dem Objekt
this :Shuttle aus dem Objektdiagramm gleichgesetzt. Die Track-Objekte rt1 und rt2 werden auf
die Track-Objekte at1 und at2 abgebildet und die locatedOn-Kante zwischen this und rt1 wird
auf die locatedOn-Kante zwischen this und at1 abgebildet. Die Abbildung des Story Patterns auf
das Objektdiagramm ist in Abbildung 2.11 gr¨
un hinterlegt. Abbildung 2.12 zeigt das Objektdia-
gramm nachdem das Story Pattern angewendet wurde.
24 KAPITEL 2. GRUNDLAGEN
Abbildung 2.11: Beispiel f¨
ur ein Objektdiagramm. Die Abbildung des Story Patterns aus Abbil-
dung 2.10 auf dieses Objektdiagramm ist gr¨
un hinterlegt
Abbildung 2.12: Objektdiagramm aus Abbildung 2.11 nachdem das Story Pattern moveSimple
darauf angewendet wurde
Mit den bisher vorgestellten Konstrukten l¨
asst sich definieren, wann ein Story Pattern ange-
wendet werden kann. Mittels negativer Anwendungsbedingungen kann die Anwendung eines
Story Patterns eingeschr¨
ankt werden.
Im Shuttle-Beispiel sind die Tracks so kurz, dass nur jeweils ein Shuttle darauf passt. Befin-
den sich zwei Shuttles auf einem Track, so kollidieren sie. Fahren zwei Shuttles auf aufeinan-
der folgenden Tracks, so bedeutet dies, dass die Shuttles so dicht hintereinander herfahren, dass
das hintere Shuttle nicht gen¨
ugend Zeit zum Reagieren hat, wenn das vordere Shuttle pl¨
otzlich
bremst. Um einen gen¨
ugend großen Sicherheitsabstand zu garantieren, der eine solche Kollisi-
on vermeidet, wird deshalb verlangt, dass sich zwischen zwei Shuttles ein freier Track befindet.
Es muss deshalb eine Bedingung aufgestellt werden, die verhindert, dass die moveSimple-Regel
erneut auf das Shuttle this aus Abbildung 2.12 angewendet wird. Andernfalls w¨
urde das Shuttle
this auf den Track at3 fahren. Da sich Shuttle as2 auf dem Track at4 befindet, w¨
are zwischen den
beiden Shuttles jedoch kein Sicherheitsabstand mehr.
2.3. MODELLKOMPOSITION 25
Um eine negative Anwendungsbedingungen zu beschreiben, bieten Story Patterns negative
Objekte und Links. Ein Story Pattern mit negativen Elementen darf nur dann auf ein Objektdia-
gramm angewendet werden, wenn alle positiven Elemente auf Elemente des Objektdiagramms
abgebildet werden k¨
onnen, die negativen jedoch nicht. Sobald eines der negativen Elemente auf
das Objektdiagramm abgebildet werden kann, ist die Anwendung des entsprechenden Story Pat-
terns nicht mehr erlaubt.
In Abbildung 2.13 ist ein Beispiel f¨
ur ein Story Pattern mit negativer Anwendungsbedingung
gegeben. Bei diesem Story Pattern handelt es sich um eine Erweiterung des Story Patterns aus
Abbildung 2.10. Die Erweiterung fordert, dass das Shuttle nur dann auf den n¨
achsten Track wei-
tergesetzt werden darf, wenn sich weder auf dem n¨
achsten noch auf dem ¨
ubern¨
achsten Track ein
anderes Shuttle befindet (dargestellt durch die durchgestrichenen Shuttle-Objekte). Dieses Story
Pattern kann nun nicht mehr auf das Shuttle this aus dem Objektdiagramm in Abbildung 2.12
angewendet werden, da das negative Shuttle-Objekt rs2 aus dem Story Pattern auf das Shuttle-
Objekt as2 aus dem Objektdiagramm abgebildet werden kann.
Abbildung 2.13: Story Pattern moveSimpleNAC, das das Story Pattern moveSimple um eine
negative Anwendungsbedingung erweitert
Im Folgenden werden Story Patterns aber nicht nur dazu eingesetzt, um Methoden zu spezifi-
zieren. Aufgrund ihrer Ausdrucksst¨
arke und ihrer leicht verst¨
andlichen Darstellungsweise eignen
sie sich auch dazu, kritische (Instanz-)Situationen und Unf¨
alle zu beschreiben. Dies wird in Ab-
schnitt 3.2.2 dargestellt.
2.3 Modellkomposition
Bisher wurde die Modellierung von Komponenten sowie deren Interaktion ¨
uber Koordinations-
muster betrachtet. Sowohl Komponenten als auch Koordinationsmuster stellen einzelne Teile des
gesamten Modells dar. In diesem Abschnitt soll nun betrachtet werden, wie aus den Teilmodellen
das gesamte Modell zusammengesetzt wird.
2.3.1 Kommunikation und Komponenten
In Abschnitt 2.1.2 und 2.2.2 wurde die Modellierung von Komponenten und ihrem Verhalten
betrachtet. Koordinationsmuster wurden in 2.2.1 eingef¨
uhrt, um das Interaktionsverhalten der
Komponenten zu beschreiben. Nun soll betrachtet werden, wie aus diesen Modellteilen ein ge-
samtes Modell gebildet wird.
26 KAPITEL 2. GRUNDLAGEN
Das Gesamtmodell besteht aus einer Menge von Komponenten- und Musterinstanzen
[GTB+03, GST+03]. Die Interaktion von Komponenten erfolgt dabei immer ¨
uber Instanzen der
Koordinationsmuster. Das bedeutet, dass die Ports einer Komponente Implementierungen von
Musterrollen darstellen. Soll in einem Komponentendiagramm dargestellt werden, dass der Port
einer Komponente eine Musterrolle verfeinert, so wird in das Diagramm eine Komponentenin-
stanz sowie eine Instanz des Koordinationsmusters eingef¨
ugt. Das Quadrat am Rand der Kom-
ponente stellt dann sowohl ihren Port als auch die verfeinerte Rolle des Koordinationsmusters
dar.
Eine solche Modellierung, bei der das Gesamtmodell aus einzelnen Teilen zusammengef¨
ugt
wird, wird als kompositionale Modellierung bezeichnet. Die hier vorgestellte kompositionale Mo-
dellierung erlaubt zum einen die verschiedenen Komponenten- und Koordinationsmustertypen
wieder zu verwenden. Zum anderen erlaubt sie aber auch eine formale Verifikation des Modells
(siehe Abschnitt 2.4).
In Abbildung 2.14 ist exemplarisch ein Modell, bestehend aus zwei Shuttle-Komponenten
und einer Komponente vom Typ BaseStation, dargestellt. Die Kommunikation der beiden Shutt-
les untereinander erfolgt ¨
uber eine Instanz des DistanceCoordination-Koordinationsmusters. Die
Kommunikation der beiden Shuttles mit der BaseStation erfolgt ¨
uber die beiden Instanzen des
Publication-Koordinationsmusters.
!
"#
$%!
&
' (%)
$+*
',.- '/$(
'0"1 /32 4 5
+
'67 /82 4
!
9:' 2%
' 2
*:' ; <
=%
*:' ; <
Abbildung 2.14: Modell bestehend aus je drei Komponenten und Koordinationsmustern
Wird das Modell auf diese Weise aus Komponenten und Koordinationsmustern zusammen-
gef¨
ugt, so muss f¨
ur jedes Paar von Komponenten, das sich zur Laufzeit eventuell koordinieren
muss, das entsprechende Koordinationsmuster instanziert sein. Da die Ausf¨
uhrung eines Kom-
munikationsprotokolls bedeutet, dass Nachrichten ausgetauscht werden, kann eine Komponente
nur mit einer begrenzten Anzahl anderer Komponenten kommunizieren. Hinzu kommt, dass me-
chatronische Systeme sehr dynamisch sind und bei der Instanzierung einer Komponente noch
nicht bekannt ist, mit welchen anderen Komponenten sie sich zur Laufzeit koordinieren muss.
Deshalb wird im n¨
achsten Abschnitt das Instanzieren und das L¨
oschen von Koordinationsmus-
tern betrachtet.
2.3. MODELLKOMPOSITION 27
2.3.2 Kulturen und Communities
Damit die Interaktion der Komponenten eines mechatronischen Systems sicher ist, muss sie
durch Instanzen von Koordinationsmustern realisiert werden. Mechatronische Systeme sind je-
doch dynamisch, d.h. bei der Instanzierung einer Komponente ist nicht bekannt, mit welchen
andere Komponenten sie jemals zur Laufzeit interagieren muss. Außerdem stehen in einem me-
chatronischen System zur Ausf¨
uhrung der Software nur begrenzte Ressourcen (CPU, Speicher,
etc. ) zur Verf¨
ugung. Dadurch kann eine Komponente nur mit einer begrenzten Anzahl anderer
Komponenten kommunizieren. F¨
ur jedes Paar von Komponenten alle m¨
oglichen Koordinations-
muster zu instanzieren, ist somit nicht m¨
oglich. Stattdessen d¨
urfen nur solche Koordinations-
muster instanziert werden, die zur Laufzeit wirklich ben¨
otigt werden.
Im Folgenden wird ein Ansatz vorgestellt, der es erm¨
oglicht, festzustellen, welche Mus-
terinstanzen zu einem bestimmten Zeitpunkt ben¨
otigt werden und die Instanzierung vornimmt
bzw. nicht mehr ben¨
otigte Instanzen l¨
oscht.
Mechatronische Systeme sind im Allgemeinen sehr komplex, sodass ihre Modellierung auf-
wendig ist. Zudem f¨
uhrt die Komplexit¨
at dazu, dass eine automatische formale Verifikation er-
schwert oder verhindert wird. Deshalb werden an dieser Stelle soziale Metaphern eingef¨
uhrt,
die eine zus¨
atzlich Strukturierung des Systems erm¨
oglichen. Durch diese zus¨
atzliche Strukturie-
rung wird zum einen die Modellierung des Systems vereinfacht, zum anderen wird dadurch aber
auch die Verifikation der Instanzierung und des L¨
oschens von Musterinstanzen erm¨
oglicht (siehe
Abschnitt 2.4.3).
Die Strukturierung erfolgt ¨
uber eine Hierarchie von Kulturen [GBK+03, KG04, KG05]. Jede
dieser Kulturen garantiert die Einhaltung einer Menge von Systemeigenschaften.
Eine Kultur besteht aus
•einer Menge von Subkulturen,
•einer Menge von Rollen,
•einer Menge von Regeln:
–Instanzierungsregeln,
–Verhaltensregeln,
–Absichtserkl¨
arungen,
•und Systemeigenschaften.
Die oben eingef¨
uhrten Komponenten werden in diesem Kontext als Agenten aufgefasst. Eine
Menge von Agenten, die die Regeln einer Kultur realisieren, werden in einer Community zusam-
mengefasst. Eine solche Community wird dynamisch durch die Instanzierungsregeln der Kultur
gebildet. Das physikalische und soziale Verhalten eines Agenten wird durch eine Menge von
Verhaltensregeln definiert. Mit einer Absichtserkl¨
arung teilt der Agent mit, wie er sich in naher
Zukunft verhalten wird.
Die Systemeigenschaften d¨
urfen durch die Anwendung der Regeln nicht verletzt werden.
Zu diesen Systemeigenschaften geh¨
ort zum Beispiel, dass die Agenten sich nicht anders verhal-
ten d¨
urfen als in einer Absichtserkl¨
arung versprochen. Andere Eigenschaften beschreiben, dass
keine Unf¨
alle und kritische Situationen eintreten d¨
urfen. Solche Eigenschaften werden z.B. als
28 KAPITEL 2. GRUNDLAGEN
verbotene Story Patterns beschrieben. Das heißt, wenn das verbotene Story Pattern auf ein Ob-
jektdiagramm angewendet werden kann, ist ein Unfall oder eine kritische Situation eingetreten.
Nach Storey [Sto96] ist eine kritische Situation (engl. hazard) definiert als ”eine Situation,
in der Personen, die Umwelt oder Material m¨
oglicherweise oder tats¨
achlich gef¨
ahrdet sind“.
Demgegen¨
uber ist ein Unfall (engl. accident) ”ein nicht beabsichtigtes Ereignis oder eine Folge
von nicht beabsichtigten Ereignissen, die sowohl den Tod oder Verletzungen von Personen sowie
Umwelt- oder Materialsch¨
aden verursachen“.
Koordinationsmuster stellen eine eingeschr¨
ankte Form der Kulturen dar. Sie bestehen aus ei-
ner Menge von Rollen und Regeln, die in Form der Kommunikationsprotokolle festgelegt sind.
Sie besitzen jedoch keine Subkulturen. Die Protokolle stellen dabei eine Absichtserkl¨
arung dar.
Die in den Koordinationsmustern spezifizierten Rolleninvarianten und Musterconstraints ent-
sprechen den in der Kultur definierten Systemeigenschaften. Wird ein Koordinationsmuster in-
stanziert, so entspricht dies der Bildung einer Community, wobei den beteiligten Agenten die
Rollen des Musters zugewiesen werden.
Die Idee besteht nun darin, mit L¨
osungen f¨
ur einzelne kleine Probleme zu beginnen und dann
diese Teill¨
osungen zu Gesamtl¨
osungen zusammenzufassen. Koordinationsmuster stellen solche
Teill¨
osungen dar. In einer solchen Teill¨
osung ist eine Komponente ein Agent, dem bestimmte
Rollen (die Musterrollen) zugewiesen werden. In den oben eingef¨
uhrten Real-Time Statecharts
ist bereits vorgesehen, dass ein Koordinationsmuster zur Laufzeit instanziert wird (modelliert
durch die Zust¨
ande active und inactive). Somit ist festgelegt, dass die Komponente eine bestimm-
te Rolle ¨
ubernehmen kann.
Ein Beispiel f¨
ur eine Kulturhierarchie ist in Abbildung 2.15 dargestellt. Die oberste Kultur
ist die Movement-Kultur, die die ControlledMovement-Kultur als Subkultur besitzt. Die Control-
ledMovement-Kultur hat zwei Subkulturen, das Publication-Koordinationsmuster und die Coor-
dinatedMovement-Kultur. Diese hat wiederum das DistanceCoordination-Koordinationsmuster
als Subkultur.
Um die Kulturen der Hierarchie modellieren zu k¨
onnen, muss zun¨
achst die in Abschnitt 2.1.3
eingef¨
uhrt Ontologie um Klassen und Assoziationen erweitert werden, die die konzeptionellen
Elemente darstellen. Als erstes wird dazu die next Assoziation zwischen der Klasse Shuttle und
der Klasse Track eingef¨
ugt. Diese Assoziation stellt eine Absichtserkl¨
arung dar. Mit ihrer Hilfe
kann ein Shuttle den anderen Shuttles mitteilen, auf welche Tracks es als n¨
achstes fahren wird.
Die Ontologie wird um ein Koordinationsmuster Publication erweitert. Mittels dieses Mus-
ters meldet sich ein Shuttle bei der BaseStation an, die den Track ¨
uberwacht, auf dem sich das
Shuttle befindet. Ist ein Shuttle bei einer BaseStation angemeldet, so sendet es in regelm¨
aßigen
Abst¨
anden seine Positionsdaten an die BaseStation. Diese sendet die Daten wiederum an alle bei
ihr gemeldeten Shuttles. Auf diese Weise erfahren die Shuttles, welche anderen Shuttles sich in
ihrer N¨
ahe befinden. Erh¨
alt die BaseStation die Positionsdaten eines Shuttles nicht, so warnt sie
die anderen Shuttles, dass dieses Shuttle m¨
oglicherweise defekt ist.
Durch das Publication-Koordinationsmuster erf¨
ahrt ein Shuttle, welche anderen Shuttles sich
in seiner N¨
ahe befinden. Dies erm¨
oglicht eine Koordination zwischen den Shuttles. Diese Koor-
dination wird durch das DistanceCoordination-Muster spezifiziert. Es stellt die Umsetzung der
Subkultur DistanceCoordination dar. Die Rollen dieser Subkultur werden als Assoziationen in
die Ontologie eingef¨
ugt. Die erweiterte Ontologie ist in Abbildung 2.16 dargestellt.
2.3. MODELLKOMPOSITION 29
!"$#
%'&
&
!
%
)(*
&
+
,-+./$#
%10
/,234
%
+,!
3,-+./$#
%
+ ,576
%10
+ /,576
%
8,!576:9$;' ,<
%'&
!=576
>2+.<+ ,/$#
%
&@?
0
"46:4"
AB <@9C D++FEHGIJK- #
%
&@?
0
L$6: +9$;' ,+<
57,-/+6M4
0
"+
6:$
0
"+,
0
(*!=
&
AB N+<O9P D++FEHGBJ,K" #
%
/"3D
(*!=
&
%
!Q(*
&
!
AB N+<O9P D++FEHGBJ,K" #
%
R23
6MD
0
(*!=
&
>2+.<+ ,/$#
%'&
=9$;' ,+<
%
??
<+9-;S ,<
>2<+- ,/$#
%'&
=!TUDV+
Abbildung 2.15: Beispiel f¨
ur eine Kulturhierarchie
Abbildung 2.16: Ontologie erweitert um konzeptionelle Elemente
30 KAPITEL 2. GRUNDLAGEN
Ein Beispiel f¨
ur eine Verhaltensregel der Movement-Kultur ist die Regel moveNext. Die
Implementierung dieser Regel ist als Story Pattern in Abbildung 2.17 gegeben. Die Regel be-
schreibt, dass das Shuttle zwei next-Links besitzt. Ein next-Link zeigt auf den Track, auf den das
Shuttle als n¨
achstes fahren m¨
ochte, und der zweite auf den ¨
ubern¨
achsten Track. Befinden sich
auf dem n¨
achsten Track und dem ¨
ubern¨
achsten Track keine anderen Shuttles, so darf das Shuttle
auf den n¨
achsten Track weiterfahren. Dazu wird der locatedOn-Link zwischen dem Shuttle und
dem Track rt1 gel¨
oscht und ein neuer zum Track rt2 erzeugt. Außerdem wird der next-Link zu
rt2:Track entfernt und ein neuer zum Track rt4 erzeugt. Durch die Anwendung dieser Regel wird
das Shuttle auf den n¨
achsten Track gesetzt und es wird gleichzeitig festgelegt, auf welchen Track
das Shuttle als ¨
ubern¨
achstes fahren m¨
ochte.
Abbildung 2.17: Beispiel f¨
ur die Implementierung der Verhaltensregel moveNext
Eine Eigenschaft, die durch die Absichtserkl¨
arungen, Instanzierungs- und Verhaltensregeln
eingehalten werden muss, ist, dass sich niemals zwei Shuttles auf dem gleichen Track befinden
d¨
urfen. Andernfalls sind die beiden Shuttles kollidiert. Diese Eigenschaft wird durch das verbo-
tene Story Pattern collision in Abbildung in 2.18 modelliert. In dieser Arbeit wird der Begriff ver-
botene Story Patterns f¨
ur solche Story Patterns verwendet, die kritische Situationen oder Unf¨
alle
beschreiben. Der Begriff Story Pattern wird nur f¨
ur die Story Pattern verwendet, die Verhaltens-
oder Instanzierungsregeln beschreiben.
Abbildung 2.18: Verbotenes Story Pattern collision
In der DistanceCoordination-Kultur wird die eigentliche Abstandshaltung der Shuttles defi-
niert. Sie stellt eine Subkultur der ControlledMovement-Kultur dar, die wiederum eine Subkultur
der Movement-Kultur ist. Das DistanceCoordination-Muster implementiert diese Kultur.
Die Instanzierungsregeln der DistanceCoordination-Kultur stellen die beiden Regeln crea-
teDC und deleteDC dar. Dabei instanziert createDC das DistanceCoordination-Muster und de-
leteDC l¨
oscht eine Instanz dieses Musters. Die Instanzierung des Muster bedeutet in diesem
2.3. MODELLKOMPOSITION 31
Fall, dass eine Funkverbindung (beschrieben durch den Konnektor des Koordinationsmusters)
aufgebaut und die Kommunikation zwischen den beiden Komponenten gestartet wird. Ebenso
bedeutet das L¨
oschen des Koordinationsmusters, dass die Funkverbindung beendet wird. Beide
Regeln werden in der Verhaltensbeschreibung der Shuttle-Komponente aufgerufen.
Die Implementierung der Regel createDC ist in Abbildung 2.19 gegeben. Sie wird von dem
Shuttle ausgef¨
uhrt, das mit this beschriftet ist. Die Regel beschreibt, dass das Koordinationsmus-
ter erzeugt werden muss, wenn auf dem Track auf den das this:Shuttle als ¨
ubern¨
achstes fahren
m¨
ochte, bereits ein anderes Shuttle ist. Das Koordinationsmuster darf nur dann erzeugt wer-
den, wenn das mit this gekennzeichnete Shuttle noch nicht in einem Koordinationsmuster die
rearRole ausf¨
uhrt und das mit rs2 beschriftete Shuttle noch nicht die frontRole ausf¨
uhrt. Dies
verhindert zum einen, dass das Koordinationsmuster mehrfach zwischen den beiden Shuttles in-
stanziert wird. Zum anderen wird dadurch verhindert, dass das Koordinationsmuster instanziert
wird, obwohl sich zwischen den beiden Shuttles noch ein weiteres Shuttle befindet.
Abbildung 2.19: Instanzierungsregel createDC
Ein Beispiel f¨
ur eine Verhaltensregel dieser Kultur ist die Regel moveDC, die eine koor-
dinierte Fahrt des Shuttles beschreibt. Koordinieren sich zwei Shuttles¨
uber eine Instanz des
DistanceCoordination-Musters, so darf das hintere Shuttle weiterfahren, wenn zwischen den bei-
den Shuttles ein Track frei ist. Dadurch erm¨
oglicht das DistanceCoordination-Muster, dass zwei
Shuttles dichter hintereinander herfahren k¨
onnen als ohne das Koordinationsmuster. Diese Regel
hat eine h¨
ohere Priorit¨
at als die Regeln der Movement-Kultur. Das bedeutet, wenn die Regel mo-
veDC angewendet werden kann und zeitgleich auch eine Regel der Movement-Kultur, z.B. die
Regel moveNext, dann wird immer die Regel mit der h¨
oheren Priorit¨
at angewendet.
Generell gilt f¨
ur die Vergabe der Priorit¨
aten: Je weiter unten in der Kulturhierarchie eine Ver-
haltensregel eingef¨
uhrt wird, desto h¨
oher ist ihre Priorit¨
at. Bei den Instanzierungsregeln verh¨
alt
es sich genau umgekehrt, je weiter oben in der Hierarchie eine Instanzierungsregel steht, de-
sto h¨
oher ist ihre Priorit¨
at und die Instanzierungsregeln haben eine h¨
ohere Priorit¨
at als die Ver-
haltensregeln. Die Instanzierungsregeln haben eine h¨
ohere Priorit¨
at als die Verhaltensregeln, da
ein Agent erst bei der Instanzierung einer Community seine Rolle und die dazu geh¨
origen Ver-
haltensregeln zugewiesen bekommt. Die Instanzierungsregeln einer Kultur haben eine h¨
ohere
Priorit¨
at als die Instanzierungsregeln ihrer Subkulturen, da der Agent erst dann eine Subkultur
instanzieren kann, wenn er Teil einer Community der Kultur ist.
32 KAPITEL 2. GRUNDLAGEN
Abbildung 2.20: Verhaltensregel moveDC
Die ControlledMovement-Kultur muss zum einen die Eigenschaften der ¨
ubergeordneten Mo-
vement-Kultur erf¨
ullen. Zum anderen sind in der Kultur zus¨
atzliche Eigenschaften spezifiziert,
die die Regeln der Kultur erf¨
ullen m¨
ussen. Eine dieser Eigenschaften beschreibt eine kritische
Situation, die niemals eintreten darf. Diese kritische Situation besteht darin, dass sich zwei Shutt-
les auf benachbarten Tracks befinden, jedoch das DistanceCoordination-Muster nicht instanziert
haben. In diesem Fall droht eine Kollision der Shuttles, denn obwohl die beiden Shuttles mit
geringem Anstand hintereinander fahren, kommunizieren sie nicht. Das bedeutet, wenn das vor-
dere Shuttle bremst, hat das hintere unter Umst¨
anden nicht mehr genug Zeit zum Reagieren und
die beiden Shuttles w¨
urden kollidieren. Diese kritische Situation wird durch das verbotene Story
Pattern impendingCollision in Abbildung 2.21 beschrieben.
Abbildung 2.21: Verbotenes Story Pattern impendingCollision
In diesem Abschnitt wurde vorgestellt, wie durch die Verwendung sozialer Metaphern ein
komplexes mechatronisches System strukturiert werden kann. Die Verwendung von hierarchi-
schen Kulturen erlaubt es, L¨
osungen f¨
ur einzelne Probleme zu entwickeln und diese dann zu ei-
ner Gesamtl¨
osung zusammenzusetzen. Die in Abschnitt 2.2.1 eingef¨
uhrten Koordinationsmuster
stellen eine besondere Form dieser Kulturen dar. Mit Hilfe der Instanzierungsregeln der jewei-
ligen Kultur wird beschrieben, wann ein Koordinationsmuster instanziert wird bzw. wann eine
Musterinstanz gel¨
oscht wird.
2.4. VERIFIKATION 33
Zus¨
atzlich zu den Instanzierungsregeln wurden Verhaltensregeln eingef¨
uhrt, die sowohl das
physikalische als auch das soziale Verhalten der Agenten umsetzen. Wobei die Agenten den in
Abschnitt 2.1.2 eingef¨
uhrten Komponenten entsprechen.
Neben den Absichtserkl¨
arungen, Instanzierungs- und Verhaltensregeln enthalten die Kulturen
auch eine Menge von Eigenschaften, die entweder in Form von TCTL-Formeln in den Koordi-
nationsmustern angegeben oder in Form von verbotenen Story Patterns definiert werden. Diese
Eigenschaften d¨
urfen durch die Instanzierungs- und Verhaltensregeln sowie durch die Absichts-
erkl¨
arungen nicht verletzt werden. Im folgenden Abschnitt wird deshalb gezeigt, wie mittels
kompositionaler formaler Verifikation nachgewiesen werden kann, dass die Eigenschaften ein-
gehalten werden.
2.4 Verifikation
In Abschnitt 2.2.1 wurde gezeigt, wie die Echtzeitkommunikation in mechatronischen Systemen
mittels Koordinationsmustern modelliert wird. Die in Abschnitt 2.1.2 eingef¨
uhrten Komponenten
verfeinern die Rollen der Koordinationsmuster, um die in den Mustern spezifizierten Kommu-
nikationsprotokolle zu realisieren. In Abschnitt 2.3.2 wurden Kulturen eingef¨
uhrt, um Systeme
bestehend aus Komponenten und Koordinationsmustern zu strukturieren und die Systemkompo-
sition aus einzelnen Teilsystemen zu erm¨
oglichen.
Die Trennung der Kommunikation vom Komponentenverhalten sowie die Strukturierung des
Gesamtsystems durch die Verwendung von Kulturen erm¨
oglichen eine kompositionale Verifika-
tion. Zur Verifikation werden dann zwei verschiedene Techniken eingesetzt. Zum einen werden
die Real-Time Statecharts der Komponenten und Koordinationsmuster durch Model Checking
verifiziert [GTB+03, GST+03]. Zum anderen werden die Story Patterns, die in den Kulturen de-
finiert werden und die in den komponenteninternen Real-Time Statecharts aufgerufen werden,
durch einen Induktionsbeweis verifiziert (siehe Kapitel 3).
2.4.1 Verifikation der Kommunikation
Ein Koordinationsmuster ist korrekt und damit die in ihm spezifizierte Kommunikation sicher,
wenn das Muster die als temporal logische Formeln vorliegenden Musterconstraints erf¨
ullt.
Die ¨
Uberpr¨
ufung, ob das Koordinationsmuster die Eigenschaften erf¨
ullt, erfolgt durch Model
Checking. Da die Semantik von Real-Time Statecharts durch Abbildung auf Timed Automata
gegeben ist, ist keine zus¨
atzlich Formalisierung des Modells notwendig.
Ein Koordinationsmuster kann durch einen Model Checker, wie zum Beispiel UPPAAL
[LPY97] oder RAVEN [Ruf01] gepr¨
uft werden.
Bei der Verwendung der Koordinationsmuster wird davon ausgegangen, dass die Kommu-
nikation zwischen zwei Kommunikationspartnern eine Punkt-zu-Punkt-Verbindung (engl. point-
to-point) dargestellt. Dadurch k¨
onnen Seiteneffekte, die durch eine zus¨
atzliche Kommunikation
erzeugt werden k¨
onnen, ausgeschlossen werden. Bei der Verifikation ist es dann nicht notwendig,
andere Koordinationsmuster oder Komponenten zu betrachten; alle notwendigen Informationen
sind im Koordinationsmuster enthalten.
34 KAPITEL 2. GRUNDLAGEN
Der Model Checker pr¨
uft zum einen, ob das Muster das Musterconstraint einh¨
alt und zum
anderen verklemmungsfrei ist.
Im Beispiel des DistanceCoordination-Musters muss der Model Checker pr¨
ufen, ob
MfrontRole||MKonnektor||MrearRole|= (A[] not (rearRole.convoy and frontRole.noConvoy)) ∧
¬deadlock gilt. Dabei bezeichnet Mxden Timed Automata, auf den das entsprechende Real-Time
Statechart abgebildet wurde und || die Parallelausf¨
uhrung von Automaten.
2.4.2 Verifikation der Komponenten
Um nachzuweisen, dass eine Komponente korrekt ist, muss gezeigt werden, dass ihre Ports kor-
rekte Verfeinerungen der Rollen darstellen, die Komponente die Rolleninvarianten aller verfei-
nerter Rollen erf¨
ullt und verklemmungsfrei ist.
Dass ein Port eine korrekte Verfeinerung einer Rolle darstellt, wird durch seine Konstruktion
erreicht. Bei dieser Konstruktion darf das Rollenverhalten nur um interne Kommunikation er-
weitert werden. Es darf jedoch kein Verhalten, das durch die Rolle garantiert wird, entfernt oder
neues nach außen sichtbares Verhalten hinzugef¨
ugt werden.
Der Nachweis, dass die Komponente die Rolleninvarianten der verfeinerten Rollen erf¨
ullt, er-
folgt ¨
uber Model Checking. Wie bei der Verifikation der Koordinationsmuster reicht es aus, eine
Komponente unabh¨
angig von anderen Komponenten und Koordinationsmustern zu betrachten.
Allerdings werden bei dieser Verifikation die entry()-, do()- und exit()-Methoden der Zust¨
ande
sowie die Methodenaufrufe der Transitionen nicht ber¨
ucksichtigt. F¨
ur diese Methoden kann mit-
tels des in [Sei05] vorgestellten Ansatzes die maximale Ausf¨
uhrungszeit bestimmt werden. Die-
se Information kann dann dazu genutzt werden, um zu bestimmen, wie lange das Schalten einer
Transition maximal dauert. Diese Zeit wird dann beim Model Checking ber¨
ucksichtigt. Die Ve-
rifikation der Methoden erfolgt im Rahmen der Verifikation der Kulturen (siehe 2.4.3). Beim
Model Checking der Komponente wird davon ausgegangen, dass die Methoden korrekt sind.
Da f¨
ur die Rollen nur verlangt wird, dass sie verklemmungsfrei sind, muss f¨
ur die Shuttle-
Komponente gepr¨
uft werden, ob MfrontPort||MSynch||MrearPort|=¬deadlock gilt.
Die Verifikation hybrider Komponenten ist Inhalt aktueller Forschung. Burmester liefert in
[Bur05] Argumente, die darauf schließen lassen, dass die Verifikation hybrider Komponenten
¨
ahnlich zur Verifikation diskreter Komponenten erfolgen kann. Auch bei dieser Verifikation wird
f¨
ur die aufgerufenen Methoden, beschrieben durch Story Patterns, mittels des Ansatz von [Sei05]
die maximale Ausf¨
uhrungszeit berechnet. Wie bei den diskreten Komponenten wird aber auch
hier angenommen, dass die Methoden korrekt sind. Die Korrektheit der Methoden wird wie bei
den diskreten Komponenten mittels der Verifikation der Kulturen sichergestellt. Dies ist m¨
oglich
da die Story Patterns, die die Methoden beschreiben, diskret sind und auf der gleichen Ontologie
arbeiten wie die Story Patterns der diskreten Komponenten.
2.4.3 Verifikation der Kulturen
F¨
ur jede Kultur wird eine Menge von Eigenschaften spezifiziert, die von Absichtserkl¨
arungen,
Instanzierungs- und Verhaltensregeln erf¨
ullt werden m¨
ussen. Wird eine Kultur instanziert, so
2.4. VERIFIKATION 35
werden die verifizierten Regeln den beteiligten Agenten zugewiesen, je nachdem welche Rolle
sie in der resultierenden Community ¨
ubernehmen.
Die Organisation der Kulturen in einer Hierarchie erm¨
oglicht eine kompositionale Verifika-
tion. F¨
ur eine Kultur muss nachgewiesen werden, dass die in ihr angegebenen Regeln sowie die
Regeln aller ¨
ubergeordneter Kulturen, die Sicherheitseigenschaften einhalten, die in der betrach-
teten und allen ¨
ubergeordneten Kulturen angegeben sind. Eigenschaften, die in untergeordneten
Kulturen verlangt werden oder in Kulturen in einem anderen Zweig der Hierarchie enthalten
sind, brauchen von der Kultur nicht eingehalten werden und deshalb bei der Verifikation einer
Kultur auch nicht ber¨
ucksichtigt werden. Somit f¨
uhrt die Verwendung der Kulturhierarchie dazu,
dass immer nur ein Ausschnitt des Systems verifiziert werden muss. Wurden alle Kulturen er-
folgreich verifiziert, so ist auch das Gesamtsystem korrekt. Eine Verifikation, die zeigt, dass alle
Regeln des Systems alle Eigenschaften erf¨
ullen, ist nicht notwenig1.
Besteht eine Kultur aus einem Koordinationsmuster, so erfolgt die Verifikation des Musters
wie in Abschnitt 2.4.1 dargestellt.
Werden die Regeln einer Kultur durch Story Patterns und die Eigenschaften durch verbo-
tene Story Patterns beschrieben, so wird eine Instanzsituation, beschrieben durch ein UML-
Objektdiagramm, als Graph aufgefasst (siehe dazu auch Kapitel 4). Jedes Objekt des Objekt-
diagramms entspricht dann einem Knoten des Graphen und jeder Link einer Kanten. Die Story
Patterns, die die Regeln beschreiben, k¨
onnen dann als Graphtransformationsregeln aufgefasst
werden.
F¨
ur die Verifikation von Graphtransformationsregeln existieren einige Ans¨
atze (siehe Ab-
schnitt 5.2 und 6). Allerdings sind diese Ans¨
atze dahingehend beschr¨
ankt, dass sie zum einen
einen Initialgraphen (also eine initiale Instanzsituation) ben¨
otigen, zum anderen d¨
urfen durch
die Anwendung der Graphtransformationsregeln nur endlich viele Graphen erzeugbar sein. Bei
den hier betrachteten Systemen ist zum Zeitpunkt der Verifikation der Initialgraph noch nicht be-
kannt. Dar¨
uber hinaus k¨
onnen die Regeln der Kultur unendlich viele Graphen erzeugen. Deshalb
wird in Kapitel 3 ein neuer Ansatz zur Verifikation von Graphtransformationsregeln vorgestellt,
der nicht diesen Einschr¨
ankungen unterliegt.
Die Objekte eines Story Patterns k¨
onnen auch Koordinationsmuster darstellen. In diesem
Fall gilt jedoch, dass das in dem Koordinationsmuster beschriebene Verhalten keinen Einfluss
auf das Story Pattern hat. Bei der Verifikation der Story Patterns wird davon ausgegangen, dass
das zugrunde liegende Koordinationsmuster korrekt ist. Ist dies der Fall, so garantiert die Verifi-
kation der Story Patterns, dass ben¨
otigte Koordinationsmuster immer vorhanden sind bzw. nicht
ben¨
otigte Koordinationsmuster gel¨
oscht werden. Die Realisierung der Koordinationsmuster hat
keinen Einfluss auf die Verifikation der Regeln.
2.4.4 Korrektheit des Gesamtsystems
Nachdem die Teile verifiziert wurden, aus denen das Gesamtsystem zusammengesetzt wird, ist
die Verifikation abgeschlossen. Eine zus¨
atzliche Verifikation des Gesamtsystems ist nicht mehr
notwendig.
1In zuk¨
unftigen Arbeiten soll gezeigt werden, dass bei der Verifiaktion einer Kultur nur die Regeln und Eigen-
schaften verifiziert werden m¨
ussen, die Teil dieser Kultur sind, siehe dazu auch Abschnitt 7.
36 KAPITEL 2. GRUNDLAGEN
In [GTB+03, GST+03] wurde gezeigt, dass ein System, das aus erfolgreich verifizier-
ten Koordinationsmuster- und Komponenteninstanzen syntaktisch korrekt zusammengesetzt ist,
auch insgesamt korrekt ist.
Die Instanzierung und das L¨
oschen der Koordinationsmuster erfolgt durch die Story Pat-
terns. F¨
ur diese Story Patterns wird mit dem in Kapitel 3 vorgestellten Ansatz gezeigt, dass sie
die Koordinationsmuster instanzieren, sobald sie ben¨
otigt werden bzw. l¨
oschen, wenn sie nicht
mehr ben¨
otigt werden. Allerdings muss noch garantiert werden, dass das komponenteninterne
Real-Time Statechart diese Story Patterns immer dann ausf¨
uhrt, wenn die Story Patterns auf die
Ontologie der Komponente angewendet werden k¨
onnen. Um dies garantieren zu k¨
onnen, muss in
jedem Zustand des komponenteninternen Real-Time Statechart jedes der Story Patterns entweder
als do()-Methode oder als Seiteneffekt einer ausgehenden Transition ausgef¨
uhrt werden.
Die in Abbildung 2.9 dargestellte Shuttle-Komponente erf¨
ullt diese Anforderung noch nicht.
2.5 Der Modellierungs- und Verifikationsprozess
In den Abschnitten 2.1.2 bis 2.4.4 wurde gezeigt, wie die Software eines mechatronischen Sys-
temsmodelliert, strukturiert und verifiziertwird.In diesem Abschnitt soll nunder Modellierungs-
und Verifikationsprozess noch einmal zusammenfassend dargestellt werden.
Zun¨
achst (1) wird das Koordinationsverhalten des Systems in Koordinationsmustern spezi-
fiziert. Diese Koordinationsmuster werden (2), wie oben beschrieben, durch Model Checking
verifiziert.
Ausgehend von den Koordinationsmusters wird die Kulturhierarchie aufgebaut (3). Die Re-
geln jeder Kultur, die mittels Story Patterns spezifiziert sind, werden (4) durch den in Kapitel 3
vorgestellten Ansatz verifiziert.
Als n¨
achstes (5) wird das Koordinationsverhalten der Komponenten modelliert. Die Kompo-
nenten stellen die Agenten des mechatronischen Systems dar. Dazu wird aus den Koordinations-
mustern/Kulturen die Menge der Rollen ausgew¨
ahlt, die die Komponente realisieren soll. Die
Rollen werden in den Ports der Komponente verfeinert. Die Regeln, die in einer Kultur f¨
ur eine
Rolle spezifiziert sind, werden im komponenteninternen Real-Time Statechart als entry()-, do()-
und exit()-Methoden bzw. als Methodenaufrufen an den Transitionen verwendet. Mittels Model
Checking kann (6) f¨
ur jede Komponente nachgewiesen werden, dass sie die Rolleninvarianten
der von ihr verfeinerten Rollen erf¨
ullt. Nach der Verifikation wird (7) f¨
ur jede Komponente und
jedes Koordinationsmuster der entsprechende Code automatisch generiert.
Das Gesamtsystem wird dann (8) dynamisch zur Laufzeit gebildet.
2.6 Zusammenfassung
In diesem Kapitel wurde zu n¨
achst die Architektur des Operator-Controller-Moduls vorgestellt.
Diese Architektur erm¨
oglicht eine Strukturierung der Informationsverarbeitung eines mechatro-
nischen Systems und teilt es in die drei Ebenen Controller, reflektorischer Operator und kogniti-
ver Operator ein. Die Software des reflektorischen Operators ist f¨
ur die Steuerung eines mecha-
2.6. ZUSAMMENFASSUNG 37
tronischen Systems und der Interaktion mit anderen Systemen verantwortlich. Da diese Software
komplex und sicherheitskritisch ist wurde ein Ansatz zur kompositionalen Modellierung und
Verifikation dieser Software vorgestellt. Die verwendeten Modellierungstechniken basieren auf
Ausschnitten der UML. Allerdings wurden die gew¨
ahlten Ausschnitte auf die Anforderungen bei
der Modellierung von mechatronischen Systemen angepasst.
Die Architektur der Software wird mittels Komponentendiagrammen und Echtzeit-
Koordinationsmustern beschrieben. Zur Spezifikation der komponenteninternen Struktur werden
Klassendiagramme verwendet.
Das Koordinationsverhalten der Komponenten wird in den Koordinationsmustern mittels
Real-Time Statecharts beschrieben. Komponenten, die eine bestimmte Rolle innerhalb eines sol-
chen Koordinationsmusters einnehmen sollen, verfeinern die entsprechende Rolle zu einem Port.
Ein Port sowie das komponenteninterne Verhalten wird durch Real-Time Statecharts modelliert.
Dabei darf das komponenteninterne Real-Time Statechart entry()-,do()- und exit()-Methoden in
den Zust¨
anden aufrufen und Methoden als Seiteneffekte der Transitionen ausf¨
uhren. Diese Me-
thoden werden mittels Story Patterns beschrieben.
Soziale Metaphern wie Kulturen, Communities und Agenten werden verwendet, um die kom-
plexe Software eines mechatronischen Systems zu strukturieren und die ben¨
otigten Story Pat-
terns, die in den komponenteninternen Real-Time Statecharts aufgerufen werden, zu finden.
Um garantieren zu k¨
onnen, dass die resultierende Software bestimmte Sicherheitseigenschaf-
ten einh¨
alt, wird eine kompositionale Verifikation verwendet. Dabei wird jedes Koordinations-
muster und jede Komponente unabh¨
angig von anderen Mustern und Komponenten mittels Mo-
del Checking ¨
uberpr¨
uft. Wobei bei der Verifikation der Komponenten angenommen wird, dass
die aufgerufenen Methoden korrekt sind. Um nachzuweisen, dass die aufgerufenen Methoden,
beschrieben durch Story Patterns, korrekt sind, wird ausgenutzt, dass Story Patterns eine einge-
schr¨
ankte Form von Graphtransformationsregeln darstellen. Das bedeutet, die Verifikation kann
mittels Verifikationstechniken f¨
ur Graphtransformationssysteme durchgef¨
uhrt werden.
F¨
ur eine solche Verifikation existieren zwar schon einige Ans¨
atze (siehe Abschnitt 6), diese
sind jedoch zur Verifikation der Software mechatronischer Systeme nur eingeschr¨
ankt einsetzbar.
Daf¨
ur gibt es zwei Gr¨
unde. Zum einen ben¨
otigen diese Verifikationstechniken einen Anfangszu-
stand und zum anderen darf der resultierende Zustandsraum nur endlich sein.
Bei der Entwicklung der Software eines mechatronischen Systems soll die Verifikation zum
fr¨
uhestm¨
oglichen Zeitpunkt erfolgen, um Fehler im System entsprechend fr¨
uh erkennen und
beheben zu k¨
onnen. Allerdings muss zu diesem Zeitpunkt der Anfangszustand des Systems noch
nicht bekannt sein. Dar¨
uber hinaus kann f¨
ur die Story Patterns, die die Methoden des Systems
beschreiben, nicht garantiert werden, dass sie nur endlich viele Zust¨
ande erzeugen. Deshalb soll
im folgenden Kapitel ein Ansatz vorgestellt werden, der diesen Einschr¨
ankungen nicht unterliegt.
38 KAPITEL 2. GRUNDLAGEN
Kapitel 3
Nachweis induktiver Invarianten
Im vorangegangenen Kapitel wurde gezeigt, wie die Softwarearchitektur eines mechatroni-
schen Systems mittels Komponenten- und Klassendiagrammen beschrieben wird. Zudem wurden
Echtzeit-Koordinationsmuster eingef¨
uhrt, um eine sichere Kommunikation zwischen den Kom-
ponenten modellieren zu k¨
onnen. Das Verhalten der Komponenten sowie die Kommunikations-
protokolle der Koordinationsmuster werden durch Real-Time Statecharts spezifiziert. Kulturen
und Communities strukturieren die Software eines mechatronischen Systems. Sie erm¨
oglichen
es, das Gesamtmodell aus kleinen Teilmodellen zusammenzuf¨
ugen. In einer Kultur werden Re-
geln f¨
ur ihre Teilnehmer festgelegt. Zu diesen Regeln geh¨
oren Instanzierungs- und Verhaltens-
regeln sowie Absichtserkl¨
arungen. Die Regeln werden mittels Story Patterns spezifiziert. Sie
werden in den Real-Time Statecharts der Komponenten als entry()-, do()- und exit()-Methoden
in den Zust¨
anden aber auch als Seiteneffekte der Transitionen ausgef¨
uhrt.
Damit ein derart spezifiziertes Modell korrekt ist, muss es die in den Kulturen festgelegten
Eigenschaften erf¨
ullen. Zu diesen Eigenschaften geh¨
oren einerseits die als TCTL-Formeln spezi-
fizierten Musterconstraints und Rolleninvarianten der Koordinationsmuster, andererseits k¨
onnen
aber auch verbotene Eigenschaften wie kritische Situationen und Unf¨
alle, in Form von verbote-
nen Story Patterns, in den Kulturen definiert sein.
In Abschnitt 2.4 wurde gezeigt, wie mit Hilfe von Model Checking verifiziert werden kann,
ob die Real-Time Statecharts der Koordinationsmuster und Komponenten die Musterconstraints
und Rolleninvarianten einhalten. In diesem Kapitel wird ein Ansatz vorgestellt, der eine Verifi-
kation der durch Story Patterns beschriebenen Regeln erm¨
oglicht.
Die Idee, die der Verifikation zugrunde liegt, ist die folgende: Ein Systemzustand wird durch
seine Objekte und deren Links charakterisiert, d.h. ein Systemzustand kann durch ein Objekt-
diagramm beschrieben werden. Die Story Patterns beschreiben die Zustands¨
uberg¨
ange, also das
Instanzierenund L¨
oschenvonObjekten sowie dasErzeugen und L¨
oschenvonLinks. EinSystem-
zustand ist korrekt, wenn auf das entsprechende Objektdiagramm keines der verbotenen Story
Patterns anwendbar ist. Um ¨
uberpr¨
ufen zu k¨
onnen, ob ein inkorrekter Zustand durch die An-
wendung der Regeln erreicht werden kann, werden die Objektdiagramme als Graphen aufgefasst
und die Story Patterns als Graphtransformationsregeln. Der Anfangszustand, der durch einen In-
itialgraphen repr¨
asentiert wird, zusammen mit allen Graphtransformationsregeln bildet dann ein
Graphtransformationssystem.
39
40 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
F¨
ur die Verifikation von Graphtransformationssysteme existieren bereits einige Ans¨
atze (sie-
he Abschnitt 5.2 und Kapitel 6). Diese unterliegen aber den Einschr¨
ankungen, dass sie einen
Initialgraphen ben¨
otigen, um die Analyse durchf¨
uhren zu k¨
onnen. Außerdem sind die meisten
dieser Ans¨
atze auf Graphtransformationssysteme beschr¨
ankt, die nur eine endliche Menge von
Graphen erzeugen k¨
onnen. Diese beiden Einschr¨
ankungen sind in mechatronischen Systemen
im Allgemeinen jedoch nicht erf¨
ullt.
In diesem Kapitel wird deshalb ein Ansatz vorgestellt, der eine Verifikation der Regeln auch
dann erlaubt, wenn kein Initialgraph gegeben ist und die Regeln unendlich viele Graphen erzeu-
gen k¨
onnen. Der Ansatz wird in Abschnitt 3.1 zun¨
achst informal erl¨
autert, bevor in Abschnitt 3.2
ff. die formale Erl¨
auterung erfolgt. Die Beweisskizzen zu den in Abschnitt 3.2 ff. aufgef¨
uhrten
Lemmata und Theoremen sind in Anhang B enthalten.
Heckel und Wagner stellen in [HW95] ein Ansatz vor, bei dem die Systemkorrektheit durch
eine automatische Modifikation der Regeln erreicht wird. Systemeigenschaften werden dabei als
Konsistenzbedingungen modelliert. Die Konsistenzbedingungen werden dabei als Graphen und
Graphhomomorphismen spezifiziert. Die Modifikation erfolgt indem die Nachbedingungen jeder
Regel mit einer Konsistenzbedingung verbunden werden. Dabei resultiert dann ein neuer Graph.
Auf diesen Graphen wird die Regel in R¨
uckw¨
artsrichtung angewendet. Der dabei entstandene
Graph liefert eine Beschreibung, wann die entsprechende Regel nicht angewendet werden darf,
undwird alsnegative Anwendungsbedigung der Regelbezeichnet. Der imFolgendenvorgestellte
Ansatz verwendet eine ¨
ahnliche Technik. Auch dieser Ansatz verbindet die Nachbedingung einer
Regel mit einem Graphen, der eine Eigenschaft beschreibt. Allerdings werden die Regeln nicht
automatisch ver¨
andert. Findet der Ansatz eine Regel, die inkorrekt ist, so liefert er ein Gegenbei-
spiel, das zeigt, wann die Anwendung der Regel einen inkorrekten Graphen erzeugen kann. Eine
ausf¨
uhrliche Diskussion der Unterschiede zwischen den beiden Ans¨
atzen wird in Abschnitt 6.1
gegeben.
In diesem Kapitel wird zun¨
achst die Idee des Verifikationsansatzes informal beschrieben (Ab-
schnitt 3.1). In Abschnitt 3.2 werden dann die Grundlagen der Graphtransformationssysteme for-
mal eingef¨
uhrt. In dieser Arbeit werden Eigenschaften von Graphtransformationssystemen und
Mengen von Graphen mittels Graphmustern beschrieben. Diese werden in Abschnitt 3.3 ein-
gef¨
uhrt. Nachdem diese Grundlagen beschrieben wurden, werden die Graphen und Graphtrans-
formationssysteme um Typen erweitert (Abschnitt 3.4). Der Verifikationsansatz verlangt, dass
Graphtransformationsregeln auch r¨
uckw¨
arts und auf Graphmuster angewendet werden k¨
onnen.
Damit dies m¨
oglich ist, sind einige Erweiterungen notwendig, diese werde in Abschnitt 3.5
vorgestellt. Abschnitt 3.6 besch¨
aftigt sich dann mit Systemeigenschaften und beschreibt Ein-
schr¨
ankungen, die bei der Verifikation der Graphtransformationssysteme ausgenutzt werden
k¨
onnen. Der eigentliche Verifikationsansatz wird dann in Abschnitt 3.7 vorgestellt.
3.1 Die Idee
Der in diesem und den folgenden Abschnitten vorgestellte Ansatz erm¨
oglicht die Verifikation von
Graphtransformationssystemen. Nach der informalen Einf¨
uhrung von Graphtransformationssys-
temen werden Graphmuster zur Beschreibung struktureller Eigenschaften solcher Systeme ein-
3.1. DIE IDEE 41
gef¨
uhrt und die Verifikationsidee erl¨
autert. Dazu werden sowohl die Graphtransformationen als
auch die Graphmuster zun¨
achst so vereinfacht, dass sie keine negativen Anwendungsbedingun-
gen enthalten. In Abschnitt 3.1.5 wird dann die Verifikation von Regeln mit negativer Anwen-
dungsbedingung betrachtet.
3.1.1 Graphtransformationssysteme
Ein Graph besteht nach [Roz97] aus einer Menge von typisierten Knoten und einer Menge von
gerichteten und typisierten Kanten zwischen den Knoten. Bei den hier betrachteten Graphen
handelt es sich um typisierte Graphen ohne Attribute.
Eine Graphtransformationsregel beschreibt die Ver¨
anderung eines Graphen durch L¨
oschen
und Hinzuf¨
ugen von Knoten und Kanten (im Folgenden kurz als Elemente bezeichnet). Eine
solche Regel L→rRbesteht aus einer linken Regelseite L, der Anwendungs- oder Vorbedingung
und einer rechten Regelseite R, der Nachbedingung. Jede der beiden wird durch einen Graphen
beschrieben. rist der Name der Regel.
Soll eine Graphtransformationsregel auf einen Graphen, den Anwendungsgraphen, angewen-
det werden, so m¨
ussen alle Elemente der Anwendungsbedingung auf entsprechende Elemente
aus dem Anwendungsgraphen abgebildet werden k¨
onnen. Ist dies m¨
oglich, so werden alle Ele-
mente, die nur in der Anwendungsbedingung enthalten sind, nicht aber in der Nachbedingung,
gel¨
oscht. Elemente, die in beiden Graphen enthalten sind, bleiben erhalten. Solche Elemente, die
nur in der Nachbedingung enthalten sind, werden neu erzeugt und in den Anwendungsgraphen
eingef¨
ugt.
In Abbildung 3.1 ist ein Beispiel f¨
ur eine Graphtransformationsregel gegeben. Diese Re-
gel beschreibt die Vorw¨
artsbewegung eines Shuttlesrs von einem Track rt1auf einen folgenden
Track rt2. Dazu wird die locatedOn-Kante rlo1zwischen rs und rt1gel¨
oscht und eine neue loca-
tedOn-Kante zwischen rs und rt2erzeugt. Die Regel entspricht dem Story Pattern moveSimple
in Abbildung 2.10 aus Kapitel 2.
"!
#$%&')(
#*+*,,
-./%0')(
1 24357698;:#2=<?>@6
#$%&')(
#*AB*,,
-./%0')(
C.D E F!
G
Abbildung 3.1: Die Graphtransformationsregel moveSimple
Ein Graphtransformationssystem besteht aus einer Menge von Initialgraphen sowie einer
Menge von Graphtransformationsregeln.
3.1.2 Graphmuster und Systemkorrektheit
Strukturelle Eigenschaften, die von einem gegebenen Graphtransformationssystem erf¨
ullt wer-
den sollen, werden durch Graphmuster beschrieben. Solange die negativen Anwendungsbedin-
42 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
gungen außer Acht gelassen werden, entsprechen diese Graphmuster einfachen Graphen. Gra-
phmuster beschreiben Teilgraphen. Jeder Graph, der einen solchen Teilgraphen enth¨
alt, erf¨
ullt
das Graphmuster. Deshalb k¨
onnen Graphmuster dazu verwendet werden, Mengen von Graphen
zu beschreiben.
Es gibt zwei Arten von Graphmustern; die geforderten Graphmuster und die verbotenen
Graphmuster. Geforderte Graphmuster m¨
ussen immer erf¨
ullt werden. Verbotene Graphmuster
d¨
urfen nie erf¨
ullt werden. Sie stellen kritische Situationen oder Unf¨
alle dar und sind deshalb in
dieser Arbeit von besonderem Interesse.
Abbildung 3.2 zeigt das verbotene Graphmuster impendingCollisionSimplified. Dieses verbo-
tene Graphmuster besagt, dass eine kritische Situation eingetreten ist, wenn sich zwei Shuttles
auf benachbarten Tracks befinden. Dabei handelt es sich um eine Vereinfachung der in Abschnitt
2.1.3 beschriebenen kritischen Situation impendingCollision, bei der sich nie zwei Shuttles auf
benachbarten Tracks befinden d¨
urfen, die nicht das DistanceCoordination-Koordinationsmuster
miteinander ausf¨
uhren.
!"#%$&('
!)*
)*#%$&('
+,-.!/$
-)
Abbildung 3.2: Verbotenes Graphmuster impendingCollisionSimplified
Ein Graph und somit der durch den Graphen repr¨
asentierte Systemzustand ist korrekt, wenn
er kein verbotenes Graphmuster enth¨
alt, d.h. wenn keines der verbotenen Graphmuster auf einen
Teilgraphen des Graphen abgebildet werden kann. Das gesamte Graphtransformationssystem ist
korrekt, wenn alle durch die Anwendung der Graphtransformationsregeln erreichbaren Graphen
korrekt sind.
In Abbildung 3.3(a) ist ein Graph dargestellt, der im Bezug auf das verbotene Graphmuster
impendingCollisionSimplified korrekt ist. Abbildung 3.3(b) zeigt dagegen einen inkorrekten Gra-
phen, da das verbotene Graphmuster impendingCollisionSimplified auf einen Teilgraphen abge-
bildet werden kann. Die Elemente, auf die das verbotene Graphmuster abgebildet werden kann,
sind zum einen rot dargestellt und zum anderen beginnt ihr Name jeweils mit v. Elemente, auf
die kein Element des verbotenen Graphmusters abgebildet wird, sind schwarz dargestellt und ihr
Name beginnt mit einem a.
3.1.3 Erreichbarkeitsanalyse
Eine erste Idee, die Korrektheit eines Graphtransformationssystems im Bezug auf eine Men-
ge von verbotenen Graphmustern zu pr¨
ufen, stellt die Erreichbarkeitsanalyse dar. Dabei wird
zun¨
achst f¨
ur den Anfangszustand gepr¨
uft, ob dieser korrekt ist. Ist das nicht der Fall, so kann die
Analyse beendet werden, da das System schon bei der Initialisierung inkorrekt ist. Ist der Ini-
tialgraph korrekt, so werden alle Graphtransformationsregeln angewendet, deren Anwendungs-
3.1. DIE IDEE 43
!#"$%&
'()*++
+,'-!#"$%&
.'-
/-)
+0$/1.0$2,
%3()*++
%4()
+0$0$2,
5$'(.5$22,
+0$365$2,,
+0$4.0$2,
(a) Beispiel f¨
ur einen Graphen, der im Bezug auf das verbotene
Graphmuster impendigCollisionSimplified korrekt ist
!"
#
#
$
&%')(+*-,
$
, )%./, 0120354
$
%' !"
$
)(6*-,
$
$
"%.
$
, '0120354
(b) Beispiel f¨
ur einen Graphen, der im Bezug
auf das verbotene Graphmuster impendigCollisi-
onSimplified inkorrekt ist
Abbildung 3.3: Beispiel f¨
ur die Korrektheit bzw. Inkorrektheit von Graphen
bedingung erf¨
ullt ist, d.h. der Graph, der die Anwendungsbedingung beschreibt, kann auf einen
Teilgraphen des Initialgraphen abgebildet werden. Die Anwendung aller m¨
oglichen Graphtrans-
formationsregeln auf den Anwendungsgraphen resultiert in einer Menge von Graphen. F¨
ur jeden
dieser Graphen muss wieder gepr¨
uft werden, ob er korrekt ist. Ist einer der Graphen inkorrekt,
so bricht die Analyse ab, da das System einen inkorrekten Graphen erreichen kann. Sind alle
Graphen korrekt, so werden auf jeden der Graphen alle anwendbaren Graphtransformationsre-
geln angewendet, woraus wieder eine Menge von Graphen resultiert. Auch f¨
ur diese Menge muss
¨
uberpr¨
uft werden, ob alle in ihr enthaltenen Graphen korrekt sind. Dieses Verfahren wird so lange
fortgesetzt bis entweder ein inkorrekter Graph gefunden wurde oder keine weitere Graphtrans-
formationsregel mehr anwendbar ist. Im letzteren Fall ist das System korrekt, da kein inkorrekter
44 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
Graph erreichbar ist. Die bei der Erreichbarkeitsanalyse nachgewiesenen Eigenschaften werden
als operationale Invarianten bezeichnet.
Bei der Erreichbarkeitsanalyse wird gepr¨
uft, ob ein inkorrekter Graph erreicht werden kann.
Eine solche Analyse ist jedoch nicht immer m¨
oglich. Zum einen ist zur Entwurfszeit eines me-
chatronischen Systems, wenn die Korrektheit der Graphtransformationsregeln gepr¨
uft wird, die
Menge der Initialgraphen des Graphtransformationssystems noch nicht bekannt bzw. die Menge
kann sich noch ver¨
andern. F¨
ur jeden neu hinzugef¨
ugten Initialgraphen m¨
usste erneut eine Ana-
lyse durchgef¨
uhrt werden. Das zweite Problem, das diese Art der Analyse verhindert, ist, dass
durch die Anwendung der Graphtransformationsregeln unendlich viele verschiedene Graphen
erzeugt werden k¨
onnen, sodass eine ¨
Uberpr¨
ufung aller erreichbaren Graphen nicht terminiert.
Deshalb wird im folgenden Abschnitt ein Verfahren vorgestellt, das die Korrektheit einer
Menge von Graphtransformationsregeln bez¨
uglich einer Menge von Sicherheitseigenschaften,
die als Graphmuster gegeben sind, auch dann nachweisen kann, wenn die Regeln unendlich viele
Graphen erzeugen k¨
onnen und kein Initialgraph gegeben ist.
3.1.4 Nachweis induktiver Invarianten
Eine Erreichbarkeitsanalyse ist nur dann m¨
oglich, wenn ein Initialgraph gegeben ist und das
betrachtete Graphtransformationssystem nur endlich viele erreichbare Graphen besitzt. Deshalb
soll im Folgenden ein Verfahren beschrieben werden, das unabh¨
angig von der Erreichbarkeit ei-
nes Graphen ¨
uberpr¨
uft, ob eine Graphtransformationsregel ein verbotenes Graphmuster erzeugen
kann.
Bei dieser Verifikation wird gepr¨
uft, ob die Anwendung einer Graphtransformationsregel
auf einen korrekten Graphen wieder einen korrekten Graphen erzeugt. Ob die korrekten Gra-
phen zur Menge der erreichbaren Graphen geh¨
ort, wird dabei nicht betrachtet. Kann f¨
ur al-
le Regeln gezeigt werden, dass sie, wenn sie auf korrekte Graphen angewendet werden, nie-
mals einen inkorrekten Graphen erzeugen k¨
onnen, so stellt das ”Nicht-Auftreten“eines verbote-
nen Graphmusters eine induktive Invariante des betrachteten Graphtransformationssystems dar
[GS04, GSK+06, BGS05a].
Der Ansatz nutzt drei Eigenschaften der Graphtransformationsregeln: (1.) Es muss mindes-
tens ein Element (Knoten oder Kante) im verbotenen Graphmuster geben, das auf ein Element
der rechten Regelseite abgebildet werden kann. Andernfalls w¨
urde die Regelanwendung das ver-
botene Muster nicht erzeugen. (2.) Die Anwendung einer Graphtransformationsregel auf einen
Graphen hat nur Auswirkungen auf Elemente, auf die die Elemente der Regel abgebildet werden.
Deshalb ist es ausreichend, Ausschnitte von Graphen statt vollst¨
andiger beliebig großer Graphen
zu betrachten. (3.) Eine Graphtransformationsregel kann auch r¨
uckw¨
arts angewendet werden,
dadurch kann f¨
ur einen inkorrekten Graphen gepr¨
uft werden, ob dieser durch die Anwendung
einer Regel aus einem korrekten Graphen entstanden sein kann.
Zu (1.): Gegeben sind eine Graphtransformationsregel und ein verbotenes Graphmuster. Ist
zus¨
atzlich ein Graph gegeben, der im Bezug auf das verbotene Graphmuster korrekt ist, so kann
der Graph, der resultiert, wenn man die Graphtransformationsregel auf den gegebenen korrekten
Graphen anwendet nur dann inkorrekt sein, wenn die Anwendung der Regel den korrekten Gra-
phen in den inkorrekten ¨
uberf¨
uhrt. Da das verbotene Graphmuster nicht Teil des Anwendungs-
3.1. DIE IDEE 45
graphen war, muss durch die Anwendung der Regel mindestens ein Element erzeugt worden
sein, das Bestandteil des verbotenen Graphen ist.
Die Abbildungen 3.4 und 3.5 zeigen je zwei Graphen. Der jeweils untere ist inkorrekt, da
er das verbotene Graphmuster impendingCollisionSimplified enth¨
alt. Beide Graphen sind durch
die Anwendung der Graphtransformationsregel moveSimple entstanden. Der Anwendungsgraph,
auf den die Regel angewendet wurde, ist jeweils der obere Graph.
In diesem und den folgenden Beispielen wurde die folgende Namens- und Farbkonvention
verwendet: Elemente, auf die sowohl die Elemente der Regel als auch die des verbotenen Gra-
phmusters abgebildet werden, sind blau dargestellt und ihr Name beginnt mit einem m. Elemente,
auf die nur Elemente der Regel abgebildet werden, sind gr¨
un gekennzeichnet und ihr Name be-
ginnt mit einem r. Solche Elemente, auf die nur Elemente des verbotenen Musters abgebildet
werden, sind rot und ihr Name beginnt mit einem v. Alle ¨
ubrigen Elemente sind schwarz und
ihr Name beginnt mit a. Wobei mf¨
ur Merging steht und eine Verbindung von verschiedenen
Graphen beschreibt, vsteht f¨
ur verboten, rf¨
ur Regel und af¨
ur Anwendungsgraph.
In Abbildung 3.4 wurde durch die Anwendung der Regel kein Element erzeugt, das zum ver-
botenen Muster geh¨
ort. Betrachtet man den Graphen im oberen Teil der Abbildung, so sieht man,
dass das verbotene Graphmuster schon Teil des Anwendungsgraphen war und somit nicht durch
die Regelanwendung entstanden ist. Genauer enth¨
alt der Anwendungsgraph im oberen Teil der
Abbildung das verbotene Graphmuster sogar zweimal. Zum einen kann er auf den Teilgraphen
abgebildet werden, der aus den Knoten vs1,mt1,vt2und vs2besteht und durch die Regelanwen-
dung nicht beeinflusst wird, zum anderen kann das verbotene Graphmuster aber auch auf den
Teilgraphen abgebildet werden, der aus den Knoten rs1,rt1,mt1und vs1besteht. Ebenso enth¨
alt
der resultierende Graph neben dem verbotenen Graphmuster impendingCollision auch ein ver-
botenes Graphmuster, dass die Kollision von zwei Shuttles und somit einen Unfall beschreibt.
Dieser Teilgraph besteht aus den Knoten vs1,mt1und vs2.
Im Gegensatz dazu wurde in Abbildung 3.5 die Kante mlo1durch die Anwendung der Regel
erzeugt, auf die die Kante vlo1:locatedOn abgebildet werden kann. Der Anwendungsgraph war
noch korrekt, erst die Anwendung der moveSimple-Regel hat die Kante erzeugt, die das ver-
botene Graphmuster vervollst¨
andigt hat und somit den korrekten Graphen in einen inkorrekten
¨
uberf¨
uhrt.
Zu (2.): Um eine Graphtransformationsregel auf einen Graphen anwenden zu k¨
onnen,m¨
ussen
alle Elemente der linken Regelseite auf Elemente des Graphen abgebildet werden. Durch die
Anwendung der Regel k¨
onnen nur diese Elemente gel¨
oscht werden. Ebenso k¨
onnen nur solche
Elemente zum Graphen hinzugef¨
ugt werden, die in der rechten Regelseite enthalten sind. Damit
eine neu erzeugte Kante inzident zu einem existierenden Knoten sein kann, muss der existierende
Knoten in der rechten Regelseite enthalten sein. Ebenso kann ein neuer Knoten nur dann adjazent
zu einem existierenden Knoten sein, wenn die entsprechende Kante neu erzeugt wird und der
existierende Knoten Teil der rechten Regelseite ist. Somit hat die Anwendung einer Regel nur
Auswirkungen auf Elemente, auf die die Elemente der Regel abgebildet werden.
Zu (3.): Wurde eine Graphtransformationsregel auf einen Graphen angewendet, so kann diese
Anwendung wieder r¨
uckg¨
angig gemacht werden. Die dazu notwendigen Einschr¨
ankungen wer-
den in Abschnitt 3.5 erl¨
autert. Dazu wird die Regel r¨
uckw¨
arts auf den entstandenen Graphen
angewendet, d.h. Elemente, die in der rechten Regelseite, aber nicht in der linken Seite der Regel
46 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
!"#
#
$&%'#(*),+
-+ #%./+ 012304!5
$%.
$%'
6%'
$%'#
7%'#(*),+
8
%.#
8
+ #%./+ 012304!5
8
29:
8
+ 9/+ ;2304<5
8
9:#(*),+
8
&%.#(*),+
=%:
-+ 9:/+ 012304!5
8
&%.#(*),+
8
+ #%>/+ 012304!5
=%'
8
%.#
8
29:
8
+ 9:/+ 012304!5
8
9:#(*),+
? @BA CED*FHG;IKJ CMLONPG
Abbildung 3.4: Die Regel moveSimple transformiert einen inkorrekten Graphen in einen anderen
inkorrekten Graphen
enthalten sind, werden gel¨
oscht und Elemente, die in der linken Regelseite enthalten sind, aber
nicht in ihrer rechten Seite, werden erzeugt.
Bei der weiter oben beschriebenen Erreichbarkeitsanalyse wird ausgehend von einem Start-
graphen ¨
uberpr¨
uft, ob die daraus erzeugbaren Graphen korrekt sind. Im Folgenden wird in um-
gekehrter Richtung vorgegangen. Das bedeutet, ausgehend von jedem inkorrekten Graphen, der
ein verbotenes Graphmuster enth¨
alt, wird f¨
ur alle Regeln ¨
uberpr¨
uft, ob sie diesen inkorrekten
Graphen aus einem korrekten erzeugt haben k¨
onnen. Bei der Analyse werden also Graphpaare
gesucht, bei denen der Anwendungsgraph korrekt ist, die Anwendung der betrachteten Regel
jedoch in einem inkorrekten Graphen resultiert.
Nach (1.) brauchen dazu nur solche Regeln betrachtet werden, die Elemente erzeugen, auf
die Elemente eines verbotenen Graphmusters abgebildet werden k¨
onnen. Konnte eine solche Re-
gel gefunden werden, so wird diese r¨
uckw¨
arts auf den inkorrekten Graphen angewendet. Der
resultierende Graph wird nun auf seine Korrektheit hin ¨
uberpr¨
uft. Enth¨
alt dieser Graph kein
verbotenes Graphmuster, ist also korrekt, so wurde ein Beispiel gefunden, das zeigt, dass die an-
gewendete Regel das System in einen inkorrekten Zustand ¨
uberf¨
uhren kann. Enth¨
alt dagegen der
resultierende Graph ebenfalls ein verbotenes Graphmuster, so erzeugt die Regel einen inkorrek-
3.1. DIE IDEE 47
!"
!#
$
#
&% '()% *+,.-0/
12'" 3546%
7'(
$'"
1'8
9
'8
9
+:"
9
% #:()% *+,.-0/
9
:" 3;46%
7'8
7'(
12'" 3;46%
1% '8)% .<+,.-/
1'"
9
'8
9
+:
9
% #:")% .<+,.-/
9
: 3546%
= >@? ACB5DFEHGJI7ALKNMOE
Abbildung 3.5: Die Regel moveSimple transformiert einen korrekten Graphen in einen inkorrek-
ten Graphen
ten Zustand aus einem anderen inkorrekten Zustand. Dieser Fall braucht nicht weiter betrachtet
zu werden, da nur die F¨
alle relevant sind, in denen eine Regel einen korrekten Zustand in einen
inkorrekten ¨
uberf¨
uhrt.
Abbildungen 3.4 und 3.5 zeigen zwei Beispiele, in denen die rechte Regelseite der Graph-
transformationsregel moveSimple und das verbotene Graphmuster impendingCollisionSimplified
mindestens einen gemeinsamen Knoten haben und somit die Regel das verbotene Graphmuster
erzeugt haben kann. Der jeweils untere Graph entspricht dem inkorrekten Graphen, auf den die
Regel r¨
uckw¨
arts angewendet wird. Der obere Graph stellt jeweils den Graphen dar, der resultiert,
wenn die Regel r¨
uckw¨
arts angewendet wurde.
In Abbildung 3.4 haben die rechte Regelseite und das verbotene Graphmuster nur den Knoten
mt1gemeinsam, dieser entspricht dem Knoten rt2der rechten Regelseite und dem Knoten vt1
des verbotenen Graphmusters. Die Knoten vs1und vs2entsprechen den gleichnamigen Knoten
des verbotenen Graphmusters und der Knoten rs1dem Knoten rs der Regel. Wird die Regel
moveSimple auf diesen Graphen r¨
uckw¨
arts angewendet, so resultiert der Graph, der im oberen
Teil der Abbildung zu sehen ist. Da auch dieser Graph inkorrekt ist, impendingCollisionSimplified
ist auch in ihm enthalten, hat die Regel lediglich einen inkorrekten Graphen in einen anderen
48 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
inkorrekten Graphen ¨
uberf¨
uhrt. Eine Regel ist jedoch nur dann inkorrekt, wenn sie, angewendet
auf einen korrekten Graphen, einen inkorrekten Graphen erzeugt. Deshalb kann der Fall, in dem
ein inkorrekter Graph in einen anderen inkorrekten ¨
uberf¨
uhrt wird, ignoriert werden.
Im unteren Graphen von Abbildung 3.5 haben das verbotene Graphmuster und die rechte
Regelseite die beiden Knoten mt1und ms1sowie die dazwischen verlaufene locatedOn-Kante
mlo1gemeinsam. Wird auf diesen Graphen die moveSimple-Regel r¨
uckw¨
arts angewendet, so
resultiert der obere der beiden in Abbildung 3.5 dargestellten Graphen. Dieser Graph enth¨
alt
das verbotene Graphmuster nicht und ist somit korrekt, d.h. es wurde ein Beispiel gefunden,
das zeigt, dass die Regel moveSimple einen korrekten Graphen in einen inkorrekten ¨
uberf¨
uhren
kann.
Bisher wurden immer vollst¨
andige Graphen betrachtet, um die Korrektheit der Regel zu ¨
uber-
pr¨
ufen. Da es jedoch unendlich viele inkorrekte Graphen geben kann, ist es nicht m¨
oglich, f¨
ur
jeden inkorrekten Graphen und jede Regel zu zeigen, dass die jeweilige Regel den inkorrek-
ten Graphen nicht aus einem korrekten erzeugt haben kann. Stattdessen sollen die bereits zu-
vor eingef¨
uhrten Graphmuster dazu verwendet werden, Mengen von Graphen zu beschreiben.
Graphmuster statt vollst¨
andiger Graphen zu betrachten ist ausreichend, da die Anwendung von
Graphtransformationsregeln nur Auswirkungen auf die Elemente eines Graphen haben, auf die
die Elemente der Regel abgebildet werden (2.). Ein solches Graphmuster muss zum einen ein ver-
botenes Graphmuster enthalten und zum anderen die Elemente der rechten Regelseite. Dar¨
uber
hinaus muss mindestens eines dieser Element sowohl Teil des verbotenen Graphmusters als auch
der rechten Regelseite sein.
In den Abbildungen 3.4 und 3.5 entsprechen die relevanten Ausschnitte genau den Elemen-
ten, die blau, gr¨
un oder rot gekennzeichnet sind.
Ein solcher Ausschnitt kann Teil von mehreren, unter Umst¨
anden unendlich vielen, Graphen
sein und kann somit dazu verwendet werden, Mengen von Graphen zu beschreiben. Diese Aus-
schnitte werden als Graphmuster oder genauer als Ergebnisgraphmuster bezeichnet. Da sowohl
die Menge der Graphtransformationsregeln als auch die Menge der verbotenen Graphmuster end-
lich ist und jeder der Graphen aus endlich vielen Knoten und Kanten besteht, ist die Menge der
m¨
oglichen Ergebnisgraphmuster ebenfalls endlich.
Zwei m¨
ogliche Ergebnisgraphmuster f¨
ur die Regel moveSimple und das verbotene Gra-
phmuster impendingCollisionSimplified sind jeweils im unteren Teil der Abbildungen 3.6 und
3.7 dargestellt. Zu der Menge der Graphen, die durch das Ergebnisgraphmuster aus Abbildung
3.6 beschrieben werden, geh¨
ort auch der untere Graph aus Abbildung 3.4. Der untere Graph
aus Abbildung 3.5 geh¨
ort zu der Menge, die durch das Ergebnisgraphmuster in Abbildung 3.7
beschrieben wird.
Ein Ergebnisgraphmuster beschreibt eine Menge von Graphen, die alle inkorrekt sind, da sie
ein verbotenes Graphmuster enthalten. Da das Ergebnisgraphmuster neben dem verbotenen Gra-
phmuster auch die rechte Regelseite enth¨
alt und diese mindestens ein Element enth¨
alt, das auch
Teil des verbotenen Graphmusters ist, kann die Anwendung der entsprechenden Regel das verbo-
tene Graphmuster erzeugt haben. Um festzustellen, ob dies der Fall ist, wird die Regel r¨
uckw¨
arts
auf das Ergebnisgraphmuster angewendet. Daraus resultiert wieder ein Graphmuster, das Start-
graphmuster. F¨
ur dieses Muster muss nun ¨
uberpr¨
uft werden, ob ein beliebiges verbotenes Gra-
phmuster darauf abbildbar ist. Ist dies nicht der Fall, so wurde ein Beispiel daf¨
ur gefunden, dass
3.1. DIE IDEE 49
die angewendete Regel ein korrektes Graphmuster in ein inkorrektes Graphmuster ¨
uberf¨
uhren
kann.
F¨
ur die Graphen bedeutet dies, dass jeder korrekte Graph, auf den das Startgraphmuster ab-
gebildet werden kann, mittels der fehlerhaften Regel in einen inkorrekten Graphen transformiert
werden kann, auf den das Ergebnisgraphmuster abbildbar ist.
Der obere Teil der Abbildungen 3.6 und 3.7 zeigt die R¨
uckw¨
artsanwendung der moveSimple-
Regel auf die im unteren Teil gegebenen Ergebnisgraphmuster. Auf das Startgraphmuster aus
Abbildung 3.6 ist das verbotene Graphmuster impendingCollisionSimplified abbildbar, w¨
ahrend
das Startgraphmuster aus Abbildung 3.7 korrekt ist.
"! #
$! %&'! %(*)+,#.-/10
$&2 "! #
$ ,&23 )+(54
$+&2 +(.(*# 6 %
73 )8(84
$ "! #
+(.(*# %
! % ! %(9) ,#*-/:0
3 )+(54
"! #
$&2 "! #
$! %;&2! %(9) ,#*-/:0
$ ,&23 )8(84
$+(*(*# 6 %
73 )8(84
+(*(*# 6 %
3 )8(84
< =< =?> @BACDEF@HGJIKD
$! % ! %(*)+,#.-/10
$! % ! %(9) ,#*-/:0
! %&'! %(*)+,#.-/10
Abbildung 3.6: Start- und Ergebnisgraphmuster f¨
ur die Regel moveSimple und das verbotene
Graphmuster impendingCollisionSimplified, wobei das Startgraphmuster einem inkorrekten Gra-
phmuster entspricht
Um nachzuweisen, dass ein Graphtransformationssystem korrekt ist im Bezug auf eine Men-
ge von verbotenen Graphmustern, muss f¨
ur jede der Regeln und jedes der verbotenen Graphmus-
ter die Menge aller m¨
oglichen Ergebnisgraphmuster gebildet werden. Auf diese Ergebnisgra-
phmuster wird dann die entsprechende Regel r¨
uckw¨
arts angewendet. F¨
ur jedes dabei resultie-
rende Startgraphmuster muss gepr¨
uft werden, ob es ein verbotenes Graphmuster enth¨
alt. Gibt
es ein Startgraphmuster, das kein verbotenes Graphmuster enth¨
alt, so wurde ein Beispiel ge-
funden, das zeigt, dass die entsprechende Regel ein korrektes Graphmuster in ein inkorrektes
Graphmuster ¨
uberf¨
uhren kann. Da dieses Beispiel zeigt, dass eine Regel inkorrekt ist, wird es als
Gegenbeispiel bezeichnet. F¨
ur Graphen bedeutet ein derartiges Gegenbeispiel, dass die Regel
einen korrekten Graphen, der das Startgraphmuster enth¨
alt, durch die Anwendung der betrach-
teten Regel in einen inkorrekten Graphen ¨
uberf¨
uhrt werden kann, der das Ergebnisgraphmuster
enth¨
alt.
Wurde eine solche inkorrekte Regel gefunden, so muss sie in einem Graphtransformations-
system mit gegebenen Initialgraphen jedoch nicht zwangsl¨
aufig einen inkorrekten Zustand erzeu-
gen. Es kann sein, dass es im System keinen erreichbaren Graphen gibt, der das entsprechende
Startgraphmuster enth¨
alt. Um festzustellen, ob die Regel in einem Graphtransformationssystem
50 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
!
"$#%&
" '# !
"#%()*+-,
".-/.+0$1
1(2344,
3.-5+0$$
61/()*+-,
7 897 8;: <>=&?A@CBED3<GFIHJ@
" '# !
"$#&
"#%()*+-,
".-/.+0$1
%K/&
L / C+0M
1/(2344,
3.-.+01$
61/()*+-,
Abbildung 3.7: Start- und Ergebnisgraphmuster f¨
ur die Regel moveSimple und das verbotene
Graphmuster impendingCollisionSimplified, wobei das Startgraphmuster einem korrekten Gra-
phen entspricht
einen inkorrekten Graphen erzeugt, w¨
are eine Erreichbarkeitsanalyse erforderlich, die jedoch
aus den in Abschnitt 3.1.3 genannten Gr¨
unden nicht immer m¨
oglich ist. In diesem Fall muss die
Regel so abge¨
andert werden, dass ihre Anwendung das verbotene Graphmuster nicht erzeugen
kann. Eine solche Korrektur kann beispielsweise mittels des von Heckel und Wagner vorgestell-
ten Ansatzes vorgenommen werden (siehe [HW95] und Abschnitt 6.1).
3.1.5 Erweiterung der Idee um negative Anwendungsbedingungen
Wie im vorangegangenen Abschnitt gezeigt wurde, kann die Regel moveSimple zu einer kriti-
schen Situation und im schlechtesten Fall auch zu einem Unfall f¨
uhren. Ein Unfall tritt dann ein,
wenn die Regel auf ein Shuttle angewendet wird, obwohl auf dem Track, auf den das Shuttle
als n¨
achstes f¨
ahrt, bereits ein anderes Shuttle ist. Zu einer kritischen Situation f¨
uhrt die Regel,
wenn sich auf dem ¨
ubern¨
achsten Track ein anderes Shuttle befindet. Um zu vermeiden, dass die
Regel in einem der beiden F¨
alle angewendet wird, wird eine negative Anwendungsbedingung
verwendet.
Die negative Anwendungsbedingung wird zur linken Regelseite hinzugef¨
ugt. Die derart er-
weiterte Regel sieht dann folgendermaßen aus [L,ˆ
L]→rR, wobei ˆ
Ldie Menge der Graphen der
negativen Anwendungsbedingung ist. W¨
ahrend die linke Regelseite Lbeschreibt, wann die Re-
gel angewendet werden kann, beschreibt die negative Anwendungsbedingung ˆ
L, wann die Regel
nicht angewendet werden darf.
Eine negative Anwendungsbedingung besteht aus einer Menge von Graphen. Jeder dieser
Graphen enth¨
alt den Graphen der linken Regelseite, erweitert ihn aber um mindestens einen
Knoten oder eine Kante. Ein solcher Graph wird auch als Constraint der negativen Anwendungs-
bedingung bezeichnet. F¨
ur jeden Knoten eines Constraints gilt, dass er entweder auch zur An-
wendungsbedingung geh¨
ort oder von ihm ausgehend ¨
uber endlich viele Kanten ein Knoten aus
der Anwendungsbedingung erreicht werden kann.
3.1. DIE IDEE 51
Ein Beispiel f¨
ur eine Graphtransformationsregel mit negativer Anwendungsbedingung ist in
Abbildung 3.8 dargestellt. Die Regel stellt eine Erweiterung der Regel moveSimple dar und
heißt moveSimpleNAC. Sie beschreibt, dass ein Shuttle nur dann auf den n¨
achsten Track fahren
darf, wenn sich weder auf dem n¨
achsten, noch auf dem ¨
ubern¨
achsten Track ein anderes Shuttle
befindet. Diese Regel entspricht dem Story Pattern aus Abbildung 2.13. Der Graph ˆ
L1verhindert
die Weiterfahrt des Shuttles, wenn sich auf dem n¨
achsten Track ein anderes Shuttle befindet. ˆ
L2
verhindert die Weiterfahrt, wenn sich auf dem ¨
ubern¨
achsten Track ein anderes Shuttle befindet.
Durch diese Erweiterung der Regel soll zum einen eine Kollision von zwei Shuttles als auch die
kritische Situation impendingCollision bzw. impendingCollisionSimplified verhindert werden.
Besteht die negative Anwendungsbedingung, wie im Beispiel, aus mehreren Graphen, so
darf die Regel nur dann angewendet werden, wenn die Anwendungsbedingung auf den Anwen-
dungsgraphen abgebildet werden kann, dies jedoch f¨
ur keinen der Graphen aus der negativen
Anwendungsbedingung m¨
oglich ist.
!#"$%'&
)(*+!#"$%'&
,& +(-.& /0$1/243
(*
(5
5
,& 76.& /0$1/243
8
9;:
+!#"$%'&
)(5+!#"$%'&
,& +(-.& /0$1/243
(5
(5
<& 5.& /0$1/243
8
9>=
?(-+!#"$%'&
,& +(-.& /0$1/243
(*
(*
5
9
@
)(*+!#"$%'&
,& 5.& /0$1/243
(*
(-
A BDC#E;FHGJIBLK>MNFPORQTS
Abbildung 3.8: Graphtransformationsregel moveSimpleNAC mit negativer Anwendungsbedin-
gung
52 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
Soll eine Regel mit negativer Anwendungsbedingung r¨
uckw¨
arts angewendet werden, so muss
die negative Anwendungsbedingung zun¨
achst angepasst werden, da anderenfalls die Nachbedin-
gung der Regel eine negative Anwendungsbedingung h¨
atte, wof¨
ur jedoch keine Semantik defi-
niert ist. Die Anwendung einer Regel in R¨
uckw¨
artsrichtung entspricht dem R¨
uckg¨
angigmachen
ihrer Anwendung in Vorw¨
artsrichtung. Wird die negative Anwendungsbedingung nicht transfor-
miert, so kann bei der R¨
uckw¨
artsanwendung einer Regel ein Graph resultieren, auf den die Regel
in Vorw¨
artsrichtung auf Grund der negativen Anwendungsbedingung nicht anwendbar ist.
Um die negative Anwendungsbedingung einer Regel [L,ˆ
L]→rRanzupassen, wird sie
zun¨
achst aus der linken Regelseite entfernt. Dann wird die derart reduzierte Regel L→r0Rauf
alle Graphen aus der negativen Anwendungsbedingung, also auf alle Graphen aus ˆ
L, angewen-
det. Da die Graphen der negativen Anwendungsbedingung immer den Graphen enthalten, der
die linke Regelseite beschreibt, existiert auch immer eine Anwendungsstelle f¨
ur die Regel. Die
resultierenden Graphen werden als negative Anwendungsbedingung zur rechten Regelseite hin-
zugef¨
ugt. Die konvertierte Regel hat dann die Form [L−1,ˆ
L−1]→r−1R−1.
Abbildung 3.9 zeigt die modifizierte Regel aus Abbildung 3.8. Dabei entspricht L−1der ur-
spr¨
unglichen rechten Regelseite Rund ˆ
L−1
1und ˆ
L−1
2stellen die transformierte negative Anwen-
dungsbedingung dar. R−1entspricht der urspr¨
unglichen linken Regelseite L.
Neben den Anwendungsbedingungen der Graphtransformationsregeln k¨
onnen auch die ver-
botenen Graphmuster um negative Anwendungsbedingungen erweitert werden.
Ein Beispiel f¨
ur ein verbotenes Graphmuster mit negativer Anwendungsbedingung ist in
Abbildung 3.10 gegeben. Dieses verbotene Graphmuster beschreibt eine kritische Situati-
on, bei der zwei Shuttles auf benachbarten Tracks fahren, jedoch das DistanceCoordination-
Koordinationsmuster nicht ausf¨
uhren; in diesem Fall droht eine Kollision der beiden Shuttles.
Eine solche kritische Situation ist eingetreten, d.h. ein Anwendungsgraph ist inkorrekt im
Bezug auf dieses verbotene Graphmuster, wenn die Anwendungsbedingung des verbotenen Gra-
phmusters auf ihn abgebildet werden kann, dies jedoch f¨
ur keinen Graphen der negativen An-
wendungsbedingung gilt.
Abbildung 3.11(a) zeigt einen inkorrekten Graphen, denn die Anwendungsbedingung der
kritischen Situation kann auf diesen Graphen abgebildet werden (diese Abbildung ist rot dar-
gestellt), der Graph der negativen Anwendungsbedingung aber nicht, da zwischen dem Shuttle
vs1und dem Shuttle vs2kein DistanceCoordination-Muster existiert. Im Gegensatz dazu ist der
Graph in Abbildung 3.11(b) korrekt. Zwar kann auch auf diesen Graphen die Anwendungsbe-
dingung des verbotenen Graphmusters abgebildet werden, jedoch koordinieren sich die beiden
Shuttles¨
uber das DistanceCoordination-Muster, d.h. auch der Knoten, der das DistanceCoordi-
nation-Muster im Graphen der negativen Anwendungsbedingung darstellt, kann auf den Anwen-
dungsgraphen abgebildet werden.
Enth¨
alt das verbotene Graphmuster eine negative Anwendungsbedingung, so kann die An-
wendung einer Graphtransformationsregel auf zwei Arten einen korrekten Graphen in einen in-
korrekten ¨
uberf¨
uhren. Zum einen kann sie ein Element erzeugen, auf das ein Teil der Anwen-
dungsbedingung des verbotenen Graphmusters abbildbar ist. Dieser Fall ist identisch dazu, dass
eine Regel ohne negative Anwendungsbedingung ein verbotenes Graphmuster erzeugt. Der zwei-
te Fall besteht darin, dass auf den Anwendungsgraph die Anwendungsbedingung eines verbote-
nen Graphmusters abgebildet werden kann und dies ebenfalls f¨
ur einen Graphen der negativen
3.1. DIE IDEE 53
"!# $&%'(*)
+
"!, $-%'(*) ./10
2) !#3) 457698
!#
!,
: ;=<->@?4ACB;EDGFH?JI9KML
/10
N
!
!,
"!# $&%'(*)
O
/10
P
O
/10
0
2) +3) 457698
$-%'(*)
N
"! $-%'(*)
2) Q3) 457698
!#
!#
P
O
/10
R
$-%'(*)
N
!
!,
2) +3) 457698
2) QS3) 7T'576U8
2) Q3) 457698
Abbildung 3.9: Konvertierung der Regel moveSimpleNAC in die Regel moveSimpleNAC−1, so-
dass sie r¨
uckw¨
arts angewendet werden kann
!#" $&%
'()##*+
,-.
,- !#" $&%
/10
2,34 5
/10
"6798 +%:#;
0
<=">8?%:@8 >%
A=#B4>
2,-
+
.,-.=::
,- !#" $&%
3 <#*" $C%
'()##*+
DED=>%'B4>
Abbildung 3.10: Verbotenes Graphmuster impendingCollision mit negativer Anwendungsbedin-
gung
Anwendungsbedingung gilt. Wird nun durch die Regelanwendung ein Element gel¨
oscht, auf das
ein Element des Graphen der negativen Anwendungsbedingung, jedoch nicht der Anwendungs-
bedingung, abgebildet werden kann, so ist das verbotene Graphmuster Teil des resultierenden
Graphen und dieser ist somit inkorrekt.
54 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
! "
!#
$%
#$%
&
(')*,+!.-
&
- '/0- 124365
&
'7
&
')
&
&
- 0- 124365
&
*,+!.-
(a) Graph, der in Bezug auf das verbotene Graphmuster im-
pendingCollision inkorrekt ist
!
"# %$&')(%*+
,-./$10 '!.2$0
'34.2/$10
536$7$))
8!.2$0
9!.2/$10
9!5$)$)7,
4# :$)'7(%*;
5!5$)$7) ,
8!$7$)7,
1-<5$)$)7,
($=?>A@ $)1B
C
%(@D@
EF:&:
(b) Graph, der in Bezug auf das verbotene Graphmuster im-
pendingCollision korrekt ist
Abbildung 3.11: Graphen, die in Bezug auf das verbotene Graphmuster impendingCollision in-
korrekt bzw. korrekt sind
Die Anwendung der Regel deleteDCSwitch, in Abbildung 3.12 dargestellt, erzeugt auf diese
Weise aus einem korrekten Graphen einen inkorrekten. Sie l¨
oscht eine Instanz des DistanceCoor-
dination-Musters zwischen zwei Shuttles, falls das vordere Shuttle an einer Weiche einen anderen
Weg f¨
ahrt, als das hintere Shuttle fahren m¨
ochte (dargestellt durch die next-Kante). Der Graph
3.1. DIE IDEE 55
bzw. das Graphmuster auf der linken Regelseite ist korrekt, die Anwendung der Regel l¨
oscht
jedoch das DistanceCoordination-Muster und erzeugt so einen inkorrekten Graphen bzw. ein in-
korrektes Graphmuster, dargestellt im unteren Teil der Abbildung.
!"$#
! $"#
%&'(
*) #+) #,-. /,01
"+
*) #23) #,-. /,01
432576.89)
$2576.89)
:8':8#;.<7#=)
/>@?BA $$ C
D
#,#/=AEFA #=
*G-H<7#=)
I JLK7MNK2O KQPSR+T'UWVNO X7Y
&(
Z9
+ !"$#
[! $$#2
%+
) #[&) #; !/,0\
"&2576.89)
"(
*) #23) #,-. /,01
42576.89)
<
Abbildung 3.12: Regel deleteDCSwitch, die eine Instanz des DistanceCoordination-Musters
l¨
oscht
F¨
ur diesen zweiten Fall muss eine zus¨
atzliche ¨
Uberpr¨
ufung eingef¨
ugt werden. Die Graphen
der negativen Anwendungsbedingung des verbotenen Musters haben die Eigenschaft, dass je-
der ihrer Knoten entweder auch zur Anwendungsbedingung geh¨
ort oder ausgehend von diesem
Knoten ¨
uber eine endliche Menge von Kanten ein Knoten der Anwendungsbedingung erreicht
werden kann.
Im obigen Beispiel wird der Knoten rdc :DistanceCoordination gel¨
oscht. Durch das L¨
oschen
von rdc kann der Graph ˆ
IC der negativen Anwendungsbedingung des verbotenen Musters im-
pendingCollision nicht mehr auf den resultierenden Graphen abgebildet werden. Der Knoten
rdc :DistanceCoordination besitzt zwei Kanten; eine beschriftet mit rrr :rearRole zum Knoten
rs1:Shuttle und eine zweite beschriftet mit rfr :frontRole zum Knoten rs2:Shuttle. Auf diese
beiden Knoten k¨
onnen die Shuttle-Knoten der Anwendungsbedingung des verbotenen Musters
abgebildet werden.
Das bedeutet, wenn ein Knoten gel¨
oscht werden soll, auf den ein Knoten eines Graphen der
negativen Anwendungsbedingung abgebildet werden kann, aber keines der Anwendungsbedin-
gung, dann muss dieser Knoten mindestens eine inzidente Kante haben, die ebenfalls gel¨
oscht
56 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
werden muss. Um eine Kante l¨
oschen zu k¨
onnen, muss sie mit beiden zu ihr inzidenten Knoten in
der linken Regelseite enthalten sein. Wird der zweite inzidente Knoten ebenfalls gel¨
oscht, so gilt
auch hier wieder, dass alle inzidenten Kanten durch die Regel entfernt werden m¨
ussen. Es muss
allerdings eine Kante geben, die inzident zu einem Knoten ist, der explizit durch die Regel er-
halten bleibt, da die Anwendungsbedingung des verbotenen Musters durch die Regelanwendung
nicht ver¨
andert wird.
Im obigen Beispiel hat der zu l¨
oschende Knoten rdc zwei inzidente Kanten, rrr und rfr. So-
wohl der zweite zu rrr inzidente Knoten rs1als auch der zweite zu rfr inzidente Knoten rs2werden
durch die Regel explizit erhalten. Daher sind beide Knoten Teil sowohl der linken als auch der
rechten Regelseite, sie sind aber auch Teil des verbotenen Graphmusters.
Diese Tatsache kann genutzt werden, um auch f¨
ur das L¨
oschen von Elementen Ergebnisgra-
phmuster zu bilden. Ein solches Ergebnisgraphmuster enth¨
alt mindestens einen Knoten, der in
beiden Regelseiten und in einem Graphen der negativen Anwendungsbedingung des verbotenen
Graphmusters enthalten ist.
Abbildung 3.13 zeigt ein m¨
ogliches Ergebnisgraphmuster. Das daraus erzeugte Startgra-
phmuster f¨
ur das verbotene Graphmuster aus Abbildung 3.10 und die Graphtransformationsregel
deleteDCSwitch ist in Abbildung 3.14 abgebildet. Die beiden Graphmuster stellen ein Gegenbei-
spiel dar, das zeigt, dass die Regel deleteDCSwitch einen korrekten Graphen in einen inkorrekten
¨
uberf¨
uhren kann. Die Anwendung der Regel f¨
uhrt genau dann dazu, dass ein korrekter Graph in
einen inkorrekten ¨
uberf¨
uhrt wird, wenn der korrekte Graph, das Startgraphmuster des Gegenbei-
spiels enth¨
alt und die entsprechende Regel auf diesen Teil des Graphen angewendet wird.
3.2 Graphtransformationssysteme
In diesem und den folgenden Abschnitten soll die zuvor informal dargestellte Idee formalisiert
werden.
Der Zustand der Software eines mechatronischen Systems ist charakterisiert durch die exis-
tierenden Objekte und deren Links. Eine solche Instanzsituation wird in einem Objektdiagramm
festgehalten. In diesem Kapitel werden statt der Objektdiagramme Graphen verwendet, so-
dass ein Systemzustand durch diesen Graphen repr¨
asentiert wird. Die ¨
Uberg¨
ange zwischen den
Zust¨
anden werden durch Graphtransformationsregeln beschrieben.
Im Folgenden wird als erstes ein ¨
Uberblick ¨
uber die grundlegende Terminologie gegeben.
Ein Teil der aufgef¨
uhrten Definitionen wurden aus anderen Texten, zumeist dem ”Handbook of
Graphgrammars“[Roz97], ¨
ubernommen. Dazu geh¨
oren die Definitionen von (beschrifteten) Gra-
phen (Definitionen 1 und 2), Graphhomomorphismen und Graphisomorphismen (Definitionen 9
und 10), die Definition eines Matches (Definition 13) und die Definition eines Graphtransforma-
tionssystems (Definition 17).
Weitere Definitionen wie die der Graphtransformationsregeln (Definition 12), der direkten
Transformation (Definition 14), der negativen Anwendungsbedingung (Definition 15) und des
Double Pushout Ansatzes (Definitition 26) wurden im Vergleich zu den Definitionen in der Lite-
ratur vereinfacht bzw. die in den Definitionen verwendeten Graphen und Funktionen unterliegen
st¨
arkeren Einschr¨
ankungen. Durch die Vereinfachungen und Einschr¨
ankungen wird der Verifi-
3.2. GRAPHTRANSFORMATIONSSYSTEME 57
"! #
%$&'$#"()
*+,))
* "! #
-
.
/%'#02134! #
5+ "! #
%$&4$#"()
67,))
889:#9*;3
<! 3+'! 3=0#:>=?@$
*
A7,))
/>BDCFEG;$9#IH
J
3=3>4EK$)5EG34$
<! 3LA'! 3=0#:>=?@$
7;7 "! #
<! 3+'! 3=0#:>=?@$
,MM:9#:;*3
M&M::#9*;3
<! 3LA'! 3=0#:>=?@$
7M&M:9#:;*3
/N O N,3P$8134! #
Abbildung 3.13: Ergebnisgraphmuster mit negativer Anwendungsbedingung
kationsansatz in Abschnitt 3.6 erm¨
oglicht. Wurde eine Definition aus der Literatur ¨
ubernommen
und f¨
ur die vorliegende Arbeit angepasst, so wird im Folgenden auch der Unterschied zur ur-
spr¨
unglichen Definition genannt.
F¨
ur den Verifikationsansatz in Abschnitt 3.6 ist es wichtig, dass eine Graphtransformations-
regel auch r¨
uckw¨
arts angewendet werden kann. Wird zur Anwendung einer Graphtransforma-
tionsregel der Double Pushout Ansatz angewendet, so ist dies immer m¨
oglich (siehe [Roz97]
Kapitel 3). In dieser Arbeit wird zwar eine eingeschr¨
ankte Form des Double Pushout Ansatzes
verwendet, jedoch sind f¨
ur die linke Regelseite auch negative Anwendungsbedingungen erlaubt.
Die Modifikation einer Regel, um diese korrekt r¨
uckw¨
arts anwenden zu k¨
onnen, wird in dieser
Arbeit in Definition 29 gegeben.
Um bei der Verifikation Aussagen ¨
uber Mengen von Graphen machen zu k¨
onnen und struk-
turelle Eigenschaften von Graphen beschreiben zu k¨
onnen, werden in dieser Arbeit Graphmuster
eingef¨
uhrt (Definition 19) und die Anwendung von Graphtransformationsregeln auf diese Muster
definiert (Definition 30). Die Graphmuster sind ¨
ahnlich zu den Eigenschaftsgraphen von Rensink
(siehe dazu auch Abschnitt 3.6) und den Konsistenzbedingungen, die zum Beispiel von Heckel
und Wagner in [HW95] verwendet werden (ein Vergleich zwischen Graphmustern und Konsis-
tenztbedingungen wird in Abschnitt 6.1 gegeben). Allerdings werden weder Eigenschaftsgra-
phen noch Konsistenzbedingungen dazu verwendet, um Mengen von Graphen zu beschreiben.
58 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
"!#$%'&() $
*+!-,. /00*1$32
4
5!
4
6&() $
7 5!#$%'&() $
*+!-,./80*9$:2
4
"!
4
6&) $
;
/<=! (>? '@) $
;
) <=!#) *%8$1AB
;
C<D!E5F*3G
;
8HI!E5*G
;
/0HI! (>? '@) $
;
) :HJ!#) *18$9AK
/ ?<L!M/ ?*1*9$1/0/C
7N!$@O
P8HI!E5*G
Q*+!#,./80*1$:2
7 "!#$%'&() $
4
"!
4
6&) $
;
/R<D! (>? '@) $
;
) <=!#) *%8$1AB
;
C<D!E5F*3G
;
8HI!E"F*3G
;
) MHJ!#) *18$9AK
;
/0HI! >? '@) $
7N!$@O
/ ?<L!:/ ?*9*1$1/0/0
8HI!E"F*3G
/
;
?!M/ ?*1*1$9/C/0
;
/?!M/ ?*1*9$1/0/C
Abbildung 3.14: Startgraphmuster mit negativer Anwendungsbedingung
Abschnitt 3.2.1 gibt eine allgemeine Definition f¨
ur Graphen und einen ¨
Uberblick ¨
uber die
wichtigsten Operationen auf Graphen. Graphtransformationsregeln werden in Abschnitt 3.2.2
erl¨
autert. In Abschnitt 3.3 werden Graphmuster eingef¨
uhrt, mit denen Mengen von Graphen be-
schrieben werden k¨
onnen. Mit den eingef¨
uhrten Konstrukten kann dann das Systemmodell be-
schrieben werden (Abschnitt 3.4). Zur Verifikation ist es notwendig, die Graphtransformations-
regeln auch r¨
uckw¨
arts und auf Graphmuster anwenden zu k¨
onnen. Deshalb erfolgt in Abschnitt
3.5 eine Erweiterung der Graphtransformationen. Abschnitt 3.6 besch¨
aftigt sich mit strukturellen
Eigenschaften eines Graphen.
Die Beweise der hier aufgef¨
uhrten Lemmata und Theoreme sind im Anhang B skizziert.
3.2.1 Graphen und grundlegende Operationen darauf
Nach Rozenberg [Roz97] besteht ein Graph aus endlich vielen Knoten, die durch Kanten ver-
bunden werden. Jede Kante hat einen Start- und einen Zielknoten. Durch die Festlegung des
Start- bzw. Zielknotens wird auch gleichzeitig die Richtung einer Kante festgelegt. Formal ist
ein solcher Graph definiert als:
3.2. GRAPHTRANSFORMATIONSSYSTEME 59
Definition 1. (Graph)
Ein Graph ist ein Tupel G= (N,E,src,tgt), wobei
•Neine endliche Knotenmenge ist,
•Eeine endliche Kantenmenge ist,
•src :E7→ Neine Funktion ist, die jeder Kante einen Startknoten zuweist und
•tgt :E7→ Neine Funktion ist, die jeder Kante einen Zielknoten zuweist.
Um die Knoten und Kanten benennen und unterscheidbar machen zu k¨
onnen, werden zwei
Alphabete eingef¨
uhrt. Eines der Alphabete legt m¨
ogliche Beschriftungen f¨
ur Knoten fest und
das andere Beschriftungen f¨
ur Kanten. Mittels zweier Beschriftungsfunktionen (engl. labeling
function) k¨
onnen den Knoten und Kanten dann Beschriftungen zugewiesen werden. Die formale
Definition f¨
ur einen solchen beschrifteten Graphen entspricht der aus [Roz97] und lautet
Definition 2. (Beschrifteter Graph)
Gegeben sind zwei Alphabete ΩNund ΩE, f¨
ur Knoten- bzw. Kantenbeschriftungen. Ein be-
schrifteter Graph (engl. labeled graph) ist ein Tupel G= (N,E,src,tgt,lN,lE), mit
•(N,E,src,tgt)ist ein Graph wie in Definition 1,
•lN:N7→ ΩNist eine Funktion zur Beschriftung von Knoten und
•lE:E7→ ΩEist eine Funktion zur Beschriftung von Kanten.
Dabei sind NG,EG,srcGund tgtGwie in Definition 1 definiert. Die Funktionen lNGund lEG
stellen knoten- bzw. kantenbeschriftende Funktionen dar. G∅ist der leere Graph f¨
ur den gilt
NG∅=EG∅=∅.Gist die Menge aller Graphen.
In Abbildung 3.15 ist ein Beispiel f¨
ur einen beschrifteten Graphen
G:= (N,E,src,tgt,lN,lE)gegeben1. Die vier Knoten an1,. . . ,an4bilden die Knotenmen-
ge N:={an1,an2,an3,an4},ae1,. . . ,ae4bilden die Kantenmenge E:={ae1,ae2,ae3,ae4}.
Die Funktion src weist jeder der Kanten aus Eeinen Startknoten zu. Bei-
spielsweise ist an1der Startknoten von Kante ae1,src ist gegeben durch
src :={(ae17→ an1),(ae27→ an2),(ae37→ an3),(ae47→ an4)}. Dementsprechend weist tgt
den Kanten einen Zielknoten zu tgt :={(ae17→ an2),(ae27→ an3),(ae37→ an4),(ae47→ an2)}.
Zur Beschriftung der Knoten steht das Alphabet ΩN:={Shuttle,Track}zur Verf¨
ugung,
die Kanten k¨
onnen mit ΩE:={locatedOn,successor}beschriftet werden. Die Be-
schriftungsfunktion lNweist jedem Knoten aus der Menge Neine Beschriftung aus
ΩNzu, lN:={(an17→ Shuttle),(an27→ Track),(an37→ Track),(an47→ Track)}. Genau-
so weist auch die Funktion lEjeder Kante aus Eeine Beschriftung aus ΩEzu,
lE:={(ae17→ locatedOn),(ae27→ successor),(ae37→ successor),(ae47→ successor)}.
1Um die Knoten und Kanten des Graphen referenzieren zu k¨
onnen sind sie mit an1, . . . , an4bzw. ae1, . . . , ae4
nummeriert.
60 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
!
"#
!
"#
$&%
'
!
"#
Abbildung 3.15: Beispiel f¨
ur einen beschrifteten Graphen
Teilgraphbeziehungen und Graphoperationen
F¨
ur zwei gegebene Graphen G1und G2kann bestimmt werden, ob die beiden Graphen identisch
sind oder einer der beiden Graphen Teilgraph des anderen ist. Die folgenden Definitionen sind
jeweils f¨
ur beschriftete Graphen angegeben; bei unbeschrifteten Graphen k¨
onnen die f¨
ur die
Beschriftungsfunktionen angegebenen Bedingungen ignoriert werden.
Die beiden Graphen G1und G2sind identisch, wenn ihre Knoten- und Kantenmengen iden-
tisch sind, gleiche Kanten auch die gleichen Start- und Zielknoten haben und die Funktionen
zur Knoten- und Kantenbeschriftung gleichen Knoten bzw. Kanten die gleichen Beschriftungen
zuweisen.
Definition 3. (Identische Graphen)
Zwei Graphen G1,G2∈ G sind identisch, wenn gilt:
•NG1=NG2,
•EG1=EG2,
•srcG1=srcG2,
•tgtG1=tgtG2,
•lNG1=lNG2und
•lEG1=lEG2.
Der Graph G1ist ein Teilgraph von G2, wenn die Knoten- und Kantenmengen von G1Teil-
mengen der Mengen von G2sind und die Funktionen zur Bestimmung des Start- und Zielknoten
einer Kante sowie die beiden Beschriftungsfunktionen eingeschr¨
ankt auf die Knoten und Kanten
aus G1identisch sind.
Definition 4. (Teilgraph)
F¨
ur zwei Graphen TG,G∈ G gilt, dass TG ein Teilgraph von Gist, geschrieben TG ≤G,
falls gilt
•NTG ⊆NG,
•ETG ⊆EG,
•srcTG =srcG|ETG ,
•tgtTG =tgtG|ETG ,
3.2. GRAPHTRANSFORMATIONSSYSTEME 61
•lNTG =lNG|NTG und
•lETG =lEG|ETG .
F¨
ur zwei Graphen TG,G∈ G gilt, dass TG ein echter Teilgraph von Gist (geschrie-
ben TG <G), wenn Gmindestens einen Knoten oder eine Kante mehr besitzt als TG,
d.h. TG ≤G∧(|NTG|<|NG|∨|ETG|<|EG|).
F¨
ur zwei gegebene Graphen kann nicht nur bestimmt werden, ob sie identisch sind oder in
einer Teilgraphbeziehung zueinander stehen, sondern sie k¨
onnen auch dazu verwendet werden,
einenneuen Graphen zu beschreiben. Dazuist es jedocherforderlich, dass f¨
urdie beiden Graphen
dieselben Alphabete zur Beschriftung der Knoten und der Kanten verwendet werden. In diesem
Fall werden die beiden Graphen als beschriftungskompatibel bezeichnet.
Die Vereinigung bietet eine M¨
oglichkeit, aus zwei beschriftungskompatiblen Graphen G1und
G2einen neuen Graphen zu erzeugen. Dazu werden die Knoten- und Kantenmengen zu einer
Knoten- bzw. Kantenmenge vereinigt. Die Funktionen src,tgt,lNund lEdes neuen Graphen
entsprechen f¨
ur Knoten und Kanten, die in G1enthalten sind, den Funktionen von G1und f¨
ur alle
Knoten und Kanten, die nur in G2, nicht aber in G1auftreten, den Funktionen aus G2.
Definition 5. (Vereinigung von Graphen)
Die Vereinigung von zwei beschriftungskompatiblen Graphen G1,G2∈ G ist definiert als
G1∪G2:= (N0,E0,src0,tgt0,l0
N,l0
E)mit
•N0:= NG1∪NG2,
•E0:= EG1∪EG2,
•src0:= srcG1⊕srcG2|(EG2\EG1),
•tgt0:= tgtG1⊕tgtG2|(EG2\EG1),
•l0
N:= lNG1⊕lNG2|(NG2\NG1)und
•l0
E:= lEG1⊕lEG2|(EG2\EG1).
Es gilt (G1∪G2) = (G2∪G1).
F¨
ur zwei Mengen X1und X2sowie zwei Funktionen f1und f2ist ⊕folgendermaßen definiert:
f1⊕f2|(X2\X1)(x) := f1(x) : x∈X1
f2(x) : x∈X2\X1
¨
Ahnlich dazu kann auch durch den Schnitt von G1und G2ein neuer Graph erzeugt werden.
In diesem Fall werden die Knoten- und Kantenmengen geschnitten und die Funktionen src,tgt,
lNund lEdes neuen Graphen entsprechen den Funktionen aus G1, wobei diese auf die Knoten
und die Kanten aus dem Schnitt eingeschr¨
ankt werden.
Definition 6. (Schnitt von Graphen)
Der Schnitt von zwei beschriftungskompatiblen Graphen G1,G2∈ G ist definiert als
G1∩G2:= (N0,E0,src0,tgt0,l0
N,l0
E)mit
•N0:= NG1∩NG2,
62 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
•E0:= EG1∩EG2,
•src0:= srcG1|E0,
•tgt0:= tgtG1|E0,
•l0
N:= lNG1|N0und
•l0
E:= lEG1|E0.
Es gilt (G1∩G2) = (G2∩G1).
Aus den beiden beschriftungskompatiblen Graphen G1und G2kann auch durch Subtraktion
ein neuer Graph gebildet werden. Bei den Knoten wird die Knotenmenge von G2von der Kno-
tenmenge von G1abgezogen. W¨
urde die neue Kantenmenge auf die gleiche Weise berechnet,
so k¨
onnten in der neuen Kantenmenge Kanten enthalten sein, die keinen Start- oder Zielknoten
besitzen. Dies ist genau dann der Fall, wenn der Start- oder Zielknoten in beiden urspr¨
unglichen
Graphen enthalten ist, die entsprechende Kante aber nur in G1. Damit der neue Graph der Defini-
tion eines Graphen (siehe Definitionen 1 und 2) entspricht, m¨
ussen diese Kanten aus der Menge
entfernt werden. Die Funktionen src,tgt,lNund lEdes neuen Graphen werden vom Graph G1
¨
ubernommen und auf die neue Knoten- und Kantenmenge eingeschr¨
ankt.
Definition 7. (Subtraktion von Graphen)
Die Subtraktion von zwei beschriftungskompatiblen Graphen G1,G2∈ G ist definiert als
G1\G2:= (N0,E0,src0,tgt0,l0
N,l0
E)mit
•N0:= NG1\NG2,
•E0:= {e∈(EG1\EG2)|(srcG1(e)∈N0∧tgtG1(e)∈N0)},
•src0:= srcG1|E0,
•tgt0:= tgtG1|E0,
•l0
N:= lNG1|N0und
•l0
E:= lNG1|E0.
Im Allgemeinen gilt (G1\G2)6= (G2\G1).
In sp¨
ateren Definitionen und S¨
atzen wird verlangt, dass zwischen zwei bestimmten Knoten
eines Graphen ein Pfad existiert. Dabei besteht ein Pfad aus einer Menge von Knoten, die durch
eine Menge von Kanten verbunden sind. Beginnt man beim Startknoten des Pfades und folgt den
Kanten, ohne deren Richtung zu ber¨
ucksichtigen, so gelangt man zum Zielknoten.
Definition 8. (Pfad)
F¨
ur einen gegebenen Graphen Gist ein Pfad definiert als eine endlich Sequenz π∈N∗
Gmit
der L¨
ange k, wobei π=n1,n2,...,nk∈NGund f¨
ur alle i∈1,...,k−1existiert ein ei∈EG
mit (src(ei) = ni∧tgt(ei) = ni+1)∨(tgt(ei) = ni∧src(ei) = ni+1). Ein Pfad, der am Knoten n1
beginnt und im Knoten nkendet, wird mit n17→πnkbeschrieben. Die L¨
ange eines Pfades πwird
als length(π) : N∗
G7→ IN bezeichnet und entspricht length(π) :=|Eπ|,Eπstellt die Kantenmenge
des Pfades πdar.
3.2. GRAPHTRANSFORMATIONSSYSTEME 63
Matching von beschrifteten Graphen
Nicht immer ist es f¨
ur eine Operation erforderlich, dass die beiden beteiligten Graphen iden-
tisch sind oder der eine Graph ein Teilgraph des anderen ist. Oft reicht es aus, wenn die beiden
Graphen strukturgleich sind. Eine solche Strukturgleichheit wird durch einen totalen Graphho-
momorphismus, wie in [Roz97] definiert, beschrieben.
Definition 9. (Totaler Graphhomomorphismus)
F¨
ur zwei gegebene Graphen G1,G2∈ G wird der totale Graphhomomorphismus
m:G17→ G2beschrieben durch ein Funktionenpaar m:= hmN:NG17→ NG2,mE:EG17→ EG2i.
Dieser Graphhomomorphismus erh¨
alt Start- und Zielknoten von Kanten sowie die Beschrif-
tungen der Knoten und Kanten, d.h. es gilt mN◦srcG1=srcG2◦mE,mN◦tgtG1=tgtG2◦mE,
lNG2◦mN=lNG1und lEG2◦mE=lEG1.
F¨
ur zwei Funktionen fund gbeschreibt ◦ihre Hintereinanderausf¨
uhrung, wobei gilt
g◦f(x) = g(f(x)).
F¨
ur zwei Graphen G1,G2∈ G bezeichnet die Menge M[G1,G2]die Menge aller Graphho-
momorphismen zwischen G1und G2, d.h. G1,G2∈ G :M[G1,G2] := {m|m:G17→ G2}. Wenn
aus dem Kontext hervorgeht, zwischen welchen Graphen die Graphhomomorphismen existieren,
wird abk¨
urzend Mverwendet.
Abbildung 3.16 zeigt einen beschrifteten Graphen G0:= (N0,E0,src0,tgt0,l0
N,l0
E), bestehend aus
der Knotenmenge N0:= {rn0
a,rn0
b,rn0
c}, der Kantenmenge E0:= {re0
a,re0
b}, und den Funktionen
src0:= {(re0
a7→ rn0
a),(re0
b7→ rn0
b)},tgt0:= {(re0
a7→ rn0
b),(re0
b7→ rn0
c)},l0
N0:= {(rn0
a7→ Shuttle),
(rn0
27→ Track),(rn0
37→ Track)}und l0
E0:= {(re0
a7→ locatedOn),(re0
b7→ successor)}. Ein Bei-
spiel f¨
ur einen Graphhomomorphismus m∈ M[G0,G]zwischen G0und dem Graphen G
aus Abbildung 3.15 ist m:= hmN,mEi. Die Funktionen mNund mEsind definiert als
mN:= {(rn0
a7→ an1),(rn0
b7→ an2),(rn0
c7→ an3)}und mE:= {(re0
a7→ ae1),(re0
b7→ ae2)}. Be-
trachtet man zum Beispiel den Knoten rn0
bund die Kante re0
aaus G0so gilt: mN(src0
G0(re0
a)) =
mN(rn0
a) = an1=srcG(ae1) = srcG(mE(re0
a)),mN(tgt0
G0(re0
a)) = mN(rn0
b) = an2=tgt(ae1) =
tgt(mE(re0a)),lNG(mN(rn0
b)) = lNG(an2) = Track =l0
NG0(rn0
b)und lEG(mE(re0
a)) = lEG(ae1) =
locatedOn =l0
EG0(aea).
!
!
"
"
#
Abbildung 3.16: Graph G0, f¨
ur den ein Graphhomomorphismus in Graph Gaus Abbildung 3.15
bestimmt werden soll
Ein totaler Graphhomomorphismus m:G17→ G2bildet alle Knoten und Kanten aus G1auf
Knoten und Kanten aus G2ab. Dabei muss jedoch nicht auf jeden Knoten und jede Kante aus G2
ein Knoten oder eine Kante aus G1abgebildet werden. Dar¨
uber hinaus ist es m¨
oglich, dass zwei
oder mehr Knoten oder Kanten aus G1auf den gleichen Knoten oder die gleiche Kante aus G2
64 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
abgebildet werden. Soll dies verhindert werden, so muss man statt des Graphhomomorphismus
einen Graphisomorphismus verwenden.
Definition 10. (Graphisomorphismus)
Ein Graphisomorphismus iso ist ein totaler Graphhomomorphismus f¨
ur den gilt, dass die
beiden Funktionen mNund mEbijektiv sind.
Im Folgenden wird f¨
ur zwei Graphen G1,G2∈ G und einen Graphisomorphismus
iso :G17→ G2die Kurzschreibweise G1≈iso G2verwendet. Existiert f¨
ur die beiden Graphen ein
beliebiger Graphisomorphismus, der jedoch nicht n¨
aher spezifiziert werden soll, so wird daf¨
ur
G1≈G2verwendet.
F¨
ur zwei Graphen G1,G2∈ G bezeichnet die Menge ISO[G1,G2]die Menge aller Gra-
phisomorphismen zwischen G1und G2, d.h. G1,G2∈ G :ISO[G1,G2] := {iso |iso ∈ M ∧
iso bijektiv}.
Bildet der Graphisomorphismus iso den Graphen G1auf einen Teilgraphen SG ∈ G von G2
ab (SG ≤G2), so wird iso als Teilgraphisomorphismus bezeichnet.
Definition 11. (Teilgraphisomorphismus)
F¨
ur drei Graphen G1,G2,TG2∈ G mit TG2≤G2stellt ein Isomorphismus
iso ∈ ISO[G1,TG2]einen Teilgraphisomorphismus zwischen G1und G2dar.
F¨
ur zwei Graphen G1,G2∈ G bezeichnet die Menge T ISO[G1,G2]die Menge al-
ler Teilgraphisomorphismen, d.h. T ISO[G1,G2] := {tiso | ∃TG2∈ G :TG2≤G2∧
tiso ∈ ISO[G1,TG2]}.
Existiert f¨
ur zwei Graphen G1,G2∈ G ein Teilgraphisomorphismus tiso ∈ T ISO[G1,G2]so
wird dies kurz notiert als G1tiso G2oder G1G2.
3.2.2 Graphtransformationen
Mit den im vorangegangenen Abschnitt eingef¨
uhrten Operationen ist es m¨
oglich, Graphen zu
transformieren, indem Knoten und Kanten aus einem existierenden Graphen gel¨
oscht bzw. neue
Knotenund Kanten eingef¨
ugtwerden. Zur Beschreibung einer solchenGraphtransformation wer-
den Graphtransformationsregeln verwendet.
Definition 12. (Graphtransformationsregel)
Eine Graphtransformationsregel L→rRbesteht aus
•dem Regelnamen r,
•einem Graphen L∈ G, der als linke Regelseite bezeichnet wird und
•einem Graphen R∈ G, der als rechte Regelseite bezeichnet wird.
F¨
ur die beiden Graphen Lund Rgilt ∃TL ∈ G :TL ≤L∧TL ≤R∧TL 6=G∅.
Die linke Regelseite einer Graphtransformationsregel beschreibt, wann die Regel angewendet
werden darf, und wird deshalb auch als Vor- oder Anwendungsbedingung bezeichnet. Die rechte
3.2. GRAPHTRANSFORMATIONSSYSTEME 65
Regelseite beschreibt die Nachbedingung der Regel. Beide Regelseiten zusammen beschreiben,
wann die Regel angewendet werden kann und welche ¨
Anderungen gemacht werden sollen.
Dabei stellt die Definition 12 der Graphtransformationsregeln eine Vereinfachung der
in [Roz97] eingef¨
uhrten Definition dar. Nach Rozenberg wird eine Regel gegeben durch
r:L→mR, wobei rder Regelname ist, Ldie linke und Rdie rechte Regelseiten sind. mist ein
Graphhomomorphismus, der einen Teilgraphen von Lauf Rabbildet. Diese Homomorphismus
wurde in der Definition 12 durch eine Teilgraphbeziehung ersetzt.
Eine Graphtransformationsregel kann auf einen existierenden Graphen, den so genannten
Anwendungsgraphen, angewendet werden, wenn es einen Graphhomomorphismus gibt, der die
linke Regelseite auf einen Teilgraphen des Anwendungsgraphen abbildet. In diesem Fall erf¨
ullt
der Anwendungsgraph die Vorbedingung der Regel. Ein solcher Graphhomomorphismus wird
als Match bezeichnet [Roz97].
Definition 13. (Match)
Ein Match mf¨
ur einen Graphen L∈ G in einem anderen Graphen G∈ G ist ein totaler Gra-
phhomomorphismus mit m:L7→ G.
Ein Beispiel f¨
ur eine solche Graphtransformationsregel ist in Abbildung 3.17 gegeben. Diese
Regel entspricht der moveSimple-Regel aus Abbildung 2.10.
"!"#
%$'&)(
!*!
(+(-,
.'!/#
,
!0
13254
$
6
&
%$'7
.'!/#
8$'&
(
!*!
(+(-,
&
.'!/#
8$'7
7
,
!3
1*254
$
9
:
8$
6
8$
6
Abbildung 3.17: Beispiel f¨
ur eine Graphtransformationsregel
Die Regel kann angewendet werden, wenn die drei Knoten nr1,nr2und nr3, so-
wie die beiden Kanten re1und re2auf Knoten des entsprechenden Anwendungsgra-
phen abgebildet werden k¨
onnen. Ein m¨
ogliches Matching mex :L7→ Gf¨
ur die Regel mo-
veSimple und den Graphen Gaus Abbildung 3.18(a) ist mex := hmexN,mexEi. Dabei ist
mexN:= {(rn17→ rn1),(rn27→ rn2),(rn37→ rn3)}und mexE:= {(re17→ re1),(re27→ re2)}. Das
Matching ist in Abbildung 3.18(a) gr¨
un hervorgehoben.
Existiert ein solcher Match f¨
ur eine Regel rund einen Anwendungsgraphen G, so werden alle
Knoten und Kanten, auf die der Match die Elemente der linken Regelseite von rabbildet, aber
nicht die Elemente der rechten Regelseite, aus Ggel¨
oscht. Die Knoten und Kanten, die nur in der
Nachbedingung der Regel enthalten sind, aber nicht in der Vorbedingung, werden erzeugt und
in den Anwendungsgraphen eingef¨
ugt. Der resultierende Graph wird als Zielgraph bezeichnet.
Die Regelanwendung wird als direkte Transformation bezeichnet und unterliegt verschiedenen
Einschr¨
ankungen, die in den Pushout Ans¨
atzen beschrieben sind (siehe Abschnitt 3.4.2). Die
folgende Definition f¨
ur eine direkte Transformation stellt eine Anpassung der Definition aus
[HE00] dar. Ein Algorithmus, der die Anwendung einer Graphtransformationsregel beschreibt,
ist in Abbildung C.3 in Anhang C.1.2 in Pseudocode-Notation gegeben.
66 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
!
"
!
""
#
$
"
#
(a) Graph Gauf den die Regel
aus Abbildung3.17 angewen-
det werden soll
"!#
$&%('
)
(b) Graph G0, der resultiert,
wenn die Regel aus Abbildung
3.17 auf Gangewendet wurde
Abbildung 3.18: Zwei Graphen G,G0, f¨
ur die ein Auftreten der Regel aus Abbildung 3.17 exis-
tiert, sodass o(L)⊆Gund o(R)⊆G0gilt
Definition 14. (Direkte Transformation)
Gegeben ist eine Graphtransformationsregel L→rRund ein Match mf¨
ur rin einem Gra-
phen G1∈ G, d.h. m:L7→ G1. Eine direkte Transformation von G1nach G2(G1und G2sind
beschriftungskompatibel) durch eine Graphtransformationsregel rist definiert als ein Graphho-
momorphismus o:L∪R7→ G1∪G2mit o|L=m, sodass gilt:
•o(L)≤G1und o(R)≤G2, d.h. die linke Regelseite kann auf einen Teilgraphen von G1
abgebildet werden und die rechte Regelseite auf einen Teilgraphen von G2und
•o(L\R) = G1\G2und o(R\L) = G2\G1, d.h. die Anwendung der Regel rl¨
oscht genau
den Teil von G1, auf den Elemente von Laber nicht von Rdurch oabgebildet werden.
Umgekehrt werden durch die Anwendung von rdie Elemente aus G2erzeugt auf die R
durch oabgebildet wird.
owird als Auftreten (engl. occurence) bezeichnet.
In Abbildung 3.18 sind zwei Graphen Gund G0gegeben. Das Auftreten oder Regel aus
Abbildung 3.17 ist in den beiden Graphen gr¨
un dargestellt. Das oben vorgestellte Matching mex
wird von overwendet, um die linke Seite der Regel auf Gabzubilden.
Wird ein Graph G1durch eine Regel rund dem Auftreten ovon rin G1in den Graphen G2
transformiert, so wird dies beschrieben durch G1→r,oG2oder kurz G1→rG2.
Eine Sequenz von direkten Transformationen der Form ρ= (G0|=⇒r0,o0G1|=⇒r1,o1
. . . |=⇒rn−1,on−1Gn)beschreibt die Transformation eines Graphen G1in einen Graphen Gndurch
die Regeln r1, . . . , rn−1und ihre Auftreten o1, . . . , on−1. Die Kurzschreibweise f¨
ur die Anwen-
dung von einer solchen Sequenz von Regeln ist G0|=⇒∗
(r0,o0),...,(rn−1,on−1)Gn,G0|=⇒∗
r0,...,rn−1Gn
oder G0|=⇒∗Gn.
3.2.3 Graphtransformationsregeln mit negativer Anwendungsbedingung
Die linke Seite einer Graphtransformationsregel gibt an, wann die Regel angewendet werden
darf. Mittels einer negativen Anwendungsbedingung kann die Anwendbarkeit einer Regel genau-
3.2. GRAPHTRANSFORMATIONSSYSTEME 67
er spezifiziert bzw. eingeschr¨
ankt werden. Solche negativen Anwendungsbedingungen werden in
diesem Abschnitt eingef¨
uhrt.
In Abbildung 3.17 ist die Regel moveSimple angegeben. Diese Regel beschreibt, dass das
Shuttle vom ersten Track rn2auf den n¨
achsten Track rn3weitergesetzt wird. Wird diese Regel
auf den Anwendungsgraphen in Abbildung 3.19 so angewendet, dass die Kante locatedOn ae1
zwischen dem mit Shuttle beschrifteten Knoten an1und dem mit Track beschrifteten Knoten
an2gel¨
oscht und zwischen an1und Track-Knoten an5eine neue locatedOn-Kante erzeugt wird,
so w¨
urde die kritische Situation impendingCollisionSimplified (siehe Abbildung 3.2) auftreten,
da die beiden Shuttlesan1und an5auf benachbarten Tracks fahren w¨
urden. Um die Regelan-
wendung in einem solchen Fall zu verhindern, muss die Regel um eine so genannte negative
Anwendungsbedingung erweitert werden.
W¨
ahrend die bisher betrachteten Anwendungsbedingungen beschreiben, wann eine Regel an-
gewendet werden darf, beschreiben negative Anwendungsbedingungen, wann eine Regel nicht
angewendet werden darf. Eine negative Anwendungsbedingung besteht aus einer Menge von
Graphen. Jeder dieser Graphen enth¨
alt den Graphen der Anwendungsbedingung und erweitert
diesen um mindestens einen Knoten oder eine Kante. Gibt es ein Match f¨
ur die Anwendungs-
bedingung in einem Anwendungsgraphen, so muss gepr¨
uft werden, ob es f¨
ur einen Graphen der
negativen Anwendungsbedingung ebenfalls einen Match gibt. Ist dies der Fall, so darf die Regel
nicht angewendet werden.
!"
#
$
!%
#
!"
#
!"
#
&('
)
!"
#
&('
)
Abbildung 3.19: Beispiel f¨
ur einen Graphen, bei dem die Anwendung von moveSimple zu einer
kritischen Situation f¨
uhren kann
Definition 15. (Negative Anwendungsbedingung)
Eine negative Anwendungsbedingung (NAB) f¨
ur einen Graphen G∈ G ist ei-
ne endliche Menge von Graphen ˆ
G, f¨
ur die gilt ∀ˆ
Gi∈ˆ
G:G≤ˆ
Giund f¨
ur al-
le Knoten n∈(Nˆ
Gi\NG)gibt es einen Pfad πivon nzu einem Knoten n0∈G,
d.h. ∀n∈(Nˆ
Gi\NG)∃n0∈NG,Pfad π:n7→πn0. Die Graphen aus ˆ
Gwerden als Cons-
traints bezeichnet. Ein solches Constraint ˆ
Giwird durch einen Graphen AG ∈ G und einen
Teilgraphisomorphismus tiso ∈ T ISO[G,AG]erf¨
ullt (geschrieben AG,G,tiso `ˆ
Gi), wenn gilt
Gtiso AG aber 6 ∃tiso0∈ T ISO[G,AG] : tiso0|G=tiso ∧ˆ
Gitiso0AG. Ein Graph AG und
ein Teilgraphisomorphismus erf¨
ullen eine negative Anwendungsbedingung ˆ
G(geschrieben
AG,G,tiso `ˆ
G), falls AG alle Constraints ˆ
Gi∈ˆ
Gerf¨
ullt, d.h. ∀ˆ
Gi∈ˆ
G: (AG,G,tiso `ˆ
Gi).
Auf Grund der Einschr¨
ankung, dass ein Auftreten durch einen Teilgraphisomorphismus be-
schrieben wird, anstelle des sonst ¨
ublichen Graphhomomorphismus, kann die Definition der ne-
gativen Anwendungsbedingung im Vergleich zur Definition in [Roz97] vereinfacht werden.
68 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
Die erweiterte Graphtransformationsregel, moveSimpleNAC, ist in Abbildung 3.20 abgebil-
det. Die Graphen ˆ
L1und ˆ
L2stellen die negative Anwendungsbedingung dar. ˆ
L1verbietet die
Anwendung der Regel, falls sich auf dem n¨
achsten Track ein weiteres Shuttle befindet, da es
sonst zu einer Kollision k¨
ame. ˆ
L2verbietet, das Shuttle vorw¨
arts zu setzen, wenn sich auf dem
¨
ubern¨
achsten Track ein anderes Shuttle befindet, da andernfalls die kritische Situation auftre-
ten w¨
urde. Die so ver¨
anderte Regel kann nicht mehr auf den Knoten an1angewendet und das
entsprechende Shuttle somit nicht weiter gesetzt werden. Sie kann jedoch auf den Knoten an5
angewendet werden, da sich auf den beiden Tracks vor diesem Shuttle kein weiteres Shuttle be-
findet.
! #"$&%
'
%)(
'
(
'
%+*
,.-
#/
,0,
'
,1-
/#
,0,
'
'
#2
'
%+2
34
-
56
7
'
889
7
'
889 7
'
+)9
,.-
#/
,0,
'
,1-
/#
,0,
'
'
#2
7
'
889
7
'
889 7
'
+)9
#+! /"$%
'
%)(
'
(
,1-
/#
,0,
'
,1-
/#
,:,
'
'
#2
'
%+2
34
-
56
7
'
889
7
'
889 7
'
889
! #"$&%
#+! /"$%
'
%)(
34
-
56
;
<
! #"$&%
'
%)(
'
(
'
%+*
'
%+=
>
?@
#+! /"$%
,.-
#/
,0,
'
,1-
/#
,0,
'
'
#2
'
%+2
34
-
56
7
'
+)9
7
'
+)9 7
'
+)9
34
-
56
'
%+=
'
/A
3B4
-
56
>
?DC
'
/E
'
/E
'
/E
'
/E
'
/=
'
#*
'
%+*
'
%+*
'
%E
'
%E
'
%E
'
%E
'
%+2
Abbildung 3.20: Regel moveSimpleNAC, die die Regel moveSimple um negative Anwendungs-
bedingungen erweitert
Um redundante Informationen zu vermeiden, werden im Folgenden minimale negative An-
wendungsbedingungen betrachtet. Angenommen, eine negative Anwendungsbedingung enth¨
alt
zwei Graphen ˆ
G1und ˆ
G2und ˆ
G1ˆ
G2. Wenn es einen Match von ˆ
G2in einem Anwendungsgra-
3.3. GRAPHMUSTER 69
phen Ggibt, dann kann dieser Match so ver¨
andert werden, dass er auch ˆ
G1auf Gabbildet. In
einem solchen Fall kann ˆ
G2aus der negativen Anwendungsbedingung entfernt und die negati-
ve Anwendungsbedingung dadurch minimiert werden. Enth¨
alt eine negative Anwendungsbedin-
gung kein Graphpaar f¨
ur das gilt, dass einer der beiden Graphen durch einen Isomorphismus auf
einen Teilgraph des anderen Graphen abgebildet werden kann, so ist die negative Anwendungs-
bedingung minimal.
Definition 16. (Minimale Negative Anwendungsbedingung)
Eine negative Anwendungsbedingung ˆ
Geines Graphen Gist eine minimale Menge von Gra-
phen, wenn gilt ∀ˆ
G,ˆ
G0∈ˆ
G:ˆ
G6=ˆ
G0⇒(6 ∃tiso ∈ T ISO[ˆ
G,ˆ
G0] : tiso |G=idG∧ˆ
Gtiso ˆ
G0).
idGentspricht der Identit¨
atsfunktion.
Ein Algorithmus zur Minimierung von negativen Anwendungsbedingungen ist in Abbildung
C.2 in Anhang C.1.1 in Pseudocode-Notation angegeben.
3.2.4 Graphtransformationssysteme
Nach [Roz97] wird ein Graphtransformationssystem durch eine Menge von initialen Graphen
sowie einer Menge von Graphtransformationsregeln gegeben.
Definition 17. (Graphtransformationssystem (GTS))
Ein Graphtransformationssystem S:= (Gi
S,RS)ist ein Tupel mit:
• Gi
Sist die Menge der Initial- oder Startgraphen des Systems und
• RSist eine endliche Menge von Graphtransformationsregeln.
F¨
ur ein gegebenes Graphtransformationssystem S:= {Gi
S,RS}bezeichnet REACH(S) :=
{G1∈ G | ∃G2∈ Gi
S:G2|=⇒∗G1}die Menge aller in Serreichbaren Zust¨
ande.
Die Definition 17 erlaubt Systeme mit unendlich großem Zustandsraum zu spezifizie-
ren, die als unendliche Graphtransformationssysteme bezeichnet werden. Ein GTS S:= {Gi
S,
RS}ist genau dann unendlich, wenn gilt, dass REACH(S)unendlich viele Graphen enth¨
alt,
die unter Ber¨
ucksichtigung des Graphisomorphismus verschieden sind, d.h. ∀G1∈REACH(S),
6 ∃G2∈(REACH(S)\G1) : G1≈G2.
3.3 Graphmuster
Mit den bisher eingef¨
uhrten Konstrukten ist es m¨
oglich Graphtransformationssysteme zu be-
schreiben. Dar¨
uber hinaus wurde gezeigt, wie eine Regel auf einen Graphen angewendet werden
kann, wenn es ein g¨
ultiges Matching f¨
ur die linke Regelseite im Graphen gibt. Es ist allerdings
noch nicht m¨
oglich, strukturelle Eigenschaften zu beschreiben, die bei der Anwendung einer
Graphtransformationsregel erhalten bleiben sollen. Zur Beschreibung struktureller Eigenschaf-
ten sollen im Folgenden Graphmuster eingef¨
uhrt werden.
Graphmuster wurden bereits im informalen Abschnitt dieses Kapitels, Abschnitt 3.1, dazu
verwendet, die kritische Situation impendingCollision bzw. impendingCollisionSimplified zu spe-
zifizieren.
70 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
Ein einfaches Graphmuster besteht aus einem Graphen G. Ein Anwendungsgraph AG erf¨
ullt
dieses Muster, falls es einen Teilgraphisomorphismus tiso ∈ T ISO[G,AG]gibt, der Gauf einen
Teilgraphen von AG abbildet, d.h. Gtiso AG. Ein solches Graphmuster kann dazu verwendet
werden, eine Menge von Graphen zu beschreiben. Dies ist genau die Menge von Graphen, die
das entsprechende Muster erf¨
ullen und somit alle einen gemeinsamen Teilgraphen haben.
Definition 18. (Einfache Graphmuster)
Ein einfaches Graphmuster p:= [P]besteht aus einem nicht leeren Graphen P∈ G.
Die Ausdrucksst¨
arke von Graphmustern kann erh¨
oht werden, indem negative Anwendungs-
bedingungen hinzugenommen werden. Ein solches Graphmuster besteht dann aus einem Gra-
phen Pund einer negativen Anwendungsbedingung ˆ
P, wobei die Menge der Graphen der ne-
gativen Anwendungsbedingung leer sein kann. Ein Graphmuster mit negativer Anwendungsbe-
dingung beschreibt eine Menge von Graphen, die einen Teilgraphen haben, auf den einerseits P
durch einen Teilgraphisomorphismus tiso abgebildet werden kann. Andererseits aber gilt, dass
kein Graph der negativen Anwendungsbedingung ˆ
P∈ˆ
Pdurch eine Erweiterung von tiso auf die
Graphen der Menge abgebildet werden kann.
Definition 19. (Graphmuster)
Ein Graphmuster p:= [P,ˆ
P]besteht aus einem nicht leeren Graphen P∈ G und einer ne-
gativen Anwendungsbedingung, die durch eine m¨
oglicherweise leeren Menge von Graphen ˆ
P
beschrieben wird. Dabei gilt: ∀ˆ
P∈ˆ
P:P≤ˆ
P.
GP bezeichnet die Menge aller Graphmuster.
Im vorangegangenen Abschnitt wurde die linke Regelseite einer Graphtransformationsregel
um eine negative Anwendungsbedingung erweitert. Die Anwendungsbedingung der Regel zu-
sammen mit der negativen Anwendungsbedingung entspricht einem Graphmuster.
Auch die kritische Situation impendingCollision kann als ein Graphmuster aufgefasst werden.
In diesem Fall beschreibt das Muster die Menge der Graphen, in denen eine kritische Situation
eingetreten ist und eine Kollision droht.
Ein einfaches Graphmuster [G]entspricht einem Graphmuster [G,ˆ
G], wobei ˆ
Geine leere Men-
ge ist.
Sind zwei Graphmuster p:= [P,ˆ
P]und p0:= [P0,ˆ
P0]gegeben, dann ist pein Teilgraphmus-
ter von p0, wenn die folgenden beiden Bedingungen erf¨
ullt sind. Erstens muss es einen Teilgra-
phisomorphismus tiso ∈ T ISO[P,P0]geben, der Pauf einen Teilgraphen von P0abbildet. Es
muss also gelten: PP0. Allerdings darf kein Graph der negativen Anwendungsbedingung ˆ
P
durch einen Teilgraphisomorphismus auf einen Teilgraphen von P0abgebildet werden k¨
onnen.
Zweitens, wenn pnicht erf¨
ullt ist, weil einer der Graphen aus ˆ
Pauf einen Anwendungsgraphen
abgebildet werden kann, muss es auch einen Graphen in ˆ
P0geben, der auf den Anwendungsgra-
phen abgebildet werden kann. Das bedeutet, dass es f¨
ur jeden Graphen aus ˆ
Peinen Graphen in
ˆ
P0gibt, der auf den Anwendungsgraphen abgebildet werden kann. Dies ist genau dann der Fall,
wenn es f¨
ur jeden Graphen ˆ
P∈ˆ
Peinen Graphen ˆ
P0∈ˆ
P0gibt, der die folgende Eigenschaft hat.
Es gilt, Ptiso P0. Entfernt man aus ˆ
P0alle Elemente, auf die der Teilgraphisomorphismus tiso
keine Elemente von Pabbildet, so gibt es f¨
ur den verbleibenden Graphen einen Teilgraphisomor-
phismus, der den Restgraphen auf einen Teilgraph von ˆ
Pabbildet.
3.3. GRAPHMUSTER 71
Definition 20. (Teilgraphmuster)
Gegeben sind zwei Graphmuster p= [P,ˆ
P]und p0= [P0,ˆ
P0].pist ein Teilgraphmuster von
p0(geschrieben p⊆p0) wenn gilt:
• ∃tiso ∈ T ISO :Ptiso P0∧P0,P,tiso `ˆ
P,
• ∀ˆ
P∈ˆ
P,∃ˆ
P0∈ˆ
P0,tiso0∈ T ISO :tiso0−1|P=tiso ∧(ˆ
P0\(P0\tiso(P))) tiso0ˆ
P.
Abbildung 3.21 zeigt ein Graphmuster, impendingCollisionExtended, das eine kritische Si-
tuation beschreibt. Dieses Muster besagt, dass eine kritische Situation eingetreten ist, wenn sich
zwei Shuttles auf benachbarten Tracks befinden, die beiden Shuttles das DistanceCoordinati-
on-Muster nicht miteinander ausf¨
uhren, obwohl beide Shuttles das Publication-Muster mit der
gleichen BaseStation ausf¨
uhren. Ist ein Shuttle bei einer BaseStation registriert, so muss es in
regelm¨
aßigen Abst¨
anden seine Position an diese senden und erh¨
alt die Position der anderen ge-
meldeten Shuttles. Das bedeutet, dass die beiden Shuttles wissen, dass das jeweils andere Shuttle
sich in ihrer N¨
ahe befindet, koordinieren sich aber dennoch nicht.
Das Graphmuster impendingCollision ist ein Teilgraphmuster von impendingCollisionExten-
ded. Zum einen gilt, dass die Anwendungsbedingung von impendingCollision mittels eines Teil-
graphisomorphismus auf die Anwendungsbedingung von impendingCollisionExtended abgebil-
det werden kann. Zum anderen ist aber auch die zweite Bedingung f¨
ur ein Teilgraphmuster
erf¨
ullt. F¨
ur den Graph der negativen Anwendungsbedingung ˆ
IC existiert ein Graph in der negati-
ven Anwendungsbedingung ˆ
ICE, sodass gilt, kann ˆ
IC auf einen Anwendungsgraphen abgebildet
werden, so kann auch ˆ
IC auf den Anwendungsgraphen abgebidelt werden. Entfernt man aus ˆ
ICE
alle Elemente, die in ICE vorkommen, aber nicht in IC (dies sind die Knoten vn0
5,vn0
6und vn0
7
sowie die Kanten ve0
4,ve0
5,ve0
6,ve0
7,ve0
8und ve0
9) so erh¨
alt man einen Graphen, der isomorph zum
Graphen ˆ
IC ist2.
F¨
ur ein Graphmuster p:= [P,ˆ
P]beschreibt G[p]die Menge aller Graphen, die das Muster
perf¨
ullen, d.h. G[p] := {G∈ G | ∃tiso ∈ T ISO :Ptiso G∧G,P,tiso `ˆ
P}. Die Kurzschreib-
weise daf¨
ur, dass ein Graph Gein Muster perf¨
ullt, ist G|=p.
Gegeben sind zwei Graphmuster p:= [P,ˆ
P]und p0:= [P0,ˆ
P0]. Ist pein Teilgraphmuster von
p0, so erf¨
ullt ein Graph G∈ G, der das Graphmuster p0erf¨
ullt, auch p. Dies ist in der Implikation
B.1 von Lemma 1 festgehalten. Gibt es andererseits einen Graphen G∈ G, der p0erf¨
ullt, paber
nicht, so folgt daraus, dass pkein Teilgraphmuster von p0sein kann. Dieses Ergebnis wird in
der Implikation 3.2 zusammengefasst. Eine Beweisskizze f¨
ur dieses und die folgenden Lemmata
und Theoreme ist in Anhang B gegeben.
Lemma 1. (Implikation von Teilgraphmustern)
F¨
ur zwei Graphmuster pund p0gilt:
(p⊆p0)⇒(∀G∈ G[p0] : G|=p)und (3.1)
(∃G∈ G[p0] : G6|=p)⇒(p6⊆ p0)(3.2)
2Es gilt auch, dass impendingCollisionSimplified ein Teilgraphmuster von impendingCollision ist
72 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
"!#
$
%&&
'
(
'
)
'
)
'
*
'
*
'
+
'
,(
'
,(
&-
'
.*
'
.+
,
/
!10
'
32
'
,)
,
/
!10
,
/
!10
'
,)
,
/
!10
'
32
4%
-
,
56
.
56
'
2
'
2
'
(
(a) Graphmuster impendingCollision
! "#
$%
'&(
# ")* +%,
-.
/# (! "-
! #
$%
"&0
# )1 %
2
34
2
34
2
35
2
35
2
36
2
36
2
37
2
37
2
38
2
38
2
39
2
3:
2
3;
2
3:
2
34
2
35
2
'35
2
'36
2
36
2
'37
2
'3;
2
3;
<#= /
2
38
<#= >
2
38
2
3:
2
3:
2
'39
2
39
2
3?
2
3?
2
34
@
>#'AB
2
34C4
D
%
"! #
&C
E
F0G
&C
D
%
"! #
H
0I
D
%
"! #
E
F0G
&C
&C
D
%
"! "-
<#= ,>
<-= /
$%
"&0
# ")* +%
# ")* +%, J
KI
J
0I
E
F0G
E
F0G
2
3;
$%
'&(
2
37
2
34ML
/0CAN
(b) Graphmuster impendingCollisionExtended
Abbildung 3.21: Beispiel f¨
ur ein Graphmuster und ein Teilgraphmuster
3.4 Das Systemmodell
Erweitert man die in Definition 17 eingef¨
uhrten Graphtransformationssysteme um Typen, so
lassen sich damit UML-Modelle formalisieren.
3.4.1 Graphen zur Zustandsbeschreibung
In dieser Arbeit werden UML-Klassendiagramme verwendet, um die Architektur der Software
eines mechatronischen Systems zu beschreiben. Ein Objektdiagramm beschreibt einen bestimm-
ten Zustand des Systems. Um ein System, das durch Klassendiagramme und Objektdiagramme
3.4. DAS SYSTEMMODELL 73
beschrieben ist, zu formalisieren, wird das Klassendiagramm auf einen Typgraphen abgebildet
und jedes Objektdiagramm auf einen typisierten Graphen. Die ¨
Uberg¨
ange von einem Zustand zu
einem anderen werden mittels Graphtransformationsregeln gegeben.
Das Klassendiagramm wird formalisiert, indem die Klassen auf Knoten und die Assozia-
tionen auf Kanten abgebildet werden. Klassennamen und Assoziationsnamen werden mittels
der Knoten- und Kantenbeschriftungsfunktionen den Knoten und Kanten zugewiesen. Um die
Graphtransformationssysteme m¨
oglichst einfach zu halten, werden Kardinalit¨
aten und Vererbung
hier nicht ber¨
ucksichtigt.
Ein Klassendiagramm kann auf einen Graphen GΩ:= (NΩ,EΩ,srcΩ,tgtΩ)abgebildet wer-
den. Dieser Graph GΩdient dann als Typgraph. Die Menge der Knotentypen, bzw. das Alphabet
zur Beschriftung von Knoten, ΩNist definiert als ΩN=NΩ, ebenso ist die Menge der Kantenty-
pen ΩEdefiniert als ΩE=EΩ.
In Abbildung 4.1(a) ist noch einmal das einfache UML-Klassendiagramm aus Abschnitt
2.1.3 abgebildet. Dieses Diagramm zeigt die vereinfachte Ontologie des Shuttle-Systems. Der
Typgraph, der diesem Klassendiagramm entspricht, besteht aus drei Knoten, beschriftet mit Ba-
seStation,Track und Shuttle. Diese Knoten entsprechen den gleichnamigen Klassen des Klassen-
diagramms. Ebenso enth¨
alt der Typgraph drei Kanten, die mit locatedOn,monitors und succes-
sor beschriftet sind. Die Kanten entsprechen den Assoziationen des Klassendiagramms, wobei
die Assoziationsnamen nun als Kantenbeschriftungen dienen. Die Kardinalit¨
aten, die im Klas-
sendiagramm angegeben sind, fallen im Typgraphen weg.
(a) Klassendiagramm, das die
vereinfachte Systemontologie
beschreibt
!""#
$%#&('
)
* +#,
(b) Typgraph f¨
ur das Klassendia-
gramm in Abbildung 4.1(a)
Abbildung 3.22: Einfaches Klassendiagramm und der dazugeh¨
orige Typgraph
Nach der Abbildung des Klassendiagramms auf einen Typgraphen entspricht ein UML-
Objektdiagramm einem beschrifteten Graphen. Jeder Knoten des beschrifteten Graphen ent-
spricht einem Objekt des Objektdiagramms und jede Kante einem Link. F¨
ur diese Gra-
phen muss garantiert werden, dass ihre Beschriftung konform zum Typgraphen und so-
mit zum urspr¨
unglichen Klassendiagramm ist. Ein Knoten ist typkonform, wenn seine Be-
schriftung einem Typ des Typgraphen entspricht. Eine Kante ist typkonform, wenn ihre Be-
schriftung mit einer Kantenbeschriftung aus dem Typgraphen ¨
ubereinstimmt und wenn die
74 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
Beschriftung des Start- und Zielknotens mit den Typen ¨
ubereinstimmen, die vom Typgra-
phen verlangt werden. Um Knoten und Kanten besser referenzieren zu k¨
onnen, erhalten sie
zus¨
atzlich einen eindeutigen Namen; dieser hat jedoch keinen Einfluss auf die auf den Gra-
phen angewendeten Operationen. Der Name eines Knoten oder einer Kante steht immer
vor einem ”:“, w¨
ahrend der Typ dem ”:“folgt. Die Menge der typkonformen Kanten ist als
correctTypedEdges(GΩ) := {(srcΩ(e),e,tgtΩ(e)) ∈NΩ×EΩ×NΩ}definiert. Ein Graph ist typ-
konform, wenn die Knoten- und Kantenbeschriftungsfunktionen nur Beschriftungen zuweisen,
die im Typgraph definiert sind und wenn alle Kanten typkonform sind. Formal ist die Typkon-
formit¨
at definiert als:
Definition 21. (Typkonformit¨
at von Graphen)
Die Beschriftung eines Graphen G:= (N,E,src,tgt,ln,lE)ist genau dann typkonform zu ei-
nem Typgraph GΩ:= (NΩ,EΩ,srcΩ,tgtΩ), wenn gilt:
lN:N7→ ΩN∧ΩN⊆NΩund lE:E7→ ΩE∧ΩE⊆EΩ(3.3)
∀e∈E: (lN(src(e)),lE(e),lN(tgt(e))) ∈correctTypedEdges(GΩ).(3.4)
Die Menge aller Graphen, die typkonform zum Typgraphen GΩsind, wird mit G[GΩ]bezeich-
net. Anhand des Typgraphen GΩk¨
onnen UML-Objektdiagramme auf typkonforme beschriftete
Graphen abgebildet werden. Wird eine Graphtransformationsregel auf einen typkonformen Gra-
phen angewendet, so muss garantiert werden, dass auch der resultierende Graph typkonform ist.
Die folgende Definition 22 sowie das Theorem 1 zeigen, dass eine Regelanwendung die Typ-
konformit¨
at erh¨
alt, wenn der Anwendungsgraph, der Graph der linken Regelseite, inklusive der
negativen Anwendungsbedingung sowie der Graph der rechten Regelseite typkonform sind.
Definition 22. (Typkonformit¨
at von Graphtransformationsregeln)
Eine Graphtransformationsregel r∈RSeines Graphtransformationssystems
S:= (GS,Gi
S,RS)ist genau dann typkonform zu GΩ, wenn alle in renthaltenen Graphen
(L,ˆ
Lund R) typkonform zu GΩsind.
Damit eine Regelanwendung typkonform erfolgen kann, muss die Vereinigung, der Schnitt,
die Subtraktion und das Matching von Graphen die Typkonformit¨
at erhalten. Da bei keiner der
vier Operationen neue Knoten oder Kanten entstehen, erf¨
ullen alle diese Anforderungen. Die
entsprechenden Lemmata (Lemma 2, 3 und 4) sind in Anhang B.2 enthalten.
Diese Ergebnisse werden in Theorem 1 verwendet, um zu zeigen, dass die Anwendung ei-
ner typkonformen Graphtransformationsregel auf einen typkonformen Graphen wieder in einem
typkonformen Graphen resultiert.
Theorem 1. (Erhaltung der Typkonformit¨
at)
F¨
ur jeden typkonformen Graphen G1∈ G und jede typkonforme Graphtransformationsregel
[L,ˆ
L]→rRgilt: falls ein G2∈ G existiert, mit G1|=⇒rG2, so ist auch G2typkonform.
3.4. DAS SYSTEMMODELL 75
3.4.2 Graphtransformationen zur Beschreibung von Zustands¨
anderungen
Nach Definition 14 kann eine Graphtransformationsregel [L,ˆ
L]→rRauf einen Graphen Gange-
wendet werden, falls es einen Match m∈ M[L,G]gibt, der Lauf Gabbildet, der aber nicht so
erweitert werden kann, dass er ein ˆ
L∈ L auf Gabbildet. Zus¨
atzlich zu dieser Bedingung kann
es zwei weitere Bedingungen geben, die die Anwendung einer Regel einschr¨
anken. Dies sind
die Identifikationsbedingung (engl. identification condition) und die Lose-Kanten-Bedingung
(engl. dangling edge condition (siehe [Roz97] Seite 189).
Damit eine Regel angewendet werden darf, wird in dieser Arbeit verlangt, dass es einen
Teilgraphisomorphismus gibt, der die linke Seite der Regel auf den Anwendungsgraphen ab-
bildet. Rozenberg verlangt in [Roz97] dagegen nur einen Graphhomomorphismus. Bei einem
Homomorphismus kann es vorkommen, dass zwei Knoten der linken Regelseite auf einen Kno-
ten des Anwendungsgraphen abgebildet werden. Wenn einer der beiden Knoten durch die Regel
gel¨
oscht, der andere jedoch durch die Regel erhalten werden soll, so entsteht ein Konflikt. Nach
[Roz97] verlangt die Identifikationsbedingung f¨
ur einen Knoten, der gel¨
oscht werden soll, dass
er auf einen Knoten abgebildet werden muss, auf den kein anderer Knoten abgebildet wird.
Definition 23. (Identifikationsbedingung)
Gegeben ist eine Graphtransformationsregel [L,ˆ
L]→rR, ein Anwendungsgraph G∈ G und
ein Match m:L7→ G, wobei f¨
ur mgilt 6 ∃ˆ
L∈ˆ
L,6 ∃m0:ˆ
L7→ G∧m0|L=m.
Die Identifikationsbedingung (engl. identification condition) verlangt, dass
∀n∈(NL\NR),n0∈NL:n6=n0⇒m(n)6=m(n0).
Die starke Identifikationsbedingung verlangt, dass grunds¨
atzlich keine zwei Knoten der lin-
ken Seite auf den selben Knoten des Anwendungsgraphen abgebildet werden d¨
urfen.
Definition 24. (Starke Identifikationsbedingung)
Gegeben ist eine Graphtransformationsregel [L,ˆ
L]→rR, ein Anwendungsgraph G∈ G und
ein Match m:L7→ G, wobei f¨
ur mgilt 6 ∃ˆ
L∈ˆ
L,6 ∃m0:ˆ
L7→ G∧m0|L=m.
Die starke Identifikationsbedingung verlangt f¨
ur rund m, dass gilt ∀n,n0∈NL:n6=n0⇒
m(n)6=m(n0).
Die Verwendung von Teilgraphisomorphismen zur Beschreibung der Matchings und des Auf-
tretens einer Regel in einem Anwendungsgraphen f¨
uhrt dazu, dass die starke Identifikationsbe-
dingung erf¨
ullt ist. Auf diese Weise wird der oben beschriebene Konflikt beim L¨
oschen eines
Elements verhindert.
Auch die Lose-Kanten-Bedingung dient dazu, Konflikte beim L¨
oschen von Knoten zu ver-
meiden. Diese Bedingung verlangt, dass durch das L¨
oschen von Knoten keine Kanten entstehen,
denen der Start- oder Zielknoten fehlt (Kanten, die keinen Start- oder Zielknoten besitzen, wer-
den als lose Kanten3bezeichnet). D.h. die Lose-Kanten-Bedingung fordert, dass Kanten, die zu
einem zu l¨
oschenden Knoten inzident sind, ebenfalls durch die Regel gel¨
oscht werden.
3Im Deutschen wird der Begriff meistens mit h¨
angende Kanten ¨
ubersetzt. In dieser Arbeit werden die Kanten
als lose Kanten bezeichnet, da dies ihren Charakter meiner Meinung nach besser beschreibt.
76 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
Definition 25. (Lose-Kanten-Bedingung)
Gegeben sind ein Anwendungsgraph G∈ G, eine Regel [L,ˆ
L]→rRund ein Auftreten omit
LoG, außerdem gilt ∀ˆ
L∈ˆ
L,6 ∃o0:o0|L=o∧ˆ
Lo0G.
Die Lose-Kanten-Bedingung verlangt, dass f¨
ur die Regel r, den Anwendungsgraphen Gund
das Auftreten ogilt 6 ∃e∈EG,e0∈EL:oE(e0) = e∧(src(e0)∈(NL\NR)∨tgt(e0)∈(NL\NR)).
Ein Ansatz, in dem sowohl die Identifikationsbedingung als auch die Lose-Kanten-
Bedingung erf¨
ullt sein m¨
ussen, damit eine Regel angewendet werden darf, ist der Double Pu-
shout Ansatz(DPO, [Roz97] Kapitel 3). Damit die Lose-Kanten-Bedingung erf¨
ullt ist, darf eine
Regel nur dann angewendet werden, wenn alle Kanten, die zu einem zu l¨
oschenden Knoten in-
zident sind, ebenfalls von der Regel gel¨
oscht werden. Dem gegen¨
uber steht der Single Pushout
Ansatz (SPO, siehe [Roz97] Kapitel 4). Im SPO muss weder die Identifikationsbedingung noch
die Lose-Kanten-Bedingung erf¨
ullt sein, damit eine Regel angewendet werden darf. Damit bei
der Regelanwendung wieder ein Graph resultiert, der keine losen Kanten enth¨
alt, m¨
ussen solche
Kanten nach der Regelanwendung gel¨
oscht werden. Zus¨
atzlich bietet der Single Pushout Ansatz
die M¨
oglichkeit, negative Anwendungsbedingungen zu formulieren, was im Double Pushout An-
satz nach [Roz97] nicht m¨
oglich ist. Nach Habel, Heckel und Taentzer [HHT96] k¨
onnen negative
Anwendungsbedingungen aber auch im Double Pushout Ansatz verwendet werden.
Wenn ein Shuttle zwei Publication-Muster ausf¨
uhrt, so wird durch die Graphtransformations-
regel in Abbildung 3.23(a) eine Instanz des Musters gel¨
oscht. F¨
ur die zu l¨
oschende Instanz ist in
der Regel jedoch nicht spezifiziert, mit welcher BaseStation dieses Muster ausgef¨
uhrt wird. Ab-
bildung 3.23(b) zeigt einen Graphen, auf den die Regel angewendet werden soll. Ein Matching
m:= hmN,mEi, das die (starke) Identifikationsbedingung erf¨
ullt, sieht folgendermaßen aus: die
Funktion mNbildet keine zwei Knoten der linken Regelseite auf den selben Knoten des Anwen-
dungsgraphen ab, mN:= {(rbs17→ abs1),(rp17→ ap1),(rt17→ at1),(rs17→ as1),(rp27→ ap2)}.
Ebenso bildet die Funktion mEkeine zwei Kanten der linken Regelseite auf eine Kante des An-
wendungsgraphen ab, mE:= {(rd17→ ad1),(rpub17→ apub1),(rlo17→ alo1),(rpub27→ apub2)}.
Die Anwendung der Regel unter Verwendung dieses Matchings w¨
urde dazu f¨
uhren, dass der
Knoten ap2gel¨
oscht wird. Allerdings wird mit apub2nur eine der zu ap2inzidenten Kanten
gel¨
oscht. Die Kante ad2bleibt als lose Kante erhalten. Von daher ist eine Anwendung der Regel
im Double Pushout Ansatz nicht erlaubt. Im Single Pushout Ansatz ist die Anwendung erlaubt,
allerdings muss die Kante ad2noch gel¨
oscht werden.
Ein weiteres Matching m0:= hm0
N,m0
Ei, das die Identifikationsbedingung jedoch nicht erf¨
ullt,
bildet die beiden Knoten rp1und rp2der linken Regelseite auf den Knoten ap1des Anwendungs-
graphen ab, m0
N:= {(rp17→ ap1),(rp27→ ap1),(rs17→ as1),(rbs17→ abs1),(rt17→ at1)}. Auch
die Funktion m0
Ebildet zwei Kanten der linken Regelseite auf die selbe Kante des Anwendungs-
graphen ab, m0
E:= {(rpub17→ apub1),(rpub27→ apub1),(rd17→ ad1),(rlo17→ alo1)}. In diesem
Fall ist die Identifikationsbedingung nicht erf¨
ullt und eine Regelanwendung im Double Pushout
Ansatz nicht erlaubt. Im Single Pushout Ansatz ist die Anwendung zwar erlaubt, jedoch muss
der Konflikt behoben werden, dass der Knoten ap1und die Kante ap2durch die Regelanwendung
sowohl erhalten, als auch gel¨
oscht werden sollen.
Dadurch, dass im DPO sowohl die Identifikations- als auch die Lose-Kanten-Bedingung
erf¨
ullt sind, k¨
onnen Regeln auch r¨
uckw¨
arts angewendet werden, was einem R¨
uckg¨
angigmachen
3.4. DAS SYSTEMMODELL 77
!"$#%
&
'()*#+,!
% -.!/ 0
%( !/$#%
! )1 ! 02354768
'9:;<0%=
>47(43,?3)
@ ABDC?BEB*FHGICKJMLN E%JMOQP
92
%1 -.!/02
>47(43,M3
%1 !"$#%
R
>()*#+,!
! 1 ! 02354768
S9:Q>T0T=
U-.!/ 0
(a) Regel delPublication
! "
#
$
#
" %
$&'()+*
,
.-/01)2! "
,
$
,
0143+
46574)2)289
9+57:3;0
0 +5<=0 >)2>?@"
65A&B()+*
,
65A=-C0D )!"
65A
9+5.92 !"
#
+5A
#
" E
,
65A
,
0D F3
(b) Anwendungsgraph auf den die Regel deletePublicati-
onim Single bzw. Double Pushout Ansatz angewendet wer-
den soll.
!"#$%
& '(*)'+,
)')(%-.(
/1023*"45
6,678 (9
3:;<=
!8>**?35
(@A:B<=
)@/8)(%-.(
5@/C025"454
6A@A6A8 (D
(c) Graph, der resultiert, wenn deletePublication unter
dem Match mim Single Pushout Ansatz auf den Anwen-
dungsgraphen angewendet wird. Die lose Kante da2wurde
noch nicht entfernt.
Abbildung 3.23: Regel deletePublication und ihre Anwendung auf einen Graphen im Single
bzw. Double Pushout Ansatz
einer Regelanwendung entspricht. Im SPO ist dies nicht immer m¨
oglich. Dies gilt zum Beispiel
nicht, wenn nach der Anwendung der Regel lose Kanten gel¨
oscht werden. Wird auf den daraus
resultierenden Graphen die entsprechende Regel r¨
uckw¨
arts angewendet, w¨
urden die gel¨
oschten
losen Kanten nicht wieder erzeugt, da sie nicht Teil der Regel waren.
78 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
In dieser Arbeit sollen Graphtransformationsregeln dazu verwendet werden, die Zu-
stands¨
uberg¨
ange der Software eines mechatronischen Systems zu modellieren. Dazu m¨
ussen
die Regeln einige Anforderungen erf¨
ullen. Zum einen werden ausdrucksstarke Regeln ben¨
otigt,
d.h. neben der Anwendungsbedingung muss f¨
ur eine Regel auch eine negative Anwendungsbe-
dingung spezifiziert werden k¨
onnen. Andererseits bedeutet das L¨
oschen einer Kante in einem
mechatronischen System, dass die Verbindung zwischen zwei Objekten gel¨
oscht wird. Um ein
versehentliches L¨
oschen einer Verbindung zu verhindern, muss die Regelanwendung die Lose-
Kanten-Bedingung erf¨
ullen. Im Verifikationsansatz, der in Abschnitt 3.7 vorgestellt wird, m¨
ussen
die Regeln auch r¨
uckw¨
arts angewendet werden k¨
onnen. Dies ist aber nur m¨
oglich, wenn die
Anwendung der Regeln sowohl die starke Lose-Kanten- als auch die starke Identifikationsbe-
dingung erf¨
ullt. Deshalb wird in dieser Arbeit der Double Pushoutiso Ansatz verwendet. Dieser
Ansatz schr¨
ankt den DPO so ein, dass im Gegensatz zum normalen DPO eine Regel nur dann
anwendbar ist, wenn das Auftreten oder Regelseite einem Teilgraphisomorphismus entspricht.
Zus¨
atzlich zum DPO aus [Roz97] sind auch negative Anwendungsbedingungen erlaubt.
Definition 26. (Double Pushout Ansatz iso (DPOiso))
Eine direkte Transformation von einem Graphen AG ∈ G zu einem Graphen TG ∈ G (AG
und TG sind beschriftungskompatibel) im Double Pushoutiso Ansatz entspricht einer direkten
Transformation (siehe Definition 14) mit den folgenden Einschr¨
ankungen:
1. Jedes korrekte Match einer Regel rerf¨
ullt die Lose-Kanten-Bedingung.
2. F¨
ur jedes Match meiner Regel [L,ˆ
L]→rRin AG gilt, dass mein Teilgraphisomorphismus
ist, LmGund ∀ˆ
L∈ˆ
L,6 ∃m0∈ T ISO[ˆ
L,AG] : m0|L=m∧ˆ
Lm0AG. F¨
ur alle Auftreten
ovon rin AG gilt, dass oein Teilgraphisomorphismus ist.
Bedingung 2 garantiert, dass die starke Identifikationsbedingung per Konstruktion erf¨
ullt ist.
Durch Bedingung 1 der Definition 26 wird erreicht, dass die Regelanwendungen keine losen
Kanten erzeugen, wenn der Match der linken Regelseite korrekt ist.
Wann ein gefundener Match korrekt ist, kann durch zus¨
atzliche Graphen in der negativen
Anwendungsbedingung beschrieben werden. Dazu wird die negative Anwendungsbedingung der
linken Regelseite so erweitert, dass die Regel nur dann angewendet werden kann, wenn alle
Kanten, die zu einem zu l¨
oschenden Knoten inzident sind, ebenfalls durch die Regel gel¨
oscht
werden. Um dies zu erreichen, m¨
ussen f¨
ur jeden zu l¨
oschenden Knoten zus¨
atzliche Graphen zur
negativen Anwendungsbedingung hinzugef¨
ugt werden. In Anhang C.1.1 ist in Abbildung C.1 der
Algorithmus extendNAC in Pseudocode-Notation gegeben, der diese Erweiterung durchf¨
uhrt.
Wie in Abbildung 3.23(c) zu sehen ist, kann die Anwendung der Regel deletePublication
zu losen Kanten f¨
uhren. Um dies zu verhindern, muss die Anwendung der Regel durch eine
negative Anwendungsbedingung eingeschr¨
ankt werden. Die Regel deletePublication l¨
oscht den
Knoten rp2vom Typ Publication. Laut Typgraph kann ein Knoten vom Typ Publication durch ei-
ne Kante vom Typ distributor mit einem Knoten vom Typ BaseStation verbunden sein und durch
eine Kante vom Typ publisher mit einem Knoten vom Typ Shuttle. F¨
ur beide F¨
alle muss jeweils
ein zus¨
atzlicher Graph zur negativen Anwendungsbedingung hinzugef¨
ugt werden. Beide zus¨
atz-
lichen Graphen der negativen Anwendungsbedingung enthalten die Anwendungsbedingung als
Teilgraphen. ˆ
L1enth¨
alt dar¨
uber hinaus einen Knoten vom Typ BaseStation, der adjazent zu rp2
3.4. DAS SYSTEMMODELL 79
ist. Die Kante zwischen den beiden Knoten hat den Typ distributor. Der andere Graph, ˆ
L2, enth¨
alt
zus¨
atzlich einen Knoten vom Typ Shuttle. Zwischen diesem neuen Knoten und dem Knoten rp2
verl¨
auft eine Kante vom Typ publisher. Die erweiterte Regel ist in Abbildung 3.24 dargestellt.
!
#"
$%&$!
'
( !
)'
%*+,
)-.'
-! $,/01
'
&(12-.34
56'
7
899:
;4'
;! < 18
'
="
6(%&$ !
)-
-! $,/01
'
>
'
?9
#
!
'
#
>&
'
8@'
%*+,
A'
.1(-.3B
8-.'
-!1,01
)-
-! $,/01
'
="
9$%&$&
56'
7
899:
C DFEHGIEJE*KLFMFGON0P&QJN0RTS
'
!
>&
'
>
U
8@'
%*+,
A'
.1(-.3B
)6'
7
V:
;B'
;! < 1A)
'
="
9$%.$ !
)-.'
-! $,/01
?9
W#
>( !
)'
%*+,
'
#
!
'
>
A'
&(12-.34
)6'
7
V:
;4'
;! < 18
8-.'
-!1,I1
@'
="
$%&$!
;4'
;! < 18
Abbildung 3.24: Graphtransformationsregel deletePublication, die so angepasst wurde, dass ihre
Anwendung im DPOiso keine losen Kanten erzeugen kann
Mit dem Algorithmus extendNAC wird die negative Anwendungsbedingung einer Regel um
zus¨
atzliche Graphen erweitert, sodass die Regelanwendung die Lose-Kanten-Bedingung einh¨
alt.
Durch die Anwendung des Algorithmus k¨
onnen jedoch redundante Graphen entstehen. Deshalb
wird bei der Regelerweiterung zus¨
atzlich die Funktion minimizeNAC (siehe Abbildung C.2 in
Anhang C.1.1) verwendet. Enth¨
alt eine negative Anwendungsbedingung zwei Graphen ˆ
G1und
ˆ
G2, mit ˆ
G1ˆ
G2, dann wird ˆ
G2durch minimizeNAC gel¨
oscht. Dies ist m¨
oglich, da es immer,
wenn es einen Teilgraphisomorphismus gibt, der ˆ
G2auf einen Anwendungsgraphen abbildet,
auch einen Teilgraphisomorphismus gibt, der ˆ
G1auf den Anwendungsgraphen abbildet.
80 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
Definition 27. (Erweiterte Graphtransformationsregel)
F¨
ur eine Regel [L,ˆ
L]→rRund einen Typgraph GΩwird die negative Anwendungs-
bedingung der erweiterten Regel [L,ˆ
Le]→reRgebildet durch ˆ
Le:= minimizeNAC(ˆ
L ∪
extendNAC(L→rR,GΩ)).
Das folgende Lemma 5 zeigt, dass die Anwendung einer erweiterten Graphtransformations-
regel aus Definition 27 die Lose-Kanten-Bedingung erf¨
ullt.
Lemma 5. (Einhaltung der Lose-Kanten-Bedingung)
Wird eine typkonforme Regel [L,ˆ
L]→rRwie in Definition 27 erweitert und die erweiterte
Regel auf einen typkonformen Graphen Gim DPOiso angewendet, so erf¨
ullt die Regelanwendung
die Lose-Kanten-Bedingung.
3.4.3 Typisierte Graphtransformationssysteme
In Abschnitt 3.4.1 wurde gezeigt, wie UML-Modelle auf Graphen abgebildet werden k¨
onnen.
Dabei wurde ein Klassendiagramm auf einen Typgraphen und Objektdiagramme auf beschrif-
tete Graphen abgebildet, wobei die Typen erhalten wurden. Im anschließenden Abschnitt 3.4.2
wurden die ¨
Uberg¨
ange zwischen den Zust¨
anden durch Graphtransformationen beschrieben und
garantiert, dass eine Regel nur dann angewendet werden kann, wenn sie die Bedingungen des
DPOiso erf¨
ullt. Ein typisiertes Graphtransformationssystem besteht aus einem Typgraphen, einer
Menge von initialen Graphen und einer Menge von Graphtransformationsregeln.
Definition 28. (Typisiertes Graphtransformationssystem)
Ein typisiertes Graphtransformationssystem Sist ein Tupel S:= (G[GΩ],Gi
S,RS)mit
• G[GΩ]ist der Typgraph,
•(Gi
S,RS)ist ein Graphtransformationssystem wie in Definition 17 definiert,
• ∀r∈ RSgilt: rist typkonform zu GΩ.
Nach Theorem 1 ist ein derart spezifiziertes Graphtransformationssystem typkonform. Das
bedeutet, dass jeder der erreichbaren Zust¨
ande typkonform sind.
3.5 Erweiterte Graphtransformationen
Bisher wurden Graphtransformationsregeln immer in Vorw¨
artsrichtung auf Graphen angewen-
det. Um den Ansatz zur ¨
Uberpr¨
ufung von Graphtransformationssystemen, der in Abschnitt 3.7
eingef¨
uhrt wird, zu erm¨
oglichen, m¨
ussen die Regeln auch r¨
uckw¨
arts angewendet werden k¨
onnen.
Dar¨
uber hinaus m¨
ussen die Regeln auch auf Graphmuster anwendbar sein.
Die Transformation von Graphmustern sowie die R¨
uckw¨
artsanwendung von Regeln werden
deshalb in diesem Abschnitt vorgestellt.
3.5. ERWEITERTE GRAPHTRANSFORMATIONEN 81
3.5.1 R¨
uckw¨
artsanwendung von Graphtransformationsregeln
Bisher wurden Regeln so angewendet, dass die linke Regelseite die Anwendungsbedingung der
Regel beschrieben hat und die rechte Regelseite die Nachbedingung. Elemente, die Teil der lin-
ken, aber nicht der rechten Regelseite sind, werden bei der Regelanwendung gel¨
oscht. Elemente,
die zur rechten aber nicht zur linken Regelseite geh¨
oren, werden durch eine Regelanwendung
neu erzeugt.
Im Folgenden sollen Graphtransformationsregeln auch r¨
uckw¨
arts angewendet werden
k¨
onnen, d.h. die rechte Regelseite stellt die Anwendungsbedingung dar und die linke Regelsei-
te die Nachbedingung. Dementsprechend werden Elemente, die durch die Vorw¨
artsanwendung
erzeugt werden, bei der R¨
uckw¨
artsanwendung gel¨
oscht. Solche Elemente, die in der Vorw¨
arts-
richtung gel¨
oscht werden, werden in der R¨
uckw¨
artsrichtung neu erzeugt.
Wendet man eine Regel rauf einen Graphen Gan, so erh¨
alt man einen Graphen G0. Wird
auf G0die Regel rr¨
uckw¨
arts angewendet, so resultiert wieder der urspr¨
ungliche Graph G. Die
R¨
uckw¨
artsanwendung von rhat somit die Vorw¨
artsanwendung von rr¨
uckg¨
angig gemacht.
Damit eine Regel [L,ˆ
L]→rRim DPOiso korrekt r¨
uckw¨
arts angewendet werden kann, muss
ihre negative Anwendungsbedingung angepasst werden. Die negative Anwendungsbedingung
muss aus der linken Regelseite entfernt werden. Dies ist notwendig, da bei der R¨
uckw¨
artsan-
wendung aus der linken Regelseite die Nachbedingung der Regel wird und im DPOiso die Nach-
bedingung keine negative Anwendungsbedingung haben darf. Die zweite Modifikation besteht
darin, dass eine negative Anwendungsbedingung zu Rhinzugef¨
ugt werden muss. Dadurch wird
erreicht, dass die Regel nur dann r¨
uckw¨
arts auf einen Graphen anwendbar ist, wenn dieser Graph
durch Anwendung der Regel in Vorw¨
artsrichtung aus einem anderen Graphen entstanden sein
kann.
Die Anpassung der negativen Anwendungsbedingung erfolgt mittels des Algorithmus con-
vertNAC (siehe Abbildung C.4 in Anhang C.2.1). Der Algorithmus bestimmt alle Graphen der
negativen Anwendungsbedingung, die die Regelanwendung verhindern, wenn sonst lose Kan-
ten erzeugt werden. Diese Graphen, so wie alle, auf die ein solcher Graph abgebildet werden
kann, werden aus der negativen Anwendungsbedingung entfernt. Auf die verbleibenden Gra-
phen wird jeweils die Regel L→rRangewendet, d.h. die negative Anwendungsbedingung von
rwird nicht ber¨
ucksichtigt. Die resultierenden Graphen bilden einen Teil der neuen negativen
Anwendungsbedingung. Durch das L¨
oschen von Graphen aus ˆ
Lzu Beginn der Anpassung wird
erreicht, dass nur solche Graphen erhalten bleiben, auf die die Regel L→rRangewendet werden
kann, ohne dass die resultierenden Graphen lose Kanten enthalten. In einem letzten Schritt wird
ˆ
L−1, die negative Anwendungsbedingung der rechten Regelseite, um Graphen erweitert, die ei-
ne R¨
uckw¨
artsanwendung der Regel verhindern, wenn ansonsten lose Kanten entstehen. Dies ist
aus dem folgenden Grund notwendig. Kanten, die bei der R¨
uckw¨
artsanwendung gel¨
oscht wer-
den, sind solche, die bei der Vorw¨
artsanwendung erzeugt werden. Damit eine Kante bei der
R¨
uckw¨
artsanwendung zu einer losen Kante werden kann, muss einer ihrer Knoten durch die Re-
gel gel¨
oscht werden, d.h. der Knoten ist Teil von R, aber nicht von L. Die Kante selber darf jedoch
nicht Teil von Rsein. In diesem Fall w¨
urde sie aber auch nicht bei der Vorw¨
artsanwendung von
rerzeugt.
82 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
In Abbildung 3.25 ist die Regel moveSimpleNAC dargestellt. Die negative Anwendungsbe-
dingung der Regel besagt, dass das Shuttle nur dann von einem Track zum n¨
achsten weiterfahren
darf, wenn sich weder auf dem n¨
achsten noch auf dem ¨
ubern¨
achsten Track ein anderes Shuttle
befindet. Um die Graphen dieser negativen Anwendung zu invertieren, wird die Regel darauf
angewendet. Abbildung 3.26 zeigt die Regel mit invertierter negativer Anwendungsbedingung.
!#"$%'&
)(*+!#"$%'&
,& +(-.& /0$1/243
(*
(5
5
,& 76.& /0$1/243
8
9;:
+!#"$%'&
)(5+!#"$%'&
,& +(-.& /0$1/243
(5
(5
<& 5.& /0$1/243
8
9>=
?(-+!#"$%'&
,& +(-.& /0$1/243
(*
(*
5
9
@
)(*+!#"$%'&
,& 5.& /0$1/243
(*
(-
A BDC#E;FHGJIBLK>MNFPORQTS
Abbildung 3.25: Regel moveSimpleNAC
Die Invertierung einer Graphtransformationsregel wird folgendermaßen durchgef¨
uhrt (der
entsprechende Algorithmus reverse ist in Abbildung C.5 in Anhang C.2.1 abgebildet): Zun¨
achst
wird die negative Anwendungsbedingung mittels convertNAC transformiert. Um redundante
Graphen in der negativen Anwendungsbedingung auszuschließen, wird die negative Anwen-
dungsbedingung mittels minimizeNAC minimiert. Anschließend werden die linke und die rechte
Regelseite vertauscht, sodass die rechte Regelseite zusammen mit der invertierten negativen An-
wendungsbedingung die Anwendungsbedingung der invertierten Regel darstellt und die linke
Regelseite der urspr¨
unglichen Regel als Nachbedingung der invertierten Regel fungiert.
3.5. ERWEITERTE GRAPHTRANSFORMATIONEN 83
! "$#&%'(*)
+$
,
- .0/21436587.:9<;=3&>@?BADCFE
! "$#&%'(*)
G) HI) JKML@N
O
PRQ
H
! O$#&%'(*)
S) OI) MT'KMLDN
H
O
O
UQ
H
"$
O
S) OI) MT'KMLDN
G) I) JKML@N
V
U
Q
"
"
,
S) OI) MT'KMLDN
! H$#&%'(*)
G) +WI) JKML@N
V
U
Q
$#2%'(*)
$#&%'(*)
Abbildung 3.26: Regel moveSimpleNAC−1stellt die inverse Regel moveSimpleNAC dar
Definition 29 verwendet den Algorithmus reverse (siehe Abbildung C.5 in Anhang C.2.1),
um die inverse Regel r−1einer Regel rzu definieren.
Definition 29. (Invertierte Graphtransformationsregel)
Die inverse Regel [L−1,ˆ
L−1]→r−1R−1einer Graphtransformationsregel [L,ˆ
L]→rRim DPOiso
ist definiert als r−1=reverse(r,GΩ).
Die in Abbildung 3.26 dargestellte Regel moveSimpleNAC−1entspricht der inversen Regel
von moveSimpleNAC. Dabei entspricht der Graph L−1der urspr¨
unglichen rechten Regelseite
und R−1der urspr¨
unglichen linken Regelseite. Da keiner der beiden Graphen aus der negativen
Anwendungsbedingung durch einen Teilgraphisomorphismus auf einen Teilgraphen des anderen
abgebildet werden kann, ist die negative Anwendungsbedingung minimal.
Gegeben sind zwei Graphen G,G0∈ G, wobei G0resultiert, wenn die Graphtransformations-
regel rauf Gangewendet wird, d.h. G|=⇒rG0. Ist r−1das Inverse von r, so resultiert die An-
wendung von r−1auf G0wieder in G, d.h. G0|=⇒r−1G. Die Anwendung der inversen Regel hat
also die Anwendung der urspr¨
unglichen Regel r¨
uckg¨
angig gemacht. Diese Eigenschaft inverser
Regeln ist in Theorem 2 festgehalten.
Theorem 2. (R¨
uckw¨
artsanwendung einer Graphtransformationsregel im DPOiso)
F¨
ur jede Graphtransformationsregel [L,ˆ
L]→rR, ihr Inverses [L−1,ˆ
L−1]→r−1R−1und ein Auf-
treten ovon rin G1gilt im DPOiso:
G1|=⇒(r,o)G2⇔G2|=⇒(r−1,o−1)G1.
84 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
3.5.2 Transformationen von Graphmustern
Graphmuster k¨
onnen dazu verwendet werden, um Mengen von Graphen zu beschreiben. Soll
f¨
ur diese Graphmengen gepr¨
uft werden, welche Auswirkung die Anwendung einer bestimmten
Graphtransformationsregel hat, so ist es notwendig, die Regel statt auf jeden der Graphen auf das
entsprechende Graphmuster anzuwenden. Die Anwendung einer Regel runter dem Auftreten o
auf ein Graphmuster presultiert wieder in einem Graphmuster, p0. Wird die Regel unter ostatt auf
pauf einen Graphen angewendet, der perf¨
ullt, also in der Menge G[p]enthalten ist, so resultiert
die Anwendung in einem Graphen, der p0erf¨
ullt und somit zur Menge G[p0]geh¨
ort.
Um eine Graphtransformationsregel [L,ˆ
L]→rRauf ein Graphmuster p:= [P,ˆ
P]anwenden
zu k¨
onnen, muss die Regelanwendung etwas modifiziert werden. Die linke Regelseite muss im-
mer durch ein Muster beschrieben werden, wobei die Menge ˆ
Lleer sein darf. Die Regel ist
anwendbar, wenn das Muster der linken Regelseite ein Teilgraphmuster des zu ver¨
andernden
Graphmusters ist. Ist diese Bedingung erf¨
ullt, so wird die Regel L→r0Rauf den Graphen Pan-
gewendet. Die negative Anwendungsbedingung ˆ
Pdes Graphmusters wird durch den Aufruf der
Methode convertNAC (s.o. und Abbildung C.4 in Anhang C.2.1) transformiert.
Definition 30. (Direkte Transformationen von Graphmustern im DPOiso)
F¨
ur eine Graphtransformationsregel [L,ˆ
L]→rRund ein Graphmuster p= [P,ˆ
P], wo-
bei [L,ˆ
L]ein Teilgraphmuster von pist ([L,ˆ
L]⊆[P,ˆ
P]), gilt im DPOiso, dass die An-
wendung von rauf pin einem Graphmuster p0= [P,ˆ
P0]resultiert mit P|=⇒rP0und
ˆ
P0=convertNAC([P,ˆ
P],[L,ˆ
L]→rR,GΩ).
Im Folgenden wird die Schreibweise p|=|=⇒rp0verwendet, wenn die Anwendung der Regel
rauf ein Graphmuster pin einem Graphmuster p0resultiert.
Theorem 3 zeigt, dass Regelanwendungen, die auf Mustern m¨
oglich sind, auch auf Graphen
m¨
oglich sind, die diese Muster erf¨
ullen. Außerdem wird gezeigt, dass die Anwendung einer
Regel auf ein Muster den gleichen Effekt hat wie bei der Anwendung auf einen Graphen, der
dieses Muster erf¨
ullt.
Theorem 3. (Transformation von Graphmustern)
F¨
ur eine Graphtransformationsregel [L,ˆ
L]→rRund zwei Graphmuster
p:= [P,hatP],p0:= [P0,ˆ
P0]gilt im DPOiso:
(p|=|=⇒rp0)
⇔
(∀G1,G2∈ G,iso ∈ ISO :P∪P0→G1∪G2: (G1|=p∧G1|=⇒r,iso|L∪RG2)⇒(G2|=p0)).
In Theorem 2 wurde f¨
ur eine Regel rund ihr Inverses r−1gezeigt, dass die Anwendung von r
auf einen Graphen Gdurch die Anwendung von r−1auf den durch rerzeugten Graphen wieder in
Gresultiert. Unter Verwendung der Theoreme 2 und 3 kann gezeigt werden, dass dieses Ergebnis
auch f¨
ur Graphmuster gilt.
3.6. SYSTEMEIGENSCHAFTEN UND INVARIANTEN 85
Theorem 4. (R¨
uckw¨
artsanwendung von Regeln auf Graphmuster)
F¨
ur eine Graphtransformationsregel [L,ˆ
L]→rR, ihr Inverses [L−1,ˆ
L−1]→r−1R−1, zwei Gra-
phmuster p:= [P,ˆ
P]und p0:= [P0,ˆ
P0]und ein Auftreten o:L∪R7→P∪P0gilt im DPOiso:
(p|=|=⇒(r,o)p0)⇔(p0|=|=⇒(r−1,o−1)p).
3.6 Systemeigenschaften und Invarianten
In Abschnitt 3.3 wurden Graphmuster eingef¨
uhrt. Diese Graphmuster sollen dazu verwendet
werden, strukturelle Eigenschaften eines Graphtransformationssystems zu beschreiben.
Die Idee, Grapheigenschaften mittels einfacher Graphmuster zu formulieren, haben Rensink
et al. in [RSV04] beschrieben. Sie nennen die Graphmuster Eigenschaftsgraphen und haben ge-
zeigt, dass ihre Ausdrucksst¨
arke ¨
aquivalent zum ∃ 6 ∃-Teil von ∀-freien logischen Formeln erster
Ordnung mit bin¨
aren Pr¨
adikaten ist.
Graphmuster k¨
onnen entweder gefordert oder verboten sein. Geforderte Graphmuster be-
schreiben Eigenschaften, die immer erf¨
ullt sein m¨
ussen. Dem gegen¨
uber stehen die verbotenen
Graphmuster; sie beschreiben Eigenschaften, die nie erf¨
ullt sein d¨
urfen.
In Grapheigenschaftsformeln stellen die Graphmuster die atomaren Eigenschaften dar.
Definition 31. (Grapheigenschaftsformel)
Eine Grapheigenschaftsformel φist entweder
•eine atomare Eigenschaft, die durch ein Graphmuster pbeschrieben und als gefordertes
Graphmuster bezeichnet wird oder
•eine atomare Eigenschaft, die durch das negierte Graphmuster ¬pdes Graphmusters p
definiert ist. Diese Eigenschaft wird als verbotenes Graphmuster bezeichnet oder
•eine zusammengesetzte Eigenschaft, gegeben durch φ∧ψoder φ∨ψ, wobei φund ψGra-
pheigenschaftsformeln sind.
Wann eine solche Grapheigenschaftsformel von einem Graphen erf¨
ullt ist, ist folgenderma-
ßen definiert:
Definition 32. (Semantik von Grapheigenschaftsformeln)
Ob ein Graph G∈ G eine Grapheigenschaftsformel θerf¨
ullt, ist ¨
uber die Struktur der Formel,
bestehend aus ihren atomaren Eigenschaften pi:= [Pi,ˆ
Pi]und Teilformeln φund ψ, folgender-
maßen definiert:
•G|=pgdw. ∃tiso ∈ T ISO[Pi,G] : Pitiso Gund G,Pi,tiso `ˆ
Pi,
•G|=¬φgdw. G6|=φ,
•G|=φ∧ψgdw. G|=φund G|=ψund
•G|=φ∨ψgdw. G|=φoder G|=ψ.
86 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
F¨
ur eine Menge Gvon Graphen und eine Menge Rvon Graphtransformationsre-
geln k¨
onnen die Eigenschaften dazu verwendet werden, die Graphen und Transformatio-
nen in verschiedene Mengen zu unterteilen. Bei den Graphen bezeichnet beispielsweise G[φ]
die Menge aller Graphen, die die Eigenschaft φerf¨
ullen, d.h. G[φ] := {G∈ G | G|=φ}.
¨
Uberf¨
uhrt eine Graphtransformation einen Graphen, der φerf¨
ullt, in einen Graphen, der
ψerf¨
ullt, so geh¨
ort die Transformation zur Menge T[φ, ψ]. Diese Menge ist definiert als
T[φ, ψ] := {r∈ R | ∃Gφ∈ G[φ],Gψ∈ G[ψ] : Gφ|=⇒rGψ}.
Ein Systemzustand, gegeben als (typisierter) Graph, ist korrekt im Bezug auf eine Syste-
meigenschaftsformel φ, wenn gilt G|=φ, d.h. geforderte Graphmuster sind in Genthalten und
verbotene Graphmuster sind nicht in Genthalten. Das gesamte System S:= (G[GΩ],Gi
S,RS)ist
korrekt (S|=φ), wenn alle Startgraphen aus Gi
Ssowie alle erreichbaren Graphen von Skorrekt
sind. Ist Skorrekt bez¨
uglich φ, so ist φeine operationale Invariante des Systems. Die formale
Definition von operationalen Invarianten stammt aus [Cha03] und lautet4:
Definition 33. (Operationale Invariante)
Eine Eigenschaft φist eine operationale Invariante eines Graphtransformationssystems
S:= (G[GΩ],Gi
S,RS)wenn gilt:
• ∀Gi∈ Gi
S:Gi|=φund
• ∀G∈REACH(S) : G|=φ.
Die ¨
Uberpr¨
ufung operationaler Invarianten ist jedoch f¨
ur den allgemeinen Fall aus verschie-
denen Gr¨
unden nicht m¨
oglich. Ein Grund daf¨
ur ist, dass die hier betrachteten Systeme unend-
lich viele Zust¨
ande haben k¨
onnen. Ein zweiter Grund ist, dass die Menge der Initialgraphen zum
Zeitpunkt der Verifikation noch nicht bekannt sein muss, bzw. dass sie sich noch ver¨
andern kann.
Sobald die Verifikation abgeschlossen ist, kann jedoch nur dann ein neuer Startgraph zur Men-
ge hinzugef¨
ugt werden, wenn auch ausgehend von diesem alle erreichbaren Graphen korrekt
sind, d.h. eine weitere Erreichbarkeitsanalyse ist erforderlich. Dadurch entsteht ein erheblicher
Aufwand.
Aus diesen Gr¨
unden sollen im Folgenden statt der operationalen Invarianten induktive Inva-
rianten betrachtet werden. Bei der ¨
Uberpr¨
ufung, ob eine Eigenschaft eine induktive Invariante
ist, wird die Erreichbarkeit eines Zustands außer Acht gelassen. Stattdessen wird ¨
uberpr¨
uft, ob
jeder korrekte Zustand durch die Anwendung einer beliebigen Regel wieder in einen korrekten
Zustand ¨
uberf¨
uhrt wird.
Definition 34. (Induktive Invariante)
Eine Eigenschaft φist eine induktive Invariante eines Systems S:= (G[GΩ],Gi
S,RS), falls
gilt: ∀G1,G2∈ G[GΩ],r∈ RS: (G1|=⇒rG2∧G1|=φ)⇒(G2|=φ).
Ist φeine induktive Invariante und wird φzus¨
atzlich von allen Startgraphen erf¨
ullt,
d.h. ∀Gi∈ Gi
S:Gi|=φ, dann ist φauch eine operationale Invariante. Umgekehrt ist jedoch nicht
jede operationale Invariante auch eine induktive.
4Die Bezeichnungen der Eigenschaften sind in der Literatur nicht eindeutig. So werden beispielsweise die opera-
tionalen Invarianten von Kindler in [Kin95] als invariante Eigenschaften bezeichnet und die induktiven Invarianten
als induktive Eigenschaften.
3.6. SYSTEMEIGENSCHAFTEN UND INVARIANTEN 87
Um zu zeigen, dass φeine induktive Invariante eines Graphtransformationssystems
S:= (G[GΩ],Gi
S,RS)ist, muss gezeigt werden, dass die Anwendung einer Regel r∈ RSauf
einen beliebigen korrekten Graphen Gφ∈ G[φ]einen korrekten Graphen G0
φ∈ G[φ]erzeugt. Das
bedeutet, φist genau dann eine induktive Invariante von S, wenn es keine Transformation gibt,
die einen Graphen Gφ∈ G[φ]in einen Graphen G¬φ∈ G[¬φ]transformiert und somit die Menge
T[φ, ¬φ]leer ist. Dieses Ergebnis ist in Lemma 6 festgehalten.
Lemma 6. (Eigenschaften induktiver Invarianten)
Eine Eigenschaft φist eine induktive Invariante eines Systems S:= (GΩ,Gi
S,RS), falls
T[φ, ¬φ] = ∅.
3.6.1 Sicherheitseigenschaften
Eine spezielle Art von Grapheigenschaftsformeln, die im Folgenden eine besondere Rolle spie-
len, sind die Sicherheitseigenschaften. Eine solche Sicherheitseigenschaft φSwird durch eine
Menge von verbotenen Graphmustern beschrieben, wobei jedes dieser verbotenen Graphmuster
einen Unfall oder eine kritische Situation des Systems beschreibt. Die Normalform einer Sicher-
heitseigenschaft sieht folgendermaßen aus:
φs:= ^
k∈K
(¬pk).
Ein Beispiel f¨
ur eine solche Sicherheitseigenschaft ist φs:= ¬impendingCollision, wobei das
Graphmuster impendingCollision dem in Abbildung 3.27 gegebenen Graphmuster entspricht. Die
Eigenschaft beschreibt, dass sich niemals zwei Shuttles auf benachbarten Tracks befinden d¨
urfen,
wenn sie nicht eine Instanz des DistanceCoordination-Musters ausf¨
uhren.
!#" $&%
'()##*+
,-.
,- !#" $&%
/10
2,34 5
/10
"6798 +%:#;
0
<=">8?%:@8 >%
A=#B4>
2,-
+
.,-.=::
,- !#" $&%
3 <#*" $C%
'()##*+
DED=>%'B4>
Abbildung 3.27: Sicherheitseigenschaft impendingCollision
Jede so dargestellte Sicherheitseigenschaft kann auch durch ¬φS=Wj∈J(pj)ausgedr¨
uckt
werden. Um diese Formel zu erf¨
ullen, gen¨
ugt ein einzelnes lokales Auftreten einer solchen kri-
tischen Situation, spezifiziert durch ein verbotenes Graphmuster. Ein solches Auftreten eines
verbotenen Graphmusters wird im Folgenden als Zeuge bezeichnet.
88 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
3.6.2 Beschr¨
ankung auf Gegenbeispiele
Um zu zeigen, dass eine Sicherheitseigenschaft der Form ¬φ:= Wj∈Jpjkeine induktive Invari-
ante eines Systems ist, ist es ausreichend eine Transformation zu finden, die zur Menge T[φ, ¬φ]
geh¨
ort. Das bedeutet, es existiert ein Graph G¬φ, der eines der verbotenen Graphmuster pider Si-
cherheitseigenschaft enth¨
alt (G¬φ|=pi) und dieser Graph ist das Resultat der Anwendung einer
Regel rauf einen Graphen Gφ, der keines der verbotenen Graphmuster enth¨
alt (∀j∈J:Gφ6|=pj).
In diesem Fall bilden die beiden Graphen Gφund G¬φein Gegenbeispiel, das zeigt, dass die an-
gewendete Regel die Eigenschaft φverletzen kann. F¨
ur die ¨
Uberpr¨
ufung der Korrektheit eines
Systems bedeutet dies, dass die Verifikation abgebrochen werden kann, sobald ein solches Ge-
genbeispiel gefunden wurde; dies ist in Lemma 7 festgehalten.
Lemma 7. (Zeugen widerlegen Sicherheitseigenschaften)
F¨
ur eine Sicherheitseigenschaft der Form Vj∈J(¬pj)und ein System S:= (G[GΩ],Gi
S,RS)ist
die Menge T[φ, ¬φ]genau dann nicht leer und somit das System inkorrekt, wenn gilt:
∃Gφ,G¬φ∈ G[GΩ],r∈ RS,o∈ ISO :
(Gφ|=⇒(r,o)G¬φ)∧(∃i∈J:G¬φ|=pi)∧(∀j∈J:Gφ6|=pj).(3.5)
3.7 Nachweis von induktiven Invarianten
Unter Zuhilfenahme der bisher vorgestellten Ergebnisse kann jetzt gezeigt werden, dass es aus-
reicht, eine endliche Menge von Repr¨
asentanten zu betrachten, um nachzuweisen, dass eine Si-
cherheitseigenschaft eine induktive Invariante eines Graphtransformationssystems ist. Die theo-
retischen Ergebnisse werden in einem Algorithmus umgesetzt, der automatisch f¨
ur eine Eigen-
schaft ¨
uberpr¨
uft, ob die Eigenschaft eine induktive Invarianten des Systems ist (siehe dazu Ab-
schnitt 5.3).
3.7.1 Theoretische Ergebnisse
F¨
ur den Nachweis, dass eine Sicherheitseigenschaft φSeine induktive Invariante eines Graph-
transformationssystems ist, wurde in Lemma 7 gezeigt, dass die Menge der Transformationen,
die einen korrekten Zustand in einen inkorrekten ¨
uberf¨
uhren, leer sein muss. Um nachzuweisen,
dass diese Menge leer ist, m¨
ussten jedoch unter Umst¨
anden unendliche viele Transformationen
betrachtet werden. Im Folgenden wird das Ergebnis aus Lemma 7 ausgenutzt, um mittels einer
endlichen minimalen Menge von Repr¨
asentanten die Systemkorrektheit nachzuweisen.
Als Repr¨
asentanten dienen dabei die in Definition 19 eingef¨
uhrten Graphmuster. Mit Hilfe
der Graphmuster wird f¨
ur jede der Graphtransformationsregeln einzeln gepr¨
uft, ob sie korrekt
ist. Eine wichtige Voraussetzung, um diese Art der ¨
Uberpr¨
ufung durchf¨
uhren zu k¨
onnen, ist, dass
die Anwendung einer Graphtransformationsregel nur Auswirkungen auf den Teil des Graphen
hat, auf den sie durch den Match abgebildet wird. Deshalb ist es nicht notwendig, vollst¨
andige
Graphen zu ¨
uberpr¨
ufen. Stattdessen reicht es aus, wenn nur der Ausschnitt des Anwendungs-
3.7. NACHWEIS VON INDUKTIVEN INVARIANTEN 89
und Zielgraphen betrachtet wird, der durch die Regelanwendung ver¨
andert wird und dadurch
die G¨
ultigkeit der Eigenschaft beeinflussen kann. Die Anwendung einer Regel rkann nur dann
die G¨
ultigkeit der Eigenschaft beeinflussen, wenn sie einen Zeugen f¨
ur eines der verbotenen
Graphmuster erzeugt.
Der Teil des Anwendungsgraphen, der durch die Regelanwendung ver¨
andert wird, also auf
den die linke Regelseite abgebildet wird, kann als Graphmuster kodiert werden. Ebenso ist es
m¨
oglich, den Teil des Zielgraphen, der sich durch die Regelanwendung ver¨
andert hat, d.h. auf
den die rechte Regelseite abgebildet werden kann, als Graphmuster zu kodieren. Verwendet man
solche Graphmuster statt vollst¨
andiger Graphen, so kann die Frage, ob die Menge T[φS,¬φS]
leer und das System somit korrekt bez¨
uglich φSist, lokal beantwortet werden.
Die Idee besteht darin, ein Graphmuster, das so genannte Ergebnisgraphmuster, so zu
w¨
ahlen, dass es als Teilgraphmuster ein verbotenes Graphmuster enth¨
alt und somit inkorrekt
ist. F¨
ur dieses Ergebnisgraphmuster wird gepr¨
uft, ob es das Ergebnis einer Regelanwendung auf
ein korrektes Graphmuster ist. Dazu wird die Regel invertiert und das Inverse auf das Ergebnis-
graphmuster angewendet. Das resultierende Graphmuster wird als Startgraphmuster bezeichnet.
Ist dieses Startgraphmuster korrekt, so konnte ein Gegenbeispiel gefunden werden, das zeigt,
dass die Regel ein korrektes Graphmuster in ein inkorrektes ¨
uberf¨
uhren kann. Dies bedeutet aber
auch, dass ein korrekter Graph, der das Startgraphmuster als Teilgraphmuster enth¨
alt, durch die
betrachtete Regel in einen inkorrekten Graphen transformiert wird.
Ein Ergebnisgraphmuster erf¨
ullt zum einen ein verbotenes Graphmuster pj:= [Pj,ˆ
Pj]und
enth¨
alt zum anderen die rechte Seite einer Graphtransformationsregel r. Damit die Anwendung
von rdas verbotene Graphmuster pjerzeugt haben kann, muss entweder Pjoder ein ˆ
Pj∈ˆ
Pj
durch die Regel beeinflusst werden. Im ersten Fall muss durch die Regel mindestens ein Element
erzeugt werden, das Teil von Pjist. Im zweiten Fall gibt es vor der Regelanwendung einen Teil-
graphisomorphismus der Pjauf das Anwendungsgraphmuster abbildet. Zus¨
atzlich kann dieser
Teilgraphisomorphismus so erweitert werden, dass er auch einen Graphen ˆ
Pjaus der negativen
Anwendungsbedingung von pjauf die Anwendungsbedingung des Anwendungsgraphmusters
abbildet. Die Regelanwendung l¨
oscht dann ein Element aus ˆ
Pj\Pj, sodass nach der Regelan-
wendung ein Teilgraphisomorphismus existiert, der Pjauf den resultierenden Graphen abbildet.
Dieser Teilgraphisomorphismus kann aber nicht so erweitert werden, dass er auch ˆ
Pjauf das
resultierende Graphmuster abbildet.
F¨
ur den zweiten Fall gilt: Ist das gel¨
oschte Element eine Kante, so bleiben ihre inziden-
ten Knoten bei der Regelanwendung erhalten. Diese Knoten sind dann sowohl Teil der linken
als auch der rechten Regelseite und auch in ˆ
Pjenthalten. Wird ein Knoten gel¨
oscht, so m¨
ussen
alle seine inzidenten Kanten ebenfalls explizit durch die Regel gel¨
oscht werden. F¨
ur jeden Kno-
ten n∈Nˆ
Pj\NPjgilt nach Definition 15, dass er ¨
uber einen Pfad πmit einem Knoten n0∈Pj
verbunden ist. Da die Regelanwendung keinen Einfluss auf Pjhat, muss n0auch nach der Re-
gelanwendung erhalten sein. Ist nadjazent zu n0, so wird n0explizit durch die Regelanwendung
erhalten und ist somit Teil sowohl der linken als auch der rechten Regelseite. Andernfalls gibt es
entweder einen Knoten n00, der auf dem Pfad zwischen nund n0liegt, d.h. n7→π0n00 7→π00 n0, und
bei der Regelanwendung erhalten bleibt. Dann ist dieser Knoten Teil der linken und rechten Re-
gelseite. Oder alle Knoten, die auf dem Pfad πliegen und Teil von ˆ
Pj\Pjsind, werden gel¨
oscht.
90 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
In diesem Fall ist n00 adjazent zu n0, wobei n0durch die Regel erhalten bleibt. Dieses Ergebnis
wird in Lemma 8 festgehalten.
Lemma 8. (Gemeinsame Elemente von Graphtransformationsregeln und Graphmustern)
F¨
ur eine Graphtransformationsregel [L,ˆ
L]→rRund ein Graphmuster p:= [P,ˆ
P]gilt im
DPOiso:
∀G,G0∈ G,o∈ ISO :G|=⇒(r,o)G0∧G6|=op∧G0|=iso p
⇒
((R\L)∩o(P)6=∅)∨(∃iso ∈ ISO,ˆ
P∈ˆ
P:iso |P=o|P∧L∩R∩ˆ
P6=∅).(3.6)
Das Ergebnis aus Lemma 8 wird im Folgenden dazu genutzt, um Ergebnisgraphmus-
ter zu bilden. Da auf ein Ergebnisgraphmuster die entsprechende Regel r¨
uckw¨
arts angewen-
det werden soll, wird zur Bildung des Musters statt der Regel [L,ˆ
L]→rRihre inverse Regel
[L−1,ˆ
L−1]→r−1R−1verwendet. Das Ergebnisgraphmuster setzt sich dann zusammen aus den bei-
den Graphmustern [L−1,ˆ
L−1]und einem Zeugen p:= [P,ˆ
P]f¨
ur ein verbotenes Graphmuster aus
der Sicherheitseigenschaft φ:= Vk∈Kpk. Nach Lemma 8 gibt es zwei M¨
oglichkeiten, ein solches
Ergebnisgraphmuster egm := [EGM,ˆ
EGM]zu erzeugen.
Die erste M¨
oglichkeit betrachtet den Fall, dass die Anwendung von r P erzeugt. Das be-
deutet, dass die inverse Regel ein Element l¨
oscht, das Teil von Pist. Deshalb werden die
Graphen L−1und Pso zu einem Graphen EGM zusammengef¨
ugt, dass mindestens eines der
durch r−1gel¨
oschten Elemente auch Teil von Pist, d.h. es gibt einen Teilgraphisomorphismus
tiso ∈ T ISO, der Elemente von Pauf Elemente von L−1abbildet, wobei mindestens ein Knoten
aus Pauf einen Knoten aus (NL−1\NR−1)oder eine Kante aus Pauf eine Kante aus (EL−1\ER−1)
abgebildetwird. Zus¨
atzlichdarf es wedereinen Graphen inder negativenAnwendungsbedingung
ˆ
L−1von r−1noch in der negativen Anwendungsbedingung ˆ
Pvon pgeben, der auf einen Teil von
EGM durch einen Teilgraphisomorphismus abgebildet werden kann.
Um die negative Anwendungsbedingung ˆ
EGM zu bilden, wird sowohl f¨
ur jeden Graphen aus
ˆ
L−1als auch f¨
ur jeden Graphen aus ˆ
Pmindestens ein neuer Graph f¨
ur die negative Anwendungs-
bedingung erzeugt. Betrachtet man einen Graphen ˆ
L−1∈ˆ
L−1und den Graph P, so wird f¨
ur diese
beiden Graph folgendermaßen eine Menge von Graphen der negativen Anwendungsbedingung
gebildet. Es werden alle Teilgraphisomorphismen tiso0bestimmt, die einen nicht leeren Teilgra-
phen von Pauf einen Teilgraphen von ˆ
L−1abbilden. F¨
ur jeden dieser Isomorphismen gilt, dass
er alle Elemente von P, die durch tiso auf Elemente auf L−1abgebildet werden, auf dieselben
Elemente abgebildet, d.h. tiso0−1|L=tiso−1. Mit Hilfe dieser Teilgraphisomorphismen werden
dann die beiden Graphen zu einem vereinigt. Dabei besteht ein Graph ˆ
EGM zun¨
achst aus allen
Elementen von ˆ
L−1. Alle Elemente aus P, die nicht durch tiso0auf Elemente aus ˆ
L−1abgebildet
werden k¨
onnen, werden hinzugef¨
ugt. Auf diese Weise entsteht eine Menge von Graphen.
Diese Menge kann unter Umst¨
anden noch reduziert werden. Nach Definition 15 muss jeder
Graph der negativen Anwendungsbedingung die Anwendungsbedingung enthalten und diese um
mindestens ein Element erweitern. Durch die Verwendung von tiso0k¨
onnen Graphen resultieren,
die isomorph zur Anwendungsbedingung sind. Diese Graphen m¨
ussen aus der negativen An-
wendungsbedingung entfernt werden. Außerdem gilt: Enth¨
alt die Menge ein Graphenpaar ˆ
EGM1
3.7. NACHWEIS VON INDUKTIVEN INVARIANTEN 91
und ˆ
EGM2und existiert ein Teilgraphisomorphismus, der ˆ
EGM1auf einen Teilgraphen von ˆ
EGM2
abbildet ( ˆ
EGM1ˆ
EGM2), dann kann ˆ
EGM2aus der Menge entfernt werden. Dies ist m¨
oglich,
da immer, wenn es einen Teilgraphisomorphismus gibt, der ˆ
EGM2auf einen Graphen oder ein
Graphmuster abbildet, dieser Teilgraphisomorphismus auch dazu verwendet werden kann, um
ˆ
EGM1auf den Graphen/das Graphmuster abzubilden. Die Bildung der Graphen bestehend aus
einem Graphen ˆ
P∈ˆ
Pund der Anwendungsbedingung L−1wird analog durchgef¨
uhrt. Auf diese
Weise wird erreicht, dass EGM ein Teilgraph von jedem ˆ
EGM ∈ˆ
EGM ist und ˆ
EGM somit eine
korrekte negative Anwendungsbedingung ist.
Abbildung 3.28(a) zeigt das Inverse der Regel moveSimpleNAC
([L−1,ˆ
L−1]→moveSimpleNAC−1R−1), Abbildung 3.28(b) zeigt das verbotene Muster impen-
dingCollision := [IC,ˆ
IC].
Ein m¨
ogliches Ergebnisgraphmuster f¨
ur die Regel und das verbotene Muster ist in Abbil-
dung 3.29 dargestellt. Dieses Ergebnisgraphmuster beschreibt den Fall, dass die Anwendung
der Regel moveSimpleNAC das verbotene Muster erzeugt, indem die Anwendungsbedingung
des verbotenen Musters vervollst¨
andigt wird. Das bedeutet, dass es Knoten oder Kanten in der
Nachbedingung der Regel gibt, die bei der Regelanwendung neu erzeugt werden (und somit zu
(NR\NL)bzw. (ER\EL)geh¨
oren) und zus¨
atzlich auch durch einen Teilgraphisomorphismus
tiso ∈ T ISO auf einen Teil von Pabgebildet werden k¨
onnen. Da zur Bildung des Ergebnisgra-
phmusters die inverse Regel verwendet wird, m¨
ussen die Elemente durch die Regelanwendung
gel¨
oscht werden; sie sind somit Teil von NL−1\NR−1bzw. EL−1\ER−1.
Im Beispiel wird durch rnur die rlo2:locatedOn erzeugt. Auf diese Kante kann durch einen
Teilgraphisomorphismus die Kante vlo1des verboten Graphmusters abgebildet werden. Da f¨
ur
eine Kante der Start- und der Zielknoten eindeutig festgelegt ist, muss der Teilgraphisomorphis-
mus auch den Knoten vs11:Shuttle auf rs1:Shuttle und den Knoten vt1:Track auf rt2:Track
abbilden. Der im Beispiel verwendete Teilgraphisomorphismus bildet zus¨
atzlich noch den Kno-
ten vt2 :Track auf den Knoten rt3:Track ab und die Kanten vsu :successor auf rsu2:successor.
Das Ergebnisgraphmuster egm := [EGM,ˆ
EGM]wird nun folgendermaßen gebildet. F¨
ur
EGM werden mit Hilfe des Teilgraphisomorphismus tiso die beiden Graphen L−1und IC der
Regel bzw. des verbotenen Musters vereint. Das bedeutet, dass EGM zun¨
achst aus dem Graph
L−1besteht. Alle Elemente, die durch tiso nicht auf Elemente aus L−1abgebildet werden, werden
zu EGM hinzugef¨
ugt. Das Ergebnisgraphmuster ist in Abbildung 3.29 dargestellt.
Um die Graphen der negativen Anwendungsbedingung zu bilden, m¨
ussen alle Graphen der
negativen Anwendungsbedingung der inversen Graphtransformationsregel sowie des verbotenen
Graphmusters betrachtet werden. In diesem Beispiel besteht die negative Anwendungsbedingung
von r−1aus den beiden Graphen ˆ
L−1
1und ˆ
L−1
2und die negative Anwendungsbedingung des verbo-
tenen Graphmusters aus dem Graphen ˆ
IC. F¨
ur jeden dieser drei Graphen m¨
ussen neue Graphen
gebildet werden. Der Graph ˆ
EGM1wird aus den Graphen ˆ
L−1
1und IC gebildet. Dazu werden
alle Teilgraphisomorphismen bestimmt, die einen Teilgraph von IC auf einen Teilgraphen von
ˆ
L−1
1abbilden. Diese Teilgraphisomorphismen m¨
ussen alle Elemente von IC, die durch den zuvor
bestimmten tiso auf Elemente aus L−1abgebildet werden, auf dieselben Elemente abbilden. In
diesem Beispiel ist das nur der Teilgraphisomorphismus tiso.ˆ
EGM1besteht dann zun¨
achst aus
ˆ
L−1
1. Alle Elemente aus IC, die nicht durch tiso auf Elemente aus ˆ
L−1
1abgebildet werden, werden
92 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
! "$#&%'(*)
+$
,
- .0/21436587.:9<;=3&>@?BADCFE
! "$#&%'(*)
G) HI) JKML@N
O
PRQ
H
! O$#&%'(*)
S) OI) MT'KMLDN
H
O
O
UQ
H
"$
O
S) OI) MT'KMLDN
G) I) JKML@N
V
U
Q
"
"
,
S) OI) MT'KMLDN
! H$#&%'(*)
G) +WI) JKML@N
V
U
Q
$#2%'(*)
$#&%'(*)
(a) Die inverse Regel moveSimpleNAC−1
!#" $&%
'()##*+
,-.
,- !#" $&%
/10
2,34 5
/10
"6798 +%:#;
0
<=">8?%:@8 >%
A=#B4>
2,-
+
.,-.=::
,- !#" $&%
3 <#*" $C%
'()##*+
DED=>%'B4>
(b) Verbotenes Graphmuster impendingCollision
Abbildung 3.28: Regel moveSimpleNAC, deren Korrektheit im Bezug auf das verbotene Gra-
phmuster impendingCollision ¨
uberpr¨
uft werden soll
zu ˆ
EGM1hinzugef¨
ugt. F¨
ur ˆ
L−1
2und IC gibt es zwei Teilgraphisomorphismen, die die geforder-
ten Eigenschaften erf¨
ullen. Deshalb entstehen die beiden Graphen ˆ
EGM2und ˆ
EGM3.ˆ
EGM2ist in
Abbildung 3.29 mit gestricheltem Rand dargestellt. Der Grund daf¨
ur ist, dass ˆ
EGM3ein Teilgraph
von ˆ
EGM2ist, somit braucht ˆ
EGM2nicht in die negative Anwendungsbedingung aufgenommen
werden. ˆ
EGM4ist der Graph, der aus der Vereinigung von L−1und ˆ
IC resultiert.
3.7. NACHWEIS VON INDUKTIVEN INVARIANTEN 93
!"#
%$
&(')'
*#+",
'
#
-.
/
'
.0
'
"!
)1
#
'
0
'
"!
)1
#
2342
5
5-
'
-67
"
98
:
;"
=<
'
>
>
'
#
<
'
2?%2
5
@
'
.!7
"
+8
*A7
"
98
B
CEDGFIH
.
-
-
,6
.
CDGF
-67
"
98
-.
'
0
'
"!
)1
#
/
'
.0
'
"!
)1
#
B
CDGF
-67
"
98
*A7
"
98
.!7
"
+8
*A7
"
98
2342
5
5-
'
2?%2
5
@
'
J9.4J
@
@
'
2?%2
5
@
'
7
"
98
'
.0
'
"!
)1
#
'
.0
'
"!
)1
#
/
'
0
'
"!
)1
#
-7
"
+8
J?4J
@
@
'
J962
5
@
'
.!7
"
98
.-.7
"
+8
B
CEDGF
'
.0
'
"!
)1
#
-.7
"
+8
'
.0
'
"!
)1
#
J3J
@
@
'
292
5
@
'
.!.7
"
98
.-7
"
+8
B
CEDGF3K
/
'
.0
'
"!
)1
#
L
'
0
'
"!
)1
#
L
'
0
'
"!
)1
#
Abbildung 3.29: Ein m¨
ogliches Ergebnisgraphmuster f¨
ur die Regel moveSimpleNAC und das
verbotene Graphmuster impendingCollision
Auf diese Weise muss f¨
ur jeden Teilgraphisomorphismus, der ein oder mehrere durch die
Regel neu erzeugte Elemente auf ein verbotenes Graphmuster abbildet, ein Ergebnisgraphmuster
gebildet werden.
Die zweite M¨
oglichkeit betrachtet den Fall, dass die Anwendung der Regel rein Element
l¨
oscht (das Element wird dann durch die Anwendung von r−1erzeugt), sodass anschließend ein
ˆ
P∈ˆ
PTeilgraphmuster des resultierenden Graphen ist. Das entsprechende Ergebnisgraphmus-
ter egm0:= [EGM0,ˆ
EGM0]wird folgendermaßen gebildet. EGM0wird durch die Vereinigung
von L−1und Pgebildet, wobei es in diesem Fall nicht unbedingt einen Teilgraphisomorphis-
mus geben muss, der einen Teilgraph von L−1auf einen Teilgraph von Pabbildet. Allerdings
muss es einen Teilgraphisomorphismus tiso0∈ T ISO und ein ˆ
P∈ˆ
Pgeben, sodass tiso0min-
destens einen Knoten, der sowohl in der linken als auch rechten Regelseite auftritt, auf einen
94 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
Knoten aus ˆ
Pabbildet. Dieser Teilgraphisomorphismus wird dann dazu verwendet, die Graphen
ˆ
EGM0
i∈ˆ
EGM0der negativen Anwendungsbedingung zu bilden. Dabei wird f¨
ur jedes Paar von
Graphen ˆ
P∈ˆ
Pund ˆ
L−1∈ˆ
L−1ein solches ˆ
EGM0
igebildet. Das ˆ
EGM0
ientspricht zun¨
achst ˆ
P.
Der Teilgraphisomorphismus tiso0wird dazu verwendet, alle m¨
oglichen Elemente von ˆ
L−1auf
Elemente aus ˆ
Pabzubilden. Elemente f¨
ur die eine solche Abbildung unter tiso0nicht m¨
oglich ist
werden zum Graphen hinzugef¨
ugt.
In Abbildung 3.30 ist die Regel deleteDCSwitch abgebildet. Die Regel beschreibt, dass
die Instanz des DistanceCoordination-Musters zwischen zwei Shuttles gel¨
oscht wird, wenn die
Shuttles an einer Weiche in unterschiedliche Richtungen weiterfahren wollen. Die Regel l¨
oscht
also einen Knoten, der auch Teil der negativen Anwendungsbedingung des verbotenen Gra-
phmusters impendingCollision aus Abbildung 3.28(b) ist.
Da die Regel nur einen Knoten und seine inzidenten Kanten l¨
oscht, jedoch keine Elemen-
te erzeugt, braucht bei der Bildung der Ergebnisgraphmuster nur die zweite M¨
oglichkeit be-
trachtet werden. Die Regel l¨
oscht den Knoten rdc, seine adjazenten Knoten rs1und rs2bleiben
bei der Anwendung erhalten. Zus¨
atzlich dazu erh¨
alt die Regel die Knoten rt1,rt2und rt3so-
wie die Kanten rlo1,rn1,rsu1,rsu2und rlo2. F¨
ur alle diese Elemente gilt, dass sie sowohl Teil
der linken als auch der rechten Regelseite sind. F¨
ur den Graphen ˆ
IC wird nun ein Teilgraphi-
somorphismus tiso0∈ ISO gesucht, der einen Teil der Elemente von ˆ
IC auf die Elemente ab-
bildet, die bei der Regelanwendung erhalten bleiben. Ein m¨
oglicher Teilgraphisomorphismus
ist tiso0:= htiso0
N,tiso0
Ei, mit tiso0
N:= {(vs17→ rs1),(vs27→ rs2),(vt17→ rt1),(vt27→ rt2)}und
tiso0
E:= {(vlo17→ rlo1),(vlo27→ rlo2),(vsu 7→ rsu1)}. Mit Hilfe dieses Teilgraphisomorphismus
kann nun EGM0gebildet werden. Dazu wird L−1mit tiso0(IC)vereinigt. Das heißt, dass der
Graph L−1um alle Elemente von IC erweitert wird, die nicht durch tiso0auf Elemente von L−1
abgebildet werden. Die negative Anwendungsbedingung ˆ
EGM besteht nur aus dem einen Gra-
phen ˆ
EGM0.ˆ
EGM0besteht zun¨
achst aus L−1. Jedes Element aus ˆ
IC, das nicht durch tiso0auf
ein Element aus L−1abgebildet werden kann, wird zus¨
atzlich in diesen Graphen eingef¨
ugt. Das
Ergebnisgraphmuster egm0ist in Abbildung 3.31 dargestellt.
Definition 35. (Ergebnisgraphmuster (EGM))
F¨
ur eine Regel [L,ˆ
L]→rR, ihr Inverses [L−1,ˆ
L−1]→r−1R−1und ein verbotenes Muster
p:= [P,ˆ
P]werden die Ergebnisgraphmuster egm := [EGM,ˆ
EGM]unter Ber¨
ucksichtigung von
Lemma 8 auf die folgenden zwei Arten gebildet.
(1) Ein Teil der Menge wird Ber¨
ucksichtigung der ersten Bedingung von Lemma 8 gebildet.
F¨
ur jedes Ergebnisgraphmuster dieser Teilmenge wird jeweils ein Graph P0und ein Graphiso-
morphismus iso ∈ ISO gew¨
ahlt, mit
P0≈iso P:
NP0∩(NL−1\NR−1)6=∅ ∨
EP0∩(EL−1\ER−1)∧ ∀e∈EP0∩(EL−1\ER−1) :
src(e)∈(NP0∩NL−1)∧tgt(e)∈(NP0∩NL−1)∧
∀ˆ
Ri∈ˆ
L−1,6 ∃tiso0∈ T ISO :
tiso0−1|L−1=iso−1∧ˆ
L−1
itiso0P0∪L−1∧
∀ˆ
Pi∈ˆ
P,6 ∃tiso00 ∈ T ISO :
tiso00 |P=iso ∧ˆ
Pitiso00 P0∪L−1.
3.7. NACHWEIS VON INDUKTIVEN INVARIANTEN 95
!"$#
! $"#
%&'(
*) #+) #,-. /,01
"+
*) #23) #,-. /,01
432576.89)
$2576.89)
:8':8#;.<7#=)
/>@?BA $$ C
D
#,#/=AEFA #=
*G-H<7#=)
I JLK7MNK2O KQPSR+T'UWVNO X7Y
&(
Z9
+ !"$#
[! $$#2
%+
) #[&) #; !/,0\
"&2576.89)
"(
*) #23) #,-. /,01
42576.89)
<
Abbildung 3.30: Die Regel deleteDCSwitch
Das Ergebnisgraphmuster wird dann folgendermaßen gebildet:
EGM := P0∪L−1
und
ˆ
EGM := {ˆ
L−1∪iso0(P)| ∃iso0∈ ISO,ˆ
L−1∈ˆ
L−1,6 ∃iso00 ∈ ISO :
iso0−1|L−1=iso−1∧EGM <(ˆ
L−1∪iso0(P)) ∧
iso00−1|L0=iso−1∧EGM <(ˆ
L−1∪iso00(P))∧
(ˆ
L−1∪iso00(P)) (ˆ
L1−1∪iso0(P))
}
∪
{L−1∪iso0(ˆ
P)| ∃iso0∈ ISO,ˆ
P∈ P,6 ∃iso00 ∈ ISO :
iso0|P=iso ∧EGM <(L−1∪iso0(ˆ
P)) ∧
iso00 |P=iso ∧EGM <(L−1∪iso00(ˆ
P))∧
(L−1∪iso00(ˆ
P)) <(L−1∪iso0(ˆ
P))
}.
(2) Der zweite Teil der Menge wird unter Ber¨
ucksichtigung der zweiten Bedingung aus Lem-
ma 8 gebildet. Dabei wird f¨
ur jedes Ergebnisgraphmuster dieser Teilmenge jeweils ein Graph ˆ
P
und ein Graphisomorphismus iso0∈ ISO gew¨
ahlt, sodass gilt:
96 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
"! #
%$&'$#"()
*+,))
* "! #
-
.
/%'#02134! #
5+ "! #
%$&4$#"()
67,))
889:#9*;3
<! 3+'! 3=0#:>=?@$
*
A7,))
/>BDCFEG;$9#IH
J
3=3>4EK$)5EG34$
<! 3LA'! 3=0#:>=?@$
7;7 "! #
<! 3+'! 3=0#:>=?@$
,MM:9#:;*3
M&M::#9*;3
<! 3LA'! 3=0#:>=?@$
7M&M:9#:;*3
/N O N,3P$8134! #
Abbildung 3.31: Ein m¨
ogliches Ergebnisgraphmuster f¨
ur die Regel deleteDCSwitch und das ver-
botene Muster impendingCollision
(NR−1∩NL−1∩Niso0(ˆ
P))6=∅.∧
∃n∈(NR−1∩NL−1∩Niso0(ˆ
P)),e∈(ER−1\EL−1) : (n=src(e)) ∨(n=tgt(e)).
In diesem Fall wird egm folgendermaßen gebildet:
EGM := L−1∪iso0(P)∧
ˆ
EGM := {L−1∪iso00(ˆ
P0)| ∃iso00 ∈ ISO,ˆ
P0∈ˆ
P,6 ∃iso000 ∈ ISO :
iso00 |P=iso0∧EGM <(L−1∪iso00(ˆ
P0)) ∧
iso000 |P=iso0∧EGM <(L−1∪iso000(ˆ
P0))∧
(L−1∪iso000(ˆ
P0)) (L−1∪iso00(ˆ
P0))
}.
In den Abbildungen 3.32, 3.33 und 3.34 ist schematisch die Bildung der Graphen der nega-
tiven Anwendungsbedingung dargestellt. Dabei geh¨
oren die Abbildungen 3.32 und 3.33 zu dem
Fall, dass die Regelanwendung ein Element des verbotenen Graphmusters erzeugt. Abbildung
3.32 beschreibt, dass ein Graph ˆ
L−1∈ˆ
L−1um Elemente aus Perweitert wird. Die Erweiterung
eines Graphen ˆ
P∈ P um Elemente aus L−1ist in Abbildung 3.33 zu sehen. Abbildung 3.34
geh¨
ort dagegen zu dem Fall, dass die Regelanwendung ein Element l¨
oscht, das Teil eines ˆ
P∈ˆ
P
ist. Die Abbildung zeigt schematisch die Erweiterung des Graphen ˆ
Pum Elemente aus L−1.
Die Menge aller korrekten Ergebnisgraphmuster f¨
ur eine Regel rund
ein verbotenes Muster pwird mit EGM(r,p)bezeichnet. Die Menge
3.7. NACHWEIS VON INDUKTIVEN INVARIANTEN 97
Abbildung 3.32: Schematische Darstellung der Erweiterung eines Graphen ˆ
L−1∈ˆ
L−1um Ele-
mente aus P
Abbildung 3.33: Schematische Darstellung der Erweiterung eines Graphen ˆ
P∈ˆ
Pum Elemente
aus L−1
Abbildung 3.34: Schematische Darstellung der Erweiterung eines Graphen ˆ
P∈ˆ
Pum Elemente
aus L−1
EGM≈(r,p)ist eine Teilmenge von EGM(r,p). Diese Menge ist mini-
mal, d.h. es gilt ∀egm ∈ EGM(r,p),∃egm0∈ EGM :≈(r,p) : egm0⊆egm und
∀egm1,egm2∈ EGM≈(r,p) : egm16⊆ egm2.
Durch die Konstruktion des Ergebnisgraphmusters ist das Graphmuster [L−1,ˆ
L−1]der inver-
sen Regel r−1immer ein Teilgraphmuster des Ergebnisgraphmusters und eine R¨
uckw¨
artsanwen-
dung der Regel im DPOiso immer m¨
oglich. Das Graphmuster, das aus der Anwendung resultiert,
wird als Startgraphmuster bezeichnet.
Das Startgraphmuster, das resultiert, wenn die inverse Regel moveSimpleNAC−1auf das Er-
gebnisgraphmuster egm aus Abbildung 3.29 angewendet wird, ist in Abbildung 3.35 dargestellt.
98 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
"!#%$ &('
)*
)
*
$+-,/.0#!'1243
5
$6.7'8!).06'
)
9 * :%!1#2$ &;'
<=>!1@?
4 :%!1#2$ &;'
<=>!1@?
/7A<=>!1@? #<=!88?
/7A<=>!1@?
BCDB12%2
BE4B12%%
F@DF1%2%
BE4B12%%
G<H>!1@?
4 :%!1#2$ &;'
I D "!#%$ &('
J*<=!88?
FEDF1%2%F@B12%%
#<H>!1@?
<=!88?
I D "!#%$ &('
J<=!88?
D "!#%$ &('
FCF1%2%B@*B12%%
#<=>!1@?
*<=!88?
D "!#%$ &('
LKNM
O
LKNMP
9 "!#%$ &('
O
LKNMC
"!#%$ &('
"!#%$ &('
O
LKNMCQ
P :%!1#2$ &;'
BCDB12%2
<=>!1@?
R
H
R
6'BS:
BE4B12%%
#<=!88?/7A<=>!1@?
GH%!@SL6
O
LKNMUT
Abbildung 3.35: Startgraphmuster, das aus der Anwendung der inversen Regel
moveSimpleNAC−1auf das Ergebnisgraphmuster aus Abbildung 3.29 resultiert
Definition 36. (Startgraphmuster)
F¨
ur eine Regel [L,ˆ
L]→rR, ihr Inverses [L−1,ˆ
L−1]→r−1R−1, das verbotene Muster p:= [P,ˆ
P]
und ein dazugeh¨
origes Ergebnisgraphmuster egm := [EGM,ˆ
EGM], ist das Startgraphmuster
sgm := [SGM,ˆ
SGM]definiert als tgm |=|=⇒r−1sgm.
Die Menge SGM≈(r,p)bezeichnet die minimale Menge der Startgraphmuster. Diese Men-
ge wird aus der Menge T GM≈(r,p)durch Anwendung der inversen Regel von rerzeugt. F¨
ur
jeden der Graphen aus SGM≈(r,p)muss gepr¨
uft werden, ob er ein verbotenes Graphmuster
enth¨
alt. Kann ein Startgraphmuster sgm ∈ SGM≈(r,p)gefunden werden, das kein verbotenes
Graphmuster enth¨
alt, so wurde ein Gegenbeispiel gefunden, dass zeigt, dass die Regel reinen
korrekten Graphen in einen inkorrekten ¨
uberf¨
uhren kann, d.h. die Menge T[φS,¬φS]nicht leer
ist.
3.7. NACHWEIS VON INDUKTIVEN INVARIANTEN 99
Lemma 9 zeigt f¨
ur ein System Sund eine Sicherheitseigenschaft φs:= Vk∈K(¬pi), dass die
Menge T[φS,¬φS]leer und φSsomit eine induktive Invariante von Sist, falls f¨
ur jedes Ergeb-
nisgraphmuster egm das dazugeh¨
origen Startgraphmuster sgm einen Zeugen f¨
ur ein verbotenes
Muster piaus φSenth¨
alt. Ein Graph, der eines der Ergebnisgraphmuster enth¨
alt und somit inkor-
rekt ist, kann nur entstanden sein, wenn die entsprechende Regel auf einen Graphen angewendet
wurde, der eines der Startgraphmuster enthalten hat. Da auch die Startgraphmuster einen Zeugen
f¨
ur ein verbotenes Muster aufweisen, ist auch der urspr¨
ungliche Graph inkorrekt.
Lemma 9. (Zeuge im Startgraphmuster impliziert induktive Invariante)
F¨
ur ein System S:= (GΩ,Gi,RS)und eine Sicherheitseigenschaft φ:= Vj∈J(¬pj)gilt im
DPOiso ∀i∈J,r∈ R:
(∀egm ∈ EGM≈(r,pi),sgm,o∈ ISO : (egm |=|=⇒(r−1,o−1)sgm)∧(∃j∈J:pj⊆sgm))
⇒
(∀G1,G2∈ G[GΩ]:(G1|=⇒(r,o)G2∧G2|=pi)⇒(∃j∈J:G1|=pj)).
Mittels dieses Lemmas kann der Nachweis, dass eine Sicherheitseigenschaft eine induktive
Invariante eines Systems ist, auf die Betrachtung von Start- und Ergebnisgraphmustern reduziert
werden. Eine Sicherheitseigenschaft ist genau dann eine induktive Invariante eines Systems,
wenn die Transformation eines Ergebnisgraphmusters durch die dazugeh¨
orige Graphtransfor-
mationsregel immer in einem Startgraphmuster resultiert, das einen Zeugen f¨
ur ein verbotenes
Muster enth¨
alt. Dieses Ergebnis ist in Theorem 5 festgehalten.
Theorem 5. (Sicherheitseigenschaft ist induktive Invariante)
F¨
ur ein System S:= (GΩ,Gi
S,RS)ist die Sicherheitseigenschaft φ:= Vj∈J(¬pj)genau dann
eine induktive Invariante, wenn gilt:
∀i∈J,r∈ RS,egm ∈ EGM≈(r,pi),sgm,o∈ ISO :
(egm |=|=⇒(r−1,o−1)sgm)⇒(∃j∈J:pj⊆sgm)(3.7)
3.7.2 Der Algorithmus
Die im voran gegangenen Abschnitt vorgestellten theoretischen Ergebnisse k¨
onnen nun dazu
verwendet werden, um einen Algorithmus zu beschreiben, der automatisch ¨
uberpr¨
uft, ob ein
Graphtransformationssystem korrekt bez¨
uglich einer Sicherheitseigenschaft φSist. D.h. der Al-
gorithmus pr¨
uft, ob jede der Eigenschaften eine induktive Invariante des Systems ist. Der Al-
gorithmus check ist in Abbildung 3.36 in Pseudocode angegeben. Er erwartet als Eingabe eine
Menge von Graphtransformationsregeln RSund eine Menge von verbotenen Mustern P, wo-
bei Pder Menge der verbotenen Graphmuster aus φSentspricht. Zus¨
atzlich dazu ben¨
otigt der
Algorithmus noch den Typgraphen GΩ.
In einem ersten Schritt (Zeile 03 bis 06) ruft der Algorithmus f¨
ur jedes Paar, bestehend aus
dem Inversen r−1einer Regel r∈ RSund ein verbotenes Graphmuster pi∈ P, den Algorith-
mus buildTGP auf, der in Abschnitt C.3.1 beschrieben wird. Dieser berechnet f¨
ur das jeweilige
100 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
Paar von Regel und verbotenem Graphmuster die Menge aller g¨
ultigen Ergebnisgraphmuster
EGM(r,pi). Diese Menge wird reduziert, sodass eine minimale Menge von Ergebnisgraphmus-
tern EGM≈(r,pi)resultiert (Zeile 07). Der zur Reduktion aufgerufene Algorithmus reduceTGP
wird in Abschnitt C.3.1 vorgestellt.
In den Zeilen 08 bis 16 wird die G¨
ultigkeit von Bedingung 3.7 aus Theorem 5 ¨
uberpr¨
uft. Dazu
wird zun¨
achst auf jedes Ergebnisgraphmuster egm aus der Menge EGM≈(r,pi)die entsprechen-
de inverse Graphtransformationsregel r−1angewendet (Zeile 10). F¨
ur das jeweils resultierende
Startgraphmuster sgm muss ¨
uberpr¨
uft werden, ob es irgendein verbotenes Muster enth¨
alt. Kann
kein Zeuge f¨
ur ein verbotenes Muster in sgm gefunden werden, so liefert der Algorithmus das
Startgraphmuster sgm, das Ergebnisgraphmuster egm und die Regel rals Gegenbeispiel zur¨
uck.
Andernfalls gibt der Algorithmus aus, dass die Regelmenge RSkorrekt ist.
01: Boolean check(Set<GraphRule> R, Set<GraphPattern>P, Graph GΩ) begin
02: Set<Graph> T GP := ∅
03: forall (r∈ R) do
04: GraphRule r−1:= reverse(r)
05: forall (p∈ P) do
06: T GP := buildT GP (r−1, p)
07: T GP := reduceT GP (T GP)
08: forall tgp ∈ T GP do
09: //determine source graph
10: GraphPattern sgp := applyRuleT oP attern(tgp, r−1, idR, GΩ)
11: //check if sgp fulfills any p0∈ P
12: if (6 ∃ p0∈ P :p0⊆sgp) then
13: //report counterxample sgp |=|=⇒rtgp
14: return false
15: fi
16: end
17: end
18: end
19: return true
20: end
Abbildung 3.36: Algorithmus check
Das System S:= (GΩ,Gi
S,RS)ist korrekt bez¨
uglich der Sicherheitseigenschaft φS, wenn der
Algorithmus check angibt, dass die Menge der Regeln korrekt ist und zus¨
atzlich alle Initialgra-
phen korrekt sind, d.h. ∀G∈ Gi
S:G|=φS.
3.7.3 Aufwandsabsch¨
atzung
Im voran gegangenen Abschnitt wurde der Algorithmus zum Nachweis induktiver Invarianten
in Graphtransformationssystemen vorgestellt. In diesem Abschnitt wird f¨
ur diesen Algorithmus
eine Absch¨
atzung f¨
ur seine Komplexit¨
at gegeben.
In der Absch¨
atzung werden die folgenden Variablen verwendet: nGist die maximale Anzahl
von Elementen (Knoten und Kanten) im gr¨
oßten Graphen. Dabei kann dieser Graph eine lin-
ke oder rechte Regelseite, die Anwendungsbedingung eines verbotenen Graphmusters oder ein
Graph einer negativen Anwendungsbedingungen einer Regel oder eines verbotenen Graphmus-
ters sein. Die Anzahl aller Regeln wird mit nRbezeichnet. nPentspricht der Anzahl aller verbo-
3.7. NACHWEIS VON INDUKTIVEN INVARIANTEN 101
tenen Graphmuster. Die maximale Anzahl von Graphen in der negativen Anwendungsbedingung
einer Regel wird mit nˆ
Lbezeichnet. Dementsprechend bezeichnet nˆ
Pdie maximale Anzahl von
Graphen in der negativen Anwendungsbedingung eines verbotenen Graphmusters.
Der Algorithmus bestimmt mehrfach (Teil-)Graphisomorphismen zwischen zwei Graphen.
Dabei muss f¨
ur alle Elemente des einen Graphen eine Abbildung auf ein Element des ande-
ren Graphen gefunden werden, wodurch ein Aufwand entsteht, der exponentiell in den Gr¨
oßen
der beiden Graphen ist. Um die Aufwandsabsch¨
atzung zu vereinfachen, wird die Gr¨
oße eines
Graphen als die Summe seiner Knoten und Kanten angegeben. Da alle Graphen eine maximale
Gr¨
oße von nGhaben, betr¨
agt der Aufwand zum Bestimmen eines Graphisomorphismus zwischen
zwei Graphen O(exp(2nG)).
Als erstes wird die Regel invertiert. Dazu muss jeder Graph der negativen Anwendungsbe-
dingung konvertiert werden und dann die minimale negative Anwendungsbedingung berechnet
werden. Zudem m¨
ussen Isomorphismen bestimmt werden. sodass sich insgesamt f¨
ur die Inver-
tierung der Regel eine Komplexit¨
at von O(nˆ
L2∗exp(2nG)) ergibt.
Anschließend bildet der Algorithmus alle m¨
oglichen Ergebnisgraphmuster. Dazu m¨
ussen
zun¨
achst alle Teilgraphen der linken Regelseite und der Anwendungsbedingung des verbotenen
Graphmuster bestimmt werden. F¨
ur jeden Teilgraphen der linken Regelseite und jeden Teilgra-
phen des verbotenen Graphmusters wird dann gepr¨
uft, ob es einen Isomorphismus gibt, der die
beiden Teilgraphen aufeinander abbildet. Um die negative Anwendungsbedingung der Ergebnis-
graphmuster zu bestimmen, m¨
ussen alle Graphen der negativen Anwendungsbedingungen aller
linken Regelseiten sowie allerverbotenen Graphmuster betrachtet werden. Auch beim Bilden der
negativen Anwendungsbedingungen m¨
ussen wieder Isomorphismen bestimmt werden, wodurch
sich f¨
ur die Funktion buildTGP eine Gesamtkomplexit¨
at von O(exp(6nG)) ergibt.
Nachdem die Menge aller Ergebnisgraphmuster erzeugt wurde, werden redundante Muster
wieder aus dieser Menge entfernt. Dazu muss jedes Paar von Ergebnisgraphmustern P1und P2
betrachtet werden und bestimmt werden, ob es einen Isomorphismus gibt, der die Anwendungs-
bedingung des Musters P1auf einen Teil der Anwendungsbedingung des Musters P2abbilden
kann. Ist dies der Fall, muss gepr¨
uft werden, ob dieser Isomorphismus so erweitert werden kann,
dass er einen Graphen der verbotenen Anwendungsbedingung von P1auf die Anwendungsbedin-
gung von P2abbilden kann. Ist dies der Fall, ist das Muster P1kein Teilgraphmuster von P2. An-
dernfalls muss noch gepr¨
uft werden, ob der gefundene Isomorphismus so erweitert werden kann,
dass jeder der Graphen der negativen Anwendungsbedingung von Muster P1auf einen Graphen
der negativen Anwendungsbedingung von Muster P2abgebildet werden kann. Die Graphen (so-
wohl die Anwendungsbedingung als auch die Graphen der negativen Anwendungsbedingung)
eines Ergebnisgraphmusters setzen sich jeweils aus zwei Graphen zusammen. Im schlechtesten
Fall haben diese beiden Graphen nur einen gemeinsamen Knoten, sodass die maximale Gr¨
oße
der Graphen eines Ergebnisgraphmusters 2nGbetr¨
agt. F¨
ur die Bestimmung eines Isomorphismus
zwischen zwei Graphen eines Ergebnisgraphmusters bedeutet dies einen Aufwand von O(4nG).
Insgesamt hat die Minimierung der Menge der Ergebnisgraphmuster deshalb einen Aufwand von
O(exp(8nG)).
Wurde die Menge der Ergebnisgraphmuster berechnet und reduziert, kann die Regel auf jedes
der Muster angewendet werden und dadurch die Menge der Startgraphmuster bestimmt werden.
Da sich ein Ergebnisgraphmuster aus zwei Graphen zusammensetzt, die jeweils eine maximale
102 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
Gr¨
oße von nGhaben, gibt es maximal exp(2nG)Ergebnisgraphmuster. Deshalb wird auch die
Schleife in Zeile 08 maximal exp(2nG)-mal ausgef¨
uhrt. Bei der Anwendung der Regel m¨
ussen
wieder Isomorphismen bestimmt werden, was zu einer Komplexit¨
at von O(exp(2nG)) f¨
uhrt.
Als letztes wird f¨
ur jedes Startgraphmuster bestimmt, ob es ein verbotenes Graphmuster
gibt, das ein Teilgraphmuster des Startgraphmusters ist. Dabei wird wie bei der Reduktion der
Menge der Ergebnisgraphmuster vorgegangen. Daraus ergibt sich dann eine Komplexit¨
at von
O(exp(8nG)).
F¨
ugt man diese Komplexit¨
aten zusammen, so erh¨
alt man den folgenden Ausdruck, wobei die
Zahl auf der linken Seite der Zeilennummer im Algorithmus entspricht.
03 O(nR∗(
04 ne
ˆ
Lxp(2nG)+
05 nP∗(
06 exp(6nG)+
07 exp(8nG)+
08 exp(2nG)∗(
10 exp(2nG)+
12 exp(8nG)
)
)
)
L¨
ost man die innerste Klammer auf, so erh¨
alt man O(nR∗(ne
ˆ
Lxp(2nG)+ nP∗(exp(6nG)+
exp(8nG)+ exp(4nG)+ exp(10nG)). Das O-Kalk¨
ul stellt eine obere Schranke f¨
ur den Aufwand
dar. Deshalb ist es m¨
oglich die Summe (ne
ˆ
Lxp(2nG)+ nP∗(exp(6nG)+ exp(8nG)+ exp(4nG)+
exp(10nG)) durch 4exp(10nG)zu ersetzen. Da die 4eine Konstante ist, mit der die Exponential-
funktion multipliziert wird, kann sie weggelassen werden. Damit ergibt sich O(nR∗(ne
ˆ
Lxp(2nG)+
nP∗exp(10nG). Zudem gilt f¨
ur große nG, dass der Term ne
ˆ
Lxp(2nG)kleiner ist als nP∗exp(10nG)
und somit ebenfalls wegf¨
allt. Daraus ergibt sich eine Komplexit¨
at des gesamten Algorithmus von
O(nR∗nP∗exp(10nG)).
Die Absch¨
atzung hat somit ergeben, dass der Aufwand des Algorithmus exponentiell in der
Gr¨
oße der betrachteten Graphen, aber nur linear in der Anzahl der Regeln und verbotenen Gra-
phmuster ist. Damit hat der Algorithmus zwar eine sehr hohe Komplexit¨
at, allerdings gilt die-
se nur f¨
ur den schlechtesten Fall. In der Praxis gilt jedoch, dass die Graphen der Regeln und
verbotenen Graphmuster relativ klein sind, sodass die hohe Komplexit¨
at eine Verifikation nicht
verhindert. Zudem wurde bei der Komplexit¨
atsberechnung davon ausgegangen, dass alle Ele-
mente denselben Typ haben. Auch dies trifft in der Praxis nicht zu. In Abschnitt 5.3 wird die
Umsetzung des Ansatzes in der Fujaba Real-Time Tool Suite beschrieben und in Abschnitt 5.4
eine Evaluierung anhand eines kleinen Beispiels durchgef¨
uhrt. Diese Evaluierung zeigt, dass der
Algorithmus trotz seiner Komplexit¨
at anwendbar ist.
3.8. ZUSAMMENFASSUNG 103
3.8 Zusammenfassung
Das Kapitel 2 stellt einen Ansatz vor, in dem Methoden mechatronischer Systeme mittels Sto-
ry Patterns beschrieben werden. F¨
ur diese Story Patterns wird ein Verfahren ben¨
otigt, dass die
Verifikation der Story Patterns erm¨
oglicht.
Da Story Patterns eine eingeschr¨
ankte Form von Graphtransformationsregeln darstellen, ist
es m¨
oglich zu ihrer ¨
Uberpr¨
ufung Verfahren zur Verifikation von Graphtransformationssystemen
einzusetzen. Allerdings ben¨
otigen existierende Ans¨
atze zum einen einen Initialgraphen, zum an-
deren sind die meisten existierenden Ans¨
atze nur anwendbar, wenn der durch die Graphtransfor-
mationsregeln aufgespannte Zustandsraum endlich ist (siehe dazu Kapitel 6). Diese beiden Ein-
schr¨
ankungen k¨
onnen f¨
ur die Story Patterns der mechatronischen Systeme nicht gew¨
ahrleistet
werden. Deshalb wurde in diesem Kapitel ein Ansatz vorgestellt, der nicht diesen Einschr¨
ankun-
gen unterliegt.
Im vorgestellten Ansatz werden die zu verifizierenden strukturellen Eigenschaften als (ver-
botene) Graphmuster beschrieben. Um auch unendliche Graphtransformationssysteme verifizie-
ren zu k¨
onnen, wird weder eine Erreichbarkeitsanalyse durchgef¨
uhrt, noch werden konkreten
Graphen analysiert. Stattdessen werden Mengen von Graphen durch Ergebnisgraphmuster (be-
stehend aus der rechten Seite einer Regel und einem verbotenen Graphmuster) beschrieben. F¨
ur
ein solches Ergebnisgraphmuster wird gepr¨
uft, ob es das Resultat einer Regelanwendung auf ein
korrektes Graphmuster (das so genannte Startgraphmuster) ist. Ist dies der Fall, so wurde gezeigt,
dass die betrachtete Regel einen korrekten Graphen in einen inkorrekten ¨
uberf¨
uhren kann. Dies
gilt immer dann, wenn ein Graph das Startgraphmuster enth¨
alt und auf dieses Startgraphmuster
die betrachtete Regel angewendet wird. Durch die Anwendung der Regel auf das Startgraphmus-
ter resultiert ein Graph, der das Ergebnisgraphmuster enth¨
alt. Das Startgraphmuster zusammen
mit der Regel und dem Ergebnisgraphmuster bilden in einem solchen Fall ein Gegenbeispiel.
Am Ende des Kapitels wurde ein Algorithmus vorgestellt, der den Ansatz in Pseudocode-
Notation beschreibt. Die Aufwandsabsch¨
atzung ergab, dass der vorgestellte Algorithmus linear
in der Anzahl der Regeln und verbotenen Graphmuster ist, aber exponentiell in der Gr¨
oße der
Graphen. Das folgende Kapitel zeigt informal, dass Story Patterns eine eingeschr¨
ankte Form der
in diesem Kapitel vorgestellten Graphtransformationsregeln, bzw. verbotenen Graphmuster sind.
In Kapitel 5 wird die prototypische Umsetzung des Ansatzes f¨
ur Story Patterns in der Fujaba
Real-Time Tool Suite beschrieben. In der Evaluierung wird dann mittels eines kleinen Beispiels
gezeigt, dass die Laufzeit in der Praxis nicht so schlecht ist, wie die Aufwandsabsch¨
atzung er-
geben hat. Dies gilt deshalb, da in der Praxis die Graphen der Regeln sowie der verbotenen
Graphmuster relativ klein und vor allem typisiert sind, wodurch weniger Ergebnisgraphmuster
gebildet werden k¨
onnen.
104 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN
Kapitel 4
Story Patterns und
Graphtransformationssysteme
Im voran gegangenen Kapitel wurden Graphtransformationssysteme eingef¨
uhrt, wie sie auch in
der Literatur (beispielsweise in [Roz97]) verwendet werden. Die Anwendbarkeit der Graphtrans-
formationsregeln wurde im DPOiso eingeschr¨
ankt. Zudem wurde definiert, wie eine Regel mit
negativer Anwendungsbedingung r¨
uckw¨
arts angewendet werden kann. Sicherheitseigenschaften
wurden in Form von verbotenen Graphmustern beschrieben. In Abschnitt 3.7 wurde dann ein
Verfahren vorgestellt, mit dem man nachweisen kann, dass die Anwendung der Regeln keinen
Graphen erzeugen kann, der eines der verbotenen Graphmuster als Teilgraphmuster enth¨
alt und
somit inkorrekt ist.
In Kapitel 2 wurden Story Patterns vorgestellt und dazu verwendet, um die von den Real-
Time Statecharts aufgerufenen Methoden modellieren zu k¨
onnen. Außerdem wurden verbotene
Story Patterns eingef¨
uhrt, um kritische Situationen und Unf¨
alle zu modellieren.
Die Story Patterns stellen eine spezielle Art von Graphtransformationsregeln dar. Sie unter-
scheiden sich von den in Kapitel 3 eingef¨
uhrten Graphtransformationsregeln haupts¨
achlich in
ihrer Syntax. W¨
ahrend Graphtransformationsregeln aus zwei Graphen, der linken und der rech-
ten Regelseite, bestehen, besteht ein Story Patterns nur aus einem Graphen, der beide Regelseiten
enth¨
alt. Zudem werden in den zuvor beschriebenen Graphtransformationssystemen negative An-
wendungsbedingungen als zus¨
atzliche Graphen zur linken Regelseite hinzugef¨
ugt, w¨
ahrend sie
in Story Patterns direkt in den Graphen eingef¨
ugt werden, der die linke und die rechte Regelseite
beschreibt. Daraus resultiert eine schw¨
achere Ausdrucksst¨
arke der negativen Anwendungsbedin-
gungen von Story Patterns. Schr¨
ankt man die Anwendbarkeit der Story Pattern zudem noch so
ein, dass sie im DPOiso angewendet werden, so ist es m¨
oglich, den im vorangegangenen Kapitel
vorgestellten Verifikationsansatz dazu zu verwenden, um f¨
ur die Story Patterns nachzuweisen,
dass ihre Anwendung kein Objektdiagramm erzeugt, auf das ein verbotenes Story Pattern an-
gewendet werden kann. Das bedeutet, die Anwendung eines Story Patterns auf ein korrektes
Objektdiagramm resultiert immer wieder in einem korrekten Objektdiagramm.
In diesem Kapitel soll informal gezeigt werden, dass Story Patterns auf die in Kapitel 3 ein-
gef¨
uhrten Graphtransformationsregeln abgebildet werden k¨
onnen und somit der Verifikationsan-
satz auch zur Verifikation von Story Pattern anwendbar ist.
105
106 KAPITEL 4. STORY PATTERNS UND GRAPHTRANSFORMATIONSSYSTEME
4.1 Objektdiagramme und Graphen
Wie bereits in Abschnitt 3.4.1 erl¨
autert wurde, kann ein Klassendiagramm auf einen Typgra-
phen abgebildet werden. Dabei wird jede Klasse auf einen Knoten und jede Assoziation auf eine
Kante abgebildet. Klassen- und Assoziationsnamen werden den Knoten und Kanten durch die
entsprechenden Beschriftungsfunktionen zugewiesen. In den hier verwendeten Klassendiagram-
men k¨
onnen ungerichtete Assoziationen enthalten sein. Bei der Abbildung auf einen Graphen
wird f¨
ur diese Assoziationen eine Richtung festgelegt.
Dementsprechend kann ein Objektdiagramm auf einen typisierten Graphen abgebildet wer-
den. Dabei wird jedes Objekt des Objektdiagramms auf einen Knoten des Graphen abgebildet.
Die Beschriftung des Knotens entspricht dem Typ sowie dem Namen des Objekts. Ebenso wird
jeder Link des Objektdiagramms auf eine Kante abgebildet, deren Beschriftung dem Objekttyp
und -namen entspricht. Enth¨
alt ein Objektdiagramm ungerichtete Links, so werden diese auf
gerichtete Kanten abgebildet, wobei ihre Richtungen den im Typgraph definierten Richtungen
entsprechen m¨
ussen.
Abbildung 4.1(a) zeigt noch einmal das einfache Klassendiagramm aus Abschnitt 2.1.3, Ab-
bildung 4.1(b) zeigt den entsprechenden Typgraphen. Das Objektdiagramm in Abbildung 4.2(a)
stellte eine m¨
ogliche Instanzierung des Klassendiagramms dar, der zu ihm ¨
aquivalente typisierte
Graph ist in Abbildung 4.2(b) zu sehen. Gleiche Namen von Objekten und Knoten sowie Links
und Kanten stellen den Zusammenhang zwischen den beiden Diagrammen dar.
(a) Einfaches Klassendia-
gramm
!""#
$%#&('
)
* +#,
(b) Typgraph, der dem obigen Klas-
sendiagramm entspricht
Abbildung 4.1: Klassendiagramm und entsprechender Typgraph
4.2 Story Patterns und Graphtransformationsregeln
Ein Story Pattern (siehe [FNTZ98, Z¨
un01] und Abschnitt 2.2.2) ist eine Graphtransformations-
regel, bei der die linke und die rechte Regelseite in einem Graphen zusammengefasst sind. Die
Objekte des Story Patterns entsprechen dabei den Knoten der Graphtransformationsregel und
die Links den Kanten. Die Objekte und Links eines Story Patterns k¨
onnen, zus¨
atzlich zum Na-
men und zum Typ, mit destroy oder mit create beschriftet sein. Alle Elemente, die nicht
4.2. STORY PATTERNS UND GRAPHTRANSFORMATIONSREGELN 107
(a) Ausschnitt eines Objektdiagramms, das eine m¨
ogli-
che Instanzierung des Klassendiagramms aus Abbildung
4.1(a) darstellt
!"#"%$ &
"
'(
)*
"
",+.-0/
1
32
&4
"56'(
)7*
!
!
)8)
&
9
-(
:<;
:
-0/+ "-(
!
;
!
)8)
&
-(
!=>
!
)8)
&
-(
$ -
?$ -
)8
"&A@CBD/
:
=>
:
-0/+ "-(
:
5>
:
-0/+ "-(
:
:
-0/+ "-(
!5
!
)A)
&
9
-(
(b) Typisierter Graph, der dem Objektdiagramm aus Abbildung 4.2(a)
entspricht
Abbildung 4.2: Objektdiagramm und entsprechender typisierter Graph
mit create beschriftet sind, stellen die Anwendungsbedingung der Graphtransformations-
regel dar. Ebenso entsprechen alle Elementen, die nicht mit destroy beschriftetet sind, der
Nachbedingung der Graphtransformationsregel.
Abbildung 4.3 zeigt die Vorw¨
artsbewegung eines Shuttles, moveSimple, zum einen als Story
Pattern und zum anderen als Graphtransformationsregel.
4.2.1 Anwendung von Story Patterns und Graphtransformationsregeln
Die Anwendung eines Story Patterns auf ein Objektdiagramm erfolgt im Single Pushout Ansatz.
Allerdings muss das Matching, dass die Anwendungsbedingung auf einen Teil des Objektdia-
gramms abbildet, ein Teilgraphisomorphismus sein. Auf diese Weise wird die Identifikationsbe-
dingung erf¨
ullt und Konflikte vermieden, bei denen zu l¨
oschende Objekte auf dasselbe Objekt
108 KAPITEL 4. STORY PATTERNS UND GRAPHTRANSFORMATIONSSYSTEME
(a) Vorw¨
artsbewegung als
Story Pattern
"!
#$%&')(
#*+*,,
-./%0')(
1 24357698;:#2=<?>@6
#$%&')(
#*AB*,,
-./%0')(
C.D E F!
G
(b) Vorw¨
artsbewegung als Graphtransformationsregel
Abbildung 4.3: Vorw¨
artsbewegung, moveSimple, eines Shuttles als Story Pattern und als Graph-
transformationsregel
abgebildet werden wie Objekte, die durch die Anwendung des Story Patterns erhalten bleiben.
Entstehen bei der Anwendung eines Story Patterns lose Kanten, so werden sie implizit gel¨
oscht.
Aufgrund dieses impliziten L¨
oschens von losen Kanten ist eine R¨
uckw¨
artsanwendung eines Sto-
ry Patterns nicht immer m¨
oglich.
Im oben vorgestellten Verifikationsansatz wurde der DPOiso Ansatz f¨
ur die Anwendung von
Graphtransformationsregeln eingef¨
uhrt. Wie bei der Anwendung von Story Patterns verlangt
auch der DPOiso Ansatz, dass das Matching der linken Regelseite auf einen Teilgraphen des
Anwendungsgraphen ein Graphisomorphismus ist. Im Gegensatz zu den Story Patterns muss
die Lose-Kanten-Bedingung im DPOiso Ansatz jedoch explizit erf¨
ullt werden. Das bedeutet, ein
Knoten darf nur dann gel¨
oscht werden, wenn dadurch keine losen Kanten entstehen.
Da sowohl das Matching der Story Patterns als auch der Graphtransformationsregeln ein Gra-
phisomorphismus sein muss, kann ein Story Pattern, das keine Objekte l¨
oscht, genau dann an-
gewendet werden, wenn auch die entsprechende Graphtransformationsregel angewendet werden
kann.
Um zu erzwingen, dass dies auch gilt, wenn das Story Pattern ein Objekt l¨
oscht, muss das
Story Pattern um zus¨
atzliche negative Objekte und Links erweitert werden. Im Klassendiagramm
ist definiert, welche Klassen adjazent zur Klasse des zu l¨
oschenden Objektes sind. F¨
ur jede dieser
Klassen wird ein negatives Objekt in das Story Pattern eingef¨
ugt. Jedes der neu erzeugten negati-
ven Objekte wird ¨
uber eine Kante mit dem zu l¨
oschenden Objekt verbunden. Diese Erweiterung
entspricht der Erweiterung der Graphtransformationsregeln aus Definition 27.
4.2. STORY PATTERNS UND GRAPHTRANSFORMATIONSREGELN 109
Durch die Erweiterung der Story Patterns um zus¨
atzliche negative Knoten und Kanten
wird erreicht, dass auch diese im DPOiso Ansatz angewendet werden und somit immer eine
R¨
uckw¨
artsanwendung der Story Patterns m¨
oglich ist.
4.2.2 Negative Anwendungsbedingungen
Sowohl bei Story Patterns als auch bei Graphtransformationsregeln k¨
onnen negative Anwen-
dungsbedingungen angegeben werden. Ihre Syntax und Semantik unterscheiden sich zwar, aller-
dings k¨
onnen die negativen Anwendungsbedingungen von Story Patterns auf negative Anwen-
dungsbedingungen von Graphtransformationsregeln abgebildet werden.
In Story Patterns wird die negative Anwendungsbedingung direkt in Form von negativen
Elementen in den Graph eingef¨
ugt, der sowohl die Anwendungs- als auch die Nachbedingung
des Story Patterns spezifiziert.
Kann die Anwendungsbedingung eines Story Patterns auf ein Objektdiagramm abgebildet
werden, jedoch keines der negativen Elemente, so kann das Story Pattern angewendet werden.
Enth¨
alt ein Story Pattern mehrere negative Elemente und es gibt ein Match f¨
ur mindestens eines
der negativen Elemente im Objektdiagramm, so ist die Anwendung des Story Patterns verbo-
ten. Enth¨
alt ein Story Pattern einen negativen Knoten mit mehreren inzidenten Kanten, so ist
seine Anwendung genau dann verboten, wenn sowohl der negative Knoten als auch alle seine
inzidenten Kanten auf das Objektdiagramm abgebildet werden k¨
onnen.
Abbildung 4.4 zeigt ein Beispiel f¨
ur ein Story Pattern mit negativer Anwendungsbedingung.
Dieses Story Pattern, createDC, erzeugt f¨
ur zwei Shuttles eine Instanz des DistanceCoordination-
Musters, falls die beiden Shuttles auf zwei Tracks sind, zwischen denen sich ein weiterer Track
befindet. Die negative Anwendungsbedingung verlangt, dass zwischen den beiden Shuttles noch
kein DistanceCoordination-Muster existiert, bei dem das Shuttle rs1 die rearRole und das Shuttle
rs2 die frontRole spielt.
Das Story Pattern darf genau dann auf ein Objektdiagramm angewendet werden, wenn die
Anwendungsbedingung des Story Patterns auf das Objektdiagramm abgebildet werden kann. Es
darf jedoch kein Objekt vom Typ DistanceCoordination geben, auf das rdc2 oder rdc3 abgebildet
werden k¨
onnen und auf dessen inzidenten Link der zu rdc2 bzw. rdc3 inzidente Link abgebildet
werden kann. Das bedeutet, dass das Muster nur dann erzeugt wird, wenn es noch kein Distance-
Coordination-Muster gibt, in dem das Shuttle rs1 die rearRole ¨
ubernommen hat und kein Muster,
in dem rs2 die frontRole spielt.
In Graphtransformationsregeln werden die negativen Anwendungsbedingungen durch
zus¨
atzliche Graphen beschrieben. Eine Graphtransformationsregel mit negativer Anwendungs-
bedingung darf angewendet werden, wenn ihre Anwendungsbedingung auf einen Teilgraphen
des Anwendungsgraphen abgebildet werden kann, eine Abbildung eines kompletten Graphen
der negativen Anwendungsbedingung jedoch nicht m¨
oglich ist.
Enth¨
alt ein Story Pattern mehrere negative Elemente, so muss bei der Abbildung auf Graph-
transformationsregeln f¨
ur jedes der Elemente ein Graph zur negativen Anwendungsbedingung
hinzugef¨
ugt werden. Jeder dieser Graphen erweitert die Anwendungsbedingung, d.h. die An-
wendungsbedingung stellt einen Teilgraphen des neu erzeugten Graphen dar. Bei der Abbildung
110 KAPITEL 4. STORY PATTERNS UND GRAPHTRANSFORMATIONSSYSTEME
Abbildung 4.4: Story Pattern createDC, das die Erzeugung eines DistanceCoordination-Musters
zeigt
eines negativen Links wird eine entsprechende Kanten in den Graphen eingef¨
ugt. Bei einem ne-
gativen Objekt wird der Graph um einen entsprechenden Knoten erweitert. Zus¨
atzlich wird f¨
ur
jeden inzidenten Link eine Kante in den Graphen eingef¨
ugt.
Abbildung 4.5 zeigt die Graphtransformationsregel createDC, die ¨
aquivalent zu dem gleich-
namigen Story Pattern ist.
4.3 Kritische Situationen und Unf¨
alle
Auch kritische Situationen und Unf¨
alle, die als verbotene Story Patterns gegeben sind, k¨
onnen
mittels verbotenen Graphmustern dargestellt werden. Dazu wird die Anwendungsbedingung
des verbotenen Story Patterns auf die Anwendungsbedingung eines Graphmusters abgebildet.
Enth¨
alt das verbotene Story Pattern negative Elemente, so wird die negative Anwendungsbedin-
gung des Graphmusters genau so gebildet, wie im Fall der Graphtransformationsregeln.
Abbildung 4.6(a) zeigt die kritische Situation impendingCollision als Story Pattern und Ab-
bildung 4.6(b) das dazu ¨
aquivalente Graphmuster.
4.4 Zusammenfassung
In Kapitel 2 wurden Story Patterns eingef¨
uhrt, um die Methoden, die von einem Real-Time
Statechart aufgerufen werden, modellieren zu k¨
onnen. Zudem wurden verbotene Story Patterns
eingef¨
uhrt, mit denen kritische Situationen und Unf¨
alle modelliert werden k¨
onnen. In Kapitel 3
wurdeein Verfahrenerl¨
autert,dass eineVerifikation vonGraphtransformationsregelnerm¨
oglicht.
Bei diesem Verfahren werden die nachzuweisenden Eigenschaften als verbotene Graphmuster
beschrieben.
In diesem Kapitel wurde informal gezeigt, dass die in Kapitel 2 eingef¨
uhrten Story Patterns
eine eingeschr¨
ankte Form der in Kapitel 3 definierten Graphtransformationsregeln sind. Eben-
so stellen die verbotenen Story Patterns eine eingeschr¨
ankte Form der verbotenen Graphmuster
dar. Somit ist es durch den Ansatz aus Kapitel 3 m¨
oglich, nachzuweisen, dass die Anwendung
4.4. ZUSAMMENFASSUNG 111
!!"#
$%
!"!#
&'%((
)&'*
+,(
#-./!0-12+
#-./!0-12+
3%
4
#-#0657+(85 #6+
$%
)"!!#
&'
$.
)&9
$0.;:<5=/+"3>
!!"#
+,(
#-./!0-12+
#-./!0-12+
? @ABDC6E.BFHG
.(
4
#-#0657+(85 #6+
I
#6+
!!"#
$%
!"!#
&'%((
)&'*
0J;:<5=/+!3>
+,(
#D!/"0-1K+
#-./!0-12+
L
MN
L
MO
P
3%
4
#-#0657+(85 #6+
$%
)"!!#
&'
)&9
$0.;:<5=/+"3>
+ ,(
I
$#6+
$Q
)"!!#
#-./!0-12+
#D!/"0-1K+
M
Abbildung 4.5: Graphtransformationsregel createDC
der Story Patterns nicht zu einer kritischen Situation oder einem Unfall (beschrieben durch ein
verbotenes Story Pattern) f¨
uhren kann.
Da eine manuelle Verifikation sowohl zeitaufw¨
andig als auch fehleranf¨
allig ist, wird im nach-
folgenden Kapitel gezeigt, wie der Ansatz automatisiert werden kann.
112 KAPITEL 4. STORY PATTERNS UND GRAPHTRANSFORMATIONSSYSTEME
(a) Kritische Situation
impendingCollision
als Story Pattern
!#" $&%
'()##*+
,-.
,- !#" $&%
/10
2,34 5
/10
"6798 +%:#;
0
<=">8?%:@8 >%
A=#B4>
2,-
+
.,-.=::
,- !#" $&%
3 <#*" $C%
'()##*+
DED=>%'B4>
(b) Kritische Situation impendingCollision als verbotenes Graphmuster
Abbildung 4.6: Die kritische Situation impendingCollision als Story Pattern und ¨
aquivalentes
verbotenes Graphmuster
Kapitel 5
Werkzeugunterst¨
utzung
In den vorangegangenen Kapiteln wurde die Modellierung und Verifikation der Software mecha-
tronischer Systeme vorgestellt. In diesem Kapitel soll nun die Umsetzung der Konzepte in der
Fujaba Real-Time Tool Suite1erl¨
autert werden.
Fujaba wird seit 1997 im Fachgebiet f¨
ur Softwaretechnik an der Universit¨
at Paderborn
entwickelt. Das urspr¨
ungliche Ziel von Fujaba bestand in einem Roundtrip Engineering, da-
her auch der Name Fujaba - From UML to Java and Back Again. Die Modellierung eines
Softwaresystems erfolgt mittels verschiedener UML-Diagramme. Aus den derart spezifizierten
Modellen kann lauff¨
ahiger Code erzeugt und zum Testen verwendet werden [Gei02]. Fujaba
erm¨
oglicht es jedoch auch, Java-Code einzulesen und als UML-Diagramme darstellen zu lassen
[NNWZ00, NNZ00].
2003 fand ein Redesign von Fujaba statt und Fujaba wurde zur Fujaba Tool Suite umstruktu-
riert. Die Fujaba Tool Suite unterst¨
utzt ein Plugin-Konzept, das es erm¨
oglicht, neue Diagrammar-
ten und Algorithmen in die Tool Suite einzuf¨
ugen [Wen03]. Dieser Plugin-Mechanismus wurde
dazu verwendet, um die Fujaba Real-Time Tool Suite zu erm¨
oglichen, in der die Modellierung
und Verifikation der Software von mechatronischen Systemen umgesetzt ist.
Im folgenden Abschnitt wird gezeigt, wie die Fujaba Real-Time Tool Suite den Prozess zur
Modellierung und Verifikation der Software mechatronischer Systeme unterst¨
utzt und einzelne
Phasen automatisiert. Im Kontext dieser Arbeit sind zwei neue Plugins entwickelt worden, die
den Entwickler dabei unterst¨
utzen, korrekte Story Patterns zu modellieren. Das erste Plugin bin-
det dazu den Simulator und Model Checker Groove an Fujaba an (Abschnitt 5.2). Das Plugin
in Abschnitt 5.3 nutzt die Tatsache aus, dass es sich bei Story Patterns um eine eingeschr¨
ankte
Form der in Kapitel 3 vorgestellten Graphtransformationsregeln handelt (siehe Kapitel 4). Es
stellt eine Umsetzung des in Kapitel 3 vorgestellten Verifikationsansatzes f¨
ur Story Patterns dar.
In Abschnitt 5.4 wird das bereits eingef¨
uhrte Shuttle-Beispiel mittels des zweiten Plugins verifi-
ziert.
1www.fujaba.de
113
114 KAPITEL 5. WERKZEUGUNTERST ¨
UTZUNG
5.1 Werkzeugunterst¨
utzung des Modellierungs- und Verifika-
tionsprozesses
In Abschnitt 2.5 wurde der Prozess zur Modellierung und Verifikation der Software mechatroni-
scher Systeme vorgestellt. In diesem Abschnitt wird nun gezeigt, wie die Fujaba Real-Time Tool
Suite die Phasen dieses Prozesses unterst¨
utzt bzw. automatisiert. Der Prozess l¨
asst sich grob in
die drei Aufgaben Modellierung, Verifikation und Codegenerierung unterteilen.
5.1.1 Modellierung
Wie in Kapitel 2 beschrieben, wird die Architektur der Software eines mechatronischen Systems
zum einen mittels Komponentendiagrammen beschrieben. Die Kommunikation zwischen den
Komponenten wird mittels Koordinationsmustern modelliert. Der interne Aufbau einer Kompo-
nente sowie ihre Datenstrukturen werden mittels Klassendiagrammen spezifiziert.
Die Kommunikationsprotokolle, die durch die Muster festgelegt werden sowie das kompo-
nenteninterne Verhalten werden durch Real-Time Statecharts angegeben. Die komponentenin-
ternen Real-Time Statecharts k¨
onnen Methoden aufrufen (entry()-, do()-, exit()-Methoden in den
Zust¨
anden und Methoden als Seiteneffekte an den Transitionen). Diese Methoden werden mit
Hilfe von Story Patterns beschrieben.
Klassendiagramme und Story Patterns geh¨
oren zum Kern von Fujaba. Koordinationsmuster,
Komponenten und Real-Time Statecharts wurden in der Fujaba Real-Time Tool Suite umgesetzt
[BGHS04, BGH+05, HG03].
Somit wird durch die Fujaba Real-Time Tool Suite die Modellierung der Softwarearchitektur
und des Koordinationsverhaltens unterst¨
utzt.
5.1.2 Verifikation
Nachdem die Softwarearchitektur und das Koordinationsverhalten spezifiziert wurden, erfolgt
die Verifikation des Systems.
Das Model Checking von Koordinationsmustern und Komponenten mit den dazugeh¨
origen
Real-Time Statecharts wurde in verschiedenen Plugins der Fujaba Real-Time Tool Suite um-
gesetzt. Dazu wurde zun¨
achst eine Schnittstelle entwickelt, die eine Anbindung verschiedener
Model Checker zul¨
asst. In [Hir04, BGHS04, BGH+05, HG03] wurde die Anbindung des Model
Checkers UPPAAL eingef¨
uhrt und in [Ste05] die Anbindung von RAVEN. Neben der Anbindung
verschiedener Model Checker erm¨
oglicht diese Schnittstelle auch, den Model Checking Prozess
in den Hintergrund zu verlegen. Das heißt, der Konsistenzmechanismus von Fujaba erkennt, dass
am Modell eine ¨
Anderung vorgenommen wurde und stellt fest, welche Eigenschaften dadurch
beeinflusst werden. Fujaba st¨
oßt dann automatisch den Model Checking Prozess f¨
ur das entspre-
chende Koordinationsmuster oder die entsprechende Komponente und die betroffene Eigenschaft
an. Das model Checking wird dann im Hintergrund durchgef¨
uhrt.
In den Real-Time Statecharts der Koordinationsmustern und Komponenten werden Metho-
den ausgef¨
uhrt. Diese werden durch Story Patterns beschrieben. Die Story Patterns m¨
ussen ei-
5.2. DAS GROOVE-PLUGIN 115
ne Menge von Sicherheitseigenschaften, beschrieben durch verbotene Story Patterns, einhalten.
Um die Entwicklung der Story Patterns zu unterst¨
utzen, wurde ein Plugin entwickelt, das Groo-
ve (einen Model Checker und Simulator f¨
ur Graphtransformationssysteme) an Fujaba anbindet.
Dieses Plugin bietet die M¨
oglichkeit, das Verhalten des durch die Story Patterns beschriebenen
Systems f¨
ur einen gegebenen Anfangszustand zu beobachten. K¨
onnen vom Anfangszustand aus
nur endlich viele verschiedene Zust¨
ande erreicht werden, so kann Groove mittels einer Erreich-
barkeitsanalyse pr¨
ufen, ob die Story Patterns einen inkorrekten Zustand erzeugen k¨
onnen. Dieses
Pluginin ist inAbschnitt 5.2 beschrieben.F¨
urdie eigentliche Verifikation vonStory Patterns wur-
de im Kontext dieser Arbeit ein Plugin entwickelt, das f¨
ur eine Menge von Story Patterns und
eine Menge von verbotenen Story Patterns eine automatische ¨
Uberpr¨
ufung durchf¨
uhrt. Dabei
wird festgestellt, ob das ”Nicht-Auftreten“der verbotenen Story Patterns eine induktive Invarian-
te des Systems darstellt. Das Plugin setzt somit den Ansatz aus Kapitel 3 f¨
ur Story Patterns um
und ist in Abschnitt 5.3 beschrieben.
5.1.3 Codegenerierung
Durch die Verifikation wird garantiert, dass das System eine Menge von Sicherheitseigenschaften
erf¨
ullt. Allerdings wurde bisher immer das Modell des Systems betrachtet und nicht der Code,
der im mechatronischen System wirklich ausgef¨
uhrt wird. Um sicherstellen zu k¨
onnen, dass auch
der Code die f¨
ur das Modell nachgewiesenen Eigenschaften erf¨
ullt, ist es notwendig, den Code
automatisch aus dem verifizierten Modell zu generieren.
Die Codegenerierung f¨
ur Klassendiagramme und Story Patterns ist Bestandteil des Fujaba
Kerns [FNT98, FNTZ98, NNWZ00, NNZ00]. F¨
ur Koordinationsmuster und Komponenten so-
wie deren Real-Time Statecharts wurde die Codegenerierung in der Fujaba Real-Time ToolSuite
umgesetzt [Bur02].
5.2 Das Groove-Plugin
In [Ren04] stellt Rensink Groove, ein Werkzeug zur Simulation und Verifikation von Graphtrans-
formationssystemen, vor. Dabei steht Groove f¨
ur GRaph-based Object-Oriented VErification.
Zurzeit unterst¨
utzt Groove eine Erreichbarkeitsanalyse f¨
ur strukturelle Eigenschaften. Die zu
¨
uberpr¨
ufenden Eigenschaften werden dabei als Graphtransformationsregel angegeben. Der Si-
mulator von Groove kann so konfiguriert werden, dass er f¨
ur eine derart spezifizierte Eigenschaft
¨
uberpr¨
uft, ob sie in jedem erreichbaren Zustand des Systems erf¨
ullt ist oder ob sie in keinem
erreichbaren Zustand erf¨
ullt ist. Dazu pr¨
uft der Simulator f¨
ur alle Graphen, die die erreichbaren
Zust¨
ande des Systems beschreiben, ob die entsprechende Regel auf sie anwendbar ist. Regeln,
die auf jeden Zustand anwendbar sein m¨
ussen, werden im Folgenden als geforderte Regeln oder
Eigenschaften bezeichnet und solche, die nie anwendbar sein d¨
urfen, als verbotene Regeln oder
Eigenschaften.
Groove ben¨
otigt als Eingabe einen Startgraphen, eine Menge von Graphtransformationsre-
geln sowie entweder eine geforderte oder eine verbotene Regel.
116 KAPITEL 5. WERKZEUGUNTERST ¨
UTZUNG
Die Graphen in Groove sind gerichtete Graphen mit beschrifteten Kanten. Die Notation der
Regeln ist ¨
ahnlich zu denen von Story Patterns. Die linke und rechte Regelseite einer Graph-
transformationsregel werden in einem Graphen zusammengefasst. Elemente, die durch die An-
wendung einer Regel gel¨
oscht oder erzeugt werden, werden entsprechend gekennzeichnet. Wie
in Story Patterns wird die negative Anwendungsbedingung in Form von negativen Knoten und
Kanten zum Diagramm hinzugef¨
ugt.
Im Rahmen dieser Arbeit wird Groove dazu verwendet, um f¨
ur eine Menge von Story Patterns
deren Anwendbarkeit zu untersuchen und zu pr¨
ufen, ob ihre Anwendung ausgehend von einem
gegebenen Anfangszustand eine kritische Situation oder Unfall verursachen kann. Dazu ist es
notwendig, die Story Patterns in die Eingabesprache von Groove zu transformieren.
Da Fujaba keine Objektdiagramme unterst¨
utzt, werden zu Evaluierungszwecken Story Pat-
terns verwendet, um den Startgraphen eines Graphtransformationssystems zu modellieren. Diese
Story Patterns d¨
urfen weder zu l¨
oschende oder zu erzeugende Elemente enthalten, noch d¨
urfen
sie negative Knoten oder Kanten besitzen. Die zu verifizierenden Regeln werden in Fujaba mit-
tels Story Patterns beschrieben. Ebenso werden die verbotenen oder geforderten Eigenschaften
als Story Patterns gegeben.
Der in Fujaba realisierte Export von Story Patterns in die Eingabesprache von Groove, die
Simulation und die Verifikation mittels Groove und die Darstellung eines von Groove erzeugten
Gegenbeispiels in Fujaba soll anhand des folgenden Beispiels erl¨
autert werden. Der Startgraph
entspricht dem in Abbildung 5.1 gegebenen Story Pattern. Dieses Story Pattern beschreibt ein
Shuttle-System bestehend aus f¨
unf Tracks, die im Kreis angeordnet sind sowie zwei Shuttles, die
sich auf jeweils einem Track befinden. Die zu verifizierende Regel ist die Regel moveSimple,
die in Abbildung 5.2 geben ist. Die Regel darf niemals dazu f¨
uhren, dass sich zwei Shuttles auf
dem selbem Track befinden. Diese Eigenschaft ist als verbotenes Story Pattern in Abbildung 5.3
gegeben und entspricht einem verbotenen Graphmuster.
Abbildung 5.1: Startgraph des zu verifizierenden Graphtransformationssystems
5.2. DAS GROOVE-PLUGIN 117
Abbildung 5.2: Zu verifizierende Regel moveSimple
Abbildung 5.3: Verbotenes Story Pattern collision
5.2.1 Export von Story Patterns
Bevor der Export der Story Patterns in die Eingabesprache von Groove erfolgen kann, muss f¨
ur
die einzelnen Story Patterns angegeben werden, ob es sich dabei um einen Startgraphen, eine
Regel oder ein gefordertes oder verbotenes Story Pattern handelt. Wird f¨
ur ein Story Pattern an-
gegeben, dass es sich dabei um eine Regel handelt, so besteht die M¨
oglichkeit, f¨
ur diese Regel
noch eine Priorit¨
at anzugeben. Das bedeutet, wenn auf ein Objektdiagramm zwei Story Patterns
angewendet werden k¨
onnen, so wird immer das Story Pattern mit der h¨
oheren Priorit¨
at ange-
wendet. Haben beide Story Patterns die gleiche Priorit¨
at, so wird nichtdeterministisch eines der
beiden Story Patterns angewendet.
Da die Transformation f¨
ur Startgraphen, Regeln und verbotene Graphmuster gleich ist, soll
sie hier am Beispiel der Regel moveSimple aus Abbildung 5.2 erl¨
autert werden.
Grooveunterscheidet zwischeneiner internen Darstellung undeiner graphischen Darstellung.
Im Folgenden werden jeweils beide Darstellungen angegeben.
F¨
ur jedes Objekt im Story Pattern wird ein Knoten in Groove erzeugt. In Story Patterns
k¨
onnen sowohl die Objekte, als auch die Links beschriftet sein. In Groove k¨
onnen dagegen nur
die Kanten beschriftet sein. Um auch einem Knoten eine Beschriftung zuweisen zu k¨
onnen, muss
eine Selbstkante eingef¨
ugt werden. Die Beschriftung des Knotens entspricht dann der Beschrif-
tung dieser Kante. Soll einem Knoten sowohl ein Name als auch ein Typ zugewiesen werden,
so m¨
ussen daf¨
ur zwei Kanten in das Modell eingef¨
ugt werden. Daraus resultieren jedoch Unter-
schiede bei der Anwendung eines Story Patterns und der entsprechenden Regel in Groove. Soll
das Story Pattern angewendet werden, so wird ¨
uberpr¨
uft, ob die Objekte des Story Patterns auf
Objekte im Objektdiagramm abgebildet werden k¨
onnen, die den gleichen Typ haben. Der Na-
me der Objekte wird bei dieser Abbildung jedoch nicht ber¨
ucksichtigt. Soll dagegen die Regel
in Groove angewendet werden, so ist das nur m¨
oglich, wenn alle Knoten und alle Kanten auf
den Anwendungsgraphen abbildbar sind. Das bedeutet, dass die Regel nur dann anwendbar ist,
wenn es einen Knoten im Anwendungsgraphen gibt, der den gleichen Namen wie der Knoten in
118 KAPITEL 5. WERKZEUGUNTERST ¨
UTZUNG
der Regel besitzt. Dadurch wird die Anwendbarkeit einer Regel im Vergleich zum dazugeh¨
ori-
gen Story Pattern eingeschr¨
ankt. Deshalb wird hier nur der jeweilige Objekttyp nach Groove
exportiert.
F¨
ur jeden Link des Story Patterns wird eine Kante in den Graph von Groove eingef¨
ugt, wobei
die Kantenbeschriftung dem Linktypen entspricht.
Wird ein Element durch das Story Pattern gel¨
oscht, erzeugt oder ist im Story Pattern als
negatives Element angegeben, so wird die Kantenbeschriftung in Groove um das Pr¨
afix ”del:“,
”new:“bzw. ”not:“erweitert. In der graphischen Darstellung wird das Pr¨
afix nicht angezeigt. Statt-
dessen werden zu l¨
oschende Elemente mit gestrichelten blauen Linien und blauer Schrift, zu
erzeugende Elemente mit dicken gr¨
unen Linien und gr¨
uner Schrift und negative Elemente mit
gestrichelten dicken roten Linien und roter Schrift dargestellt.
In Groove werden die Regeln im Single Pushout Ansatz angewendet. Resultieren aus einer
Regelanwendung lose Kanten, so werden sie durch Groove gel¨
oscht. Außerdem kann eine Re-
gel auf einen Graphen angewendet werden, wenn es einen Graphhomomorphismus gibt, der die
Anwendungsbedingung auf den Anwendungsgraphen abbildet. Ein solcher Homomorphismus
darf auch zwei Knoten der Anwendungsbedingung auf einen Knoten des Anwendungsgraphen
abbilden. Um zu erzwingen, dass die Regelanwendung im DPOiso Ansatz erfolgt, m¨
ussen zwei
Modifikationen an den Regeln erfolgen. 1. Bevor ein Story Pattern, das eine Regel darstellt, nach
Groove exportiert werden kann, muss es um zus¨
atzliche negative Knoten erweitert werden. Die-
se zus¨
atzlichen negativen Knoten verhindern eine Anwendung, sollten anderenfalls lose Kanten
entstehen. Die Erweiterung der Story Patterns entspricht der Erweiterung von Graphtransforma-
tionsregeln, die in Definition 27 gegeben ist. 2. Muss verhindert werden, dass zwei Knoten der
Regel auf den selben Knoten im Anwendungsgraphen abgebildet werden, d.h. es muss erzwun-
gen werden, dass der Match der linken Regelseite einem Teilgraphisomorphismus entspricht.
Dazu werden in Groove negative Kanten verwendet. F¨
ur jedes Paar von Knoten, die den selben
Typ haben und entweder durch die Regelanwendung gel¨
oscht oder explizit erhalten bleiben und
nicht negativ sind, muss eine zus¨
atzliche Kante eingef¨
ugt werden, die mit ”not:“beschriftet ist.
F¨
ur zwei negative Knoten mit dem selben Typen bzw. f¨
ur einen negativen Knoten und einen posi-
tiven Knoten, der nicht durch die Regel erzeugt wird, wird eine zus¨
atzliche mit ”!not“beschriftete
Kante eingef¨
ugt. In der graphischen Darstellung werden dann negative Kanten angezeigt, die mit
”=“bzw. ”!not“beschriftet sind.
Abbildung 5.4 zeigt die Regel moveSimple zum einen als Story Pattern und zum anderen
als Groove-Regel. Dabei wurde die successor-Kante und die Kante, die anzeigt, dass die beiden
Track-Knoten nicht auf den selben Knoten abgebildet werden d¨
urfen, als eine Kanten dargestellt.
5.2.2 Simulation und Verifikation mit Groove
Nachdem der Startgraph, die Transformationsregeln und die geforderten bzw. verbotenen Story
Patterns auf die Eingabesprache von Groove abgebildet wurden, wird Groove gestartet. Simula-
tion und Verifikation erfolgen in Groove in Abh¨
angigkeit davon, ob die Eingabe geforderte oder
verbotene Regeln enth¨
alt.
Verbotene Regeln stellen kritische Situationen oder Unf¨
alle dar. Eine kritische Situation oder
ein Unfall ist eingetreten, wenn die entsprechende verbotene Regel auf einen Systemzustand,
5.2. DAS GROOVE-PLUGIN 119
(a) Die Regel moveSimple
als Story Pattern (b) Die Regel moveSimple dar-
gestellt in Groove
Abbildung 5.4: Die Regel moveSimple als Story Pattern und als Groove-Regel
beschrieben durch einen Graphen, angewendet werden kann. Der Groove-Simulator erzeugt aus-
gehend vom Startzustand den Zustandsraum des Systems, in dem er alle m¨
oglichen Regeln
zun¨
achst auf den Anfangszustand und dann auf alle resultierenden Zust¨
ande anwendet. Der Auf-
bau des Zustandsraums endet an einem Graphen, wenn auf diesen entweder eine verbotene Regel
angewendet werden kann und der Graph somit inkorrekt ist oder wenn keine Regel anwendbar
ist. Der Zustandsraum wird als Baum dargestellt, wobei die Knoten den Zust¨
anden entsprechen
und die Kanten den Regelanwendungen. Aus Effizienzgr¨
unden wird f¨
ur mehrere isomorphe Gra-
phen nur ein Zustand erzeugt, sodass aus dem Baum ein Graph wird. Nach [HEWC97] wird
dieser Graph als Graphtransitionssystem bezeichnet.
W¨
ahlt man einen der Knoten des Graphen aus, so wird der entsprechende Zustand angezeigt
und die Anwendungsstelle der n¨
achsten Regel hervorgehoben. Eine weitere Hilfe, die Groove
bietet, besteht darin, dass der Simulator eine Liste enth¨
alt, in der die Namen aller angewendeten
Regeln aufgef¨
uhrt werden. Aus dieser Liste k¨
onnen dann R¨
uckschl¨
usse auf die Anwendbarkeit
der Regeln gezogen werden. Wurde eine Regel nicht angewendet, so kann dies am gew¨
ahlten
Initialgraphen liegen, es kann aber auch ein Indiz daf¨
ur sein, dass die Anwendungsbedingung zu
stark ist und eine Anwendung der Regel verhindert.
5.2.3 Darstellung von Gegenbeispielen
Nachdem die Analyse des Systems abgeschlossen ist, kann die Darstellung des Zustandsraums
in Groove dazu verwendet werden, um Gegenbeispiele zu finden, die zeigen, dass das System
inkorrekt ist. F¨
ur eine geforderte Eigenschaft ist ein solches Gegenbeispiel ein Graph, auf den
die entsprechende Regel nicht angewendet werden kann. Ein Gegenbeispiel f¨
ur eine verbotene
Eigenschaft ist ein Graph, auf den die entsprechende verbotene Regel angewendet werden kann.
Ziel ist es nun, solche Gegenbeispiele aus Groove zu exportieren und in der Fujaba Real-
Time Tool Suite darzustellen. Da bei großen Systemen mit vielen verschiedenen Zust¨
anden die
Darstellung des Zustandsraums un¨
ubersichtlich wird, soll statt des gesamten Zustandsraums nur
der k¨
urzeste Pfad vom Startzustand zu einem inkorrekten Endzustand betrachtet werden. Ein
solcher Pfad besteht aus einer Menge von Graphen und den darauf angewendeten Transformati-
onsregeln. Da die Graphen groß und somit un¨
ubersichtlich werden k¨
onnen und es f¨
ur eine Regel
120 KAPITEL 5. WERKZEUGUNTERST ¨
UTZUNG
unter Umst¨
anden mehrere Anwendgungsstellen in einem Graphen gibt, soll Groove so angepasst
werden, dass neben den Zust¨
anden des Systems auch die verwendeten Matchings der Regeln
gespeichert werden2.
Das Fenster, das das Gegenbeispiel anzeigt, ist dreigeteilt. Links oben wird eine Liste mit
den Namen aller verbotenen Story Patterns des Systems angegeben, f¨
ur die ein Gegenbeispiel
gefunden wurde. Darunter ist eine Tabelle abgebildet, in der von oben nach unten der Pfad vom
Startzustand zu einem Zustand aufgef¨
uhrt ist, auf den das ausgew¨
ahlte verbotene Story Pattern
angewendet werden kann. Links steht der jeweilige Zustand, daneben steht die auf diesen Zu-
stand angewendete Regel und der resultierende Zustand steht rechts. W¨
ahlt man eine Zeile aus,
so wird der links angegeben Graph im rechten Teil des Fensters angezeigt und die Anwendungs-
stelle des Story Patterns wird farblich hervorgehoben. Die Anwendungsstelle eines Story Patterns
wird gr¨
un hervorgehoben, die Anwendungsstelle eines verbotenen Story Patterns rot.
In Abbildung 5.5 ist ein Gegenbeispiel f¨
ur das Story Pattern moveSimple und das verbotene
Story Pattern collision gegeben.
Abbildung 5.5: Von Groove erzeugtes Gegenbeispiel in Fujaba dargestellt
5.3 Plugin zum Nachweis von induktiven Invarianten
Existierende Ans¨
atze zur Verifikation von Graphtransformationssystemen, wie zum Beispiel
Groove, ben¨
otigen einen Startgraphen. Zudem muss sichergestellt werden, dass ausgehend von
diesem Startgraphen nur endlich viele Graphen erreichbar sind (siehe Kapitel 6). In Kapitel 3
wurde dagegen ein Ansatz vorgestellt, der die Korrektheit eines Graphtransformationssystems
2Mit Rensink wurde das Austauschformat zwischen Fujaba und Groove definiert, sodass eine Umsetzung der
Idee in Fujaba bereits erfolgen konnte.
5.3. PLUGIN ZUM NACHWEIS VON INDUKTIVEN INVARIANTEN 121
auch dann sicher stellt, wenn kein Startgraph gegeben ist oder die Regeln unendlich viele Gra-
phen erzeugen k¨
onnen. Dazu wird gezeigt, dass das ”Nicht-Auftreten“eines verbotenen Gra-
phmusters eine induktive Invariante des Systems ist. Wie in Kapitel 4 gezeigt wurde, stellen Story
Patterns eine eingeschr¨
ankte Form der in Kapitel 3 eingef¨
uhrten Graphtransformationssysteme
dar. Deshalb ist es m¨
oglich, den Verifikationsansatz aus Kapitel 3 zur Verifikation von Story Pat-
terns zu verwenden. In diesem Abschnitt soll das Fujaba Plugin vorgestellt werden, dass den An-
satz f¨
ur Story Patterns umsetzt und vollautomatischausf¨
uhrt (siehe dazu auch [Bec05, BGS05a]).
Als Eingabe erwartet das Plugin eine Menge von Story Patterns sowie eine Menge von ver-
botenen Story Patterns. Im Gegensatz zu dem in Abschnitt 5.2 vorgestellten Groove-Plugin wird
jedoch kein Initialgraph ben¨
otigt.
Im Folgenden werden das Story Pattern moveSimple (Abbildung 5.4(a)) und das verbote-
ne Story Pattern collision (Abbildung 5.3) verwendet, um die Arbeitsweise der Funktionen zu
beschreiben.
5.3.1 Verifikation
Story Patterns werden in Fujaba im Single Pushout Ansatz angewendet, wobei das Matching der
Anwendungsbedingung ein Isomorphismus sein muss. Damit der Verifikationsansatz aus Kapitel
3 verwendet werden kann, m¨
ussen die Story Patterns im DPOiso Ansatz angewendet werden. Die
Verwendung eines Isomorphismus zur Beschreibung des Matchings garantiert, dass die Identifi-
kationsbedingung immer erf¨
ullt ist. Damit auch die Lose-Kanten-Bedingung immer erf¨
ullt wird,
m¨
ussen die Story Patterns um negative Elemente erweitert werden, die eine Anwendung verhin-
dern, wenn andernfalls lose Kanten resultieren. Die Erweiterung der Story Patterns erfolgt durch
die Funktion RuleExtension.
Der Verifikationsalgorithmus bestimmt f¨
ur jedes Story Pattern und jedes verbotene Story
Pattern alle m¨
oglichen Abbildungen der Nachbedingung auf das verbotene Story Pattern. Diese
Berechnung erfolgt mittels der Funktion Matching.
F¨
ur jede der durch Matching bestimmten Abbildungen wird ein neues Story Pattern erzeugt,
das sowohl die Nachbedingung des Story Patterns als auch das verbotene Story Pattern enth¨
alt.
Die Bildung dieses neuen Story Patterns ist die Aufgabe der Funktion Merge. Das neue Story
Pattern entspricht einem Ergebnisgraphmuster.
Auf das neue Story Pattern wird das Story Pattern r¨
uckw¨
arts angewendet. Das resultierende
Story Pattern entspricht dann einem Startgraphmuster. F¨
ur dieses Story Pattern muss ¨
uberpr¨
uft
werden, ob es korrekt ist, d.h. ob es kein verbotenes Story Pattern enth¨
alt und es kein Match f¨
ur
die Anwendungsbedingung eines h¨
oher priorisierten Story Patterns im Startgraphmuster gibt.
F¨
ur diese ¨
Uberpr¨
ufung wird wieder die Funktion Matching verwendet.
Matching
Die Matching-Funktion berechnet, ob es f¨
ur ein Story Pattern G1 ein Matching, in Form eines
Teilgraphisomorphismus, in einem anderen Story Pattern G2 gibt, d.h. G1 G2. Ist dies der Fall,
so wird das gefundene Matching zur¨
uckgegeben.
122 KAPITEL 5. WERKZEUGUNTERST ¨
UTZUNG
Die Funktion berechnet das Matching sukzessive. Sie beginnt mit einem Objektpaar, einem
Objekt n1 aus G1 und einem Objekt n2 aus G2. Sie pr¨
uft, ob diese beiden Objekte denselben Typ
haben und ob sie entweder beide positiv oder beide negativ sind. Ist dies nicht der Fall, so wird ein
neues Objektpaar bestimmt. Andernfalls wird diese Abbildung in das Matching aufgenommen.
F¨
ur alle Links, die inzident zu n1 sind, wird gepr¨
uft, ob es einen Link in G2 gibt, auf den sie
abgebildet werden k¨
onnen und der inzident zu n2 ist. Bei dieser Abbildung muss zum einen
gepr¨
uft werden, ob die Links vom selben Typ sind, beide entweder positiv oder beide negativ
sind und ob auf den Link aus G2 noch kein anderer Link aus G1 abgebildet wurde. Erf¨
ullt eine
Abbildung diese Eigenschaften, so wird sie ebenfalls in das Matching aufgenommen. Konnten
alle zu n1 inzidenten Links abgebildet werden, wird das jeweils zweite inzidente Objekt des
Links betrachtet und gepr¨
uft, ob dieses auf ein Objekt aus G2 abgebildet werden kann, auf das
bisher noch kein anderes Objekt abgebildet wurde.
K¨
onnen alle Objekte und Links aus G1 auf Objekte und Links aus G2 abgebildet werden, so
wird das berechnete Matching zur¨
uckgegeben.
Die Matching-Funktion wird unter anderem zur Bildung der Ergebnisgraphmuster ben¨
otigt.
Dazu muss die Funktion ein Matching eines Teil-Story Patterns3der Nachbedingung eines Story
Patterns in einem verbotenen Story Pattern bestimmen.
Betrachtet man das Story Pattern aus Abbildung 5.4(a), so stellen die Objekte rt2 und rs1
sowie der dazwischen verlaufende locatedOn-Link ein Teil-Story Pattern der Nachbedingung
dar. Wird f¨
ur dieses Teil-Story Pattern und das verbotene Story Pattern aus Abbildung 5.3 die
Matching-Funktion aufgerufen, so liefert sie zwei m¨
ogliche Matchings zur¨
uck. Der erste bildet
rt2 auf vt ab und rs1 auf vs1 und den zwischen rs1 und rt2 verlaufenden locatedOn-Link auf den
locatedOn-Link, der zwischen vs1 und vt verl¨
auft. Der zweite Match bildet rs1 auf vs2,rt2 auf
vt und den locatedOn-Link auf den Link zwischen vs2 und vt ab.
RuleExtension
Die Funktion RuleExtension wird dazu verwendet, ein Story Pattern um zus¨
atzliche negative Ob-
jekte zu erweitern, sodass die Anwendung des Story Patterns verhindert wird, wenn andernfalls
lose Kanten resultieren sollten. Diese Erweiterung erfolgt nur intern und ist f¨
ur den Benutzer
des Plugins nicht sichtbar. Die Funktion erweitert sowohl die Vor- als auch die Nachbedingung
des Story Patterns um zus¨
atzliche negative Elemente, damit weder bei der Vorw¨
arts- noch bei
der R¨
uckw¨
artsanwendung des Story Patterns lose Kanten entstehen k¨
onnen. Die Erweiterung
entspricht der Regelerweiterung aus Definition 27 in Kapitel 3.
Bei der Erweiterung der Vorbedingung werden alle Objekte betrachtet, die durch die Anwen-
dung des Story Patterns gel¨
oscht werden. Dazu wird im Klassendiagramm nachgesehen, welche
Typen adjazent zu dem Typ des zu l¨
oschenden Objektes sind. F¨
ur jeden dieser adjazenten Ty-
pen wird ein negatives Objekt in das Story Pattern eingef¨
ugt, falls dieses noch nicht existiert
und durch einen Link mit dem zu l¨
oschenden Objekt verbunden ist. Bei der Erweiterung der
Nachbedingung wird ebenso verfahren. Statt der zu l¨
oschenden Objekte werden jedoch die zu
3Ein Teil-Story Pattern besteht aus einer Teilmenge der Objekte und Links des urspr¨
unglichen Story Patterns.
Dabei muss jeder Link mit zwei Objekten verbunden sein.
5.3. PLUGIN ZUM NACHWEIS VON INDUKTIVEN INVARIANTEN 123
erzeugenden betrachtet. Diese zweite Erweiterung ist notwendig, damit auch bei der R¨
uckw¨
arts-
anwendung des Story Patterns die Bedingungen des DPOiso Ansatzes erf¨
ullt sind. Die Funktion
liefert das derart erweiterte Story Pattern zur¨
uck.
Da eine Erweiterung eines Story Patterns nur dann notwendig ist, wenn das Story Pattern
ein Objekt erzeugt oder l¨
oscht, das moveSimple Story Pattern jedoch nur einen locatedOn-Link
l¨
oscht und dann einen neuen erzeugt, ist eine Erweiterung dieses Story Patterns nicht notwendig.
Merging
Die Merging-Funktion erzeugt aus zwei Story Patterns G1 und G2 ein neues Story Pattern. Da-
zu ben¨
otigt sie ein von der Matching-Funktion berechnetes Matching, das einen Teil des Story
Patterns G1 auf einen Teil von G2 abbildet.
Sind die beiden Story Patterns und das Matching gegeben, so wird das neue Story Pattern
gebildet, indem das Story Pattern G1 durch alle Elemente aus G2 erweitert wird, die nicht durch
das Matching auf G1 abgebildet werden k¨
onnen. Das so entstandene Story Pattern wird von der
Funktion zur¨
uck gegeben.
Wird der Funktion das Story Pattern moveSimple, das verbotene Story Pattern collision und
der erste von der Matching-Funktion berechnete Match (rs1 wird auf vs1 abgebildet und rt2 auf
vt)¨
ubergeben, so erzeugt die Funktion das in Abbildung 5.6 dargestellte Story Pattern. Da dieses
Story Pattern aus der Nachbedingung des Story Patterns moveSimple und dem verbotenen Story
Pattern collision besteht, stellt es ein Ergebnisgraphmuster dar.
Abbildung 5.6: Durch die Merging-Funktion bestimmtes Story Pattern
Der Verifikationsalgorithmus
Der Verifikationsalgorithmus erwartet als Eingabe eine Menge von Story Patterns sowie eine
Menge von verbotenen Story Patterns. F¨
ur Story Patterns k¨
onnen Priorit¨
aten angegeben werden.
Das heißt, sind auf eine Instanzsituation zwei oder mehr Story Patterns anwendbar, wird das Sto-
ry Pattern mit der h¨
ochsten Priorit¨
at angewendet. Haben alle Story Patterns die gleiche Priorit¨
at,
so wird nichtdeterministisch eines der Story Patterns angewendet. Diese Priorit¨
aten m¨
ussen bei
der Verifikation ber¨
ucksichtigt werden.
In einem ersten Schritt wird f¨
ur jede Nachbedingung aller Story Patterns die Menge aller
Teil-Story Patterns bestimmt. F¨
ur jedes der Teil-Story Patterns werden dann mittels der Mat-
ching-Funktion alle Matchings mit allen verbotenen Story Patterns gebildet. Jedes gefundenen
124 KAPITEL 5. WERKZEUGUNTERST ¨
UTZUNG
Matching wird anschließend zusammen mit dem Story Pattern und dem verbotenen Story Pattern
an die Merge-Funktion ¨
ubergeben, die daraus ein neues Story Pattern, das Ergebnisgraphmuster,
bildet.
Das entsprechende Story Pattern wird durch die Funktion RuleExtension erweitert und
r¨
uckw¨
arts auf jedes der Ergebnisgraphmuster angewendet. Daraus resultieren die Startgraphmus-
ter. F¨
ur jedes dieser Startgraphmuster pr¨
uft die Matching-Funktion, ob es ein Matching f¨
ur ein
verbotenes Story Pattern in dem Startgraphmuster gibt. Kann kein solches Matching gefunden
werden, so wird gepr¨
uft, ob es ein Story Pattern mit h¨
oherer Priorit¨
at gibt, das auf das Start-
graphmuster angewendet werden kann, d.h. f¨
ur dessen Anwendungsbedingung es ein Matching
im Startgraphmuster gibt. Ist dies der Fall, so verhindert das h¨
oher priorisierte Story Pattern die
Anwendung des zuvor betrachteten Story Patterns. Kann kein solches h¨
oher priorisiertes Sto-
ry Pattern auf das Startgraphmuster angewendet werden, so wurde ein Gegenbeispiel gefunden,
das zeigt, dass die Anwendung des betrachteten Story Patterns zu einer kritischen Situation oder
einem Unfall f¨
uhren kann.
Die Menge der zu betrachtenden Ergebnisgraphmuster kann im Vergleich zu der Menge aus
Kapitel 3 reduziert werden. Diese Reduktion resultiert aus der geringeren Ausdrucksst¨
arke der
negativen Elemente im Vergleich zu den negativen Anwendungsbedingungen (siehe Abschnitt
4.2.2).
Wie in Graphtransformationssystemen gibt es auch bei Story Patterns zwei M¨
oglichkeiten
einen korrekten Graphen in einen inkorrekten zu ¨
uberf¨
uhren. Die erste besteht darin, dass ein
Element erzeugt wird, das Teil der Anwendungsbedingung des verbotenen Story Patterns ist.
Die zweite M¨
oglichkeit ist, dass ein Element gel¨
oscht wird und dieses Element zur negativen
Anwendungsbedingung des verbotenen Graphmusters geh¨
ort, aber nicht zu dessen Anwendungs-
bedingung.
Im ersten Fall unterscheiden sich die in Kapitel 3 betrachteten Graphtransformationssysteme
und Story Patterns nicht. Da in Story Patterns negative Kanten nur zwischen positiven Objekten
verlaufen d¨
urfen und negative Knoten nicht miteinander verbunden sein d¨
urfen, kann der zweite
Fall nur dann eintreten, wenn ein Element gel¨
oscht wird, das inzident bzw. adjazent zu einem
positiven Objekt ist. Deshalb brauchen im zweiten Fall bei den Story Patterns nur solche Ergeb-
nisgraphmuster betrachtet werden, bei denen die Matching-Funktion mindestens ein Objekt der
Nachbedingung des Story Patterns auf ein Objekt des verbotenen Story Patterns abbildet. Eine
Abbildung der Elemente der Nachbedingung auf die negativen Elemente des verbotenen Sto-
ry Patterns ist nicht notwendig. F¨
ur Graphtransformationsregeln m¨
ussen dagegen auch solche
F¨
alle betrachtet werden, in denen Knoten der rechten Regelseite auf Knoten eines Graphen der
negativen Anwendungsbedingung abgebildet werden k¨
onnen.
Hat der Algorithmus ein Gegenbeispiel gefunden, das zeigt, dass in einem System eine kriti-
sche Situation oder ein Unfall auftreten kann, so terminiert er. In diesem Fall wird das gefundene
Gegenbeispiel zur¨
uckgegeben. Terminiert der Algorithmus nachdem f¨
ur jedes Story Pattern und
jedes verbotene Story Pattern alle m¨
oglichen Start- und Ergebnisgraphmuster betrachtet wurden,
ohne das ein Gegenbeispiel gefunden wurde, so sind die Story Pattern korrekt im Bezug auf die
betrachtete Menge von verbotenen Story Patterns.
5.4. EVALUIERUNG 125
In manchen F¨
allen kann es vorkommen, dass der Algorithmus ”unknown“zur¨
uckliefert. Dies
bedeutet, dass das Startgraphmuster die Anwendungsbedingung eines verbotenen Story Patterns
oder eines h¨
oher priorisierten Story Patterns enth¨
alt. Allerdings kann keine der negativen Kanten
auf das Startgraphmuster abgebildet werden, bzw. f¨
ur keinen der negativen Knoten mit allen
inzidenten Kanten existiert eine Abbildung.
5.3.2 Darstellung von Gegenbeispielen
Ein Gegenbeispiel besteht aus einem Start- und einem Ergebnisgraphmuster zusammen mit ei-
nem Story Pattern, dessen Anwendung auf das Startgraphmuster im Ergebnisgraphmuster resul-
tiert. Terminiert der Algorithmus, nachdem er ein solches Gegenbeispiel gefunden hat, so werden
die beiden Graphmuster, die Instanzen des internen Metamodells darstellen, in Story Patterns
transformiert und k¨
onnen dann wieder in Fujaba dargestellt werden.
F¨
ur das Story Pattern moveSimple aus Abbildung 5.2 und das verbotene Story Pattern collisi-
on liefert der Algorithmus das in Abbildung 5.7 dargestellte Gegenbeispiel.
Das Gegenbeispiel besteht aus dem Startgraphmuster, dem Ergebnisgraphmuster sowie dem
angewendeten Story Pattern. Das obere der beiden dargestellten Graphmuster ist das Startgra-
phmuster, das untere das Ergebnisgraphmuster. Das angewendete Story Pattern wird nicht abge-
bildet. Von ihm wird nur der Name in der linken oberen Ecke des Fensters angegeben.
Das Gegenbeispiel in Abbildung 5.7 zeigt, dass die Anwendung des Story Patterns moveSim-
ple zu einem Objektdiagramm f¨
uhren kann, das den Unfall collision enth¨
alt. Dies ist genau dann
der Fall, wenn zwei Shuttles existieren, die auf benachbarten Tracks positioniert sind. Wird das
Story Pattern moveSimple nun auf das hintere der beiden Shuttles angewendet, so wird dieses
auf den n¨
achsten Track gesetzt und die beiden Shuttles befinden sich auf demselben Track.
5.4 Evaluierung
Im voran gegangenen Abschnitt wurde die prototypische Umsetzung des Verifikationsansatzes
aus Kapitel 3 f¨
ur Story Patterns beschrieben. Die Aufwandsabsch¨
atzung am Ende von Kapitel
3 ergab, dass der Verifikationsansatz exponentiell von der Gr¨
oße der Graphen, die die linke und
rechte Regelseite, die Graphmuster und die negativen Anwendungsbedingungen repr¨
asentieren,
abh¨
angt, aber nur linear von der Anzahl der Regeln und verbotenen Graphmuster. In diesem
Abschnitt soll anhand eines kleinen Beispiels gezeigt werden, dass die Laufzeit des Algorithmus
im Allgemeinen jedoch nicht so schlecht ist. Die Differenz zwischen dem berechneten Aufwand
und den gemessenen Zeiten resultiert daraus, dass die Aufwandsabsch¨
atzung den schlechtesten
Fall betrachtet. Dieser tritt ein, wenn weder die Elemente der Graphtransformationsregeln noch
der verbotenen Graphmuster typisiert sind. Dass die Elemente einer Regel oder eines verbotenen
Graphmusters nicht typisiert sind, trifft in der Realit¨
at jedoch selten ein.
Bevor in Abschnitt 5.4.2 die Evaluierung des Plugins zum automatischen Nachweis von in-
duktiven Invarianten beschrieben wird, werden in Abschnitt 5.4.1 die wichtigsten Charakteristi-
ken des evaluierten Modells genannt.
126 KAPITEL 5. WERKZEUGUNTERST ¨
UTZUNG
Abbildung 5.7: Von Fujaba generiertes Gegenbeispiel, das zeigt, dass das Story Pattern move-
Simple das verbotene Graphmuster collision erzeugen kann
5.4.1 Charakteristiken des Evaluierungsbeispiels
Zur Evaluierung des Plugins zum automatischen Nachweis von induktiven Invarianten wurden
die Graphtransformationsregeln und verbotenen Graphmuster aus dem Shuttle-Beispiel als Story
Patterns bzw. verbotene Story Patterns dargestellt. Wie in Abschnitt 2.3.2 beschrieben, werden
die Story Patterns und verbotenen Story Patterns hierarchisch angeordneten Kulturen zugewie-
sen. Zur Evaluierung wurden alle Story Patterns und verbotenen Graphmuster der ControlledMo-
vement-Kultur sowie der ¨
ubergeordneten Movement-Kultur verwendet.
Insgesamt wurden 7 Story Patterns verifiziert. Davon haben 4 Story Patterns Instanzierungs-
regeln dargestellt und 3 Verhaltensregeln. Bei der Verifikation wurde nachgewiesen, dass die
Story Patterns 12 verbotene Story Patterns erf¨
ullen. Von diesen 12 verbotenen Story Patterns
hat eins einen Unfall modelliert, 2 kritische Situationen und weitere 9 verbotene Story Patterns
wurden dazu verwendet, um die Kardinalit¨
aten des zugeh¨
origen Klassendiagramms nachzubil-
den. Die Nachbildung der Kardinalit¨
aten ist notwendig, da weder der Ansatz aus Kapitel 3 noch
dessen im voran gegangenen Abschnitt vorgestellte prototypische Umsetzung die im Klassendia-
gramm vorgegebenen Kardinalit¨
aten noch nicht ber¨
ucksichtigen (siehe dazu auch Abschnitt 7.2).
L¨
asst man die vorgegebenen Kardinalit¨
aten bei der Verifikation jedoch außer Acht, so liefert das
Plugin unter Umst¨
anden ung¨
ultige Gegenbeispiele. Alle verifizierten (verbotenen) Story Patterns
werden in Anhang A dargestellt und erl¨
autert.
Die Aufwandsabsch¨
atzung in Kapitel 3 hat ergeben, dass der Verifikationsaufwand von der
Gr¨
oße der Graphen abh¨
angig ist. F¨
ur Story Patterns und verbotene Story Patterns wird bei der
5.4. EVALUIERUNG 127
Evaluierung das folgende Gr¨
oßenmaß verwendet: Die Gr¨
oße eines (verbotenen) Story Patterns
entspricht der Anzahl der Objekte und Links, die bei seiner Anwendung erhalten bleiben oder
neu erzeugt werden sowie der Anzahl der negativen Elemente. Die Wahl dieses Maßes erfolgte
auf Grund der ¨
Uberlegung, dass der aufw¨
andigste Schritt bei der Verifikation die Bildung al-
ler m¨
oglichen Ergebnisgraphmuster ist. Ein solches Ergebnisgraphmuster setzt sich genau aus
den Elementen zusammen, die zum verbotenen Story Pattern geh¨
oren oder durch das zu veri-
fizierende Story Patterns erhalten bleiben bzw. erzeugt werden. Wurden die positiven Elemente
zu einem Ergebnisgraphmuster zusammengef¨
ugt, so wird die negative Anwendungsbedingung
durch Hinzuf¨
ugen der negativen Elemente gebildet.
Eine ¨
Ubersicht ¨
uber die Gr¨
oße der verifizierten Story Patterns und verbotenen Story Patterns
ist in Tabelle 5.1 gegeben. Dabei gibt #Ojeweils die Anzahl der Objekte an und #Ldie Anzahl
der Links.
Gr¨
oße der Story Patterns Gr¨
oße der verbotenen Story Patterns
Minimum Maximum Durchschnitt Minimum Maximum Durchschnitt
#O#L#O#L#O#L#O#L#O#L#O#L
5 8 10 11 7 9 2 2 4 4 3 3
Tabelle 5.1: Gr¨
oße der verifizierten (verbotenen) Story Patterns
5.4.2 Evaluierung des Plugins zum automatischen Nachweises von induk-
tiven Invarianten
Die Aufwandsabsch¨
atzung f¨
ur den Verifikationsansatz in Abschnitt 3.7.3 hat ergeben, dass der
Aufwand exponentiell in der Gr¨
oße der (verbotenen) Story Patterns, aber nur linear in deren
Anzahl ist. Die Absch¨
atzung erfolgte f¨
ur den schlechtesten Fall. Dieser tritt ein, wenn alle Ob-
jekte und Links der (verbotenen) Story Patterns denselben Typ haben. In diesem Abschnitt soll
zun¨
achst anhand eines kleinen Beispiels gezeigt werden, welche Auswirkungen die Gr¨
oße der
(verbotenen) Story Patterns auf den Aufwand hat. Im Anschluss daran wird dann gezeigt, welche
Auswirkungen die Verwendung von Typen auf den Verifikationsaufwand hat. In beiden F¨
allen
wird der Aufwand in Zeit gemessen.
Zur Evaluierung wurde ein Intel Pentium 4 mit 2.40GHz CPU und 512 KB Cache sowie 1GB
Hauptspeicher eingesetzt. Die Evaluierung wurde unter Linux durchgef¨
uhrt.
Um die Auswirkung der Gr¨
oße der (verbotenen) Story Patterns zu veranschaulichen, wird das
im vorgegangenen Abschnitt charakterisierte Beispiel verifiziert. Die Verifikation des Beispiels
ben¨
otigte insgesamt 84 Sekunden.
Bei der Verifikation wird f¨
ur jedes Paar, bestehend aus einem Story Pattern und einem verbo-
tenen Story Pattern, ¨
uberpr¨
uft, ob die Anwendung des Story Patterns das verbotene Story Pattern
erzeugen kann. Das Diagramm in Abbildung 5.8 zeigt die Verifikationszeiten f¨
ur jedes dieser
Paare. Die Zeiten sind in Sekunden angegeben. Statt der Namen der (verbotenen) Story Patterns
sind die jeweiligen Gr¨
oßen an den Achsen notiert. An der x-Achse sind die Gr¨
oßen der verifizier-
ten Story Patterns in aufsteigender Folge notiert. Die y-Achse stellt die Gr¨
oßen der verwendeten
128 KAPITEL 5. WERKZEUGUNTERST ¨
UTZUNG
verbotenen Story Patterns in aufsteigender Folge dar. Wie an der Graphik zu sehen ist, steigt
der Aufwand f¨
ur die Verifikation mit der Gr¨
oße der (verbotenen) Story Patterns an. Der Grund
daf¨
ur, dass die Verifikation der beiden gr¨
oßten verbotenen Story Patterns deutlich schneller war
als die Vorangegangenen liegt darin, dass die Objekte dieser beiden verbotenen Story Patterns
mehr unterschiedliche Typen haben als die der zuvor verifizierten.
2|2 2|2 2|2 2|2 2|2 3|2 3|2 4|3 4|3 4|3 4|4 4|4
5|8
6|9
8|9
10|11
0,0
1,0
2,0
3,0
4,0
5,0
6,0
7,0
8,0
9,0
Abbildung 5.8: Ben¨
otigte Verifikationszeiten
In Story Patterns haben alle Objekte einen Typ. Um den Einfluss der Verwendung von Ty-
pen auf den Verifikationsaufwand zeigen zu k¨
onnen, wurden allen Objekten die gleichen Typen
zugewiesen.
Verifiziert man die so modifizierten Story Patterns, so ergibt die Analyse, dass die Story Pat-
terns einen inkorrekten Zustand erzeugen k¨
onnen. In diesem Fall bricht die Analyse ab, sobald
ein Gegenbeispiel gefunden wurde. Um die Verifikationszeiten dennoch mit denen des korrekten,
typisierten Beispiels vergleichen zu k¨
onnen, wurde der Evaluierungsmodus des Plugins verwen-
det. Dieser Modus f¨
uhrt die Analyse so durch, als w¨
aren die zu verifizierenden Story Patterns
korrekt, d.h. in diesem Modus wird die Analyse nicht abgebrochen, wenn ein Gegenbeispiel ge-
5.4. EVALUIERUNG 129
funden wurde. Zudem stellt das Plugin in diesem Modus auch die gefundenen Gegenbeispiele
nicht dar, sodass das Plugin keine Zeit f¨
ur die graphische Darstellung ben¨
otigt.
Die Verifikation des gesamten nicht typisierten Beispiels musste nach etwa 12 Stunden er-
folglos abgebrochen werden. Eine weitere Analyse der 7 Story Patterns sowie der 3 verbotenen
Story Patterns, die im urspr¨
unglichen Beispiel den Unfall und die beiden kritischen Situationen
modelliert haben, konnte erfolgreich in 1755,8 Sekunden durchgef¨
uhrt werden. Tabelle 5.2 stellt
die ben¨
otigten Verifikationszeiten f¨
ur diese (verbotenen) Story Patterns aus dem typisierten und
dem nicht typisierten Beispiel gegen¨
uber. Wie schon in Abbildung 5.8, werden auch hier statt
der Namen der (verbotenen) Story Patterns deren Gr¨
oßen angegeben. Die Zeiten sind jeweils in
Sekunden angegeben.
Verbotene Story Patterns/ 3 |2 4 |4 4 |4
Story Patterns Typen keine Typen Typen keine Typen Typen keine Typen
5|5 0,4 1,1 0,4 7,8 0,4 6,4
6|6 0,4 1,4 0,4 12,3 0,5 12,4
6|4 0,4 2,0 0,4 12,9 0,4 15,7
6|10 0,4 1,4 0,4 26,5 0,4 10,6
5|9 0,4 2,1 0,4 1207,4 0,4 22,4
6|10 0,5 4,0 0,5 131,7 0,5 61,5
6|11 0,8 2,8 0,7 187,8 0,7 25,6
gesamt 3,3 14,8 3,4 1586,4 3,3 154,6
Tabelle 5.2: Vergleich der Verifikationszeiten mit und ohne Typen
Wie der Tabelle 5.2 zu entnehmen ist, ben¨
otigt die Verifikation ohne Typen deutlich l¨
anger
als die Verifikation mit Typen.
Die verifizierten (verbotenen) Story Patterns stammen aus der in Abschnitt 2.3.2 vorgestellten
ControlledMovement-Kultur. Die Verifikation der CoordinatedMovement-Kultur musste jedoch
ergebnislos nach mehr als 12 Stunden abgebrochen werden. Die CoorinatedMovement-Kultur
erweitert die ControlledMovement-Kultur um weitere 4 Story Patterns und 2 verbotene Story
Patterns. Die 6 zus¨
atzlichen (verbotenen) Story Patterns sind gr¨
oßer als die (verbotenen) Story
Patterns der ControlledMovement-Kultur und auch die Anzahl von Objekten mit demselben Typ
ist gr¨
oßer.
Ein Grund f¨
ur die beiden fehlgeschlagenen Verifikationsversuche besteht darin, dass es sich
bei dem Plugin um einen Prototypen handelt. Zurzeit berechnet das Plugin beispielsweise noch
zu viele Ergebnisgraphmuster. In Abschnitt 3.6 wurde gezeigt, dass nur solche Ergebnisgra-
phmuster relevant sind, bei denen mindestens ein Element, das durch das Story Pattern neu
erzeugt wird, auf ein Element des verbotenen Story Patterns abgebildet wird. Das Plugin be-
rechnet jedoch jedes m¨
ogliche Ergebnisgraphmuster. Das hat besonders dann Auswirkungen,
wenn (verbotene) Story Patterns mit vielen Objekten vom selben Typ verifiziert werden sollen.
Das Plugin wird zurzeit weiterentwickelt, um dieses Problem zu beheben. Dar¨
uber hinaus
wurde in [GSK+06] eine erste Idee pr¨
asentiert, die es erm¨
oglicht die (verbotenen) Story Pat-
terns symbolisch zu codieren. Auf diese Weise brauchen die Ergebnisgraphmuster nicht mehr
130 KAPITEL 5. WERKZEUGUNTERST ¨
UTZUNG
einzeln aufgez¨
ahlt werden, sondern k¨
onnen zu Mengen zusammengefasst werden. Um die Er-
gebnisgraphmuster zu bestimmen, die R¨
uckw¨
artsanwendung der Regeln durchzuf¨
uhren und f¨
ur
die resultierenden Startgraphmuster zu pr¨
ufen, ob diese eines der verbotenen Story Patterns oder
die Anwendungsbedingung eines h¨
oher priorisierten Story Patterns enthalten, wird der BDD-
basierte Interpreter CroCoPat [BNL05] verwendet.
5.5 Zusammenfassung
In diesem Kapitel wurde die Werkzeugunterst¨
utzung f¨
ur die Modellierung und Verifikation der
Software mechatronischer Systeme vorgestellt.
Die Fujaba Real-Time Tool Suite unterst¨
utzt die Modellierung der Softwarearchitektur so-
wohl durch Klassendiagramme als auch durch Komponentendigramme. F¨
ur die Modellierung
des Koordinationsverhaltens bietet Fujaba Real-Time Statecharts. Die in den Statecharts aufge-
rufenen Story Patterns sind ebenfalls Teil von Fujaba.
Zur Verifikation der Real-Time Statecharts existieren zwei Plugins, die die Model Checker
UPPAAL und RAVEN an Fujaba anbinden. Ein Plugin zur Verifikation von Story Patterns wurde
im Rahmen dieser Arbeit entwickelt. Dieses Plugin wurde in Abschnitt 5.3 vorgestellt und in
Abschnitt 5.4 evaluiert. Die Evaluierung hat die Aufwandsabsch¨
atzung aus Kapitel 3 best¨
atigt.
Sie hat aber auch gezeigt, dass die Verwendung von Typen die Verifikation deutlich beschleunigt.
Ist die Verifikation abgeschlossen, so bietet die Fujaba Real-Time Tool Suite die M¨
oglich-
keit, automatisch Code zu generieren. Dies bietet den Vorteil, dass Eigenschaften, die durch die
formale Verifikation nachgewiesen wurden, auch durch die Implementierung erf¨
ullt werden.
Kapitel 6
Verwandte Arbeiten
Der in den Kapiteln 2 und 3 vorgestellte Ansatz erm¨
oglicht eine kompositionale Modellierung
und Verifikation der Software mechatronischer Systeme. Außerdem wurde in Kapitel 5 gezeigt,
wie der Modellierungs- und Verifikationsprozess durch die Fujaba Real-Time Tool Suite un-
terst¨
utzt und automatisiert wird.
In diesem Kapitel sollen nun verwandte Arbeiten betrachtet werden. Ein ausf¨
uhrlicher Ver-
gleich des gesamten Modellierungs- und Verifikationsprozesses und seiner Umsetzung in der
Fujaba Real-Time Tool Suite mit verwandten Ans¨
atzen wurde von Burmester in [Bur05] vorge-
nommen. An dieser Stelle soll ein Vergleich des in Kapitel 3 vorgestellten Ansatzes zur Verifi-
kation von Graphtransformationssystemen mit anderen existierenden Ans¨
atzen erfolgen.
Es werden drei verschiedene Vorgehensweisen vorgestellt. Als erstes wird in Abschnitt 6.1
ein Ansatz beschrieben, der die Regeln eines Graphtransformationssystems so modifiziert, dass
ihre Anwendungen nicht zu einem inkorrekten Zustand f¨
uhren k¨
onnen. Die zweite betrachtete
Kategorie stellen Ans¨
atze dar, bei denen Model Checking Techniken dazu eingesetzt werden,
um bestimmte Eigenschaften f¨
ur ein Graphtransformationssystem nachzuweisen. Diese Ans¨
atze
werden in Abschnitt 6.2 beschrieben. In Abschnitt 6.3 werden Verifikationstechniken f¨
ur Graph-
transformationssysteme erl¨
autert, die auf Petrinetzanalysetechniken basieren.
6.1 Korrektheit per Konstruktion
Der von Heckel und Wagner in [HW95] vorgestellte Ansatz diente als Basis f¨
ur den in Kapitel
3 vorgestellten Ansatz zur Verifikation von Graphtransformationssystemen. Der Ansatz von He-
ckel und Wagner erm¨
oglicht es, Graphtransformationsregeln so zu modifizieren, dass bestimmte
strukturelle Eigenschaften eines beliebigen Graphen bei der Regelanwendung erhalten bleiben.
In der AGG Tool Suite1wurde dieser Ansatz prototypisch umgesetzt [Mat01].
Die Regeln werden im Single Pushout Ansatz angewendet. Ihre Anwendung kann durch
Conditional Constraints, die zur linken Regelseite hinzugef¨
ugt werden, eingeschr¨
ankt werden.
Die Eigenschaften, die durch die Anwendung einer Regel erhalten bleiben sollen, werden als
Konsistenzbedingung bezeichnet. Eine Konsistenzbedingung besteht dabei aus einer Menge von
graphischen Konsistenzconstraints.
1http://tfs.cs.tu-berlin.de/agg
131
132 KAPITEL 6. VERWANDTE ARBEITEN
Ein graphisches Konsistenzconstraint beschreibt eine strukturelle Eigenschaft eines Graphen,
wie beispielsweise das Vorhandensein oder die Abwesenheit von bestimmten Elementen oder die
Gleichheit zweier Elemente. Eine graphisches Konsistenzconstraint besteht aus zwei Graphen,
der Pr¨
amisse Pund der Konklusion Q; Wobei es einen totalen Homomorphismus gibt, der die
Pr¨
amisse auf die Konklusion abbildet. Ein Graph erf¨
ullt ein Konsistenzconstraint, wenn es einen
Homomorphismus gibt, der die Pr¨
amisse Pauf den Graphen abbildet und der so erweitert werden
kann, dass er neben Pauch die Konklusion Qauf den Graphen abbildet.
Ein Graph wird als konsistent bezeichnet, wenn er die Konsistenzbedingung erf¨
ullt. Ein
Graphtransformationssystem ist konsistent, wenn jede Anwendung einer Regel auf einen kon-
sistenten Graphen wieder einen konsistenten Graphen erzeugt.
Das Ziel des Ansatzes aus [HW95] besteht darin, die Regeln eines Graphtransformations-
systems so zu modifiziert, dass das System konsistent ist. Die Modifikation der Regeln erfolgt,
indem die rechte Regelseite durch eine so genannte Verklebung (engl. gluing) mit jeder der Kon-
sistenzbedingungen verbunden wird. Dabei werden jedoch nur die F¨
alle ber¨
ucksichtigt, bei denen
mindestens ein durch die Regel erzeugtes Element mit einem Element der Konsistenzbedingung
verklebt wird. Auf den bei der Verklebung entstehenden Graphen wird die inverse Regel ange-
wendet. Daraus resultiert wieder ein Graph. Dieser Graph stellt dann ein zus¨
atzliches Conditional
Constraint der linken Regelseite dar. Auf diese Weise wird verhindert, dass die Regel anwendbar
ist, wenn andernfalls die Konsistenzbedingung verletzt wird.
Die Definition der von Heckel und Wagner eingef¨
uhrten Konsistenzbedingungen entspricht
der Definition der induktiven Invarianten. Beide Begriffe bezeichnen Eigenschaften, die, wenn
sie von einem Graphen erf¨
ullt sind, durch die Anwendung einer beliebigen Regel erhalten blei-
ben.
Ein Unterschied zwischen den beiden Ans¨
atzen besteht in der Verwendung von negativen
Anwendungsbedingungen in Regeln und verbotenen Graphmustern bzw. graphischen Konsis-
tenzconstraints. Die negative Anwendungsbedingung einer Regel oder eines verbotenen Gra-
phmusters aus Kapitel 3 kann aus einer Menge von Graphen bestehen, die Alternativen beschrei-
ben. Dagegen kann die Pr¨
amisse einer Regel oder eines Konsistenzconstraints in [HW95] nur
aus einem Graphen bestehen. Der Ansatz von Heckel und Wagner bietet zwar die M¨
oglichkeit
zus¨
atzlich zur Pr¨
amisse noch eine Konklusion anzugeben, diese kann bei Regeln aus einer Men-
ge von Graphen bestehen, bei Konsistenzbedingungen nur aus genau einem Graphen, allerdings
haben die Pr¨
amissen eine andere Semantik als die negativen Anwendungsbedingungen aus Ka-
pitel 3. Eine Regel ist nach [HW95] anwendbar bzw. ein Konsistenzconstraint erf¨
ullt, wenn die
Pr¨
amisse mittels eines Homomorphismus auf den Anwendungsgraphen abbildbar ist und der ver-
wendete Homomorphismus so erweitert werden kann, dass er auch mindestens einen Graphen
der Konklusion auf den Anwendungsgraphen abbildet.
In Kapitel 3 wurde gezeigt, dass ein korrekter Graph auf zwei Arten in einen inkorrekten
Graphen ¨
uberf¨
uhrt werden kann. Zum einen indem bei einer Regelanwendung ein Element er-
zeugt wird, das Teil der Anwendungsbedingung des verbotenen Graphmusters ist. Zum andere
kann eine Regel ein Element l¨
oschen, das zur negativen Anwendungsbedingung, aber nicht zur
Anwendungsbedingung des verbotenen Graphmusters geh¨
ort. Beim Nachweis induktiver Inva-
rianten, wie er in dieser Arbeit vorgestellt wurde, werden beide F¨
alle ber¨
ucksichtigt. Dagegen
wird in [HW95] nur der erste Fall betrachtet.
6.1. KORREKTHEIT PER KONSTRUKTION 133
Bei der Modifikation der Graphtransformationsregeln nach [HW95] wird jedes Konsistenz-
constraint unabh¨
angig von den anderen Constraints betrachtet. Das kann dazu f¨
uhren, dass eine
Regel unn¨
otig um zus¨
atzliche Conditional Constraints erweitert wird. Das ist genau dann der
Fall, wenn ein Konsistenzconstraint c1nur verletzt werden kann, wenn die betrachtete Regel auf
einen Graphen angewendet wird, der zwar das Constraint c1erf¨
ullt, aber inkonsistent in Bezug
auf ein zweites Konsistenzconstraint c2ist. Im schlimmsten Fall kann die Anwendung einer Re-
gel auch ohne Modifikation keine inkonsistenten Graphen erzeugen, der Ansatz f¨
ugt aber f¨
ur
jedes Konsistenzconstraint und jede seiner m¨
oglichen Verklebungen mit der rechten Regelseite
ein neues Conditional Constraint zur linken Regelseite hinzu. Um eine so erweiterte Regel an-
wenden zu k¨
onnen, muss f¨
ur jedes Conditional Constraint ¨
uberpr¨
uft werden, ob es erf¨
ullt ist.
Dies kann einen erheblichen Mehraufwand f¨
ur die sp¨
atere Regelanwendung bedeuten.
Im Gegensatz dazu werden beim Nachweis von induktiven Invarianten die verbotenen Gra-
phmuster nicht unabh¨
angig voneinander betrachtet. Nachdem das Ergebnisgraphmuster gebildet
wurde, wird die entsprechende Regel r¨
uckw¨
arts auf das Muster angewendet. F¨
ur das resultieren-
de Startgraphmuster wird dann ¨
uberpr¨
uft, ob es ein verbotenes Muster enth¨
alt. Kann ein beliebi-
ges verbotenes Graphmuster im Startgraphmuster gefunden werden, so hat die Regelanwendung
einen inkorrekten Graphen in einen anderen inkorrekten Graphen ¨
uberf¨
uhrt. Die Zahl der gebil-
deten Ergebnisgraphmuster entspricht der Zahl der Verklebungen (zumindest f¨
ur den Fall, dass
die Regel ein Element erzeugt, das Teil der Anwendungsbedingung des verbotenen Graphmus-
ters ist). Im Gegensatz zum Ansatz aus [HW95] m¨
ussen diese Ergebnisgraphmuster jedoch nur
einmal zur Verifikation betrachtet werden, w¨
ahrend die Konsistenzconstraints bei jeder Regelan-
wendung wieder ¨
uberpr¨
uft werden m¨
ussen.
Die Verwendung des Single Pushout Ansatzes kann sogar dazu f¨
uhren, dass Conditional
Constraints zur linken Regelseite hinzugef¨
ugt werden, die eine Regelanwendung verhindern,
obwohl diese nicht in einem inkonsistenten Graphen enden. Dies ist genau dann der Fall, wenn
bei der R¨
uckw¨
artsanwendung der Regel Kanten implizit gel¨
oscht werden, d.h. es werden lose
Kanten entfernt. Mindestens ein inzidenter Knoten dieser Kante ist Teil der Regel. Die Kante
selber ist aber weder Teil der linken noch der rechten Regelseite. Wendet man eine solche Regel
zun¨
achst r¨
uckw¨
arts auf einen Graphen G1an und dieselbe Regel dann wieder in Vorw¨
artsrichtung
auf den resultierenden Graphen, so erh¨
alt man nicht den Graphen G1, da die implizit gel¨
oschte
Kante nicht wieder erzeugt wird. Der Ansatz hat also zuviele Conditional Constraints erzeugt.
Um solche Probleme zu verhindern, wurde in Kapitel 3 der DPOiso eingef¨
uhrt.
Insgesamt gibt es einige Parallelen zwischen dem Ansatz von Heckel und Wagner und dem
in Kapitel 3 vorgestellten Ansatz. Allerdings f¨
uhrt das Hinzuf¨
ugen von zus¨
atzlichen Graphen zur
negativen Anwendungsbedingung dazu, dass die ¨
Uberpr¨
ufung zur Laufzeit, ob die entsprechende
Regel anwendbar ist, l¨
anger dauert als zuvor. Dies ist dann kritisch, wenn eine Regelanwendung
auch ohne die zus¨
atzlichen Graphen nicht anwendbar w¨
are, bzw. nicht zu einer Inkonsistenz
f¨
uhren kann. Es ist jedoch vorstellbar, die beiden Ans¨
atze zu kombinieren, sodass zun¨
achst eine
¨
Uberpr¨
ufung der Regeln durchgef¨
uhrt wird und nur im Fehlerfall eine Modifikation der Regeln
erfolgt. Dazu m¨
usste jedoch der Ansatz aus [HW95] zun¨
achst an die Formalisierung aus Kapitel
3 angepasst werden.
Eine solche Erweiterung und Kombination des Ansatzes von Heckel und Wagner wird auch
von Koch, Mancini und Parisi-Presicce in [KPP03, KMPP02] vorgeschlagen.
134 KAPITEL 6. VERWANDTE ARBEITEN
Die Autoren erweitern den Ansatz von Heckel und Wagner um den Fall, dass die Anwen-
dung einer Regel ein Element l¨
oscht und dadurch eine Sicherheitseigenschaft verletzt. Zudem
erfolgt bei Koch et al. eine Modifikation einer Regel nur dann, wenn ihre Anwendung zu einem
inkorrekten Graphen f¨
uhren kann.
Mit dem Verfahren, das Koch et al. in [KMPP02] vorstellen, ist esm¨
oglich eine obere Schran-
ke zu bestimmen, die angibt, wann die Anwendungen der Regeln ausgehend von einem ge-
gebenen Startgraphen sp¨
atestens zu einem inkorrekten Graphen f¨
uhren m¨
ussen. Die maxima-
le Pfadl¨
ange wird in Abh¨
anigkeit vom gegebenen Startgraphen sowie der Anzahl der Regeln
bestimmt. Mittels dieser maximalen Pfadl¨
ange kann dann ein beschr¨
anktes Model Checking
(engl. bounded Model Checking) durchgef¨
uhrt werden, d.h. ausgehend vom Startgraphen wird
der Zustandsraum des Systems durch Anwendung der Regeln aufgebaut (siehe dazu auch Ab-
schnitt 6.2). F¨
ur jeden erzeugten Graphen wird ¨
uberpr¨
uft, ob er korrekt ist. Kann ein Graph
erzeugt werden, der inkorrekt ist, bricht die Analyse ab. Sonst wird die Analyse f¨
ur jeden der
Pfade solange durchgef¨
uhrt bis er zu Ende ist, d.h. keine Regelanwendung mehr m¨
oglich ist,
oder bis der betrachtete Pfad die maximale Pfadl¨
ange erreicht hat. Kann im letzteren Fall kein
inkorrekter Graph erreicht werden, so ist das betrachtete System korrekt.
Wird ein Graph erreicht, der inkorrekt ist, so wird die zuletzt angewendete Regel durch die
Erweiterung des Ansatzes von Heckel und Wagner modifiziert.
Der Ansatz von Koch et al. erweitert den von Heckel und Wagner zwar f¨
ur den Fall, dass
die Anwendung einer Regel ein Element l¨
oscht und dadurch eine Eigenschaft verletzt und mo-
difiziert eine Regel nur dann, wenn sie einen inkorrekten Graphen erzeugt, unterliegt aber an-
sonsten den gleichen Einschr¨
ankungen. Um die maximal zu betrachtende Pfadl¨
ange bestimmen
zu k¨
onnen, m¨
ussen die Regeln im Vergleich zu denen von Heckel und Wagner deutlich ein-
geschr¨
ankt werden. So darf eine Regel entweder Elemente erzeugen oder l¨
oschen, aber nicht
beides. Zudem d¨
urfen nur Regeln, die Elemente l¨
oschen, eine negative Anwendungsbedingung
besitzen. Diese beiden Einschr¨
ankungen der Regeln und vor allem die letztere sind jedoch f¨
ur
die hier betrachteten mechatronischen Systeme zu stark. Dar¨
uber hinaus ist der Ansatz nur dann
anwendbar, wenn der Startgraph gegeben ist. Auch diese Annahme trifft in mechatronischen
Systemen im Allgemeinen nicht zu.
6.2 Model Checking von Graphtransformationssystemen
Eine M¨
oglichkeit, die Korrektheit eines Graphtransformationssystems nachzuweisen, stellt das
Model Checking dar. Die Grundlage f¨
ur das Model Checking von Graphtransformationssys-
temen wurde von Heckel et al. in [HEWC97] eingef¨
uhrt. Aufbauend auf dieser Idee k¨
onnen
Graphtransformationssysteme auf zwei Arten mittels Model Checking verifiziert werden. Zum
einen k¨
onnen die Systeme auf die Eingabesprache eines existierenden Model Checkers abgebil-
det werden, so wie dies in CheckVML und OBGG erfolgt. Zum anderen ist es auch m¨
oglich,
Model Checking Techniken direkt auf Graphtransformationssysteme anzuwenden. Ein solcher
Model Checker f¨
ur Graphtransformationssysteme ist Groove (siehe auch Abschnitt 5.2).
In [HEWC97] haben Heckel, Ehrig, Wolter und Corradini die Grundlage f¨
ur das Model
Checking von Graphtransformationssystemen eingef¨
uhrt. Die von den Autoren betrachteten Re-
6.2. MODEL CHECKING VON GRAPHTRANSFORMATIONSSYSTEMEN 135
geln werden im Double Pushout Ansatz angewendet und d¨
urfen keine negative Anwendungsbe-
dingung besitzen. Die Graphen der betrachteten Systeme sind typisiert.
Ans¨
atze, die auf dem Ansatz von Heckel et al. aufbauen und in Werkzeugen realisiert wurden,
sind der CheckVML-Ansatz von Varr`
o et al. (Check Visual Modeling Languages, [SV03, Var04],
der Groove-Ansatz von Rensink (GRaph-based Oject-Oriented VErification2, siehe Abschnitt 5.2
und [Ren03, Ren04]) sowie der OBGG-Ansatz von Dotti et al. (Object-Based Graph Grammars,
[DFRS03]). Wobei sowohl bei Varr`
o als auch bei Rensink der Single Pushout Ansatz zur Re-
gelanwendung verwendet wird. Der OBGG-Ansatz verwendet dagegen den klassischen Double
Pushout Ansatz ohne negative Anwendungsbedingungen. Zus¨
atzlich werden die Regeln in die-
sem Ansatz so eingeschr¨
ankt, dass Objekte nicht gel¨
oscht werden d¨
urfen.
Die Idee der Ans¨
atze besteht darin, ein gegebenes Graphtransformationssystem auf ein Tran-
sitionssystem (z.B. Kripkestruktur oder Graphtransitionssystem, siehe Abschnitt 5.2) abzubil-
den. Jeder Zustand eines solchen Transitionssystems entspricht dann einem Graphen. Der Start-
zustand entspricht dem Initialgraphen des Graphtransformationssystems. Kann eine Regel auf
einen bestimmten Graphen angewendet werden, so existiert im Transitionssystem f¨
ur diese Re-
gelanwendung eine Transition. Der Ausgangszustand der Transition repr¨
asentiert den Anwen-
dungsgraphen und der Zielzustand den aus der Regelanwendung resultierenden Graphen.
Heckel et al. verwenden zur Beschreibung der Eigenschaften, die durch die Verifikation nach-
gewiesen werden sollen, graphische Konsistenzbedingungen (siehe Abschnitt 6.1) bzw. tem-
porallogische Formeln. Eine temporallogische Formel f¨
ur Graphtransformationssysteme setzt
sich aus den ¨
ublichen All- und Existenzquantoren sowie den Pfadquantoren temporallogischer
Formeln zusammen (siehe [CGP02] Kapitel 3). Die atomaren Eigenschaften solcher Formeln
werden durch graphische Konsistenzbedingungen beschrieben. In CheckVML und OBGG wer-
den die Eigenschaften mittels temporallogischer Formeln beschrieben. Groove verwendet zur
Spezifikation der Eigenschaften geforderte und verbotene Regeln (siehe Abschnitt 5.2).
Wurde ein Graphtransformationssystem in ein Transitionssystem ¨
uberf¨
uhrt, so kann Model
Checking [CGP02] dazu verwendet werden, um nachzuweisen, dass das System korrekt ist im
Bezug auf eine Menge von Eigenschaften. Die Realisierung des Model Checkings kann auf ver-
schiedene Arten erfolgen. In CheckVML wird ein Graphtransformationssystem zun¨
achst auf
einen abstrakten Zustandsautomaten (engl. abstract state machine) abgebildet. Ein solcher ab-
strakter Zustandsautomat kann dann auf die Eingabesprache eines existierenden Model Checkers
abgebildet werden, wie zum Beispiel auf PROMELA die Eingabesprache von SPIN [Hol03].
Auch Dotti et al. verwenden zur Verifikation SPIN. Rensink hat dagegen mit Groove einen spe-
ziellen Model Checker f¨
ur Graphtransformationssysteme entwickelt.
Die Abbildung von Graphtransformationssystemen auf Transitionssysteme erm¨
oglicht die
Verwendung von Model Checkern zur Verifikation, d.h. sie kann dazu verwendet werden, einen
Nachweis operationaler Invarianten zu f¨
uhren. Durch diese Technik k¨
onnen jedoch nur Syste-
me mit endlichem Zustandsraum betrachtet werden. Um zu erreichen, dass das zu verifizieren-
de System einen endlichen Zustandsraum hat, verwendet CheckVML ein beschr¨
anktes Model
Checking. Dazu muss a priori festgelegt werden wie viele Objekte von einem Typ zur Laufzeit
erzeugt werden d¨
urfen. Nach [RSV04] ist CheckVML deshalb f¨
ur Systeme mit vielen dyna-
2http://www.cs.utwente.nl/∼groove
136 KAPITEL 6. VERWANDTE ARBEITEN
misch erzeugten Objekten nicht so gut geeignet wie Groove. Diese Tatsache war ein Grund f¨
ur
die Anbindung von Groove an Fujaba.
Aber auch wenn ein System einen endlichen Zustandsraum besitzt, kann das so genannte
Zustandsraumexplosionsproblem (engl. state space explosion problem) die Verifikation verhin-
dern. Das bedeutet, wenn das System aus zu vielen Zust¨
anden besteht, ist das Model Checking
nicht mehr m¨
oglich. Zwar unterst¨
utzen CheckVML und Groove verschiedene Optimierungstech-
niken, es ist jedoch trotzdem nicht m¨
oglich, Systeme mit mehr als 700.000 Zust¨
anden mittels
CheckVML und 500.000 Zust¨
anden mittels Groove zu verifizieren [RSV04].
Um ¨
uberhaupt ein Model Checking durchf¨
uhren zu k¨
onnen, wird von allen vorgestellten
Ans¨
atzen/Werkzeugen ein Initialgraph ben¨
otigt.
Da f¨
ur mechatronische Systeme nicht garantiert werden kann, dass diese einen endlichen
Zustandsraum besitzen und der Initialgraph zum Verifikationszeitpunkt noch nicht bekannt sein
muss, sind Ans¨
atze zum Model Checking von Graphtransformationssystemen in dieser Dom¨
ane
nur begrenzt einsetzbar. Gegen die Verwendung des OBGG-Ansatzes spricht zudem die starke
Einschr¨
ankung der Regeln.
Kompositionale Verifikation
Um Graphtransformationssysteme mit großem, aber endlichem Zustandsraum verifizieren zu
k¨
onnen, schl¨
agt Heckel in [Hec98] und Heckel, Lajios und Menge in [HLM05] eine komposi-
tionale Verifikation vor. Dazu wird das Gesamtsystem in kleinere Teilsysteme, die so genannten
Sichten, unterteilt. Eine Sicht besteht aus einem Teil des Typgraphen, der angibt, welche Typen in
der Sicht betrachtet werden. Jeder Sicht wird ein Anfangszustand zugewiesen, der dem urspr¨
ung-
lichen Anfangszustand entspricht, aber auf die in der Sicht zul¨
assigen Typen eingeschr¨
ankt ist.
Ebenso entsprechen die Regeln der Sicht den Regeln des Gesamtsystems, werden aber auf die
Typen der Sicht eingeschr¨
ankt. Wird eine der Regeln angewendet, so erfolgt die Anwendung in
allen Sichten synchron unter dem gleichen Auftreten der linken Regelseite. Auf diese Weise wird
garantiert, dass Eigenschaften, die f¨
ur eine Sicht nachgewiesen wurden, auch im Gesamtsystem
gelten.
Damit die Dekomposition Auswirkungen auf die Verifikation hat, muss sie so gew¨
ahlt wer-
den, dass die Anwendung einer Regel nur in m¨
oglichst wenigen Sichten Auswirkungen hat.
Die Dekomposition muss manuell vom Entwickler durchgef¨
uhrt werden. Ist die Dekompositi-
on erfolgt, so kann die Verifikation erfolgen. Dabei wird die in [HEWC97] beschriebene Idee
verwendet, um jede der Sichten unabh¨
angig von allen anderen Sichten zu verifizieren.
Mittels eines solchen kompositionalen Vorgehens lassen sich auch Systeme mit gr¨
oßerem
Zustandsraum verifizieren. Allerdings muss die Dekomposition in Sichten manuell durch den
Entwickler erfolgen, was fehleranf¨
allig ist. Bei der Verifikation der Story Patterns ist eine solche
manuelle Dekomposition in Teilsysteme, die voneinander unabh¨
angig verifiziert werden k¨
onnen,
nicht notwendig. Sie ergibt sich aus der Verwendung der Kulturhierarchien. Wurden die Sichten
gut gew¨
ahlt, erm¨
oglicht der Ansatz zwar die Verifikation von Graphtransformationssystemen
mit einem großen Zustandsraum, die mit einem nicht-kompositionalen Vorgehen nicht verifi-
ziert werden k¨
onnen, jedoch gilt auch hier, dass der Zustandsraum endlich und ein Initialgraph
gegeben sein muss.
6.3. ANALYSE MITTELS PETRINETZTECHNIKEN 137
6.3 Analyse mittels Petrinetztechniken
Im voran gegangenen Abschnitt wurde Model Checking dazu verwendet, Eigenschaften f¨
ur
ein Graphtransformationssystem nachzuweisen. Baldan, Corradini und K¨
onig [BCK01, BK02,
BCK, BCK04] sowie Padberg und Enders [PE02] verwenden dagegen Petrinetztechniken zur
Analyse von Graphtransformationssystemen.
Da die Anwendung beider Ans¨
atze starken Restriktionen unterliegen, die in mechatronischen
Systemen im Allgemeinen nicht erf¨
ullt werden und es f¨
ur beide Ans¨
atze keine Werkzeugun-
terst¨
utzung gibt, sollen die beiden Ans¨
atze hier nur kurz skizziert werden. In beiden Ans¨
atzen
erfolgt die Regelanwendung im Double Pushout Ansatz, wobei die Regeln keine negativen An-
wendungsbedingungen besitzen d¨
urfen. Zudem ben¨
otigen beide Ans¨
atze einen Initialgraphen,
um die Analyse durchf¨
uhren zu k¨
onnen.
6.3.1 Approximierte Entfaltung
Das Ziel von Baldan, Corradini und K¨
onig [BCK01, BK02, BCK, BCK04] besteht darin, Graph-
transformationssysteme mittels existierender Techniken zu verifizieren. Dazu werden die Graph-
transformationssysteme, auch solche mit unendlichem Zustandsraum, durch eine approximierte
Entfaltung (engl. apporixmated unfolding) auf eine endliche Struktur, die so genannten Petri-
graphen, abgebildet. Ein Petrigraph besteht aus einem Petrinetz und einem Graphen. Die Tran-
sitionen des Petrinetzes entsprechen den Regelanwendungen des urspr¨
unglichen Graphtransfor-
mationssystems. Jeder Graph, der durch das Graphtransformationssystem erzeugt werden kann,
entspricht einer erreichbaren Markierung des Petrinetzes, sodass zur Verifikation des Systems
existierende Petrinetztechniken verwendet werden k¨
onnen.
Durch die approximierte Entfaltung entsteht ein Petrigraph, der aus einem Graphen und ei-
nem Petrinetz besteht. Jeder Graph, der durch das Graphtransformationssystem erzeugt werden
kann, kann durch einen Graphhomomorphismus auf den Graphen des Petrigraphen abgebildet
werden. Außerdem gilt, dass jeder durch das Graphtransformationssystem erzeugbare Graph ei-
ner erreichbaren Markierung im Petrinetzes des Petrigraphen entspricht. Deshalb gilt, dass je-
de Eigenschaft, die im Graphtransformationssystem erf¨
ullt ist, auch im Petrigraphen erf¨
ullt ist.
Bei der Verifikation auf dem Graphen k¨
onnen Erreichbarkeitsanalysen durchgef¨
uhrt und Ver-
klemmungen erkannt werden. Die Analyse des Petrinetzes erm¨
oglicht zudem den Nachweis von
Lebendigkeitseigenschaften und Transitionsinvarianten.
Dieser Ansatz ist jedoch f¨
ur die Analyse von mechatronischen Systeme nicht geeignet, da
er starken Restriktionen unterliegt. Zu den bereits zu Beginn dieses Abschnitts genannten Ein-
schr¨
ankungen kommt, dass durch die Regeln nur Kanten gel¨
oscht werden d¨
urfen. Knoten d¨
urfen
dagegen nur neu erzeugt werden. Diese Restriktion wird in einem mechatronischen System im
Allgemeinen nicht erf¨
ullt.
6.3.2 Regelinvarianten in Graphtransformationssystemen
Das Ziel von Padberg und Enders [PE02] besteht darin, Petrinetzanalysetechniken auf Graph-
transformationssysteme zu ¨
ubertragen.
138 KAPITEL 6. VERWANDTE ARBEITEN
Die Autoren ¨
ubertragen die Begriffe Markierung (engl. marking), Schalten von Transitio-
nen (engl. firing), Erreichbarkeit von Markierungen (engl reachable), Lebendigkeit des Netzes
(engl. liveness), Beschr¨
ankung (engl. bounded) und vorallem Transitionsinvarianten.
Die ersten f¨
unf Begriffe k¨
onnen direkt auf Graphtransformationssysteme ¨
ubertragen werden,
z.B. entspricht ein erreichbarer Graph im Graphtransformationssystem einer erreichbaren Mar-
kierung im Petrinetz. Da Graphtransformationssysteme m¨
achtiger sind als Petrinetze, ist eine
direkte ¨
Ubertragung der Transitionsinvarianten auf Regelinvarianten nicht m¨
oglich. Eine Tran-
sitionsinvariante besagt, dass nach dem Schalten einer beliebigen Sequenz von Transitionen die
urspr¨
ungliche Markierung wieder erreicht wird. Dementsprechend besagt eine Regelinvariante,
dass die Anwendung einer Sequenz von Regeln wieder im urspr¨
unglichen Graphen endet.
Eine Sequenz von Regeln ist eine Regelinvariante, wenn alle Elemente, die durch die An-
wendungen der Regeln gel¨
oscht werden, durch die Anwendungen auch wieder erzeugt werden.
Um festzustellen, ob dies der Fall ist, werden die Regeln der Sequenz zu einer Regel mit multi-
plen Pushout zusammengefasst. Gilt dann, dass es einen Isomorphismus gibt, der die linke Seite
des multiplen Pushouts Lauf die rechte Seite Rabbildet, so stellt die Sequenz der Regeln einen
Regelinvariante dar.
Abgesehen davon, dass der Ansatz zur Analyse einen Startgraphen ben¨
otigt und die Regeln
keine negativen Anwendungsbedingungen enthalten d¨
urfen, ist es nicht m¨
oglich, beschriftete
bzw. typisierte Graphen zu verwenden. Das Hauptproblem dieses Ansatzes besteht jedoch darin,
dass jede m¨
ogliche Regelsequenz betrachtet werden muss. Da in einer solchen Sequenz jede
Regel beliebig oft auftreten kann, gibt es unendlich viele M¨
oglichkeiten eine solche Sequenz zu
bilden, obwohl die Zahl der Regeln endlich ist.
6.4 Zusammenfassung
In diesem Kapitel wurden verwandte Arbeiten vorgestellt. Es wurden verschiedene Vorgehens-
weise erl¨
autert, die dazu verwendet werden k¨
onnen, die Korrektheit von Graphtransformations-
systemen zu garantieren.
Der erste dazu vorgestellte Ansatz modifiziert die Regeln eines Graphtransformationssystems
so, dass nur korrekte Zust¨
ande durch die Regelanwendung erzeugt werden k¨
onnen. Allerdings er-
folgt eine solche Modifikation auch dann, wenn die Regel schon vorher korrekt war, wodurch die
negativen Anwendungsbedingungen der Regeln unn¨
otig vergr¨
oßert werden. Der darauf aufbau-
ende Ansatz, der eine Regel nur dann ver¨
andert, wenn deren Anwendung zu einem Fehler f¨
uhren
kann, ben¨
otigt einen Startgraphen und schr¨
ankt die Ausdrucksst¨
arke der Transformationsregeln
stark ein.
Die ¨
ubrigen Ans¨
atze verifizieren, ob ein gegebenes Graphtransformationssystem korrekt ist.
Diese Ans¨
atze ben¨
otigen alle einen Startgraphen, um die Verifikation durchf¨
uhren zu k¨
onnen.
Nur der Ansatz zur approximierten Entfaltung von Baldan, Corradini und K¨
onig ist zur Verifi-
kation von Graphtransformationssystemen mit unendlichen Zustandsr¨
aumen geeignet, unterliegt
aber anderen Einschr¨
ankungen, die eine Anwendung des Ansatzes f¨
ur die Verifikation der Soft-
ware mechatronischer Systeme verhindern.
Kapitel 7
Zusammenfassung und Ausblick
In den Kapiteln 2 und 3 wurde ein Ansatz zur kompositionalen Modellierung und Verifikation
der Software mechatronischer Systeme vorgestellt. In Kapitel 5 wurde gezeigt, wie die Modellie-
rung und Verifikation in der Fujaba Real-Time Tool Suite prototypisch umgesetzt worden ist. In
diesem Kapitel soll der gesamte Ansatz noch einmal zusammengefasst werden und ein Ausblick
auf zuk¨
unftige Arbeiten gegeben werden.
7.1 Zusammenfassung
Ein mechatronisches System kann als Operator-Controller-Modul aufgefasst werden, dessen In-
formationsverarbeitung in die Bereiche Controller, reflektorischer Operator und kognitiver Ope-
rator unterteilt ist. Die Software, die zur Informationsverarbeitung im reflektorischen Operator
eingesetzt wird, ist f¨
ur die Steuerung des Controllers sowie f¨
ur die Koordination mit anderen
OCMs verantwortlich. Da die Software des reflektorischen Operators sicherheitskritisch ist, be-
stand das Ziel dieser Arbeit darin, einen Ansatz zur kompositionalen Modellierung und Verifika-
tion der Software zu entwickeln.
Der vorgestellte Ansatz baut auf den existierenden Konzepten der MECHATRONIC UML auf
und erweitert diese.
In der MECHATRONIC UML wird die Softwarearchitektur eines mechatronischen Systems
mittels Komponentendiagrammen beschrieben. Die Interaktion, die zwischen zwei oder mehr
Komponenten stattfinden soll, wird durch Koordinationsmuster spezifiziert.
Verhalten, sowohl komponenteninternes Verhalten als auch das Kommunikationsverhalten
zwischen verschiedenen Komponenten, wird durch Real-Time Statecharts modelliert.
Die Verifikation der Koordinationsmuster und Komponenten erfolgt durch komopsitionales
Model Checking, d.h. jedes Koordinationsmuster und jede Komponente kann unabh¨
angig von
den anderen Koordinationsmustern und Komponenten verifiziert werden. Im Gegensatz zu den
meisten anderen kompositionalen Ans¨
atzen ist es nicht notwendig, zun¨
achst das gesamte Modell
zu erstellen und dann in kleinere verifizierbare Teilmodelle zu unterteilen. Die Dekomposition
des Modells ergibt sich aus der Modellierung.
139
140 KAPITEL 7. ZUSAMMENFASSUNG UND AUSBLICK
Nach der erfolgreichen Verifikation der Koordinationsmuster und Komponenten gilt: Intera-
gieren mehrere Komponenteninstanzen ausschließlich ¨
uber Instanzen der Koordinationsmuster,
so ist diese Interaktion sicher. Allerdings sind mechatronische Systeme sehr dynamisch. Dar-
aus folgt, dass bei der Instanzierung einer Komponente nicht bekannt ist, mit welchen ande-
ren Komponenten sie zur Laufzeit interagieren muss. Da in mechatronischen Systemen zudem
nur begrenzte Speicher- und Rechenkapazit¨
aten vorhanden sind, ist es nicht m¨
oglich, zwischen
jedem Paar von Komponenteninstanzen alle m¨
oglichen Muster zu instanzieren. Stattdessen ist
es notwendig, zur Laufzeit die ben¨
otigten Koordinationsmuster zu instanzieren und nicht mehr
ben¨
otigte Instanzen eines Koordinationsmusters wieder zu l¨
oschen.
Eine Methode, die ein Koordinationsmuster instanziert, kann als Story Pattern modelliert
werden. Ein solches Story Pattern wird dann durch das komponenteninterne Real-Time State-
chart als entry()-, do()- oder exit()-Methode in einem Zustand aufgerufen oder als Seiteneffekt
beim Schalten einer Transition ausgef¨
uhrt.
Bei der Verifikation der Komponente wird davon ausgegangen, dass die aufgerufenen Me-
thoden korrekt sind, sie werden durch das Model Checking nicht ¨
uberpr¨
uft. Um die Korrektheit
der Methoden nachzuweisen, wurde in dieser Arbeit ein neuer Ansatz vorgestellt.
In diesem Ansatz wird ein Systemzustand als Graph aufgefasst, dessen Knoten den im Sys-
temzustand vorkommenden Objekten entsprechen und dessen Kanten die Links des Systemzu-
stands darstellen. Ein Story Pattern, das Objekte und Links erzeugt oder l¨
oscht, stellt dann eine
spezielle Form einer Graphtransformationsregel dar. Sicherheitseigenschaften, die bei der An-
wendung einer solchen Regel erhalten bleiben m¨
ussen, werden durch Graphmuster spezifiziert.
Eigenschaften, die kritische Situationen oder Unf¨
alle modellieren und niemals auftreten d¨
urfen,
werden als verbotene Graphmuster beschrieben. Auch diese Graphmuster k¨
onnen durch Story
Patterns dargestellt werden.
Die meisten der existierenden Ans¨
atze zur Verifikation von Graphtransformationssystemen
ben¨
otigen zum einen einen initialen Graphen, also einen Anfangszustand des Systems. Zum an-
deren muss gelten, dass ausgehend vom Initialgraphen nur endlich viele Graphen durch die An-
wendung der Regeln erreichbar sind. Da diese Einschr¨
ankungen in einem mechatronischen Sys-
tem zumeist jedoch nicht erf¨
ullt sind, wurde in dieser Arbeit ein Ansatz vorgestellt, der diesen
Einschr¨
ankungen nicht unterliegt. Statt nachzuweisen, dass alle erreichbaren Graphen korrekt
sind, zeigt der Ansatz, dass eine Regelanwendung auf einen korrekten Graphen immer wieder
in einem korrekten Graphen resultiert. Die Erreichbarkeit eines Graphen wird dabei außer Acht
gelassen. Das heißt, der Ansatz zeigt, dass die Abwesenheit der verbotenen Graphmuster eine
induktive Invariante des Systems ist. Der Nachweis wird dabei r¨
uckw¨
arts gef¨
uhrt, d.h. f¨
ur einen
inkorrekten Graphen wird gepr¨
uft, ob dieser das Resultat einer Regelanwendung auf einen kor-
rekten Graphen ist.
F¨
ur eine Graphtransformationsregel gilt, dass sie nur Auswirkungen auf Elemente des An-
wendungsgraphen haben kann, auf die die Elemente der Regel abgebildet werden. Zudem kann
die Anwendung einer Regel nur auf zwei Arten zu einer Verletzung einer Eigenschaft f¨
uhren,
d.h. einen Graphen erzeugen, der ein verbotenes Graphmuster enth¨
alt. Zum einen, wenn sie ein
Element erzeugt, sodass die Anwendungsbedingung des verbotenen Graphmusters erf¨
ullt ist, die
negative Anwendungsbedingung jedoch nicht. Zum anderen, wenn sie ein Element der negativen
Anwendungsbedingung l¨
oscht.
7.2. AUSBLICK 141
Diese Fakten k¨
onnen beim Nachweis induktiver Invarianten ausgenutzt werden. Statt
vollst¨
andige Graphen zu betrachten, werden Graphmuster betrachtet. Ein solches Graphmuster
besteht aus der rechten Seite einer Regel sowie aus einem verbotenen Graphmuster. Es wird als
Ergebnisgraphmuster bezeichnet und repr¨
asentiert die Menge aller Graphen, auf die die rech-
te Regelseite und das verbotene Graphmuster abgebildet werden k¨
onnen. Da das Ergebnisgra-
phmuster ein verbotenes Graphmuster enth¨
alt, beschreibt es eine Menge von inkorrekten Gra-
phen. Zudem enth¨
alt das Ergebnisgraphmuster die rechte Regelseite, sodass eine R¨
uckw¨
artsan-
wendung der entsprechenden Regel auf das Ergebnisgraphmuster m¨
oglich ist.
Wird die Regel r¨
uckw¨
arts auf das Ergebnisgraphmuster angewendet, so resultiert das Start-
graphmuster. Enth¨
alt dieses Startgraphmuster keines der verbotenen Graphmuster, so gilt, dass
jeder korrekte Graph, auf den das Startgraphmuster abgebildet werden kann, durch Anwendung
der betrachteten Regel in einen Graphen ¨
uberf¨
uhrt werden kann, der das Ergebnisgraphmuster
enth¨
alt und somit inkorrekt ist.
Das Verfahren kann auch f¨
ur Systeme mit unendlich großem Zustandsraum angewendet
werden. Dar¨
uber hinaus wird zur Verifikation kein Initialgraph ben¨
otigt. In einer Aufwands-
absch¨
atzung wurde gezeigt, dass der Ansatz linear in der Anzahl der Regeln und verbotenen
Graphmuster, aber exponentiell in der Gr¨
oße der Graphen der Regel und verbotenen Graphmus-
ter ist. Das Verfahren wurde als Plugin in der Fujaba Real-Time Tool Suite prototypisch reali-
siert. In einer Evaluierung konnte gezeigt werden, dass das Verfahren trotz seiner Komplexit¨
at
anwendbar ist, wenn die Graphen der Regeln und der verbotenen Graphmuster nicht zu groß
sind.
Ist die Verifikation der Koordinationsmuster und Komponenten sowie der Methoden, die in
den Komponenten intern aufgerufen werden, abgeschlossen, so ist auch der gesamte Verifika-
tionsprozess abgeschlossen. Eine Verifikation des gesamten Modells ist nicht notwendig und
meistens auf Grund der Gr¨
oße des Modells auch nicht m¨
oglich. Die vorgestellten Modellierungs-
und Verifikationskonzepte garantieren, dass das gesamte Modell korrekt ist, wenn es syntaktisch
korrekt aus den verifizierten Koordinationsmustern und Komponenten zusammengesetzt wird.
Damit auch der Code, der sp¨
ater im mechatronischen System wirklich ausgef¨
uhrt wird, die
verifizierten Sicherheitseigenschaften erf¨
ullt, muss er automatisch generiert werden. Da zur Mo-
dellierung nur Diagrammarten verwendet werden, f¨
ur die auch eine formale Semantik definiert
wurde, ist eine solche automatische Codegenerierung m¨
oglich.
7.2 Ausblick
Im Fachgebiet Softwaretechnik laufen zurzeit verschiedene Arbeiten, in denen die MECHATRO-
NIC UML erweitert wird. Dabei betrachten die Arbeiten vor allem Erweiterungen um hybride
Aspekte, d.h. die Modellierung und Verifikation von kontinuierlichen und diskreten Werten (sie-
he dazu auch [Bur05]).
In diesem Abschnitt soll genauer auf die Erweiterungsm¨
oglichkeiten des Ansatzes zum au-
tomatischen Nachweis induktiver Invarianten eingegangen werden.
Dieser Ansatz wurde dazu entwickelt, um die Methoden, die durch Story Patterns beschrie-
ben und in einem mechatronischen System ausgef¨
uhrt werden, verifizieren zu k¨
onnen. Die
142 KAPITEL 7. ZUSAMMENFASSUNG UND AUSBLICK
Ausf¨
uhrung einer solchen Methode, d.h. die Anwendung eines Story Patterns auf eine Instanz-
situation f¨
uhrt dazu, dass neue Objekte und Links erzeugt oder existierende Objekte und Links
gel¨
oscht werden. Ein wichtiges Konzept der objektorientierten Modellierung, das zwar durch
die Story Patterns, nicht aber durch den vorgestellten Verifikationsansatz, unterst¨
utzt wird, ist
die Vererbung. Um auch Story Patterns verifizieren zu k¨
onnen, in denen Vererbung verwendet
wurde, ist eine Erweiterung des Ansatzes notwendig.
Neben der Vererbung unterst¨
utzen Story Patterns auch die Modifikation von Attributwerten
eines existierenden Objekts. Eine Erweiterung des Verifikationsansatzes um Attribute und deren
Modifikation ist deshalb angebracht.
In den Klassendiagrammen, die dazu verwendet werden, um die Typen der Objekte und ih-
rer m¨
oglichen Verbindungen zu spezifizieren, k¨
onnen Kardinalit¨
aten spezifiziert werden. Diese
geben f¨
ur ein Objekt an, wieviele andere Objekte von einem bestimmten Typ adjazent zu ihm
sein k¨
onnen. Um diese Kardinalit¨
aten bei der Verifikation ber¨
ucksichtigen zu k¨
onnen, m¨
ussen
zus¨
atzliche verbotene Graphmuster angegeben werden. Dies ist zwar prinzipiell m¨
oglich, hat sich
jedoch bei der Evaluierung des Ansatzes in der Fujaba Real-Time Tool Suite als eine sehr l¨
asti-
ge Arbeit herausgestellt. Deshalb sollte der Ansatz so erweitert werden, dass die Kardinalit¨
aten
bei der Verifikation ber¨
ucksichtigt werden ohne das explizit zus¨
atzliche verbotene Graphmuster
spezifiziert werden m¨
ussen.
Die Story Patterns werden dazu verwendet, um Methoden eines mechatronischen Systems zu
spezifizieren. Zurzeit ist es unter bestimmten Umst¨
anden m¨
oglich, mit dem Ansatz von Seibel
[Sei05] festzustellen, wie lange diese Ausf¨
uhrung maximal dauert. Eine explizite Modellierung
und Verifikation von Zeit und Zeiteigenschaften wird momentan jedoch nicht von den Story Pat-
terns unterst¨
utzt und kann auch mit dem Ansatz aus Kapitel 3 noch nicht verifiziert werden. Da
Zeit in mechatronischen Systemen jedoch eine besondere Rolle spielt, sollte sie in die Modellie-
rung und die Verifikation der Story Patterns aufgenommen werden.
Story Patterns stehen meist nicht allein, sondern beschreiben eine Aktivit¨
at eines Story Dia-
gramms. Wird ein Story Diagramm auf eine Instanzsituation angewendet, so wird zun¨
achst das
Story Pattern der Startaktivit¨
at angewendet. Dann das Story Pattern der n¨
achsten Aktivit¨
at und
so weiter, bis das Story Pattern der Stopaktivit¨
at angewendet wurde. Eine Sicherheitseigenschaft
ist eine induktive Invariante eines Systems, wenn ein Story Diagramm angewendet auf eine kor-
rekte Instanzsituation wieder in einer korrekten Instanzsituation resultiert. Die Instanzsituationen
nach dem Anwenden des Story Patterns der Startaktivit¨
at und vor der Anwendung der Stopak-
tivit¨
at m¨
ussen die Sicherheitseigenschaft nicht erf¨
ullen. Der in Kapitel 3 vorgestellte Ansatz ist
zur Verifikation solcher Story Diagramme im Allgemeinen aufgrund seiner Komplexit¨
at nicht
anwendbar. F¨
ur sehr einfache Story Diagramme mit relativ kleinen Story Patterns sollte eine
Anwendung des Ansatzes jedoch m¨
oglich sein.
Alle bisher vorgestellten Erweiterungsm¨
oglichkeiten f¨
uhren dazu, dass die Komplexit¨
at des
Ansatzes weiter steigt. Um diese Komplexit¨
at in den Griff zu bekommen, reichen die Mittel,
die bisher im Plugin zum automatischen Nachweis induktiver Invarianten eingesetzt werden, je-
doch nicht aus. Eine M¨
oglichkeit, die Verifikation trotz der erh¨
ohten Komplexit¨
at durchf¨
uhren
zu k¨
onnen, besteht darin, das Verifikationsproblem auf ein Constraint-Solving-Problem abzu-
bilden. Zum L¨
osen des Problems kann dann ein existierender Constraint-Solver (z.B. ILOG
7.2. AUSBLICK 143
Solver1) verwendet werden. Zudem wurde in [GSK+06] eine Idee skizziert, wie man das Pro-
blem symbolisch kodieren und dadurch den Verifikationsaufwand verringern kann. Dazu werden
die Ergebnisgraphmuster in Mengen zusammengefasst. Die Bildung dieser Mengen sowie die
R¨
uckw¨
artsanwendung der Regeln und der Test, ob die resultierenden Startgraphmuster korrekt
sind, erfolgt mittels des BDD-basierten Interpreters CroCoPat [BNL05].
Eine weitere M¨
oglichkeit, der Komplexit¨
at entgegenzuwirken, besteht darin, die Komposi-
tionalit¨
at der Modellierung bei der Verifikation st¨
arker auszunutzen. So wurden in Abschnitt
2.3.2 die Kulturhierarchien eingef¨
uhrt, um mechatronische Systeme kompositional modellieren
und verifizieren zu k¨
onnen. Zurzeit werden die Informationen aus einer solchen Hierarchie nur
insofern bei der Verifikation ausgenutzt, dass bei der Verifikation der Regeln einer Kultur nur
die Regeln und verbotenen Graphmuster von ¨
ubergeordneten Kulturen ber¨
ucksichtigt werden.
Untergeordnete Kulturen oder Kulturen, die in anderen Zweigen der Hierarchie angeordnet sind
brauchen nicht ber¨
ucksichtigt werden. Es ist jedoch vorstellbar, dass Verifikationsergebnisse aus
h¨
oheren Hierarchien bei der Verifikation untergeordneter Kulturen ausgenutzt werden k¨
onnen.
Beispielsweise haben die Verhaltensregeln einer h¨
oheren Hierarchieebene eine geringere Prio-
rit¨
at als die einer untergeordneten Ebene. Die Instanzierungs- und Verhaltensregeln erf¨
ullen die
Sicherheitseigenschaften ihrer Hierarchieebene und aller h¨
oheren Ebenen. Da die Verhaltensre-
geln der h¨
oheren Ebenen nur anwendbar sind, wenn keine Regel der aktuell betrachteten Kultur
anwendbar ist, sollten sie auch deren Sicherheitseigenschaften nicht verletzen k¨
onnen.
Neben der Erweiterung, die es erm¨
oglicht, noch ausdruckst¨
arkere Story Patterns zu verifi-
zieren, besteht auch die M¨
oglichkeit den Ansatz aus Kapitel 3 mit dem von Heckel und Wagner
vorgestellten Ansatz zur Erzeugung konsistenter Graphtransformationsregeln zu verbinden. Die
Idee besteht darin, den Ansatz von Heckel und Wagner an die Formalisierung aus Kapitel 3
anzupassen. Dann kann der Ansatz zum Nachweis von induktiven Invarianten dazu verwendet
werden, um die Korrektheit einer Menge von Graphtransformationsregeln zu ¨
uberpr¨
ufen. Wird
bei dieser ¨
Uberpr¨
ufung f¨
ur eine Regel ein Gegenbeispiel generiert, das zeigt, dass die Regel in-
korrekt ist, so kann der Ansatz von Heckel und Wagner dazu eingesetzt werden, um die Regel
automatisch zu korrigieren.
Eine Erweiterung des Ansatzes aus Kapitel 3 wie zuvor beschrieben, erm¨
oglicht auch sei-
ne Anwendung in anderen Kontexten. Beispielsweise ist es dann m¨
oglich, die von Tichy et
al. [TSG04, TGSP05, TG05] vorgestellten Regeln zur Selbstadaption und zur Selbstreparatur
zu verifizieren. Auf diese Weise k¨
onnte nicht nur die Sicherheit eines Systems erh¨
oht werden,
sondern auch seine Verl¨
asslichkeit (engl. reliability). Außerdem ist es dann m¨
oglich, die Konsis-
tenzbedingungen der von Gehrke in [Geh05] aufgestellten Regeln zur Modelltransformation zu
verifizieren.
1www.ilog.com
144 KAPITEL 7. ZUSAMMENFASSUNG UND AUSBLICK
Literaturverzeichnis
[ACD90] ALUR, R.; COURCOUBETIS, C. ; DILL, D.: Model-Checking for Real-Time Systems. In:
Proceedings of the 5th Annual IEEE Symposium on Logic in Computer Science. Philadelphia,
PA, 1990, S. 414–425
[AD90] ALUR, Rajeev; DILL, David L.: Automata for Modeling Real-Time Systems. In: Proceedings
of the 17th International Colloquium on Automata, Languages and Programming. New York,
NY, USA : Springer-Verlag New York, Inc., 1990, S. 322–335
[AD94] ALUR, Rajeev; DILL, David L.: A theory of timed automata. In: Theoretical Computer
Science 126 (1994), Nr. 2, S. 183–235
[BCK] BALDAN, Paolo; CORRADINI, Andrea ; K¨
ONIG, Barbara: Static Analysis of Distributed
Systems with Mobility Specified by Graph Grammars - A Case Study. In: Proceedings of the
6th International Conference on Integrated Design and Process Technology (IDPT 2002),
Pasadena, USA
[BCK01] BALDAN, Paolo; CORRADINI, Andrea ; K¨
ONIG, Barbara: A Static Analysis Technique for
Graph Transformation Systems. In: K.G.LARSEN (Hrsg.); M.NIELSEN (Hrsg.): Procee-
dings of the 12th International Conference on Concurrency Theory (CONCUR 2001), Aal-
borg, Denmark Bd. 2154, Springer-Verlag Heidelberg, 2001, S. 381–395
[BCK04] BALDAN, Paolo; CORRADINI, Andrea ; K¨
ONIG, Barbara: Verifying Finite-State Graph
Grammars: An Unfolding-Based Approach. In: GARDNER, Philippa (Hrsg.); YOSHIDA,
Nobuko (Hrsg.): Proceedings of the 15th International Conference on Concurrency Theo-
ry (CONCUR 2004), London, UK Bd. 3170, Springer-Verlag Heidelberg, 2004, S. 83–98
[Bec05] BECKER, Basil: Automatische ¨
Uberpr¨
ufung Induktiver Invarianten f¨
ur Graphtransformati-
onssysteme. Paderborn, Deutschland, Universit¨
at Paderborn, Studienarbeit, 2005
[BG03] BURMESTER, Sven; GIESE, Holger: The Fujaba Real-Time Statechart PlugIn. In: GIESE,
Holger (Hrsg.); Z¨
UNDORF, Albert (Hrsg.): Proceedings of the 1st International Fujaba Days
2003, Kassel, Deutschland Bd. tr-ri-04-247, Universit¨
at Paderborn, 2003, S. 1–8
[BGH+05] BURMESTER, Sven; GIESE, Holger; HIRSCH, Martin; SCHILLING, Daniela ; TICHY, Matt-
hias: The Fujaba Real-Time Tool Suite: Model-Driven Development of Safety-Critical, Real-
Time Systems. In: Proceedings of the 27th International Conference on Software Enginee-
ring (ICSE 2005), St. Louis, Missouri, USA, ACM Press, 2005, S. 670 – 671
145
146 LITERATURVERZEICHNIS
[BGHS04] BURMESTER, Sven; GIESE, Holger; HIRSCH, Martin ; SCHILLING, Daniela: Incremental
Design and Formal Verification with UML/RT in the FUJABA Real-Time Tool Suite. In:
Proceedings of the International Workshop on Specification and Validation of UML Models
for Real Time and Embedded Systems (SVERTS 2004), Satellite Event of the 7th International
Conference on the Unified Modeling Language (UML 2004), Lisabon, Portugal, 2004
[BGO04] BURMESTER, Sven; GIESE, Holger ; OBERSCHELP, Oliver: Hybrid UML Components for
the Design of Complex Self-optimizing Mechatronic Systems. In: ARAUJO, Helder (Hrsg.);
VIEIRA, Alves (Hrsg.); BRAZ, Jose (Hrsg.); ENCARNACAO, Bruno (Hrsg.) ; CARVALHO,
Marina (Hrsg.): Proceedings of 1st International Conference on Informatics in Control, Au-
tomation and Robotics (ICINCO 2004), Setubal, Portugal, INSTICC Press, 2004, S. 222–229
[BGS05a] BECKER, Basil; GIESE, Holger ; SCHILLING, Daniela: A Plugin for Checking Inductive
Invariants when Modeling with Class Diagrams and Story Patterns. In: Proceedings of the
3rd International Fujaba Days 2005, Paderborn, Deutschland Bd. tr-ri-05-259, Universit¨
at
Paderborn, 2005, S. 45 – 48
[BGS05b] BURMESTER, Sven; GIESE, Holger ; SCH ¨
AFER, Wilhelm: Model-Driven Architecture for
Hard Real-Time Systems: From Platform Independent Models to Code. In: Proceedings
of the European Conference on Model Driven Architecture - Foundations and Applications
(ECMDA-FA’05), N¨
urnberg, Deutschland, Springer Verlag, 2005 (Lecture Notes in Compu-
ter Science (LNCS)), S. 1–15
[BGT05] BURMESTER, Sven; GIESE, Holger ; TICHY, Matthias: Model-Driven Development of Re-
configurable Mechatronic Systems with Mechatronic UML. In: ASSMANN, Uwe (Hrsg.);
RENSINK, Arend (Hrsg.) ; AKSIT, Mehmet (Hrsg.): Model Driven Architecture: Foundati-
ons and Applications Bd. 3599, Springer-Verlag Heidelberg, 2005, S. 47 – 61
[BK02] BALDAN, Paolo; K¨
ONIG, Barbara: Approximating the Behaviour of Graph Transformati-
on Systems. In: CORRADINI, A. (Hrsg.); EHRIG, H. (Hrsg.); KREOWSKI, H.-J. (Hrsg.) ;
ROZENBERG, G. (Hrsg.): Proceedings of the 1st International Conference on Graph Trans-
formation (ICGT 2002), Barcelona, Spanien Bd. 2505, Springer-Verlag Heidelberg, 2002, S.
14–29
[BNL05] BEYER, Dirk; NOACK, Andreas ; LEWERENTZ, Claus: Efficient Rational Calculation for
Software Analysis. In: IEEE Transactions on Software Engineering 31 (2005), Nr. 2, S.
137–149
[BTG04] BURMESTER, Sven; TICHY, Matthias ; GIESE, Holger: Modeling Reconfigurable Mechatro-
nic Systems with Mechatronic UML. In: ASSMANN, U. (Hrsg.): Proceedings of Model Dri-
ven Architecture: Foundations and Applications (MDAFA 2004), Link¨
oping, Sweden, 2004,
S. 155 – 169
[Bur02] BURMESTER, Sven: Generierung von Java Real-Time Code f¨
ur zeitbehaftete UML Modelle,
Universit¨
at Paderborn, Paderborn, Deutschland, Diplomarbeit, 2002
[Bur05] BURMESTER, Sven: Model-Driven Engineering of Reconfigurable Mechatronic Systems (er-
scheint). Paderborn, Deutschland, Universit¨
at Paderborn, Dissertation, 2005
LITERATURVERZEICHNIS 147
[CGP02] CLARK, Edmund M.; GRUMBERG, Orna ; PELED, Doron A.: Model Checking. 4. MIT
Press, 2002
[Cha03] CHARPENTIER, Michel: Composing Invariants. In: ARAKI, Keijiro (Hrsg.); GNESI, Stefania
(Hrsg.) ; MANDRIOLI, Dino (Hrsg.): Proceedings of the 12th International Symposium of
Formal Methods Europe (FME 2003), Pisa, Italien Bd. 2805, Springer-Verlag Heidelberg,
2003, S. 401 – 421
[DFRS03] DOTTI, Fernando L.; FOSS, Luciana; RIBEIRO, Leila ; SANTOS, Osmar M.: Verification of
Distributed Object-Oriented Systems. In: NAJM, Elie (Hrsg.); NESTMANN, Uwe (Hrsg.) ;
STEVENS, Perdita (Hrsg.): Proceedings ofthe 6th Internation Conferenceon Formal Methods
for Open Object-Based Distributed Systems (FMOODS 2003), Paris, Frankreich Bd. 2884,
Springer-Verlag Heidelberg, 2003, S. 261 – 275
[FNT98] FISCHER, Thorsten; NIERE, J¨
org ; TORUNSKI, Lars: Konzeption und Realisierung einer
integrierten Entwicklungsumgebung f¨
ur UML, Java und Story-Driven-Modeling. Paderborn,
Deutschland, Univerisity of Paderborn, Diplomarbeit, 1998
[FNTZ98] FISCHER, Thorsten; NIERE, J¨
org; TORUNSKI, Lars ; Z¨
UNDORF, Albert: Story Diagrams: A
new Graph Rewrite Language based on the Unified Modeling Language. In: ENGELS, Gregor
(Hrsg.); ROZENBERG, Grzegorz (Hrsg.): Proceedings of the 6th International Workshop on
Theory and Application of Graph Transformation (TAGT 1998), Paderborn, Deutschland Bd.
1764, Springer Verlag, 1998, S. 296–309
[GB03] GIESE, Holger; BURMESTER, Sven: Real-Time Statechart Semantics / Universit¨
at Pader-
born. Paderborn, Deutschland, 2003 (tr-ri-03-239). – Forschungsbericht
[GBK+03] GIESE, Holger; BURMESTER, Sven; KLEIN, Florian; SCHILLING, Daniela ; TICHY, Matt-
hias: Multi-Agent System Design for Safety-Critical Self-Optimizing Mechatronic Systems
with UML. In: HENDERSON-SELLERS, B. (Hrsg.); DEBENHAM, J. (Hrsg.): 2nd Internatio-
nal Workshop on Agent-Oriented Methodologies (OOPSLA 2003), Anaheim, USA, Center for
Object Technology Applications and Research (COTAR), University of Technology, Sydney,
Australia, 2003, S. 21–32
[GBSO04] GIESE, Holger; BURMESTER, Sven; SCH ¨
AFER, Wilhelm ; OBERSCHELP, Oliver: Mo-
dular Design and Verification of Component-Based Mechatronic Systems with Online-
Reconfiguration. In: Proceedings of 12th ACM SIGSOFT Foundations of Software Engi-
neering 2004 (FSE 2004), Newport Beach, USA, ACM Press, 2004, S. 179–188
[Ge05] GAUSEMEIER, J¨
urgen; ET AL.: Sonderforschungsbereich 614 - Selbstoptimierende Systeme
des Maschinenbaus, 2. F¨
orderperiode, Finanzierungsantrag. Bd. 1. Universit¨
at Paderborn,
2005
[Geh05] GEHRKE, Matthias: Entwurf mechatronischer Systeme auf Basis von Funktionshierarchien
und Systemstrukturen (erscheint), Universit¨
at Paderborn, Dissertation, 2005
[Gei02] GEIGER, Leif: Design Level Debugging mit Fujaba, Technische Universit¨
at Braunschweig,
Studienarbeit, 2002
148 LITERATURVERZEICHNIS
[Gie03] GIESE, Holger: A Formal Calculus for the Compositional Pattern-Based Design of Correct
Real-Time Systems / Universit¨
at Paderborn. Paderborn, Deutschland, 2003 (tr-ri-03-240). –
Forschungsbericht
[GS04] GIESE, Holger; SCHILLING, Daniela: Towards the Automatic Verification of Inductive Inva-
riants for Invinite State UML Models / Universit¨
at Paderborn. Paderborn, Deutschland, 2004
(tr-ri-04-252). – Forschungsbericht
[GSK+06] GIESE, Holger; SCHILLING, Daniela; KLEIN, Florian; BECKER, Basil ; BEYER, Dirk: Sym-
bolic Invariant Verification for Systems with Dynamic Structural Adaptation. In: Proceedings
of the 28th International Conference on Software Engineering (ICSE 2006), Shanghai, China
(angenommen), ACM Press, 2006
[GST+03] GIESE,Holger; SCHILLING, Daniela; TICHY, Matthias; BURMESTER, Sven; SCH ¨
AFER, Wil-
helm ; FLAKE, Stephan: Towards the Compositional Verification of Real-Time UML Designs
/ Universit¨
at Paderborn. Paderborn, Deutschland, 2003 (tr-ri-03-241). – Forschungsbericht.
– 1–47 S
[GTB+03] GIESE, Holger; TICHY, Matthias; BURMESTER, Sven; SCH ¨
AFER, Wilhelm ; FLAKE, Ste-
phan: Towards the Compositional Verification of Real-Time UML Designs. In: Proceedings
of the European Software Engineering Conference (ESEC), Helsinki, Finland, ACM Press,
2003, S. 38–47
[HE00] HECKEL, Reiko; ENGELS, Gregor: Graph Transformation and Visual Modeling Languages.
In: Bulletin of the European Association for Theoretical Computer Science (EATACS) (2000),
Nr. 71
[Hec98] HECKEL, Reiko: Compositional Verification of Reactive Systems Specified by Graph Trans-
formation. In: ASTESIANO, Egidio (Hrsg.): Proceedings of the 1st International Conference
on Fundamental Approaches to Software Engineering (FASE 1998), Held as Part of the Eu-
ropean Joint Conferences on the Theory and Practice of Software (ETAPS 1998), Lisabon,
Protugal Bd. 1382, Springer-Verlag Heidelberg, 1998, S. 138–153
[HEWC97] HECKEL, Reiko; EHRIG, Hartmut; WOLTER, Uwe ; CORRADINI, Andrea: Integrating the
Specification Techniques of Graph Transformation and Temporal Logic. In: Proceedings
of the 22nd International Symposium on Mathematical Foundations of Computer Science
(MFCS 1997), Bratislava, Slovakia Bd. 1295, Springer-Verlag Heidelberg, 1997, S. 219 –
228
[HG03] HIRSCH, Martin; GIESE, Holger: Towards the Incremental Model Checking of Complex
RealTime UML Models. In: GIESE, Holger (Hrsg.); Z¨
UNDORF, Albert (Hrsg.): Proceedings
of the 1st International Fujaba Days 2003, 13.-14.October, Kassel, Deutschland Bd. tr-ri-04-
247, Universit¨
at Paderborn, 2003
[HHT96] HABEL, Annegret; HECKEL, Reiko ; TAENTZER, Gabriele: Graph Grammars with Negative
Application Conditions. In: Fundamenta Informatikae 26 (1996), Nr. 3 - 4, S. 287 – 313
[Hir04] HIRSCH, Martin: Effizientes Model Checking von UML-RT Modellen und Realtime State-
charts mit UPPAAL, Universit¨
at Paderborn, Diplomarbeit, 2004
LITERATURVERZEICHNIS 149
[HLM05] HECKEL, Reiko; LAJIOS, Georgios ; MENGE, Sebastian: Modulare Analyse Stochastischer
Graphtransformationssysteme. In: Software Engineering Bd. 64, Gesellschaft f¨
ur Informatik,
2005, S. 141–152
[HOG04] HESTERMEYER, Thorsten; OBERSCHELP, Oliver ; GIESE, Holger: Structured Information
Processing For Self-optimizing Mechatronic Systems. In: ARAUJO, Helder (Hrsg.); VIEI-
RA, Alves (Hrsg.); BRAZ, Jose (Hrsg.); ENCARNACAO, Bruno (Hrsg.) ; CAVALHO, Marina
(Hrsg.): Proceeings of the 1st International Conference on Informatics in Control, Automati-
on and Robotics (ICINCO 2004), Setubal, Portugal, INSTICC Pess, 2004, S. 230–237
[Hol03] HOLZMAN, Gerard J.: The SPIN Model Checker: Primer and Reference Manual. Addision
Wesley Professional, 2003
[HW95] HECKEL, Reiko; WAGNER, Annika: Ensuring consistency of conditional graph rewriting - a
constructive approach. In: CORRADINI, Andrea (Hrsg.); MONTANARI, Ugo (Hrsg.): Procee-
dings of Joint Computergraph/Semagraph Workshop on Graph Rewriting and Computation
(SEGRAGRA 1995), Volterra, Italien Bd. 2, Elsevier, 1995
[KG04] KLEIN, Florian; GIESE, Holger: Advanced separation of concerns for mechatronic multi-
agent systems through dynamic communities. In: AL., Ricardo C. (Hrsg.): Proceedings of
the 3rd Workshop on Software Engineering for Large-Scale Multi-Agent Systems (SELMAS
2004) held in Conjunction with the International Conference on Software Engineering (ICSE
2004), Edinburgh, Schottland, IEE, 2004, S. 112–119
[KG05] KLEIN, Florian; GIESE, Holger: Separation of concerns for mechatronic multi-agent sys-
tems through dynamic communities. In: CHOREN, Ricardo (Hrsg.); GARCIA, Alessandro
(Hrsg.); LUCENA, Carlos (Hrsg.) ; ROMANOVSKY, Alexander (Hrsg.): Software Engineering
for Multi-Agent Systems III: Research Issues and Practical Applications Bd. 3390. Springer
Verlag, 2005, S. 272–289
[Kin95] KINDLER, Ekkart: Invariants, composition, and substitution. In: Acta Informatika 32 (1995),
S. 299 – 312
[KMPP02] KOCH, Manuel; MANCINI, Luigi V. ; PARISI-PRESICCE, Francesco: Decidability of Safety
in Graph-Based Models for Access Control. In: GOLLMANN, D. (Hrsg.); KARJOTH, G.
(Hrsg.) ; WAIDNER, M. (Hrsg.): Proceedings of the 7th European Symposium on Research
in Computer Security (ESORICS 2002), 14.-16.Oktober, Z¨
urich, Schweiz Bd. 2502, Springer-
Verlag Heidelberg, 2002, S. 229 – 243
[KPP03] KOCH, Manuel; PARISI-PRESICCE, Francesco: UML Specificationd Access Control Policies
and their Formal Verification / George Mason University. Fairfax, USA, 2003 (ISE-TR-03-
10). – Forschungsbericht
[LPY97] LARSEN, K.; PETTERSSON, P. ; YI, W.: UPPAAL in a Nutshell. In: Springer International
Journal of Software Tools for Technology 1 (1997), Nr. 1
[Mat01] MATZ, Michael: Konzeption und Implementierung eines Verfahren zum Nachweis der Kon-
sistenz in einer attributierten Graphgrammatik, Technische Universit¨
at Berlin, Diplomarbeit,
2001
150 LITERATURVERZEICHNIS
[NNWZ00] NICKEL, Ulrich A.; NIERE, J¨
org; WADSACK, J¨
org P. ; Z¨
UNDORF, Albert: Roundtrip Engi-
neering with FUJABA. In: EBERT, J. (Hrsg.); KULLBACH, B. (Hrsg.) ; LEHNER, F. (Hrsg.):
Proceedings of the 2nd Workshop on Software-Reengineering (WSR00), Bad Honnef, Ger-
many, Fachberichte Informatik, Universit¨
at Koblenz-Landau, 2000
[NNZ00] NICKEL, Ulrich A.; NIERE, J¨
org ; Z¨
UNDORF, Albert: Tool demonstration: The FUJABA
environment. In: Proceedings of the 22nd International Conference on Software Engineering
(ICSE00), Limerick, Ireland, ACM Press, 2000, S. 742–745
[OHG04] OBERSCHELP, Oliver; HESTERMEYER, Thorsten ; GIESE, Holger: Strukturierte Informati-
onsverarbeitung f¨
ur selbstoptimierende mechatronische Systeme. In: GAUSEMEIER, J¨
urgen
(Hrsg.); WALLASCHECK, J¨
urgen (Hrsg.): Proceedings of the 2nd Paderborner Workshop In-
telligente Mechatronische Systeme, Paderborn, Deutschland Bd. 145, 2004, S. 43–56
[PE02] PADBERG, Julia; ENDERS, Bettina E.: Rule Invariants in Graph Transformation Systems
for Analyzing Safety-Critical Systems. In: CORRADINI, Andrea (Hrsg.); EHRIG, Hartmut
(Hrsg.); KREOWSKI, Hans-J¨
org (Hrsg.) ; ROZENBERG, Grzegorz (Hrsg.): Proceedings of
the First International Conference on Graph Transformation (ICGT 2002), 7.-12.October,
Barcelona, Spanien Bd. 2505, Springer-Verlag Heidelberg, 2002, S. 334 – 350
[Ren03] RENSINK, Arend: Towerds [sic] Model Checking Graph Grammars. In: LEUSCHEL, M.
(Hrsg.); GRUNER, S. (Hrsg.) ; PRESTI, S. L. (Hrsg.): Workshop on Automated Verification
of Critical Systems (AVoCS 2003), Southampton, GB Bd. DSSE–TR–2003–2, University of
Southampton, 2003, S. 150–160
[Ren04] RENSINK, Arend: The GROOVE Simulator: A Tool for State Space Generation. In: PFALZ,
John(Hrsg.); NAGL,Manfred(Hrsg.); B¨
OHLEN, Boris (Hrsg.): Proceedings of the 2nd Work-
shop on Applications of Graph Transformations with Industrial Relevance (AGTIVE 2004),
Charlottesville, USA Bd. 3062, Springer-Verlag Heidelberg, 2004, S. 479–485
[Roz97] ROZENBERG, Grzegorz: Handbook of Graph Grammars and Computing by Graph Trans-
formation. Bd. 1. Foundations. World Science Publishing Co. Pte. Ltd., 1997
[RSV04] RENSINK, Arend; SCHMIDT,´
Akos ; VARR´
O, D´
aniel: Model Checking Graph Transforma-
tions: A Comparison of Two Approaches. In: EHRIG, Hartmut (Hrsg.); ENGELS, Gregor
(Hrsg.); PARISI-PRESICCE, Francesco (Hrsg.) ; ROZENBERG, Grzegorz (Hrsg.): Procee-
dings of the 2nd International Conference on Graph Transformations (ICGT 2004), Rom,
Italien Bd. 3256, Springer-Verlag Heidelberg, 2004, S. 226 – 241
[Ruf01] RUF, J¨
urgen: RAVEN: Real-Time Analyzing and Verification Environment. In: Journal on
Universal Computer Science (J.UCS), Springer 7 (2001), Nr. 1, S. 89 – 104
[Sei05] SEIBEL, Andreas: Story Diagramme f¨
ur eingebettete Echtzeitsysteme, Universit¨
at Paderborn,
Studienarbeit, 2005
[Ste05] STECKER, Alexander: Model Checking von Real-Time Statecharts mit RAVEN. Paderborn,
Deutschland, Universit¨
at Paderborn, Studienarbeit, 2005
[Sto96] STOREY, Neil R.: Safety Critical Computer Systems. Boston, MA, USA : Addison-Wesley
Longman Publishing Co., Inc., 1996
LITERATURVERZEICHNIS 151
[SV03] SCHMIDT,´
Akos; VARR´
O, D´
aniel: CheckVML: A Tool for Model Checking Visual Modeling
Languages. In: STEVENS, Perdita (Hrsg.); WHITTLE, Jon (Hrsg.) ; BOOCH, Grady (Hrsg.):
Proceedings of the 6th International Conference on the Unified Modeling Language (UML
2003), 20.-24.Oktober, San Francisco, USA Bd. 2863, Springer-Verlag Heidelberg, 2003, S.
92 – 95
[Szy02] SZYPERSKI, Clemens: Component Software - Beyond Object-Oriented Programming. 2.
Addison-Wesley, 2002
[TG05] TICHY, Matthias; GIESE, Holger: Extending Fault Tolerance Patterns by Visual Degradation
Rules. In: Proceedings of the Workshop on Visual Modeling for Software Intensive Systems
(VMSIS 2005) at the the IEEE Symposium on Visual Languages and Human-Centric Com-
puting (VL/HCC 2005), Dallas, USA, 2005, S. 67 – 74
[TGSP05] TICHY, Matthias; GIESE, Holger; SCHILLING, Daniela ; PAULS, Wladimir: Computing Op-
timal Self-Repair Actions: Damage Minimization versus Repair Time. In: LEMOS, Rog´
erio
de (Hrsg.); ROMANOVSKY, Alexander (Hrsg.): Proceedings of the Workshop on Architec-
ting Dependable Systems (WADS 2005), held at the International Conference on Software
Engineering (ICSE 2005),St. Louis, USA, ACM Press, 2005
[TSG04] TICHY, Matthias; SCHILLING, Daniela ; GIESE, Holger: Design of Self-Managing Depen-
dable Systems with UML and Fault Tolerance Patterns. In: Proceedings of the Workshop
on Self-Managed Systems (WOSS 2004) held at the ACM SIGSOFT Foundations in Software
Engineering (FSE 2004), Newport Beach, USA, 2004
[UML05] UML 2.0 Superstructure Specification / Object Management Group. 2005. – Forschungsbe-
richt
[Var04] VARR´
O, D´
aniel: Automated Formal Verification of Visual Modeling Languages by Model
Checking. In: Software and System Modeling 3 (2004), Nr. 2, S. 85–113
[Wen03] WENDEHALS, Lothar: 10 Steps to Build a Fujaba Plugin. 2003. – http://www.se.eecs.uni-
kassel.de/˜fujabawiki/index.php/HowTos
[Z¨
un01] Z¨
UNDORF, Albert: Rigorous Object Oriented Software Development with Fujaba. Pader-
born, Deutschland, Universit¨
at Paderborn, Habilitation, 2001
152 LITERATURVERZEICHNIS
Anhang A
Das Shuttle-Beispiel
In diesem Kapitel werden alle Regeln (Verhaltens- und Instanzierungsregeln) des Shuttle-
Beispiels vorgestellt. Die Regeln wurden in Kapitel 2 in den drei Kulturen Movement-, Control-
ledMovement- und CoordinatedMovement-Kultur definiert. F¨
ur die Regeln der Movement-Kultur
sowie der CoordinatedMovement-Kultur konnte gezeigt werden, dass sie bez¨
uglich der Sicher-
heitseigenschaften korrekt sind. Die Regeln werden in Abschnitt A.1 erl¨
autert. Zus¨
atzlich wird
in Abschnitt A.1.3 f¨
ur jede Regel deren Priorit¨
at und die im Evaluierunsabschnitt (Abschnitt 5.4)
eingef¨
uhrte Gr¨
oße angegeben.
Die Sicherheitseigeschaften, die in jeder der drei Kulturen gelten m¨
ussen, werden ebenfalls
in diesem Kapitel (in Abschnitt A.2) erl¨
autert. F¨
ur die Sicherheitseigenschaften wird auch die
jeweilige Gr¨
oße angegeben.
Der Ansatz aus Kapitel 3 und die entsprechende Implementierung in der Fujaba Real-Time
Tool Suite (Abschnitt 5.3) ber¨
ucksichtigen zurzeit nicht die im Klassendiagramm spezifizierten
Kardinalit¨
aten. Deshalb werden in Abschnitt A.2.3 verbotene Graphmuster beschrieben, die bei
der Verifikation dazu verwendet wurden, die Kardinalit¨
aten zu modellieren. Zu jedem dieser
Graphmuster wird auch seine Gr¨
oße genannt.
A.1 Regeln
In diesem Abschnitt werden alle Regeln des Shuttle-Beispiels in Form von Story Pattern dar-
gestellt und erl¨
autert. Der Abschnitt ist in drei Unterabschnitte gegliedert. Der erste Abschnitt
A.1.1 beschreibt die Regeln der Movment-Kultur. Diese enth¨
alt die Regeln member,noMember,
moveNext,approachSwitch sowie moveSwitch. In Abschnitt A.1.2 werden die Regeln der Con-
trolledMovement-Kultur vorgestellt. Diese Kultur enth¨
alt alle Regeln der ihr ¨
ubergeordneten Mo-
vement-Kultur sowie die Regeln createPublication und deletePublication. Im dritten Abschnitt
(Abschnitt A.1.3) werden die Regeln der CoordinatedMovement-Kultur beschrieben. Neben den
Regeln der ¨
ubergeordneten Movement- und ControlledMovment-Kulturen enth¨
alt die Kultur die
Regeln createDC,moveDC und deleteDC.
153
154 ANHANG A. DAS SHUTTLE-BEISPIEL
A.1.1 Die Regeln der Movement-Kultur
In diesem Abschnitt werden die beiden Instanzierungsregeln member und noMember sowie die
drei Verhaltensregeln moveNext,approachSwitch und moveSwitch der Movement-Kultur als Sto-
ry Pattern dargestellt und erl¨
autert. Die Verhaltensregeln der Movement-Kultur beschreiben die
Grundfunktionalit¨
at eines Shuttles, die Vorw¨
artsbewegung sowohl auf einer geraden Strecke als
auch beim Ann¨
ahern und Passieren einer Weiche.
M¨
ochte ein Shuttle einen Track befahren, der zu einer anderen ControlledArea geh¨
ort als
der Track, auf dem es sich zur Zeit befindet, so muss es zun¨
achst in die Community der neuen
ControlledArea aufgenommen werden. Dazu wird zwischen dem Shuttle und der ControlledA-
rea ein neuer contains-Link erzeugt, falls es diesen noch nicht gibt. Die Zugeh¨
origkeit eines
Tracks zu einer ControlledArea wird nicht direkt durch Links definiert. Stattdessen enth¨
alt jede
ControlledArea eine BaseStation. Alle Tracks, die von der BaseStation ¨
uberwacht werden, sind
automatisch Teil der ControlledArea. Deshalb ist in der Regel member in Abbildung A.1, die die
Aufnahme eines Shuttles in einer ControlledArea beschreibt, auch das entsprechende BaseStati-
on-Objekt angegeben.
Abbildung A.1: Die Regel member
W¨
ahrend die member-Regel die Aufnahme eines Shuttles in eine ControlledArea beschreibt,
beschreibt die Regel noMember, die in Abbildung A.13 als Story Pattern gegeben ist, das ein
Shuttle nicht mehr zu einer ControlledArea geh¨
ort, sobald es ein Track bef¨
ahrt, dass nicht von
der BaseStation der ControlledArea ¨
uberwacht wird.
Die Regel moveNext (siehe Abbildung A.3) beschreibt die Fahrt eines Shuttles auf gerader
Strecke, d.h. wenn keine Weiche in der N¨
ahe ist. Dabei muss die Regel zusammen mit den beiden
anderen Regeln die Sicherheitseigenschaften der Kultur, in diesem Fall collision und notMember
(siehe Abschnitt A.2), einhalten. Das bedeutet, die Anwendung der Regel darf nicht dazu f¨
uhren,
dass sich zwei Shuttles auf einem Track befinden. Da die Regel nicht f¨
ur die Weichenfahrt eines
Shuttles anwendbar sein soll, darf der Track auf den das Shuttle rs1 als n¨
achstes fahren m¨
ochte
(dargestellt durch den next-Link) keine Weiche sein, d.h. sie darf nur rt1 :Track als Vorg¨
anger
haben. Dies wird durch das negative Objekt rt5 vom Typ Track dargestellt. Um eine Kollision
von zwei Shuttles zu vermeiden, muss zudem gelten, dass sich auf den beiden Tracksrt2 und
rt3, auf die das Shuttle rs1 als n¨
achstes und ¨
ubern¨
achstes fahren m¨
ochte, kein weiteres Shuttle
befinden; Dargestellt durch die beiden negativen Shuttle-Objekte rs2 und rs3.
A.1. REGELN 155
Abbildung A.2: Die Regel noMember
Sind diese Anforderungen erf¨
ullt, so kann die Regel angewendet werden und rs1weiter-
fahren. In diesem Fall wird der locatedOn-Link gel¨
oscht und ein neuer zwischen dem Shuttle
und rt2 erzeugt. Außerdem muss die Angabe, auf welchen Track das Shuttle als n¨
achstes und
¨
ubern¨
achstes fahren m¨
ochte, aktualisiert werden. Dazu wird der next-Link zwischen dem Shuttle
und rt2 gel¨
oscht und ein neuer zum Track rt4 erzeugt.
Abbildung A.3: Die Regel moveNext
Damit ein Shuttle sicher eine Weiche passieren kann ohne mit einem anderen Shuttle zu kol-
lidieren, werden zwei weitere Regeln ben¨
otigt. Die erste, approachSwitch aus Abbildung A.4,
beschreibt, wie sich ein Shuttle einer Weiche n¨
ahert. Die Weiche wird durch den Track rt3 dar-
gestellt, der mit rt2 und rt5 zwei Vorg¨
anger hat.
Durch seine beiden next-Links gibt das Shuttle zu verstehen, dass es diese Weiche passie-
ren m¨
ochte. Damit dies jedoch sicher geschehen kann, darf sich auf dem n¨
achsten Track rt2,
aber auch auf der Weiche selber, kein weiteres Shuttle befinden. Bei einer Weiche k¨
onnen auch
Shuttles vom parallelen Track kommen. F¨
ur eine sichere Weichendurchfahrt darf sich auf diesem
parallelen Track (rt5) kein anderes Shuttle befinden.
Ist die Anwendungsbedingung der Regel erf¨
ullt, so wird das Shuttle, wie in der moveNext
Regel, auf den n¨
achsten Track gesetzt und seine next-Links aktualisiert.
156 ANHANG A. DAS SHUTTLE-BEISPIEL
Abbildung A.4: Die Regel approachSwitch
Wurde die Regel approachSwitch angewendet, so erreicht das Shuttle den Track, der direkt
vor der Weiche ist. Um die Weiche passieren zu k¨
onnen, wird die Regel moveSwitch (siehe
Abbildung A.5) angewendet. In dieser Regel stellt das Track-Objekt rt2 die Weiche dar. Das
Shuttle darf auf die Weiche fahren, wenn sich weder auf der Weiche noch auf dem Track rt1,
der parall zu dem ist, auf dem sich das Shuttle befindet, ein anderes Shuttle f¨
ahrt. Außerdem
darf sich auch kein anderes Shuttle auf dem Track befinden, auf den das Shuttle als ¨
ubern¨
achstes
fahren m¨
ochte (rt4).
Kann die Regel angewendet werden, so f¨
ahrt das Shuttle auf die Weiche und aktualisiert
dabei auch seine next-Links.
Abbildung A.5: Die Regel moveSwitch
A.1.2 Die Regeln der ControlledMovement-Kultur
Von der ControlledMovement-Kultur werden alle Verhaltensregeln und Sicherheitseigenschaften
¨
ubernommen, die in der ¨
ubergeordneten Movement-Kultur definiert sind. Zu diesen f¨
unf Regeln
A.1. REGELN 157
f¨
ugt die ControlledMovement-Kultur zwei Instanzierungsregeln hinzu, die Regel createPublica-
tion sowie die Regel deletePublication. Diese beiden Regeln sind daf¨
ur verantwortlich eine In-
stanz einen Publication-Koordinationsmusters zwischen einem Shuttle und einer BaseStation zu
erzeugen bzw. zu l¨
oschen. Die Instanzierung bzw. das L¨
oschen einer solchen Instanz entspricht
einer Anmeldung bzw. Abmeldung eines Shuttles bei der entsprechenden BaseStation (siehe
dazu auch Abschnitt 2.3.2).
Bevor ein Shuttle in eine neue ControlledArea einfahren darf, muss es sich bei deren Ba-
seStation anmelden. Ist das Shuttle angemeldet, so sendet die BaseStation Informationen ¨
uber
alle anderen bei ihr gemeldeten Shuttles. Auf diese Weise erfahren die Shuttle, welche anderen
Shuttles sich in ihrer N¨
ahe befinden und k¨
onnen entsprechend f¨
ur eine sichere und kollisionsfreie
Fahrt sorgen. Das Anmelden bei einer BaseStation erfolgt mittels der createPublication-Regel,
die in Abbildung A.6 dargestellt ist.
Wenn ein Shuttle als n¨
achstes auf einen Track fahren m¨
ochte, der von einer BaseStation
¨
uberwacht wird, mit dem das Shuttle noch kein Publication-Koordinationsmuster ausf¨
uhrt, so ist
das Shuttle noch nicht bei der BaseStation angemeldet. Dargestellt wird das durch ein negatives
Publication-Objekt, mit Links zum Shuttle und zur BaseStation. In diesem Fall wird zwischen
dem Shuttle und der BaseStation ein neues Publication-Objekt erzeugt und das Shuttle somit bei
der BaseStation angemeldet.
Abbildung A.6: Die Regel createPublication
Verl¨
asst das Shuttle eine ControlledArea, so kann es sich bei der entsprechenden BaseSta-
tion wieder abmelden. Diese Abmeldung erfolgt mit der in Abbildung A.7 dargestellten Regel
deletePublication.
Von einer BaseStation kann sich ein Shuttle abmelden, wenn diese weder den Track ¨
uber-
wacht, auf dem sich das Shuttle zur Zeit befindet, noch einen Track, auf den das Shuttle als
n¨
achstes oder ¨
ubern¨
achstes fahren m¨
ochte. Dargestellt wird dies durch die negativen monitors-
Links, die die BaseStation zu den Tracks hat, zu denen das Shuttle einen locatedOn-Link oder
einen next-Link besitzt.
Wird die Anwendungsbedingung der Regel erf¨
ull, so wird die entsprechende Instanz des
Publication-Koordinationsmusters gel¨
oscht.
158 ANHANG A. DAS SHUTTLE-BEISPIEL
Abbildung A.7: Die Regel deletePublication
A.1.3 Die Regeln der CoordinatedMovement-Kultur
Die CoordinatedMovement-Kultur ¨
ubernimmt zum einen die f¨
unf Regeln der Movement-Kultur
und zum anderen die beiden Regeln der ControlledMovement-Kultur. Zu diesen sieben Regeln
f¨
ugt sie eine weitere Verhaltensregeln und drei weitere Instanzierungregeln hinzu.
In der CoordinatedMovement-Kultur wird das DistanceCoordiantion-Koordinationsmuster
eingef¨
uhrt, damit zwei Shuttles einen Konvoi bilden k¨
onnen. Die Konvoibildung erfolgt indem
der Abstand zwischen zwei Shuttles reduziert wird. Die Minimierung des Abstandes der beiden
Shuttles wird dadurch modelliert, dass die beiden Shuttles nun auf benachbarten Tracks fahren
d¨
urfen.
Die Instanzierung des DistanceCoordination-Musters zwischen zwei Shuttles erfolgt durch
die in Abbildung A.8 gezeigt createDC-Regel.
Diese Regel ist anwendbar, wenn zwei Shuttles hintereinanderherfahren und zwischen den
Tracks, auf denen sich die beiden Shuttle befinden, nur ein weiterer Track ist. Die Regel darf nicht
angewendet werden, wenn das vordere Shuttle das Koordinationsmuster schon ausf¨
uhrt und da-
bei die frontRole ¨
ubernommen hat oder das hintere Shuttle das Muster ausf¨
uhrt und dabei bereits
die rearRole ¨
ubernommen hat. In diesem Fall existiert entweder bereits ein DistanceCoordianti-
on-Muster zwischen den beiden Shuttles oder zwischen den beiden Shuttles befindet sich noch
ein drittes Shuttle.
Kann die Regel angewendet werden, so wird eine Instanz des DistanceCoordination-Musters
erzeugt, zu dem das hintere Shuttle einen rear-Link besitzt und das vordere einen front-Link.
Die Regel createDC erzeugt eine Instanz des DistanceCoordination-Musters, wenn sich die
Shuttles auf einer normalen Strecke befinden. Um auch die rechtzeitige Instanzierung des Mus-
ters an einer Weiche garantieren zu k¨
onnen, wird eine weitere Regel, die Regel createDCSwitch,
die in Abbildung A.9 dargestellt ist, ben¨
otigt.
In dieser Regel stellt der Track rt3 die Weiche dar. Das Shuttle rs2 befindet sich n¨
aher an
der Weiche und hat deshalb das Vorfahrtsrecht vor dem Shuttle rs1. Das bedeutet, dass rs2 im
DistanceCoordination-Muster die Rolle frontRole ¨
ubernimmt, w¨
ahrend rs1 die rearRole ¨
uber-
nimmt. Das entsprechende Muster wird jedoch nur instanziert, wenn rs2noch in keiner Instanz
des DistanceCoordination-Musters als front agiert und rs1 in noch keiner Instanz von Distance-
Coordination als rear. Gilt diese Bedingung nicht, so bedeutet dies entweder, dass bereits eine
A.1. REGELN 159
Abbildung A.8: Die Regel createDC
Instanz des Musters zwischen den beiden Shuttles existiert. Es kann aber auch sein, dass rs1 be-
reits im Konvoi f¨
ahrt und ein anderes Shuttle vor sich hat, in diesem Fall muss sich das vordere
Shuttle mit rs2 koordinieren. Eine dritte M¨
oglichkeit besteht darin, dass rs2 schon in einem Kon-
voi f¨
ahrt und ihm in diesem Konvoi ein anderes Shuttle folgt. In diesem Fall muss rs1 solange
auf rt1 warten, bis sich das letzte Shuttle des Konvois auf dem Track rt4 befindet. Dann kann es
mit diesem Shuttle das Muster ausf¨
uhren und seine Fahrt fortsetzen.
Ist die Anwendungsbedingung der Regel erf¨
ullt, so wird eine Instanz des DistanceCoordi-
nation-Musters erzeugt. Das Shuttle rs1 bekommt dann einen rear-Link zu dieser Musterinstanz
und rs2 einen front-Link.
Abbildung A.9: Die Regel createDCSwitch
Nachdem mittels createDC oder createDCSwitch eine Instanz des DistanceCoordination-
Musters erzeugt wurde, k¨
onnen die beiden Shuttles einen Konvoi bilden. Dazu wird die Regel
moveDC (siehe Abbildung A.10) angewendet. Die Bildung des Konvois erfolgt, indem der Ab-
stand zwischen den beiden Shuttles verringert wird, sodass die beiden Shuttles sich auf direkt
aufeinander folgenden Tracks befinden. Ist zwischen den beiden Shuttles ein Track frei, so wird
das hintere der beiden Shuttles durch moveDCauf diesen Track gesetzt.
160 ANHANG A. DAS SHUTTLE-BEISPIEL
Abbildung A.10: Die Regel moveDC
Trennen sich die Wege der beiden Shuttles oder ist das vordere Shuttle schneller als das
hintere, so wird der Konvoi aufgel¨
ost. In diesem Fall muss auch die Instanz des DistanceCoordi-
nation-Musters gel¨
oscht werden. Dies ist deshalb erforderlich, da ein Shuttle h¨
ochstens ¨
uber zwei
Instanzen des DistanceCoordination-Musters mit anderen Shuttles kommunizieren kann; Einmal
¨
ubernimmt es dabei die rearRole und einmal die frontRole. W¨
urde eine nicht mehr ben¨
otigte
Musterinstanz nicht gel¨
oscht, so w¨
urde dies dem Shuttle die M¨
oglichkeit nehmen, einen Konvoi
mit einem anderen Shuttle zu bilden.
Die Regel deleteDC in Abbildung A.11 ist f¨
ur das L¨
oschen einer Instanz des DistanceCoor-
dination-Musters zust¨
andig. Die Regel l¨
oscht eine solche Instanz, wenn sich das vordere Shuttle
nicht mehr auf einem Track befindet, auf den das hintere Shuttle als n¨
achstes oder ¨
ubern¨
achstes
fahren m¨
ochte. Dies wird dargestellt durch die beiden negativen locatedOn-Links des vorderen
Shuttles.
Abbildung A.11: Die Regel deleteDC
Priorit¨
aten und Gr¨
oßen der Regeln
Nachdem in den vorangegangenen Abschnitten alle Regeln des Shuttle-Beispiels erl¨
autert wur-
den, werden in diesem Abschnitt ihre Priorit¨
aten aufgelistet. Zudem wird f¨
ur jede Regel deren
Gr¨
oße angegeben. Dabei entspricht die Gr¨
oße einer Regel der Anzahl Knoten (Objekte in Story
A.2. VERBOTENE GRAPHMUSTER 161
Patterns) und Kanten (Links in Story Patterns), die bei der Regelanwendung nicht gel¨
oscht wer-
den (siehe dazu auch Abschnitt 5.4) bzw. negativ sind. Die Priorit¨
aten und Gr¨
oßen der Regeln
werden in Tabelle A.1 aufgef¨
uhrt.
Regel Priorit¨
at Gr¨
oße
Objekte Links
member 10 6 9
noMember 11 6 9
moveNext 0 8 9
approachSwitch 1 10 11
moveSwitch 2 9 10
createPublication 8 7 10
deletePublication 9 5 8
createDC 5 8 9
moveDC 3 8 10
deleteDC 7 8 10
Tabelle A.1: Charakteristiken der Regeln im Shuttle-System
A.2 Verbotene Graphmuster
Im voran gegangenen Abschnitt wurden die Verhaltens- und Instazierungsregeln des Shutt-
le-Beispiels erl¨
autert. Im folgenden Abschnitt A.2.1 sollen nun die Sicherheitseigenschaften
erl¨
autert werden, die diese Regeln einhalten m¨
ussen. Diese Sicherheitseigenschaften werden
durch verbotenen Graphmuster bzw. verbotene Story Patterns modelliert. Neben den f¨
unf Si-
cherheitseigenschaften werden in Abschnitt A.2.3 weitere acht verbotene Story Patterns gezeigt.
Diese werden ben¨
otigt, da der Ansatz aus Kapitel 3 und dessen Umsetzung aus Abschnitt 5.3 die
im Klassendiagramm gegebenen Kardinalit¨
aten nicht ber¨
ucksichtigt.
A.2.1 Sicherheitseigenschaften
In den drei Kulturen wurden insgesamt f¨
unf Sicherheitseigenschaften spezifiziert. Davon stellt
das verbotene Graphmuster collision der Movement-Kultur einen Unfall dar. Die ¨
ubrigen vier
verbotenen Graphmuster stellen kritische Situationen dar.
Die verbotenen Graphmuster der Movement-Kultur
Die Movement-Kultur enth¨
alt die beiden verbotenen Graphmuster collision und notMember.
Das verbotenen Graphmuster collision aus Abbildung A.12 stellt einen Unfall dar, den es auf
jeden Fall zu verhindern gilt. Da die Tracks so kurz sind, dass nur jeweils ein Shuttle darauf passt,
ist ein Unfall eingetreten, wenn sich zwei Shuttles auf einem Track befinden. Das bedeutet, die
162 ANHANG A. DAS SHUTTLE-BEISPIEL
Abbildung A.12: Der Unfall collision
Sicherheitseigenschaft ist verletzt, sobald es zwei Shuttle-Objekte gibt, die einen locatedOn-Link
zum selben Track-Objekt haben.
F¨
ahrt ein Shuttle in eine neue ControlledArea ein, so wird es durch die Anwendung Mitglied
der entsprechenden Movement-Community. Dadurch werden dem Shuttle dann die Rollen und
Regeln der Community zugewiesen. Eine kritische Situation ist eingetreten, wenn ein Shuttle in
eine neue ControlledArea einf¨
ahrt ohne in die entsprechende Community aufgenommen zu wer-
den. Modelliert wird diese kritische Situation durch das verbotenen Story Pattern notMember in
Abbildung A.13. Dieses verbotene Story Pattern besagt, dass eine kritische Situation eingetreten
ist, wenn sich ein Shuttle auf einem Track befindet, dass von der BaseStation einer Controlle-
dArea ¨
uberwacht wird, jedoch zwischen dem Shuttle und der ControlledArea kein contains-Link
existiert.
Abbildung A.13: Die kritische Situation notMember
Die verbotenen Graphmuster der ControlledMovement-Kultur
In der ControlledMovement-Kultur gelten die Sicherheitseigenschaften der ¨
ubergeordneten Mo-
vement-Kultur: collision und notMember. Dar¨
uber hinaus ist in der ControlledMovement-Kultur
eine weitere Sicherheitseigenschaft in Form eines Story Patterns definiert.
Das verbotene Story Pattern noPublication, dargestellt in Abbildung A.14, stellt eine kritische
Situation dar. Diese ist eingetreten, wenn sich ein Shuttle auf einem Track befindet ohne mit der
BaseStation, die diesen Track ¨
uberwacht, das Publication-Muster auszuf¨
uhren. Dies ist deshalb
kritisch, da das Shuttle dann keine Informationen ¨
uber die Positionen der anderen Shuttles der
ControlledArea, zu der die BaseStation geh¨
ort, erh¨
alt und auch die anderen Shuttles nichts von
dem neuen Shuttle erfahren.
A.2. VERBOTENE GRAPHMUSTER 163
Abbildung A.14: Die kritische Situation noPublication
A.2.2 Die verbotenen Graphmuster der CoordinatedMovement-Kultur
Die Regeln der CoordinatedMovement-Kultur m¨
ussen alle Sicherheitseigenschaften erf¨
ullen, die
in den ¨
ubergeordneten Kulturen, Movement und ControlledMovement, spezifiziert sind. Zus¨
atz-
lich zu diesen drei Sicherheitseigenschaften gelten in der CoordinatedMovement-Kultur auch
noch die beiden Eigenschaften impendingCollision und impendingCollisionSwitch. Beide Sicher-
heitseigenschaften sind in Form von verbotenen Story Patterns spezifiziert.
Das verbotene Story Pattern impendingCollision beschreibt eine kritische Situation. Diese ist
eingetreten, wenn zwei Shuttles hintereinanderherfahren, das vordere Shuttle sich auf dem Track
befindet, auf den das hintere als n¨
achtes fahren m¨
ochte, die beiden Shuttles das DistanceCoor-
dination-Muster jedoch nicht miteinander ausf¨
uhren. DistanceCoordination-Muster miteinander
auszuf¨
uhren. In diesem Fall droht eine Kollision, da die beiden Shuttles mit sehr geringem Ab-
stand hintereinanderherfahren, das vordere Shuttle jedoch keine R¨
ucksicht auf das hintere nimmt.
W¨
urde das vordere Shuttle pl¨
otzlich stark bremsen, so bliebe dem hinteren Shuttle keine Zeit,
um zu reagieren.
Abbildung A.15: Die kritische Situation impendingCollision
Eine kritische Situation kann auch an einer Weiche auftreten. Dies ist genau dann der Fall,
wenn sich zwei Shuttles auf den parallelen Tracks direkt vor einer Weiche befinden, jedoch nicht
das DistanceCoordination-Muster miteinander ausf¨
uhren. Einerseits w¨
urde in diesem Fall die
Vorw¨
artsbewegung eines Shuttles dazu f¨
uhren, dass sich die beiden Shuttles auf zwei aufein-
ander folgenden Tracks befinden, ohne jedoch das DistanceCoordination-Muster auszuf¨
uhren,
dies w¨
urde dann der kritischen Situation impendingCollision entsprechen. Zum anderen w¨
are in
diesem Fall aber auch nicht geregelt, welches Shuttle die Weiche zuerst passieren darf Somit
164 ANHANG A. DAS SHUTTLE-BEISPIEL
k¨
onnten beide Shuttles weiterfahren und w¨
urden sich dann auf demselben Track befinden, was
eine Kollsion der beiden Shuttles bedeutet. Diese kritische Situation, impendingCollisionSwitch,
wird in Abbildung A.16 dargestellt.
Abbildung A.16: Die kritische Situation impendingCollisionSwitch
A.2.3 Kardinalit¨
aten
Da der Ansatz aus Kapitel 3 und dessen Umsetzung aus Abschnitt 5.3 die im Klassendiagramm
gegebenen Kardinalit¨
aten nicht ber¨
ucksichtigt, m¨
ussen diese durch zus¨
atzlich verbotene Gra-
phmuster spezifiziert werden. Wird dies nicht gemacht, so erh¨
alt man bei der Verifikation Gegen-
beispiele, die das Klassendiagramm verletzen. Die in diesem Beispiel verwendeten verbotenen
Graphmuster sollen nachfolgend kurz vorgestellt werden. Das Klassendiagramm des Shuttle-
Beispiels ist noch einmal in Abbildung A.17 dargestellt.
Abbildung A.17: Die erweiterte Ontologie
Die Kardinalit¨
aten des Klassendiagramms fordern, dass ein Shuttle sich genau auf einem
Track befindet. Deshalb verbietet das Story Pattern singleLocatedOn in Abbildung A.18, dass
ein Shuttle meherere locatedOn-Links zum selben Track besitzt. Dementsprechend verbietet das
A.2. VERBOTENE GRAPHMUSTER 165
Abbildung A.18: singleLocatedOn
Abbildung A.19: unumbigousLocatedOn
Story Pattern unambigousLocatedOn, Abbildung A.19, dass ein Shuttle locatedOn-Links zu un-
terschiedlichen Tracks hat.
W¨
ahrend ein locatedOn-Link angibt, auf welchem Track sich ein Shuttle befindet, werden
die next-Links dazu verwendet, um anzugeben auf welchen Track das Shuttle als n¨
achstes fah-
ren m¨
ochte. Deshalb ist es nicht erlaubt, dass ein next-Link auf den selben Track zeigt wie der
locatedOn-Link des Shuttles. Dies wird durch das verbotene Story Pattern locatedOnNext aus
Abbildung A.20 dargestellt.
Abbildung A.20: locatedOnNext
Um eine sichere Fahrt eines Shuttles garantieren zu k¨
onnen, muss es immer zwei next-
Links besitzen, die anzeigen, auf welche Tracks das Shuttle als n¨
achstes und ¨
ubern¨
achstes fahren
m¨
ochte. Die beiden next-Links d¨
urfen jedoch nicht zum selben Track-Objekt zeigen. Diese Ei-
genschaft wird durch das verbotene Story Pattern singleNext in Abbildung A.21 spezifiziert.
Abbildung A.21: singleNext
Das Klassendiagramm aus Abbildung A.17 fordert, dass ein Shuttle genau zwei next-Links
hat. Deshalb verbietet das Story Pattern tooManyNext aus Abbildung A.22, dass ein Shuttle mehr
als zwei next-Links hat.
W¨
ahrend die bisher in diesem Abschnitt betrachteten verbotenen Story Patterns Aussagen
¨
uber ein Shuttle und seine Links gemacht haben, schr¨
anken die folgenden verbotenen Story Pat-
terns das Schienensystem ein.
Die verbotenen Story Pattern singleSuccessor, Abbildung A.23, und twoWayTracks, Abbil-
dung A.24, beschreiben, dass zwischen zwei Tracks nur genau ein successor-Link sein darf.
Dabei verbietet singleSuccessor, dass sich zwischen zwei Tracks mehrere successor-Links in
166 ANHANG A. DAS SHUTTLE-BEISPIEL
Abbildung A.22: tooManyNext
dieselbe Richtung existieren. Das Story Pattern twoWayTracks verbietet, dass zwischen zwei
Tracks jeweils ein successor-Link in jede Richtung existiert.
Abbildung A.23: singleSuccessor
Abbildung A.24: twoWayTracks
Im Klassendiagramm in Abbildung A.17 ist angegeben, dass ein Track h¨
ochstens zwei
Vorg¨
anger oder Nachfolger haben darf. Das verbotene Story Pattern tooManyPredecesors in
Abbildung A.25 zeigt, dass ein Track mehr als zwei Vorg¨
anger hat. Dem gegen¨
uber verbietet das
Story Pattern tooManySuccessors in Abbildung A.26, dass ein Track mehr als zwei Nachfolger
hat.
Abbildung A.25: tooManyPredecesors
A.2.4 Gr¨
oßen der verbotenen Graphmuster
Nachdem in den voran gegangenen Abschnitten die verbotenen Graphmuster erl¨
autert wurden,
werden in der Tabelle A.2 die Gr¨
oßen der verbotenen Graphmuster aufgelistet.
A.2. VERBOTENE GRAPHMUSTER 167
Abbildung A.26: tooManySuccessors
Verbotene Gr¨
oße
Graphmuster Objekte Links
collision 3 2
notMember 4 4
noPublication 4 4
impendingCollision 5 6
impendingCollisionSwitch 6 8
singleLocatedOn 2 2
unumbigousLocatedOn 3 2
locatedOnNext 2 2
singleNext 2 2
tooManyNext 4 3
singleSuccessor 2 2
twoWayTracks 2 2
tooManyPredesesors 4 3
tooManySuccessors 4 3
Tabelle A.2: Charakteristiken der verbotenen Graphmuster im Shuttle-Beispiel
168 ANHANG A. DAS SHUTTLE-BEISPIEL
Anhang B
Theoretische Ergebnisse und
Beweisskizzen
F¨
ur die in Kapitel 3 aufgef¨
uhrten Lemmata und Theoreme sollen in diesen Kapitel deren Beweise
skizziert werden.
B.1 Graphmuster
Lemma 1. (Implikation von Teilgraphmustern)
F¨
ur zwei Graphmuster pund p0gilt:
(p⊆p0)⇒(∀G∈ G[p0] : G|=p)und (B.1)
(∃G∈ G[p0] : G6|=p)⇒(p6⊆ p0).(B.2)
Beweis: Implikation B.1: Um zu zeigen, dass die Implikation stimmt, muss zum einen gezeigt
werden, dass es einen Isomorphismus gibt, der Pauf Gabbildet und zum anderen, dass es keinen
Isomorphismus gibt, er ein ˆ
P∈ˆ
Pauf Gabbildet.
Per Definition gilt (p⊆p0)⇒ ∃iso ∈ ISO :Piso P0und ∀G∈ G[p0],∃iso0∈ ISO :
G⇒P0iso0G. Daraus folgt ∃iso00 ∈ ISO :iso00 := iso0◦iso, f¨
ur diesen Isomorphismus iso00
gilt Piso00 G. Womit die erste Forderung erf¨
ullt ist.
Nach Definition 20 gilt ∀ˆ
P∈ˆ
P,∃ˆ
P0∈ˆ
P,isoiv ∈ ISO :iso |P=iso ∧
(ˆ
P0\(P0\iso(P))) isoiv ˆ
P. Aus ∃iso0∈ ISO :P0iso0Gund ∀ˆ
P0∈ˆ
P0,6 ∃iso000 ∈ ISO :
iso000 |P0=iso0∧ˆ
P0iso000 Gfolgt, dass ∀ˆ
P0∈ˆ
P0,6 ∃isov∈ ISO : (ˆ
P0\(P0\iso(P))) isovGund
damit gilt auch ∀ˆ
P∈ˆ
P,6 ∃isovi ∈ ISO :isovi |P=iso00 ∧ˆ
Pisovi G. Damit ist auch die zweite
Forderung erf¨
ullt und es gilt G|=p.
Implikation B.2: folgt direkt aus Implikation B.1.
169
170 ANHANG B. THEORETISCHE ERGEBNISSE UND BEWEISSKIZZEN
B.2 Das Systemmodell
Lemma 2. F¨
ur zwei Graphen G1,G2∈ G, die typkonform zu GΩsind, gilt, dass auch ihre Verei-
nigung G1∪G2typkonform zu GΩist.
Beweis: Beide Graphen sind typkonform zu GΩ, das bedeutet, dass ihre Beschriftungsfunktionen
das gleiche Alphabet GΩverwenden. Somit kann eine Vereinigung der beiden Graphen gebildet
werden. Da bei der Vereinigung keine neuen Elemente erzeugt werden, sondern ein neuer Graph
aus den Elementen von G1und G2gebildet wird, ist auch die Vereinigung typkonform zu GΩ.
Lemma 3. F¨
ur zwei Graphen G1,G2∈ G, die typkonform zu GΩsind, gilt, dass auch der Schnitt
G1∩G2und die Subtraktion G1\G2typkonform sind.
Beweis: Beide Graphen sind typkonform zu GΩ, somit ist das Bilden des Schnitts und der Subtrak-
tion m¨
oglich. Beim Schnitt und der Subtraktion werden keine neuen Elemente erzeugt, sondern
Elemente aus einem Graphen entfernt, der typkonform zu GΩist, somit ist auch der Schnitt und
die Subtraktion typkonform zu GΩ.
Lemma 4. F¨
ur zwei Graphen G1,G2∈ G und einen totalen Graphhomomorphismus
m∈ M :G17→ G2gilt, dass G1genau dann typkonform zu GΩist, wenn G2typkonform zu GΩ
ist.
Beweis: Die Definition 9 verlangt f¨
ur einen totalen Graphhomomorphismus, dass er die Knoten-
und Kantenbeschriftungen erh¨
alt. Existiert ein m∈ M :G17→ G2so gilt, dass entweder beide
Graphen G1und G2typkonform zum Typgraphen GΩsind oder beide Graphen nicht typkonform
sind.
Theorem 1. F¨
ur jeden typkonformen Graphen G1∈ G und jede typkonforme Graphtransforma-
tionsregel [L,ˆ
L]→rRgilt: falls ein G2∈ G existiert, mit G1|=⇒rG2, so ist auch G2typkonform.
Beweis: Die Regel [L,ˆ
L]→rRist auf den Graphen G1anwendbar, wenn ∃iso ∈ ISO :Liso G
und ∀ˆ
L∈ˆ
L,6 ∃iso0:iso0|L=iso ∧ˆ
Piso0Ggilt. Nach Lemma 4 gilt, dass Homomorphismen die
Typkonformit¨
at erhalten. Kann die Regel unter dem Auftreten omit o:o|L=iso angewendet
werden, so werden aus G1durch Subtraktion alle Elemente entfernt auf die die Elemente aus
L\Rabgebildet werden k¨
onnen, d.h. G0
1:= G1\o(L\R). Da die Subtraktion nach Lemma 3
die Typkonformit¨
at erh¨
alt, ist der resultierende Graph G0
1typkonform zu GΩ.G0
1wird nun um alle
Elemente aus R\Lerweitert, d.h. G2:= G0
1∪o(R\L). Da die Vereinigung nach Lemma 2 die
Typkonformit¨
at erh¨
alt, ist G2typkonform zu GΩ.
Lemma 5. Wird eine typkonforme Regel [L,ˆ
L]→rRwie in Definition 27 erweitert und die erwei-
terte Regel auf einen typkonformen Graphen Gim DPOiso angewendet, so erf¨
ullt die Regelan-
wendung die Lose-Kanten-Bedingung.
Beweis: Sei [Lre,ˆ
Lre]→reRre eine erweiterte Regel, G1∈ G ein Anwendungsgraph und G2∈ G
ein Ergebnisgraph, wobei G1und G2typkonform zu GΩsind und es gilt G1|=⇒re G2.
Angenommen, die Anwendung von runter Auftreten oauf den Graphen G1er-
zeugt eine lose Kante, d.h. ∃e∈EG1,6 ∃e0∈ELre :o(e0) = e∧((src(e0)∈(NLre \NRre )) ∨
(tgt(e0)∈(NLre \NRre ))). Das bedeutet, es m¨
ussen zwei F¨
alle betrachtet werden. Erstens der
Fall, dass bei einer Kante der Startknoten fehlt und zum zweiten der Fall, dass bei einer Kante
der Zielknoten fehlt.
B.3. ERWEITERTE GRAPHTRANSFORMATIONEN 171
Fall 1: es gibt eine Kante, bei der der Startknoten fehlt, d.h. ∃n∈(NL\NR) :
o(n) = src(e). Da rre anwendbar ist bedeutet das, dass es keinen Graphen
ˆ
Lre ∈ˆ
Lre gibt, der die Anwendung verbietet, d.h. 6 ∃ˆ
Lre ∈ˆ
Lre :Nˆ
Lre := NLre ∪ {n},
Eˆ
Lre := ELre ∪ {e},srcˆ
Lre := srcLre (x) : x∈ELre
n:x== e,tgtˆ
Lre := tgtLre (x) : x∈ELre
n:x== e,
lNˆ
Lre (x) := lNLre (x) : x∈NLre
tn:x== nund lEˆ
Lre (x) := lELre (x) : x∈ELre
te:x== e. Da f¨
ur jede
korrekt typisierte Kante, die inzident zu einem zu l¨
oschenden Knoten ist, ein Graph zur negativen
Anwendungsbedingung hinzugef¨
ugt wird, gilt auch, dass f¨
ur jede korrekt typisierte Kante e00
mit o(n) = src(e00)ein Graph in die negative Anwendungsbedingung aufgenommen wird. Da es
jedoch keinen Graphen in der negativen Anwendungsbedingung gibt, der die Regelanwendung
verbietet, sodass der Knoten o(n)gel¨
oscht wird und aus der Kanten o(e)eine lose Kante wird,
folgt daraus, dass enicht korrekt typisiert ist. Diese ist jedoch ein Widerspruch zur Annahme, da
G1typkonform zu GΩist.
Fall 2: erfolgt analog zu Fall 1.
B.3 Erweiterte Graphtransformationen
Theorem 2. (R¨
uckw¨
artsanwendung einer Graphtransformationsregel im DPOiso)
F¨
ur jede Graphtransformationsregel [L,ˆ
L]→rR, ihr Inverses [L−1,ˆ
L−1]→r−1R−1und ein Auf-
treten ovon rin G1gilt im DPOiso:
G1|=⇒(r,o)G2⇔G2|=⇒(r−1,o−1)G1.
Beweis: ”⇒“:Da G2durch die Anwendung von runter dem Auftreten oauf den Graphen
G1entstanden ist, muss es einen Isomorphismus iso ∈ ISO geben, f¨
ur den gilt iso =o−1|L−1
∧L−1iso G2. Somit ist r−1anwendbar wenn gilt ∀ˆ
L−1∈ˆ
L−1,6 ∃iso0∈ ISO :iso0|L−1=iso ∧
ˆ
Liso0G2.
Die Menge ˆ
L−1kann in zwei Teilmengen unterteilt werden: Die erste Menge ˆ
L−1
1enth¨
alt
alle Graphen ˆ
L−1∈ˆ
L−1, die durch die Anwendung von extendNAC erzeugt wurden, um eine
Anwendung von r−1zu verhindern, wenn andernfalls lose Kanten entstehen. Die zweite Menge
ˆ
L−1
2∈ˆ
L−1enth¨
alt alle Graphen ˆ
L−1, die durch die Konvertierung der negativen Anwendungs-
bedingung ˆ
Lentstanden sind.
F¨
ur die Graphen der Menge ˆ
L−1
1gilt, dass ihre Knoten entweder auch in L−1enthalten sind
oder adjazent zu Knoten sind, die bei der Anwendung von r−1gel¨
oscht und damit durch die An-
wendung von rerzeugt werden. Da Knoten, die durch die Anwendung von rerzeugt wurden, nur
adjazent zu Knoten sein k¨
onnen, die zu Rund somit auch zu L−1geh¨
oren, gibt es keinen Isomor-
phismus iso0∈ ISO der einen Graphen aus ˆ
L−1auf G2abbildet und f¨
ur den gilt iso0|L−1=iso.
Somit wird die Regelanwendung durch die Teilmenge ˆ
L−1
1nicht verhindert.
F¨
ur die Menge ˆ
L−1
2gilt, dass ihre Graphen durch die Konvertierung der negativen Anwen-
dungsbedingung ˆ
Lvon rentstanden sind, d.h. ∀ˆ
L−1∈ˆ
L−1
2,∃ˆ
L∈ˆ
L:ˆ
L|=⇒L→(r0,o)Rˆ
L−1. Da die
Graphen aus ˆ
L−1
2durch die Anwendung der gleichen Regel entstanden sind, wie der Graph
G2, gilt, dass es nur dann einen Isomorphismus iso1∈ ISO geben kann, der einen Graphen
ˆ
L−1∈ˆ
L−1
2auf G2abbildet, wenn es einen Isomorphismus iso2∈ ISO und einen Graphen ˆ
L∈ˆ
L
172 ANHANG B. THEORETISCHE ERGEBNISSE UND BEWEISSKIZZEN
gibt, sodass gilt ˆ
Liso2G1und ˆ
L|=⇒L→(r0,o)Rˆ
L−1. Dies ist jedoch ein Widerspruch, da rauf G1
anwendbar ist. Somit wird die Anwendung von r−1auf G2unter dem Auftreten o−1auch durch
die Menge ˆ
L−1
2nicht verhindert.
”⇐“:erfolgt analog zu ”⇒“.
Theorem 3. F¨
ur eine Graphtransformationsregel [L,ˆ
L]→rRund zwei Graphmuster
p:= [P,hatP],p0:= [P0,ˆ
P0]gilt im DPOiso:
(p|=|=⇒rp0)
⇔
(∀G1,G2∈ G,iso ∈ ISO :P∪P0→G1∪G2: (G1|=p∧G1|=⇒r,iso|L∪RG2)⇒(G2|=p0)).
Beweis: ”⇒“:Annahme (G1|=p∧G|=⇒(r,iso|R∪L)G2)⇒(G2|=p0)gilt nicht. Dann muss ei-
ner der beiden folgenden F¨
alle gelten: (1) 6 ∃iso0∈ ISO :iso0|P0=iso ∧P0iso0G2oder es gilt
(2) ∃ˆ
P∈ˆ
P,iso0∈ ISO :iso0|P0=iso |P0∧ˆ
P0iso0G2.
Fall (1): falls kein solcher Isomorphismus iso0existiert, muss gelten
∃n∈NP0,e∈EP0:iso0(n) = undefiniert ∨iso0(e) = undefiniert. Da iso alle Elemente aus
Pauf G1abbildet und p|=|=⇒rp0gilt muss n(oder e) entweder (a) nur in P0aber nicht in Pent-
halten sein und somit durch die Anwendung von rerzeugt werden oder (b) n(oder e) ist sowohl
Teil von Pals auch von P0wird aber durch die Anwendung von rgel¨
oscht, d.h. n∈(NL\NR)
(bzw. e∈(EL\ER)).
(a) da p|=|=⇒r,op0gilt, muss rden Knoten n(bzw. die Kantee) erzeugen, d.h. n∈(NR\NL)
(bzw. e∈(ER\EL)). Dann wird n(bzw. e) jedoch auch bei der Anwendung von runter dem
Auftreten oauf G1erzeugt und ist somit auch in G2enthalten.
(b) n(bzw. e) geh¨
ort sowohl zu Pals auch zu P0, dann muss die Anwendung von runter o
das Element l¨
oschen, in diesem Fall wird das Element aber auch gel¨
oscht, wenn runter oauf p
angewendet wird und somit w¨
urde nicht p|=|=⇒(r,o)p0gelten.
Fall 2: es gilt ∃ˆ
P0∈ˆ
P0,iso0∈ ISO :iso0|P0=iso |P0∧ˆ
P0iso0G2. Da p|=|=⇒rp0und G1|=p
gilt, muss ˆ
P0durch die Anwendung von rerzeugt worden sein. Die Menge ˆ
P0setzt sich aus zwei
Teilmengen zusammen. (a) Die erste Menge, ˆ
P0
1, enth¨
alt alle ˆ
P0, die durch extendNAC erzeugt
werden. (b) Die zweite Menge, ˆ
P0
2, enth¨
alt alle ˆ
P0, f¨
ur die gilt ∃ˆ
P∈ˆ
P:ˆ
P|=⇒L→r0Rˆ
P0.
(a) extendNAC pr¨
uft f¨
ur jeden durch rneu erzeugten Knoten im Typgraphen, Knoten
von welchem Typ adjazent zum neuen Knoten sein k¨
onnen. F¨
ur jeden dieser Knoten wird
ein Graph in die negative Anwendungsbedingung eingef¨
ugt. Somit beschreiben die ˆ
P0∈ˆ
P0
1,
dass ein neu erzeugter Knoten nur adjazent zu Knoten aus Rsein kann. Daraus folgt, dass
∀ˆ
P∈ˆ
P0
1,6 ∃iso0∈ ISO :ˆ
Piso0G2.
(b) ∀ˆ
P∈ˆ
P0
2,∃ˆ
P∈ˆ
P:ˆ
P|=⇒L→r0Rˆ
P0, daraus folgt, dass ˆ
P0durch die Anwendung von run-
ter dem Auftreten onur entstehen kann, wenn ˆ
Pdurch einen Isomorphismus aus G1abgebildet
werden kann, dann w¨
urde aber G16|=pgelten, was eine Widerspruch zur Voraussetzung ist.
Aus Fall 1 und Fall 2 folgt ”⇒“.
”⇐“:zuerst wird gezeigt, dass P|=⇒(r,o)P0gilt. Die rechte Seite der Implikation gilt f¨
ur
alle Graphen G1und G2, f¨
ur die gilt G|=p∧G1|=⇒(r,o)G2. Somit k¨
onnen G1und G2beliebig
B.4. SYSTEMEIGENSCHAFTEN UND INVARIANTEN 173
gew¨
ahlt werden, also auch G1=Pund G2=P0. Daraus folgt dann P=G1|=⇒rG2=P0, dies
entspricht P|=⇒rP0.
Angenommen der rechte Teil der Implikation gilt, der linke aber nicht, d.h. ¬(p|=|=⇒(r,o)p0)
⇒(p|=|=⇒(r,o)p00). Da P|=⇒(r,o)P0gilt, muss auch P00 ≈P0gelten. Nach ”⇒“ gilt
(p|=|=⇒(r,o)p00)⇒(∀G1,G2∈ G,iso ∈ ISO :P∪P00 7→ G1∪G2: (G1|=p∧G|=⇒(r,o)G2)
⇒(G2|=p00)). Wegen P00 ≈P0und ¬(p|=|=⇒(r,o)p0)muss dann jedoch gelten (∃ˆ
P0∈ P0,
iso0∈ ISO :ˆ
P0iso0G2)⇒(G26|=p0), was aber ein Widerspruch zur Voraussetzung ist.
Theorem 4. F¨
ur eine Graphtransformationsregel [L,ˆ
L]→rR, ihr Inverses [L−1,ˆ
L−1]→r−1R−1,
zwei Graphmuster p:= [P,ˆ
P]und p0:= [P0,ˆ
P0]und ein Auftreten o:L∪R7→P∪P0gilt im
DPOiso:
(p|=|=⇒(r,o)p0)⇔(p0|=|=⇒(r−1,o−1)p).
Beweis: Folgt direkt aus den beiden Theoremen 2 und 3.
B.4 Systemeigenschaften und Invarianten
Lemma 6. Eine Eigenschaft φist eine induktive Invariante eines Systems S:= (GΩ,Gi
S,RS),
falls T[φ, ¬φ] = ∅.
Beweis: ”⇒“:Da φeine induktive Invariante ist, gilt ∀G1,G2∈ G[GΩ],r∈ R,o∈ ISO :
(G1|=⇒(r,o)G2∧G|=φ)⇒(G2|=φ). Damit gilt dann auch T[φ, ¬φ] = ∅.
”⇐“:Aus T[φ, ¬φ]folgt 6 ∃r∈ R,G1,G2∈ G[GΩ],o∈ ISO : ((G1|=⇒(r,o)G2∧G|=φ)
∧G26|=φ). Deshalb gilt ∀r∈ R,G1,G2∈ G[GΩ],o∈ ISO : (¬(G1|=⇒(r,o)G2∧G|=φ)∨
¬(G6|=φ)). Das ist ¨
aquivalent zu ∀r∈ R,G1,G2∈ G[GΩ],o∈ ISO : (G1|=⇒(r,o)G2∧G1|=φ)
⇒(G2|=φ)und somit ist φeine induktive Invariante.
Lemma 7. F¨
ur eine Sicherheitseigenschaft der Form Vj∈J(¬pj)und ein System
S:= (G[GΩ],Gi
S,RS)ist die Menge T[φ, ¬φ]genau dann nicht leer und somit das System
inkorrekt, wenn gilt:
∃Gφ,G¬φ∈ G[GΩ],r∈ RS,o∈ ISO :
(Gφ|=⇒(r,o)G¬φ)∧(∃i∈J:G¬φ|=pi)∧(∀j∈J:Gφ6|=pj).(B.3)
Beweis: Folgt direkt aus der Definition von T[φ, ¬φ]und der Struktur der Sicherheitseigenschaf-
ten.
174 ANHANG B. THEORETISCHE ERGEBNISSE UND BEWEISSKIZZEN
B.5 Nachweis von induktiven Invarianten
Lemma 8. F¨
ur eine Graphtransformationsregel [L,ˆ
L]→rRund ein Graphmuster p:= [P,ˆ
P]gilt
im DPOiso:
∀G,G0∈ G,o∈ ISO :G|=⇒(r,o)G0∧G6|=op∧G0|=iso p
⇒
((R\L)∩o(P)6=∅)∨(∃iso ∈ ISO,ˆ
P∈ˆ
P:iso |P=o|P∧L∩R∩ˆ
P6=∅).(B.4)
Beweis: Annahme die Implikation gilt nicht, d.h. es gilt (1) dass (R\L)∩iso(P) = ∅und (2)
∀iso0∈ ISO,ˆ
P∈ P :iso |P=iso ∧(L∩R∩iso0(P)) = ∅.
(1) es gilt (R\L)∩iso(P) = ∅ ⇒ 6 ∃n∈NP,e∈EP: (iso(n)∈(NG1\NG2)) ∨
(iso(e)∈(EG1\EG2)) ⇒Piso G1.
(2) es gilt ∀iso0∈ ISO,ˆ
P∈ˆ
P:iso0|P=iso ∧L∩R∩iso0(ˆ
P) = ∅ ⇒ 6 ∃n∈Nˆ
P:
iso0(n)∈(L∩R). Nach (1) gilt Piso G1. Somit muss die Anwendung von reinen Knoten aus
(Nˆ
P\NP)oder eine Kante aus (Eˆ
P\EP)entfernen. F¨
ur alle Knoten aus (Nˆ
P\NP)gilt, wegen
der Verwendung des DPOiso, dass es einen Pfad zu einem Knoten aus Pgibt. Das bedeutet, dass
ein Knoten aus Nˆ
P\NPentfernt oder in diese Menge eingef¨
ugt werden kann, wenn ein adjazenter
Knoten n0explizit durch die Regel erhalten bleibt, d.h. es muss gelten n0∈(NL∩NE∩iso(Nˆ
P)).
Ebenso kann eine Kante aus (Eˆ
P\EP)nur gel¨
oscht werden, wenn ein inzidenter Knoten n0expli-
zit erhalten bleibt. Da die Menge (NL∩NE∩iso(Nˆ
P)) leer ist, muss somit gelten, dass ∀ˆ
P∈ P :
ˆ
P6iso G1.
Beide Punkte zusammen ergeben einen Widerspruch zur Annahmen.
Lemma 9. F¨
ur ein System S:= (GΩ,Gi,RS)und eine Sicherheitseigenschaft φ:= Vj∈J(¬pj)
gilt im DPOiso ∀i∈J,r∈ R:
(∀egm ∈ EGM≈(r,pi),sgm,o∈ ISO : (egm |=|=⇒(r−1,o−1)sgm)∧(∃j∈J:pj⊆sgm))
⇒
(∀G1,G2∈ G[GΩ]:(G1|=⇒(r,o)G2∧G2|=pi)⇒(∃j∈J:G1|=pj)).
Beweis: Angenommen, die Implikation gilt nicht. Dann gilt ¬(∀G1,G2∈ G[GΩ],o∈ ISO :
(G1|=⇒(r,o)G2∧G2|=pi)⇒(∃j∈J:G1|=pj)), d.h. ∃G1,G2∈ G[GΩ] : (G1|=⇒(r,o)G2∧
G2|=Pi)und es gilt ∀j∈J:G16|=pj. Da ∀j∈J:G16|=pjgilt, folgt daraus, dass die Anwen-
dung von runter dem Auftreten oauf G1pierzeugt haben muss. Nach Lemma 8 muss G2ein
Element enthalten, auf das oein Element der rechten Regelseite von rabbildet und auf das
zus¨
atzlich ein Element aus piabgebildet werden kann. Da die Menge T GP≈(r,pi)alle m¨
ogli-
chen Ergebnisgraphmuster f¨
ur rund pienth¨
alt, muss gelten ∃egm ∈ T GP≈(r,pi) : G2|=egm.
Aus Theorem 2 folgt dann, dass die zu rinverse Regel r−1auf G2angewendet werden kann. Diese
Regelanwendung resultiert in einem Graphen G1f¨
ur den gilt G|=sgm.G16|=φimpliziert nach
Bedingung B.1 aus Lemma 1, dass es keinen Zeugen f¨
ur ein verbotenes Graphmuster in G1gibt.
Somit muss gelten ∀j∈J:pj6⊆ sgm. Dies stellt jedoch ein Widerspruch zur Voraussetzung dar.
B.5. NACHWEIS VON INDUKTIVEN INVARIANTEN 175
Theorem 5. F¨
ur ein System S:= (GΩ,Gi
S,RS)ist die Sicherheitseigenschaft φ:= Vj∈J(¬pj)
genau dann eine induktive Invariante, wenn gilt:
∀i∈J,r∈ RS,egm ∈ EGM≈(r,pi),sgm,o∈ ISO :
(egm |=|=⇒(r−1,o−1)sgm)⇒(∃j∈J:pj⊆sgm).(B.5)
Beweis: Nach Lemma 9 gilt, dass ∀j∈J,r∈ RS,G1,G2∈ G[GΩ],o∈ ISO : (G1|=⇒(r,o)G2
∧G2|=pi)⇒ ∃j∈J:G|=pj. Dies entspricht, da φ:= Vj∈J(¬pj),∀G1,G2∈ G[GΩ],r∈ RS,
o∈ ISO : (G1|=⇒(r,o)G2∧G26|=φ)⇒G6|=φ. Nach Lemma 7 muss dann T[φ, ¬φ] = ∅gelten.
Lemma 6 garantiert dann, dass φeine induktive Invariante von Sist.
176 ANHANG B. THEORETISCHE ERGEBNISSE UND BEWEISSKIZZEN
Anhang C
Algorithmen
In diesem Kapitel werden Algorithmen in Pseudocode-Notation beschrieben, die die theoreti-
schen Ergebnisse aus Kapitel 3 darstellen.
C.1 Graphtransformationen
Dieser Abschnitt beschreibt die Algorithmen, die ben¨
otigt werden, um Graphtransformations-
regeln anzuwenden. Neben dem Algorithmus, der die eigentliche Regelanwendung beschreibt
(Abschnitt C.1.2), werden auch Algorithmen vorgestellt, die die Regeln so erweitern, dass sie im
DPOiso Ansatz korrekt angewendet werden (Abschnitt C.1.1).
C.1.1 Negative Anwendungsbedingungen
Damit eine Graphtransformationsregel im DPOiso Ansatz angewendet wird, muss garantiert wer-
den, dass sowohl die Identifikationsbedingung als auch die Lose-Kanten-Bedingung bei jeder
Regelanwendung erf¨
ullt werden. Die Erf¨
ullung der Identifikationsbedingung wird dadurch er-
reicht, dass das Auftreten einer Regel in einem Anwendungsgraphen durch einen Isomorphis-
mus gegeben sein muss. Damit die Lose-Kanten-Bedingung immer erf¨
ullt wird, muss die linke
Regelseite so erweitert werden, dass die Regel nur dann anwendbar ist, wenn bei der Anwen-
dung keine losen Kanten entstehen. Der Algorithmus, der diese Erweiterung beschreibt, ist im
folgenden Abschnitt gegeben.
Durch die Erweiterung der linken Regelseite um zus¨
atzliche Graphen in der negativen An-
wendungsbedingung, k¨
onnen redundante Graphen entstehen. Dies ist immer dann der Fall, wenn
es zwei Graphen gibt, von denen der eine ein Teilgraph des anderen ist. In diesem Fall kann
der gr¨
oßere der beiden Graphen aus der negativen Anwendungsbedingung entfernt werden. Im-
mer wenn dieser gr¨
oßere Graph eine Regelanwendung verhindert, kann der entsprechende Match
auch dazu verwendet werden, um den kleineren Graphen auf den Anwendungsgraphen abzubil-
den. Das bedeutet, dass die Regelanwendung auch durch den kleineren Graphen verboten wird.
Der Algorithmus zum Entfernen redundanter Graphen aus der negativen Anwendungsbedingung
wird nach dem Algorithmus zum Erweitern der linken Regelseite beschrieben.
177
178 ANHANG C. ALGORITHMEN
Der Algorithmus extendNAC
Abbildung C.1 zeigt einen Algorithmus in Pseudocode-Notation, der die Erweiterung der negati-
ven Anwendungsbedingung vornimmt. Als Eingabeerh¨
altder Algorithmus eineRegel[L,ˆ
L]→rR
sowie den dazu geh¨
origen Typgraph GΩ. Die ¨
außere For-Schleife betrachtet alle Knoten, die
gel¨
oscht werden sollen. In den Zeilen 5 bis 18 werden f¨
ur jeden dieser Knoten alle inzidenten
Kanten betrachtet, die den zu l¨
oschenden Knoten als Startknoten haben. Ist die Kante kein Teil
der linken Regelseite, so wird ein Graph erzeugt, der neben der linken Regelseite diese Kante
enth¨
alt. Ist der Zielknoten der Kante noch nicht im Graphen enthalten, so wird auch er in den
Graphen aufgenommen. In Zeile 16 wird der Graph zur negativen Anwendungsbedingung hinzu-
gef¨
ugt. In den Zeilen 19 bis 33 wird der Fall betrachtet, dass der zu l¨
oschende Knoten Zielknoten
einer Kante ist, die nicht durch die Regel gel¨
oscht wird.
01: Set<Graph> extendNAC(Set<Graph>(L, ˆ
L, R), Graph GΩ)
02: begin
03: Set<Graph> addNAC = ˆ
L
04: forall n∈NL−NRdo
05: forall (lN(n), te, n0)∈correctT ypedEdges(GΩ)do
06: // edge with source in L but not in R
07: if (e6∈ EL) then
08: E0:= EL∪ {e}
09: if (n06∈ NL) then
10: N0:= NL∪ {n0}
11: fi
12: src’ := λx.if (x == e) then n else src(x) fi
13: tgt’ := λx.if (x == e) then n’ else tgt(x) fi
14: l0
N:= λx.if (x == n’) then tn0else lN(x)fi
15: l0
E:= λx.if (x == e) then teelse lE(x)fi
16: addNAC.add(N0, E0, src0, tgt0, l0
N, l0
E)
17: fi
18: end
19: forall (n0, te, lN(n)) ∈correctT ypedEdges(GΩ) do
20: // edge with target in L but not in R
21: if (e6∈ EL) then
22: E0:= EL∪ {e}
23: if (n06∈ NL) then
24: N0:= NL∪ {n0}
25: fi
26: src’ := λx.if (x == e) then n’ else src(x) fi
27: tgt’ := λx.if (x == e) then n else tgt(x) fi
28: l0
N:= λ x.if (x== n0)then tn0else lN(x)fi
29: l0
E:= λ x.if (x== e)then teelse lE(x)fi
30: addNAC.add(N0, E0, src0, tgt0, l0
N, l0
E)
31: fi
32: end
33: end
34: return addNAC
35: end
Abbildung C.1: Algorithmus extendNAC, der die negative Anwendungsbedingung der linken
Regelseite erweitert, sodass die Regelanwendung die Lose-Kanten-Bedingung erf¨
ullt
C.1. GRAPHTRANSFORMATIONEN 179
Der Algorithmus minimizeNAC
Der Algorithmus zur Minimierung von negativen Anwendungsbedingungen ist in Abbildung
C.2 dargestellt. Dieser Algorithmus pr¨
uft in Zeile 4 bis 10 f¨
ur jeden Graphen ˆ
Lder negativen
Anwendungsbedingung, ob es einen anderen Graphen ˆ
L0gibt, der Teilgraph von ˆ
List. Kann kein
solcher Graph gefunden werden, wird ˆ
Lin die minimale negative Anwendungsbedingung aufge-
nommen, Zeile 11. Als R¨
uckgabe liefert der Algorithmus in Zeile 13 eine Menge von Graphen,
die die minimale negative Anwendungsbedingung beschreiben.
01: Set <Graph> minimizeNAC(<Graph> ˆ
L) begin
02: Set <Graph> HL := ∅
03: forall ˆ
L∈ˆ
Ldo
04: Boolean flag := true;
05: forall ˆ
L0∈ˆ
L−{ˆ
L}do
06: if (∃iso :iso |L) = idL∧ˆ
L0iso ˆ
L) then
07: flag := false
08: fi
09: end
10: if (flag =true) then HL := HL ∪ {ˆ
L}fi
11: end
12: return HL
13: end
Abbildung C.2: Algorithmus minimizeNAC zur Minimierung von negativen Anwendungsbedin-
gungen
C.1.2 Anwendung von Graphtransformationsregeln
Nachdem eine Graphtransformationsregel um zus¨
atzliche Graphen in der negativen Anwen-
dungsbedingung erweitert wurde, kann ihre Anwendung erfolgen. Der Algorithmus der eine
Regelanwendung im DPOiso Ansatz vornimmt, wenn diese erweitert wurden, ist im folgenden
Abschnitt gegeben.
Der Algorithmus apply
Der Algorithmus, der die Anwendung einer Regel rauf einen Graphen Gbeschreibt ist in Abbil-
dung C.3 gegeben, wobei iso das Auftreten von rin Gbeschreibt. In Zeile 02 wird ¨
uberpr¨
uft, ob
der ¨
ubergebene Isomorphismus die linke Regelseite auf einen Teilgraphen des Anwendungsgra-
phen abbildet. Ist dies nicht der Fall, so kann die Regel nicht angewendet werden. Andernfalls
wird ein neuer Isomorphismus gew¨
ahlt, der den ¨
ubergebenen Isomorphismus so erweitert, dass er
auch die Elemente der rechten Regelseite abbildet. Mittels diesem neuen Isomorphismus erfolgt
dann (Zeile 05) die eigentliche Regelanwendung. Dazu werden alle Elemente aus dem Anwen-
dungsgraphen entfernt, auf den die Elemente der linken aber nicht der rechten Regelseite durch
den Isomorphismus abgebildet werden. Elemente, die in der rechten, aber nicht in der linken Re-
gelseite enthalten sind, werden durch den Isomorphismus in den Anwendungsgraphen eingef¨
ugt.
Der resultierende Graph wird dann (Zeile 09) zur¨
uckgeliefert.
180 ANHANG C. ALGORITHMEN
01: Graph apply(Graph G, Rule L→rR, Isomorphism iso)
02: if (Liso G) then
03: choose Isomorphism iso’: R7→ G with iso0|L=iso ∧iso0(R\L)∩G=∅
04: //apply rule
05: T G := (G\iso0(L\R)) ∪iso0(R)
06: //all other nodes and edges remain unchanged
07: return TG
08: else
09: return G
10: fi
11: end
Abbildung C.3: Algorithmus apply, der die Anwendung einer Graphtransformationsregel unter
dem Single Pushout Approach beschreibt
C.2 Erweiterte Graphtransformationen
Mit dem im voran gegangenen Abschnitt eingef¨
uhrten Algorithmus ist es m¨
oglich, eine Regel
in Vorw¨
artsrichtung auf einen Anwendungsgraphen anzuwenden. Wurde die Regel zuvor um
zus¨
atzliche Graphen in der negativen Anwendungsbedingung erweitert, so erf¨
ullt diese Regelan-
wendungen die Identifikations- und die Lose-Kanten-Bedingung des Eingeschr¨
ankten Single Pu-
shout Ansatz. Eine Regelanwendung im Single Pushout Ansatz kann auch in R¨
uckw¨
artsrichtung
erfolgen. Außerdem ist es nicht nur m¨
oglich, eine Regel auf einen Anwendungsgraphen, sondern
auch auf ein Graphmuster anzuwenden. Die ben¨
otigten Algorithmen zur R¨
uckw¨
artsanwendung
von Graphtransformationsregeln werden im folgenden Abschnitt C.2.1 erkl¨
art. Der Algorithmus
zur Anwendung einer Graphtransformationsregel auf ein Graphmuster ist Inhalt von Abschnitt
C.2.2.
C.2.1 R¨
uckw¨
artsanwendung von Graphtransformationsregeln
Nachdem beschrieben wurde, wie eine Regel im DPOiso Ansatz korrekt in Vorw¨
artsrichtung
angewendet wird, soll in diesem Abschnitt die R¨
uckw¨
artsanwendung betrachtet werden. Auch
bei der R¨
uckw¨
artsanwendung m¨
ussen die Identifikations- und die Lose-Kanten-Bedingung des
DPOiso Ansatz erf¨
ullt werden.
Der Algorithmus reverse ver¨
andert eine Graphtransformationsregel so, dass sie in
R¨
uckw¨
artsrichtung angewendet werden kann und dabei die Bedingungen des DPOiso Ansatz
einh¨
alt. Dazu ist es zun¨
achst notwendig, die negative Anwendungsbedingung anzupassen. Dies
erfolgt mittels des Algorithmus convertNAC, der in Abbildung C.4 gegeben ist. Die eigentlich
Anwendung der Regel erfolgt dann mit dem bereits beschrieben Algorithmus zur Regelanwen-
dung apply aus Abbildung C.3.
Der Algorithmus convertNAC
Damit eine Regel korrekt in R¨
uckw¨
artsrichtung angewendet werden kann, muss ihre negative
Anwendungsbedingung angepasst werden. Dies ist aus verschiedenen Gr¨
unden erforderlich. Als
C.2. ERWEITERTE GRAPHTRANSFORMATIONEN 181
erstes wird bei einer R¨
uckw¨
artsanwendung aus der urspr¨
unglichen linken Regelseite die neue
rechte Regelseite und diese darf keine negative Anwendungsbedingung besitzen. Zweitens, auch
bei einer R¨
uckw¨
artsanwendung m¨
ussen die Identifikations- und die Lose-Kanten-Bedingung des
DPOiso Ansatzes eingehalten werden.
Um die negative Anwendungsbedingung konvertieren zu k¨
onnen, m¨
ussen zun¨
achst alle Gra-
phen aus der negativen Anwendungsbedingung entfernt werden, die eine Regelanwendung ver-
hindern, wenn andernfalls lose Kanten entstehen w¨
urden (Zeilen 04 bis 06). Die verbleibenden
Graphen der negativen Anwendung werden dann (Zeilen 07 bis 12) transformiert, indem die Re-
gel (ohne negative Anwendungsbedingung) darauf angewendet wird. Durch das Entfernen aller
Graphen, die eine Regelanwendung verhindern, sollten andernfalls lose Kanten entstehen, wird
gew¨
ahrleistet, dass die Regel nur auf solche Graphen angewendet wird, bei denen keine losen
Kanten zur¨
uckbleiben. Nachdem diese Graphen modifiziert wurden, m¨
ussen nun die Graphen
hinzugef¨
ugt werden, die eine Regelanwendung verhindern, wenn sonst lose Kanten entstehen.
Dazu wird die Funktion extendNAC (Zeile 13) aufgerufen, wobei jedoch die linke und die rechte
Regelseite vertauscht wurden.
01: Set<Graph> convertNAC(GraphRule [L, ˆ
L]→rR)
02: begin
03: Set <Graph> HL’ := ∅
04: Set <Graph> enac := extendNAC([L, ˆ
L]→rR, G Ω)
05: //delete all graphs of the NAC which relate to a dangling edge
06: Set <Graph> HL := {ˆ
L∈ˆ
L | 6 ∃ ˆ
L0∈enac :ˆ
L0≤ˆ
L}
07: while HL 6=∅do
08: choose ˆ
Lin HL
09: ˆ
L0:= apply(ˆ
L, L→rR)
10: HL := HL \ {ˆ
L}
11: HL’ := HL’ ∪ {ˆ
L0}
12: end
13: return HL0∪extendNAC(R→r−1L, GΩ)
14: end
Abbildung C.4: Algorithmus convertNAC zum Konvertieren von negativen Anwendungsbedin-
gungen
Der Algorithmus reverse
Der Algorithmus reverse Abbildung C.5 beschreibt die Transformation einer Graphtransforma-
tionsregel, sodass ihre Anwendung mittels des Algorithmus apply aus Abbildung C.3 die Bedin-
gungen des DPOiso Ansatzes erf¨
ullt.
In einem ersten Schritt (Zeile 03) wird dazu die negative Anwendungsbedingung mit Hilfe
des Algorithmus convertNAC aus Abbildung C.4 konvertiert. Anschließend wird die resultie-
rende negative Anwendungsbedingung mit dem Algorithmus minimizeNAC aus Abbildung C.2
minimiert, d.h. redundante Graphen werden entfernt (Zeile 04). Als letztes wird die Aufgabe der
Graphen Lund Rvertauscht (Zeile 05). Das bedeutet, aus der urspr¨
unglichen Nachbedingung,
der rechten Regelseite R, wird die neue Anwendungsbedingung und aus der urspr¨
unglichen An-
wendungsbedingung Ldie neue Nachbedingung.
182 ANHANG C. ALGORITHMEN
01: GraphRule reverse(GraphRule [L, ˆ
L]→rR, Graph GΩ)
02: begin
03: Set<Graph> nac := convertNAC( [L, ˆ
L]→rR, GΩ)
04: nac := minimizeNAC([R, nac]→r−1L)
05: return [R, nac]→r−1L
06: end
Abbildung C.5: Algorithmus reverse zur Invertierung von Graphtransformationsregeln
C.2.2 Anwendung von Regeln auf Graphmuster
Eine Graphtransformationsregel kann auch dazu genutzt werden, um ein Graphmuster zu
ver¨
andern. Dabei muss jedoch ber¨
ucksichtigt werden, dass das Graphmuster eine negative An-
wendungsbedingung besitzen kann. Diese negative Anwendungsbedingung muss durch die Re-
gelanwendung ebenfalls transformiert werden. Der Algorithmus, der eine Regel auf ein Gra-
phmuster anwendet, wird im Folgenden beschrieben.
Der Algorithmus applyRuleToPattern
Der Algorithmus, der die Anwendung einer Regel rauf ein Graphmuster pbeschreibt, ist in
Abbildung C.6 gegeben. Die if-Anweisung in Zeile 02 pr¨
uft, ob die linke Regelseite ein Teilgra-
phmuster des Graphmusters [P,ˆ
P]ist. Ist dies der Fall, wird in den Zeilen 03 bis 16 das Auftreten
oder linken und rechten Regelseite bestimmt. Dieses Auftreten bildet Elemente der linken Re-
gelseite mittels des Isomorphismus aus der if-Anweisung auf Elemente der Graphmusters ab. F¨
ur
Elemente, die nur Teil der rechten Regelseite sind, wird die Identit¨
atsfunktion verwendet. Das
Auftreten wird dann dazu verwendet, um alle Elemente, die zur linken, aber nicht zur rechten
Regelseite geh¨
oren aus dem Muster zu entfernen (Zeile 19). Elemente, die zur rechten aber nicht
zur linken Regelseite geh¨
oren, werden mit Hilfe von oin das Muster eingef¨
ugt, Zeile 22. Ist dies
erfolgt, so wird die negative Anwendungsbedingung des Musters angepasst. In der for-Schleife
in den Zeilen 27 bis 30 werden die Graphen der negativen Anwendungsbedingung ˆ
Pangepasst,
indem die Regel rauf jeden der Graphen angewendet wird. Da [L,ˆ
L]ein Teilgraphmuster von
[P,ˆ
P], ist eine Anwendung der Regel auf jeden Graphen aus ˆ
Pimmer m¨
oglich. Da die Regel
rauf ein Graphmuster angewendet wird, wird auch die konvertierte negative Anwendungsbe-
dingung von rin die negative Anwendungsbedingung von paufgenommen. Dies ist in Zeile
32 beschrieben. Als Ergebnis liefert der Algorithmus ein Graphmuster p0:= [P0ˆ
P0], wobei P0
durch die Anwendung der Regel auf Perzeugt wird und ˆ
P0sich aus den konvertierten negativen
Anwendungsbedingungen von pund rzusammensetzt.
C.3 ¨
Uberpr¨
ufung induktiver Invarianten
Nachdem die Algorithmen zur Regelanwendung in Vorw¨
arts- und R¨
uckw¨
artsrichtung betrach-
tet wurden und ein Algorithmus zur Anwendung einer Regel auf Graphmuster vorgestellt wur-
de, k¨
onnen nun die Algorithmen eingef¨
uhrt werden, die den Nachweis induktiver Invarianten
durchf¨
uhren.
C.3. ¨
UBERPR ¨
UFUNG INDUKTIVER INVARIANTEN 183
01: GraphPattern applyRuleToPattern(GraphP attern [P , ˆ
P],
Rule r→[L, ˆ
mathcalL]R, isomorphism iso, Graph GΩ) begin
02: if ((Liso G)∧(6 ∃ ˆ
L∈ˆ
L, P ∈ˆ
P, iso0:
iso0−1|P=iso ∧(ˆ
P\(P0\iso(P))) iso0ˆ
L) then
03: //build the occurence o:= hon, oeiby extending iso
04: on:= λ x. if (x∈NL) then
05: ison
06: else
07: if (x∈NR\NL) then
08: id
09: fi
10: fi
11: oe:= λ x. if (x∈EL) then
12: isoe
13: else
14: if (x∈ER\EL) then
15: id
16: fi
17: fi
18: //build new Graph P’ with P|=⇒rP0
19: //first remove all elements that belong to L but not to R
20: P0:= P\o(L\R)
21: //add elements that belong to R but not to L
22: P0:= P0∪(R\L)
23: //all other elements remain unchanged
24: // ˆ
P0is build of adjusted ˆ
Pand ˆ
L
25: // ˆ
Phas to be converted by applying r to all graphs in ˆ
P
26: Set<Graph> ˆ
P0:= ∅
27: for ( ˆ
P∈ˆ
P) do
28: Graph ˆ
P0:= apply(ˆ
P , r0→LR, o)
29: ˆ
P0:= ˆ
P0∪ˆ
P0
30: end
31: //add converted ˆ
Lto ˆ
P0
32: ˆ
P0:= ˆ
P0∪convertNAC(r→[L, L]R, GΩ)
33: return [P0,ˆ
P0]
34: else
35: return [P , ˆ
P]
36: fi
37: end
Abbildung C.6: Algorithmus applyRuleToPattern, der die Anwendung einer Graphtransformati-
onsregel auf ein Graphmuster beschreibt
Dazu wird zun¨
achst die Menge aller Ergebnisgraphmuster mittels des Algorithmus buildTGP
gebildet (siehe Algorithmus in Abbildung C.7). Dabei k¨
onnen jedoch redundante Ergebnisgra-
phmuster entstehen, d.h. die vom Algorithmus zur¨
uck gelieferte Menge enth¨
alt Paare von Er-
gebnisgraphmustern, bei denen das eine Graphmuster ein Teilgraphmuster des zweiten ist. In
diesem Fall, reicht es das Teilgraphmuster zu behalten, das andere Graphmuster kann aus der
Menge entfernt werden Dies erfolgt mittels des Algorithmus reduceTGP in Abbildung C.8.
Der Algorithmus, der den Nachweis der induktiven Invarianten f¨
uhrt und diese beiden Algo-
rithmen aufruft, wurde bereits in Abschnitt 3.7.2 erl¨
autert.
184 ANHANG C. ALGORITHMEN
C.3.1 Bildung von Ergebnisgraphmustern
Derwichtigste Algorithmus beimNachweis induktiver Invarianten ist derAlgorithmus buildTGP,
der die Ergebnisgraphmuster erzeugt. Dieser Algorithmus wird als n¨
achstes vorgestellt. Die Men-
ge der zur¨
uckgelieferten Ergebnisgraphmuster, kann redundante Ergebnisgraphmuster enthalten.
Das bedeutet, die Menge enth¨
alt Paare von Graphmustern bei denen das eine ein Teilgraphmus-
ter des anderen ist. In diesem Fall reicht es aus, das Teilgraphmuster zu behalten, das andere
Graphmuster kann aus der Menge entfernt werden. Diese Reduktion der Menge der Ergebnis-
graphmuster kann mit dem Algorithmus reduceTGP aus Abbildung C.8 erfolgen.
Der Algorithmus buildTGP
Der Algorithmus buildTGP erzeugt f¨
ur eine Graphtransformationsregel [L,ˆ
L]→rRund ein ver-
botenes Graphmuster [P,ˆ
P]alle m¨
oglichen Ergebnisgraphmuster.
Die Menge der Ergebnisgraphmuster setzt sich nach Definition 35 aus zwei Teilmengen
zusammen. Die erste beschreibt den Fall, dass Elemente, die durch die Regel erzeugt werden
die Anwendungsbedingung des verbotenen Graphmusters vervollst¨
andigt. In diesem Fall gibt es
mindestens ein Element, das Teil der rechten, aber nicht der linken Regelseite ist und das durch
einen Isomorphismus auf ein Element der Anwendungsbedingung des verbotenen Graphmuster
abgebildet werden kann. Die zweite Teilmenge besteht aus den Ergebnisgraphmustern, bei denen
die Regel mindestens ein Element entfernt, das Teil eines Graphen der negativen Anwendungs-
bedingung des verbotenen Graphmusters ist. In diesem Fall gibt es mindestens einen Knoten,
der bei der Regelanwendung erhalten bleibt und somit Teil der linken und rechten Regelseite
ist. Zus¨
atzlich muss dieses Element durch einen Isomorphismus auf ein Element des verbotenen
Graphmusters abbildet.
Die Bildung der ersten Teilmenge wird in den Zeilen 08 bis 37 beschrieben. In der Zeile
08 wird die Menge aller Teilgraphen der linken Regelseite gebildet. Dabei m¨
ussen diese Teil-
graphen jedoch mindestens ein Element enthalten, das nicht auch zur rechten Regelseite geh¨
ort.
Anschließend (Zeile 09) wird die Menge aller Teilgraphen der Anwendungsbedingung des ver-
botenen Graphmusters gebildet. F¨
ur jedes Paar, bestehend aus einem Teilgraphen der linken Re-
gelseite und einem Teilgraphen der Anwendungsbedingung des verbotenen Graphmusters, wird
bestimmt, ob es einen Teilgraphisomorphismus gibt, der den Teilgraphen des verbotenen Gra-
phmusters auf den Teilgraphen der linken Regelseite abbildet (Zeile 13). Ist dies der Fall (Zeile
14), so wird dieser Isomorphismus verwendet, um die Anwendungsbedingung des Ergebnisgra-
phmusters aus der linken Regelseite und der Anwendungsbedingung des verbotenen Graphmus-
ters zu bilden. Anschließend wird die Menge aller Isomorphismen bestimmt, die den gefundenen
Isomorphismus erweitern (Zeile 17). Diese Isomorphismen werden dazu verwendet, um die ne-
gativen Anwendungsbedingungen des Ergebnisgraphmusters zu bilden. Dazu werden zum einen
alle Graphen der negativen Anwendungsbedingung der linken Regelseite um den Anwendungs-
graphen des verbotenen Graphmusters erweitert (Zeile 16 bis 21). Und zum anderen werden
alle Graphen der negativen Anwendungsbedingung des verbotenen Graphmusters um die rechte
Regelseite erweitert (Zeile 24 bis 30). In Zeile 31 wird die Menge der Graphen der negativen
Anwendungsbedingung minimiert, bevor in Zeile 33 das Ergebnisgraphmuster erzeugt und in
Zeile 34 zur Menge der Ergebnisgraphmuster hinzugef¨
ugt.
C.3. ¨
UBERPR ¨
UFUNG INDUKTIVER INVARIANTEN 185
Die Bildung der zweiten Teilmenge ist Inhalt der Zeilen 38 bis 58. In Zeile 41 wird zun¨
achst
die Menge ∆LS−1neu gebildet. Dabei besteht LS−1aus allen Teilgraphen der linken Regelseite,
bei denen es mindestens ein Element gibt, das auch zur rechten Regelseite geh¨
ort. Dann wird
die Menge aller Teilgraphen aller Graphen der negativen Anwendungsbedingung des verbotenen
Graphmusters gebildet (Zeile 41). F¨
ur jedes Paar, bestehend aus einem Graphen der linken Re-
gelseite und des verbotenen Graphmusters, wird bestimmt, ob es einen Isomorphismus gibt, der
den Teilgraphen des verbotenen Graphmuster auf den Teilgraphen der linken Regelseite abbildet
(Zeile 44). Ist dies der Fall, so wird dieser Isomorphismus als erstes dazu verwendet, um die
Anwendungsbedingung des Ergebnisgraphmusters zu bilden (Zeile 45). Als n¨
achstes wird die
Menge der Isomorphismen bestimmt, die den Isomorphismus erweitern. Mittels dieser Menge
der Isomorphismen werden dann die Graphen der negativen Anwendungsbedingungen gebildet,
indem die Anwendungsbedingung der linken Regelseite um die Elemente der Graphen der ne-
gativen Anwendungsbedingung des verbotenen Graphmusters erweitert wird (Zeilen 46 bis 51).
Diese Menge wird in Zeile 52 minimiert, in Zeile 53 wird das Ergebnisgraphmuster gebildet und
in Zeile 54 zur Menge der Ergebnisgraphmuster hinzugef¨
ugt.
Die Menge aller Ergebnisgraphmuster wird dann zur¨
uckgeliefert (Zeile 59).
Der Algorithmus reduceTGP
Der zuvor vorgestellte Algorithmus buildTGP bestimmt f¨
ur eine Regel und einem verbotenen
Graphmuster alle m¨
oglichen Ergebnisgraphmuster. Dabei entstehen jedoch redundante Gra-
phmuster, d.h. es gibt Paare von Graphmustern, bei denen das eine Muster ein Teilgraphmuster
des zweiten ist. Dies ist zwar kein Fehler, hat jedoch Auswirkungen auf den Verifikationsalgo-
rithmus, da dieser f¨
ur jedes Ergebnisgraphmuster ¨
uberpr¨
ufen muss, ob es durch die Anwendung
der Regel auf ein korrektes Startgraphmuster erzeugt worden sein kann. Deshalb wird nun ein
Algorithmus vorgestellt, mit dem die Anzahl der Ergebnisgraphmuster minimiert werden kann.
Der Algorithmus pr¨
uft f¨
ur jedes Paar der Ergebnisgraphmuster aus der ¨
ubergebenen Menge,
ob das Ergebnisgraphmuster tgp ein Teilgraphmuster von tgp0ist (Zeilen 05 bis 18). Ist dies der
Fall wird tgp0aus der Menge der Ergebnisgraphmuster entfernt, Zeile 12. Die minimierte Menge
wird dann zur¨
uck gegeben (Zeile 19).
186 ANHANG C. ALGORITHMEN
01: Set<GraphPattern> buildTGP(Rule [L−1,ˆ
L−1]→r−1R−1, GraphP attern[P , ˆ
P])
02: begin:
03: Set<GraphPattern> T GP := ∅
04: Graph T GP
05: Graph ˆ
T GP
06: GraphPattern tgp
07: //(L−1\R−1)∩P6=∅
08: Set<Graph> LS−1:= {L0|(L0≤L−1)∧((L−1\R−1)6=∅)}
09: Set<Graph> P S := {P0|P0≤P}
10: forall (L−1∈LS−1)do
11: forall (P0∈P S)do
12: if (∃iso :L−1=iso P0) then
13: T GP =L−1∪iso(P)
14: //calculate the NAC
15: //extend all ˆ
L−1by P
16: ISO0:= {iso0|iso0|P0=iso}
17: forall (iso0∈ ISO0) do
18: forall (ˆ
L−1∈ˆ
L−1) do
19: ˆ
T GP := ˆ
L−1∪iso0(P)
20: ˆ
T GP := ˆ
T GP ∪ ˆ
T GP
21: end
22: end
23: //extend all ˆ
Pby L−1
24: forall (iso0∈ ISO0) do
25: forall ( ˆ
P∈ˆ
P) do
26: ˆ
T GP := L−1∪ˆ
P
27: ˆ
T GP := ˆ
T GP ∪ ˆ
T GP
28: end
29: end
30: ˆ
T GP := minimizeNAC(ˆ
T GP)
31: tgp := [T GP , ˆ
T GP]
32: T GP := T GP ∪ tgp
33: ˆ
T GP := ∅
34: fi
35: end
36: end
37: //L−1∩R−1∩ˆ
P6=∅
38: ˆ
T GP := ∅
39: LS−1:= {L−1|L-1 ≤(L−1∩R−1)}
40: ˆ
P S := {ˆ
P0|(ˆ
P0≤ˆ
P)}
41: forall (L0∈LS−1) do
42: forall ( ˆ
P0∈ˆ
P S) do
43: if (∃iso :L−1=iso ˆ
P0) then
44: T GP := L−1∪iso(P)
45: //calculate the NAC
46: ISO0:= {iso0|iso0|ˆ
P0=iso}
47: forall (iso0∈ˆ
ISO0) do
48: forall ( ˆ
P∈ˆ
P) do
49: ˆ
T GP := L−1∪iso0(ˆ
P)
50: ˆ
T GP := ˆ
T GP ∪ ˆ
T GP
51: end
51: end
52: ˆ
T GP := minimizeNAC(ˆ
T GP)
53: tgp := [T GP , ˆ
T GP]
54: T GP := T GP ∪ tgp
55: ˆ
T GP := ∅
56: fi
57: end
58: end
59: return T GP
60: end
Abbildung C.7: Algorithmus buildTGP zur Bildung der Ergebnisgraphmuster
C.3. ¨
UBERPR ¨
UFUNG INDUKTIVER INVARIANTEN 187
01: Set<GraphPattern> reduceTGP(GraphP attern T GP)
02: begin:
03: Set<GraphPattern> reducedSet := T GP
04: Set<GraphPattern> tmpSet
05: forall (tgp := [T GP , ˆ
T GP]∈ T GP) do
06: tmpSet := T GP \ tgp
07: forall (tgp0:= [T GP 0,ˆ
T GP0]∈tmpSet) do
08: if (∃iso :T GP iso T GP 0) then
09: forall ( ˆ
T GP ∈ˆ
T GP) do
10: if (6 ∃ iso0:iso0|T GP =iso ∧ˆ
T GP iso0T GP 0) then
11: if (∃ˆ
T GP 0∈ˆ
T GP0∧ ∃ iso00 :
iso00−1|T GP =iso ∧(ˆ
T GP 0\(T GP 0\iso(T GP ))) iso00 ˆ
T GP ) then
12: reducedSet := reducedSet \tgp0
13: fi
14: fi
15: end
16: fi
17: end
18: end
19: return reducedSet
20: end
Abbildung C.8: Algorithmus reduceTGP zur Reduzierung der Menge der Ergebnisgraphmuster
Index
Agent, 27
Community, 27
direkte Transformation, 65
von Graphmustern, 84
Double Pushout Ansatz, 76
Double Pushoutiso Ansatz, 78
Echtzeit, 1
harte Echtzeitbedingung, 10
Ergebnisgraphmuster, 94
Erreichbarkeitsanalyse, 42
Fujaba, 113
Real-Time Tool Suite, 7, 113
Tool Suite, 113
Gegenbeispiel, 7, 49, 88
Darstellung in Fujaba, 125
Darstellung in Groove, 119
Graph, 5, 41, 58
Anwendungsgraph, 41, 65
beschrifteter Graph, 59
beschriftungskompatible Graphen, 61
identische Graphen, 60
Pfad, 62
Schnitt von Graphen, 61
Subtraktion von Graphen, 62
Teilgraph, 60
echter Teilgraph, 61
Typgraph, 73
typkonformer Graph, 74
Vereinigung von Graphen, 61
Zielgraph, 65
Grapheigenschaftsformel, 85
Graphhomomorphismus, 63
Graphisomorphismus, 64
Teilgraphisomorphismus, 64
Graphmuster, 6, 41, 70
einfaches Graphmuster, 70
Ergebnisgraphmuster, 7, 48, 89
gefordertes Graphmuster, 42, 85
Startgraphmuster, 7, 48, 89, 97
Teilgraphmuster, 70
verbotenes Graphmuster, 6, 42, 85
Zeuge, 87
Graphtransformationsregel, 5, 41, 64
Anwendungsbedingung, 41, 64
erweiterte Graphtransformationsregel,
79
invertierte Graphtransformationsregel,
82
linke Regelseite, 41, 64
Nachbedingung, 41
Nchbedingung, 65
negative Anwendungsbedingung, 50,
67, 109
minimale negative Anwendungsbe-
dingung, 68
rechte Regelseite, 41, 65
Typkonformit¨
at, 74
Vorbedingung, 41, 64
Graphtransformationssystem, 41, 69
erreichbare Zust¨
ande, 69
typisiertes Graphtransformationssys-
tem, 80
typkonformes Graphtransformations-
system, 80
unendliches Graphtransformationssys-
tem, 69
Graphtransitionssystem, 119
188
INDEX 189
Identifikationsbedingung, 75
starke Identifikationsbedingung, 75
Informationsverarbeitung, 10
Invariante
induktive Invariante, iii, 7, 44, 86
operationale Invariante, 44, 86
Komponente, 4, 11
ben¨
otigte Schnittstelle, 12
bereitgestellte Schnittstelle, 12
hybride Komponente, 22
Konnektor, 13
Port, 12
Verfeinerung, 19
Softwarekomponente, 11
UML-Komponentendiagramm, 12
kompositionale Modellierung, 2, 26
Koordinationsmuster, 4, 15
Konnektor, 15
Musterconstraint, 15
Rolle, 15
Rolleninvariante, 15
kritische Situation, 28
Kultur, 27
Regel, 27
Absichtserkl¨
arung, 27
Instanzierungsregel, 27
Verhaltensregel, 27
Rolle, 27
Subkultur, 27
lose Kante, 75
h¨
angende Kante, 75
Lose-Kanten-Bedingung, 75
Match, 65
Mechatronic UML, 4
mechatronisches System, iii, 1
Ontologie, 13
Operator-Controller-Modul, 3, 10
Controller, 10, 11
kognitiver Operator, 11
motorischer Kreis, 10
Operator, 11
reflektorischer Operator, 10
Real-Time Statecharts, 17
sichere Kommunikation, 14
Sicherheitseigenschaft, 2, 87
sicherheitskritisches System, iii, 1
Single Pushout Ansatz, 76
Story Diagramm, 22
Story Pattern, 22, 106
negative Anwendungsbedingung, 24,
109
UML-Aktivit¨
atendiagramm, 22
UML-Klassendiagramm, 13
UML-Objektdiagramm, 23
Unfall, 28
Zustandsautomat, 17
Protokoll-Zustandsautomat, 17
Verhaltens-Zustandsautomat, 17
