Institut fu¨r 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 Anspru¨che an die Leistungsfa¨higkeit und Sicherheit technischer Systeme, wie Autos oder Flugzeuge, steigt stetig. Um den wachsenden Anforderungen gerecht zu werden ist es notwendig, dass maschinenbauliche, elektrotechnische und Softwarekomponenten zusammenarbeiten. Ein System, dass aus solchen Komponenten zusammengesetzt ist, wird als mechatronisches System bezeichnet. Ein solches System kann u¨ber Sensoren Informationen u¨ber seine Umwelt sammeln. Es hat aber auch die Mo¨glichkeit, mit anderen mechatronischen Systemen zu kommunizieren oder zu kooperieren. Die Software, die fu¨r 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 komplex ist und zumeist einen unendlichen Zustandsraum hat, reicht Testen alleine nicht aus, um die Korrektheit der Software nachzuweisen. Automatische Ansa¨tze zur formalen Verifikation wie Model Checking ko¨nnen nur Systeme mit einem endlichen Zustandsraum verifizieren. Theorembeweiser, die einen Korrektheitsnachweis auch fu¨r solche Systeme fu¨hren ko¨nnen, beno¨tigen 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 formal verifizieren kann. Der Ansatz baut auf den existierenden Ansatz der M ECHATRONIC UML auf. Er nutzt dabei die Tatsache aus, dass ein Systemzustand in der M ECHATRONIC UML, charakterisiert durch die mechatronischen Systeme und deren laufende Interaktion, als Graph dargestellt werden kann. Zustandsu¨berga¨nge wie beispielsweise das Starten oder Beenden einer Interaktion ko¨nnen dann als Graphtransformationsregel beschrieben werden. Zudem ko¨nnen die hier betrachteten strukturellen Sicherheitseigenschaften lokal nachgewiesen werden. Fu¨r eine Menge von Graphtransformationsregeln und eine Menge von Sicherheitseigenschaften wird dann gezeigt, dass die Regeln niemals einen korrekten Graphen, also einen Zustand, der alle Sicherheitseigenschaften erfu¨llt, in einen inkorrekten Graphen u¨berfu¨hren ko¨nnen. Die Erreichbarkeit der Graphen wird dabei jedoch nicht beru¨cksichtigt. Somit wird bei der Verifikation nachgewiesen, dass die Sicherheitseigenschaften induktive Invarianten des Systems darstellen. iii

iv

Danke Bevor ich meine Forschungsergebnisse der letzten Jahre pra¨sentiere, mo¨chte 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 Scha¨fer. Bei Wilhelm mo¨chte ich mich dafu¨r bedanken, dass er mich 2002 zur Promotion ermutigte, mir die Chance gegeben hat mich in seiner Arbeitsgruppe mit spannenden Themen der Informatik zu bescha¨ftigen und mir viele wertvolle Tipps gegeben hat. An dieser Stelle mo¨chte ich mich auch bei Prof. Gregor Engels und Prof. Ju¨rgen Gausemeier dafu¨r bedanken, dass sie meine Promotion betreut haben. Bei meinem Kollegen Holger Giese mo¨chte ich mich fu¨r viele fruchtbare Diskussionen, Anregungen und einen riesigen Berg "spannender Bettlektu¨re"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 Ju¨rgen Maniera, der nie die Geduld verloren hat und am Ende jedes noch so seltsame technische Ra¨tsel lo¨sen konnte. Bu¨rokratische Probleme sind wa¨hrend meiner Promotionszeit in Paderborn dank Jutta Haupt nie aufgetreten. Mein Dank gilt Jutta aber vor allem fu¨r die freundschaftliche Unterstu¨tzung und die Dienstag-Mittagessen. Jung"Ws, esro solche Kollegen hat braucht schlimm wart ihr gar nicht. keine Feinde mehr"(Sprichwort Im Gegenteil, ich mo¨chte mich in an der Arbeitsgruppe). dieser Stelle bei allen meinen Kollegen- Bjo¨rn Axenath, Sven Burmester, Matthias Gehrke, Holger Giese, Stefan Henkler, Martin Hirsch, Florian Klein, Ekkart Kindler, Jo¨rg Niere, Ahmet Mehic, Matthias Meyer, Vladimir Rubin, Matthias Tichy, Robert Wagner, Jo¨rg Wadsack und Lothar Wendehals- fu¨r die gute Zusammenarbeit, gemeinsame Kinoabende und eine scho¨ne Promotionszeit bedanken. Lothar mo¨chte ich daru¨ber hinaus fu¨r drei freundschaftliche Jahre im gemeinsamen Bu¨ro danken. Matthias Gehrke, Martin Hirsch, Florian Klein, Lothar Wendehals, Matthias Meyer, Matthias Tichy, Robert Wagner und Reiko Heckel mo¨chte ich dafu¨r danken, dass sie ein oder mehrere Kapitel meiner Arbeit, zum Teil auch mehrfach, Korrektur gelesen und mir gute Tipps zur Verbesserung gegeben haben. Bei Basil Becker und Victor Neumann mo¨chte ich mich dafu¨r bedanken, dass sie im Rahmen ihrer Studienarbeiten und wa¨hrend ihrer Ta¨tigkeiten als studentische Hilfskra¨fte 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 mo¨chte ich mich fu¨r die gute Freundschaft bedanken und dafu¨r, dass ich auf dem Ru¨cken ihrer Pferde nicht nur Glu¨ck und Erholung sondern auch so manch eine Problemlo¨sung finden konnte. Meiner besten Freundin Silke Kaspari mo¨chte ich fu¨r die vergnu¨glichen gemeinsamen Stunden und die vielen aufmunternden Emails bedanken. Außerdem gilt Silke mein Dank, da sie viele Stunden dafu¨r aufgebracht hat, um die Rechtschreibung und Zeichensetzung in dieser Arbeit zu korrigieren. Bei meinen Eltern mo¨chte ich mich dafu¨r bedanken, dass sie immer fu¨r mich da waren, mich unterstu¨tzt haben(auch dann, wenn ihnen meine Entscheidungen mal nicht gefallen haben) und sie sich mit mir und fu¨r mich u¨ber Erfolge gefreut haben.

Inhaltsverzeichnis 1 Einleitung 1.1 Motivation...................................... 1.2 Anwendungsbeispiel................................ 1.3 Ziel und Lo¨sungsansatz............................... 1.4 Aufbau der Arbeit.................................. 1 1 2 3 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 Die Idee....................................... 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 Das Systemmodell................................. 72 3.4.1 Graphen zur Zustandsbeschreibung.................... 72 3.4.2 Graphtransformationen zur Beschreibung von Zustandsa¨nderungen... 75 3.4.3 Typisierte Graphtransformationssysteme.................. 80 3.5 Erweiterte Graphtransformationen......................... 80 3.5.1 Ru¨ckwa¨rtsanwendung von Graphtransformationsregeln.......... 81 3.5.2 Transformationen von Graphmustern................... 84 3.6 Systemeigenschaften und Invarianten........................ 85 3.6.1 Sicherheitseigenschaften.......................... 87 3.6.2 Beschra¨nkung auf Gegenbeispiele..................... 88 3.7 Nachweis von induktiven Invarianten........................ 88 3.7.1 Theoretische Ergebnisse.......................... 88 3.7.2 Der Algorithmus.............................. 99 3.7.3 Aufwandsabscha¨tzung........................... 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 Unfa¨lle......................... 110 4.4 Zusammenfassung................................. 110 5 Werkzeugunterstu¨ tzung 113 5.1 Werkzeugunterstu¨tzung des Modellierungs- und Verifikationsprozesses...... 114 5.1.1 Modellierung................................ 114 5.1.2 Verifikation................................. 114 5.1.3 Codegenerierung.............................. 115 5.2 Das Groove-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 Verbotene Graphmuster............................... 161 A.2.1 Sicherheitseigenschaften.......................... 161 A.2.2 Die verbotenen Graphmuster der CoordinatedMovement -Kultur..... 163 A.2.3 Kardinalita¨ten................................ 164 A.2.4 Gro¨ßen der verbotenen Graphmuster.................... 166 B Theoretische Ergebnisse und Beweisskizzen 169 B.1 Graphmuster.................................... 169 B.2 Das Systemmodell................................. 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 Ru¨ckwa¨rtsanwendung von Graphtransformationsregeln.......... 180 C.2.2 Anwendung von Regeln auf Graphmuster................. 182 C.3 U¨ berpru¨fung induktiver Invarianten........................ 182 C.3.1 Bildung von Ergebnisgraphmustern.................... 184

x INHALTSVERZEICHNIS

Abbildungsverzeichnis 1.1 Zwei hintereinander herfahrende Shuttle s..................... 3 2.1 Die Architektur des Operator-Controller-Moduls. Quelle:[Ge05]......... 2.2 OCM als Komponente. Quelle:[Ge05]....................... 2.3 Definition des Komponententyps Shuttle ...................... 2.4 Zwei Instanzen der Shuttle -Komponente...................... 2.5 Klassendiagramm, das die Ontologie der Shuttle -Komponente beschreibt.... 2.6 Das DistanceCoordination -Koordinationsmuster.................. 2.7 Instanz des DistanceCoordination -Musters..................... 2.8 Real-Time Statechart, das das Verhalten der Rolle rearRole beschreibt...... 2.9 Verhalten der Shuttle -Komponente......................... 2.10 Story Pattern moveSimple , das die Bewegung eines Shuttle s von einem Track auf den na¨chsten beschreibt............................... 2.11 Beispiel fu¨r ein Objektdiagramm. Die Abbildung des Story Patterns aus Abbildung 2.10 auf dieses Objektdiagramm ist gru¨n hinterlegt............. 2.12 Objektdiagramm aus Abbildung 2.11 nachdem das Story Pattern moveSimple darauf angewendet wurde.............................. 2.13 Story Pattern moveSimpleNAC , das das Story Pattern moveSimple um eine negative Anwendungsbedingung erweitert...................... 2.14 Modell bestehend aus je drei Komponenten und Koordinationsmustern...... 2.15 Beispiel fu¨r eine Kulturhierarchie......................... 2.16 Ontologie erweitert um konzeptionelle Elemente................. 2.17 Beispiel fu¨r die Implementierung der Verhaltensregel moveNext ......... 2.18 Verbotenes Story Pattern collision .......................... 2.19 Instanzierungsregel createDC ............................ 2.20 Verhaltensregel moveDC .............................. 2.21 Verbotenes Story Pattern impendingCollision .................... 11 12 12 13 13 16 17 19 21 23 24 24 25 26 29 29 30 30 31 32 32 3.1 Die Graphtransformationsregel moveSimple .................... 41 3.2 Verbotenes Graphmuster impendingCollisionSimplified .............. 42 3.3 Beispiel fu¨r die Korrektheit bzw. Inkorrektheit von Graphen........... 43 3.4 Die Regel moveSimple transformiert einen inkorrekten Graphen in einen anderen inkorrekten Graphen................................ 46 xi

xii ABBILDUNGSVERZEICHNIS 3.5 Die Regel moveSimple transformiert einen korrekten Graphen in einen inkorrekten Graphen..................................... 47 3.6 Start- und Ergebnisgraphmuster fu¨r die Regel moveSimple und das verbotene Graphmuster impendingCollisionSimplified , wobei das Startgraphmuster einem inkorrekten Graphmuster entspricht........................ 49 3.7 Start- und Ergebnisgraphmuster fu¨r 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 , sodass sie ru¨ckwa¨rts angewendet werden kann.................... 53 3.10 Verbotenes Graphmuster impendingCollision mit negativer Anwendungsbedingung 53 3.11 Graphen, die in Bezug auf das verbotene Graphmuster impendingCollision inkorrekt bzw. korrekt sind................................ 54 3.12 Regel deleteDCSwitch , die eine Instanz des DistanceCoordination -Musters lo¨scht 55 3.13 Ergebnisgraphmuster mit negativer Anwendungsbedingung............ 57 3.14 Startgraphmuster mit negativer Anwendungsbedingung.............. 58 3.15 Beispiel fu¨r einen beschrifteten Graphen...................... 60 3.16 Graph G , fu¨r den ein Graphhomomorphismus in Graph G aus Abbildung 3.15 bestimmt werden soll................................ 63 3.17 Beispiel fu¨r eine Graphtransformationsregel.................... 65 3.18 Zwei Graphen G, G , fu¨r die ein Auftreten der Regel aus Abbildung 3.17 existiert, sodass o( L) G und o( R) G gilt........................ 66 3.19 Beispiel fu¨r einen Graphen, bei dem die Anwendung von moveSimple zu einer kritischen Situation fu¨hren kann.......................... 67 3.20 Regel moveSimpleNAC , die die Regel moveSimple um negative Anwendungsbedingungen erweitert............................... 68 3.21 Beispiel fu¨r ein Graphmuster und ein Teilgraphmuster............... 72 3.22 Einfaches Klassendiagramm und der dazugeho¨rige Typgraph........... 73 3.23 Regel deletePublication und ihre Anwendung auf einen Graphen im Single bzw. Double Pushout Ansatz............................ 77 3.24 Graphtransformationsregel deletePublication , die so angepasst wurde, dass ihre Anwendung im DPO iso keine losen Kanten erzeugen kann............ 79 3.25 Regel moveSimpleNAC ............................... 82 3.26 Regel moveSimpleNAC - 1 stellt die inverse Regel moveSimpleNAC dar...... 83 3.27 Sicherheitseigenschaft impendingCollision ..................... 87 3.28 Regel moveSimpleNAC , deren Korrektheit im Bezug auf das verbotene Graphmuster impendingCollision u¨berpru¨ft werden soll................ 92 3.29 Ein mo¨gliches Ergebnisgraphmuster fu¨r die Regel moveSimpleNAC und das verbotene Graphmuster impendingCollision ...................... 93 3.30 Die Regel deleteDCSwitch ............................. 95 3.31 Ein mo¨gliches Ergebnisgraphmuster fu¨r die Regel deleteDCSwitch und das verbotene Muster impendingCollision ......................... 96

ABBILDUNGSVERZEICHNIS xiii 3.32 Schematische Darstellung der Erweiterung eines Graphen L^ - 1  L ^ - 1 um Elemente aus P ..................................... 3.33 Schematische Darstellung der Erweiterung eines Graphen P^ P ^ um Elemente aus L - 1 ....................................... 3.34 Schematische Darstellung der Erweiterung eines Graphen P^ P ^ um Elemente aus L - 1 ....................................... 97 97 97 3.35 Startgraphmuster, das aus der Anwendung der inversen Regel moveSimpleNAC - 1 auf das Ergebnisgraphmuster aus Abbildung 3.29 resultiert........................................ 98 3.36 Algorithmus check ................................. 100 4.1 Klassendiagramm und entsprechender Typgraph.................. 106 4.2 Objektdiagramm und entsprechender typisierter Graph.............. 107 4.3 Vorwa¨rtsbewegung, moveSimple , eines Shuttle s als Story Pattern und als Graphtransformationsregel................................ 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 a¨quivalentes verbotenes Graphmuster................................ 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 moveSimple das verbotene Graphmuster collision erzeugen kann............ 126 5.8 Beno¨tigte 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 linken Regelseite erweitert, sodass die Regelanwendung die Lose-Kanten-Bedingung erfu¨llt 178 C.2 Algorithmus minimizeNAC zur Minimierung von negativen Anwendungsbedingungen........................................ 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 Anwendungsbedingungen........................................ 181 C.5 Algorithmus reverse zur Invertierung von Graphtransformationsregeln...... 182 C.6 Algorithmus applyRuleToPattern , der die Anwendung einer Graphtransformationsregel 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 Gro¨ß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 gro¨ßere Rolle im ta¨glichen Leben. Beispiele fu¨r solche Systeme reichen von der Kaffeemaschine bis hin zu Autos und Flugzeugen oder den an der Universita¨t Paderborn entwickelten autonom fahrenden Shuttle s(siehe Abschnitt 1.2). Dabei steigen die Anspru¨che an die Leistungsfa¨higkeit, aber auch an die Sicherheit dieser Systeme, stetig. Zu den Anspru¨chen an die Leistungsfa¨higkeit geho¨rt, dass die Systeme zunehmend autonom agieren ko¨nnen mu¨ssen. In Autos wird dies durch Fahrerassistenzsysteme realisiert und im Flugzeug durch Autopiloten. Um den wachsenden Anspru¨chen gerecht zu werden, ist es erforderlich, dass maschinenbauliche, elektrotechnische und Softwarekomponenten zusammenarbeiten. Ein System, das aus solchen Komponenten zusammengesetzt ist, wird als mechatronisches System bezeichnet. U¨ ber Sensoren erha¨lt ein mechatronisches System Informationen u¨ber seine Umwelt. Bei Autos oder Shuttle s liefern die Sensoren beispielsweise Informationen u¨ber die Beschaffenheit der Strecke. Weitere Sensoren werden dazu eingesetzt, andere Verkehrsteilnehmer oder Hindernisse zu erkennen. Die durch die Sensoren erfassten Daten werden dann an Softwarekomponenten weitergeleitet. Die Softwarekomponenten bestimmen anhand dieser Daten, welche Aktionen durchzufu¨hren sind und steuern die entsprechenden Aktoren, die die Aktionen wie Bremsen oder Beschleunigen durchfu¨hren. Neben dem Informationsgewinn u¨ber Sensoren, ko¨nnen verschiedene mechatronische Systeme aber auch durch den Austausch von Daten u¨ber 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 Systems ein sicherheitskritisches System dar. Eine Fehlfunktion der Software, z.B. U¨ berschreiten 1

2 KAPITEL 1. EINLEITUNG von Fristen oder fehlerhafte Berechnungen, resultiert im schlimmsten Fall in einem Unfall, der zu großen finanziellen Scha¨den fu¨hren oder Menschenleben kosten kann. Die Komplexita¨t der Software erfordert einen Entwicklungsansatz, der es erlaubt, ein abstraktes Modell der Software kompositional zu entwerfen, d.h. statt das System als Ganzes zu modellieren, muss es mo¨glich sein das System in Teile zu untergliedern, jedes Teil einzeln zu modellieren und das Modell des Gesamtsystems dann aus diesen Teilen zusammen zufu¨gen. Aufgrund des sicherheitskritischen Charakters muss es zudem mo¨glich sein, fu¨r das Modell bestimmte Sicherheitseigenschaften nachzuweisen. Dabei stellt eine Sicherheitseigenschaft eine Eigenschaft dar, die in jedem erreichbaren Systemzustand erfu¨llt ist. Der Nachweis, dass das Modell der Software eines mechatronischen Systems eine Menge von Sicherheitseigenschaften erfu¨llt, gestaltet sich in der hier betrachteten Doma¨ne als sehr schwierig. Zwar stellen die Modelle eine Abstraktion der spezifizierten Systeme dar, jedoch sind auch sie im Allgemeinen zu komplex, um vollsta¨ndig getestet zu werden. Vollautomatische Verifikationstechniken wie Model Checking machen Aussagen u¨ber alle erreichbaren Zusta¨nde eines Modells. Allerdings skalieren solche Verfahren nicht fu¨r Systeme mit beliebig großem bzw. unendlich großem Zustandsraum. Die Software eines mechatronischen Systems kann jedoch einen sehr großen oder unendlich großen Zustandsraum besitzen. Verfahren wie Theorembeweise ko¨nnen zwar auch zur Verifikation von solchen Systemen eingesetzt werden, sind jedoch nicht vollautomatisch 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 (eSmFpBla)r6is1c4h-d"iSeeSlobfsttwopatriemfiu¨erre S n h d u e tt S le yssetenmtweicdkeeslMt, wasocbheiinjeendbeasu S s" h 1 u . t I tl n e neeirnhamlbecdhiaetsreosnSisFcBhesswSiyrdsteexmdarstellt. Die Shuttle s sind Teil eines Transportsystem, dass die Vorteile von individuellen und o¨ffentlichen Verkehrsmitteln verbindet. So sollen die Shuttle s nicht nach fest vorgegebenen Fahrpla¨nen fahren, sondern Personen und Gu¨ter auf Anforderung vom Start- zum Zielort bringen. Andererseits sollen die Shuttle s aber auch einen geringeren Energiebedarf haben als zum Beispiel Autos, sodass sie umweltfreundlicher als der Individualverkehr sind. Um dieses Ziel zu erreichen, fahren die Shuttle s autonom und ko¨nnen selbsta¨ndig und dezentral Entscheidungen treffen. Die Shuttle s fahren auf Schienen. Ein Satellitensystem unterstu¨tzt die Shuttle s bei der Positionsberechnung. Sowohl die Kommunikation zwischen zwei Shuttle s, als auch die Kommunikation zwischen einem Shuttle und den Bahnho¨fen, auf denen die Shuttle s angefordert werden ko¨nnen, erfolgt u¨ber ein Funknetz. In Abbildung 2.14 ist ein solches System graphisch dargestellt. Der Antrieb der Shuttle s erfolgt, a¨hnlich wie bei der Magnetschwebebahn, u¨ber einen elektromagnetischen Linearmotor. Die dazu notwendigen Statorwellen werden von zwischen den Schienen eingelassenen Statoren erzeugt. 1 www.sfb614.de

1.3. ZIEL UND LO¨ SUNGSANSATZ 3 Abbildung 1.1: Zwei hintereinander herfahrende Shuttle s Um den Energieverbrauch der Shuttle s zu minimieren, ko¨nnen sie Konvois bilden. Diese Konvois sind kontaktfrei, sodass das Bilden der Konvois wa¨hrend der Fahrt stattfinden kann. Zur Bildung von Konvois wird der Abstand zwischen zwei Shuttle s minimiert. Je kleiner der Abstand ist, desto mehr Energie kann von den Shuttle s eingespart werden, da der Luftwiderstand verringert wird. Die Abstandshaltung erfolgt zum einen u¨ber einen Abstandssensor, der den Abstand zum vorher fahrenden Shuttle misst und zum anderen dadurch, dass die Shuttle s u¨ber das Funknetz 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 fru¨hzeitig erfa¨hrt, welche anderen Shuttle s sich in seiner Na¨he befinden, ist das System in u¨berlappende kritische Abschnitte, ControlledArea , unterteilt. Jeder dieser kritischen Abschnitte wird von einer Abschnittskontrolle, der BaseStation , u¨berwacht. Bevor ein Shuttle in einen kritischen Abschnitt einfahren darf, muss es sich bei der entsprechenden Abschnittskontrolle anmelden. Nach der Anmeldung muss das Shuttle in regelma¨ßigen Absta¨nden seine Position an die Abschnittskontrolle senden. Diese wiederum sendet die Daten an alle anderen bei ihr gemeldeten Shuttle s. Fa¨llt ein Shuttle aus und sendet seine Positionsdaten nicht, so warnt die Abschnittskontrolle die anderen Shuttle s. Die Abschnittskontrolle hat also die Aufgabe, den Shuttle s mitzuteilen, welche anderen Shuttle s in der Na¨he sind und vor Gefahren durch defekte Shuttle s zu warnen. Die Abschnittskontrolle kann die einzelnen Shuttle s jedoch nicht koordinieren; dies erfolgt ausschließlich durch die Shuttle s. 1.3 Ziel und Lo¨sungsansatz Die Informationsverarbeitung eines mechatronischen Systems kann als Operator-ControllerModul (OCM) aufgefasst werden[OHG04, HOG04, Ge05]. Ein solches Modul ist in die drei Ebenen Controller , reflektorischer Operator und kognitiver Operator unterteilt. Wa¨hrend der Controller 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 koordinieren. Die Aufgabe des kognitiven Operator besteht darin Wissen u¨ber die Umwelt und das OCM selber zu sammeln und dazu zu nutzen, um das Verhalten des OCM besser an die gegebenen Anforderungen anzupassen.

4 KAPITEL 1. EINLEITUNG Da die Software des reflektorischen Operators fu¨r 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 fu¨r die Software des reflektorischen Operators und hier besonders fu¨r die Koordination zwischen zwei OCMs. Der Ansatz soll eine automatische und kompositionale Verifikation der Software, modelliert durch Graphtransformationssysteme, auch dann ermo¨glicht, wenn diese einen unendlichen Zustandsraum besitzen und ihr Initialzustand zum Zeitpunkt der Verifikation nicht bekannt ist. Die Grundlage fu¨r die Softwareentwicklung stellt dabei die M ECHATRONIC UML(siehe [BGT05, GTB + 03, GBSO04, Bur05]) dar. Sie ist eine Anpassung der UML fu¨r die Modellierung und Verifikation der Software mechatronischer Systeme. Dabei bietet sie vor allem Mo¨glichkeiten, um die Interaktion zwischen verschiedenen mechatronischen Systemen zu spezifizieren und zu verifizieren. Jedes OCM wird in der M ECHATRONIC UML als Komponente aufgefasst. Eine solche Komponente 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 M ECHATRONIC UML werden diese Protokolle in Koordinationsmustern festgehalten. Damit zwei Komponenten miteinander interagieren ko¨nnen, mu¨ssen sie das entsprechende Protokoll ausfu¨hren, d.h. jede der an der Interaktion beteiligten Komponenten muss das Protokoll komponentenintern umsetzen. Die Modellierung mittels M ECHATRONIC UML ist kompositional, d.h. jedes Koordinationsmuster kann unabha¨ngig von anderen Koordinationsmustern entwickelt werden. Ebenso ko¨nnen die Komponenten unabha¨ngig voneinander entwickelt werden. Betrachtet man das Anwendungsbeispiel aus Abschnitt 1.2, so stellt jedes Shuttle und jede BaseStation ein OCM dar, das in der M ECHATRONIC UML als Komponente vom Typ Shuttle bzw. vom Typ BaseStation modelliert wird. Fahren zwei Shuttle s dicht hintereinander her, so mu¨ssen sie, um nicht zu kollidieren, ein Protokoll zur Abstandshaltung ausfu¨hren. Die kompositionale Modellierung der M ECHATRONIC UML la¨sst auch eine kompositionale Verifikation zu. Fu¨r jedes der Koordinationsmuster kann mittels Model Checking unabha¨ngig von anderen Koordinationsmustern und Komponenten automatisch nachgewiesen werden, dass es eine Menge von Sicherheitseigenschaften erfu¨llt. Auch die Verifikation der Komponenten erfolgt durch Model Checking und kann unabha¨ngig von anderen Komponenten und den Koordinationsmustern erfolgen. Bei der Verifikation einer Komponente wird u¨berpru¨ft, ob sich die Komponente so verha¨lt, wie sie es durch die Umsetzung der Protokolle aus den Koordinationsmustern versprochen hat. Das gesamte Modell eines Systems wird dann aus Instanzen der Komponenten und Koordinationsmuster zusammengesetzt. Wurden die Komponenten und Koordinationsmuster erfolgreich verifiziert, das gesamte Modell syntaktisch korrekt aus Instanzen der Komponenten und Koordinationsmuster zusammengesetzt und erfolgt die Interaktion der Komponenten ausschließlich u¨ber die Koordinationsmuster, so gilt, dass auch das gesamte Modell die vorgegebenen Sicherheitseigenschaften erfu¨llt. Eine zusa¨tzliche Verifikation, um nachzuweisen, dass die Sicherheitseigenschaften auch vom gesamten Modell erfu¨llt werden, ist nicht notwendig.

1.3. ZIEL UND LO¨ SUNGSANSATZ 5 Der von Burmester und anderen vorgestellte Ansatz der M ECHATRONIC UML garantiert somit, dass die Interaktion mehrerer Komponenten sicher ist, wenn diese die notwendigen Koordinationsmuster miteinander ausfu¨hren. Da mechatronische Systeme sehr dynamisch sind, ist bei der Instanzierung einer Komponente jedoch nicht bekannt, mit welchen anderen Komponenteninstanzen sie zur Laufzeit interagieren muss. Im Anwendungsbeispiel stellt jedes Shuttle eine Instanz der Komponente Shuttle dar. Die Shuttle s bewegen sich auf den Schienen und begegnen dabei anderen Shuttle s, mit denen sie interagieren mu¨ssen, z.B. um eine Abstandshaltung durchzufu¨hren. Da sich die Shuttle s im Schienennetz frei bewegen ko¨nnen, ist bei der Instanzierung einer Shuttle -Komponenten, also der Inbetriebnahme eines Shuttle s, nicht bekannt, welchen anderen Shuttle s 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 mu¨ssen von den Komponenteninstanzen verarbeitet und evtl. gespeichert werden. Jede der Komponenteninstanzen stellt ein mechatronisches System dar. In solchen Systemen stehen nur begrenzte Rechen- und Speicherkapazita¨ten zur Verfu¨gung. Das bedeutet, selbst wenn alle anderen Komponenteninstanzen eines Systems bei der Instanzierung einer Komponente bekannt sind, so ist es nicht mo¨glich, zwischen jedem Komponentenpaar alle mo¨glichen Muster zu instanzieren, d.h. es ist nicht mo¨glich, dass eine Komponenteninstanz mit allen anderen Komponenteninstanzen kommuniziert. Eine Beschreibung, wann eine bestimmte Musterinstanz beno¨tigt bzw. wann sie nicht mehr beno¨tigt wird und wie eine Instanz erzeugt oder gelo¨scht werden muss, ist mittels der M ECHA TRONIC UML nicht mo¨glich. Aus diesem Grund wird ein Ansatz beno¨tigt, der es erlaubt, die Instanzierung und das Lo¨schen von Koordinationsmustern zu modellieren. Um garantieren zu ko¨nnen, dass eine Instanz eines Koordinationsmusters immer vorhanden ist wenn sie beno¨tigt wird, muss der Ansatz zudem eine formale Verifikation ermo¨glichen. Da mechatronische Systeme in der Regel zu komplex sind, um als Ganzes modelliert zu werden, muss der Ansatz zusa¨tzlich eine kompositionale Modellierung und Verifikation erlauben. Ein solcher Ansatz wird in dieser Arbeit vorgestellt und in den existierenden Modellierungsund Verifikationsprozess der M ECHATRONIC UML integriert. Der in dieser Arbeit vorgestellte Ansatz basiert auf der folgenden Idee: Ein Systemzustand wird durch seine Koordinationsmuster- und Komponenteninstanzen sowie durch die existierenden Verbindungen zwischen den Instanzen charakterisiert. Eine solche Instanzsituation 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 U¨ bergang von einem Systemzustand in einen anderen beschreibt dann das Erzeugen oder das Lo¨schen von Instanzen oder deren Verbindungen. Fasst man einen Systemzustand als Graphen auf, so werden bei einem Zustandsu¨bergang Knoten und Kanten erzeugt bzw. gelo¨scht. Wann ein Konten oder eine Kante erzeugt oder gelo¨scht werden muss und wie ein neu erzeugter Knoten oder eine neu erzeugte Kante in einen Graphen eingefu¨gt wird, wird mittels Graphtransformationsregeln definiert. Damit entspricht ein Zustandsu¨bergang einer Graphtransformation.

6 KAPITEL 1. EINLEITUNG In dieser Arbeit werden zur Beschreibung von Graphtransformationen Story Patterns [FNTZ98, Zu¨n01] verwendet. Story Patterns wurden speziell fu¨r die objektorientierte Modellierung entwickelt und stellen eine Erweiterung der UML-Aktivita¨tendiagramme dar. Der Vorteil bei einer Verwendung einer UML-nahen Modellierungssprache liegt darin, dass der Einarbeitungsaufwand in diese Sprache gering ist und somit eine gro¨ß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 u¨berpru¨ft werden ko¨nnen. Fasst man einen Systemzustand als Graphen auf, so bietet dies einen weiteren Vorteil: Strukturelle Sicherheitseigenschaften, die vom System erfu¨llt werden mu¨ssen, ko¨nnen ebenfalls als Graphen aufgefasst werden. In dieser Arbeit werden Graphmuster eingefu¨hrt, die eine spezielle Form von Graphen darstellen, um solche strukturellen Eigenschaften zu spezifizieren. Von besonderem Interesse werden dabei die so genannten verbotenen Graphmuster sein, da diese dazu genutzt werden ko¨nnen, um kritische Situationen und Unfa¨lle zu modellieren, die nie eintreten du¨rfen. Auch solche Graphmuster ko¨nnen als Story Patterns beschrieben werden. Im Anwendungsbeispiel kann ein solches verbotenes Graphmuster dazu verwendet werden, um zu beschreiben, dass zwei Shuttle s sehr dicht hintereinander herfahren, ohne jedoch ein Koordinationsmuster zur Abstandshaltung miteinander auszufu¨hren. Dies entspricht einer kritischen Situation, da das vordere Shuttle bei seinen Aktionen keine Ru¨cksicht auf das hintere Shuttle nimmt und ihm beispielsweise nicht signalisiert, dass es bremsen mo¨chte. In diesem Fall droht eine Kollision der beiden Shuttle s. Fu¨r eine Menge von verbotenen Graphmustern soll durch formale Verifikation gezeigt werden, dass die Anwendung der Graphtransformationsregeln niemals einen Graphen erzeugen ko¨nnen, der ein solches verbotenes Graphmuster entha¨lt. Das bedeutet, es soll gepru¨ft werden, dass niemals eine der durch die verbotenen Graphmuster beschriebenen kritischen Situationen oder Unfa¨lle eintritt. Zur Verifikation von Graphtransformationssystemen existieren zwar einige Ansa¨tze(siehe Kapitel 6), jedoch sind diese zumeist auf Systeme beschra¨nkt, in denen nur endliche viele Zusta¨nde erreichbar sind. Die Regeln zur Instanzierung und zum Lo¨schen von Koordinationsmuster- und Komponenteninstanzen sowie deren Verbindungen, ko¨nnen aber unter Umsta¨nden unendlich viele Zusta¨nde erzeugen. Daru¨ber hinaus beno¨tigen die meisten dieser Ansa¨tze den Anfangszustand des Systems. Da die Verifikation zum fru¨hst mo¨glichen Zeitpunkt im Entwicklungsprozess erfolgen soll, der Anfangszustand im Allgemeinen jedoch erst recht spa¨t bekannt ist, wu¨rde die Verwendung dieser Ansa¨tze den Entwicklungsprozess verzo¨gern. Deshalb sind die existierenden Ansa¨tze im Allgemeinen in der Doma¨ne der mechatronischen Systeme nicht einsetzbar. Aus diesem Grund wird in dieser Arbeit ein Verfahren eingefu¨hrt, dass die Verifikation von Graphtransformationssystemen auch dann erlaubt, wenn das System unendlich viele erreichbare Zusta¨nde besitzt. Statt wie die existierenden Verfahren fu¨r jeden Zustand zu pru¨fen, ob dieser korrekt ist, d.h. zu pru¨fen ob er keines der verbotenen Graphmuster entha¨lt, pru¨ft der hier vorgestellte Ansatz, ob ein inkorrekter Zustand das Resultat einer Regelanwendung auf einen korrekten 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 verknu¨pft, daraus resultiert das so genannte Ergebnisgraphmuster . Auf dieses Ergebnisgraphmuster wird dann die entsprechende Regel ru¨ckwa¨rts angewendet, woraus das Startgraphmuster resultiert. Entha¨lt dieses Startgraphmuster kein verbotenes Graphmuster, so wurde ein Beispiel gefunden, das zeigt, dass die betrachtete Regel einen korrekten Zustand in einen inkorrekten u¨berfu¨hren kann. Dabei wird allerdings nicht betrachtet, ob der inkorrekte Zustand ausgehend vom Startzustand des Systems erreichbar ist. Damit pru¨ft der Ansatz fu¨r jedes verboontsesnyestGemraspihsmt. uImsteGr, eogbensesaintz"NzuimchtA-Ansuafttzrevteonn" eine induktive Invariante des GraphtransformatiHeckel und Wagner wird jedoch die betrachtete Regel nicht modifiziert. Zudem wird gezeigt, wie die Regelmenge in voneinander unabha¨ngige Teilmengen unterteilt werden kann. Diese Teilmengen ko¨nnen dann unabha¨ngig voneinander verifiziert werden. Wird ein Beispiel gefunden, in dem eine Regel einen korrekten Graphen in einen inkorrekten u¨berfu¨hrt, so werden diese beiden Graphen zusammen mit der angewendeten Regel als Gegenbeispiel zuru¨ckgeliefert. Die Generierung eines solchen Gegenbeispiels sowie seiner Darstellung in der gleichen Notation, mit der auch das Modell entwickelt wurde, ermo¨glicht eine einfache Fehlerdiagnose. In dieser Arbeit wird das Verfahren zuna¨chst formalisiert. Dies geschieht jedoch nicht auf Ebene der Story Patterns, sondern allgemeiner fu¨r Graphtransformationssysteme, wie sie zumeist in der Literatur verwendet werden. Die dabei gewonnenen Erkenntnisse werden auf Story Pattern u¨bertragen und prototypisch in der Fujaba Real-Time Tool Suite 2 umgesetzt. Das Verfahren soll dann anhand eines kleinen Ausschnitts des im vorangegangenen Abschnitts vorgestellten Anwendungsbeispiels evaluiert werden. Zusammen mit dem bereits existierenden Ansatz der M ECHATRONIC UML und dessen Umsetzung in der Fujaba Real-Time Tool Suite bietet der Ansatz dann die Mo¨glichkeit, die Software eines mechatronischen Systems kompositional zu modellieren und automatisch zu verifizieren. Damit ist es dann mo¨glich, die Leistungsfa¨higkeit technischer Systeme zu erho¨hen, indem Softwarekomponenten in Systeme, bestehend aus maschinenbaulichen und elektrotechnischen Komponenten, integriert werden. Trotz der daraus resultierenden Komplexita¨t der Software kann der vorgestellte Ansatz ihre Korrektheit im Bezug auf bestimmte Sicherheitseigenschaften gewa¨hrleisten. 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 M ECHATRONIC 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 Lo¨schen identifiziert werden ko¨nnen. Am Ende des Kapitels wird der Prozess vorgestellt, der die Identifikation der relevanten 2 www.fujaba.de

8 KAPITEL 1. EINLEITUNG Komponenten und Koordinationsmuster, deren Modellierung und Verifikation beinhaltet. Dieser Prozess beschreibt auch, wie die Verifikation der Regeln zum Instanzieren und Lo¨schen von Komponenten und Koordinationsmustern sowie deren Verbindungen in den Gesamtprozess integriert wird. Kapitel 3 beschreibt einen Ansatz zum Nachweis von induktiven Invarianten in Graphtransformationssystemen. Dieser Ansatz wird bei der Entwicklung sicherheitskritischer Software fu¨r mechatronische Systeme dazu verwendet, um die Regeln zum Instanzieren und Lo¨schen von Komponenten und Koordinationsmustern zu verifizieren. Kapitel 4 beschreibt informal die Abbildung der in Kapitel 2 eingefu¨hrten Story Patterns auf die in Kapitel 3 beschriebenen Graphtransformationsregeln und verbotenen Graphmuster. Diese Abbildung ermo¨glicht die Verwendung des Verifikationsansatzes aus Kapitel 3 fu¨r die Verifikation von Story Patterns. Kapitel 5 beschreibt die prototypische Umsetzung des gesamten Modellierungs- und Verifikationsansatzes. Am Ende des Kapitels erfolgt eine Evaluierung anhand des Anwendungsbeispiels. Kapitel 6 fasst verwandte Arbeiten zur Verifikation von Graphtransformationssystemen zusammen. Kapitel 7 fasst die Ergebnisse dieser Arbeit zusammen und liefert einen U¨ berblick u¨ber mo¨gliche Erweiterungen des Ansatzes.

Kapitel 2 Grundlagen In diesem Kapitel werden die existierenden Ansa¨tze vorgestellt, die fu¨r die vorliegende Arbeit als Grundlage dienen. Daru¨ber hinaus wird gezeigt, wie der in dieser Arbeit vorgestellte Ansatz in die existierenden Ansa¨tze integriert werden kann. In[OHG04, HOG04, Ge05] wurde die Architektur des Operator-Controller-Moduls vorgestellt. Diese bietet die Mo¨glichkeit die Informationsverarbeitung eines mechatronischen Systems zu Strukturieren. Die Software eines mechatronischen Systems ist im Allgemeinen sehr komplex und sicherheitskritisch. Dies gilt insbesondere fu¨r den Teil der Software, der fu¨r die Steuerung der Hardware sowie die Interaktion mit anderen mechatronischen Systemen verantworlich ist. Um diese Komplexita¨t handhaben zu ko¨nnen und eine effiziente Analyse zu ermo¨glichen, wird eine modellbasierte Softwareentwicklung verwendet. Bei der modellbasierten Softwareentwicklung wird sowohl die Architektur des Softwaresystems als auch sein Verhalten in einem Modell festgehalten. Dabei wird von implementierungsspezifischen Details abstrahiert. Das resultierende Modell soll mittels formaler Methoden verifiziert werden ko¨nnen, damit Modellierungsfehler mo¨glichst fru¨h im Entwicklungsprozess aufgedeckt werden. Die Unified Modeling Language(UML, siehe[UML05]) stellt die Standardmodellierungssprache fu¨r die modellbasierte Softwareentwicklung dar. Sie entha¨lt verschiedene Notationen fu¨r die Modellierung von Softwarearchitekturen und Verhalten. Um ein mechatronisches System spezifizieren zu ko¨nnen, muss auch echtzeitfa¨hige Software spezifiziert werden ko¨nnen. Dies wird durch die UML, wie sie in[UML05] definiert ist, jedoch nicht bzw. nur unzureichend unterstu¨tzt. Deshalb ist es notwendig, einige Notationen der UML auszuwa¨hlen 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 M ECHATRONIC UML[BGT05, BTG04, GBSO04, GTB + 03, Bur05] bezeichnet und soll in diesem Kapitel eingefu¨hrt werden. In diesem Kapitel wird zuna¨chst die Modellierung der Architektur vorgestellt 2.1. Nachdem 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 Koordinati9

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 vollsta¨ndig getestet werden zu ko¨nnen, wird in Abschnitt 2.4 ein Ansatz zur formalen, kompositionalen Verifikation vorgestellt. Der gesamte Modellierungsund Verifikationsprozess wird in Abschnitt 2.5 erla¨utert. 2.1 Architektur Die Strukturierung der Informationsverarbeitung erfolgt mittels der Architektur des OperatorController-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 fu¨r 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 u¨ber Sensoren sowie deren Verarbeitung, eines mechatronischen Systems ist komplex. In[OHG04, HOG04, Ge05] stellen Oberschelp, Hestermeyer und Giese deshalb die Architektur des Operator-ControllerModul(OCM) zur strukturierten und modularen Entwicklung der Informationsverarbeitung eines mechatronischen Systems vor. In diesem Ansatz wird ein mechatronisches System als Operator-Controller-Modul aufgefasst, das in die drei Ebenen Controller, reflektorischer Operator und kognitiver Operator unterteilt 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 sicherheitskritischen Situation fu¨hren. Ein Controller kann aus mehreren Reglern bestehen, zwischen denen umgeschaltet werden kann. Die Informationsverarbeitung des Controllers ist quasi-kontinuierlich, d.h. die Sensoren nehmen kontinuierlich Daten auf und leiten diese zur Verarbeitung weiter. U¨ ber der Controller-Ebene liegt die Ebene des reflektorischen Operators . Zu den Aufgaben des reflektorischen Operators geho¨rt die U¨ berwachung des Controllers. Der reflektorische Operator kann keinen direkten Einfluss auf die Aktorik des Systems nehmen. Er kann jedoch die Konfiguration des Controllers vera¨ndern und dadurch die Umschaltung der Regler bewirken. Auch die sicherheitskritische Koordination mit anderen Operator-Controller-Modulen erfolgt u¨ber den

2.1. ARCHITEKTUR 11 Abbildung 2.1: Die Architektur des Operator-Controller-Moduls. Quelle:[Ge05] reflektorischen Operator. Die U¨ berwachungs-, Steuerungs- und Koordinationsfunktionen des reflektorischen 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 u¨ber 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 Operators 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 ko¨nnen. Ein OperatorController-Modul stellt selber eine Komponente dar. Eine schematische Darstellung einer Komponente, die das Operator-Controller-Modul aus Abbildung 2.1 repra¨sentiert ist in Abbildung 2.2 gegeben. Im Folgenden wird die detaillierte Darstellung von Controller, reflektorischem Operator und kognitiven Operator weggelassen und nur die Koordination des OCM mit anderen OCMs modelliert. Nach Szyperski traglich festgelegten [SSczhyn0i2tt]stiesltle"neiunned S e o x f p tw liz a i r t e e k n o K m o p n o t n ex e t n a t b e hea¨inngeigKkoeimtepno.sEitiinoensSeoifnthweaitremkoitmvpeor-nente kann unabha¨ngig verteilt und durch Dritte mit anderen Komponenten verbunden werden."

12 KAPITEL 2. GRUNDLAGEN PI 1$Q¨§¢§9@© BA £DC¥D%§E% F2©!¡G3H5D©¡¤2§#£$¡ £¦¥¨§ ©©!"§#£$¡&%('0)12©¡43657©¡¤2§#£$¡ 8 £¥¨§9¡£@ ¡©¡ Abbildung 2.2: OCM als Komponente. Quelle:[Ge05] Das bedeutet, eine Komponente ist eine Einheit, deren Implementierung nach außen nicht sichtbar ist. Fu¨r eine Komponente wird festgelegt, welche Nachrichten sie fu¨r andere Komponenten bereitstellt bzw. welche Nachrichten sie von anderen Komponenten erwartet. In einem UML-Komponentendiagramm [UML05] werden die Komponententypen festgelegt. Das nach außen sichtbare Verhalten einer Komponente, d.h. die Interaktion mit anderen Komponenten, wird durch beno¨ tigte Schnittstellen (engl. required interfaces) und bereitgestellte Schnittstellen (engl. provided interfaces) beschrieben. Dabei entsprechen die beno¨tigten Schnittsr"itvceehlrltteernnagddleiicnehK"fKeosomtngpteeolxentgeatnbethnea¨Svncoghnignkaitentisdtteeenrlel"envno"Kn.oESmiznpyeopnbeeresnnkto¨eitniugnetedrwSdacirehtenbti.tetrDsetieietlgleebsebtreeelsilcttgehenrsetSiebcltlh,tenwitSetslccthehnlelietNtnstadeclehlnebeschreibt, welche Nachrichten die Komponente anderen Komponenten zur Verfu¨gung stellt. Mehrere Schnittstellen einer Komponente ko¨nnen in einem Port zusammengefasst werden. Im Beispiel stellt jedes Shuttle eine Komponente dar. Um sich gegenseitig koordinieren zu ko¨nnen, mu¨ssen die Shuttle s sowohl Nachrichten versenden als auch empfangen ko¨nnen. Das Senden und Empfangen von Nachrichten erfolgt u¨ber beno¨tigte und bereitgestellte Schnittstellen. Abbildung 2.3 zeigt die Komponente, die den Typ Shuttle definiert. Die Komponente besitzt zwei beno¨tigte Schnittstellen, dargestellt durch einen Halbkreis, und zwei bereitgestellte Schnittstellen, dargestellt durch einen Kreis. Jeweils eine beno¨tigte und eine bereitgestellte Schnittstelle werden in einem Port zusammengefasst. Die Ports werden durch Quadrate an den Ra¨ndern der Komponente repra¨sentiert.  ¥" ! £¦¥§¥©¨ Abbildung 2.3: Definition des Komponententyps Shuttle Nachdem die Komponententypen festgelegt wurden, ko¨nnen konkrete Komponenteninstanzen betrachtet werden. Auch Komponenteninstanzen werden in einem UMLKomponentendiagramm dargestellt. Wird die bereitgestellte Schnittstelle einer Komponente mit der beno¨tigten Schnittstelle einer zweiten Komponente verbunden, so bietet die M ECHATRO NIC UML die Mo¨glichkeit, dies abku¨rzend durch einen Pfeil darzustellen. Dieser Pfeil verla¨uft

2.1. ARCHITEKTUR 13 von der Komponente, die die Schnittstelle bereitstellt, zu der Komponente mit der beno¨tigten Schnittstelle. Tauschen zwei Komponenten in beide Richtungen Nachrichten aus, d.h. beide haben jeweils eine beno¨tigte und eine bereitgestellte Schnittstelle, so wird abku¨rzend ein Doppelpfeil verwendet. Eine solche Verbindung von zwei Komponenten wird als Konnektor bezeichnet. Abbildung 2.4 zeigt zwei Instanzen der Shuttle -Komponente, die miteinander u¨ber einen Konnektor kommunizieren.  ¡£¢¥¤§¦¨¢¥© © §"!$#"% &('  ¡£¢¥¤§¦¨¢¥© © 0)1"!$#"% &(' Abbildung 2.4: Zwei Instanzen der Shuttle -Komponente Ein Komponententyp beschreibt, welche Schnittstellen eine Komponente bereitstellt bzw. beno¨tigt. Das Verhalten dieser Schnittstellen wird intern durch die in Abschnitt 2.2.1 eingefu¨hrten 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, ko¨nnen durch UML-Klassendiagramme definiert werden. 2.1.3 Klassendiagramme UML-Klassendiagramme [UML05] werden dazu verwendet, die interne Architektur einer Komponente zu spezifizieren, ihre Datenstrukturen festzulegen und um das interne Verhalten der Komponenten realisieren zu ko¨nnen. Abbildung 2.5 zeigt das Klassendiagramm, das die interne Architektur der Shuttle Komponente festlegt. Es definiert die Ontologie des Shuttle s, d.h. in ihm wird die Sicht des Shuttle s 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 Kardinalita¨ten an der Assoziation besagen, dass sich jedes Shuttle auf genau einem Track befindet. Die Track s sind so kurz, dass sich ho¨chstens ein Shuttle darauf befinden kann. Dies wird durch die Kardinalita¨t 0... 1 ausgedru¨ckt. Das Schienennetz wird durch die successor -Assoziationen modelliert. Fu¨r Weichen gibt es keine eigene Klasse. Eine Weiche wird dadurch modelliert, dass ein Track zwei Vorga¨nger oder zwei Nachfolger hat. Die Aufgabe der BaseStation besteht darin, die Track s und die auf ihnen fahrenden Shuttle s zu u¨berwachen. Jede BaseStation kann beliebig viele Track s u¨berwachen und u¨berwacht mindestens einen, dargestellt durch die Kardinalita¨t 1 · · · an der monitors -Assoziation. Umgekehrt kann ein Track von beliebig vielen BaseStation s u¨berwacht werden und wird von mindestens einer u¨berwacht, d.h. die von den BaseStation s u¨berwachten Bereiche ko¨nnen sich u¨berlappen. In diesem Abschnitt wurden Komponentendiagramme eingefu¨hrt, um die Architektur eines Softwaresystems zu modellieren. Fu¨r jede der Komponenten kann eine Menge von bereitgestellten und beno¨tigten Schnittstellen angegeben werden, die festlegen, welches Verhalten eine Komponente nach außen zeigt bzw. welches Verhalten sie von anderen Komponenten erwartet. Intern wird eine Komponente mittels eines Klassendiagramms strukturiert, das auch die Datenstrukturen 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 Schnittstellen der Komponenten stellen dar, welche Nachrichten eine Komponente bereitstellt bzw. welche Nachrichten sie von anderen Komponenten beno¨tigt. Existiert zwischen zwei Komponenteninstanzen ein Konnektor, d.h. die beno¨tigten und bereitgestellten Schnittstellen der Komponenten wurden miteinander verbunden, so muss garantiert werden ko¨nnen, dass entweder Nachrichten, die von der einen Komponente versandt werden, von der anderen Komponente auch empfangen werden oder beim Verlust oder zu spa¨ten Eintreffen einer Nachricht kein Unfall und keine kritische Situation eintreten kann. Eine Kommunikation, die diese Eigenschaft erfu¨llt wird als sicher bezeichnet. Um eine solche sicher Kommunikation zu spezifizieren werden Kommunikationsprotokolle verwendet. 2.2.1 Kommunikation Bei der Modellierung einer sicheren Kommunikation zwischen Komponenten muss zum einen beru¨cksichtigt werden, dass das Senden und Empfangen von Nachrichten zwischen Komponenten Zeit beno¨tigt. Zudem muss beru¨cksichtigt werden, dass Nachrichten verloren gehen ko¨nnen, zum Beispiel durch ein unzuverla¨ssiges U¨ bertragungsmedium. Die EchtzeitKoordinationsmuster der M ECHATRONIC UML unterstu¨tzen 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 Reihenfolge die Nachrichten versandt oder empfangen werden, wie viel Zeit mindestens vergehen muss oder maximal vergehen darf, wenn eine Nachricht verschickt oder empfangen werden soll. Zur Spezifikation der Kommunikation werden Zustandsautomaten verwendet. Da die in der UML eingefu¨hrten Protokoll-Zustandsautomaten[UML05] kaum die Modellierung von Echtzeitverhalten unterstu¨tzen, werden fu¨r 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 Kommunikationsverhaltens. Soll eine Komponente in einer Kommunikation eine bestimmte Rolle u¨bernehmen, so muss sie die entsprechende Rolle verfeinern. Das bedeutet, die Komponente muss das Kommunikationsverhalten der Rolle realisieren. Nach[Gie03, GTB + 03] darf dabei jedoch kein zusa¨tzliches extern sichtbares Verhalten hinzugefu¨gt 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 erfu¨llen. Eine Rolleninvariante ist einer bestimmten Rolle zugeordnet. Sie beschreibt eine Eigenschaft, die von dem entsprechenden Kommunikationspartner erfu¨llt werden muss. Durch formale Verifikation kann gezeigt werden, dass eine Komponente, die eine Rolle bei der Kommunikation u¨bernommen hat, die entsprechende Rolleninvariante einha¨lt(siehe Abschnitt 2.4.2). Beschrieben werden Rolleninvarianten zum Beispiel durch TCTL-Formeln[ACD90]. Die Konnektoren beschreiben die Verbindung zwischen den Rollen. Sie werden wie die Rollen durch ein Real-Time Statechart beschrieben. Im Konnektor werden die Qualita¨tseigenschaften(engl. quality of service) der Verbindung zwischen den Rollen spezifiziert. Die Beschreibung entha¨lt zum Beispiel, wie lange das Verschicken einer Nachricht beno¨tigt oder wie zuverla¨ssig 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 ausgewa¨hlt, deren Kommunikationsverhalten die Komponente umsetzen soll. Eine Komponente kann dadurch an der Kommunikation verschiedener Koordinationsmuster teilnehmen. Die Modellierung des Komponentenverhaltens ist Inhalt von Abschnitt 2.2.2. Die Trennung von Kommunikations- und Komponentenverhalten ermo¨glicht einerseits eine Wiederverwendung der Koordinationsmuster, andererseits kann auf diese Weise eine formale

16 KAPITEL 2. GRUNDLAGEN Verifikation durchgefu¨hrt werden. In Abschnitt 2.3.1 wird gezeigt, wie ein komplexes Softwaresystem aus Komponenten- und Koordinationsmusterinstanzen zusammengesetzt werden kann. Im Shuttle -System mu¨ssen sich beispielsweise zwei Shuttle -Instanzen gegenseitig koordinieren, um hintereinander fahren zu ko¨nnen, ohne zu kollidieren[BGH + 05]. Fu¨r diese Koordination wird das DistanceCoordination -Koordinationsmuster aus Abbildung 2.6 verwendet. Dieses Koordinationsmuster besteht aus den beiden Rollen frontRole und rearRole und einem bidirektionalem Konnektor. Die Rollen werden durch die beiden Quadrate im Diagramm dargestellt, das Koordinationsmuster als gestricheltes Oval. 8@9BA #¡CD¦!$%¦E2 ¡F"G 8@9BA #¡CRQS¤§$P'¤T)5¡©2$VUW"%¡©X#¡Y`¥#¦ 3 ¤(¡©4)1¡©2$CUa#¡£©X#¡Y'c ¨!#"%$' & £¡¥¤§¦©¨¨¡© 8D9HA #¡CI¦!$P#¦E2 ¡£"'G ¤($%'¤0)1¡©2$ "6¡©!#$%"47¡!¤ 3 ¤§¡©4)5¡©2$ 8D9BA #¡CI¦!$P#¦E2 ¡£"'G Abbildung 2.6: Das DistanceCoordination -Koordinationsmuster An das Koordinationsmuster sind zwei Musterconstraints angefu¨gt. Das Constraint A[] not deadlock besagt, dass die Kommunikation der Rollen u¨ber den Konnektor immer verklemmungsfrei(engl. deadlock free) sein muss. Das Constraint A[] not( rearRole. convoy and frontRole. noConvoy) verlangt, dass das vordere Shuttle nicht im Zustand noConvoy fa¨hrt, wenn das hintere Shuttle im Zustand convoy fa¨hrt. Andernfalls wu¨rde das vordere Shuttle bei seinen Aktionen nicht beru¨cksichtigen, dass das hintere Shuttle mit sehr geringem Abstand hinter ihm herfa¨hrt. Ebenso ist an jede der beiden Rollen eine Rolleninvariante angefu¨gt. 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 Shuttle s s1 die frontRole realisiert und der Port rear von Shuttle s2 die rearRole . Damit zwei Shuttle -Komponenten kollisionsfrei hintereinander herfahren ko¨nnen, muss dass Verhalten der Rollen so spezifiziert werden, dass die Shuttle s Konvois bilden und wieder auflo¨sen ko¨nnen. Zudem mu¨ssen die Protokolle, die das Rollenverhalten beschreiben, so modelliert werden, dass sie eventuelle Nachrichtenverluste abfangen ko¨nnen, ohne dass die beteiligten Shuttle s 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 u¨ber die im folgenden Abschnitt vorgestellten Real-Time Statecharts.

2.2. VERHALTEN 13254 #¡67¦¥$%¦98 ¡£"@ 13254 #¡6feR¤g$%6¤Yhb¡©8$'i5"(¡©p#¡qr¥#¦tsY¤§¡©)hW¡£8$Eiu#¡£©p#¡q6v ¨!¥#"%$'& £¡¥¤§¦©¨¨¡© A ©BDCE¡©#$GF RQTSEUWV¥XY`8$ ¤§$c6¤ 13254 #¡67¦¥$%¦98 ¡£"@ "(¡©¥#$%") ¡0¤ A £BIC'¡©#$6PF sY¤g¡£ )aIS0UbV¥XY`8$ 13254 #¡63¦¥$c#¦98 ¡d"6@ 17 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 Modellierung von Zeit eine besondere Rolle. UML-Zustandsautomaten bieten zur Modellierung von Zeitverhalten jedoch nur das after -Konstrukt an. Dieses Konstrukt ist fu¨r die Modellierung der hier betrachteten mechatronischen Systeme nicht ausreichend. Zudem besitzen die UMLZustandsautomaten eine Nullzeitsemantik, d.h. die Transitionen der Zustandsautomaten ko¨nnen schalten, ohne dass dabei Zeit vergeht. In mechatronischen Systemen, in denen das Schalten einer Transition mit der Ausfu¨hrung von Methoden auch auf physikalischer Ebene verbunden sein kann wie beispielsweise dem Versenden oder empfangen einer Nachricht, ist eine solche Semantik nicht realisierbar. Deshalb werden in der M ECHATRONIC UML Real-Time Statecharts [GB03, BG03, BGS05b, Bur05] eingesetzt, um die Kommunikationsprotokolle und das Komponentenverhalten 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 U¨ berblick vorgestellt werden. Eine ausfu¨hrlichere Beschreibung ist in[Bur05, GB03] enthalten. Real-Time Statecharts bieten verschiedene Mo¨glichkeiten um Zeit zu spezifizieren. Eine Transition kann mit einem Intervall beschriftet werden, das angibt, wie lange das Schalten der Transition mindestens bzw. ho¨chstens dauert. Zeitinvarianten geben an, wann ein Zustand spa¨testens wieder verlassen werden muss. Dazu ko¨nnen mehrere Uhren spezifiziert werden. Diese Uhren werden beim Schalten bestimmter Transitionen zuru¨ckgesetzt. Eine Transition ist aktiviert, wenn ihre Zeitbedingung(engl. time guard) erfu¨llt ist, das auslo¨sende Ereignis vorliegt und die Bedingung der Transition, bestehend aus einem boolschen Ausdruck u¨ber Variablen und Methoden, wahr ist. Ist die aktivierte Transition zwingend(engl. urgent), so muss sie sofort nach ihrer Aktivierung schalten. Nicht-zwingende Transitionen ko¨nnen das Schalten verzo¨gern, so lange ihre Zeitbedingung erfu¨llt ist. Nicht-zwingende Transitionen werden durch gestrichelte Pfeile dargestellt.

18 KAPITEL 2. GRUNDLAGEN Wa¨hrend die Ausfu¨hrungssemantik der Real-Time Statecharts der von Timed Automata entspricht, enthalten sie auch einige Konstrukte von UML-Zustandsautomaten. Dazu geho¨ren zum Beispiel sowohl flache als auch tiefe Historie(engl. shallow und deep history) und parallele und hierarchische Zusta¨nde. Fu¨r einen Zustand ko¨nnen außerdem entry()-, do()- und exit()- Methoden definiert werden. Entha¨lt ein Zustand eine do()-Methode, so wird diese Methode periodisch ausgefu¨hrt solange der Zustand aktiviert ist. Wird der Zustand aktiviert und sofort wieder verlassen, so muss seine do()-Methode jedoch mindestens einmal ausgefu¨hrt werden. Fu¨r jede der Methoden muss eine maximal zula¨ssige Ausfu¨hrungszeit(engl. worst case execution time) spezifiziert werden. Zusa¨tzlich zu den entry()-, do()- und exit()-Methoden in den Zusta¨nden ko¨nnen die Transitionen mit Methodenaufrufen belegt sein. In diesem Fall wird, sobald die Transition schaltet, zuna¨chst die entsprechende Methode ausgefu¨hrt. Wie in den Zustandsautomaten der UML werden diese Methoden jedoch nur in den Real-Time Statecharts verwendet, die das Verhalten einer Komponente beschreiben. Statecharts mit Methodenaufrufen werden in Abschnitt 2.2.2 noch einmal betrachtet. In UML-Protokoll-Zustandsautomaten und Real-Time Statecharts, die Protokolle modellieren, werden keine Methoden aufgerufen. Fu¨r Real-Time Statecharts kann Code generiert werden, der auf echtzeitfa¨higen Plattformen ausgefu¨hrt werden kann. Eine solche Codegenerierung ist mo¨glich, da fu¨r die Real-Time Statecharts durch Abbildung auf Timed Automata eine formale Semantik definiert wurde und fu¨r jede Methode, die innerhalb eines Real-Time Statecharts aufgerufen wird, eine maximal zula¨ssige Ausfu¨hrungszeit angegeben werden muss. In Abbildung 2.8 ist ein Beispiel fu¨r ein Real-Time Statechart gegeben, das das Protokoll der Rolle rearRole beschreibt. Standardma¨ßig ist die rearRole im Zustand inactive , d.h. es findet keine Kommunikation statt. Nichtdeterministisch wird aus diesem Zustand in den Zustand active gewechselt. Die entsprechende Transition ist nicht-zwingend(sie ist gestrichelt), deshalb kann ihr Schalten beliebig verzo¨gert werden. raisedEvents an der Transition gibt an, dass die folgenden Nachrichten erzeugt und versendet werden. Mit empf¨angerName. nachricht wird spezifiziert, wer der Empfa¨nger ist und welche Nachricht ihm gesandt werden soll. Durch frontRole. startCommunication wird der frontRole signalisiert, dass eine Kommunikation erforderlich 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 0 zuru¨ckgesetzt 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 Besta¨tigung, 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 Empfangsbesta¨tigung warten darf. Trifft die Empfangsbesta¨tigung in dieser Zeit nicht ein, muss die rearRole davon ausgehen, dass die Nachricht mo¨glicherweise verloren gegangen ist und schaltet wieder in den Zustand inactive . Trifft die Empfangsbesta¨tigung innerhalb der erlaubten Zeit ein, so wechselt die rearRole in den Zustand noConvoy . Ausgehend von diesem Zustand kann die rearRole der frontRole nichtdeterministisch den Vorschlag machen, einen Konvoi zu bilden. Im Zustand wait wartet die rearRole dann darauf, dass die frontRole der Konvoibildung zustimmt(Nachricht startConvoy ) oder die Konvoibildung ablehnt(Nachricht convoyProposalRejected ).

2.2. VERHALTEN 19 Soll ein bestehender Konvoi aufgelo¨st werden, so schickt die rearRole die Nachricht breakConvoyProposal . Die frontRole kann daraufhin den Konvoi durch das Versenden der Nachricht breakConvoy auflo¨sen oder die Anfrage der rearRole mit breakConvoyProposalRejected zuru¨ckweisen. 5 ! e68¡¦9 ! # §¢ !2 GHIQP¤§ 4  3@YG¡¦F%£`¡T¡25 ! !% G'4 5§ AGS@xGR ! Eg£ #! q '&¤r s &¦tvuv&%&Aw ! # §¢ !% G' QP¤§ 4  3@YG'¡¤F%£` # ! 4  3@YG' ! fg£`¡T¡25 h! '&)(102&3& £§¢¡¨© !2 GHIQP¤§ 4  A@ # §¢¡¨©CBDE¡¦F%¡3G ! 9 4  A@ # §¢¡¨©CBDE¡¦F%¡%G ! 9c6Xde # I $ !% 4  3@iU5 !2W £`§¢¡¨© 4  3@YG' ! fg£`§¢¡¢© "! 4  A@VU5 !CW £`§¢¡¢©T68pde # !% G' QPT§ 4  A@VU5 !CW £§¢¡¨©CBDE¡¦F%¡%G ! 9 # §¢¡¨© 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 RealTime Statecharts spezifiziert. 2.2.2 Komponentenverhalten Das Verhalten einer Komponente wird, wie das Verhalten einer Rolle, durch ein Real-Time Statechart beschrieben. Besitzt eine Komponente Schnittstellen und Ports, die durch eine Rolle beschrieben 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 hinzufu¨gen, das nach außen sichtbar ist und das nicht in der realisierten Rolle enthalten ist. Das bedeutet, fu¨r jede Transition im Real-Time Statechart des Ports, die ein Ereignis an einen anderen Port sendet oder von einem anderen Port empfa¨ngt, existiert eine Transition im Real-Time Statechart der Rolle, die das gleiche Ereignis sendet oder empfa¨ngt. Zum anderen darf bei der Umsetzung kein Verhalten entfernt werden. Das heißt, Verhalten, das die Rolle entha¨lt, muss auch in der Komponente enthalten sein. Oder anders ausgedru¨ckt, fu¨r jede Transition im Real-Time Statechart der Rolle muss es eine Transition im Real-Time Statechart des Ports geben, dass das gleiche Ereignis empfa¨ngt oder versendet. Die Verfeinerung stellt somit eine Simulation (siehe[CGP02] Kapitel 11) dar fu¨r die zusa¨tzlich gelten 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 hauptsa¨chlich Nichtdeterminismus entfernt wird.

20 KAPITEL 2. GRUNDLAGEN Realisiert eine Komponente das Verhalten mehrerer Rollen oder besitzt sie zusa¨tzliches internes 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 Zusta¨nden du¨rfen entry()-, do()- und exit()Methoden verwendet werden und die Transitionen ko¨nnen mit Methodenaufrufen belegt sein. Schaltet eine Transition, die mit einem Methodenaufruf belegt ist, so wird der Aufruf als Seiteneffekt(engl. side effect) ausgefu¨hrt. Ein solcher Seiteneffekt kann das Versenden von Nachrichten an eine andere Komponente sein. Andererseits kann als Seiteneffekt eine Methode ausgefu¨hrt werden, die auf der internen Struktur der Komponente, beispielsweise auf ihrer Ontologie, arbeitet. Ein Beispiel fu¨r eine solche Komponente ist die Shuttle -Komponente. Jedes Shuttle muss sowohl als vorderes als auch als hinteres Shuttle agieren ko¨nnen. Deshalb besitzt die Komponente Shuttle sowohl einen Port front als auch einen Port rear . Die beiden Ports verfeinern das Verhalten, das in den Rollen frontRole und rearRole des DistanceCoordination -Musters spezifiziert ist. Abbildung 2.9 zeigt die drei parallelen Zusta¨nde der Shuttle -Komponente. Der oberste Zustand 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 sichtbar. Die Aufgabe des mittleren Zustands besteht darin, die beiden Ports der Komponente zu synchronisieren. Dazu wird eine synchrone Kommunikation verwendet, dargestellt durch Nachrichn te o n C , o d o ie rd e in n a tw tio e n d,erd.mh.iteseiknoemord"i?n"ioerdtesricehinemmit "k!e"ibneegminnanend.erZeunn S a¨c h h u s tt t le is. tPdearsio S di h s u c t h tle wiimrd Zustand gepru¨ ft, ob die Methode createDC anwendbar ist. Dies ist genau dann der Fall, wenn sich ein anderes Shuttle in der Na¨he befindet, mit dem eine Koordination erforderlich ist. Sobald die Methode anwendbar ist, schaltet die entsprechende Transition und sto¨ßt eine Koordination zwischen den beiden Shuttle s an, falls sich der mittlere Zustand mit dem Zustand des rear -Ports synchronisieren kann. Die Synchronisation erfolgt u¨ber das Versenden von !startDC im mittleren Zustand und das Empfangen von ?startDC im rear -Port. Sind die beiden Shuttle s soweit voneinander entfernt, 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 la¨sst nur die Koordination von jeweils zwei Shuttle s zu, d.h. ein Shuttle kann niemals zeitgleich ein vorderes und ein hinteres Shuttle sein. Somit ko¨nnen die Konvois auch nur aus zwei Shuttle s bestehen. Burmester verwendet das Konzept des DistanceCoordination -Musters in[Bur05], um auch Konvois beliebiger La¨nge 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 aufgelo¨st. Beispielsweise kann die rearRole nichtdeterministisch aus dem Zustand inactive in den Zustand active wechseln. Im rear -Port ist ein Wechsel nur dann mo¨glich,

2.2. VERHALTEN ! "¡§ uwv W§!§r& £¦¥¨§© ¦ $£ !% &('0)1§$£¦§© ¡ b ¡¦dce g ¡¦"$£¦§© ¡ @£ S% & A'T)2§2£§©"$£¦§© ¡ b ¥$@£§©"¡ £¤¥#§© ¦ g )1§2£§hce £)4¨576"¦(¡§1)98 @£ S% & A'T)2§2£§©£¦§© ¡ ¡¦¡¦ g ¡¦""¡¦¦(ipD £)2$576"¦¤¡§1)98 @£ S% & A'T¥$¡¦FE GAH)4£F& % S`!¨¥¨§1$5 $£ !% &('0¥¨¡¦FE b )r"¡¦¦(ipD GHA)q£3& £3¡¦)!IP g B$£FD¦a¡¦ £)2$576¦(¡§1)98 $£ !% &('tB$£FD¦"¡¦¦ £3¡¦)!IP RQ g ¥¨¡¦sT)qipD £)4¨576"¦(¡§1)98 $£ !% &('0)1§2£§©¡¦ g ¥$¡¦sv)©ipD £)4¨576"¦¤¡§1)u8 @£ S% & A'CB@£3D¤a¡¦FE GHA)q£3& % S`!$¥#§1$5 ¥¨¡¦ @£ !% "& A'CB@£3D¦¡¦FE b B@£3D¦¡¦ GAH)4£F& )13¡¦¥ §h g @o d b ¡¦" ¥@£§© ¡¦"£¦§© ¡ g )1§$£¦§© ¡ ¥$£§© g $£¦§© ¡ "¡§ p §hAq ¥$£¦§1(ce b )1§2£§©aU ¥¨"£¦§© ¡ % $£ b )1§2£§hce §h vde $o d(f g ¡¦dce ¡¦¡¦Fw ¡§ (¡§ 8y()4#§©"¡¦¦F)2 W3& £3&)2!I¥$#§ p §Q q g )ra¡¦(iD § QghQHdHd b ¡¦A§©"¡¦¦(ipD §1£§1Aw ¡§ ¡¦(§e¥¨¡¦Fi)2 W3&fj!k b B@£3D¦¡¦ y¤)4#§©¡¦F)2 W3&C§ W¦@ b ¥$"¡¦¦sv)qiD § QxvderQHdAd(f ¥$¡¦Fw ¡§ g B@£3D¤a¡¦ ¥$"¡¦¦F)2 W3& b ¥$¡¦sv)©ipD @£ £3¡¦)!IP w ¡§ 53¤&#§1AceP b )1§1GFce g )1§2£§hce ¡¦"a¡¦ % $£ ¤¡§ x8y()2¨§©a¡¦F)4 W3&C £F&)4@!IP¥¨¨§e g ¡¦"a¡¦ ¥$"¡¦¦F)2 W3& b & 5a¡¦ Td"e dHd(f §1£§1 % @£ ¡¦A§l¥¨¡¦Fi)2 W3&fj!k b ¥$¡¦FmnA§4iD g ¥$"¡¦¦(ipD ¥¨¡¦ % @£ £¤¥#§© ¦ g )2§2£§©"U g )1§1GFce £)4¨576"¦¤¡§1)u8 ! "¡§ % & A'T)2§ ¥@£§© £)2$576¦(¡§1)98 ! ¡§ % &('0)1§2£ p §d q §©@£§©"¡ vde dHd(f £¦¥¨§© ¦ b )1§1GH"$£¦§© ¡ b )2§2£§hce ! ¡§ % &('0)1§2£§©£3¡§©"¡ § ds o dHd ¡¦""¡¦¦ g & 5"¡¦¦ £)4¨576"¦(¡§1)98 ! ¡§ % &('0¥¨¡¦FE GHH)4£3& b ¡¦"a¡¦ ! ¡§ % &('0¥¨¡¦FE GHH)4£3& % `!$¥¨§1¨5 I£§ ! ¡§ % "& A'CB b ¡¦""¡¦¦ @£3D¦¡¦ b ¥¨¡¦(iD ! ¡§ % & A'T)2§2£§©a¡¦ §1 Ur$£§1 b ¥$¡¦(ipD ! ¡§ % &('tB$£FD¦a¡¦ % S`!¨¥¨§1$5 ¥$¡¦ g ¥¨¡¦FmtA§4ipD £)4¨576"¦¤¡§1)u8 ! "¡§ % & A'CB@£3D¤a¡¦FE GHA)q£3& Abbildung 2.9: Verhalten der Shuttle -Komponente 21

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 verzo¨gert werden. Erha¨lt 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 mo¨glich, die Kommunikation zwischen mehreren Komponenten zu modellieren und beispielsweise die Ontologie zu vera¨ndern. Es ist jedoch noch nicht mo¨glich, das bei der Kommunikation vereinbarte Verhalten auf physikalischer Ebene umzusetzen. Deshalb werden in[BGO04, BGT05, Bur05] hybride Komponenten eingefu¨hrt. Hybride Komponenten werden beno¨tigt, 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 fu¨r eine hybride Komponente ist die Komponente Control in Abbildung 2.2. Die Ports der Komponente sind kontinuierlich, dies wird durch das ausgefu¨llte Dreieck innerhalb des Ports dargestellt. Hybride Komponenten werden an dieser Stelle nur der Vollsta¨ndigkeit halber genannt. Im weiteren Verlauf der Arbeit werden jedoch nur diskrete Komponenten, wie zuvor eingefu¨hrt, betrachtet. Die in Kapitel 3 und ff. vorgestellte Verifikationstechnik kann jedoch auch fu¨r hybride Komponenten verwendet werden. Story Diagramme Das reaktive Verhalten der Komponenten resultiert aus den entry()-, do()- und exit()-Methoden der Zusta¨nde sowie den Methoden, die als Seiteneffekte beim Schalten einer Transition ausgefu¨hrt werden. Solche Methoden werden in der UML durch UML-Aktivita¨ tendiagramme beschrieben. In [Zu¨n01, FNTZ98] wurden die UML-Aktivita¨tendiagramme zu Story Diagrammen erweitert. Sie stellen den Kontrollfluss einer Methode graphisch dar. U¨ ber Parameter ko¨nnen den Story Diagrammen Attributwerte und Objektreferenzen u¨bergeben werden. Die Basisstruktur von Story Diagrammen stellen die so genannten Aktivita¨ ten dar. Aktivita¨ten ko¨nnen durch Transitionen verbunden werden, die die Ausfu¨hrungsreihenfolge festlegen. Die Ausfu¨hrung beginnt bei einer eindeutigen initialen Aktivita¨t. Verlassen mehrere Transitionen eine Aktivita¨t, so mu¨ssen diese mit sich gegenseitig ausschließenden Bedingungen belegt sein. Die Ausfu¨hrung terminiert, wenn die Stopaktivita¨t erreicht wurde. Die Aktivita¨ten ko¨nnen entweder durch Codefragmente oder durch Story Patterns beschrieben werden. Story Patterns stellen eine 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 Aktivita¨t 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 vera¨ndert werden soll. In ihm wird definiert, welche Objekte und Links(im Folgenden kurz Elemente genannt) bei einer A¨ nderung neu erzeugt oder gelo¨scht werden sollen. Zudem kann mittels Story Patterns der Wert von Attributen gea¨ndert werden. Elemente, die durch die Anwendung eines Story Patterns gelo¨scht 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 gru¨n dargestellt. Elemente, die nicht gekennzeichnet sind, bleiben bei der Anwendung des Story Patterns unvera¨ndert erhalten. Abbildung 2.10 zeigt ein einfaches Beispiel fu¨r ein Story Pattern. Dieses Story Pattern, moveSimple , beschreibt die Bewegung des Shuttle s von einem Track ( rt1 ) auf den na¨chsten( rt2 ). Fu¨r diese Vorwa¨rtsbewegung des Shuttle s 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 beschriftet). Abbildung 2.10: Story Pattern moveSimple , das die Bewegung eines Shuttle s von einem Track auf den na¨chsten beschreibt Ein Story Pattern kann auf eine Instanzsituation(beschrieben durch ein UMLObjektdiagramm) angewendet werden, wenn alle ungekennzeichneten und mit destroy gekennzeichneten Elemente des Story Patterns auf Elemente des Objektdiagramms abgebildet werden ko¨nnen. Bei der Anwendung werden dann alle mit destroy gekennzeichneten Elemente gelo¨scht und die mit create beschrifteten Elemente erzeugt und zum Objektdiagramm hinzugefu¨ gt. Abbildung 2.11 zeigt ein Beispiel fu¨r ein Objektdiagramm. Das Diagramm stellt die Ontologie eines Shuttle s dar. Sie besteht aus fu¨nf 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 Objektdiagramm 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 gru¨n hinterlegt. Abbildung 2.12 zeigt das Objektdiagramm nachdem das Story Pattern angewendet wurde.

24 KAPITEL 2. GRUNDLAGEN Abbildung 2.11: Beispiel fu¨r ein Objektdiagramm. Die Abbildung des Story Patterns aus Abbildung 2.10 auf dieses Objektdiagramm ist gru¨n hinterlegt Abbildung 2.12: Objektdiagramm aus Abbildung 2.11 nachdem das Story Pattern moveSimple darauf angewendet wurde Mit den bisher vorgestellten Konstrukten la¨sst sich definieren, wann ein Story Pattern angewendet werden kann. Mittels negativer Anwendungsbedingungen kann die Anwendung eines Story Patterns eingeschra¨nkt werden. Im Shuttle -Beispiel sind die Track s so kurz, dass nur jeweils ein Shuttle darauf passt. Befinden sich zwei Shuttle s auf einem Track , so kollidieren sie. Fahren zwei Shuttle s auf aufeinander folgenden Track s, so bedeutet dies, dass die Shuttle s so dicht hintereinander herfahren, dass das hintere Shuttle nicht genu¨gend Zeit zum Reagieren hat, wenn das vordere Shuttle plo¨tzlich bremst. Um einen genu¨gend großen Sicherheitsabstand zu garantieren, der eine solche Kollision vermeidet, wird deshalb verlangt, dass sich zwischen zwei Shuttle s 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 wu¨rde das Shuttle this auf den Track at3 fahren. Da sich Shuttle as2 auf dem Track at4 befindet, wa¨re zwischen den beiden Shuttle s 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 Objektdiagramm angewendet werden, wenn alle positiven Elemente auf Elemente des Objektdiagramms abgebildet werden ko¨nnen, die negativen jedoch nicht. Sobald eines der negativen Elemente auf das Objektdiagramm abgebildet werden kann, ist die Anwendung des entsprechenden Story Patterns nicht mehr erlaubt. In Abbildung 2.13 ist ein Beispiel fu¨r 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 na¨chsten Track weitergesetzt werden darf, wenn sich weder auf dem na¨chsten noch auf dem u¨berna¨chsten 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 spezifizieren. Aufgrund ihrer Ausdruckssta¨rke und ihrer leicht versta¨ndlichen Darstellungsweise eignen sie sich auch dazu, kritische(Instanz-)Situationen und Unfa¨lle zu beschreiben. Dies wird in Abschnitt 3.2.2 dargestellt. 2.3 Modellkomposition Bisher wurde die Modellierung von Komponenten sowie deren Interaktion u¨ber Koordinationsmuster 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 eingefu¨hrt, um das Interaktionsverhalten der Komponenten zu beschreiben. Nun soll betrachtet werden, wie aus diesen Modellteilen ein gesamtes 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 u¨ber 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 Komponenteninstanz sowie eine Instanz des Koordinationsmusters eingefu¨gt. Das Quadrat am Rand der Komponente stellt dann sowohl ihren Port als auch die verfeinerte Rolle des Koordinationsmusters dar. Eine solche Modellierung, bei der das Gesamtmodell aus einzelnen Teilen zusammengefu¨gt wird, wird als kompositionale Modellierung bezeichnet. Die hier vorgestellte kompositionale Modellierung 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 Shuttle s untereinander erfolgt u¨ber eine Instanz des DistanceCoordination -Koordinationsmusters. Die Kommunikation der beiden Shuttle s mit der BaseStation erfolgt u¨ber die beiden Instanzen des Publication -Koordinationsmusters.  ¥!¥"$ # &%'© # ¡¤£ () ¡¤0 ¡6£§¦7£'©32 B #X9 ©Y #`!¥ ©¡ !§9DFE % 9 ¦¢G6©@%'© # ¡¤£ B #X9 ©Y #`!¥ ©¡ 145 ¥!¥"$# %§© # ¡¤£ ¥¥!¥"W#X9 P§¦7 () ¡¤0 ¡¤£§¦1£'©32 9H4I GQP ©R© " ¦ a¦¢%7 £¥£§©¡¥ 8 # 9 ©@%¥£§ ) ¡6¡¥CB # £1%'© # ¡¤£ ¥¥!¥"$# 9 P§¦1 () ¡¤0 ¡¤£§¦1£'©32 S C¡¤£'© 9TU GVP ©R© " ¦ Abbildung 2.14: Modell bestehend aus je drei Komponenten und Koordinationsmustern Wird das Modell auf diese Weise aus Komponenten und Koordinationsmustern zusammengefu¨gt, so muss fu¨r jedes Paar von Komponenten, das sich zur Laufzeit eventuell koordinieren muss, das entsprechende Koordinationsmuster instanziert sein. Da die Ausfu¨hrung eines Kommunikationsprotokolls bedeutet, dass Nachrichten ausgetauscht werden, kann eine Komponente nur mit einer begrenzten Anzahl anderer Komponenten kommunizieren. Hinzu kommt, dass mechatronische 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 na¨chsten Abschnitt das Instanzieren und das Lo¨schen von Koordinationsmustern 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 jedoch 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 mechatronischen System zur Ausfu¨hrung der Software nur begrenzte Ressourcen(CPU, Speicher, etc.) zur Verfu¨gung. Dadurch kann eine Komponente nur mit einer begrenzten Anzahl anderer Komponenten kommunizieren. Fu¨r jedes Paar von Komponenten alle mo¨glichen Koordinationsmuster zu instanzieren, ist somit nicht mo¨glich. Stattdessen du¨rfen nur solche Koordinationsmuster instanziert werden, die zur Laufzeit wirklich beno¨tigt werden. Im Folgenden wird ein Ansatz vorgestellt, der es ermo¨glicht, festzustellen, welche Musterinstanzen zu einem bestimmten Zeitpunkt beno¨tigt werden und die Instanzierung vornimmt bzw. nicht mehr beno¨tigte Instanzen lo¨scht. Mechatronische Systeme sind im Allgemeinen sehr komplex, sodass ihre Modellierung aufwendig ist. Zudem fu¨hrt die Komplexita¨t dazu, dass eine automatische formale Verifikation erschwert oder verhindert wird. Deshalb werden an dieser Stelle soziale Metaphern eingefu¨hrt, die eine zusa¨tzlich Strukturierung des Systems ermo¨glichen. Durch diese zusa¨tzliche Strukturierung wird zum einen die Modellierung des Systems vereinfacht, zum anderen wird dadurch aber auch die Verifikation der Instanzierung und des Lo¨schens von Musterinstanzen ermo¨glicht(siehe Abschnitt 2.4.3). Die Strukturierung erfolgt u¨ber 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 , ­ Absichtserkla¨ rungen , · und Systemeigenschaften. Die oben eingefu¨hrten Komponenten werden in diesem Kontext als Agenten aufgefasst. Eine Menge von Agenten, die die Regeln einer Kultur realisieren, werden in einer Community zusammengefasst. 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 Absichtserkla¨rung teilt der Agent mit, wie er sich in naher Zukunft verhalten wird. Die Systemeigenschaften du¨rfen durch die Anwendung der Regeln nicht verletzt werden. Zu diesen Systemeigenschaften geho¨rt zum Beispiel, dass die Agenten sich nicht anders verhalten du¨rfen als in einer Absichtserkla¨rung versprochen. Andere Eigenschaften beschreiben, dass keine Unfa¨lle und kritische Situationen eintreten du¨rfen. Solche Eigenschaften werden z.B. als

28 KAPITEL 2. GRUNDLAGEN verbotene Story Patterns beschrieben. Das heißt, wenn das verbotene Story Pattern auf ein Objektdiagramm angewendet werden kann, ist ein Unfall oder eine kritische Situation eingetreten. in Nach Storey[Sto96] ist eine kritische Situation (engl. hazard) der Personen, die Umwelt oder Material mo¨glicherweise oder dtaetfisna¨ icehrlticahls g"eefia¨nherdSeittusaitniod"n., Dvoenmngiecghet nbu¨ebabersiicshtteiginte U n n E f r a e ll ig(ennisgsle.na,cdciiedesonwt)o"helindennicThotdboeadbesriVchetrilgettezsunEgreenigvnoisn oder eine Personen Folge sowie Umwelt- oder Materialscha¨den verursachen". Koordinationsmuster stellen eine eingeschra¨nkte Form der Kulturen dar. Sie bestehen aus einer Menge von Rollen und Regeln, die in Form der Kommunikationsprotokolle festgelegt sind. Sie besitzen jedoch keine Subkulturen. Die Protokolle stellen dabei eine Absichtserkla¨rung dar. Die in den Koordinationsmustern spezifizierten Rolleninvarianten und Musterconstraints entsprechen den in der Kultur definierten Systemeigenschaften. Wird ein Koordinationsmuster instanziert, so entspricht dies der Bildung einer Community, wobei den beteiligten Agenten die Rollen des Musters zugewiesen werden. Die Idee besteht nun darin, mit Lo¨sungen fu¨r einzelne kleine Probleme zu beginnen und dann diese Teillo¨sungen zu Gesamtlo¨sungen zusammenzufassen. Koordinationsmuster stellen solche Teillo¨sungen dar. In einer solchen Teillo¨sung ist eine Komponente ein Agent, dem bestimmte Rollen(die Musterrollen) zugewiesen werden. In den oben eingefu¨hrten Real-Time Statecharts ist bereits vorgesehen, dass ein Koordinationsmuster zur Laufzeit instanziert wird(modelliert durch die Zusta¨nde active und inactive ). Somit ist festgelegt, dass die Komponente eine bestimmte Rolle u¨bernehmen kann. Ein Beispiel fu¨r eine Kulturhierarchie ist in Abbildung 2.15 dargestellt. Die oberste Kultur ist die Movement -Kultur, die die ControlledMovement -Kultur als Subkultur besitzt. Die ControlledMovement -Kultur hat zwei Subkulturen, das Publication -Koordinationsmuster und die CoordinatedMovement -Kultur. Diese hat wiederum das DistanceCoordination -Koordinationsmuster als Subkultur. Um die Kulturen der Hierarchie modellieren zu ko¨nnen, muss zuna¨chst die in Abschnitt 2.1.3 eingefu¨hrt 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 eingefu¨gt. Diese Assoziation stellt eine Absichtserkla¨rung dar. Mit ihrer Hilfe kann ein Shuttle den anderen Shuttle s mitteilen, auf welche Track s es als na¨chstes fahren wird. Die Ontologie wird um ein Koordinationsmuster Publication erweitert. Mittels dieses Musters meldet sich ein Shuttle bei der BaseStation an, die den Track u¨berwacht, auf dem sich das Shuttle befindet. Ist ein Shuttle bei einer BaseStation angemeldet, so sendet es in regelma¨ßigen Absta¨nden seine Positionsdaten an die BaseStation . Diese sendet die Daten wiederum an alle bei ihr gemeldeten Shuttle s. Auf diese Weise erfahren die Shuttle s, welche anderen Shuttle s sich in ihrer Na¨he befinden. Erha¨lt die BaseStation die Positionsdaten eines Shuttle s nicht, so warnt sie die anderen Shuttle s, dass dieses Shuttle mo¨glicherweise defekt ist. Durch das Publication -Koordinationsmuster erfa¨hrt ein Shuttle , welche anderen Shuttle s sich in seiner Na¨he befinden. Dies ermo¨glicht eine Koordination zwischen den Shuttle s. Diese Koordination wird durch das DistanceCoordination -Muster spezifiziert. Es stellt die Umsetzung der Subkultur DistanceCoordination dar. Die Rollen dieser Subkultur werden als Assoziationen in die Ontologie eingefu¨gt. Die erweiterte Ontologie ist in Abbildung 2.16 dargestellt.

2.3. MODELLKOMPOSITION @B3a#$ 8 $& 779!!#8©¤A#$ @B"8 ¦$$&£38%'$&¡¤%£)#$C()%0%1$2(3$&¥465 bP$&%'`C©E¥ D$&#0%1$G()$&¥§65 797 ©8 798 &a#$3$hC c¤&c a#%1$¤W6©#Y9¨&`C¦ DWE¨CY` ¦ D¨&` ef%'¦ ¦ x¨C`#$yW¦ h¡C©¦#$CpirqftD©¤u ¥4¥$)5 7 7 ¨G¥4¥Q¦h¦ #3@B$ 8 £3$&% Twh%1¥§¥$ H @B3a#$ 8 $&  D!©E#"¦$C%F¡¤#()0%1$G()$&¥§65 7I7 H¨C$&%1$¥ $G©DD$&$£¤£¤¥Q¥§¦¦¨¨©©¦¦R bP$C%F`C©¤¥ D$&#0%1$G()$&¥§65 ef%'¦ ¦ x¨C`#$yW¦ h¡C©¦#$CpirqftD©¤u ¥4¥$)5 7 #£¤¥Q¦¨2©#¦ £¤¥§¦ ¨©¦ QD!©E#TX"6¦$C¤%F%¡¤H#¦4()C©#0%1D$G$()H$&@B¥§635 a#$ 8 $& 77I7 ¨&H¨C%V$C%1$$2¥ $G©©#DDD$&$3$&SUSUSUTTXT W6Y9¦ D¨&` bP$C%F`C©¤¥ D$&#0%1$G()$&¥§65 798 3a#$&SUT ef%'¦ ¦!¨&`#$dWg¦ h¡C©¦#$Cpirqst!©Eu ¥§¥$)5 7 7 ¦ ¦ 8dc 8dc $& $& H H ¦4#(RTXR¥4¥§¦ 0¦ ¦v#(6TX¥§¥§¦ 0¦ CW6Y9¦ D¨C` SU¦D!©E#¨G$CTwR¤% H ¦4C©#¦ Abbildung 2.15: Beispiel fu¨r eine Kulturhierarchie 29 Abbildung 2.16: Ontologie erweitert um konzeptionelle Elemente

30 KAPITEL 2. GRUNDLAGEN Ein Beispiel fu¨r eine Verhaltensregel der Movement -Kultur ist die Regel moveNext . Die Implementierung dieser Regel ist als Story Pattern in Abbildung 2.17 gegeben. Die Regel beschreibt, dass das Shuttle zwei next -Links besitzt. Ein next -Link zeigt auf den Track , auf den das Shuttle als na¨chstes fahren mo¨chte, und der zweite auf den u¨berna¨chsten Track . Befinden sich auf dem na¨chsten Track und dem u¨berna¨chsten Track keine anderen Shuttle s, so darf das Shuttle auf den na¨chsten Track weiterfahren. Dazu wird der locatedOn -Link zwischen dem Shuttle und dem Track rt1 gelo¨scht 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 na¨chsten Track gesetzt und es wird gleichzeitig festgelegt, auf welchen Track das Shuttle als u¨berna¨chstes fahren mo¨chte. Abbildung 2.17: Beispiel fu¨r die Implementierung der Verhaltensregel moveNext Eine Eigenschaft, die durch die Absichtserkla¨rungen, Instanzierungs- und Verhaltensregeln eingehalten werden muss, ist, dass sich niemals zwei Shuttle s auf dem gleichen Track befinden du¨rfen. Andernfalls sind die beiden Shuttle s kollidiert. Diese Eigenschaft wird durch das verbotene Story Pattern collision in Abbildung in 2.18 modelliert. In dieser Arbeit wird der Begriff verbotene Story Pattern s fu¨r solche Story Patterns verwendet, die kritische Situationen oder Unfa¨lle beschreiben. Der Begriff Story Pattern wird nur fu¨r die Story Pattern verwendet, die Verhaltensoder Instanzierungsregeln beschreiben. Abbildung 2.18: Verbotenes Story Pattern collision In der DistanceCoordination -Kultur wird die eigentliche Abstandshaltung der Shuttle s definiert. 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 createDC und deleteDC dar. Dabei instanziert createDC das DistanceCoordination -Muster und deleteDC lo¨scht 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 Lo¨schen 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 ausgefu¨hrt, das mit this beschriftet ist. Die Regel beschreibt, dass das Koordinationsmuster erzeugt werden muss, wenn auf dem Track auf den das this:Shuttle als u¨berna¨chstes fahren mo¨chte, bereits ein anderes Shuttle ist. Das Koordinationsmuster darf nur dann erzeugt werden, wenn das mit this gekennzeichnete Shuttle noch nicht in einem Koordinationsmuster die rearRole ausfu¨hrt und das mit rs2 beschriftete Shuttle noch nicht die frontRole ausfu¨hrt. Dies verhindert zum einen, dass das Koordinationsmuster mehrfach zwischen den beiden Shuttle s instanziert wird. Zum anderen wird dadurch verhindert, dass das Koordinationsmuster instanziert wird, obwohl sich zwischen den beiden Shuttle s noch ein weiteres Shuttle befindet. Abbildung 2.19: Instanzierungsregel createDC Ein Beispiel fu¨r eine Verhaltensregel dieser Kultur ist die Regel moveDC , die eine koordinierte Fahrt des Shuttle s beschreibt. Koordinieren sich zwei Shuttle s u¨ber eine Instanz des DistanceCoordination -Musters, so darf das hintere Shuttle weiterfahren, wenn zwischen den beiden Shuttle s ein Track frei ist. Dadurch ermo¨glicht das DistanceCoordination -Muster, dass zwei Shuttle s dichter hintereinander herfahren ko¨nnen als ohne das Koordinationsmuster. Diese Regel hat eine ho¨here Priorita¨t als die Regeln der Movement -Kultur. Das bedeutet, wenn die Regel moveDC angewendet werden kann und zeitgleich auch eine Regel der Movement -Kultur, z.B. die Regel moveNext , dann wird immer die Regel mit der ho¨heren Priorita¨t angewendet. Generell gilt fu¨r die Vergabe der Priorita¨ten: Je weiter unten in der Kulturhierarchie eine Verhaltensregel eingefu¨hrt wird, desto ho¨her ist ihre Priorita¨t. Bei den Instanzierungsregeln verha¨lt es sich genau umgekehrt, je weiter oben in der Hierarchie eine Instanzierungsregel steht, desto ho¨her ist ihre Priorita¨t und die Instanzierungsregeln haben eine ho¨here Priorita¨t als die Verhaltensregeln. Die Instanzierungsregeln haben eine ho¨here Priorita¨t als die Verhaltensregeln, da ein Agent erst bei der Instanzierung einer Community seine Rolle und die dazu geho¨rigen Verhaltensregeln zugewiesen bekommt. Die Instanzierungsregeln einer Kultur haben eine ho¨here Priorita¨t 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 u¨bergeordneten Movement -Kultur erfu¨llen. Zum anderen sind in der Kultur zusa¨tzliche Eigenschaften spezifiziert, die die Regeln der Kultur erfu¨llen mu¨ssen. Eine dieser Eigenschaften beschreibt eine kritische Situation, die niemals eintreten darf. Diese kritische Situation besteht darin, dass sich zwei Shuttle s auf benachbarten Track s befinden, jedoch das DistanceCoordination -Muster nicht instanziert haben. In diesem Fall droht eine Kollision der Shuttle s, denn obwohl die beiden Shuttle s mit geringem Anstand hintereinander fahren, kommunizieren sie nicht. Das bedeutet, wenn das vordere Shuttle bremst, hat das hintere unter Umsta¨nden nicht mehr genug Zeit zum Reagieren und die beiden Shuttle s wu¨rden 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 hierarchischen Kulturen erlaubt es, Lo¨sungen fu¨r einzelne Probleme zu entwickeln und diese dann zu einer Gesamtlo¨sung zusammenzusetzen. Die in Abschnitt 2.2.1 eingefu¨hrten Koordinationsmuster stellen eine besondere Form dieser Kulturen dar. Mit Hilfe der Instanzierungsregeln der jeweiligen Kultur wird beschrieben, wann ein Koordinationsmuster instanziert wird bzw. wann eine Musterinstanz gelo¨scht wird.

2.4. VERIFIKATION 33 Zusa¨tzlich zu den Instanzierungsregeln wurden Verhaltensregeln eingefu¨hrt, die sowohl das physikalische als auch das soziale Verhalten der Agenten umsetzen. Wobei die Agenten den in Abschnitt 2.1.2 eingefu¨hrten Komponenten entsprechen. Neben den Absichtserkla¨rungen, Instanzierungs- und Verhaltensregeln enthalten die Kulturen auch eine Menge von Eigenschaften, die entweder in Form von TCTL-Formeln in den Koordinationsmustern angegeben oder in Form von verbotenen Story Patterns definiert werden. Diese Eigenschaften du¨rfen durch die Instanzierungs- und Verhaltensregeln sowie durch die Absichtserkla¨rungen nicht verletzt werden. Im folgenden Abschnitt wird deshalb gezeigt, wie mittels kompositionaler formaler Verifikation nachgewiesen werden kann, dass die Eigenschaften eingehalten 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 eingefu¨hrten Komponenten verfeinern die Rollen der Koordinationsmuster, um die in den Mustern spezifizierten Kommunikationsprotokolle zu realisieren. In Abschnitt 2.3.2 wurden Kulturen eingefu¨hrt, um Systeme bestehend aus Komponenten und Koordinationsmustern zu strukturieren und die Systemkomposition aus einzelnen Teilsystemen zu ermo¨glichen. Die Trennung der Kommunikation vom Komponentenverhalten sowie die Strukturierung des Gesamtsystems durch die Verwendung von Kulturen ermo¨glichen eine kompositionale Verifikation. 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 definiert 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 erfu¨llt. Die U¨ berpru¨fung, ob das Koordinationsmuster die Eigenschaften erfu¨llt, erfolgt durch Model Checking. Da die Semantik von Real-Time Statecharts durch Abbildung auf Timed Automata gegeben ist, ist keine zusa¨tzlich Formalisierung des Modells notwendig. Ein Koordinationsmuster kann durch einen Model Checker, wie zum Beispiel UPPAAL [LPY97] oder RAVEN[Ruf01] gepru¨ft werden. Bei der Verwendung der Koordinationsmuster wird davon ausgegangen, dass die Kommunikation zwischen zwei Kommunikationspartnern eine Punkt-zu-Punkt-Verbindung(engl. pointto-point) dargestellt. Dadurch ko¨nnen Seiteneffekte, die durch eine zusa¨tzliche Kommunikation erzeugt werden ko¨nnen, 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 pru¨ft zum einen, ob das Muster das Musterconstraint einha¨lt und zum anderen verklemmungsfrei ist. Im Beispiel des DistanceCoordination -Musters muss der Model Checker pru¨fen, ob M frontRole || M Konnektor || M rearRole |=( A[] not( rearRole. convoy and frontRole. noConvoy))  deadlock gilt. Dabei bezeichnet M x den Timed Automata, auf den das entsprechende Real-Time Statechart abgebildet wurde und || die Parallelausfu¨hrung von Automaten. 2.4.2 Verifikation der Komponenten Um nachzuweisen, dass eine Komponente korrekt ist, muss gezeigt werden, dass ihre Ports korrekte Verfeinerungen der Rollen darstellen, die Komponente die Rolleninvarianten aller verfeinerter Rollen erfu¨llt 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 erweitert werden. Es darf jedoch kein Verhalten, das durch die Rolle garantiert wird, entfernt oder neues nach außen sichtbares Verhalten hinzugefu¨gt werden. Der Nachweis, dass die Komponente die Rolleninvarianten der verfeinerten Rollen erfu¨llt, erfolgt u¨ber Model Checking. Wie bei der Verifikation der Koordinationsmuster reicht es aus, eine Komponente unabha¨ngig von anderen Komponenten und Koordinationsmustern zu betrachten. Allerdings werden bei dieser Verifikation die entry()-, do()- und exit()-Methoden der Zusta¨nde sowie die Methodenaufrufe der Transitionen nicht beru¨cksichtigt. Fu¨r diese Methoden kann mittels des in[Sei05] vorgestellten Ansatzes die maximale Ausfu¨hrungszeit bestimmt werden. Diese Information kann dann dazu genutzt werden, um zu bestimmen, wie lange das Schalten einer Transition maximal dauert. Diese Zeit wird dann beim Model Checking beru¨cksichtigt. Die Verifikation 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 fu¨r die Rollen nur verlangt wird, dass sie verklemmungsfrei sind, muss fu¨r die Shuttle Komponente gepru¨ft werden, ob M frontPort || M Synch || M rearPort |=  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 a¨hnlich zur Verifikation diskreter Komponenten erfolgen kann. Auch bei dieser Verifikation wird fu¨r die aufgerufenen Methoden, beschrieben durch Story Patterns, mittels des Ansatz von[Sei05] die maximale Ausfu¨hrungszeit 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 mo¨glich 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 Fu¨r jede Kultur wird eine Menge von Eigenschaften spezifiziert, die von Absichtserkla¨rungen, Instanzierungs- und Verhaltensregeln erfu¨llt werden mu¨ssen. 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 u¨bernehmen. Die Organisation der Kulturen in einer Hierarchie ermo¨glicht eine kompositionale Verifikation. Fu¨r eine Kultur muss nachgewiesen werden, dass die in ihr angegebenen Regeln sowie die Regeln aller u¨bergeordneter Kulturen, die Sicherheitseigenschaften einhalten, die in der betrachteten und allen u¨bergeordneten 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 beru¨cksichtigt werden. Somit fu¨hrt die Verwendung der Kulturhierarchie dazu, dass immer nur ein Ausschnitt des Systems verifiziert werden muss. Wurden alle Kulturen erfolgreich verifiziert, so ist auch das Gesamtsystem korrekt. Eine Verifikation, die zeigt, dass alle Regeln des Systems alle Eigenschaften erfu¨llen, ist nicht notwenig 1 . 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 verbotene Story Patterns beschrieben, so wird eine Instanzsituation, beschrieben durch ein UMLObjektdiagramm, als Graph aufgefasst(siehe dazu auch Kapitel 4). Jedes Objekt des Objektdiagramms entspricht dann einem Knoten des Graphen und jeder Link einer Kanten. Die Story Patterns, die die Regeln beschreiben, ko¨nnen dann als Graphtransformationsregeln aufgefasst werden. Fu¨r die Verifikation von Graphtransformationsregeln existieren einige Ansa¨tze(siehe Abschnitt 5.2 und 6). Allerdings sind diese Ansa¨tze dahingehend beschra¨nkt, dass sie zum einen einen Initialgraphen(also eine initiale Instanzsituation) beno¨tigen, zum anderen du¨rfen 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 bekannt. Daru¨ber hinaus ko¨nnen die Regeln der Kultur unendlich viele Graphen erzeugen. Deshalb wird in Kapitel 3 ein neuer Ansatz zur Verifikation von Graphtransformationsregeln vorgestellt, der nicht diesen Einschra¨nkungen unterliegt. Die Objekte eines Story Patterns ko¨nnen 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 Verifikation der Story Patterns, dass beno¨tigte Koordinationsmuster immer vorhanden sind bzw. nicht beno¨tigte Koordinationsmuster gelo¨scht 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 zusa¨tzliche Verifikation des Gesamtsystems ist nicht mehr notwendig. 1 In zuku¨nftigen Arbeiten soll gezeigt werden, dass bei der Verifiaktion einer Kultur nur die Regeln und Eigenschaften verifiziert werden mu¨ssen, 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 verifizierten Koordinationsmuster- und Komponenteninstanzen syntaktisch korrekt zusammengesetzt ist, auch insgesamt korrekt ist. Die Instanzierung und das Lo¨schen der Koordinationsmuster erfolgt durch die Story Patterns. Fu¨r diese Story Patterns wird mit dem in Kapitel 3 vorgestellten Ansatz gezeigt, dass sie die Koordinationsmuster instanzieren, sobald sie beno¨tigt werden bzw. lo¨schen, wenn sie nicht mehr beno¨tigt werden. Allerdings muss noch garantiert werden, dass das komponenteninterne Real-Time Statechart diese Story Patterns immer dann ausfu¨hrt, wenn die Story Patterns auf die Ontologie der Komponente angewendet werden ko¨nnen. Um dies garantieren zu ko¨nnen, muss in jedem Zustand des komponenteninternen Real-Time Statechart jedes der Story Patterns entweder als do()-Methode oder als Seiteneffekt einer ausgehenden Transition ausgefu¨hrt werden. Die in Abbildung 2.9 dargestellte Shuttle -Komponente erfu¨llt 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 Systems modelliert, strukturiert und verifiziert wird. In diesem Abschnitt soll nun der Modellierungsund Verifikationsprozess noch einmal zusammenfassend dargestellt werden. Zuna¨chst(1) wird das Koordinationsverhalten des Systems in Koordinationsmustern spezifiziert. Diese Koordinationsmuster werden(2), wie oben beschrieben, durch Model Checking verifiziert. Ausgehend von den Koordinationsmusters wird die Kulturhierarchie aufgebaut(3). Die Regeln jeder Kultur, die mittels Story Patterns spezifiziert sind, werden(4) durch den in Kapitel 3 vorgestellten Ansatz verifiziert. Als na¨chstes(5) wird das Koordinationsverhalten der Komponenten modelliert. Die Komponenten stellen die Agenten des mechatronischen Systems dar. Dazu wird aus den Koordinationsmustern/Kulturen die Menge der Rollen ausgewa¨hlt, die die Komponente realisieren soll. Die Rollen werden in den Ports der Komponente verfeinert. Die Regeln, die in einer Kultur fu¨r 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) fu¨r jede Komponente nachgewiesen werden, dass sie die Rolleninvarianten der von ihr verfeinerten Rollen erfu¨llt. Nach der Verifikation wird(7) fu¨r 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 na¨chst die Architektur des Operator-Controller-Moduls vorgestellt. Diese Architektur ermo¨glicht eine Strukturierung der Informationsverarbeitung eines mechatronischen Systems und teilt es in die drei Ebenen Controller, reflektorischer Operator und kognitiver Operator ein. Die Software des reflektorischen Operators ist fu¨r 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 gewa¨hlten Ausschnitte auf die Anforderungen bei der Modellierung von mechatronischen Systemen angepasst. Die Architektur der Software wird mittels Komponentendiagrammen und EchtzeitKoordinationsmustern 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 solchen 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 Zusta¨nden aufrufen und Methoden als Seiteneffekte der Transitionen ausfu¨hren. Diese Methoden werden mittels Story Patterns beschrieben. Soziale Metaphern wie Kulturen, Communities und Agenten werden verwendet, um die komplexe Software eines mechatronischen Systems zu strukturieren und die beno¨tigten Story Patterns, die in den komponenteninternen Real-Time Statecharts aufgerufen werden, zu finden. Um garantieren zu ko¨nnen, dass die resultierende Software bestimmte Sicherheitseigenschaften einha¨lt, wird eine kompositionale Verifikation verwendet. Dabei wird jedes Koordinationsmuster und jede Komponente unabha¨ngig von anderen Mustern und Komponenten mittels Model Checking u¨berpru¨ft. 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 eingeschra¨nkte Form von Graphtransformationsregeln darstellen. Das bedeutet, die Verifikation kann mittels Verifikationstechniken fu¨r Graphtransformationssysteme durchgefu¨hrt werden. Fu¨r eine solche Verifikation existieren zwar schon einige Ansa¨tze(siehe Abschnitt 6), diese sind jedoch zur Verifikation der Software mechatronischer Systeme nur eingeschra¨nkt einsetzbar. Dafu¨r gibt es zwei Gru¨nde. Zum einen beno¨tigen diese Verifikationstechniken einen Anfangszustand und zum anderen darf der resultierende Zustandsraum nur endlich sein. Bei der Entwicklung der Software eines mechatronischen Systems soll die Verifikation zum fru¨hestmo¨glichen Zeitpunkt erfolgen, um Fehler im System entsprechend fru¨h erkennen und beheben zu ko¨nnen. Allerdings muss zu diesem Zeitpunkt der Anfangszustand des Systems noch nicht bekannt sein. Daru¨ber hinaus kann fu¨r die Story Patterns, die die Methoden des Systems beschreiben, nicht garantiert werden, dass sie nur endlich viele Zusta¨nde erzeugen. Deshalb soll im folgenden Kapitel ein Ansatz vorgestellt werden, der diesen Einschra¨nkungen nicht unterliegt.

38 KAPITEL 2. GRUNDLAGEN

Kapitel 3 Nachweis induktiver Invarianten Im vorangegangenen Kapitel wurde gezeigt, wie die Softwarearchitektur eines mechatronischen Systems mittels Komponenten- und Klassendiagrammen beschrieben wird. Zudem wurden Echtzeit-Koordinationsmuster eingefu¨hrt, um eine sichere Kommunikation zwischen den Komponenten modellieren zu ko¨nnen. Das Verhalten der Komponenten sowie die Kommunikationsprotokolle der Koordinationsmuster werden durch Real-Time Statecharts spezifiziert. Kulturen und Communities strukturieren die Software eines mechatronischen Systems. Sie ermo¨glichen es, das Gesamtmodell aus kleinen Teilmodellen zusammenzufu¨gen. In einer Kultur werden Regeln fu¨r ihre Teilnehmer festgelegt. Zu diesen Regeln geho¨ren Instanzierungs- und Verhaltensregeln sowie Absichtserkla¨rungen. Die Regeln werden mittels Story Patterns spezifiziert. Sie werden in den Real-Time Statecharts der Komponenten als entry()-, do()- und exit()-Methoden in den Zusta¨nden aber auch als Seiteneffekte der Transitionen ausgefu¨hrt. Damit ein derart spezifiziertes Modell korrekt ist, muss es die in den Kulturen festgelegten Eigenschaften erfu¨llen. Zu diesen Eigenschaften geho¨ren einerseits die als TCTL-Formeln spezifizierten Musterconstraints und Rolleninvarianten der Koordinationsmuster, andererseits ko¨nnen aber auch verbotene Eigenschaften wie kritische Situationen und Unfa¨lle, in Form von verbotenen 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 Verifikation der durch Story Patterns beschriebenen Regeln ermo¨glicht. 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 Objektdiagramm beschrieben werden. Die Story Patterns beschreiben die Zustandsu¨berga¨nge, also das Instanzieren und Lo¨schen von Objekten sowie das Erzeugen und Lo¨schen von Links. Ein Systemzustand ist korrekt, wenn auf das entsprechende Objektdiagramm keines der verbotenen Story Patterns anwendbar ist. Um u¨berpru¨fen zu ko¨nnen, ob ein inkorrekter Zustand durch die Anwendung der Regeln erreicht werden kann, werden die Objektdiagramme als Graphen aufgefasst und die Story Patterns als Graphtransformationsregeln. Der Anfangszustand, der durch einen Initialgraphen repra¨sentiert wird, zusammen mit allen Graphtransformationsregeln bildet dann ein Graphtransformationssystem. 39

40 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN Fu¨r die Verifikation von Graphtransformationssysteme existieren bereits einige Ansa¨tze(siehe Abschnitt 5.2 und Kapitel 6). Diese unterliegen aber den Einschra¨nkungen, dass sie einen Initialgraphen beno¨tigen, um die Analyse durchfu¨hren zu ko¨nnen. Außerdem sind die meisten dieser Ansa¨tze auf Graphtransformationssysteme beschra¨nkt, die nur eine endliche Menge von Graphen erzeugen ko¨nnen. Diese beiden Einschra¨nkungen sind in mechatronischen Systemen im Allgemeinen jedoch nicht erfu¨llt. 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 erzeugen ko¨nnen. Der Ansatz wird in Abschnitt 3.1 zuna¨chst informal erla¨utert, bevor in Abschnitt 3.2 ff. die formale Erla¨uterung erfolgt. Die Beweisskizzen zu den in Abschnitt 3.2 ff. aufgefu¨hrten 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 Ru¨ckwa¨rtsrichtung angewendet. Der dabei entstandene Graph liefert eine Beschreibung, wann die entsprechende Regel nicht angewendet werden darf, und wird als negative Anwendungsbedigung der Regel bezeichnet. Der im Folgenden vorgestellte Ansatz verwendet eine a¨hnliche Technik. Auch dieser Ansatz verbindet die Nachbedingung einer Regel mit einem Graphen, der eine Eigenschaft beschreibt. Allerdings werden die Regeln nicht automatisch vera¨ndert. Findet der Ansatz eine Regel, die inkorrekt ist, so liefert er ein Gegenbeispiel, das zeigt, wann die Anwendung der Regel einen inkorrekten Graphen erzeugen kann. Eine ausfu¨hrliche Diskussion der Unterschiede zwischen den beiden Ansa¨tzen wird in Abschnitt 6.1 gegeben. In diesem Kapitel wird zuna¨chst die Idee des Verifikationsansatzes informal beschrieben(Abschnitt 3.1). In Abschnitt 3.2 werden dann die Grundlagen der Graphtransformationssysteme formal eingefu¨hrt. In dieser Arbeit werden Eigenschaften von Graphtransformationssystemen und Mengen von Graphen mittels Graphmustern beschrieben. Diese werden in Abschnitt 3.3 eingefu¨hrt. Nachdem diese Grundlagen beschrieben wurden, werden die Graphen und Graphtransformationssysteme um Typen erweitert(Abschnitt 3.4). Der Verifikationsansatz verlangt, dass Graphtransformationsregeln auch ru¨ckwa¨rts und auf Graphmuster angewendet werden ko¨nnen. Damit dies mo¨glich ist, sind einige Erweiterungen notwendig, diese werde in Abschnitt 3.5 vorgestellt. Abschnitt 3.6 bescha¨ftigt sich dann mit Systemeigenschaften und beschreibt Einschra¨nkungen, die bei der Verifikation der Graphtransformationssysteme ausgenutzt werden ko¨nnen. Der eigentliche Verifikationsansatz wird dann in Abschnitt 3.7 vorgestellt. 3.1 Die Idee Der in diesem und den folgenden Abschnitten vorgestellte Ansatz ermo¨glicht die Verifikation von Graphtransformationssystemen. Nach der informalen Einfu¨hrung von Graphtransformationssystemen werden Graphmuster zur Beschreibung struktureller Eigenschaften solcher Systeme ein-

3.1. DIE IDEE 41 gefu¨hrt und die Verifikationsidee erla¨utert. Dazu werden sowohl die Graphtransformationen als auch die Graphmuster zuna¨chst so vereinfacht, dass sie keine negativen Anwendungsbedingungen enthalten. In Abschnitt 3.1.5 wird dann die Verifikation von Regeln mit negativer Anwendungsbedingung 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 Vera¨nderung eines Graphen durch Lo¨schen und Hinzufu¨gen von Knoten und Kanten(im Folgenden kurz als Elemente bezeichnet). Eine solche Regel L r R besteht aus einer linken Regelseite L , der Anwendungs - oder Vorbedingung und einer rechten Regelseite R , der Nachbedingung . Jede der beiden wird durch einen Graphen beschrieben. r ist der Name der Regel. Soll eine Graphtransformationsregel auf einen Graphen, den Anwendungsgraphen , angewendet werden, so mu¨ssen alle Elemente der Anwendungsbedingung auf entsprechende Elemente aus dem Anwendungsgraphen abgebildet werden ko¨nnen. Ist dies mo¨glich, so werden alle Elemente, die nur in der Anwendungsbedingung enthalten sind, nicht aber in der Nachbedingung, gelo¨scht. 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 eingefu¨ gt. In Abbildung 3.1 ist ein Beispiel fu¨r eine Graphtransformationsregel gegeben. Diese Regel beschreibt die Vorwa¨rtsbewegung eines Shuttle s rs von einem Track rt 1 auf einen folgenden Track rt 2 . Dazu wird die locatedOn -Kante rlo 1 zwischen rs und rt 1 gelo¨scht und eine neue locatedOn -Kante zwischen rs und rt 2 erzeugt. Die Regel entspricht dem Story Pattern moveSimple in Abbildung 2.10 aus Kapitel 2. ¡£¢¥¤§¦©¨ ¡£¢¥¤§¦©¨ ¡!¤"$#&%'(0)2143 I PRQ©SUTWVYX5Pa`cbdT ¡ gFh¤" 2#i%(&)21p3 ¡56¥¤78¡9%'#A@ ¡5¢BC¤¢B'#0#&&¢D¢D§¡ ¡E(FG¤7H¡9%'#A@ ¡56¥¤78¡9%'#A@ ¡5¢Be¤f¢B'#0#&&¢D¢D§¡ ¡E(FG¤7H¡9%'#A@ 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 erfu¨llt werden 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. Graphmuster beschreiben Teilgraphen. Jeder Graph, der einen solchen Teilgraphen entha¨lt, erfu¨llt das Graphmuster. Deshalb ko¨nnen Graphmuster dazu verwendet werden, Mengen von Graphen zu beschreiben. Es gibt zwei Arten von Graphmustern; die geforderten Graphmuster und die verbotenen Graphmuster . Geforderte Graphmuster mu¨ssen immer erfu¨llt werden. Verbotene Graphmuster du¨rfen nie erfu¨llt werden. Sie stellen kritische Situationen oder Unfa¨lle dar und sind deshalb in dieser Arbeit von besonderem Interesse. Abbildung 3.2 zeigt das verbotene Graphmuster impendingCollisionSimplified . Dieses verbotene Graphmuster besagt, dass eine kritische Situation eingetreten ist, wenn sich zwei Shuttle s auf benachbarten Track s befinden. Dabei handelt es sich um eine Vereinfachung der in Abschnitt 2.1.3 beschriebenen kritischen Situation impendingCollision , bei der sich nie zwei Shuttle s auf benachbarten Track s befinden du¨rfen, die nicht das DistanceCoordination -Koordinationsmuster miteinander ausfu¨hren. £¦¥¨§© §©  ¨£ ¥!#"%$¢&('0)21  EA¦¥!#"%$¢&('0)21 £4¥5768$¢"@9 "%"%(¡3¡G6 &AB¥5768$¢"@9 Abbildung 3.2: Verbotenes Graphmuster impendingCollisionSimplified Ein Graph und somit der durch den Graphen repra¨sentierte Systemzustand ist korrekt, wenn er kein verbotenes Graphmuster entha¨lt, 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 Graphen, da das verbotene Graphmuster impendingCollisionSimplified auf einen Teilgraphen abgebildet 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 Menge von verbotenen Graphmustern zu pru¨fen, stellt die Erreichbarkeitsanalyse dar. Dabei wird zuna¨chst fu¨r den Anfangszustand gepru¨ft, 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 Initialgraph korrekt, so werden alle Graphtransformationsregeln angewendet, deren Anwendungs-

3.1. DIE IDEE 43 '01¤2¥¢354#678¡ £¢¤¦¥§¡£©©  ¤!¥#"%$&'¨) ( '¨¨P0D0£#$ '7R@¥#"A$&'¨)( )¤!¥#0H6'¨¨P0D0£#$ @¥#"A$( '0S6'9@¥F0S6'¨P¨P0 0D£#$ #678¡ #¡£F9E¥§¡£©© #"A$&'¨)( '¨P¨0D0D£¢$ '7Q@¥#"A$( 'GI¥F0H6'¨¨P0D0£#$ (a) Beispiel fu¨r einen Graphen, der im Bezug auf das verbotene Graphmuster impendigCollisionSimplified korrekt ist 6 ¡879¦A@CB£(0ED 6 ¡¥"¦A@TB£(0ED 6 D A7F¦GD(!PHQSR 6 D(!PHQSR 6 79¦#' 6 ¡¤£47F¦¡¤£¢¡¡ 6 !¥"¦#$%&&' £(51¦¨¡©£¢¡¡ £¢¥§¦¨¡©£¢¡¡ (051¦#$%&&' £()1¦¨¡©£¢¡¡ (0)1¦#' !"¦#$%&&' £¢§¦¨¡©£¢¡¡ (b) Beispiel fu¨r einen Graphen, der im Bezug auf das verbotene Graphmuster impendigCollisionSimplified inkorrekt ist Abbildung 3.3: Beispiel fu¨r die Korrektheit bzw. Inkorrektheit von Graphen bedingung erfu¨llt ist, d.h. der Graph, der die Anwendungsbedingung beschreibt, kann auf einen Teilgraphen des Initialgraphen abgebildet werden. Die Anwendung aller mo¨glichen Graphtransformationsregeln auf den Anwendungsgraphen resultiert in einer Menge von Graphen. Fu¨r jeden dieser Graphen muss wieder gepru¨ft 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 Graphtransformationsregeln angewendet, woraus wieder eine Menge von Graphen resultiert. Auch fu¨r diese Menge muss u¨berpru¨ft 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 Graphtransformationsregel 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 gepru¨ft, ob ein inkorrekter Graph erreicht werden kann. Eine solche Analyse ist jedoch nicht immer mo¨glich. Zum einen ist zur Entwurfszeit eines mechatronischen Systems, wenn die Korrektheit der Graphtransformationsregeln gepru¨ft wird, die Menge der Initialgraphen des Graphtransformationssystems noch nicht bekannt bzw. die Menge kann sich noch vera¨ndern. Fu¨r jeden neu hinzugefu¨gten Initialgraphen mu¨sste erneut eine Analyse durchgefu¨hrt werden. Das zweite Problem, das diese Art der Analyse verhindert, ist, dass durch die Anwendung der Graphtransformationsregeln unendlich viele verschiedene Graphen erzeugt werden ko¨nnen, sodass eine U¨ berpru¨fung aller erreichbaren Graphen nicht terminiert. Deshalb wird im folgenden Abschnitt ein Verfahren vorgestellt, das die Korrektheit einer Menge von Graphtransformationsregeln bezu¨glich einer Menge von Sicherheitseigenschaften, die als Graphmuster gegeben sind, auch dann nachweisen kann, wenn die Regeln unendlich viele Graphen erzeugen ko¨nnen und kein Initialgraph gegeben ist. 3.1.4 Nachweis induktiver Invarianten Eine Erreichbarkeitsanalyse ist nur dann mo¨glich, wenn ein Initialgraph gegeben ist und das betrachtete Graphtransformationssystem nur endlich viele erreichbare Graphen besitzt. Deshalb soll im Folgenden ein Verfahren beschrieben werden, das unabha¨ngig von der Erreichbarkeit eines Graphen u¨berpru¨ft, ob eine Graphtransformationsregel ein verbotenes Graphmuster erzeugen kann. Bei dieser Verifikation wird gepru¨ft, ob die Anwendung einer Graphtransformationsregel auf einen korrekten Graphen wieder einen korrekten Graphen erzeugt. Ob die korrekten Graphen zur Menge der erreichbaren Graphen geho¨rt, wird dabei nicht betrachtet. Kann fu¨r alle Regeln gezeigt werden, dass sie, wenn sie auf korrekte Graphen angewendet werden, niemals einen inkorrekten nen Graphmusters eine G in r d a u p k h t e iv n e er In z v e a u r g ia en nt k e o¨dnensenb,estroacshtetlelttednaGs "raNpihcthrta-nAsufoftrrmetaetnio"neisnseysstveemrbsodtaer[GS04, GSK + 06, BGS05a]. Der Ansatz nutzt drei Eigenschaften der Graphtransformationsregeln:(1.) Es muss mindestens ein Element(Knoten oder Kante) im verbotenen Graphmuster geben, das auf ein Element der rechten Regelseite abgebildet werden kann. Andernfalls wu¨rde die Regelanwendung das verbotene 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 vollsta¨ndiger beliebig großer Graphen zu betrachten.(3.) Eine Graphtransformationsregel kann auch ru¨ckwa¨rts angewendet werden, dadurch kann fu¨r einen inkorrekten Graphen gepru¨ft 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 zusa¨tzlich 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 Graphen in den inkorrekten u¨berfu¨hrt. 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 entha¨lt. 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 Graphmusters abgebildet werden, sind blau dargestellt und ihr Name beginnt mit einem m . Elemente, auf die nur Elemente der Regel abgebildet werden, sind gru¨n gekennzeichnet und ihr Name beginnt mit einem r . Solche Elemente, auf die nur Elemente des verbotenen Musters abgebildet werden, sind rot und ihr Name beginnt mit einem v . Alle u¨brigen Elemente sind schwarz und ihr Name beginnt mit a . Wobei m fu¨r Merging steht und eine Verbindung von verschiedenen Graphen beschreibt, v steht fu¨r verboten, r fu¨r Regel und a fu¨r Anwendungsgraph. In Abbildung 3.4 wurde durch die Anwendung der Regel kein Element erzeugt, das zum verbotenen Muster geho¨rt. 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 entha¨lt 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 vs 1 , mt 1 , vt 2 und vs 2 besteht und durch die Regelanwendung nicht beeinflusst wird, zum anderen kann das verbotene Graphmuster aber auch auf den Teilgraphen abgebildet werden, der aus den Knoten rs 1 , rt 1 , mt 1 und vs 1 besteht. Ebenso entha¨lt der resultierende Graph neben dem verbotenen Graphmuster impendingCollision auch ein verbotenes Graphmuster, dass die Kollision von zwei Shuttle s und somit einen Unfall beschreibt. Dieser Teilgraph besteht aus den Knoten vs 1 , mt 1 und vs 2 . Im Gegensatz dazu wurde in Abbildung 3.5 die Kante mlo 1 durch die Anwendung der Regel erzeugt, auf die die Kante vlo 1 : locatedOn abgebildet werden kann. Der Anwendungsgraph war noch korrekt, erst die Anwendung der moveSimple -Regel hat die Kante erzeugt, die das verbotene Graphmuster vervollsta¨ndigt hat und somit den korrekten Graphen in einen inkorrekten u¨ berfu¨ hrt. Zu(2.): Um eine Graphtransformationsregel auf einen Graphen anwenden zu ko¨nnen, mu¨ssen alle Elemente der linken Regelseite auf Elemente des Graphen abgebildet werden. Durch die Anwendung der Regel ko¨nnen nur diese Elemente gelo¨scht werden. Ebenso ko¨nnen nur solche Elemente zum Graphen hinzugefu¨gt 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 ru¨ckga¨ngig gemacht werden. Die dazu notwendigen Einschra¨nkungen werden in Abschnitt 3.5 erla¨utert. Dazu wird die Regel ru¨ckwa¨rts 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 6¡879¦5@BA£"DC V ¡87F¦5@BA£"DC £(§¦¡¤£¢¡¡ "()¦#0%' & EC 57F¦GC PQHR3S V C 57b¦GC PQHR3S 67F¦#$%'& 6¡¤£'79¦¡¤£¢¡¡ a 79¦#$%'& V ¡©£'7F¦¡¤£¢¡¡5 V ¡WX¦5@BA£"DC V C ¨WX¦GC PQHR3S V PWX¦#$%'& ©£!)¦¡©£¢¡¡ "!§¦#$%' & £¢¥§¦¨¡©£¢¡¡ cdfe gihBprqYsut2gwvyxq 2¡U79¦5@BA£"DC V ¡87F¦5@BA£"DC ©£(3¦4¡¤£¢¡¡5 "(§¦#$%'& T79¦#$& EC ¨WX¦GC PQHR3S V C 57F¦GC PQHR3S 6¡¤£'79¦¡¤£¢¡¡5 a 7X¦#$& V ¡©£'7F¦¡¤£¢¡¡5 V ¡WX¦5@BA£"DC V C ¨W§¦GC`S V PWX¦#$& ©£!§¦¡¤£¢¡¡5 "!§¦#$& ©£¢¥)¦¨¡©£¢¡¡ Abbildung 3.4: Die Regel moveSimple transformiert einen inkorrekten Graphen in einen anderen inkorrekten Graphen enthalten sind, werden gelo¨scht 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 Startgraphen u¨berpru¨ft, ob die daraus erzeugbaren Graphen korrekt sind. Im Folgenden wird in umgekehrter Richtung vorgegangen. Das bedeutet, ausgehend von jedem inkorrekten Graphen, der ein verbotenes Graphmuster entha¨lt, wird fu¨r alle Regeln u¨berpru¨ft, ob sie diesen inkorrekten Graphen aus einem korrekten erzeugt haben ko¨nnen. 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 ko¨nnen. Konnte eine solche Regel gefunden werden, so wird diese ru¨ckwa¨rts auf den inkorrekten Graphen angewendet. Der resultierende Graph wird nun auf seine Korrektheit hin u¨berpru¨ft. Entha¨lt dieser Graph kein verbotenes Graphmuster, ist also korrekt, so wurde ein Beispiel gefunden, das zeigt, dass die angewendete Regel das System in einen inkorrekten Zustand u¨berfu¨hren kann. Entha¨lt dagegen der resultierende Graph ebenfalls ein verbotenes Graphmuster, so erzeugt die Regel einen inkorrek-

3.1. DIE IDEE I P94¥2QSR¨¢¡¤¡T7# ©87&¨9@¥A7&B"#$DFEHG ©U¡'9@¥¨§© !¢¥¨!"$#"%'&¨© §© ©6!94¥¨!"$#"%'&¨© I ¡'9V¥¨§© W 19V¥¨1$"#$'%&¨© W 'X4¥2QYR¨¢¡¤¡T7# W 7&5X@¥A7&B"#$DFEHG W ¡CX4¥¨§© (!¢£)¥01$"#"%%&2© £¦¥¨§© !""#$'%&¨© abdc egfShpirqtsUevuxwyi 47 !""#$'%&¨© §©(( ©U¡'9V¥¨§© I P94¥2QYR¨¢¡¤¡T7# I 7&29V¥A7&F`#"DFE)G ©U19@¥¨1$"#"%%&2© I ¡'94¥¨§© W 19V¥¨1$"#$'%&¨© W %X¦¥2QSR¨¢¡¤¡T7# W ¡CX¦¥¨§© W 7&5X4¥A7&F`#"DFE)G £¦¥¨!""#$'%&¨© £¥¨§© $"#$'%&¨© Abbildung 3.5: Die Regel moveSimple transformiert einen korrekten Graphen in einen inkorrekten Graphen ten Zustand aus einem anderen inkorrekten Zustand. Dieser Fall braucht nicht weiter betrachtet zu werden, da nur die Fa¨lle relevant sind, in denen eine Regel einen korrekten Zustand in einen inkorrekten u¨berfu¨hrt. Abbildungen 3.4 und 3.5 zeigen zwei Beispiele, in denen die rechte Regelseite der Graphtransformationsregel 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 ru¨ckwa¨rts angewendet wird. Der obere Graph stellt jeweils den Graphen dar, der resultiert, wenn die Regel ru¨ckwa¨rts angewendet wurde. In Abbildung 3.4 haben die rechte Regelseite und das verbotene Graphmuster nur den Knoten mt 1 gemeinsam, dieser entspricht dem Knoten rt 2 der rechten Regelseite und dem Knoten vt 1 des verbotenen Graphmusters. Die Knoten vs 1 und vs 2 entsprechen den gleichnamigen Knoten des verbotenen Graphmusters und der Knoten rs 1 dem Knoten rs der Regel. Wird die Regel moveSimple auf diesen Graphen ru¨ckwa¨rts 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 u¨berfu¨hrt. 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 u¨berfu¨hrt wird, ignoriert werden. Im unteren Graphen von Abbildung 3.5 haben das verbotene Graphmuster und die rechte Regelseite die beiden Knoten mt 1 und ms 1 sowie die dazwischen verlaufene locatedOn -Kante mlo 1 gemeinsam. Wird auf diesen Graphen die moveSimple -Regel ru¨ckwa¨rts angewendet, so resultiert der obere der beiden in Abbildung 3.5 dargestellten Graphen. Dieser Graph entha¨lt 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 u¨berfu¨hren kann. Bisher wurden immer vollsta¨ndige Graphen betrachtet, um die Korrektheit der Regel zu u¨berpru¨fen. Da es jedoch unendlich viele inkorrekte Graphen geben kann, ist es nicht mo¨glich, fu¨r jeden inkorrekten Graphen und jede Regel zu zeigen, dass die jeweilige Regel den inkorrekten Graphen nicht aus einem korrekten erzeugt haben kann. Stattdessen sollen die bereits zuvor eingefu¨hrten Graphmuster dazu verwendet werden, Mengen von Graphen zu beschreiben. Graphmuster statt vollsta¨ndiger 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 verbotenes Graphmuster enthalten und zum anderen die Elemente der rechten Regelseite. Daru¨ber 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 Elementen, die blau, gru¨n oder rot gekennzeichnet sind. Ein solcher Ausschnitt kann Teil von mehreren, unter Umsta¨nden unendlich vielen, Graphen sein und kann somit dazu verwendet werden, Mengen von Graphen zu beschreiben. Diese Ausschnitte werden als Graphmuster oder genauer als Ergebnisgraphmuster bezeichnet. Da sowohl die Menge der Graphtransformationsregeln als auch die Menge der verbotenen Graphmuster endlich ist und jeder der Graphen aus endlich vielen Knoten und Kanten besteht, ist die Menge der mo¨glichen Ergebnisgraphmuster ebenfalls endlich. Zwei mo¨gliche Ergebnisgraphmuster fu¨r die Regel moveSimple und das verbotene Graphmuster 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, geho¨rt auch der untere Graph aus Abbildung 3.4. Der untere Graph aus Abbildung 3.5 geho¨rt 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 Graphmuster auch die rechte Regelseite entha¨lt und diese mindestens ein Element entha¨lt, das auch Teil des verbotenen Graphmusters ist, kann die Anwendung der entsprechenden Regel das verbotene Graphmuster erzeugt haben. Um festzustellen, ob dies der Fall ist, wird die Regel ru¨ckwa¨rts auf das Ergebnisgraphmuster angewendet. Daraus resultiert wieder ein Graphmuster, das Startgraphmuster . Fu¨r dieses Muster muss nun u¨berpru¨ft werden, ob ein beliebiges verbotenes Graphmuster darauf abbildbar ist. Ist dies nicht der Fall, so wurde ein Beispiel dafu¨r gefunden, dass

3.1. DIE IDEE 49 die angewendete Regel ein korrektes Graphmuster in ein inkorrektes Graphmuster u¨berfu¨hren kann. Fu¨r die Graphen bedeutet dies, dass jeder korrekte Graph, auf den das Startgraphmuster abgebildet 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 Ru¨ckwa¨rtsanwendung der moveSimple Regel auf die im unteren Teil gegebenen Ergebnisgraphmuster. Auf das Startgraphmuster aus Abbildung 3.6 ist das verbotene Graphmuster impendingCollisionSimplified abbildbar, wa¨hrend das Startgraphmuster aus Abbildung 3.7 korrekt ist. "!$# ¥&%('0)21143 5 3 7 # ¥3 7¨@WA21D5BE¨GXH 1 # ¥0Q AC@SR "! ) # ¥ ! )C@F@B5 !! 7 6 !$# ¥&%('0)21143 5 603 7 # ¥3 7¨@WA21D5BE¨GXH U 1 # ¥0Q AV@VR 6 ! )C8P¥ ! )C@F@B5 !T! 7 `a`acb dfe(gh¢i¦p"drqtsuh 6 ! 8P¥&%('0)21143 5 603 7¤89¥3 7¢@BAC1D5FE¨GIH 621D8P¥0Q AC@SR 1 # ¥0Q AV@VR "!$# ¥&%('0)21143 5 £¦¥¨§© 3 7¤89¥3 7¢@BAC1D5FE¨GIH 603 7 # ¥3 7¢@BAC1D5FE¨GIH "! ) # ¥ ! )C@B@B5 !T! 7 U 1 # ¥0Q AV@VR 6 ! ) # ¥ ! )C@B@B5 !T! 7 6 ! 8P¥&%('0)21143 5 603 7Y8P¥3 7¨@WA21D5BE¨GXH 621D8P¥0Q AV@VR Abbildung 3.6: Start- und Ergebnisgraphmuster fu¨r die Regel moveSimple und das verbotene Graphmuster impendingCollisionSimplified , wobei das Startgraphmuster einem inkorrekten Graphmuster entspricht Um nachzuweisen, dass ein Graphtransformationssystem korrekt ist im Bezug auf eine Menge von verbotenen Graphmustern, muss fu¨r jede der Regeln und jedes der verbotenen Graphmuster die Menge aller mo¨glichen Ergebnisgraphmuster gebildet werden. Auf diese Ergebnisgraphmuster wird dann die entsprechende Regel ru¨ckwa¨rts angewendet. Fu¨r jedes dabei resultierende Startgraphmuster muss gepru¨ft werden, ob es ein verbotenes Graphmuster entha¨lt. Gibt es ein Startgraphmuster, das kein verbotenes Graphmuster entha¨lt, so wurde ein Beispiel gefunden, das zeigt, dass die entsprechende Regel ein korrektes Graphmuster in ein inkorrektes Graphmuster u¨berfu¨hren kann. Da dieses Beispiel zeigt, dass eine Regel inkorrekt ist, wird es als Gegenbeispiel bezeichnet. Fu¨r Graphen bedeutet ein derartiges Gegenbeispiel, dass die Regel einen korrekten Graphen, der das Startgraphmuster entha¨lt, durch die Anwendung der betrachteten Regel in einen inkorrekten Graphen u¨berfu¨hrt werden kann, der das Ergebnisgraphmuster entha¨lt. Wurde eine solche inkorrekte Regel gefunden, so muss sie in einem Graphtransformationssystem mit gegebenen Initialgraphen jedoch nicht zwangsla¨ufig einen inkorrekten Zustand erzeugen. Es kann sein, dass es im System keinen erreichbaren Graphen gibt, der das entsprechende Startgraphmuster entha¨lt. Um festzustellen, ob die Regel in einem Graphtransformationssystem

50 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN £¦¥¨§© !¨£"¥#!%$'&(0)%132 TI£G¥@AB&C$ED Q¡FE£"¥¡SC$H$00¡6¡6!¨ UVWUVYX £¦¥@PQ&R$RD `ba8cedgfihQ`qpsrtd 4 ¡FE£G¥¡FC$0$H0¡6¡I! 4 ¡657¥¨§8© 4 !95¦¥#!%$'&(0)%132 4 (57¥@AB&C$ED TI£G¥@AB&C$ED Q¡FE£¦¥¡FC$0$0H¡I¡6! £G¥¨§8© !£G¥#!g$0&C(H)%1w2 £G¥@PQ&R$RD 4 ¡FE£G¥¡FC$0$H0¡6¡I! 4 ¡65¦¥¨§8© 4 !95¦¥#!%$'&(0)%132 4 (57¥@AB&C$ED Abbildung 3.7: Start- und Ergebnisgraphmuster fu¨r die Regel moveSimple und das verbotene Graphmuster impendingCollisionSimplified , wobei das Startgraphmuster einem korrekten Graphen entspricht einen inkorrekten Graphen erzeugt, wa¨re eine Erreichbarkeitsanalyse erforderlich, die jedoch aus den in Abschnitt 3.1.3 genannten Gru¨nden nicht immer mo¨glich ist. In diesem Fall muss die Regel so abgea¨ndert werden, dass ihre Anwendung das verbotene Graphmuster nicht erzeugen kann. Eine solche Korrektur kann beispielsweise mittels des von Heckel und Wagner vorgestellten 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 kritischen Situation und im schlechtesten Fall auch zu einem Unfall fu¨hren. Ein Unfall tritt dann ein, wenn die Regel auf ein Shuttle angewendet wird, obwohl auf dem Track , auf den das Shuttle als na¨chstes fa¨hrt, bereits ein anderes Shuttle ist. Zu einer kritischen Situation fu¨hrt die Regel, wenn sich auf dem u¨berna¨chsten Track ein anderes Shuttle befindet. Um zu vermeiden, dass die Regel in einem der beiden Fa¨lle angewendet wird, wird eine negative Anwendungsbedingung verwendet. Die negative Anwendungsbedingung wird zur linken Regelseite hinzugefu¨gt. Die derart erweiterte Regel sieht dann folgendermaßen aus [ L, L ^ ] r R , wobei L ^ die Menge der Graphen der negativen Anwendungsbedingung ist. Wa¨hrend die linke Regelseite L beschreibt, wann die Regel 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 entha¨lt den Graphen der linken Regelseite, erweitert ihn aber um mindestens einen Knoten oder eine Kante. Ein solcher Graph wird auch als Constraint der negativen Anwendungsbedingung bezeichnet. Fu¨r jeden Knoten eines Constraints gilt, dass er entweder auch zur Anwendungsbedingung geho¨rt oder von ihm ausgehend u¨ber endlich viele Kanten ein Knoten aus der Anwendungsbedingung erreicht werden kann.

3.1. DIE IDEE 51 Ein Beispiel fu¨r 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 na¨chsten Track fahren darf, wenn sich weder auf dem na¨chsten, noch auf dem u¨berna¨chsten Track ein anderes Shuttle befindet. Diese Regel entspricht dem Story Pattern aus Abbildung 2.13. Der Graph L^ 1 verhindert die Weiterfahrt des Shuttle s, wenn sich auf dem na¨chsten Track ein anderes Shuttle befindet. L^ 2 verhindert die Weiterfahrt, wenn sich auf dem u¨berna¨chsten Track ein anderes Shuttle befindet. Durch diese Erweiterung der Regel soll zum einen eine Kollision von zwei Shuttle s 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 Anwendungsgraphen abgebildet werden kann, dies jedoch fu¨r keinen der Graphen aus der negativen Anwendungsbedingung mo¨glich ist. &¡A@B§C354£6798  C@E§F8 GH%6!IGPRQ WYV X §C354£6798  UT¨§F8 GH%6!IGPRQ @B§#%¦2( &¡)£2@S§¡)£ !¥S§#$%¦2( £¦¥¨§©¡¤£ !"§#$&%''( &¡A@S§C354£6798 WbV a §354£6798  C@E§F8 GH%6!IGPRQ `8©S§F8 GH%6!IGPRQ @S§#$&%''( &¡)£2@S§©¡)£ !¥¨§#$%¦2( &¡)£¦¥"§¡)£ !¨§#%¦2( @E§C354£6798  C@E§F8 GH%6!IGPRQ W @B§#$&%''( £2@B§¡¤£ !¥S§#$&%''( £¦¥¨§©¡¤£ e fhg5iYprqts&fvubwxpy d &¡A@B§C354£6798 !"§#$&%''( ©¥S§F8 GH%6!IGPRQ @B§#%¦2( £2@E§¡¤£ !¥¨§#$&%''( &¡)£¦¥"§¡)£ !¨§#%¦2( Abbildung 3.8: Graphtransformationsregel moveSimpleNAC mit negativer Anwendungsbedingung

52 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN Soll eine Regel mit negativer Anwendungsbedingung ru¨ckwa¨rts angewendet werden, so muss die negative Anwendungsbedingung zuna¨chst angepasst werden, da anderenfalls die Nachbedingung der Regel eine negative Anwendungsbedingung ha¨tte, wofu¨r jedoch keine Semantik definiert ist. Die Anwendung einer Regel in Ru¨ckwa¨rtsrichtung entspricht dem Ru¨ckga¨ngigmachen ihrer Anwendung in Vorwa¨rtsrichtung. Wird die negative Anwendungsbedingung nicht transformiert, so kann bei der Ru¨ckwa¨rtsanwendung einer Regel ein Graph resultieren, auf den die Regel in Vorwa¨rtsrichtung auf Grund der negativen Anwendungsbedingung nicht anwendbar ist. Um die negative Anwendungsbedingung einer Regel [ L, L ^ ] r R anzupassen, wird sie zuna¨chst aus der linken Regelseite entfernt. Dann wird die derart reduzierte Regel L r R auf alle Graphen aus der negativen Anwendungsbedingung, also auf alle Graphen aus L ^ , angewendet. Da die Graphen der negativen Anwendungsbedingung immer den Graphen enthalten, der die linke Regelseite beschreibt, existiert auch immer eine Anwendungsstelle fu¨r die Regel. Die resultierenden Graphen werden als negative Anwendungsbedingung zur rechten Regelseite hinzugefu¨gt. Die konvertierte Regel hat dann die Form [ L - 1 , L ^ - 1 ] r - 1 R - 1 . Abbildung 3.9 zeigt die modifizierte Regel aus Abbildung 3.8. Dabei entspricht L - 1 der urspru¨nglichen rechten Regelseite R und L^ 1 1 und L^ 2 1 stellen die transformierte negative Anwendungsbedingung dar. R - 1 entspricht der urspru¨nglichen linken Regelseite L . Neben den Anwendungsbedingungen der Graphtransformationsregeln ko¨nnen auch die verbotenen Graphmuster um negative Anwendungsbedingungen erweitert werden. Ein Beispiel fu¨r ein verbotenes Graphmuster mit negativer Anwendungsbedingung ist in Abbildung 3.10 gegeben. Dieses verbotene Graphmuster beschreibt eine kritische Situation, bei der zwei Shuttle s auf benachbarten Track s fahren, jedoch das DistanceCoordination Koordinationsmuster nicht ausfu¨hren; in diesem Fall droht eine Kollision der beiden Shuttle s. Eine solche kritische Situation ist eingetreten, d.h. ein Anwendungsgraph ist inkorrekt im Bezug auf dieses verbotene Graphmuster, wenn die Anwendungsbedingung des verbotenen Graphmusters auf ihn abgebildet werden kann, dies jedoch fu¨r keinen Graphen der negativen Anwendungsbedingung 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 dargestellt), der Graph der negativen Anwendungsbedingung aber nicht, da zwischen dem Shuttle vs 1 und dem Shuttle vs 2 kein DistanceCoordination -Muster existiert. Im Gegensatz dazu ist der Graph in Abbildung 3.11(b) korrekt. Zwar kann auch auf diesen Graphen die Anwendungsbedingung des verbotenen Graphmusters abgebildet werden, jedoch koordinieren sich die beiden Shuttle s u¨ber das DistanceCoordination -Muster, d.h. auch der Knoten, der das DistanceCoordination -Muster im Graphen der negativen Anwendungsbedingung darstellt, kann auf den Anwendungsgraphen abgebildet werden. Entha¨lt das verbotene Graphmuster eine negative Anwendungsbedingung, so kann die Anwendung einer Graphtransformationsregel auf zwei Arten einen korrekten Graphen in einen inkorrekten u¨berfu¨hren. Zum einen kann sie ein Element erzeugen, auf das ein Teil der Anwendungsbedingung des verbotenen Graphmusters abbildbar ist. Dieser Fall ist identisch dazu, dass eine Regel ohne negative Anwendungsbedingung ein verbotenes Graphmuster erzeugt. Der zweite Fall besteht darin, dass auf den Anwendungsgraph die Anwendungsbedingung eines verbotenen Graphmusters abgebildet werden kann und dies ebenfalls fu¨r einen Graphen der negativen

3.1. DIE IDEE y GIH '¡&3D¥¨§©)0 @¡BA" %C¦¥QA%R!¡¤"#SUTWV (¥¨!#"!$&% §)0 '&£¦¥¨6E7¨9¡@¡BA" %¦¥QA%U9¡¤"!SUTV  ¥¨!#"!$&% £¦¥¨§© y GIH y GIH H (¥26E7¨9¡@¡BA" %¦¥QA%R!¡¤"#SUTWV $ ¥¨6E7¨9¡@¡BA" %C£¦¥QA%R!¡¤"#SUTWV '¡&35¥¨§©)0 '1035¥¨1#!"#&$% '¡¤ ¥¨§)0 '1¦¥¨1#!"!$$% '¡¤£(¥¨§©)0 @¡BA" %¦¥QA%R!¡¤"#SUTWV '¡&3D¥¨§©)0 (¥¨!#"!$&% §)0  ¥C!#"!$&% £ ¥¨§© @¡BA" X Ya`EbdcRegfYihqprctsWuwv GIH F¦GIH %235¥QA%R!¡¤"#SUTWV '¡&3D¥¨§©)0 '1035¥¨1#!"!$$% '¡¤(¥¨§©)0 '1¦¥¨1#!"#&$% '¡¤£(¥¨§©)0 53 Abbildung 3.9: Konvertierung der Regel moveSimpleNAC in die Regel moveSimpleNAC - 1 , sodass sie ru¨ckwa¨rts angewendet werden kann §R© GIH £¦¥¨§© )¨DE¥1)2&3$542687 )0£¦¥1)2&3$542687 !F"%$¢&(' @¥0¡A¢&5&5B¡¤¡C)" £ ¥!#"%$¢&(' GISH "e"#¥1"a5$("fR)b &T¥1UWV ¡C7X$¢&5(Y H )`)"a4bVc7X$¢dV)b7 "i¥0h"a)b79fR)b §© £ ¥¨§© )¨DE¥1)2&3$542687 )0£Q¥1)`&5$¢B426g7 !F"a$X&X' @¥0¡A¢&5&5B¡¤¡C)" £¦¥!F"%$¢&(' Abbildung 3.10: Verbotenes Graphmuster impendingCollision mit negativer Anwendungsbedingung Anwendungsbedingung gilt. Wird nun durch die Regelanwendung ein Element gelo¨scht, auf das ein Element des Graphen der negativen Anwendungsbedingung, jedoch nicht der Anwendungsbedingung, abgebildet werden kann, so ist das verbotene Graphmuster Teil des resultierenden Graphen und dieser ist somit inkorrekt.

54 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN 8 ¡@9A§1BDC©£3FE 8 ¡¥"§1BDC©£3FE 8 E 19G§HE!PRQTS 8 E)¥¨§HE!PRQTS 8 9U§©#$%'& 8 ¡¤£'9A§©¡¤£¦¡¡© 8 !¥"§©#$%'& £56§7¡¤£¦¡¡© £¦¥¨§©¡¤£¦¡¡© §©#$%'& £26§7¡¤£¦¡¡© §©#$& !"§©#$%'& £¦(§)¡0£¦¡¡1 (a) Graph, der in Bezug auf das verbotene Graphmuster impendingCollision inkorrekt ist £i£p¥X£©£¤&¨X !"¥$#&%('¢¤) @(6a¥cbed(6AIf g ¨7¨(£©@!d ¨ £¦¥§¡¤£©¨¢¨ $#%('¢¤) $ ¨$4¥5@7BC ( ¨§1R¥5@7BY (F¦£ 'IE¥`S'6A6AUD2¨(£ (FP£© '¢W3¥(S'6A6AUD2¨(£ '13¥(S'6A6UA2D¨(£ (FP£ '¢V3¥('6U6AUD2¨(£ (FP£© (FP£ 'QT¥§'6U6AA22¨$£ (b) Graph, der in Bezug auf das verbotene Graphmuster impendingCollision korrekt ist Abbildung 3.11: Graphen, die in Bezug auf das verbotene Graphmuster impendingCollision inkorrekt bzw. korrekt sind Die Anwendung der Regel deleteDCSwitch , in Abbildung 3.12 dargestellt, erzeugt auf diese Weise aus einem korrekten Graphen einen inkorrekten. Sie lo¨scht eine Instanz des DistanceCoordination -Musters zwischen zwei Shuttle s, falls das vordere Shuttle an einer Weiche einen anderen Weg fa¨hrt, als das hintere Shuttle fahren mo¨chte(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 lo¨scht jedoch das DistanceCoordination -Muster und erzeugt so einen inkorrekten Graphen bzw. ein inkorrektes Graphmuster, dargestellt im unteren Teil der Abbildung. ¡B¡£¡q¤¦¡%§E)¡r`U5aA§ ¡!$R(Q¤PSUT&FVWA§ ¡£¢¥¤¦¢¨§© ¡BA 5P(Q¤¦A 5D"EF§2GDHI¢ ¡¤¡!"# ¡!G"b¤dcfe$66¢¨"2§)g h 5D5¡!Gaei¢¨pe 5a¢ ¡%XV¡9¤1XV¡!5Y¢F'`U5aA§ ¡4(C¤¡!"# ¡!$6¤PSUT&FVWA§ ¡%$'&)(0¤1$&¨"2"2§3$4$65¡ ¡!$&¨¤$&¨"2"3§2$6$45¡ ¡78¤9¡@¨")# ¡BA 51C¤¦A 5D"EF§2GDHI¢ s tvuUwxuPy2uC9xy2U ` ¡!$R(0¤PSUT&FVWA§ ¡£¢¤¦¢¨§W© ¡BA 5P(Q¤¦A 5D"EF§2GDHI¢ ¡%8¤¡@¨")# ¡%4(0¤¡@¨")# ¡%$48¤PSUT&FVWA§ ¡!$&)(C¤$&¨"2"2§3$4$65¡ ¡!$&¨¤$'&¨"3"2§2$6$65P¡ ¡%7C¤¡!"# ¡£A 58¤¦A 5Y"2¨§3GDH¢ Abbildung 3.12: Regel deleteDCSwitch , die eine Instanz des DistanceCoordination -Musters lo¨ scht Fu¨r diesen zweiten Fall muss eine zusa¨tzliche U¨ berpru¨fung eingefu¨gt werden. Die Graphen der negativen Anwendungsbedingung des verbotenen Musters haben die Eigenschaft, dass jeder ihrer Knoten entweder auch zur Anwendungsbedingung geho¨rt oder ausgehend von diesem Knoten u¨ber eine endliche Menge von Kanten ein Knoten der Anwendungsbedingung erreicht werden kann. Im obigen Beispiel wird der Knoten rdc: DistanceCoordination gelo¨scht. Durch das Lo¨schen von rdc kann der Graph I^C der negativen Anwendungsbedingung des verbotenen Musters impendingCollision nicht mehr auf den resultierenden Graphen abgebildet werden. Der Knoten rdc: DistanceCoordination besitzt zwei Kanten; eine beschriftet mit rrr: rearRole zum Knoten rs 1 : Shuttle und eine zweite beschriftet mit rfr: frontRole zum Knoten rs 2 : Shuttle . Auf diese beiden Knoten ko¨nnen die Shuttle -Knoten der Anwendungsbedingung des verbotenen Musters abgebildet werden. Das bedeutet, wenn ein Knoten gelo¨scht werden soll, auf den ein Knoten eines Graphen der negativen Anwendungsbedingung abgebildet werden kann, aber keines der Anwendungsbedingung, dann muss dieser Knoten mindestens eine inzidente Kante haben, die ebenfalls gelo¨scht

56 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN werden muss. Um eine Kante lo¨schen zu ko¨nnen, muss sie mit beiden zu ihr inzidenten Knoten in der linken Regelseite enthalten sein. Wird der zweite inzidente Knoten ebenfalls gelo¨scht, so gilt auch hier wieder, dass alle inzidenten Kanten durch die Regel entfernt werden mu¨ssen. Es muss allerdings eine Kante geben, die inzident zu einem Knoten ist, der explizit durch die Regel erhalten bleibt, da die Anwendungsbedingung des verbotenen Musters durch die Regelanwendung nicht vera¨ndert wird. Im obigen Beispiel hat der zu lo¨schende Knoten rdc zwei inzidente Kanten, rrr und rfr . Sowohl der zweite zu rrr inzidente Knoten rs 1 als auch der zweite zu rfr inzidente Knoten rs 2 werden 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 fu¨r das Lo¨schen von Elementen Ergebnisgraphmuster zu bilden. Ein solches Ergebnisgraphmuster entha¨lt mindestens einen Knoten, der in beiden Regelseiten und in einem Graphen der negativen Anwendungsbedingung des verbotenen Graphmusters enthalten ist. Abbildung 3.13 zeigt ein mo¨gliches Ergebnisgraphmuster. Das daraus erzeugte Startgraphmuster fu¨r das verbotene Graphmuster aus Abbildung 3.10 und die Graphtransformationsregel deleteDCSwitch ist in Abbildung 3.14 abgebildet. Die beiden Graphmuster stellen ein Gegenbeispiel dar, das zeigt, dass die Regel deleteDCSwitch einen korrekten Graphen in einen inkorrekten u¨berfu¨hren kann. Die Anwendung der Regel fu¨hrt genau dann dazu, dass ein korrekter Graph in einen inkorrekten u¨berfu¨hrt wird, wenn der korrekte Graph, das Startgraphmuster des Gegenbeispiels entha¨lt 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 existierenden Objekte und deren Links. Eine solche Instanzsituation wird in einem Objektdiagramm festgehalten. In diesem Kapitel werden statt der Objektdiagramme Graphen verwendet, sodass ein Systemzustand durch diesen Graphen repra¨sentiert wird. Die U¨ berga¨nge zwischen den Zusta¨nden werden durch Graphtransformationsregeln beschrieben. Im Folgenden wird als erstes ein U¨ berblick u¨ber die grundlegende Terminologie gegeben. Ein Teil der aufgefu¨hrten Definitionen wurden aus anderen Texten, zumeist Graphgrammars"[Roz97], u¨bernommen. Dazu geho¨ren die Definitionen von(dbeemsch"Hrifatnedtebno)oGkroafphen(Definitionen 1 und 2), Graphhomomorphismen und Graphisomorphismen(Definitionen 9 und 10), die Definition eines Matches(Definition 13) und die Definition eines Graphtransformationssystems(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 Literatur vereinfacht bzw. die in den Definitionen verwendeten Graphen und Funktionen unterliegen sta¨rkeren Einschra¨nkungen. Durch die Vereinfachungen und Einschra¨nkungen wird der Verifi-

3.2. GRAPHTRANSFORMATIONSSYSTEME !¦"$#%¥'&)(¨01¡2¡43 5 !`3 Q'#C¥93 QaH1¡¤5Xbacd6 @A¡ "w0#%¥¨"w0XW5X"Y" £¦¥¨§© !¦¡B#C¥¨§© !¦"w08¥¨"w0XX5W"B" !¦¡¤£¦¥¨§© !`3 Qv£e¥93 QaH1¡¤5Xbacd6 !¦"B£¦¥'&)(¨01¡2¡43 5 G ©)QR3 5 !¦"S#C¥'&)(¨01¡2¡43 5 F E !`3 Q'#C¥93 QaH1¡¤5Xbacd6 @A¡ "V0#%¥¨"V0WX5W"B" £U¥¨§© G b¨f¥hgpiq"¤¡Y'6W5sr t QaQ' !¦¡B#%¥¨§© !U"w08¥¨"w0XW5X"Y" !e¡¤£U¥¨§© G1x x )QR3 5 !`3 Qv£e¥93 QaH1¡¤5Xbacd6 !U"Y£U¥'&)(¨01¡2¡43 5 57 Abbildung 3.13: Ergebnisgraphmuster mit negativer Anwendungsbedingung kationsansatz in Abschnitt 3.6 ermo¨glicht. Wurde eine Definition aus der Literatur u¨bernommen und fu¨r die vorliegende Arbeit angepasst, so wird im Folgenden auch der Unterschied zur urspru¨nglichen Definition genannt. Fu¨r den Verifikationsansatz in Abschnitt 3.6 ist es wichtig, dass eine Graphtransformationsregel auch ru¨ckwa¨rts angewendet werden kann. Wird zur Anwendung einer Graphtransformationsregel der Double Pushout Ansatz angewendet, so ist dies immer mo¨glich(siehe[Roz97] Kapitel 3). In dieser Arbeit wird zwar eine eingeschra¨nkte Form des Double Pushout Ansatzes verwendet, jedoch sind fu¨r die linke Regelseite auch negative Anwendungsbedingungen erlaubt. Die Modifikation einer Regel, um diese korrekt ru¨ckwa¨rts anwenden zu ko¨nnen, wird in dieser Arbeit in Definition 29 gegeben. Um bei der Verifikation Aussagen u¨ber Mengen von Graphen machen zu ko¨nnen und strukturelle Eigenschaften von Graphen beschreiben zu ko¨nnen, werden in dieser Arbeit Graphmuster eingefu¨hrt(Definition 19) und die Anwendung von Graphtransformationsregeln auf diese Muster definiert(Definition 30). Die Graphmuster sind a¨hnlich 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 Konsistenztbedingungen wird in Abschnitt 6.1 gegeben). Allerdings werden weder Eigenschaftsgraphen noch Konsistenzbedingungen dazu verwendet, um Mengen von Graphen zu beschreiben.

58 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN ¤U¤2¤435¤§67¤98@¡A 6 Y G`h3 @b¥c 9dA 6 !#" §BC¡£¡¥35¤§DF¦©¨¨GVH¥%¨¡BI 6XP Y A ¡)`a35A ¡£B7V6I¦£ef Y g`h3¥iS¤p%BQq ¤Ux3©%6dy ¤§G c `v3XG c BWBI6IGHGH¡)¤ ¤0Vrs3¥i4¤p%BQq Y G c 3wG c BIBW6IGHGg¡¥¤ Y Vrs3¥i4¤p%BQq ¤ R ¤43 R ¤§¡©T8'¡©A 6 Y A ¡wrt35A ¡BI%V6W¦£eu Y GHrs3 'b¥c 9dA 6 1 ¤2¤435¤§67¤98@¡A 6 ¤U¤2¤S35¤§67¤98@¡A 6 Y G`a3 @b¥c 9dA 6 '#&" 1 ¦¥BC3EDF¨ GHH¥%BI6QP £¡¥¤§¦©¨$%¨ ¡© ¤§¦¥BC3EDF¨GVH)%BW6XP (¡£¡)¤0¦©¨¨¡© Y A ¡)`a35A ¡£B7V6I¦£ef Y g`h3¥iS¤p%BQq ¤Ux3©%6dy ¤§G c `v3wG c BIBW6IGHGg¡¥¤ ¤Vrs3¥iS¤§Bq G Y c 3wG c BIBI6WGgGH¡¥¤ Y Vrs3¥iS¤§Bq 1R ¤S3 R ¤0¡©T8@¡A 6 ¤ R ¤43 R ¤§¡©T8'¡©A 6 Y A ¡Xrt35A ¡BI%V6W¦£eu Y GHrs3 @b¥c 9dA 6 Abbildung 3.14: Startgraphmuster mit negativer Anwendungsbedingung Abschnitt 3.2.1 gibt eine allgemeine Definition fu¨r Graphen und einen U¨ berblick u¨ber die wichtigsten Operationen auf Graphen. Graphtransformationsregeln werden in Abschnitt 3.2.2 erla¨utert. In Abschnitt 3.3 werden Graphmuster eingefu¨hrt, mit denen Mengen von Graphen beschrieben werden ko¨nnen. Mit den eingefu¨hrten Konstrukten kann dann das Systemmodell beschrieben werden(Abschnitt 3.4). Zur Verifikation ist es notwendig, die Graphtransformationsregeln auch ru¨ckwa¨rts und auf Graphmuster anwenden zu ko¨nnen. Deshalb erfolgt in Abschnitt 3.5 eine Erweiterung der Graphtransformationen. Abschnitt 3.6 bescha¨ftigt sich mit strukturellen Eigenschaften eines Graphen. Die Beweise der hier aufgefu¨hrten 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 verbunden 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 · N eine endliche Knotenmenge ist, · E eine endliche Kantenmenge ist, · src: E N eine Funktion ist, die jeder Kante einen Startknoten zuweist und · tgt: E N eine Funktion ist, die jeder Kante einen Zielknoten zuweist. Um die Knoten und Kanten benennen und unterscheidbar machen zu ko¨nnen, werden zwei Alphabete eingefu¨hrt. Eines der Alphabete legt mo¨gliche Beschriftungen fu¨r Knoten fest und das andere Beschriftungen fu¨r Kanten. Mittels zweier Beschriftungsfunktionen(engl. labeling function) ko¨nnen den Knoten und Kanten dann Beschriftungen zugewiesen werden. Die formale Definition fu¨r einen solchen beschrifteten Graphen entspricht der aus[Roz97] und lautet Definition 2.( Beschrifteter Graph ) Gegeben sind zwei Alphabete N und E , fu¨r Knoten- bzw. Kantenbeschriftungen. Ein beschrifteter Graph(engl. labeled graph) ist ein Tupel G=( N, E, src, tgt, l N , l E ) , mit ·( N, E, src, tgt) ist ein Graph wie in Definition 1, · l N : N N ist eine Funktion zur Beschriftung von Knoten und · l E : E E ist eine Funktion zur Beschriftung von Kanten. Dabei sind N G , E G , src G und tgt G wie in Definition 1 definiert. Die Funktionen l N G und l E G stellen knoten- bzw. kantenbeschriftende Funktionen dar. G ist der leere Graph fu¨r den gilt N G = E G = . G ist die Menge aller Graphen. In Abbildung 3.15 ist ein Beispiel fu¨r einen beschrifteten Graphen G:=( N, E, src, tgt, l N , l E ) gegeben 1 . Die vier Knoten an 1 ,..., an 4 bilden die Knotenmenge N:={ an 1 , an 2 , an 3 , an 4 } , ae 1 ,..., ae 4 bilden die Kantenmenge E:={ ae 1 , ae 2 , ae 3 , ae 4 } . Die Funktion src weist jeder der Kanten aus E einen Startknoten zu. Beispielsweise ist an 1 der Startknoten von Kante ae 1 , src ist gegeben durch src:={( ae 1  an 1 ),( ae 2  an 2 ),( ae 3  an 3 ),( ae 4  an 4 )} . Dementsprechend weist tgt den Kanten einen Zielknoten zu tgt:={( ae 1  an 2 ),( ae 2  an 3 ),( ae 3  an 4 ),( ae 4  an 2 )} . Zur Beschriftung der Knoten steht das Alphabet N :={ Shuttle, Track} zur Verfu¨gung, die Kanten ko¨nnen mit E :={ locatedOn, successor} beschriftet werden. Die Beschriftungsfunktion l N weist jedem Knoten aus der Menge N eine Beschriftung aus N zu, l N :={( an 1  Shuttle),( an 2  Track),( an 3  Track),( an 4  Track)} . Genauso weist auch die Funktion l E jeder Kante aus E eine Beschriftung aus E zu, l E :={( ae 1  locatedOn),( ae 2  successor),( ae 3  successor),( ae 4  successor)} . 1 Um die Knoten und Kanten des Graphen referenzieren zu ko¨nnen sind sie mit an 1 ,..., an 4 bzw. ae 1 ,..., ae 4 nummeriert.

60 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN $ ¡¦"!# 3 # ©¨£ 687 '9' % ¡ £ % !&'(¡¦)102¨ 3 # § $¦¡""!©# ¦¡"!# § 3 # Abbildung 3.15: Beispiel fu¨r einen beschrifteten Graphen Teilgraphbeziehungen und Graphoperationen Fu¨r zwei gegebene Graphen G 1 und G 2 kann bestimmt werden, ob die beiden Graphen identisch sind oder einer der beiden Graphen Teilgraph des anderen ist. Die folgenden Definitionen sind jeweils fu¨r beschriftete Graphen angegeben; bei unbeschrifteten Graphen ko¨nnen die fu¨r die Beschriftungsfunktionen angegebenen Bedingungen ignoriert werden. Die beiden Graphen G 1 und G 2 sind identisch , wenn ihre Knoten- und Kantenmengen identisch 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 G 1 , G 2  G sind identisch, wenn gilt: · N G 1 = N G 2 , · E G 1 = E G 2 , · src G 1 = src G 2 , · tgt G 1 = tgt G 2 , · l N G1 = l N G2 und · l E G1 = l E G2 . Der Graph G 1 ist ein Teilgraph von G 2 , wenn die Knoten- und Kantenmengen von G 1 Teilmengen der Mengen von G 2 sind und die Funktionen zur Bestimmung des Start- und Zielknoten einer Kante sowie die beiden Beschriftungsfunktionen eingeschra¨nkt auf die Knoten und Kanten aus G 1 identisch sind. Definition 4.( Teilgraph ) Fu¨r zwei Graphen TG, G G gilt, dass TG ein Teilgraph von G ist, geschrieben TG G , falls gilt · N TG  N G , · E TG  E G , · src TG = src G | E TG , · tgt TG = tgt G | E TG ,

3.2. GRAPHTRANSFORMATIONSSYSTEME 61 · l N TG = l N G | N TG und · l E TG = l E G | E TG . Fu¨r zwei Graphen TG, G G gilt, dass TG ein echter Teilgraph von G ist(geschrieben TG< G ), wenn G mindestens einen Knoten oder eine Kante mehr besitzt als TG , d.h. TG G (| N TG |<| N G | | E TG |<| E G |) . Fu¨r zwei gegebene Graphen kann nicht nur bestimmt werden, ob sie identisch sind oder in einer Teilgraphbeziehung zueinander stehen, sondern sie ko¨nnen auch dazu verwendet werden, einen neuen Graphen zu beschreiben. Dazu ist es jedoch erforderlich, dass fu¨r die 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 Mo¨glichkeit, aus zwei beschriftungskompatiblen Graphen G 1 und G 2 einen neuen Graphen zu erzeugen. Dazu werden die Knoten- und Kantenmengen zu einer Knoten- bzw. Kantenmenge vereinigt. Die Funktionen src , tgt , l N und l E des neuen Graphen entsprechen fu¨r Knoten und Kanten, die in G 1 enthalten sind, den Funktionen von G 1 und fu¨r alle Knoten und Kanten, die nur in G 2 , nicht aber in G 1 auftreten, den Funktionen aus G 2 . Definition 5.( Vereinigung von Graphen ) Die Vereinigung von zwei beschriftungskompatiblen Graphen G 1 , G 2  G ist definiert als G 1  G 2 :=( N, E, src, tgt, l N , l E ) mit · N:= N G 1  N G 2 , · E:= E G 1  E G 2 , · src:= src G 1  src G 2 | ( E G2 \ E G1 ) , · tgt:= tgt G 1  tgt G 2 | ( E G2 \ E G1 ) , · l N := l N G1  l N G2 | ( N G2 \ N G1 ) und · l E := l E G1  l E G2 | ( E G2 \ E G1 ) . Es gilt ( G 1  G 2 )=( G 2  G 1 ) . Fu¨r zwei Mengen X 1 und X 2 sowie zwei Funktionen f 1 und f 2 ist folgendermaßen definiert: f 1  f 2 | ( X 2 \ X 1 ) ( x):= f 1 ( x): x X 1 f 2 ( x): x X 2 \ X 1 A¨ hnlich dazu kann auch durch den Schnitt von G 1 und G 2 ein neuer Graph erzeugt werden. In diesem Fall werden die Knoten- und Kantenmengen geschnitten und die Funktionen src , tgt , l N und l E des neuen Graphen entsprechen den Funktionen aus G 1 , wobei diese auf die Knoten und die Kanten aus dem Schnitt eingeschra¨nkt werden. Definition 6.( Schnitt von Graphen ) Der Schnitt von zwei beschriftungskompatiblen Graphen G 1 , G 2  G ist definiert als G 1  G 2 :=( N, E, src, tgt, l N , l E ) mit · N:= N G 1  N G 2 ,

62 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN · E:= E G 1  E G 2 , · src:= src G 1 | E , · tgt:= tgt G 1 | E , · l N := l N G1 | N und · l E := l E G1 | E . Es gilt ( G 1  G 2 )=( G 2  G 1 ) . Aus den beiden beschriftungskompatiblen Graphen G 1 und G 2 kann auch durch Subtraktion ein neuer Graph gebildet werden. Bei den Knoten wird die Knotenmenge von G 2 von der Knotenmenge von G 1 abgezogen. Wu¨rde die neue Kantenmenge auf die gleiche Weise berechnet, so ko¨nnten 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 urspru¨nglichen Graphen enthalten ist, die entsprechende Kante aber nur in G 1 . Damit der neue Graph der Definition eines Graphen(siehe Definitionen 1 und 2) entspricht, mu¨ssen diese Kanten aus der Menge entfernt werden. Die Funktionen src , tgt , l N und l E des neuen Graphen werden vom Graph G 1 u¨bernommen und auf die neue Knoten- und Kantenmenge eingeschra¨nkt. Definition 7.( Subtraktion von Graphen ) Die Subtraktion von zwei beschriftungskompatiblen Graphen G 1 , G 2  G ist definiert als G 1 \ G 2 :=( N, E, src, tgt, l N , l E ) mit · N:= N G 1 \ N G 2 , · E:={ e ( E G 1 \ E G 2 )| ( src G1 ( e) N tgt G1 ( e) N) } , · src:= src G 1 | E , · tgt:= tgt G 1 | E , · l N := l N G1 | N und · l E := l N G1 | E . Im Allgemeinen gilt ( G 1 \ G 2 )=( G 2 \ G 1 ) . In spa¨teren Definitionen und Sa¨tzen 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 beru¨cksichtigen, so gelangt man zum Zielknoten. Definition 8.( Pfad ) Fu¨r einen gegebenen Graphen G ist ein Pfad definiert als eine endlich Sequenz  N G mit der La¨nge k , wobei  = n 1 , n 2 ,..., n k  N G und fu¨r alle i 1,..., k- 1 existiert ein e i  E G mit ( src( e i )= n i  tgt( e i )= n i+ 1 ) ( tgt( e i )= n i  src( e i )= n i+ 1 ) . Ein Pfad, der am Knoten n 1 beginnt und im Knoten n k endet, wird mit n 1 n k beschrieben. Die La¨nge eines Pfades wird als length( ): N G  NI bezeichnet und entspricht length( ):=| E | , E stellt die Kantenmenge des Pfades dar.

3.2. GRAPHTRANSFORMATIONSSYSTEME 63 Matching von beschrifteten Graphen Nicht immer ist es fu¨r eine Operation erforderlich, dass die beiden beteiligten Graphen identisch 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 Graphhomomorphismus , wie in[Roz97] definiert, beschrieben. Definition 9.( Totaler Graphhomomorphismus ) Fu¨r zwei gegebene Graphen G 1 , G 2  G wird der totale Graphhomomorphismus m: G 1  G 2 beschrieben durch ein Funktionenpaar m:= m N : N G 1  N G 2 , m E : E G 1  E G 2 . Dieser Graphhomomorphismus erha¨lt Start- und Zielknoten von Kanten sowie die Beschriftungen der Knoten und Kanten, d.h. es gilt m N  src G 1 = src G 2  m E , m N  tgt G 1 = tgt G 2  m E , l N G2  m N = l N G1 und l E G2  m E = l E G1 . Fu¨r zwei Funktionen f und g beschreibt ihre Hintereinanderausfu¨hrung, wobei gilt g f( x)= g( f( x)) . Fu¨r zwei Graphen G 1 , G 2  G bezeichnet die Menge M[ G 1 , G 2 ] die Menge aller Graphhomomorphismen zwischen G 1 und G 2 , d.h. G 1 , G 2  G: M[ G 1 , G 2 ]:={ m| m: G 1  G 2 } . Wenn aus dem Kontext hervorgeht, zwischen welchen Graphen die Graphhomomorphismen existieren, wird abku¨rzend M verwendet. Abbildung 3.16 zeigt einen beschrifteten Graphen G:=( N, E, src, tgt, l N , l E ) , bestehend aus der Knotenmenge N:={ rn a , rn b , rn c } , der Kantenmenge E:={ re a , re b } , und den Funktionen src:={( re a  rn a ),( re b  rn b )} , tgt:={( re a  rn b ),( re b  rn c )} , l N :={( rn a  Shuttle), ( rn 2  Track),( rn 3  Track)} und l E :={( re a  locatedOn),( re b  successor)} . Ein Beispiel fu¨r einen Graphhomomorphismus m M[ G, G] zwischen G und dem Graphen G aus Abbildung 3.15 ist m:= m N , m E . Die Funktionen m N und m E sind definiert als m N :={( rn a  an 1 ),( rn b  an 2 ),( rn c  an 3 )} und m E :={( re a  ae 1 ),( re b  ae 2 )} . Betrachtet man zum Beispiel den Knoten rn b und die Kante re a aus G so gilt: m N ( src G ( re a ))= m N ( rn a )= an 1 = src G ( ae 1 )= src G ( m E ( re a )) , m N ( tgt G ( re a ))= m N ( rn b )= an 2 = tgt( ae 1 )= tgt( m E ( re a)) , l N G ( m N ( rn b ))= l N G ( an 2 )= Track= l N G ( rn b ) und l E G ( m E ( re a ))= l E G ( ae 1 )= locatedOn= l E G ( ae a ) . # ¦13 £¦¥§¥©¨ # 13 ¨ ¦¥! # 14 "$# %%&' # £() 14 '0' # # ¦12 "$# (5& Abbildung 3.16: Graph G , fu¨r den ein Graphhomomorphismus in Graph G aus Abbildung 3.15 bestimmt werden soll Ein totaler Graphhomomorphismus m: G 1  G 2 bildet alle Knoten und Kanten aus G 1 auf Knoten und Kanten aus G 2 ab. Dabei muss jedoch nicht auf jeden Knoten und jede Kante aus G 2 ein Knoten oder eine Kante aus G 1 abgebildet werden. Daru¨ber hinaus ist es mo¨glich, dass zwei oder mehr Knoten oder Kanten aus G 1 auf den gleichen Knoten oder die gleiche Kante aus G 2

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 fu¨r den gilt, dass die beiden Funktionen m N und m E bijektiv sind. Im Folgenden wird fu¨r zwei Graphen G 1 , G 2  G und einen Graphisomorphismus iso: G 1  G 2 die Kurzschreibweise G 1 iso G 2 verwendet. Existiert fu¨r die beiden Graphen ein beliebiger Graphisomorphismus, der jedoch nicht na¨her spezifiziert werden soll, so wird dafu¨r G 1  G 2 verwendet. Fu¨r zwei Graphen G 1 , G 2  G bezeichnet die Menge ISO[ G 1 , G 2 ] die Menge aller Graphisomorphismen zwischen G 1 und G 2 , d.h. G 1 , G 2  G: ISO[ G 1 , G 2 ]:={ iso| iso M iso bijektiv } . Bildet der Graphisomorphismus iso den Graphen G 1 auf einen Teilgraphen SG G von G 2 ab( SG G 2 ), so wird iso als Teilgraphisomorphismus bezeichnet. Definition 11.( Teilgraphisomorphismus ) Fu¨r drei Graphen G 1 , G 2 , TG 2  G mit TG 2  G 2 stellt ein Isomorphismus iso ISO[ G 1 , TG 2 ] einen Teilgraphisomorphismus zwischen G 1 und G 2 dar. Fu¨r zwei Graphen G 1 , G 2  G bezeichnet die Menge T ISO[ G 1 , G 2 ] die Menge aller Teilgraphisomorphismen, d.h. T ISO[ G 1 , G 2 ]:={ tiso| TG 2  G: TG 2  G 2 tiso ISO[ G 1 , TG 2 ]} . Existiert fu¨r zwei Graphen G 1 , G 2  G ein Teilgraphisomorphismus tiso T ISO[ G 1 , G 2 ] so wird dies kurz notiert als G 1 tiso G 2 oder G 1 G 2 . 3.2.2 Graphtransformationen Mit den im vorangegangenen Abschnitt eingefu¨hrten Operationen ist es mo¨glich, Graphen zu transformieren, indem Knoten und Kanten aus einem existierenden Graphen gelo¨scht bzw. neue Knoten und Kanten eingefu¨gt werden. Zur Beschreibung einer solchen Graphtransformation werden Graphtransformationsregeln verwendet. Definition 12.( Graphtransformationsregel ) Eine Graphtransformationsregel L r R besteht 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. Fu¨r die beiden Graphen L und R gilt  TL G: TL L TL R TL= G . Die linke Regelseite einer Graphtransformationsregel beschreibt, wann die Regel angewendet werden darf, und wird deshalb auch als Voroder 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 A¨ nderungen gemacht werden sollen. Dabei stellt die Definition 12 der Graphtransformationsregeln eine Vereinfachung der in[Roz97] eingefu¨hrten Definition dar. Nach Rozenberg wird eine Regel gegeben durch r: L m R , wobei r der Regelname ist, L die linke und R die rechte Regelseiten sind. m ist ein Graphhomomorphismus, der einen Teilgraphen von L auf R abbildet. 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 erfu¨llt der Anwendungsgraph die Vorbedingung der Regel. Ein solcher Graphhomomorphismus wird als Match bezeichnet[Roz97]. Definition 13.( Match ) Ein Match m fu¨r einen Graphen L G in einem anderen Graphen G G ist ein totaler Graphhomomorphismus mit m: L G . Ein Beispiel fu¨r eine solche Graphtransformationsregel ist in Abbildung 3.17 gegeben. Diese Regel entspricht der moveSimple -Regel aus Abbildung 2.10. )V6 T ¥!#"$"&%' ) '#(0T )21434)75 69% D8A3H1 @"I'Q3BPS) '3R 8 ' 6 @C@ED ) X (0)7)F6919U 3G5  ¡£¢¥¤§¦©¨¡¦ W )V6 T ¥!#"$"&%' (0)F193G5 )V698 @ )3B' 3 8 ' % D 3Q1 @C@ED ) "I'BPS)R ' U6 (0)F)V19693GU 5 Abbildung 3.17: Beispiel fu¨r eine Graphtransformationsregel Die Regel kann angewendet werden, wenn die drei Knoten nr 1 , nr 2 und nr 3 , sowie die beiden Kanten re 1 und re 2 auf Knoten des entsprechenden Anwendungsgraphen abgebildet werden ko¨nnen. Ein mo¨gliches Matching m ex : L G fu¨r die Regel moveSimple und den Graphen G aus Abbildung 3.18(a) ist m ex := m ex N , m ex E . Dabei ist m ex N :={( rn 1  rn 1 ),( rn 2  rn 2 ),( rn 3  rn 3 )} und m ex E :={( re 1  re 1 ),( re 2  re 2 )} . Das Matching ist in Abbildung 3.18(a) gru¨n hervorgehoben. Existiert ein solcher Match fu¨r eine Regel r und einen Anwendungsgraphen G , so werden alle Knoten und Kanten, auf die der Match die Elemente der linken Regelseite von r abbildet, aber nicht die Elemente der rechten Regelseite, aus G gelo¨scht. Die Knoten und Kanten, die nur in der Nachbedingung der Regel enthalten sind, aber nicht in der Vorbedingung, werden erzeugt und in den Anwendungsgraphen eingefu¨gt. Der resultierende Graph wird als Zielgraph bezeichnet. Die Regelanwendung wird als direkte Transformation bezeichnet und unterliegt verschiedenen Einschra¨nkungen, die in den Pushout Ansa¨ tzen beschrieben sind(siehe Abschnitt 3.4.2). Die folgende Definition fu¨r 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 '¡!( 4 5 1 ¨! 161 ¡5 ) 440 £ ¥§¦©¨  £ !"$#& % ¡ ) !¤0  ( 1 ¨!$ 121 £ ¦ ¨¨ ! ¥ §¦¤¨© ¦"¡# ¥ $¦¨© ¦&% ¨&¨ !! 4 3 1 ¨!$ 121 ) !¤0 '¡!3 $&£ ¨¨& ! ¥ §¦¤¨© % $' ( ¨)¦#012435¡ @9 0A0 ( (a) Graph G auf den die Regel aus Abbildung3.17 angewendet werden soll (b) Graph G , der resultiert, wenn die Regel aus Abbildung 3.17 auf G angewendet wurde Abbildung 3.18: Zwei Graphen G, G , fu¨r die ein Auftreten der Regel aus Abbildung 3.17 existiert, sodass o( L) G und o( R) G gilt Definition 14.( Direkte Transformation ) Gegeben ist eine Graphtransformationsregel L r R und ein Match m fu¨r r in einem Graphen G 1  G , d.h. m: L G 1 . Eine direkte Transformation von G 1 nach G 2 ( G 1 und G 2 sind beschriftungskompatibel) durch eine Graphtransformationsregel r ist definiert als ein Graphhomomorphismus o: L R G 1  G 2 mit o| L = m , sodass gilt: · o( L) G 1 und o( R) G 2 , d.h. die linke Regelseite kann auf einen Teilgraphen von G 1 abgebildet werden und die rechte Regelseite auf einen Teilgraphen von G 2 und · o( L\ R)= G 1 \ G 2 und o( R\ L)= G 2 \ G 1 , d.h. die Anwendung der Regel r lo¨scht genau den Teil von G 1 , auf den Elemente von L aber nicht von R durch o abgebildet werden. Umgekehrt werden durch die Anwendung von r die Elemente aus G 2 erzeugt auf die R durch o abgebildet wird. o wird als Auftreten(engl. occurence) bezeichnet. In Abbildung 3.18 sind zwei Graphen G und G gegeben. Das Auftreten o der Regel aus Abbildung 3.17 ist in den beiden Graphen gru¨n dargestellt. Das oben vorgestellte Matching m ex wird von o verwendet, um die linke Seite der Regel auf G abzubilden. Wird ein Graph G 1 durch eine Regel r und dem Auftreten o von r in G 1 in den Graphen G 2 transformiert, so wird dies beschrieben durch G 1 r, o G 2 oder kurz G 1 r G 2 . Eine Sequenz von direkten Transformationen der Form  =( G 0 |= r 0 , o 0 G 1 |= r 1 , o 1 ...|= r n- 1 , o n- 1 G n ) beschreibt die Transformation eines Graphen G 1 in einen Graphen G n durch die Regeln r 1 ,..., r n- 1 und ihre Auftreten o 1 ,..., o n- 1 . Die Kurzschreibweise fu¨r die Anwendung von einer solchen Sequenz von Regeln ist G 0 |= ( r 0 , o 0 ) ,...,( r n- 1 , o n- 1 ) G n , G 0 |= r 0 ,..., r n- 1 G n oder G 0 |= G n . 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. eingeschra¨nkt werden. Solche negativen Anwendungsbedingungen werden in diesem Abschnitt eingefu¨hrt. In Abbildung 3.17 ist die Regel moveSimple angegeben. Diese Regel beschreibt, dass das Shuttle vom ersten Track rn 2 auf den na¨chsten Track rn 3 weitergesetzt wird. Wird diese Regel auf den Anwendungsgraphen in Abbildung 3.19 so angewendet, dass die Kante locatedOn ae 1 zwischen dem mit Shuttle beschrifteten Knoten an 1 und dem mit Track beschrifteten Knoten an 2 gelo¨scht und zwischen an 1 und Track -Knoten an 5 eine neue locatedOn -Kante erzeugt wird, so wu¨rde die kritische Situation impendingCollisionSimplified (siehe Abbildung 3.2) auftreten, da die beiden Shuttle s an 1 und an 5 auf benachbarten Track s fahren wu¨rden. Um die Regelanwendung in einem solchen Fall zu verhindern, muss die Regel um eine so genannte negative Anwendungsbedingung erweitert werden. Wa¨hrend die bisher betrachteten Anwendungsbedingungen beschreiben, wann eine Regel angewendet werden darf, beschreiben negative Anwendungsbedingungen , wann eine Regel nicht angewendet werden darf. Eine negative Anwendungsbedingung besteht aus einer Menge von Graphen. Jeder dieser Graphen entha¨lt den Graphen der Anwendungsbedingung und erweitert diesen um mindestens einen Knoten oder eine Kante. Gibt es ein Match fu¨r die Anwendungsbedingung in einem Anwendungsgraphen, so muss gepru¨ft werden, ob es fu¨r einen Graphen der negativen Anwendungsbedingung ebenfalls einen Match gibt. Ist dies der Fall, so darf die Regel nicht angewendet werden. §¦ 8@9 $¤A ¨ ©¨¤¦ © 34' !5 !¨" #%$ ¨"#&# ¥' ) 8@9 $¤A ¨ ©¨"£ 34' !5 ©( !¨"( £ #%$ ¨"#&# ¥' 34' !5 !¨6) ©2 #%$ ¨"#&# ¥' 37' §5 ©¨2 ©1 #%$ ¨#0# ¥' 34' §5 Abbildung 3.19: Beispiel fu¨r einen Graphen, bei dem die Anwendung von moveSimple zu einer kritischen Situation fu¨hren kann Definition 15.( Negative Anwendungsbedingung ) Eine negative Anwendungsbedingung(NAB) fu¨r einen Graphen G G ist eine endliche Menge von Graphen G ^ , fu¨r die gilt  G^ i  G ^ : G G^ i und fu¨r alle Knoten n ( N G^ i \ N G ) gibt es einen Pfad i von n zu einem Knoten n G , d.h.  n ( N G^ i \ N G ) n N G , Pfad  : n n . Die Graphen aus G ^ werden als Constraints bezeichnet. Ein solches Constraint G^ i wird durch einen Graphen AG G und einen Teilgraphisomorphismus tiso T ISO[ G, AG] erfu¨llt(geschrieben AG, G, tiso G^ i ), wenn gilt G tiso AG aber  tiso T ISO[ G, AG]: tiso| G = tiso G^ i tiso AG . Ein Graph AG und ein Teilgraphisomorphismus erfu¨llen eine negative Anwendungsbedingung G ^ (geschrieben AG, G, tiso G ^ ), falls AG alle Constraints G^ i  G ^ erfu¨llt, d.h.  G^ i  G ^ :( AG, G, tiso G^ i ) . Auf Grund der Einschra¨nkung, dass ein Auftreten durch einen Teilgraphisomorphismus beschrieben wird, anstelle des sonst u¨blichen Graphhomomorphismus, kann die Definition der negativen Anwendungsbedingung im Vergleich zur Definition in[Roz97] vereinfacht werden.

68 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN Die erweiterte Graphtransformationsregel, moveSimpleNAC , ist in Abbildung 3.20 abgebildet. Die Graphen L^ 1 und L^ 2 stellen die negative Anwendungsbedingung dar. L^ 1 verbietet die Anwendung der Regel, falls sich auf dem na¨chsten Track ein weiteres Shuttle befindet, da es sonst zu einer Kollision ka¨me. L^ 2 verbietet, das Shuttle vorwa¨rts zu setzen, wenn sich auf dem u¨berna¨chsten Track ein anderes Shuttle befindet, da andernfalls die kritische Situation auftreten wu¨rde. Die so vera¨nderte Regel kann nicht mehr auf den Knoten an 1 angewendet und das entsprechende Shuttle somit nicht weiter gesetzt werden. Sie kann jedoch auf den Knoten an 5 angewendet werden, da sich auf den beiden Track s vor diesem Shuttle kein weiteres Shuttle befindet. 9 7A@ Q¥R E 0S0T$ 2 $9%'21&)@(103254'687 9 7CP U 9 (C&AW DIE 9 25P &G&52 DHD % 9 9 7Ca c§b d Q¥R E 0S0T$ 2 $%©&5(C032G4'6!9 2G7 a 9 7CB U 9 (C&AW 9 2Gi DFE &5&G2 DHD % 9 9 71i U 9 (C&AW 9 7A@ Q¥R E 0S0T$ 2 $9%©21&5@(C032G4'6!7 9 7CP U 9 (V&VW DIE 9 25P &G&52 DXD % 9 9 7Ca QfR E 0S0T$ 2 9 2Ge $%'&)(103254'687 9 7CB U 9 (V&VW 9 2Gi DIE &G&52 DHD % 9 chb g 9 71i U 9 (V&VW 9 7A@ Q¥R E 0S0T$ 2 $9%'21&)@(103254'687 9 7CP U 9 (V&VW DIE 9&G25&5P 2 DHD % 9  ¡£¢¥¤§¦©¨¡¦!# " 9 7CP U 9 (V&VW DIE 9&G25&5P 2 DHD % 9 9 7CB 9 7CB U 9 (V&VW DF9 2GE i&5&G2 DHD % 9 9 7A@ Q¥R E 0S0T$ 2 $9%©25&5B(C032G4'6!7 U 9 (V&VW 9DF2GE i&5&G2 DHD % 9 ` 9 71i U 9 (C&AW Y 9 71i U 9 (C&AW Abbildung 3.20: Regel moveSimpleNAC , die die Regel moveSimple um negative Anwendungsbedingungen erweitert Um redundante Informationen zu vermeiden, werden im Folgenden minimale negative Anwendungsbedingungen betrachtet. Angenommen, eine negative Anwendungsbedingung entha¨lt zwei Graphen G^ 1 und G^ 2 und G^ 1 G^ 2 . Wenn es einen Match von G^ 2 in einem Anwendungsgra-

3.3. GRAPHMUSTER 69 phen G gibt, dann kann dieser Match so vera¨ndert werden, dass er auch G^ 1 auf G abbildet. In einem solchen Fall kann G^ 2 aus der negativen Anwendungsbedingung entfernt und die negative Anwendungsbedingung dadurch minimiert werden. Entha¨lt eine negative Anwendungsbedingung kein Graphpaar fu¨r das gilt, dass einer der beiden Graphen durch einen Isomorphismus auf einen Teilgraph des anderen Graphen abgebildet werden kann, so ist die negative Anwendungsbedingung minimal. Definition 16.( Minimale Negative Anwendungsbedingung ) Eine negative Anwendungsbedingung G ^ eines Graphen G ist eine minimale Menge von Graphen, wenn gilt  G^, G^ G ^ : G^= G^ ( tiso T ISO[ G^, G^]: tiso| G = id G  G^ tiso G^) . id G entspricht der Identita¨tsfunktion. 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:=( G Si , R S ) ist ein Tupel mit: · G Si ist die Menge der Initial- oder Startgraphen des Systems und · R S ist eine endliche Menge von Graphtransformationsregeln. Fu¨r ein gegebenes Graphtransformationssystem S:={G Si , R S } bezeichnet REACH( S):= { G 1  G| G 2  G Si : G 2 |= G 1 } die Menge aller in S erreichbaren Zusta¨ nde . Die Definition 17 erlaubt Systeme mit unendlich großem Zustandsraum zu spezifizieren, die als unendliche Graphtransformationssysteme bezeichnet werden. Ein GTS S:={G Si , R S } ist genau dann unendlich, wenn gilt, dass REACH( S) unendlich viele Graphen entha¨lt, die unter Beru¨cksichtigung des Graphisomorphismus verschieden sind, d.h.  G 1  REACH( S),  G 2  ( REACH( S)\ G 1 ): G 1  G 2 . 3.3 Graphmuster Mit den bisher eingefu¨hrten Konstrukten ist es mo¨glich Graphtransformationssysteme zu beschreiben. Daru¨ber hinaus wurde gezeigt, wie eine Regel auf einen Graphen angewendet werden kann, wenn es ein gu¨ltiges Matching fu¨r die linke Regelseite im Graphen gibt. Es ist allerdings noch nicht mo¨glich, strukturelle Eigenschaften zu beschreiben, die bei der Anwendung einer Graphtransformationsregel erhalten bleiben sollen. Zur Beschreibung struktureller Eigenschaften sollen im Folgenden Graphmuster eingefu¨hrt werden. Graphmuster wurden bereits im informalen Abschnitt dieses Kapitels, Abschnitt 3.1, dazu verwendet, die kritische Situation impendingCollision bzw. impendingCollisionSimplified zu spezifizieren.

70 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN Ein einfaches Graphmuster besteht aus einem Graphen G . Ein Anwendungsgraph AG erfu¨llt dieses Muster, falls es einen Teilgraphisomorphismus tiso T ISO[ G, AG] gibt, der G auf einen Teilgraphen von AG abbildet, d.h. G tiso 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 erfu¨llen 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 Ausdruckssta¨rke von Graphmustern kann erho¨ht werden, indem negative Anwendungsbedingungen hinzugenommen werden. Ein solches Graphmuster besteht dann aus einem Graphen P und einer negativen Anwendungsbedingung P ^ , wobei die Menge der Graphen der negativen Anwendungsbedingung leer sein kann. Ein Graphmuster mit negativer Anwendungsbedingung 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^ P ^ durch 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 negativen Anwendungsbedingung, die durch eine mo¨glicherweise 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 zusammen 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 G ^ eine leere Menge ist. Sind zwei Graphmuster p:=[ P, P ^ ] und p:=[ P, P ^ ] gegeben, dann ist p ein Teilgraphmuster von p , wenn die folgenden beiden Bedingungen erfu¨llt sind. Erstens muss es einen Teilgraphisomorphismus tiso T ISO[ P, P] geben, der P auf einen Teilgraphen von P abbildet. Es muss also gelten: P P . Allerdings darf kein Graph der negativen Anwendungsbedingung P ^ durch einen Teilgraphisomorphismus auf einen Teilgraphen von P abgebildet werden ko¨nnen. Zweitens, wenn p nicht erfu¨llt ist, weil einer der Graphen aus P ^ auf einen Anwendungsgraphen abgebildet werden kann, muss es auch einen Graphen in P ^ geben, der auf den Anwendungsgraphen abgebildet werden kann. Das bedeutet, dass es fu¨r jeden Graphen aus P ^ einen Graphen in P ^ gibt, der auf den Anwendungsgraphen abgebildet werden kann. Dies ist genau dann der Fall, wenn es fu¨r jeden Graphen P^ P ^ einen Graphen P^ P ^ gibt, der die folgende Eigenschaft hat. Es gilt, P tiso P . Entfernt man aus P^ alle Elemente, auf die der Teilgraphisomorphismus tiso keine Elemente von P abbildet, so gibt es fu¨r den verbleibenden Graphen einen Teilgraphisomorphismus, der den Restgraphen auf einen Teilgraph von P^ abbildet.

3.3. GRAPHMUSTER 71 Definition 20.( Teilgraphmuster ) Gegeben sind zwei Graphmuster p=[ P, P ^ ] und p=[ P, P ^ ] . p ist ein Teilgraphmuster von p (geschrieben p p ) wenn gilt: · tiso T ISO: P tiso P P, P, tiso P ^ , · P^ P ^ , P^ P ^ , tiso T ISO: tiso - 1 | P = tiso ( P^\( P\ tiso( P))) tiso P^ . Abbildung 3.21 zeigt ein Graphmuster, impendingCollisionExtended , das eine kritische Situation beschreibt. Dieses Muster besagt, dass eine kritische Situation eingetreten ist, wenn sich zwei Shuttle s auf benachbarten Track s befinden, die beiden Shuttle s das DistanceCoordination -Muster nicht miteinander ausfu¨hren, obwohl beide Shuttle s das Publication -Muster mit der gleichen BaseStation ausfu¨hren. Ist ein Shuttle bei einer BaseStation registriert, so muss es in regelma¨ßigen Absta¨nden seine Position an diese senden und erha¨lt die Position der anderen gemeldeten Shuttle s. Das bedeutet, dass die beiden Shuttle s wissen, dass das jeweils andere Shuttle sich in ihrer Na¨he befindet, koordinieren sich aber dennoch nicht. Das Graphmuster impendingCollision ist ein Teilgraphmuster von impendingCollisionExtended . Zum einen gilt, dass die Anwendungsbedingung von impendingCollision mittels eines Teilgraphisomorphismus auf die Anwendungsbedingung von impendingCollisionExtended abgebildet werden kann. Zum anderen ist aber auch die zweite Bedingung fu¨r ein Teilgraphmuster erfu¨llt. Fu¨r den Graph der negativen Anwendungsbedingung I^C existiert ein Graph in der negativen Anwendungsbedingung IC^E , sodass gilt, kann I^C auf einen Anwendungsgraphen abgebildet werden, so kann auch I^C auf den Anwendungsgraphen abgebidelt werden. Entfernt man aus IC^E alle Elemente, die in ICE vorkommen, aber nicht in IC (dies sind die Knoten vn 5 , vn 6 und vn 7 sowie die Kanten ve 4 , ve 5 , ve 6 , ve 7 , ve 8 und ve 9 ) so erha¨lt man einen Graphen, der isomorph zum Graphen I^C ist 2 . Fu¨r ein Graphmuster p:=[ P, P ^ ] beschreibt G[ p] die Menge aller Graphen, die das Muster p erfu¨llen, d.h. G[ p]:={ G G| tiso T ISO: P tiso G G, P, tiso P ^ } . Die Kurzschreibweise dafu¨r, dass ein Graph G ein Muster p erfu¨llt, ist G|= p . Gegeben sind zwei Graphmuster p:=[ P, P ^ ] und p:=[ P, P ^ ] . Ist p ein Teilgraphmuster von p , so erfu¨llt ein Graph G G , der das Graphmuster p erfu¨llt, auch p . Dies ist in der Implikation B.1 von Lemma 1 festgehalten. Gibt es andererseits einen Graphen G G , der p erfu¨llt, p aber nicht, so folgt daraus, dass p kein Teilgraphmuster von p sein kann. Dieses Ergebnis wird in der Implikation 3.2 zusammengefasst. Eine Beweisskizze fu¨r dieses und die folgenden Lemmata und Theoreme ist in Anhang B gegeben. Lemma 1.( Implikation von Teilgraphmustern ) Fu¨r zwei Graphmuster p und p gilt: ( p p) ( G G[ p]: G|= p) und(3.1) ( G G[ p]: G|= p) ( p p) (3.2) 2 Es gilt auch, dass impendingCollisionSimplified ein Teilgraphmuster von impendingCollision ist

72 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN ¤¦¥¨§©© 9 (#P 9 (!@ 9 QP 02D ©G 3IH ( !#" 9 (B ¤¦¥¨§©© 9 DA 02D ©G 3IH ( ' § F 'S'T0¨ 9 D@ !#" 9 (!A £ ¡ 8E¦0 $&%' ©( ! #) ¡1020¨435% ( © %60 ( 9 (C 9 FB 9 FC R 70 (© E¦0 9 (#P 9 (!@ ¤¦¥¨§©© 9 QP 02D ©G 3IH ( 9 (B ¤¦¥¨§©© 9 DA 02D ©G 3IH ( !#" ' § D 'S'T0¨ 9 D@ 788" 9 (!A (a) Graphmuster impendingCollision ¡£¢¦¤ P )%QR P 9QU 6 ¨7 24§©8H P ) QY h ¨7 24"$32 5) P )%QS P QW '524§&$AB2C7¨%$&D 1 8¨%$g$ P ) QU 1 8¨%$g$ !#"%$&'!(0) P QR !#"%$&'!(0) P 9QT P ) QT i p"Hq §©¨§§ P QS i p"Hq P QV ` 5)a2$&G§ ` 5)a2$&Db§ P QX t "§us 1 $"%$3245) P )%QX P 9QY 6 ¨7 2§98@ P ) QV h ¨7 24#"%$324E) P Qc '524§&$AB2C7¨%$&D ¡£ ¤ r 2§$")Hs P )%QW ¢ !G'52£)@"%$324E) P QRwv G"Hgex P QRgR d b5)%$9ef P )%QR P )%QU 1 8¨%$g$ 1 8¨%$g$ P QU 6 ¨7 2§98@ P ) QY h ¨7 24"$32 5) P ) QS E"$&'!(F) P QR i p"Hq §©¨§§ P 9QS !#"%$&'!(0) P QT P )%QT i p"Hq P 9QW '524§&$AB2C7¨%$& P QV ` 5)a2$&b§ ` E)a2$&G§ t "§Hs 1 $"$32 5) P QX P )%QX P QY 6 ¨7 24§©8H P )%QV h ¨7 24"$32 5) P Qc '52§$AI2£7¨%$& (b) Graphmuster impendingCollisionExtended Abbildung 3.21: Beispiel fu¨r ein Graphmuster und ein Teilgraphmuster 3.4 Das Systemmodell Erweitert man die in Definition 17 eingefu¨hrten 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 bestimmten 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 U¨ berga¨nge von einem Zustand zu einem anderen werden mittels Graphtransformationsregeln gegeben. Das Klassendiagramm wird formalisiert, indem die Klassen auf Knoten und die Assoziationen auf Kanten abgebildet werden. Klassennamen und Assoziationsnamen werden mittels der Knoten- und Kantenbeschriftungsfunktionen den Knoten und Kanten zugewiesen. Um die Graphtransformationssysteme mo¨glichst einfach zu halten, werden Kardinalita¨ten und Vererbung hier nicht beru¨cksichtigt. Ein Klassendiagramm kann auf einen Graphen G :=( N , E , src , tgt ) abgebildet werden. Dieser Graph G dient dann als Typgraph . Die Menge der Knotentypen, bzw. das Alphabet zur Beschriftung von Knoten, N ist definiert als N = N , ebenso ist die Menge der Kantentypen E definiert 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 BaseStation , Track und Shuttle . Diese Knoten entsprechen den gleichnamigen Klassen des Klassendiagramms. Ebenso entha¨lt der Typgraph drei Kanten, die mit locatedOn , monitors und successor beschriftet sind. Die Kanten entsprechen den Assoziationen des Klassendiagramms, wobei die Assoziationsnamen nun als Kantenbeschriftungen dienen. Die Kardinalita¨ten, die im Klassendiagramm angegeben sind, fallen im Typgraphen weg. £¦¥¨§©¡© A B©)C5D£ 6758¡¤&@9 £3!¤&4&¨¥4£¦£"5 $'&(¡©)¥¨0'12 §"!©#©%$ ¥ (a) Klassendiagramm, das die vereinfachte Systemontologie beschreibt (b) Typgraph fu¨r das Klassendiagramm in Abbildung 4.1(a) Abbildung 3.22: Einfaches Klassendiagramm und der dazugeho¨rige Typgraph Nach der Abbildung des Klassendiagramms auf einen Typgraphen entspricht ein UMLObjektdiagramm einem beschrifteten Graphen. Jeder Knoten des beschrifteten Graphen entspricht einem Objekt des Objektdiagramms und jede Kante einem Link. Fu¨r diese Graphen muss garantiert werden, dass ihre Beschriftung konform zum Typgraphen und somit zum urspru¨nglichen Klassendiagramm ist. Ein Knoten ist typkonform , wenn seine Beschriftung einem Typ des Typgraphen entspricht. Eine Kante ist typkonform , wenn ihre Beschriftung mit einer Kantenbeschriftung aus dem Typgraphen u¨bereinstimmt und wenn die

74 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN Beschriftung des Start- und Zielknotens mit den Typen u¨bereinstimmen, die vom Typgraphen verlangt werden. Um Knoten und Kanten besser referenzieren zu ko¨nnen, erhalten sie zusa¨tzlich einen eindeutigen Namen; dieser hat jedoch keinen Einfluss auf die auf den Graphen angewendeten Operationen. Der Name eines Knoten oder einer Kante steht immer c v o o r r re e c i t n T e y m pe " d :" E , dg w e a¨ s h ( G re n ) d := der {( T sr y c p ( d e e ) m , e, " t : g " t f ol ( g e t ) . ) Die Menge  N × E der typkonformen Kanten × N } definiert. Ein Graph ist als ist typkonform , wenn die Knoten- und Kantenbeschriftungsfunktionen nur Beschriftungen zuweisen, die im Typgraph definiert sind und wenn alle Kanten typkonform sind. Formal ist die Typkonformita¨t definiert als: Definition 21.( Typkonformita¨ t von Graphen ) Die Beschriftung eines Graphen G:=( N, E, src, tgt, l n , l E ) ist genau dann typkonform zu einem Typgraph G :=( N , E , src , tgt ) , wenn gilt: l N : N N N  N und l E : E E E  E (3.3)  e E:( l N ( src( e)), l E ( e), l N ( tgt( e))) correctTypedEdges( G ). (3.4) Die Menge aller Graphen, die typkonform zum Typgraphen G sind, wird mit G[ G ] bezeichnet. Anhand des Typgraphen G ko¨nnen UML-Objektdiagramme auf typkonforme beschriftete Graphen abgebildet werden. Wird eine Graphtransformationsregel auf einen typkonformen Graphen 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 Typkonformita¨t erha¨lt, wenn der Anwendungsgraph, der Graph der linken Regelseite, inklusive der negativen Anwendungsbedingung sowie der Graph der rechten Regelseite typkonform sind. Definition 22.( Typkonformita¨ t von Graphtransformationsregeln ) Eine Graphtransformationsregel r R S eines Graphtransformationssystems S:=( G S , G Si , R S ) ist genau dann typkonform zu G , wenn alle in r enthaltenen Graphen ( L , L ^ und R ) typkonform zu G sind. Damit eine Regelanwendung typkonform erfolgen kann, muss die Vereinigung, der Schnitt, die Subtraktion und das Matching von Graphen die Typkonformita¨t erhalten. Da bei keiner der vier Operationen neue Knoten oder Kanten entstehen, erfu¨llen 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 einer typkonformen Graphtransformationsregel auf einen typkonformen Graphen wieder in einem typkonformen Graphen resultiert. Theorem 1. (Erhaltung der Typkonformita¨ t) Fu¨r jeden typkonformen Graphen G 1  G und jede typkonforme Graphtransformationsregel [ L, L ^ ] r R gilt: falls ein G 2  G existiert, mit G 1 |= r G 2 , so ist auch G 2 typkonform.

3.4. DAS SYSTEMMODELL 75 3.4.2 Graphtransformationen zur Beschreibung von Zustandsa¨nderungen Nach Definition 14 kann eine Graphtransformationsregel [ L, L ^ ] r R auf einen Graphen G angewendet werden, falls es einen Match m M[ L, G] gibt, der L auf G abbildet, der aber nicht so erweitert werden kann, dass er ein L^ L auf G abbildet. Zusa¨tzlich zu dieser Bedingung kann es zwei weitere Bedingungen geben, die die Anwendung einer Regel einschra¨nken. 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 abbildet. Rozenberg verlangt in[Roz97] dagegen nur einen Graphhomomorphismus. Bei einem Homomorphismus kann es vorkommen, dass zwei Knoten der linken Regelseite auf einen Knoten des Anwendungsgraphen abgebildet werden. Wenn einer der beiden Knoten durch die Regel gelo¨scht, der andere jedoch durch die Regel erhalten werden soll, so entsteht ein Konflikt. Nach [Roz97] verlangt die Identifikationsbedingung fu¨r einen Knoten, der gelo¨scht 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 ^ ] r R , ein Anwendungsgraph G G und ein Match m: L G , wobei fu¨r m gilt  L^ L ^ , m: L^ G m| L = m . Die Identifikationsbedingung(engl. identification condition) verlangt, dass  n ( N L \ N R ), n N L : n= n m( n)= m( n) . Die starke Identifikationsbedingung verlangt, dass grundsa¨tzlich keine zwei Knoten der linken Seite auf den selben Knoten des Anwendungsgraphen abgebildet werden du¨rfen. Definition 24.( Starke Identifikationsbedingung ) Gegeben ist eine Graphtransformationsregel [ L, L ^ ] r R , ein Anwendungsgraph G G und ein Match m: L G , wobei fu¨r m gilt  L^ L ^ , m: L^ G m| L = m . Die starke Identifikationsbedingung verlangt fu¨r r und m , dass gilt  n, n N L : n= n m( n)= m( n) . Die Verwendung von Teilgraphisomorphismen zur Beschreibung der Matchings und des Auftretens einer Regel in einem Anwendungsgraphen fu¨hrt dazu, dass die starke Identifikationsbedingung erfu¨llt ist. Auf diese Weise wird der oben beschriebene Konflikt beim Lo¨schen eines Elements verhindert. Auch die Lose-Kanten-Bedingung dient dazu, Konflikte beim Lo¨schen von Knoten zu vermeiden. Diese Bedingung verlangt, dass durch das Lo¨schen von Knoten keine Kanten entstehen, denen der Start- oder Zielknoten fehlt(Kanten, die keinen Start- oder Zielknoten besitzen, werden als lose Kanten 3 bezeichnet). D.h. die Lose-Kanten-Bedingung fordert, dass Kanten, die zu einem zu lo¨schenden Knoten inzident sind, ebenfalls durch die Regel gelo¨scht werden. 3 Im Deutschen wird der Begriff meistens mit ha¨ ngende Kanten u¨bersetzt. 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 ^ ] r R und ein Auftreten o mit L o G , außerdem gilt  L^ L ^ , o: o| L = o L^ o G . Die Lose-Kanten-Bedingung verlangt, dass fu¨r die Regel r , den Anwendungsgraphen G und das Auftreten o gilt  e E G , e E L : o E ( e)= e ( src( e) ( N L \ N R ) tgt( e) ( N L \ N R )) . Ein Ansatz, in dem sowohl die Identifikationsbedingung als auch die Lose-KantenBedingung erfu¨llt sein mu¨ssen, damit eine Regel angewendet werden darf, ist der Double Pushout Ansatz (DPO,[Roz97] Kapitel 3). Damit die Lose-Kanten-Bedingung erfu¨llt ist, darf eine Regel nur dann angewendet werden, wenn alle Kanten, die zu einem zu lo¨schenden Knoten inzident sind, ebenfalls von der Regel gelo¨scht werden. Dem gegenu¨ber steht der Single Pushout Ansatz (SPO, siehe[Roz97] Kapitel 4). Im SPO muss weder die Identifikationsbedingung noch die Lose-Kanten-Bedingung erfu¨llt sein, damit eine Regel angewendet werden darf. Damit bei der Regelanwendung wieder ein Graph resultiert, der keine losen Kanten entha¨lt, mu¨ssen solche Kanten nach der Regelanwendung gelo¨scht werden. Zusa¨tzlich bietet der Single Pushout Ansatz die Mo¨glichkeit, negative Anwendungsbedingungen zu formulieren, was im Double Pushout Ansatz nach[Roz97] nicht mo¨glich ist. Nach Habel, Heckel und Taentzer[HHT96] ko¨nnen negative Anwendungsbedingungen aber auch im Double Pushout Ansatz verwendet werden. Wenn ein Shuttle zwei Publication -Muster ausfu¨hrt, so wird durch die Graphtransformationsregel in Abbildung 3.23(a) eine Instanz des Musters gelo¨scht. Fu¨r die zu lo¨schende Instanz ist in der Regel jedoch nicht spezifiziert, mit welcher BaseStation dieses Muster ausgefu¨hrt wird. Abbildung 3.23(b) zeigt einen Graphen, auf den die Regel angewendet werden soll. Ein Matching m:= m N , m E , das die(starke) Identifikationsbedingung erfu¨llt, sieht folgendermaßen aus: die Funktion m N bildet keine zwei Knoten der linken Regelseite auf den selben Knoten des Anwendungsgraphen ab, m N :={( rbs 1  abs 1 ),( rp 1  ap 1 ),( rt 1  at 1 ),( rs 1  as 1 ),( rp 2  ap 2 )} . Ebenso bildet die Funktion m E keine zwei Kanten der linken Regelseite auf eine Kante des Anwendungsgraphen ab, m E :={( rd 1  ad 1 ),( rpub 1  apub 1 ),( rlo 1  alo 1 ),( rpub 2  apub 2 )} . Die Anwendung der Regel unter Verwendung dieses Matchings wu¨rde dazu fu¨hren, dass der Knoten ap 2 gelo¨scht wird. Allerdings wird mit apub 2 nur eine der zu ap 2 inzidenten Kanten gelo¨scht. Die Kante ad 2 bleibt 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 ad 2 noch gelo¨scht werden. Ein weiteres Matching m:= m N , m E , das die Identifikationsbedingung jedoch nicht erfu¨llt, bildet die beiden Knoten rp 1 und rp 2 der linken Regelseite auf den Knoten ap 1 des Anwendungsgraphen ab, m N :={( rp 1  ap 1 ),( rp 2  ap 1 ),( rs 1  as 1 ),( rbs 1  abs 1 ),( rt 1  at 1 )} . Auch die Funktion m E bildet zwei Kanten der linken Regelseite auf die selbe Kante des Anwendungsgraphen ab, m E :={( rpub 1  apub 1 ),( rpub 2  apub 1 ),( rd 1  ad 1 ),( rlo 1  alo 1 )} . In diesem Fall ist die Identifikationsbedingung nicht erfu¨llt 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 ap 1 und die Kante ap 2 durch die Regelanwendung sowohl erhalten, als auch gelo¨scht werden sollen. Dadurch, dass im DPO sowohl die Identifikations- als auch die Lose-Kanten-Bedingung erfu¨llt sind, ko¨nnen Regeln auch ru¨ckwa¨rts angewendet werden, was einem Ru¨ckga¨ngigmachen

3.4. DAS SYSTEMMODELL 77 £¦¥¨§©¤£!#"%$ @§)R%#£'c¡)(Q" '&7¥¨§2EF()¡)3G H!#"%$ &)()¡7¥@§2&)()¡)3G#£ '&¤01§EF()¡)3G H!#"%$ '&)()¡¤01§2&)()¡)34#£ §)`¤H7a "A¥I§23"HP¤QSRUTV$ £!¥@§AB5)(CD3 d efhgcf)ifBprqsgutwvx2i7twy £¦¥¨§©¤£WP!#"%$ @§)R%#£'w¡)(Q") &7¥I§2EF()¡)3G#HP¤!"%$ '&)()¡7¥I§2&)()¡)34#£ 8 §) ")¥I§23"HP¤QSRUTV$ £¦¥@§AB5)(CD3 (a) Regel delPublication ©¨¨!" D ¡TSe¥aEg Hh¨ A1¡!3¨"©4 D  ¤¡TSe¥ D  Hh¨ pQ#(¤ #W¡CS¦¥F%'¡#W(P02)¡!3¨"©4 5 ¡CSe¥ 5 "©4§¨" i )¡TSe¥ 8f@¡#ACB W¡CSU¥¢0XQ!YH( H" ¡CS`¥aH"bA1¡!( R¤¡TSU¥§R#APAP(VW)" D ¡¤£¦¥FEG HI¨AP¡#3¨"©4 D  ¤¡#£6¥ D  HI¨RQ#(C £¦¥§©¨¨!" #$¡#£¦¥&%'¡¤)(102)¡!3¨"24 )¡#£6¥ 89@¡#ACB 5 ¡#£6¥ 5 "©4§¨" 7 (b) Anwendungsgraph auf den die Regel deletePublication im Single bzw. Double Pushout Ansatz angewendet werden soll. £¦¥A$"%@70EF©@!0 £¦¥¨§©"!$ # ©¤£¦¥¨¡©%'&)(10 )%2£)%Q("!$# £¦¥¨TU!$#V@!0W% )Q£¦¥XY0`)¤a )%2£3¥¢45&©67( !¢£8¥¨!@(BA9CD# )%'©¤£3¥V%b©)BB(c%Q%S!0 @de¥Xf0`)¤a $"%@70EF©@!0 )%%S("!R# !$#V@!0h% (c) Graph, der resultiert, wenn deletePublication unter dem Match m im Single Pushout Ansatz auf den Anwendungsgraphen angewendet wird. Die lose Kante da 2 wurde 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 mo¨glich. Dies gilt zum Beispiel nicht, wenn nach der Anwendung der Regel lose Kanten gelo¨scht werden. Wird auf den daraus resultierenden Graphen die entsprechende Regel ru¨ckwa¨rts angewendet, wu¨rden die gelo¨schten 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 Zustandsu¨berga¨nge der Software eines mechatronischen Systems zu modellieren. Dazu mu¨ssen die Regeln einige Anforderungen erfu¨llen. Zum einen werden ausdrucksstarke Regeln beno¨tigt, d.h. neben der Anwendungsbedingung muss fu¨r eine Regel auch eine negative Anwendungsbedingung spezifiziert werden ko¨nnen. Andererseits bedeutet das Lo¨schen einer Kante in einem mechatronischen System, dass die Verbindung zwischen zwei Objekten gelo¨scht wird. Um ein versehentliches Lo¨schen einer Verbindung zu verhindern, muss die Regelanwendung die LoseKanten-Bedingung erfu¨llen. Im Verifikationsansatz, der in Abschnitt 3.7 vorgestellt wird, mu¨ssen die Regeln auch ru¨ckwa¨rts angewendet werden ko¨nnen. Dies ist aber nur mo¨glich, wenn die Anwendung der Regeln sowohl die starke Lose-Kanten- als auch die starke Identifikationsbedingung erfu¨llt. Deshalb wird in dieser Arbeit der Double Pushout iso Ansatz verwendet. Dieser Ansatz schra¨nkt den DPO so ein, dass im Gegensatz zum normalen DPO eine Regel nur dann anwendbar ist, wenn das Auftreten o der Regelseite einem Teilgraphisomorphismus entspricht. Zusa¨tzlich zum DPO aus[Roz97] sind auch negative Anwendungsbedingungen erlaubt. Definition 26.( Double Pushout Ansatz iso (DPO iso ) ) Eine direkte Transformation von einem Graphen AG G zu einem Graphen TG G ( AG und TG sind beschriftungskompatibel) im Double Pushout iso Ansatz entspricht einer direkten Transformation(siehe Definition 14) mit den folgenden Einschra¨nkungen: 1. Jedes korrekte Match einer Regel r erfu¨llt die Lose-Kanten-Bedingung. 2. Fu¨r jedes Match m einer Regel [ L, L ^ ] r R in AG gilt, dass m ein Teilgraphisomorphismus ist, L m G und  L^ L ^ , m T ISO[ L^, AG]: m| L = m L^ m AG . Fu¨r alle Auftreten o von r in AG gilt, dass o ein Teilgraphisomorphismus ist. Bedingung 2 garantiert, dass die starke Identifikationsbedingung per Konstruktion erfu¨llt 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 zusa¨tzliche 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 lo¨schenden Knoten inzident sind, ebenfalls durch die Regel gelo¨scht werden. Um dies zu erreichen, mu¨ssen fu¨r jeden zu lo¨schenden Knoten zusa¨tzliche Graphen zur negativen Anwendungsbedingung hinzugefu¨gt werden. In Anhang C.1.1 ist in Abbildung C.1 der Algorithmus extendNAC in Pseudocode-Notation gegeben, der diese Erweiterung durchfu¨hrt. Wie in Abbildung 3.23(c) zu sehen ist, kann die Anwendung der Regel deletePublication zu losen Kanten fu¨hren. Um dies zu verhindern, muss die Anwendung der Regel durch eine negative Anwendungsbedingung eingeschra¨nkt werden. Die Regel deletePublication lo¨scht den Knoten rp 2 vom Typ Publication . Laut Typgraph kann ein Knoten vom Typ Publication durch eine 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 . Fu¨r beide Fa¨lle muss jeweils ein zusa¨tzlicher Graph zur negativen Anwendungsbedingung hinzugefu¨gt werden. Beide zusa¨tzlichen Graphen der negativen Anwendungsbedingung enthalten die Anwendungsbedingung als Teilgraphen. L^ 1 entha¨lt daru¨ber hinaus einen Knoten vom Typ BaseStation , der adjazent zu rp 2

3.4. DAS SYSTEMMODELL 79 ist. Die Kante zwischen den beiden Knoten hat den Typ distributor . Der andere Graph, L^ 2 , entha¨lt zusa¨tzlich einen Knoten vom Typ Shuttle . Zwischen diesem neuen Knoten und dem Knoten rp 2 verla¨uft eine Kante vom Typ publisher . Die erweiterte Regel ist in Abbildung 3.24 dargestellt. ¤¦© ¢"54 & 6'78(6&)(0132 ¤AE ¢ E3 6(D¤GH©¨§)(I1¨¤ ¤!© 09 a4 & T@78(6&(0 132 ¤AEF9 E3 6(D¤GH©¨§)(I1¨¤ ¤¦¥£9 $# §¨©¨%@&(0 132 ¤!¥¨§¨©£9 ¥¨§¨©¨b£¤ ¤!YR9 Y132`(I1¨¤V ¤!¥ ¢"$# §¨©¨%'&)(0132 ¤¦¥¨§¨© ¢ ¥¨§¨©¨£¤ ¤S(T9 ¨U ¤V&W%WX ¤¦ 1¨9  18%@ &(IPEFQR2 ¤A09 7B¨§)(C(D ¡£ ¢ ¤AE ¢ E3 6(D¤GH©¨§)(I1¨¤ ¤!© 09 a4 &W6'78(6&)(0182 ¤VEF9 E3I(D¤!H©¨§)(I1¨¤ ¤¦¥£9 5# §¨©¨b%'&)(0182 ¤!YR9 Y132`(I1¨¤V ¤¦¥¨§¨©£9 ¥¨§¨©¨£¤ ¤S(T9 ¨U ¤V&W%WX ¤¦ 1e9  1F%'&)(I@EFQf2 ¤Vd9 7B¨§)(C(D ¤!¥ ¢5# §¨©¨%'&)(0132 ¤!¥¨§¨© ¢" ¥¨§¨©¨ c W¤ 9 ¤¦© d9 a4 & 6'78(6&)(0132 ¤VEF9 E3I(D¤!s©¨§)(I1¨¤ ¤!¥£9 5# §¨©¨%'&)(0132 ¤!¥¨§¨©£9 ¥¨§¨©¨b£¤ ¤!YR9 Y132`(I1¨¤V ¤A(T9 ¨U ¤&%£X ¤¦ 1e9  18%@ &(IPEFQR2 ¤A09 7B¨§)(C(D ¤¦¥ ¢5# §¨©¨b%@&(0 132 ¤¦¥¨§¨© ¢ ¥¨§¨©¨ c W¤ ¡ g hpirqsi¨t'iBu"vpwpqyxH8$t£xH ¤!© 09 a4 &W6'7F(6&(0 132 ¤AEF9 E3 6(D¤GH©¨§)(I1¨¤ ¤¦¥£9 3# §¨©¨b%'&)(0182 ¤!¥¨§¨©£9 ¥¨§¨©¨b£¤ ¤¦Yf9 Y132`(I1e¤A ¤A(T9 ¨U ¤&%£X ¤¦ 1e9  1F%'&)(I@EFQf2 ¤Vd9 7B¨§)(C(D Abbildung 3.24: Graphtransformationsregel deletePublication , die so angepasst wurde, dass ihre Anwendung im DPO iso keine losen Kanten erzeugen kann Mit dem Algorithmus extendNAC wird die negative Anwendungsbedingung einer Regel um zusa¨tzliche Graphen erweitert, sodass die Regelanwendung die Lose-Kanten-Bedingung einha¨lt. Durch die Anwendung des Algorithmus ko¨nnen jedoch redundante Graphen entstehen. Deshalb wird bei der Regelerweiterung zusa¨tzlich die Funktion minimizeNAC (siehe Abbildung C.2 in Anhang C.1.1) verwendet. Entha¨lt eine negative Anwendungsbedingung zwei Graphen G^ 1 und G^ 2 , mit G^ 1 G^ 2 , dann wird G^ 2 durch minimizeNAC gelo¨scht. Dies ist mo¨glich, da es immer, wenn es einen Teilgraphisomorphismus gibt, der G^ 2 auf einen Anwendungsgraphen abbildet, auch einen Teilgraphisomorphismus gibt, der G^ 1 auf den Anwendungsgraphen abbildet.

80 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN Definition 27.( Erweiterte Graphtransformationsregel ) Fu¨r eine Regel [ L, L ^ ] r R und einen Typgraph G wird die negative Anwendungsbedingung der erweiterten Regel [ L, L ^ e ] r e R gebildet durch L ^ e := minimizeNAC( L ^ extendNAC( L r R, G )) . Das folgende Lemma 5 zeigt, dass die Anwendung einer erweiterten Graphtransformationsregel aus Definition 27 die Lose-Kanten-Bedingung erfu¨llt. Lemma 5. (Einhaltung der Lose-Kanten-Bedingung) Wird eine typkonforme Regel [ L, L ^ ] r R wie in Definition 27 erweitert und die erweiterte Regel auf einen typkonformen Graphen G im DPO iso angewendet, so erfu¨llt 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 ko¨nnen. Dabei wurde ein Klassendiagramm auf einen Typgraphen und Objektdiagramme auf beschriftete Graphen abgebildet, wobei die Typen erhalten wurden. Im anschließenden Abschnitt 3.4.2 wurden die U¨ berga¨nge zwischen den Zusta¨nden durch Graphtransformationen beschrieben und garantiert, dass eine Regel nur dann angewendet werden kann, wenn sie die Bedingungen des DPO iso erfu¨llt. Ein typisiertes Graphtransformationssystem besteht aus einem Typgraphen, einer Menge von initialen Graphen und einer Menge von Graphtransformationsregeln. Definition 28.( Typisiertes Graphtransformationssystem ) Ein typisiertes Graphtransformationssystem S ist ein Tupel S:=( G[ G ], G Si , R S ) mit · G[ G ] ist der Typgraph, ·( G Si , R S ) ist ein Graphtransformationssystem wie in Definition 17 definiert, · r R S gilt: r ist typkonform zu G . Nach Theorem 1 ist ein derart spezifiziertes Graphtransformationssystem typkonform. Das bedeutet, dass jeder der erreichbaren Zusta¨nde typkonform sind. 3.5 Erweiterte Graphtransformationen Bisher wurden Graphtransformationsregeln immer in Vorwa¨rtsrichtung auf Graphen angewendet. Um den Ansatz zur U¨ berpru¨fung von Graphtransformationssystemen, der in Abschnitt 3.7 eingefu¨hrt wird, zu ermo¨glichen, mu¨ssen die Regeln auch ru¨ckwa¨rts angewendet werden ko¨nnen. Daru¨ber hinaus mu¨ssen die Regeln auch auf Graphmuster anwendbar sein. Die Transformation von Graphmustern sowie die Ru¨ckwa¨rtsanwendung von Regeln werden deshalb in diesem Abschnitt vorgestellt.

3.5. ERWEITERTE GRAPHTRANSFORMATIONEN 81 3.5.1 Ru¨ ckwa¨rtsanwendung 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 linken, aber nicht der rechten Regelseite sind, werden bei der Regelanwendung gelo¨scht. Elemente, die zur rechten aber nicht zur linken Regelseite geho¨ren, werden durch eine Regelanwendung neu erzeugt. Im Folgenden sollen Graphtransformationsregeln auch ru¨ckwa¨rts angewendet werden ko¨nnen, d.h. die rechte Regelseite stellt die Anwendungsbedingung dar und die linke Regelseite die Nachbedingung. Dementsprechend werden Elemente, die durch die Vorwa¨rtsanwendung erzeugt werden, bei der Ru¨ckwa¨rtsanwendung gelo¨scht. Solche Elemente, die in der Vorwa¨rtsrichtung gelo¨scht werden, werden in der Ru¨ckwa¨rtsrichtung neu erzeugt. Wendet man eine Regel r auf einen Graphen G an, so erha¨lt man einen Graphen G . Wird auf G die Regel r ru¨ckwa¨rts angewendet, so resultiert wieder der urspru¨ngliche Graph G . Die Ru¨ckwa¨rtsanwendung von r hat somit die Vorwa¨rtsanwendung von r ru¨ckga¨ngig gemacht. Damit eine Regel [ L, L ^ ] r R im DPO iso korrekt ru¨ckwa¨rts 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 Ru¨ckwa¨rtsanwendung aus der linken Regelseite die Nachbedingung der Regel wird und im DPO iso die Nachbedingung keine negative Anwendungsbedingung haben darf. Die zweite Modifikation besteht darin, dass eine negative Anwendungsbedingung zu R hinzugefu¨gt werden muss. Dadurch wird erreicht, dass die Regel nur dann ru¨ckwa¨rts auf einen Graphen anwendbar ist, wenn dieser Graph durch Anwendung der Regel in Vorwa¨rtsrichtung aus einem anderen Graphen entstanden sein kann. Die Anpassung der negativen Anwendungsbedingung erfolgt mittels des Algorithmus convertNAC (siehe Abbildung C.4 in Anhang C.2.1). Der Algorithmus bestimmt alle Graphen der negativen Anwendungsbedingung, die die Regelanwendung verhindern, wenn sonst lose Kanten erzeugt werden. Diese Graphen, so wie alle, auf die ein solcher Graph abgebildet werden kann, werden aus der negativen Anwendungsbedingung entfernt. Auf die verbleibenden Graphen wird jeweils die Regel L r R angewendet, d.h. die negative Anwendungsbedingung von r wird nicht beru¨cksichtigt. Die resultierenden Graphen bilden einen Teil der neuen negativen Anwendungsbedingung. Durch das Lo¨schen von Graphen aus L ^ zu Beginn der Anpassung wird erreicht, dass nur solche Graphen erhalten bleiben, auf die die Regel L r R angewendet 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 eine Ru¨ckwa¨rtsanwendung der Regel verhindern, wenn ansonsten lose Kanten entstehen. Dies ist aus dem folgenden Grund notwendig. Kanten, die bei der Ru¨ckwa¨rtsanwendung gelo¨scht werden, sind solche, die bei der Vorwa¨rtsanwendung erzeugt werden. Damit eine Kante bei der Ru¨ckwa¨rtsanwendung zu einer losen Kante werden kann, muss einer ihrer Knoten durch die Regel gelo¨scht werden, d.h. der Knoten ist Teil von R , aber nicht von L . Die Kante selber darf jedoch nicht Teil von R sein. In diesem Fall wu¨rde sie aber auch nicht bei der Vorwa¨rtsanwendung von r erzeugt.

82 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN In Abbildung 3.25 ist die Regel moveSimpleNAC dargestellt. Die negative Anwendungsbedingung der Regel besagt, dass das Shuttle nur dann von einem Track zum na¨chsten weiterfahren darf, wenn sich weder auf dem na¨chsten noch auf dem u¨berna¨chsten 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. &¡A@B§C354£6798 WYV X §C354£6798  C@E§F8 GH%6!IGPRQ  UT¨§F8 GH%6!IGPRQ @B§#%¦2( &¡)£2@S§¡)£ !¥S§#$%¦2( £¦¥¨§©¡¤£ !"§#$&%''( &¡A@S§C354£6798 WbV a §354£6798  C@E§F8 GH%6!IGPRQ `8©S§F8 GH%6!IGPRQ @S§#$&%''( &¡)£2@S§©¡)£ !¥¨§#$%¦2( &¡)£¦¥"§¡)£ !¨§#%¦2( @E§C354£6798  C@E§F8 GH%6!IGPRQ W @B§#$&%''( £2@B§¡¤£ !¥S§#$&%''( £¦¥¨§©¡¤£ e fhg5iYprqts&fvubwxpy !"§#$&%''( d &¡A@B§C354£6798 ©¥S§F8 GH%6!IGPRQ @B§#%¦2( £2@E§¡¤£ !¥¨§#$&%''( &¡)£¦¥"§¡)£ !¨§#%¦2( Abbildung 3.25: Regel moveSimpleNAC Die Invertierung einer Graphtransformationsregel wird folgendermaßen durchgefu¨hrt(der entsprechende Algorithmus reverse ist in Abbildung C.5 in Anhang C.2.1 abgebildet): Zuna¨chst wird die negative Anwendungsbedingung mittels convertNAC transformiert. Um redundante Graphen in der negativen Anwendungsbedingung auszuschließen, wird die negative Anwendungsbedingung mittels minimizeNAC minimiert. Anschließend werden die linke und die rechte Regelseite vertauscht, sodass die rechte Regelseite zusammen mit der invertierten negativen Anwendungsbedingung die Anwendungsbedingung der invertierten Regel darstellt und die linke Regelseite der urspru¨nglichen Regel als Nachbedingung der invertierten Regel fungiert.

3.5. ERWEITERTE GRAPHTRANSFORMATIONEN ¥ 2 §!"$#¦&% '¡32r§6587£9@BA ©¥y§sA w#9 uwvhx £&24§¡(£  ¥¨§!$#¦&% §6587£9@BA  C)§sA t#¦ uwvdx '¡(£¦¥)§¡(£  ¨§!"$#¦&% 2 2 §!"'#11% '¡324§6587£9@BA '¡¥)§65P7£9@BA ©¥¨§sA t#¦ uwvdx ©y§sA w#9 uwvhx '¡(£&24§¡¤£  ¥y§!"'#11% '¡(£¦¥)§C¡¤£ )§!$#¦&% 83 2 '¡32y§6587£9@BA §!"'#11% ©¥y§sA w#9 uwvhx '¡(£&2y§¡(£  ¥y§!"'#11% '¡(£¦¥)§©¡(£ E FHGPIRQTSVU¢FXW`YaQ8bdcfehgpi '¡324§6587£9@BA  2r§sA t#¦ uwvdx §!"'#11% '¡(£&2r§¡(£ 2  ¥)§!"'#11% £¦¥¨§©¡¤£ )§!"'#11%  ¨§!"$#¦&% Abbildung 3.26: Regel moveSimpleNAC - 1 stellt 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 - 1 einer Regel r zu definieren. Definition 29.( Invertierte Graphtransformationsregel ) Die inverse Regel [ L - 1 , L ^ - 1 ] r - 1 R - 1 einer Graphtransformationsregel [ L, L ^ ] r R im DPO iso ist definiert als r - 1 = reverse( r, G ) . Die in Abbildung 3.26 dargestellte Regel moveSimpleNAC - 1 entspricht der inversen Regel von moveSimpleNAC . Dabei entspricht der Graph L - 1 der urspru¨nglichen rechten Regelseite und R - 1 der urspru¨nglichen 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, G G , wobei G resultiert, wenn die Graphtransformationsregel r auf G angewendet wird, d.h. G|= r G . Ist r - 1 das Inverse von r , so resultiert die Anwendung von r - 1 auf G wieder in G , d.h. G|= r - 1 G . Die Anwendung der inversen Regel hat also die Anwendung der urspru¨nglichen Regel ru¨ckga¨ngig gemacht. Diese Eigenschaft inverser Regeln ist in Theorem 2 festgehalten. Theorem 2.( Ru¨ ckwa¨ rtsanwendung einer Graphtransformationsregel im DPO iso ) Fu¨r jede Graphtransformationsregel [ L, L ^ ] r R , ihr Inverses [ L - 1 , L ^ - 1 ] r - 1 R - 1 und ein Auftreten o von r in G 1 gilt im DPO iso : G 1 |= ( r, o) G 2  G 2 |= ( r - 1 , o - 1 ) G 1 .

84 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN 3.5.2 Transformationen von Graphmustern Graphmuster ko¨nnen dazu verwendet werden, um Mengen von Graphen zu beschreiben. Soll fu¨r diese Graphmengen gepru¨ft 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 r unter dem Auftreten o auf ein Graphmuster p resultiert wieder in einem Graphmuster, p . Wird die Regel unter o statt auf p auf einen Graphen angewendet, der p erfu¨llt, also in der Menge G[ p] enthalten ist, so resultiert die Anwendung in einem Graphen, der p erfu¨llt und somit zur Menge G[ p] geho¨rt. Um eine Graphtransformationsregel [ L, L ^ ] r R auf ein Graphmuster p:=[ P, P ^ ] anwenden zu ko¨nnen, muss die Regelanwendung etwas modifiziert werden. Die linke Regelseite muss immer durch ein Muster beschrieben werden, wobei die Menge L ^ leer sein darf. Die Regel ist anwendbar, wenn das Muster der linken Regelseite ein Teilgraphmuster des zu vera¨ndernden Graphmusters ist. Ist diese Bedingung erfu¨llt, so wird die Regel L r R auf den Graphen P angewendet. Die negative Anwendungsbedingung P ^ des 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 DPO iso ) Fu¨r eine Graphtransformationsregel [ L, L ^ ] r R und ein Graphmuster p=[ P, P ^ ] , wobei [ L, L ^ ] ein Teilgraphmuster von p ist( [ L, L ^ ] [ P, P ^ ] ), gilt im DPO iso , dass die Anwendung von r auf p in einem Graphmuster p=[ P, P ^ ] resultiert mit P|= r P und P ^ = convertNAC([ P, P ^ ],[ L, L ^ ] r R, G ) . Im Folgenden wird die Schreibweise p|=|= r p verwendet, wenn die Anwendung der Regel r auf ein Graphmuster p in einem Graphmuster p resultiert. Theorem 3 zeigt, dass Regelanwendungen, die auf Mustern mo¨glich sind, auch auf Graphen mo¨glich sind, die diese Muster erfu¨llen. 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 erfu¨llt. Theorem 3.( Transformation von Graphmustern ) Fu¨r eine Graphtransformationsregel [ L, L ^ ] r R und zwei Graphmuster p:=[ P, hat P], p:=[ P, P ^ ] gilt im DPO iso : ( p|=|= r p) ( G 1 , G 2  G, iso ISO: P P G 1  G 2 :( G 1 |= p G 1 |= r, iso| L R G 2 ) ( G 2 |= p)). In Theorem 2 wurde fu¨r eine Regel r und ihr Inverses r - 1 gezeigt, dass die Anwendung von r auf einen Graphen G durch die Anwendung von r - 1 auf den durch r erzeugten Graphen wieder in G resultiert. Unter Verwendung der Theoreme 2 und 3 kann gezeigt werden, dass dieses Ergebnis auch fu¨r Graphmuster gilt.

3.6. SYSTEMEIGENSCHAFTEN UND INVARIANTEN 85 Theorem 4.( Ru¨ ckwa¨ rtsanwendung von Regeln auf Graphmuster ) Fu¨r eine Graphtransformationsregel [ L, L ^ ] r R , ihr Inverses [ L - 1 , L ^ - 1 ] r - 1 R - 1 , zwei Graphmuster p:=[ P, P ^ ] und p:=[ P, P ^ ] und ein Auftreten o: L R P P gilt im DPO iso : ( p|=|= ( r, o) p) ( p|=|= ( r - 1 , o - 1 ) p). 3.6 Systemeigenschaften und Invarianten In Abschnitt 3.3 wurden Graphmuster eingefu¨hrt. 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 gezeigt, dass ihre Ausdruckssta¨rke a¨quivalent zum -Teil von -freien logischen Formeln erster Ordnung mit bina¨ren Pra¨dikaten ist. Graphmuster ko¨nnen entweder gefordert oder verboten sein. Geforderte Graphmuster beschreiben Eigenschaften, die immer erfu¨llt sein mu¨ssen. Dem gegenu¨ber stehen die verbotenen Graphmuster; sie beschreiben Eigenschaften, die nie erfu¨llt sein du¨rfen. In Grapheigenschaftsformeln stellen die Graphmuster die atomaren Eigenschaften dar. Definition 31.( Grapheigenschaftsformel ) Eine Grapheigenschaftsformel ist entweder · eine atomare Eigenschaft, die durch ein Graphmuster p beschrieben und als gefordertes Graphmuster bezeichnet wird oder · eine atomare Eigenschaft, die durch das negierte Graphmuster  p des Graphmusters p definiert ist. Diese Eigenschaft wird als verbotenes Graphmuster bezeichnet oder · eine zusammengesetzte Eigenschaft, gegeben durch oder , wobei und Grapheigenschaftsformeln sind. Wann eine solche Grapheigenschaftsformel von einem Graphen erfu¨llt ist, ist folgendermaßen definiert: Definition 32.( Semantik von Grapheigenschaftsformeln ) Ob ein Graph G G eine Grapheigenschaftsformel erfu¨llt, ist u¨ber die Struktur der Formel, bestehend aus ihren atomaren Eigenschaften p i :=[ P i , P ^ i ] und Teilformeln und , folgendermaßen definiert: · G|= p gdw.  tiso T ISO[ P i , G]: P i tiso G und G, P i , tiso P^ i , · G|= gdw. G|= , · G|= gdw. G|= und G|= und · G|= gdw. G|= oder G|= .

86 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN Fu¨r eine Menge G von Graphen und eine Menge R von Graphtransformationsregeln ko¨nnen die Eigenschaften dazu verwendet werden, die Graphen und Transformationen in verschiedene Mengen zu unterteilen. Bei den Graphen bezeichnet beispielsweise G[ ] die Menge aller Graphen, die die Eigenschaft erfu¨llen, d.h. G[ ]:={ G G| G|= } . U¨ berfu¨hrt eine Graphtransformation einen Graphen, der erfu¨llt, in einen Graphen, der erfu¨llt, so geho¨rt die Transformation zur Menge T[, ] . Diese Menge ist definiert als T[, ]:={ r R| G  G[ ], G  G[ ]: G |= r G } . Ein Systemzustand, gegeben als(typisierter) Graph, ist korrekt im Bezug auf eine Systemeigenschaftsformel , wenn gilt G|= , d.h. geforderte Graphmuster sind in G enthalten und verbotene Graphmuster sind nicht in G enthalten. Das gesamte System S:=( G[ G ], G Si , R S ) ist korrekt( S|= ), wenn alle Startgraphen aus G Si sowie alle erreichbaren Graphen von S korrekt sind. Ist S korrekt bezu¨glich , so ist eine operationale Invariante des Systems. Die formale Definition von operationalen Invarianten stammt aus[Cha03] und lautet 4 : Definition 33.( Operationale Invariante ) Eine Eigenschaft ist eine operationale Invariante eines Graphtransformationssystems S:=( G[ G ], G Si , R S ) wenn gilt: · G i  G Si : G i |= und · G REACH( S): G|= . Die U¨ berpru¨fung operationaler Invarianten ist jedoch fu¨r den allgemeinen Fall aus verschiedenen Gru¨nden nicht mo¨glich. Ein Grund dafu¨r ist, dass die hier betrachteten Systeme unendlich viele Zusta¨nde haben ko¨nnen. Ein zweiter Grund ist, dass die Menge der Initialgraphen zum Zeitpunkt der Verifikation noch nicht bekannt sein muss, bzw. dass sie sich noch vera¨ndern kann. Sobald die Verifikation abgeschlossen ist, kann jedoch nur dann ein neuer Startgraph zur Menge hinzugefu¨gt 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 Gru¨nden sollen im Folgenden statt der operationalen Invarianten induktive Invarianten betrachtet werden. Bei der U¨ berpru¨fung, ob eine Eigenschaft eine induktive Invariante ist, wird die Erreichbarkeit eines Zustands außer Acht gelassen. Stattdessen wird u¨berpru¨ft, ob jeder korrekte Zustand durch die Anwendung einer beliebigen Regel wieder in einen korrekten Zustand u¨berfu¨hrt wird. Definition 34.( Induktive Invariante ) Eine Eigenschaft ist eine induktive Invariante eines Systems S:=( G[ G ], G Si , R S ) , falls gilt:  G 1 , G 2  G[ G ], r R S :( G 1 |= r G 2  G 1 |= ) ( G 2 |= ) . Ist eine induktive Invariante und wird zusa¨tzlich von allen Startgraphen erfu¨llt, d.h.  G i  G Si : G i |= , dann ist auch eine operationale Invariante. Umgekehrt ist jedoch nicht jede operationale Invariante auch eine induktive. 4 Die Bezeichnungen der Eigenschaften sind in der Literatur nicht eindeutig. So werden beispielsweise die operationalen 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 ], G Si , R S ) ist, muss gezeigt werden, dass die Anwendung einer Regel r R S auf einen beliebigen korrekten Graphen G  G[ ] einen korrekten Graphen G  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 , G Si , R S ) , falls T[,  ]= . 3.6.1 Sicherheitseigenschaften Eine spezielle Art von Grapheigenschaftsformeln, die im Folgenden eine besondere Rolle spielen, sind die Sicherheitseigenschaften . Eine solche Sicherheitseigenschaft S wird durch eine Menge von verbotenen Graphmustern beschrieben, wobei jedes dieser verbotenen Graphmuster einen Unfall oder eine kritische Situation des Systems beschreibt. Die Normalform einer Sicherheitseigenschaft sieht folgendermaßen aus: s :=(  p k ). k K Ein Beispiel fu¨r 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 Shuttle s auf benachbarten Track s befinden du¨rfen, wenn sie nicht eine Instanz des DistanceCoordination -Musters ausfu¨hren. §R© GIH £¦¥¨§© )¨DE¥1)2&3$542687 )0£¦¥1)2&3$542687 !F"%$¢&(' @¥0¡A¢&5&5B¡¤¡C)" £ ¥!#"%$¢&(' GISH "e"#¥1"a5$("fR)b &T¥1UWV ¡C7X$¢&5(Y H )`)"a4bVc7X$¢dV)b7 "i¥0h"a)b79fR)b §© £ ¥¨§© )¨DE¥1)2&3$542687 )0£Q¥1)`&5$¢B426g7 !F"a$X&X' @¥0¡A¢&5&5B¡¤¡C)" £¦¥!F"%$¢&(' Abbildung 3.27: Sicherheitseigenschaft impendingCollision Jede so dargestellte Sicherheitseigenschaft kann auch durch S = j J ( p j ) ausgedru¨ckt werden. Um diese Formel zu erfu¨llen, genu¨gt ein einzelnes lokales Auftreten einer solchen kritischen 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 Beschra¨nkung auf Gegenbeispiele Um zu zeigen, dass eine Sicherheitseigenschaft der Form : = j J p j keine induktive Invariante eines Systems ist, ist es ausreichend eine Transformation zu finden, die zur Menge T[,  ] geho¨rt. Das bedeutet, es existiert ein Graph G , der eines der verbotenen Graphmuster p i der Sicherheitseigenschaft entha¨lt( G |= p i ) und dieser Graph ist das Resultat der Anwendung einer Regel r auf einen Graphen G , der keines der verbotenen Graphmuster entha¨lt(  j J: G |= p j ). In diesem Fall bilden die beiden Graphen G und G ein Gegenbeispiel , das zeigt, dass die angewendete Regel die Eigenschaft verletzen kann. Fu¨r die U¨ berpru¨fung der Korrektheit eines Systems bedeutet dies, dass die Verifikation abgebrochen werden kann, sobald ein solches Gegenbeispiel gefunden wurde; dies ist in Lemma 7 festgehalten. Lemma 7. (Zeugen widerlegen Sicherheitseigenschaften) Fu¨r eine Sicherheitseigenschaft der Form j J (  p j ) und ein System S:=( G[ G ], G Si , R S ) ist die Menge T[,  ] genau dann nicht leer und somit das System inkorrekt, wenn gilt:  G , G  G[ G ], r R S , o ISO: ( G |= ( r, o) G ) ( i J: G |= p i ) ( j J: G |= p j ). (3.5) 3.7 Nachweis von induktiven Invarianten Unter Zuhilfenahme der bisher vorgestellten Ergebnisse kann jetzt gezeigt werden, dass es ausreicht, eine endliche Menge von Repra¨sentanten zu betrachten, um nachzuweisen, dass eine Sicherheitseigenschaft eine induktive Invariante eines Graphtransformationssystems ist. Die theoretischen Ergebnisse werden in einem Algorithmus umgesetzt, der automatisch fu¨r eine Eigenschaft u¨berpru¨ft, ob die Eigenschaft eine induktive Invarianten des Systems ist(siehe dazu Abschnitt 5.3). 3.7.1 Theoretische Ergebnisse Fu¨r den Nachweis, dass eine Sicherheitseigenschaft S eine induktive Invariante eines Graphtransformationssystems ist, wurde in Lemma 7 gezeigt, dass die Menge der Transformationen, die einen korrekten Zustand in einen inkorrekten u¨berfu¨hren, leer sein muss. Um nachzuweisen, dass diese Menge leer ist, mu¨ssten jedoch unter Umsta¨nden unendliche viele Transformationen betrachtet werden. Im Folgenden wird das Ergebnis aus Lemma 7 ausgenutzt, um mittels einer endlichen minimalen Menge von Repra¨sentanten die Systemkorrektheit nachzuweisen. Als Repra¨sentanten dienen dabei die in Definition 19 eingefu¨hrten Graphmuster. Mit Hilfe der Graphmuster wird fu¨r jede der Graphtransformationsregeln einzeln gepru¨ft, ob sie korrekt ist. Eine wichtige Voraussetzung, um diese Art der U¨ berpru¨fung durchfu¨hren zu ko¨nnen, 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, vollsta¨ndige Graphen zu u¨berpru¨fen. 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 vera¨ndert wird und dadurch die Gu¨ltigkeit der Eigenschaft beeinflussen kann. Die Anwendung einer Regel r kann nur dann die Gu¨ltigkeit der Eigenschaft beeinflussen, wenn sie einen Zeugen fu¨r eines der verbotenen Graphmuster erzeugt. Der Teil des Anwendungsgraphen, der durch die Regelanwendung vera¨ndert wird, also auf den die linke Regelseite abgebildet wird, kann als Graphmuster kodiert werden. Ebenso ist es mo¨glich, den Teil des Zielgraphen, der sich durch die Regelanwendung vera¨ndert hat, d.h. auf den die rechte Regelseite abgebildet werden kann, als Graphmuster zu kodieren. Verwendet man solche Graphmuster statt vollsta¨ndiger Graphen, so kann die Frage, ob die Menge T[ S , S ] leer und das System somit korrekt bezu¨glich S ist, lokal beantwortet werden. Die Idee besteht darin, ein Graphmuster, das so genannte Ergebnisgraphmuster , so zu wa¨hlen, dass es als Teilgraphmuster ein verbotenes Graphmuster entha¨lt und somit inkorrekt ist. Fu¨r dieses Ergebnisgraphmuster wird gepru¨ft, ob es das Ergebnis einer Regelanwendung auf ein korrektes Graphmuster ist. Dazu wird die Regel invertiert und das Inverse auf das Ergebnisgraphmuster 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 u¨berfu¨hren kann. Dies bedeutet aber auch, dass ein korrekter Graph, der das Startgraphmuster als Teilgraphmuster entha¨lt, durch die betrachtete Regel in einen inkorrekten Graphen transformiert wird. Ein Ergebnisgraphmuster erfu¨llt zum einen ein verbotenes Graphmuster p j :=[ P j , P ^ j ] und entha¨lt zum anderen die rechte Seite einer Graphtransformationsregel r . Damit die Anwendung von r das verbotene Graphmuster p j erzeugt haben kann, muss entweder P j oder ein P^ j  P ^ j durch die Regel beeinflusst werden. Im ersten Fall muss durch die Regel mindestens ein Element erzeugt werden, das Teil von P j ist. Im zweiten Fall gibt es vor der Regelanwendung einen Teilgraphisomorphismus der P j auf das Anwendungsgraphmuster abbildet. Zusa¨tzlich kann dieser Teilgraphisomorphismus so erweitert werden, dass er auch einen Graphen P^ j aus der negativen Anwendungsbedingung von p j auf die Anwendungsbedingung des Anwendungsgraphmusters abbildet. Die Regelanwendung lo¨scht dann ein Element aus P^ j \ P j , sodass nach der Regelanwendung ein Teilgraphisomorphismus existiert, der P j auf den resultierenden Graphen abbildet. Dieser Teilgraphisomorphismus kann aber nicht so erweitert werden, dass er auch P^ j auf das resultierende Graphmuster abbildet. Fu¨r den zweiten Fall gilt: Ist das gelo¨schte Element eine Kante, so bleiben ihre inzidenten Knoten bei der Regelanwendung erhalten. Diese Knoten sind dann sowohl Teil der linken als auch der rechten Regelseite und auch in P^ j enthalten. Wird ein Knoten gelo¨scht, so mu¨ssen alle seine inzidenten Kanten ebenfalls explizit durch die Regel gelo¨scht werden. Fu¨r jeden Knoten n N P^ j \ N P j gilt nach Definition 15, dass er u¨ber einen Pfad mit einem Knoten n P j verbunden ist. Da die Regelanwendung keinen Einfluss auf P j hat, muss n auch nach der Regelanwendung erhalten sein. Ist n adjazent zu n , so wird n explizit durch die Regelanwendung erhalten und ist somit Teil sowohl der linken als auch der rechten Regelseite. Andernfalls gibt es entweder einen Knoten n , der auf dem Pfad zwischen n und n liegt, d.h. n n n , und bei der Regelanwendung erhalten bleibt. Dann ist dieser Knoten Teil der linken und rechten Regelseite. Oder alle Knoten, die auf dem Pfad liegen und Teil von P^ j \ P j sind, werden gelo¨scht.

90 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN In diesem Fall ist n adjazent zu n , wobei n durch die Regel erhalten bleibt. Dieses Ergebnis wird in Lemma 8 festgehalten. Lemma 8. (Gemeinsame Elemente von Graphtransformationsregeln und Graphmustern) Fu¨r eine Graphtransformationsregel [ L, L ^ ] r R und ein Graphmuster p:=[ P, P ^ ] gilt im DPO iso :  G, G G, o ISO: G|= ( r, o) G G|= o p G|= iso p (( R\ L) o( P)= ) ( iso ISO, P^ P ^ : iso| P = o| P  L R P^= ). (3.6) Das Ergebnis aus Lemma 8 wird im Folgenden dazu genutzt, um Ergebnisgraphmuster zu bilden. Da auf ein Ergebnisgraphmuster die entsprechende Regel ru¨ckwa¨rts angewendet werden soll, wird zur Bildung des Musters statt der Regel [ L, L ^ ] r R ihre inverse Regel [ L - 1 , L ^ - 1 ] r - 1 R - 1 verwendet. Das Ergebnisgraphmuster setzt sich dann zusammen aus den beiden Graphmustern [ L - 1 , L ^ - 1 ] und einem Zeugen p:=[ P, P ^ ] fu¨r ein verbotenes Graphmuster aus der Sicherheitseigenschaft : = k K p k . Nach Lemma 8 gibt es zwei Mo¨glichkeiten, ein solches Ergebnisgraphmuster egm:=[ EGM, EG ^ M] zu erzeugen. Die erste Mo¨glichkeit betrachtet den Fall, dass die Anwendung von r P erzeugt. Das bedeutet, dass die inverse Regel ein Element lo¨scht, das Teil von P ist. Deshalb werden die Graphen L - 1 und P so zu einem Graphen EGM zusammengefu¨gt, dass mindestens eines der durch r - 1 gelo¨schten Elemente auch Teil von P ist, d.h. es gibt einen Teilgraphisomorphismus tiso T ISO , der Elemente von P auf Elemente von L - 1 abbildet, wobei mindestens ein Knoten aus P auf einen Knoten aus ( N L - 1 \ N R - 1 ) oder eine Kante aus P auf eine Kante aus ( E L - 1 \ E R - 1 ) abgebildet wird. Zusa¨tzlich darf es weder einen Graphen in der negativen Anwendungsbedingung L ^ - 1 von r - 1 noch in der negativen Anwendungsbedingung P ^ von p geben, der auf einen Teil von EGM durch einen Teilgraphisomorphismus abgebildet werden kann. Um die negative Anwendungsbedingung EG ^ M zu bilden, wird sowohl fu¨r jeden Graphen aus L ^ - 1 als auch fu¨r jeden Graphen aus P ^ mindestens ein neuer Graph fu¨r die negative Anwendungsbedingung erzeugt. Betrachtet man einen Graphen L^ - 1  L ^ - 1 und den Graph P , so wird fu¨r diese beiden Graph folgendermaßen eine Menge von Graphen der negativen Anwendungsbedingung gebildet. Es werden alle Teilgraphisomorphismen tiso bestimmt, die einen nicht leeren Teilgraphen von P auf einen Teilgraphen von L^ - 1 abbilden. Fu¨r jeden dieser Isomorphismen gilt, dass er alle Elemente von P , die durch tiso auf Elemente auf L - 1 abgebildet werden, auf dieselben Elemente abgebildet, d.h. tiso - 1 | L = tiso - 1 . Mit Hilfe dieser Teilgraphisomorphismen werden dann die beiden Graphen zu einem vereinigt. Dabei besteht ein Graph EG^M zuna¨chst aus allen Elementen von L^ - 1 . Alle Elemente aus P , die nicht durch tiso auf Elemente aus L^ - 1 abgebildet werden ko¨nnen, werden hinzugefu¨gt. Auf diese Weise entsteht eine Menge von Graphen. Diese Menge kann unter Umsta¨nden 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 tiso ko¨nnen Graphen resultieren, die isomorph zur Anwendungsbedingung sind. Diese Graphen mu¨ssen aus der negativen Anwendungsbedingung entfernt werden. Außerdem gilt: Entha¨lt die Menge ein Graphenpaar EG^M 1

3.7. NACHWEIS VON INDUKTIVEN INVARIANTEN 91 und EG^M 2 und existiert ein Teilgraphisomorphismus, der EG^M 1 auf einen Teilgraphen von EG^M 2 abbildet( EG^M 1 EG^M 2 ), dann kann EG^M 2 aus der Menge entfernt werden. Dies ist mo¨glich, da immer, wenn es einen Teilgraphisomorphismus gibt, der EG^M 2 auf einen Graphen oder ein Graphmuster abbildet, dieser Teilgraphisomorphismus auch dazu verwendet werden kann, um EG^M 1 auf den Graphen/das Graphmuster abzubilden. Die Bildung der Graphen bestehend aus einem Graphen P^ P ^ und der Anwendungsbedingung L - 1 wird analog durchgefu¨hrt. Auf diese Weise wird erreicht, dass EGM ein Teilgraph von jedem EG^M EG ^ M ist und EG ^ M somit eine korrekte negative Anwendungsbedingung ist. Abbildung 3.28(a) zeigt das Inverse der Regel moveSimpleNAC ( [ L - 1 , L^ - 1 ] moveSimpleNAC - 1 R - 1 ), Abbildung 3.28(b) zeigt das verbotene Muster impendingCollision :=[ IC, I^C] . Ein mo¨gliches Ergebnisgraphmuster fu¨r die Regel und das verbotene Muster ist in Abbildung 3.29 dargestellt. Dieses Ergebnisgraphmuster beschreibt den Fall, dass die Anwendung der Regel moveSimpleNAC das verbotene Muster erzeugt, indem die Anwendungsbedingung des verbotenen Musters vervollsta¨ndigt wird. Das bedeutet, dass es Knoten oder Kanten in der Nachbedingung der Regel gibt, die bei der Regelanwendung neu erzeugt werden(und somit zu ( N R \ N L ) bzw. ( E R \ E L ) geho¨ren) und zusa¨tzlich auch durch einen Teilgraphisomorphismus tiso T ISO auf einen Teil von P abgebildet werden ko¨nnen. Da zur Bildung des Ergebnisgraphmusters die inverse Regel verwendet wird, mu¨ssen die Elemente durch die Regelanwendung gelo¨scht werden; sie sind somit Teil von N L - 1 \ N R - 1 bzw. E L - 1 \ E R - 1 . Im Beispiel wird durch r nur die rlo 2 : locatedOn erzeugt. Auf diese Kante kann durch einen Teilgraphisomorphismus die Kante vlo 1 des verboten Graphmusters abgebildet werden. Da fu¨r eine Kante der Start- und der Zielknoten eindeutig festgelegt ist, muss der Teilgraphisomorphismus auch den Knoten vs1 1 : Shuttle auf rs 1 : Shuttle und den Knoten vt 1 : Track auf rt 2 : Track abbilden. Der im Beispiel verwendete Teilgraphisomorphismus bildet zusa¨tzlich noch den Knoten vt2: Track auf den Knoten rt 3 : Track ab und die Kanten vsu: successor auf rsu 2 : successor . Das Ergebnisgraphmuster egm:=[ EGM, EG ^ M] wird nun folgendermaßen gebildet. Fu¨r EGM werden mit Hilfe des Teilgraphisomorphismus tiso die beiden Graphen L - 1 und IC der Regel bzw. des verbotenen Musters vereint. Das bedeutet, dass EGM zuna¨chst aus dem Graph L - 1 besteht. Alle Elemente, die durch tiso nicht auf Elemente aus L - 1 abgebildet werden, werden zu EGM hinzugefu¨gt. Das Ergebnisgraphmuster ist in Abbildung 3.29 dargestellt. Um die Graphen der negativen Anwendungsbedingung zu bilden, mu¨ssen alle Graphen der negativen Anwendungsbedingung der inversen Graphtransformationsregel sowie des verbotenen Graphmusters betrachtet werden. In diesem Beispiel besteht die negative Anwendungsbedingung von r - 1 aus den beiden Graphen L^ 1 1 und L^ 2 1 und die negative Anwendungsbedingung des verbotenen Graphmusters aus dem Graphen I^C . Fu¨r jeden dieser drei Graphen mu¨ssen neue Graphen gebildet werden. Der Graph EG^M 1 wird aus den Graphen L^ 1 1 und IC gebildet. Dazu werden alle Teilgraphisomorphismen bestimmt, die einen Teilgraph von IC auf einen Teilgraphen von L^ 1 1 abbilden. Diese Teilgraphisomorphismen mu¨ssen alle Elemente von IC , die durch den zuvor bestimmten tiso auf Elemente aus L - 1 abgebildet werden, auf dieselben Elemente abbilden. In diesem Beispiel ist das nur der Teilgraphisomorphismus tiso . EG^M 1 besteht dann zuna¨chst aus L^ 1 1 . Alle Elemente aus IC , die nicht durch tiso auf Elemente aus L^ 1 1 abgebildet werden, werden

92 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN ¥ 2 §!"$#¦&% '¡32r§6587£9@BA ©¥y§sA w#9 uwvhx £&24§¡(£  ¥¨§!$#¦&% §6587£9@BA  C)§sA t#¦ uwvdx '¡(£¦¥)§¡(£  ¨§!"$#¦&% 2 2 §!"'#11% '¡324§6587£9@BA '¡¥)§65P7£9@BA ©¥¨§sA t#¦ uwvdx ©y§sA w#9 uwvhx '¡(£&24§¡¤£  ¥y§!"'#11% '¡(£¦¥)§C¡¤£ )§!$#¦&% 2 '¡32y§6587£9@BA §!"'#11% ©¥y§sA w#9 uwvhx '¡(£&2y§¡(£  ¥y§!"'#11% '¡(£¦¥)§©¡(£ E FHGPIRQTSVU¢FXW`YaQ8bdcfehgpi '¡324§6587£9@BA  2r§sA t#¦ uwvdx §!"'#11% '¡(£&2r§¡(£ 2  ¥)§!"'#11% £¦¥¨§©¡¤£ )§!"'#11%  ¨§!"$#¦&% (a) Die inverse Regel moveSimpleNAC - 1 §R© GIH £¦¥¨§© )¨DE¥1)2&3$542687 )0£¦¥1)2&3$542687 !F"%$¢&(' @¥0¡A¢&5&5B¡¤¡C)" £ ¥!#"%$¢&(' GISH "e"#¥1"a5$("fR)b &T¥1UWV ¡C7X$¢&5(Y H )`)"a4bVc7X$¢dV)b7 "i¥0h"a)b79fR)b §© £ ¥¨§© )¨DE¥1)2&3$542687 )0£Q¥1)`&5$¢B426g7 !F"a$X&X' @¥0¡A¢&5&5B¡¤¡C)" £¦¥!F"%$¢&(' (b) Verbotenes Graphmuster impendingCollision Abbildung 3.28: Regel moveSimpleNAC , deren Korrektheit im Bezug auf das verbotene Graphmuster impendingCollision u¨berpru¨ft werden soll zu EG^M 1 hinzugefu¨gt. Fu¨r L^ 2 1 und IC gibt es zwei Teilgraphisomorphismen, die die geforderten Eigenschaften erfu¨llen. Deshalb entstehen die beiden Graphen EG^M 2 und EG^M 3 . EG^M 2 ist in Abbildung 3.29 mit gestricheltem Rand dargestellt. Der Grund dafu¨r ist, dass EG^M 3 ein Teilgraph von EG^M 2 ist, somit braucht EG^M 2 nicht in die negative Anwendungsbedingung aufgenommen werden. EG^M 4 ist der Graph, der aus der Vereinigung von L - 1 und I^C resultiert.

3.7. NACHWEIS VON INDUKTIVEN INVARIANTEN ghqp E£T¥U 4 'WV ¡PQ¥R¡P 'S' S¡E¡ 9 $¡¤£¦¥¨§"© # ¡EF¥¨§"© 9 F¥H 9 ' 43 %AI 5 # 9 $¥H 9 ' 4&3 %AI 5 $1¥B£eU 4 'WV $¡Pc¥7¡P 'S' d¡!¡ 9 4 'CV ghqf p £ E£T¥U 4 'WV £¦¥¨§© ¡!¢¥¨§"© # ¡!$¥¨§"© 9 $¥H 9 ' 4&3 %AI ¡tW£F¥R¡t 'd' d¡!¡ 9 5 $1¥B£eU 4 'WV 9 $ 9¡Pc' 4¥73¡P #%A'SI9 ' F¥H 9 5 d¡!¡ 9 ' 4&3 %AI 5 $¢¥U 4 'WV gihqf p E£F¥U 4 'CV £F¥¨§© 9 $¥H 9 ' 4&3 %AI 5 ¡PW£¦¥¡P 'S' d¡!¡ 9 £¦¥U 4 'CV ¡E$¥¨§"© # ¡!F¥¨§"© 9 F¥H 9 ' 43 %AI 5 'd' d¡!¡ 9 # 9 F¥H 9 ' 43 %AI 5 4 'WV gihqf pQu E£¦¥U 4 'CV $¡D£T¥¨§"© 9 $¥H 9 ' 4&3 %AI 5 ¡tW£T¥¡P 'S' d¡!¡ 9 £F¥U 4 'CV $¡E$¥¨§"© 9 F¥H 9 ' 43 %AI 5 'd' d¡!¡ 9 4 'WV gihqf psr E£T¥U 4 'WV # X ¥ Y4 a` 9 $¡¤£¦¥¨§"© #&8@%9A' 9 ¥) %(10B5C02¡34!D4¨059 '5 76 #b ¥ b 9 5 ` 9 # ¡EF¥¨§"© 9 F¥H 9 ' 43 %AI 5 # 9 ¥H 9 ' 4&3 %AI 5 ¡PQ¥R¡P 'S' S¡E¡ 9 $1¥B£eU 4 'WV $¡Pc¥7¡P 'S' d¡!¡ 9 4 'CV 93 Abbildung 3.29: Ein mo¨gliches Ergebnisgraphmuster fu¨r die Regel moveSimpleNAC und das verbotene Graphmuster impendingCollision Auf diese Weise muss fu¨r jeden Teilgraphisomorphismus, der ein oder mehrere durch die Regel neu erzeugte Elemente auf ein verbotenes Graphmuster abbildet, ein Ergebnisgraphmuster gebildet werden. Die zweite Mo¨glichkeit betrachtet den Fall, dass die Anwendung der Regel r ein Element lo¨scht(das Element wird dann durch die Anwendung von r - 1 erzeugt), sodass anschließend ein P^ P ^ Teilgraphmuster des resultierenden Graphen ist. Das entsprechende Ergebnisgraphmuster egm:=[ EGM, EG ^ M] wird folgendermaßen gebildet. EGM wird durch die Vereinigung von L - 1 und P gebildet, wobei es in diesem Fall nicht unbedingt einen Teilgraphisomorphismus geben muss, der einen Teilgraph von L - 1 auf einen Teilgraph von P abbildet. Allerdings muss es einen Teilgraphisomorphismus tiso T ISO und ein P^ P ^ geben, sodass tiso mindestens einen Knoten, der sowohl in der linken als auch rechten Regelseite auftritt, auf einen

94 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN Knoten aus P^ abbildet. Dieser Teilgraphisomorphismus wird dann dazu verwendet, die Graphen EG^M i  EG ^ M der negativen Anwendungsbedingung zu bilden. Dabei wird fu¨r jedes Paar von Graphen P^ P ^ und L^ - 1  L ^ - 1 ein solches EG^M i gebildet. Das EG^M i entspricht zuna¨chst P^ . Der Teilgraphisomorphismus tiso wird dazu verwendet, alle mo¨glichen Elemente von L^ - 1 auf Elemente aus P^ abzubilden. Elemente fu¨r die eine solche Abbildung unter tiso nicht mo¨glich ist werden zum Graphen hinzugefu¨gt. In Abbildung 3.30 ist die Regel deleteDCSwitch abgebildet. Die Regel beschreibt, dass die Instanz des DistanceCoordination -Musters zwischen zwei Shuttle s gelo¨scht wird, wenn die Shuttle s an einer Weiche in unterschiedliche Richtungen weiterfahren wollen. Die Regel lo¨scht also einen Knoten, der auch Teil der negativen Anwendungsbedingung des verbotenen Graphmusters impendingCollision aus Abbildung 3.28(b) ist. Da die Regel nur einen Knoten und seine inzidenten Kanten lo¨scht, jedoch keine Elemente erzeugt, braucht bei der Bildung der Ergebnisgraphmuster nur die zweite Mo¨glichkeit betrachtet werden. Die Regel lo¨scht den Knoten rdc , seine adjazenten Knoten rs 1 und rs 2 bleiben bei der Anwendung erhalten. Zusa¨tzlich dazu erha¨lt die Regel die Knoten rt 1 , rt 2 und rt 3 sowie die Kanten rlo 1 , rn 1 , rsu 1 , rsu 2 und rlo 2 . Fu¨r alle diese Elemente gilt, dass sie sowohl Teil der linken als auch der rechten Regelseite sind. Fu¨r den Graphen I^C wird nun ein Teilgraphisomorphismus tiso ISO gesucht, der einen Teil der Elemente von I^C auf die Elemente abbildet, die bei der Regelanwendung erhalten bleiben. Ein mo¨glicher Teilgraphisomorphismus ist tiso:= tiso N , tiso E , mit tiso N :={( vs 1  rs 1 ),( vs 2  rs 2 ),( vt 1  rt 1 ),( vt 2  rt 2 )} und tiso E :={( vlo 1  rlo 1 ),( vlo 2  rlo 2 ),( vsu rsu 1 )} . Mit Hilfe dieses Teilgraphisomorphismus kann nun EGM gebildet werden. Dazu wird L - 1 mit tiso( IC) vereinigt. Das heißt, dass der Graph L - 1 um alle Elemente von IC erweitert wird, die nicht durch tiso auf Elemente von L - 1 abgebildet werden. Die negative Anwendungsbedingung EG ^ M besteht nur aus dem einen Graphen EG^M . EG^M besteht zuna¨chst aus L - 1 . Jedes Element aus I^C , das nicht durch tiso auf ein Element aus L - 1 abgebildet werden kann, wird zusa¨tzlich in diesen Graphen eingefu¨gt. Das Ergebnisgraphmuster egm ist in Abbildung 3.31 dargestellt. Definition 35.( Ergebnisgraphmuster(EGM) ) Fu¨r eine Regel [ L, L ^ ] r R , ihr Inverses [ L - 1 , L ^ - 1 ] r - 1 R - 1 und ein verbotenes Muster p:=[ P, P ^ ] werden die Ergebnisgraphmuster egm:=[ EGM, EG ^ M] unter Beru¨cksichtigung von Lemma 8 auf die folgenden zwei Arten gebildet. (1) Ein Teil der Menge wird Beru¨cksichtigung der ersten Bedingung von Lemma 8 gebildet. Fu¨r jedes Ergebnisgraphmuster dieser Teilmenge wird jeweils ein Graph P und ein Graphisomorphismus iso ISO gewa¨hlt, mit P iso P: N P  ( N L - 1 \ N R - 1 )= E P  ( E L - 1 \ E R - 1 ) e E P  ( E L - 1 \ E R - 1 ): src( e) ( N P  N L - 1 ) tgt( e) ( N P  N L - 1 )  R^ i  L ^ - 1 , tiso T ISO: tiso - 1 | L - 1 = iso - 1  L^ i 1 tiso P L - 1  P^ i  P ^ , tiso T ISO: tiso| P = iso P^ i tiso P L - 1 .

3.7. NACHWEIS VON INDUKTIVEN INVARIANTEN ¡B¡£¡q¤¦¡%§E)¡r`U5aA§ ¡!G"b¤dcfe$66¢¨"2§)g h 5D5¡!Gaei¢¨pe 5a¢ ¡%XV¡9¤1XV¡!5Y¢F'`U5aA§ ¡!$R(Q¤PSUT&FVWA§ ¡£¢¥¤¦¢¨§© ¡BA 5P(Q¤¦A 5D"EF§2GDHI¢ ¡¤¡!"# ¡4(C¤¡!"# ¡!$6¤PSUT&FVWA§ ¡%$'&)(0¤1$&¨"2"2§3$4$65¡ ¡!$&¨¤$&¨"2"3§2$6$45¡ ¡78¤9¡@¨")# ¡BA 51C¤¦A 5D"EF§2GDHI¢ s tvuUwxuPy2uC9xy2U ` ¡!$R(0¤PSUT&FVWA§ ¡£¢¤¦¢¨§W© ¡BA 5P(Q¤¦A 5D"EF§2GDHI¢ ¡%8¤¡@¨")# ¡%4(0¤¡@¨")# ¡%$48¤PSUT&FVWA§ ¡!$&)(C¤$&¨"2"2§3$4$65¡ ¡!$&¨¤$'&¨"3"2§2$6$65P¡ ¡%7C¤¡!"# ¡£A 58¤¦A 5Y"2¨§3GDH¢ Abbildung 3.30: Die Regel deleteDCSwitch 95 Das Ergebnisgraphmuster wird dann folgendermaßen gebildet: EGM:= P L - 1 und EG ^ M:={ L^ - 1  iso( P)| iso ISO, L^ - 1  L ^ - 1 , iso ISO: iso - 1 | L - 1 = iso - 1  EGM<( L^ - 1  iso( P)) iso - 1 | L = iso - 1  EGM<( L^ - 1  iso( P)) ( L^ - 1  iso( P))( L^ 1 - 1 iso( P)) } { L - 1  iso( P^)| iso ISO, P^ P, iso ISO: iso| P = iso EGM<( L - 1  iso( P^)) iso| P = iso EGM<( L - 1  iso( P^)) ( L - 1  iso( P^))<( L - 1  iso( P^)) }. (2) Der zweite Teil der Menge wird unter Beru¨cksichtigung der zweiten Bedingung aus Lemma 8 gebildet. Dabei wird fu¨r jedes Ergebnisgraphmuster dieser Teilmenge jeweils ein Graph P^ und ein Graphisomorphismus iso ISO gewa¨hlt, sodass gilt:

96 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN !¦"$#%¥'&)(¨01¡2¡43 5 !`3 Q'#C¥93 QaH1¡¤5Xbacd6 @A¡ "w0#%¥¨"w0XW5X"Y" £¦¥¨§© !¦¡B#C¥¨§© !¦"w08¥¨"w0XX5W"B" !¦¡¤£¦¥¨§© !`3 Qv£e¥93 QaH1¡¤5Xbacd6 !¦"B£¦¥'&)(¨01¡2¡43 5 G ©)QR3 5 !¦"S#C¥'&)(¨01¡2¡43 5 F E !`3 Q'#C¥93 QaH1¡¤5Xbacd6 @A¡ "V0#%¥¨"V0WX5W"B" £U¥¨§© G b¨f¥hgpiq"¤¡Y'6W5sr t QaQ' !¦¡B#%¥¨§© !U"w08¥¨"w0XW5X"Y" !e¡¤£U¥¨§© G1x x )QR3 5 !`3 Qv£e¥93 QaH1¡¤5Xbacd6 !U"Y£U¥'&)(¨01¡2¡43 5 Abbildung 3.31: Ein mo¨gliches Ergebnisgraphmuster fu¨r die Regel deleteDCSwitch und das verbotene Muster impendingCollision ( N R - 1  N L - 1  N iso( P^) )= .  n ( N R - 1  N L - 1  N iso( P^) ), e ( E R - 1 \ E L - 1 ):( n= src( e)) ( n= tgt( e)). In diesem Fall wird egm folgendermaßen gebildet: EGM:= L - 1  iso( P) EG ^ M:={ L - 1  iso( P^)| iso ISO, P^ P ^ , iso ISO: iso| P = iso EGM<( L - 1  iso( P^)) iso| P = iso EGM<( L - 1  iso( P^)) ( L - 1  iso( P^))( L - 1  iso( P^)) }. In den Abbildungen 3.32, 3.33 und 3.34 ist schematisch die Bildung der Graphen der negativen Anwendungsbedingung dargestellt. Dabei geho¨ren 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 ^ - 1 um Elemente aus P erweitert wird. Die Erweiterung eines Graphen P^ P um Elemente aus L - 1 ist in Abbildung 3.33 zu sehen. Abbildung 3.34 geho¨rt dagegen zu dem Fall, dass die Regelanwendung ein Element lo¨scht, das Teil eines P^ P ^ ist. Die Abbildung zeigt schematisch die Erweiterung des Graphen P^ um Elemente aus L - 1 . Die Menge aller korrekten Ergebnisgraphmuster fu¨r eine Regel r und ein verbotenes Muster p wird 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 ^ - 1 um Elemente aus P Abbildung 3.33: Schematische Darstellung der Erweiterung eines Graphen P^ P ^ um Elemente aus L - 1 Abbildung 3.34: Schematische Darstellung der Erweiterung eines Graphen P^ P ^ um Elemente aus L - 1 EGM ( r, p) ist eine Teilmenge von EGM( r, p) . Diese Menge ist minimal, d.h. es gilt  egm EGM( r, p), egm EGM: ( r, p): egm egm und  egm 1 , egm 2  EGM ( r, p): egm 1  egm 2 . Durch die Konstruktion des Ergebnisgraphmusters ist das Graphmuster [ L - 1 , L ^ - 1 ] der inversen Regel r - 1 immer ein Teilgraphmuster des Ergebnisgraphmusters und eine Ru¨ckwa¨rtsanwendung der Regel im DPO iso immer mo¨glich. Das Graphmuster, das aus der Anwendung resultiert, wird als Startgraphmuster bezeichnet. Das Startgraphmuster, das resultiert, wenn die inverse Regel moveSimpleNAC - 1 auf das Ergebnisgraphmuster egm aus Abbildung 3.29 angewendet wird, ist in Abbildung 3.35 dargestellt.

98 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN $ ¡&%!¥¨§© §vuxw $'(¨%)¥0(214357628@9 "#%)¥` "¡fg¥h¡fI1P17P¡#¡¤( $ G¥U%e` ¡#£!¥¨§© $ ¡fi¥R¡fI1P177¡¤¡¤( (R£ ¥0(X173I5P628Y9 $!5£¦¥` $ ¡A%B¥¨§© y §vuxw% $W(¨%)¥0(214357628@9 "#%)¥` %!¥h¡pI171P7¡¤¡#( £¦¥¨§© ¡¤£ ¥¨§© (R£!¥0(X173I5P628Y9 (h£!¥0(214357628@9 $ G¥U%e` $ ¡fi¥R¡fI1P177¡¤¡¤( $£¦¥` $ ¡A%)¥¨§© y §vuxwg£ $'(¨%)¥0(214357628@9 #%!¥` "¡fd%B¥¡fI1P177¡¤¡¤( "¡#£ ¥¨§© ¡¤£!¥¨§© $!#%B¥` (h£!¥0(214357628@9 $¦¡pg¥¡pI171P7¡¤¡#( (h£!¥0(214357628@9 $!5£!¥` $ ¡&%B¥¨§© y §vuxwg $'(¨%)¥0(214357628@9 #%B¥` %)¥¡fI1P177¡¤¡¤( $!#%!¥` $ ¡#£ ¥¨§© $¦¡pi¥h¡pI171P7¡¤¡#( $'(h£!¥0(214357628@9 $!5£¦¥` y §vuxw $ ¡A%)¥¨§© (T $W(¨%B¥0(X173I5P628Y9 "#%)¥` "¡fg¥h¡fI1P17P¡#¡¤( $ G¥U%e` 61C¥EDGFH¡5¤3¨9I1PRQ S (2("6TFU9V3AFH(T9 "(T9f(X ¡#£!¥¨§© $ ¡fi¥R¡fI1P177¡¤¡¤( (¥0(X173I5P628Y9 $!5£¦¥` Abbildung 3.35: Startgraphmuster, das aus der Anwendung der inversen Regel moveSimpleNAC - 1 auf das Ergebnisgraphmuster aus Abbildung 3.29 resultiert Definition 36.( Startgraphmuster ) Fu¨r eine Regel [ L, L ^ ] r R , ihr Inverses [ L - 1 , L ^ - 1 ] r - 1 R - 1 , das verbotene Muster p:=[ P, P ^ ] und ein dazugeho¨riges Ergebnisgraphmuster egm:=[ EGM, EG ^ M] , ist das Startgraphmuster sgm:=[ SGM, SG ^ M] definiert als tgm|=|= r - 1 sgm . Die Menge SGM ( r, p) bezeichnet die minimale Menge der Startgraphmuster. Diese Menge wird aus der Menge T GM ( r, p) durch Anwendung der inversen Regel von r erzeugt. Fu¨r jeden der Graphen aus SGM ( r, p) muss gepru¨ft werden, ob er ein verbotenes Graphmuster entha¨lt. Kann ein Startgraphmuster sgm SGM ( r, p) gefunden werden, das kein verbotenes Graphmuster entha¨lt, so wurde ein Gegenbeispiel gefunden, dass zeigt, dass die Regel r einen korrekten Graphen in einen inkorrekten u¨berfu¨hren kann, d.h. die Menge T[ S , S ] nicht leer ist.

3.7. NACHWEIS VON INDUKTIVEN INVARIANTEN 99 Lemma 9 zeigt fu¨r ein System S und eine Sicherheitseigenschaft s := k K (  p i ) , dass die Menge T[ S , S ] leer und S somit eine induktive Invariante von S ist, falls fu¨r jedes Ergebnisgraphmuster egm das dazugeho¨rigen Startgraphmuster sgm einen Zeugen fu¨r ein verbotenes Muster p i aus S entha¨lt. Ein Graph, der eines der Ergebnisgraphmuster entha¨lt und somit inkorrekt 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 fu¨r ein verbotenes Muster aufweisen, ist auch der urspru¨ngliche Graph inkorrekt. Lemma 9. (Zeuge im Startgraphmuster impliziert induktive Invariante) Fu¨r ein System S:=( G , G i , R S ) und eine Sicherheitseigenschaft : = j J (  p j ) gilt im DPO iso  i J, r R : ( egm EGM ( r, p i ), sgm, o ISO:( egm|=|= ( r - 1 , o - 1 ) sgm) ( j J: p j  sgm)) ( G 1 , G 2  G[ G ]:( G 1 |= ( r, o) G 2  G 2 |= p i ) ( j J: G 1 |= p j )). 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 dazugeho¨rige Graphtransformationsregel immer in einem Startgraphmuster resultiert, das einen Zeugen fu¨r ein verbotenes Muster entha¨lt. Dieses Ergebnis ist in Theorem 5 festgehalten. Theorem 5. (Sicherheitseigenschaft ist induktive Invariante) Fu¨r ein System S:=( G , G Si , R S ) ist die Sicherheitseigenschaft : = j J (  p j ) genau dann eine induktive Invariante, wenn gilt:  i J, r R S , egm EGM ( r, p i ), sgm, o ISO: ( egm|=|= ( r - 1 , o - 1 ) sgm) ( j J: p j  sgm) (3.7) 3.7.2 Der Algorithmus Die im voran gegangenen Abschnitt vorgestellten theoretischen Ergebnisse ko¨nnen nun dazu verwendet werden, um einen Algorithmus zu beschreiben, der automatisch u¨berpru¨ft, ob ein Graphtransformationssystem korrekt bezu¨glich einer Sicherheitseigenschaft S ist. D.h. der Algorithmus pru¨ft, ob jede der Eigenschaften eine induktive Invariante des Systems ist. Der Algorithmus check ist in Abbildung 3.36 in Pseudocode angegeben. Er erwartet als Eingabe eine Menge von Graphtransformationsregeln R S und eine Menge von verbotenen Mustern P , wobei P der Menge der verbotenen Graphmuster aus S entspricht. Zusa¨tzlich dazu beno¨tigt der Algorithmus noch den Typgraphen G . In einem ersten Schritt(Zeile 03 bis 06) ruft der Algorithmus fu¨r jedes Paar, bestehend aus dem Inversen r - 1 einer Regel r R S und ein verbotenes Graphmuster p i  P , den Algorithmus buildTGP auf, der in Abschnitt C.3.1 beschrieben wird. Dieser berechnet fu¨r das jeweilige

100 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN Paar von Regel und verbotenem Graphmuster die Menge aller gu¨ltigen Ergebnisgraphmuster EGM( r, p i ) . Diese Menge wird reduziert, sodass eine minimale Menge von Ergebnisgraphmustern EGM ( r, p i ) resultiert(Zeile 07). Der zur Reduktion aufgerufene Algorithmus reduceTGP wird in Abschnitt C.3.1 vorgestellt. In den Zeilen 08 bis 16 wird die Gu¨ltigkeit von Bedingung 3.7 aus Theorem 5 u¨berpru¨ft. Dazu wird zuna¨chst auf jedes Ergebnisgraphmuster egm aus der Menge EGM ( r, p i ) die entsprechende inverse Graphtransformationsregel r - 1 angewendet(Zeile 10). Fu¨r das jeweils resultierende Startgraphmuster sgm muss u¨berpru¨ft werden, ob es irgendein verbotenes Muster entha¨lt. Kann kein Zeuge fu¨r ein verbotenes Muster in sgm gefunden werden, so liefert der Algorithmus das Startgraphmuster sgm , das Ergebnisgraphmuster egm und die Regel r als Gegenbeispiel zuru¨ck. Andernfalls gibt der Algorithmus aus, dass die Regelmenge R S korrekt 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 , id R , G ) 11: //check if sgp f ulf ills any p P 12: if(  p P: p sgp ) then 13: //report counterxample sgp|=|= r tgp 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 , G Si , R S ) ist korrekt bezu¨glich der Sicherheitseigenschaft S , wenn der Algorithmus check angibt, dass die Menge der Regeln korrekt ist und zusa¨tzlich alle Initialgraphen korrekt sind, d.h.  G G Si : G|= S . 3.7.3 Aufwandsabscha¨tzung Im voran gegangenen Abschnitt wurde der Algorithmus zum Nachweis induktiver Invarianten in Graphtransformationssystemen vorgestellt. In diesem Abschnitt wird fu¨r diesen Algorithmus eine Abscha¨tzung fu¨r seine Komplexita¨t gegeben. In der Abscha¨tzung werden die folgenden Variablen verwendet: n G ist die maximale Anzahl von Elementen(Knoten und Kanten) im gro¨ßten Graphen. Dabei kann dieser Graph eine linke oder rechte Regelseite, die Anwendungsbedingung eines verbotenen Graphmusters oder ein Graph einer negativen Anwendungsbedingungen einer Regel oder eines verbotenen Graphmusters sein. Die Anzahl aller Regeln wird mit n R bezeichnet. n P entspricht 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 L ^ bezeichnet. Dementsprechend bezeichnet n P ^ die maximale Anzahl von Graphen in der negativen Anwendungsbedingung eines verbotenen Graphmusters. Der Algorithmus bestimmt mehrfach(Teil-)Graphisomorphismen zwischen zwei Graphen. Dabei muss fu¨r alle Elemente des einen Graphen eine Abbildung auf ein Element des anderen Graphen gefunden werden, wodurch ein Aufwand entsteht, der exponentiell in den Gro¨ßen der beiden Graphen ist. Um die Aufwandsabscha¨tzung zu vereinfachen, wird die Gro¨ße eines Graphen als die Summe seiner Knoten und Kanten angegeben. Da alle Graphen eine maximale Gro¨ße von n G haben, betra¨gt der Aufwand zum Bestimmen eines Graphisomorphismus zwischen zwei Graphen O( exp( 2n G )) . Als erstes wird die Regel invertiert. Dazu muss jeder Graph der negativen Anwendungsbedingung konvertiert werden und dann die minimale negative Anwendungsbedingung berechnet werden. Zudem mu¨ssen Isomorphismen bestimmt werden. sodass sich insgesamt fu¨r die Invertierung der Regel eine Komplexita¨t von O( n L ^ 2  exp( 2n G )) ergibt. Anschließend bildet der Algorithmus alle mo¨glichen Ergebnisgraphmuster. Dazu mu¨ssen zuna¨chst alle Teilgraphen der linken Regelseite und der Anwendungsbedingung des verbotenen Graphmuster bestimmt werden. Fu¨r jeden Teilgraphen der linken Regelseite und jeden Teilgraphen des verbotenen Graphmusters wird dann gepru¨ft, ob es einen Isomorphismus gibt, der die beiden Teilgraphen aufeinander abbildet. Um die negative Anwendungsbedingung der Ergebnisgraphmuster zu bestimmen, mu¨ssen alle Graphen der negativen Anwendungsbedingungen aller linken Regelseiten sowie aller verbotenen Graphmuster betrachtet werden. Auch beim Bilden der negativen Anwendungsbedingungen mu¨ssen wieder Isomorphismen bestimmt werden, wodurch sich fu¨r die Funktion buildTGP eine Gesamtkomplexita¨t von O( exp( 6n G )) ergibt. Nachdem die Menge aller Ergebnisgraphmuster erzeugt wurde, werden redundante Muster wieder aus dieser Menge entfernt. Dazu muss jedes Paar von Ergebnisgraphmustern P 1 und P 2 betrachtet werden und bestimmt werden, ob es einen Isomorphismus gibt, der die Anwendungsbedingung des Musters P 1 auf einen Teil der Anwendungsbedingung des Musters P 2 abbilden kann. Ist dies der Fall, muss gepru¨ft werden, ob dieser Isomorphismus so erweitert werden kann, dass er einen Graphen der verbotenen Anwendungsbedingung von P 1 auf die Anwendungsbedingung von P 2 abbilden kann. Ist dies der Fall, ist das Muster P 1 kein Teilgraphmuster von P 2 . Andernfalls muss noch gepru¨ft werden, ob der gefundene Isomorphismus so erweitert werden kann, dass jeder der Graphen der negativen Anwendungsbedingung von Muster P 1 auf einen Graphen der negativen Anwendungsbedingung von Muster P 2 abgebildet werden kann. Die Graphen(sowohl 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 Gro¨ße der Graphen eines Ergebnisgraphmusters 2n G betra¨gt. Fu¨r die Bestimmung eines Isomorphismus zwischen zwei Graphen eines Ergebnisgraphmusters bedeutet dies einen Aufwand von O( 4n G ) . Insgesamt hat die Minimierung der Menge der Ergebnisgraphmuster deshalb einen Aufwand von O( exp( 8n G )) . 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 Gro¨ße von n G haben, gibt es maximal exp( 2n G ) Ergebnisgraphmuster. Deshalb wird auch die Schleife in Zeile 08 maximal exp( 2n G ) -mal ausgefu¨hrt. Bei der Anwendung der Regel mu¨ssen wieder Isomorphismen bestimmt werden, was zu einer Komplexita¨t von O( exp( 2n G )) fu¨hrt. Als letztes wird fu¨r 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 Komplexita¨t von O( exp( 8n G )) . Fu¨gt man diese Komplexita¨ten zusammen, so erha¨lt man den folgenden Ausdruck, wobei die Zahl auf der linken Seite der Zeilennummer im Algorithmus entspricht. 03 O( n R  ( 04 n e L ^ xp( 2n G )+ 05 n P  ( 06 exp( 6n G )+ 07 exp( 8n G )+ 08 exp( 2n G ) ( 10 exp( 2n G )+ 12 exp( 8n G ) ) ) ) Lo¨st man die innerste Klammer auf, so erha¨lt man O( n R  ( n e L ^ xp( 2n G )+ n P  ( exp( 6n G )+ exp( 8n G )+ exp( 4n G )+ exp( 10n G )) . Das O-Kalku¨l stellt eine obere Schranke fu¨r den Aufwand dar. Deshalb ist es mo¨glich die Summe ( n e L ^ xp( 2n G )+ n P  ( exp( 6n G )+ exp( 8n G )+ exp( 4n G )+ exp( 10n G )) durch 4exp( 10n G ) zu ersetzen. Da die 4 eine Konstante ist, mit der die Exponentialfunktion multipliziert wird, n P  exp( 10n G ) . Zudem gilt kfu¨arnngrsoißeew n e G g,gdealassssdeenrwTeerrdmen n . e L ^ D x a p m ( 2 i n t G e ) rgkibletisniecrhi O st ( a n l R s n ( P n e L ^ exxpp (( 21n0 G n ) G +) und somit ebenfalls wegfa¨llt. Daraus ergibt sich eine Komplexita¨t des gesamten Algorithmus von O( n R  n P  exp( 10n G )) . Die Abscha¨tzung hat somit ergeben, dass der Aufwand des Algorithmus exponentiell in der Gro¨ße der betrachteten Graphen, aber nur linear in der Anzahl der Regeln und verbotenen Graphmuster ist. Damit hat der Algorithmus zwar eine sehr hohe Komplexita¨t, allerdings gilt diese nur fu¨r den schlechtesten Fall. In der Praxis gilt jedoch, dass die Graphen der Regeln und verbotenen Graphmuster relativ klein sind, sodass die hohe Komplexita¨t eine Verifikation nicht verhindert. Zudem wurde bei der Komplexita¨tsberechnung davon ausgegangen, dass alle Elemente 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 durchgefu¨hrt. Diese Evaluierung zeigt, dass der Algorithmus trotz seiner Komplexita¨t anwendbar ist.

3.8. ZUSAMMENFASSUNG 103 3.8 Zusammenfassung Das Kapitel 2 stellt einen Ansatz vor, in dem Methoden mechatronischer Systeme mittels Story Patterns beschrieben werden. Fu¨r diese Story Patterns wird ein Verfahren beno¨tigt, dass die Verifikation der Story Patterns ermo¨glicht. Da Story Patterns eine eingeschra¨nkte Form von Graphtransformationsregeln darstellen, ist es mo¨glich zu ihrer U¨ berpru¨fung Verfahren zur Verifikation von Graphtransformationssystemen einzusetzen. Allerdings beno¨tigen existierende Ansa¨tze zum einen einen Initialgraphen, zum anderen sind die meisten existierenden Ansa¨tze nur anwendbar, wenn der durch die Graphtransformationsregeln aufgespannte Zustandsraum endlich ist(siehe dazu Kapitel 6). Diese beiden Einschra¨nkungen ko¨nnen fu¨r die Story Patterns der mechatronischen Systeme nicht gewa¨hrleistet werden. Deshalb wurde in diesem Kapitel ein Ansatz vorgestellt, der nicht diesen Einschra¨nkungen unterliegt. Im vorgestellten Ansatz werden die zu verifizierenden strukturellen Eigenschaften als(verbotene) Graphmuster beschrieben. Um auch unendliche Graphtransformationssysteme verifizieren zu ko¨nnen, wird weder eine Erreichbarkeitsanalyse durchgefu¨hrt, noch werden konkreten Graphen analysiert. Stattdessen werden Mengen von Graphen durch Ergebnisgraphmuster(bestehend aus der rechten Seite einer Regel und einem verbotenen Graphmuster) beschrieben. Fu¨r ein solches Ergebnisgraphmuster wird gepru¨ft, 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 u¨berfu¨hren kann. Dies gilt immer dann, wenn ein Graph das Startgraphmuster entha¨lt und auf dieses Startgraphmuster die betrachtete Regel angewendet wird. Durch die Anwendung der Regel auf das Startgraphmuster resultiert ein Graph, der das Ergebnisgraphmuster entha¨lt. 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 PseudocodeNotation beschreibt. Die Aufwandsabscha¨tzung ergab, dass der vorgestellte Algorithmus linear in der Anzahl der Regeln und verbotenen Graphmuster ist, aber exponentiell in der Gro¨ße der Graphen. Das folgende Kapitel zeigt informal, dass Story Patterns eine eingeschra¨nkte Form der in diesem Kapitel vorgestellten Graphtransformationsregeln, bzw. verbotenen Graphmuster sind. In Kapitel 5 wird die prototypische Umsetzung des Ansatzes fu¨r 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 Aufwandsabscha¨tzung ergeben 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 ko¨nnen.

104 KAPITEL 3. NACHWEIS INDUKTIVER INVARIANTEN

Kapitel 4 Story Patterns und Graphtransformationssysteme Im voran gegangenen Kapitel wurden Graphtransformationssysteme eingefu¨hrt, wie sie auch in der Literatur(beispielsweise in[Roz97]) verwendet werden. Die Anwendbarkeit der Graphtransformationsregeln wurde im DPO iso eingeschra¨nkt. Zudem wurde definiert, wie eine Regel mit negativer Anwendungsbedingung ru¨ckwa¨rts 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 entha¨lt und somit inkorrekt ist. In Kapitel 2 wurden Story Patterns vorgestellt und dazu verwendet, um die von den RealTime Statecharts aufgerufenen Methoden modellieren zu ko¨nnen. Außerdem wurden verbotene Story Patterns eingefu¨hrt, um kritische Situationen und Unfa¨lle zu modellieren. Die Story Patterns stellen eine spezielle Art von Graphtransformationsregeln dar. Sie unterscheiden sich von den in Kapitel 3 eingefu¨hrten Graphtransformationsregeln hauptsa¨chlich in ihrer Syntax. Wa¨hrend Graphtransformationsregeln aus zwei Graphen, der linken und der rechten Regelseite, bestehen, besteht ein Story Patterns nur aus einem Graphen, der beide Regelseiten entha¨lt. Zudem werden in den zuvor beschriebenen Graphtransformationssystemen negative Anwendungsbedingungen als zusa¨tzliche Graphen zur linken Regelseite hinzugefu¨gt, wa¨hrend sie in Story Patterns direkt in den Graphen eingefu¨gt werden, der die linke und die rechte Regelseite beschreibt. Daraus resultiert eine schwa¨chere Ausdruckssta¨rke der negativen Anwendungsbedingungen von Story Patterns. Schra¨nkt man die Anwendbarkeit der Story Pattern zudem noch so ein, dass sie im DPO iso angewendet werden, so ist es mo¨glich, den im vorangegangenen Kapitel vorgestellten Verifikationsansatz dazu zu verwenden, um fu¨r die Story Patterns nachzuweisen, dass ihre Anwendung kein Objektdiagramm erzeugt, auf das ein verbotenes Story Pattern angewendet 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 eingefu¨hrten Graphtransformationsregeln abgebildet werden ko¨nnen und somit der Verifikationsansatz 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 erla¨utert wurde, kann ein Klassendiagramm auf einen Typgraphen 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 Klassendiagrammen ko¨nnen ungerichtete Assoziationen enthalten sein. Bei der Abbildung auf einen Graphen wird fu¨r diese Assoziationen eine Richtung festgelegt. Dementsprechend kann ein Objektdiagramm auf einen typisierten Graphen abgebildet werden. 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. Entha¨lt ein Objektdiagramm ungerichtete Links, so werden diese auf gerichtete Kanten abgebildet, wobei ihre Richtungen den im Typgraph definierten Richtungen entsprechen mu¨ssen. Abbildung 4.1(a) zeigt noch einmal das einfache Klassendiagramm aus Abschnitt 2.1.3, Abbildung 4.1(b) zeigt den entsprechenden Typgraphen. Das Objektdiagramm in Abbildung 4.2(a) stellte eine mo¨gliche Instanzierung des Klassendiagramms dar, der zu ihm a¨quivalente 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 B©)C5D£ 6758¡¤&@9 £3!¤&4&¨¥4£¦£"5 $'&(¡©)¥¨0'12 §"!©#©%$ ¥ (a) Einfaches Klassendiagramm (b) Typgraph, der dem obigen Klassendiagramm entspricht Abbildung 4.1: Klassendiagramm und entsprechender Typgraph 4.2 Story Patterns und Graphtransformationsregeln Ein Story Pattern(siehe[FNTZ98, Zu¨n01] und Abschnitt 2.2.2) ist eine Graphtransformationsregel, 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 ko¨nnen, zusa¨tzlich zum Namen 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 mo¨gliche Instanzierung des Klassendiagramms aus Abbildung 4.1(a) darstellt '() 021¥3$45476 8 ' 6 E ) c6 E AV' 4§8edgfhG '( 3 ) ( 3 AVA 8 (W( E¥@ ' 4 ) &9¢@ 'AB '¥X!) X EHG&C 4§E¥@ ( £!£"$#&% £¥¡§¦©¨ '¥X Sb X EHG&C 4§E@ ( '( 3S ( 3 AeA 8 (W( E¥@ ' 4¤ST¥9¢@ 'AUB 'X ab X EHG&C 4§E¥@ ( 'I(0")4 ' Q4DCFP EH'G ( 8R% '¥X`Y X EHG&C 4§E¥@ ( '( 3ab ( 3 AVA 8 (¤( E¥@ '( 3 Y ( 3 AVA 8 (¤( E¥@ (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 Graphtransformationsregel dar. Ebenso entsprechen alle Elementen, die nicht mit destroy beschriftetet sind, der Nachbedingung der Graphtransformationsregel. Abbildung 4.3 zeigt die Vorwa¨rtsbewegung eines Shuttle s, 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 Objektdiagramms abbildet, ein Teilgraphisomorphismus sein. Auf diese Weise wird die Identifikationsbedingung erfu¨llt und Konflikte vermieden, bei denen zu lo¨schende Objekte auf dasselbe Objekt

108 KAPITEL 4. STORY PATTERNS UND GRAPHTRANSFORMATIONSSYSTEME (a) Vorwa¨rtsbewegung als Story Pattern ¡£¢¥¤§¦©¨ ¡!¤"$#&%'(0)2143 ¡56¥¤78¡9%'#A@ ¡5¢BC¤¢B'#0#&&¢D¢D§¡ ¡£¢¥¤§¦©¨ I PRQ©SUTWVYX5Pa`cbdT ¡ gFh¤" 2#i%(&)21p3 ¡E(FG¤7H¡9%'#A@ ¡56¥¤78¡9%'#A@ ¡5¢Be¤f¢B'#0#&&¢D¢D§¡ ¡E(FG¤7H¡9%'#A@ (b) Vorwa¨rtsbewegung als Graphtransformationsregel Abbildung 4.3: Vorwa¨rtsbewegung, moveSimple , eines Shuttle s als Story Pattern und als Graphtransformationsregel 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 gelo¨scht. Aufgrund dieses impliziten Lo¨schens von losen Kanten ist eine Ru¨ckwa¨rtsanwendung eines Story Patterns nicht immer mo¨glich. Im oben vorgestellten Verifikationsansatz wurde der DPO iso Ansatz fu¨r die Anwendung von Graphtransformationsregeln eingefu¨hrt. Wie bei der Anwendung von Story Patterns verlangt auch der DPO iso 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 DPO iso Ansatz jedoch explizit erfu¨llt werden. Das bedeutet, ein Knoten darf nur dann gelo¨scht werden, wenn dadurch keine losen Kanten entstehen. Da sowohl das Matching der Story Patterns als auch der Graphtransformationsregeln ein Graphisomorphismus sein muss, kann ein Story Pattern, das keine Objekte lo¨scht, genau dann angewendet werden, wenn auch die entsprechende Graphtransformationsregel angewendet werden kann. Um zu erzwingen, dass dies auch gilt, wenn das Story Pattern ein Objekt lo¨scht, muss das Story Pattern um zusa¨tzliche negative Objekte und Links erweitert werden. Im Klassendiagramm ist definiert, welche Klassen adjazent zur Klasse des zu lo¨schenden Objektes sind. Fu¨r jede dieser Klassen wird ein negatives Objekt in das Story Pattern eingefu¨gt. Jedes der neu erzeugten negativen Objekte wird u¨ber eine Kante mit dem zu lo¨schenden 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 zusa¨tzliche negative Knoten und Kanten wird erreicht, dass auch diese im DPO iso Ansatz angewendet werden und somit immer eine Ru¨ckwa¨rtsanwendung der Story Patterns mo¨glich ist. 4.2.2 Negative Anwendungsbedingungen Sowohl bei Story Patterns als auch bei Graphtransformationsregeln ko¨nnen negative Anwendungsbedingungen angegeben werden. Ihre Syntax und Semantik unterscheiden sich zwar, allerdings ko¨nnen die negativen Anwendungsbedingungen von Story Patterns auf negative Anwendungsbedingungen von Graphtransformationsregeln abgebildet werden. In Story Patterns wird die negative Anwendungsbedingung direkt in Form von negativen Elementen in den Graph eingefu¨gt, 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. Entha¨lt ein Story Pattern mehrere negative Elemente und es gibt ein Match fu¨r mindestens eines der negativen Elemente im Objektdiagramm, so ist die Anwendung des Story Patterns verboten. Entha¨lt 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 ko¨nnen. Abbildung 4.4 zeigt ein Beispiel fu¨r ein Story Pattern mit negativer Anwendungsbedingung. Dieses Story Pattern, createDC , erzeugt fu¨r zwei Shuttle s eine Instanz des DistanceCoordination Musters, falls die beiden Shuttle s auf zwei Track s sind, zwischen denen sich ein weiterer Track befindet. Die negative Anwendungsbedingung verlangt, dass zwischen den beiden Shuttle s 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 ko¨nnen 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 DistanceCoordination -Muster gibt, in dem das Shuttle rs1 die rearRole u¨bernommen hat und kein Muster, in dem rs2 die frontRole spielt. In Graphtransformationsregeln werden die negativen Anwendungsbedingungen durch zusa¨tzliche Graphen beschrieben. Eine Graphtransformationsregel mit negativer Anwendungsbedingung darf angewendet werden, wenn ihre Anwendungsbedingung auf einen Teilgraphen des Anwendungsgraphen abgebildet werden kann, eine Abbildung eines kompletten Graphen der negativen Anwendungsbedingung jedoch nicht mo¨glich ist. Entha¨lt ein Story Pattern mehrere negative Elemente, so muss bei der Abbildung auf Graphtransformationsregeln fu¨r jedes der Elemente ein Graph zur negativen Anwendungsbedingung hinzugefu¨gt werden. Jeder dieser Graphen erweitert die Anwendungsbedingung, d.h. die Anwendungsbedingung 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 eingefu¨gt. Bei einem negativen Objekt wird der Graph um einen entsprechenden Knoten erweitert. Zusa¨tzlich wird fu¨r jeden inzidenten Link eine Kante in den Graphen eingefu¨gt. Abbildung 4.5 zeigt die Graphtransformationsregel createDC , die a¨quivalent zu dem gleichnamigen Story Pattern ist. 4.3 Kritische Situationen und Unfa¨lle Auch kritische Situationen und Unfa¨lle, die als verbotene Story Patterns gegeben sind, ko¨nnen mittels verbotenen Graphmustern dargestellt werden. Dazu wird die Anwendungsbedingung des verbotenen Story Patterns auf die Anwendungsbedingung eines Graphmusters abgebildet. Entha¨lt das verbotene Story Pattern negative Elemente, so wird die negative Anwendungsbedingung des Graphmusters genau so gebildet, wie im Fall der Graphtransformationsregeln. Abbildung 4.6(a) zeigt die kritische Situation impendingCollision als Story Pattern und Abbildung 4.6(b) das dazu a¨quivalente Graphmuster. 4.4 Zusammenfassung In Kapitel 2 wurden Story Patterns eingefu¨hrt, um die Methoden, die von einem Real-Time Statechart aufgerufen werden, modellieren zu ko¨nnen. Zudem wurden verbotene Story Patterns eingefu¨hrt, mit denen kritische Situationen und Unfa¨lle modelliert werden ko¨nnen. In Kapitel 3 wurde ein Verfahren erla¨utert, dass eine Verifikation von Graphtransformationsregeln ermo¨glicht. Bei diesem Verfahren werden die nachzuweisenden Eigenschaften als verbotene Graphmuster beschrieben. In diesem Kapitel wurde informal gezeigt, dass die in Kapitel 2 eingefu¨hrten Story Patterns eine eingeschra¨nkte Form der in Kapitel 3 definierten Graphtransformationsregeln sind. Ebenso stellen die verbotenen Story Patterns eine eingeschra¨nkte Form der verbotenen Graphmuster dar. Somit ist es durch den Ansatz aus Kapitel 3 mo¨glich, nachzuweisen, dass die Anwendung

4.4. ZUSAMMENFASSUNG w1v x §©  5h(3&)G4HEIuC C)2D@ #%'&)(10 ¡A)(4(33¡!¡! (F¦¥YX`Sa¡G!&¨C)(4Qb R @&)VS 5TC s !£¦¥#'&)(10 ¡A)(4(33¡!¡! £¦¥¨§©  5E(F&G3HEIPC !"¥Q#'&)(10 w$v y §© &  5E(F&G3HEIPC #%'&)(10 ¡A)(4(33¡!¡! C)D@ (F£¦¥YX`Sa¡G!&¨C)(4Qb R @&)VS 5TC !£¦¥#'&)(10 ¡2)(3(34¡¤¡! £"¥¨§©  5E(F&G3HEIPC !"¥Q#'&)(10 111 w §B©  5E(F&G3HEIPC #&@(@0 ¡2)(3(43¡! C)D@ !£¦¥#'&)(10 c defhgTiFfprq ¡2)(3(34¡¤¡! &@ (t¥YX`Sa¡G!&C)(3Qb R @&)VS 5TC s £¦¥¨§©  5E(F&G3HEIPC !"¥$#%'&)(10 §B©  5h(3&)G4HEIuC C)D@ #&@(@0 ¡2)(3(43¡! !£¦¥#'&)(10 ¡2)(3(34¡¤¡! £¦¥¨§©  5E(F&G3HEIPC !"¥$#%'&)(10 Abbildung 4.5: Graphtransformationsregel createDC der Story Patterns nicht zu einer kritischen Situation oder einem Unfall(beschrieben durch ein verbotenes Story Pattern) fu¨hren kann. Da eine manuelle Verifikation sowohl zeitaufwa¨ndig als auch fehleranfa¨llig ist, wird im nachfolgenden Kapitel gezeigt, wie der Ansatz automatisiert werden kann.

112 KAPITEL 4. STORY PATTERNS UND GRAPHTRANSFORMATIONSSYSTEME (a) Kritische Situation impendingCollision als Story Pattern GIH §R©£¦¥¨§ © )¨DE¥1)2&3$542687 )0£¦¥1)2&3$542687 !F"%$¢&(' @¥0¡A¢&5&5B¡¤¡C)" £ ¥!#"%$¢&(' GISH "e"#¥1"a5$("fR)b &T¥1UWV ¡C7X$¢&5(Y H )`)"a4bVc7X$¢dV)b7 "i¥0h"a)b79fR)b §© £ ¥¨§© )¨DE¥1)2&3$542687 )0£Q¥1)`&5$¢B426g7 !F"a$X&X' @¥0¡A¢&5&5B¡¤¡C)" £¦¥!F"%$¢&(' (b) Kritische Situation impendingCollision als verbotenes Graphmuster Abbildung 4.6: Die kritische Situation impendingCollision als Story Pattern und a¨quivalentes verbotenes Graphmuster

Kapitel 5 Werkzeugunterstu¨ tzung In den vorangegangenen Kapiteln wurde die Modellierung und Verifikation der Software mechatronischer Systeme vorgestellt. In diesem Kapitel soll nun die Umsetzung der Konzepte in der Fujaba Real-Time Tool Suite 1 erla¨utert werden. Fujaba wird seit 1997 im Fachgebiet fu¨r Softwaretechnik an der Universita¨t Paderborn entwickelt. Das urspru¨ngliche Ziel von Fujaba bestand in einem Roundtrip Engineering, daher 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 lauffa¨higer Code erzeugt und zum Testen verwendet werden[Gei02]. Fujaba ermo¨glicht 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 umstrukturiert. Die Fujaba Tool Suite unterstu¨tzt ein Plugin-Konzept, das es ermo¨glicht, neue Diagrammarten und Algorithmen in die Tool Suite einzufu¨gen[Wen03]. Dieser Plugin-Mechanismus wurde dazu verwendet, um die Fujaba Real-Time Tool Suite zu ermo¨glichen, 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 unterstu¨tzt und einzelne Phasen automatisiert. Im Kontext dieser Arbeit sind zwei neue Plugins entwickelt worden, die den Entwickler dabei unterstu¨tzen, korrekte Story Patterns zu modellieren. Das erste Plugin bindet 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 eingeschra¨nkte Form der in Kapitel 3 vorgestellten Graphtransformationsregeln handelt(siehe Kapitel 4). Es stellt eine Umsetzung des in Kapitel 3 vorgestellten Verifikationsansatzes fu¨r Story Patterns dar. In Abschnitt 5.4 wird das bereits eingefu¨hrte Shuttle -Beispiel mittels des zweiten Plugins verifiziert. 1 www.fujaba.de 113

114 KAPITEL 5. WERKZEUGUNTERSTU¨ TZUNG 5.1 Werkzeugunterstu¨ tzung des Modellierungs- und Verifikationsprozesses In Abschnitt 2.5 wurde der Prozess zur Modellierung und Verifikation der Software mechatronischer Systeme vorgestellt. In diesem Abschnitt wird nun gezeigt, wie die Fujaba Real-Time Tool Suite die Phasen dieses Prozesses unterstu¨tzt bzw. automatisiert. Der Prozess la¨sst 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 Komponente sowie ihre Datenstrukturen werden mittels Klassendiagrammen spezifiziert. Die Kommunikationsprotokolle, die durch die Muster festgelegt werden sowie das komponenteninterne Verhalten werden durch Real-Time Statecharts angegeben. Die komponenteninternen Real-Time Statecharts ko¨nnen Methoden aufrufen(entry()-, do()-, exit()-Methoden in den Zusta¨nden und Methoden als Seiteneffekte an den Transitionen). Diese Methoden werden mit Hilfe von Story Patterns beschrieben. Klassendiagramme und Story Patterns geho¨ren 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 unterstu¨tzt. 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 dazugeho¨rigen Real-Time Statecharts wurde in verschiedenen Plugins der Fujaba Real-Time Tool Suite umgesetzt. Dazu wurde zuna¨chst eine Schnittstelle entwickelt, die eine Anbindung verschiedener Model Checker zula¨sst. In[Hir04, BGHS04, BGH + 05, HG03] wurde die Anbindung des Model Checkers UPPAAL eingefu¨hrt und in[Ste05] die Anbindung von RAVEN. Neben der Anbindung verschiedener Model Checker ermo¨glicht diese Schnittstelle auch, den Model Checking Prozess in den Hintergrund zu verlegen. Das heißt, der Konsistenzmechanismus von Fujaba erkennt, dass am Modell eine A¨ nderung vorgenommen wurde und stellt fest, welche Eigenschaften dadurch beeinflusst werden. Fujaba sto¨ßt dann automatisch den Model Checking Prozess fu¨r das entsprechende Koordinationsmuster oder die entsprechende Komponente und die betroffene Eigenschaft an. Das model Checking wird dann im Hintergrund durchgefu¨hrt. In den Real-Time Statecharts der Koordinationsmustern und Komponenten werden Methoden ausgefu¨hrt. Diese werden durch Story Patterns beschrieben. Die Story Patterns mu¨ssen ei-

5.2. DAS GROOVE-PLUGIN 115 ne Menge von Sicherheitseigenschaften, beschrieben durch verbotene Story Patterns, einhalten. Um die Entwicklung der Story Patterns zu unterstu¨tzen, wurde ein Plugin entwickelt, das Groove(einen Model Checker und Simulator fu¨r Graphtransformationssysteme) an Fujaba anbindet. Dieses Plugin bietet die Mo¨glichkeit, das Verhalten des durch die Story Patterns beschriebenen Systems fu¨r einen gegebenen Anfangszustand zu beobachten. Ko¨nnen vom Anfangszustand aus nur endlich viele verschiedene Zusta¨nde erreicht werden, so kann Groove mittels einer Erreichbarkeitsanalyse pru¨fen, ob die Story Patterns einen inkorrekten Zustand erzeugen ko¨nnen. Dieses Plugin in ist in Abschnitt 5.2 beschrieben. Fu¨r die eigentliche Verifikation von Story Patterns wurde im Kontext dieser Arbeit ein Plugin entwickelt, das fu¨r eine Menge von Story Patterns und eine Menge von verbotenen Story Patterns eine automatische U¨ berpru¨fung durchfu¨hrt. Dabei wteirddesfeSsytgsetesmteslltd,aorbstdeallst."DNaicshPt-lAuguifntrseetetznt"sdoemr vitedrbeonteAnnesnaStztoaruysPKaattpeirtnesl eine induktive Invarian3 fu¨r 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 erfu¨llt. Allerdings wurde bisher immer das Modell des Systems betrachtet und nicht der Code, der im mechatronischen System wirklich ausgefu¨hrt wird. Um sicherstellen zu ko¨nnen, dass auch der Code die fu¨r das Modell nachgewiesenen Eigenschaften erfu¨llt, ist es notwendig, den Code automatisch aus dem verifizierten Modell zu generieren. Die Codegenerierung fu¨r Klassendiagramme und Story Patterns ist Bestandteil des Fujaba Kerns[FNT98, FNTZ98, NNWZ00, NNZ00]. Fu¨r Koordinationsmuster und Komponenten sowie 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 Graphtransformationssystemen, vor. Dabei steht Groove fu¨r GRaph-based Object-Oriented VErification. Zurzeit unterstu¨tzt Groove eine Erreichbarkeitsanalyse fu¨r strukturelle Eigenschaften. Die zu u¨berpru¨fenden Eigenschaften werden dabei als Graphtransformationsregel angegeben. Der Simulator von Groove kann so konfiguriert werden, dass er fu¨r eine derart spezifizierte Eigenschaft u¨berpru¨ft, ob sie in jedem erreichbaren Zustand des Systems erfu¨llt ist oder ob sie in keinem erreichbaren Zustand erfu¨llt ist. Dazu pru¨ft der Simulator fu¨r alle Graphen, die die erreichbaren Zusta¨nde des Systems beschreiben, ob die entsprechende Regel auf sie anwendbar ist. Regeln, die auf jeden Zustand anwendbar sein mu¨ssen, werden im Folgenden als geforderte Regeln oder Eigenschaften bezeichnet und solche, die nie anwendbar sein du¨rfen, als verbotene Regeln oder Eigenschaften. Groove beno¨tigt als Eingabe einen Startgraphen, eine Menge von Graphtransformationsregeln sowie entweder eine geforderte oder eine verbotene Regel.

116 KAPITEL 5. WERKZEUGUNTERSTU¨ TZUNG Die Graphen in Groove sind gerichtete Graphen mit beschrifteten Kanten. Die Notation der Regeln ist a¨hnlich zu denen von Story Patterns. Die linke und rechte Regelseite einer Graphtransformationsregel werden in einem Graphen zusammengefasst. Elemente, die durch die Anwendung einer Regel gelo¨scht oder erzeugt werden, werden entsprechend gekennzeichnet. Wie in Story Patterns wird die negative Anwendungsbedingung in Form von negativen Knoten und Kanten zum Diagramm hinzugefu¨gt. Im Rahmen dieser Arbeit wird Groove dazu verwendet, um fu¨r eine Menge von Story Patterns deren Anwendbarkeit zu untersuchen und zu pru¨fen, 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 unterstu¨tzt, werden zu Evaluierungszwecken Story Patterns verwendet, um den Startgraphen eines Graphtransformationssystems zu modellieren. Diese Story Patterns du¨rfen weder zu lo¨schende oder zu erzeugende Elemente enthalten, noch du¨rfen sie negative Knoten oder Kanten besitzen. Die zu verifizierenden Regeln werden in Fujaba mittels 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 erla¨utert werden. Der Startgraph entspricht dem in Abbildung 5.1 gegebenen Story Pattern. Dieses Story Pattern beschreibt ein Shuttle -System bestehend aus fu¨nf Track s, die im Kreis angeordnet sind sowie zwei Shuttle s, 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 fu¨hren, dass sich zwei Shuttle s 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 fu¨r die einzelnen Story Patterns angegeben werden, ob es sich dabei um einen Startgraphen, eine Regel oder ein gefordertes oder verbotenes Story Pattern handelt. Wird fu¨r ein Story Pattern angegeben, dass es sich dabei um eine Regel handelt, so besteht die Mo¨glichkeit, fu¨r diese Regel noch eine Priorita¨t anzugeben. Das bedeutet, wenn auf ein Objektdiagramm zwei Story Patterns angewendet werden ko¨nnen, so wird immer das Story Pattern mit der ho¨heren Priorita¨t angewendet. Haben beide Story Patterns die gleiche Priorita¨t, so wird nichtdeterministisch eines der beiden Story Patterns angewendet. Da die Transformation fu¨r Startgraphen, Regeln und verbotene Graphmuster gleich ist, soll sie hier am Beispiel der Regel moveSimple aus Abbildung 5.2 erla¨utert werden. Groove unterscheidet zwischen einer internen Darstellung und einer graphischen Darstellung. Im Folgenden werden jeweils beide Darstellungen angegeben. Fu¨r jedes Objekt im Story Pattern wird ein Knoten in Groove erzeugt. In Story Patterns ko¨nnen sowohl die Objekte, als auch die Links beschriftet sein. In Groove ko¨nnen dagegen nur die Kanten beschriftet sein. Um auch einem Knoten eine Beschriftung zuweisen zu ko¨nnen, muss eine Selbstkante eingefu¨gt werden. Die Beschriftung des Knotens entspricht dann der Beschriftung dieser Kante. Soll einem Knoten sowohl ein Name als auch ein Typ zugewiesen werden, so mu¨ssen dafu¨r zwei Kanten in das Modell eingefu¨gt werden. Daraus resultieren jedoch Unterschiede bei der Anwendung eines Story Patterns und der entsprechenden Regel in Groove. Soll das Story Pattern angewendet werden, so wird u¨berpru¨ft, ob die Objekte des Story Patterns auf Objekte im Objektdiagramm abgebildet werden ko¨nnen, die den gleichen Typ haben. Der Name der Objekte wird bei dieser Abbildung jedoch nicht beru¨cksichtigt. Soll dagegen die Regel in Groove angewendet werden, so ist das nur mo¨glich, 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. WERKZEUGUNTERSTU¨ TZUNG der Regel besitzt. Dadurch wird die Anwendbarkeit einer Regel im Vergleich zum dazugeho¨rigen Story Pattern eingeschra¨nkt. Deshalb wird hier nur der jeweilige Objekttyp nach Groove exportiert. Fu¨r jeden Link des Story Patterns wird eine Kante in den Graph von Groove eingefu¨gt, wobei die Kantenbeschriftung dem Linktypen entspricht. Wird ein Element durch das Story Pattern gelo¨scht, erzeugt oder ist im Story Pattern als n"dneeegswsaet:in"vbewzsweEr.dl"eenmnoetz:n"utealrow¨nsgeceihtgeeernbtd.eeInn,EdsleoermwgerianrpdtehdimsiecihtKegnaenDsttearnircbshteeesllcltuhennrigfbtwulaniurgdenidnaLsGiPnroriae¨ofinvxeunnuidmchbdtlaaansugePerrza¨Seficixghtr."idfStet,al:zt"tu-, erzeugende Elemente mit dicken gru¨nen Linien und gru¨ner 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 gelo¨scht. Außerdem kann eine Regel 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 DPO iso Ansatz erfolgt, mu¨ssen zwei Modifikationen an den Regeln erfolgen. 1. Bevor ein Story Pattern, das eine Regel darstellt, nach Groove exportiert werden kann, muss es um zusa¨tzliche negative Knoten erweitert werden. Diese zusa¨tzlichen negativen Knoten verhindern eine Anwendung, sollten anderenfalls lose Kanten entstehen. Die Erweiterung der Story Patterns entspricht der Erweiterung von Graphtransformationsregeln, 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 erzwungen werden, dass der Match der linken Regelseite einem Teilgraphisomorphismus entspricht. Dazu werden in Groove negative Kanten verwendet. Fu¨r jedes Paar von Knoten, die den selben Typ haben und entweder durch die Regelanwendung gelo¨scht oder explizit erhalten bleiben und nicht negativ sind, muss eine Fu¨r zwei negative Knoten mit zusa¨tzliche dem selben Kante Typen bezinwg. effu¨u¨rgetinweenrdneeng,atdivieenmKitn"onteont:"ubnedscehinreifnteptoissit-. tiven Knoten, der nicht durch die Regel erzeugt wird, wird eine zusa¨tzliche mit Kante eingefu¨gt. In der graphischen Darstellung werden dann negative Kanten "a!nngoetz"ebiegstc, hdriieftmetiet "="bAzbwb.il"d!unnogt"b5e.4sczheriifgttetdsieinRd.egel 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 du¨rfen, 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. Simulation und Verifikation erfolgen in Groove in Abha¨ngigkeit davon, ob die Eingabe geforderte oder verbotene Regeln entha¨lt. Verbotene Regeln stellen kritische Situationen oder Unfa¨lle 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 dargestellt 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 ausgehend vom Startzustand den Zustandsraum des Systems, in dem er alle mo¨glichen Regeln zuna¨chst auf den Anfangszustand und dann auf alle resultierenden Zusta¨nde anwendet. Der Aufbau 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 Zusta¨nden entsprechen und die Kanten den Regelanwendungen. Aus Effizienzgru¨nden wird fu¨r mehrere isomorphe Graphen nur ein Zustand erzeugt, sodass aus dem Baum ein Graph wird. Nach[HEWC97] wird dieser Graph als Graphtransitionssystem bezeichnet. Wa¨hlt man einen der Knoten des Graphen aus, so wird der entsprechende Zustand angezeigt und die Anwendungsstelle der na¨chsten Regel hervorgehoben. Eine weitere Hilfe, die Groove bietet, besteht darin, dass der Simulator eine Liste entha¨lt, in der die Namen aller angewendeten Regeln aufgefu¨hrt werden. Aus dieser Liste ko¨nnen dann Ru¨ckschlu¨sse auf die Anwendbarkeit der Regeln gezogen werden. Wurde eine Regel nicht angewendet, so kann dies am gewa¨hlten Initialgraphen liegen, es kann aber auch ein Indiz dafu¨r 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. Fu¨r eine geforderte Eigenschaft ist ein solches Gegenbeispiel ein Graph, auf den die entsprechende Regel nicht angewendet werden kann. Ein Gegenbeispiel fu¨r 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 RealTime Tool Suite darzustellen. Da bei großen Systemen mit vielen verschiedenen Zusta¨nden die Darstellung des Zustandsraums unu¨bersichtlich wird, soll statt des gesamten Zustandsraums nur der ku¨rzeste Pfad vom Startzustand zu einem inkorrekten Endzustand betrachtet werden. Ein solcher Pfad besteht aus einer Menge von Graphen und den darauf angewendeten Transformationsregeln. Da die Graphen groß und somit unu¨bersichtlich werden ko¨nnen und es fu¨r eine Regel

120 KAPITEL 5. WERKZEUGUNTERSTU¨ TZUNG unter Umsta¨nden mehrere Anwendgungsstellen in einem Graphen gibt, soll Groove so angepasst werden, dass neben den Zusta¨nden des Systems auch die verwendeten Matchings der Regeln gespeichert werden 2 . Das Fenster, das das Gegenbeispiel anzeigt, ist dreigeteilt. Links oben wird eine Liste mit den Namen aller verbotenen Story Patterns des Systems angegeben, fu¨r die ein Gegenbeispiel gefunden wurde. Darunter ist eine Tabelle abgebildet, in der von oben nach unten der Pfad vom Startzustand zu einem Zustand aufgefu¨hrt ist, auf den das ausgewa¨hlte verbotene Story Pattern angewendet werden kann. Links steht der jeweilige Zustand, daneben steht die auf diesen Zustand angewendete Regel und der resultierende Zustand steht rechts. Wa¨hlt man eine Zeile aus, so wird der links angegeben Graph im rechten Teil des Fensters angezeigt und die Anwendungsstelle des Story Patterns wird farblich hervorgehoben. Die Anwendungsstelle eines Story Patterns wird gru¨n hervorgehoben, die Anwendungsstelle eines verbotenen Story Patterns rot. In Abbildung 5.5 ist ein Gegenbeispiel fu¨r 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 Ansa¨tze zur Verifikation von Graphtransformationssystemen, wie zum Beispiel Groove, beno¨tigen 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 2 Mit 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 Graphen erzeugen phmusters eine ikno¨dnunketinv.eDInavzauriawnitreddgeeszSeyigstte, mdassisst.dWasie"NinicKhat-pAituelft4regteezn"eiegitnwesurvdeer,bsotteelnleennSGtorrayPatterns eine eingeschra¨nkte Form der in Kapitel 3 eingefu¨hrten Graphtransformationssysteme dar. Deshalb ist es mo¨glich, den Verifikationsansatz aus Kapitel 3 zur Verifikation von Story Patterns zu verwenden. In diesem Abschnitt soll das Fujaba Plugin vorgestellt werden, dass den Ansatz fu¨r Story Patterns umsetzt und vollautomatisch ausfu¨hrt(siehe dazu auch[Bec05, BGS05a]). Als Eingabe erwartet das Plugin eine Menge von Story Patterns sowie eine Menge von verbotenen Story Patterns. Im Gegensatz zu dem in Abschnitt 5.2 vorgestellten Groove-Plugin wird jedoch kein Initialgraph beno¨tigt. Im Folgenden werden das Story Pattern moveSimple (Abbildung 5.4(a)) und das verbotene 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, mu¨ssen die Story Patterns im DPO iso Ansatz angewendet werden. Die Verwendung eines Isomorphismus zur Beschreibung des Matchings garantiert, dass die Identifikationsbedingung immer erfu¨llt ist. Damit auch die Lose-Kanten-Bedingung immer erfu¨llt wird, mu¨ssen die Story Patterns um negative Elemente erweitert werden, die eine Anwendung verhindern, wenn andernfalls lose Kanten resultieren. Die Erweiterung der Story Patterns erfolgt durch die Funktion RuleExtension . Der Verifikationsalgorithmus bestimmt fu¨r jedes Story Pattern und jedes verbotene Story Pattern alle mo¨glichen Abbildungen der Nachbedingung auf das verbotene Story Pattern. Diese Berechnung erfolgt mittels der Funktion Matching . Fu¨r 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 entha¨lt. 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 ru¨ckwa¨rts angewendet. Das resultierende Story Pattern entspricht dann einem Startgraphmuster. Fu¨r dieses Story Pattern muss u¨berpru¨ft werden, ob es korrekt ist, d.h. ob es kein verbotenes Story Pattern entha¨lt und es kein Match fu¨r die Anwendungsbedingung eines ho¨her priorisierten Story Patterns im Startgraphmuster gibt. Fu¨r diese U¨ berpru¨fung wird wieder die Funktion Matching verwendet. Matching Die Matching -Funktion berechnet, ob es fu¨r 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 zuru¨ckgegeben.

122 KAPITEL 5. WERKZEUGUNTERSTU¨ TZUNG Die Funktion berechnet das Matching sukzessive. Sie beginnt mit einem Objektpaar, einem Objekt n1 aus G1 und einem Objekt n2 aus G2 . Sie pru¨ft, 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. Fu¨r alle Links, die inzident zu n1 sind, wird gepru¨ft, ob es einen Link in G2 gibt, auf den sie abgebildet werden ko¨nnen und der inzident zu n2 ist. Bei dieser Abbildung muss zum einen gepru¨ft 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. Erfu¨llt 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 gepru¨ft, ob dieses auf ein Objekt aus G2 abgebildet werden kann, auf das bisher noch kein anderes Objekt abgebildet wurde. Ko¨nnen alle Objekte und Links aus G1 auf Objekte und Links aus G2 abgebildet werden, so wird das berechnete Matching zuru¨ckgegeben. Die Matching -Funktion wird unter anderem zur Bildung der Ergebnisgraphmuster beno¨tigt. Dazu muss die Funktion ein Matching eines Teil-Story Patterns 3 der 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 fu¨r dieses Teil-Story Pattern und das verbotene Story Pattern aus Abbildung 5.3 die Matching -Funktion aufgerufen, so liefert sie zwei mo¨gliche Matchings zuru¨ck. 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 verla¨uft. 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 zusa¨tzliche negative Objekte zu erweitern, sodass die Anwendung des Story Patterns verhindert wird, wenn andernfalls lose Kanten resultieren sollten. Diese Erweiterung erfolgt nur intern und ist fu¨r den Benutzer des Plugins nicht sichtbar. Die Funktion erweitert sowohl die Vor- als auch die Nachbedingung des Story Patterns um zusa¨tzliche negative Elemente, damit weder bei der Vorwa¨rts- noch bei der Ru¨ckwa¨rtsanwendung des Story Patterns lose Kanten entstehen ko¨nnen. Die Erweiterung entspricht der Regelerweiterung aus Definition 27 in Kapitel 3. Bei der Erweiterung der Vorbedingung werden alle Objekte betrachtet, die durch die Anwendung des Story Patterns gelo¨scht werden. Dazu wird im Klassendiagramm nachgesehen, welche Typen adjazent zu dem Typ des zu lo¨schenden Objektes sind. Fu¨r jeden dieser adjazenten Typen wird ein negatives Objekt in das Story Pattern eingefu¨gt, falls dieses noch nicht existiert und durch einen Link mit dem zu lo¨schenden Objekt verbunden ist. Bei der Erweiterung der Nachbedingung wird ebenso verfahren. Statt der zu lo¨schenden Objekte werden jedoch die zu 3 Ein Teil-Story Pattern besteht aus einer Teilmenge der Objekte und Links des urspru¨nglichen 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 Ru¨ckwa¨rtsanwendung des Story Patterns die Bedingungen des DPO iso Ansatzes erfu¨llt sind. Die Funktion liefert das derart erweiterte Story Pattern zuru¨ck. Da eine Erweiterung eines Story Patterns nur dann notwendig ist, wenn das Story Pattern ein Objekt erzeugt oder lo¨scht, das moveSimple Story Pattern jedoch nur einen locatedOn -Link lo¨scht 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. Dazu beno¨tigt 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 ko¨nnen. Das so entstandene Story Pattern wird von der Funktion zuru¨ck 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 ) u¨bergeben, 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. Fu¨r Story Patterns ko¨nnen Priorita¨ten angegeben werden. Das heißt, sind auf eine Instanzsituation zwei oder mehr Story Patterns anwendbar, wird das Story Pattern mit der ho¨chsten Priorita¨t angewendet. Haben alle Story Patterns die gleiche Priorita¨t, so wird nichtdeterministisch eines der Story Patterns angewendet. Diese Priorita¨ten mu¨ssen bei der Verifikation beru¨cksichtigt werden. In einem ersten Schritt wird fu¨r jede Nachbedingung aller Story Patterns die Menge aller Teil-Story Patterns bestimmt. Fu¨r jedes der Teil-Story Patterns werden dann mittels der Matching -Funktion alle Matchings mit allen verbotenen Story Patterns gebildet. Jedes gefundenen

124 KAPITEL 5. WERKZEUGUNTERSTU¨ TZUNG Matching wird anschließend zusammen mit dem Story Pattern und dem verbotenen Story Pattern an die Merge -Funktion u¨bergeben, die daraus ein neues Story Pattern, das Ergebnisgraphmuster, bildet. Das entsprechende Story Pattern wird durch die Funktion RuleExtension erweitert und ru¨ckwa¨rts auf jedes der Ergebnisgraphmuster angewendet. Daraus resultieren die Startgraphmuster. Fu¨r jedes dieser Startgraphmuster pru¨ft die Matching -Funktion, ob es ein Matching fu¨r ein verbotenes Story Pattern in dem Startgraphmuster gibt. Kann kein solches Matching gefunden werden, so wird gepru¨ft, ob es ein Story Pattern mit ho¨herer Priorita¨t gibt, das auf das Startgraphmuster angewendet werden kann, d.h. fu¨r dessen Anwendungsbedingung es ein Matching im Startgraphmuster gibt. Ist dies der Fall, so verhindert das ho¨her priorisierte Story Pattern die Anwendung des zuvor betrachteten Story Patterns. Kann kein solches ho¨her priorisiertes Story 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 fu¨hren kann. Die Menge der zu betrachtenden Ergebnisgraphmuster kann im Vergleich zu der Menge aus Kapitel 3 reduziert werden. Diese Reduktion resultiert aus der geringeren Ausdruckssta¨rke der negativen Elemente im Vergleich zu den negativen Anwendungsbedingungen(siehe Abschnitt 4.2.2). Wie in Graphtransformationssystemen gibt es auch bei Story Patterns zwei Mo¨glichkeiten einen korrekten Graphen in einen inkorrekten zu u¨berfu¨hren. Die erste besteht darin, dass ein Element erzeugt wird, das Teil der Anwendungsbedingung des verbotenen Story Patterns ist. Die zweite Mo¨glichkeit ist, dass ein Element gelo¨scht wird und dieses Element zur negativen Anwendungsbedingung des verbotenen Graphmusters geho¨rt, aber nicht zu dessen Anwendungsbedingung. 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 du¨rfen und negative Knoten nicht miteinander verbunden sein du¨rfen, kann der zweite Fall nur dann eintreten, wenn ein Element gelo¨scht wird, das inzident bzw. adjazent zu einem positiven Objekt ist. Deshalb brauchen im zweiten Fall bei den Story Patterns nur solche Ergebnisgraphmuster 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 Story Patterns ist nicht notwendig. Fu¨r Graphtransformationsregeln mu¨ssen dagegen auch solche Fa¨lle betrachtet werden, in denen Knoten der rechten Regelseite auf Knoten eines Graphen der negativen Anwendungsbedingung abgebildet werden ko¨nnen. Hat der Algorithmus ein Gegenbeispiel gefunden, das zeigt, dass in einem System eine kritische Situation oder ein Unfall auftreten kann, so terminiert er. In diesem Fall wird das gefundene Gegenbeispiel zuru¨ckgegeben. Terminiert der Algorithmus nachdem fu¨r jedes Story Pattern und jedes verbotene Story Pattern alle mo¨glichen 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 bedeInutmeta, ndcahsesndaFsa¨lSletanrtkgarnanphems vuostrekrodmiemAenn,wdeansdsudnegrsAbelgdoinrigthumnguesi"nuenskvneorwbont"eznuernu¨cSktolireyfePrat.ttDeriness oder eines ho¨her priorisierten Story Patterns entha¨lt. Allerdings kann keine der negativen Kanten auf das Startgraphmuster abgebildet werden, bzw. fu¨r 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 einem Story Pattern, dessen Anwendung auf das Startgraphmuster im Ergebnisgraphmuster resultiert. 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 ko¨nnen dann wieder in Fujaba dargestellt werden. Fu¨r das Story Pattern moveSimple aus Abbildung 5.2 und das verbotene Story Pattern collision 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 Startgraphmuster, das untere das Ergebnisgraphmuster. Das angewendete Story Pattern wird nicht abgebildet. 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 moveSimple zu einem Objektdiagramm fu¨hren kann, das den Unfall collision entha¨lt. Dies ist genau dann der Fall, wenn zwei Shuttle s existieren, die auf benachbarten Track s positioniert sind. Wird das Story Pattern moveSimple nun auf das hintere der beiden Shuttle s angewendet, so wird dieses auf den na¨chsten Track gesetzt und die beiden Shuttle s befinden sich auf demselben Track . 5.4 Evaluierung Im voran gegangenen Abschnitt wurde die prototypische Umsetzung des Verifikationsansatzes aus Kapitel 3 fu¨r Story Patterns beschrieben. Die Aufwandsabscha¨tzung am Ende von Kapitel 3 ergab, dass der Verifikationsansatz exponentiell von der Gro¨ße der Graphen, die die linke und rechte Regelseite, die Graphmuster und die negativen Anwendungsbedingungen repra¨sentieren, abha¨ngt, 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 Aufwandsabscha¨tzung 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 Realita¨t jedoch selten ein. Bevor in Abschnitt 5.4.2 die Evaluierung des Plugins zum automatischen Nachweis von induktiven Invarianten beschrieben wird, werden in Abschnitt 5.4.1 die wichtigsten Charakteristiken des evaluierten Modells genannt.

126 KAPITEL 5. WERKZEUGUNTERSTU¨ TZUNG Abbildung 5.7: Von Fujaba generiertes Gegenbeispiel, das zeigt, dass das Story Pattern moveSimple 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 zugewiesen. Zur Evaluierung wurden alle Story Patterns und verbotenen Graphmuster der ControlledMovement -Kultur sowie der u¨bergeordneten Movement -Kultur verwendet. Insgesamt wurden 7 Story Patterns verifiziert. Davon haben 4 Story Patterns Instanzierungsregeln dargestellt und 3 Verhaltensregeln. Bei der Verifikation wurde nachgewiesen, dass die Story Patterns 12 verbotene Story Patterns erfu¨llen. 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 Kardinalita¨ten des zugeho¨rigen Klassendiagramms nachzubilden. Die Nachbildung der Kardinalita¨ten ist notwendig, da weder der Ansatz aus Kapitel 3 noch dessen im voran gegangenen Abschnitt vorgestellte prototypische Umsetzung die im Klassendiagramm vorgegebenen Kardinalita¨ten noch nicht beru¨cksichtigen(siehe dazu auch Abschnitt 7.2). La¨sst man die vorgegebenen Kardinalita¨ten bei der Verifikation jedoch außer Acht, so liefert das Plugin unter Umsta¨nden ungu¨ltige Gegenbeispiele. Alle verifizierten(verbotenen) Story Patterns werden in Anhang A dargestellt und erla¨utert. Die Aufwandsabscha¨tzung in Kapitel 3 hat ergeben, dass der Verifikationsaufwand von der Gro¨ße der Graphen abha¨ngig ist. Fu¨r Story Patterns und verbotene Story Patterns wird bei der

5.4. EVALUIERUNG 127 Evaluierung das folgende Gro¨ßenmaß verwendet: Die Gro¨ß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 U¨ berlegung, dass der aufwa¨ndigste Schritt bei der Verifikation die Bildung aller mo¨glichen Ergebnisgraphmuster ist. Ein solches Ergebnisgraphmuster setzt sich genau aus den Elementen zusammen, die zum verbotenen Story Pattern geho¨ren oder durch das zu verifizierende Story Patterns erhalten bleiben bzw. erzeugt werden. Wurden die positiven Elemente zu einem Ergebnisgraphmuster zusammengefu¨gt, so wird die negative Anwendungsbedingung durch Hinzufu¨gen der negativen Elemente gebildet. Eine U¨ bersicht u¨ber die Gro¨ße der verifizierten Story Patterns und verbotenen Story Patterns ist in Tabelle 5.1 gegeben. Dabei gibt # O jeweils die Anzahl der Objekte an und # L die Anzahl der Links. Gro¨ße der Story Patterns Minimum Maximum Durchschnitt # O# L# O# L# O# L 5 8 10 11 7 9 Gro¨ße der verbotenen Story Patterns Minimum Maximum Durchschnitt # O# L# O# L# O# L 22443 3 Tabelle 5.1: Gro¨ße der verifizierten(verbotenen) Story Patterns 5.4.2 Evaluierung des Plugins zum automatischen Nachweises von induktiven Invarianten Die Aufwandsabscha¨tzung fu¨r den Verifikationsansatz in Abschnitt 3.7.3 hat ergeben, dass der Aufwand exponentiell in der Gro¨ße der(verbotenen) Story Patterns, aber nur linear in deren Anzahl ist. Die Abscha¨tzung erfolgte fu¨r den schlechtesten Fall. Dieser tritt ein, wenn alle Objekte und Links der(verbotenen) Story Patterns denselben Typ haben. In diesem Abschnitt soll zuna¨chst anhand eines kleinen Beispiels gezeigt werden, welche Auswirkungen die Gro¨ß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 Fa¨llen 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 durchgefu¨hrt. Um die Auswirkung der Gro¨ße der(verbotenen) Story Patterns zu veranschaulichen, wird das im vorgegangenen Abschnitt charakterisierte Beispiel verifiziert. Die Verifikation des Beispiels beno¨tigte insgesamt 84 Sekunden. Bei der Verifikation wird fu¨r jedes Paar, bestehend aus einem Story Pattern und einem verbotenen Story Pattern, u¨berpru¨ft, ob die Anwendung des Story Patterns das verbotene Story Pattern erzeugen kann. Das Diagramm in Abbildung 5.8 zeigt die Verifikationszeiten fu¨r jedes dieser Paare. Die Zeiten sind in Sekunden angegeben. Statt der Namen der(verbotenen) Story Patterns sind die jeweiligen Gro¨ßen an den Achsen notiert. An der x-Achse sind die Gro¨ßen der verifizierten Story Patterns in aufsteigender Folge notiert. Die y-Achse stellt die Gro¨ßen der verwendeten

128 KAPITEL 5. WERKZEUGUNTERSTU¨ TZUNG verbotenen Story Patterns in aufsteigender Folge dar. Wie an der Graphik zu sehen ist, steigt der Aufwand fu¨r die Verifikation mit der Gro¨ße der(verbotenen) Story Patterns an. Der Grund dafu¨r, dass die Verifikation der beiden gro¨ß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. 9,0 8,0 7,0 6,0 5,0 4,0 3,0 2,0 1,0 10|11 0,0 8|9 2|2 2|2 2|2 2|2 2|2 3|2 3|2 4|3 4|3 4|3 4|4 4|4 6|9 5|8 Abbildung 5.8: Beno¨tigte Verifikationszeiten In Story Patterns haben alle Objekte einen Typ. Um den Einfluss der Verwendung von Typen auf den Verifikationsaufwand zeigen zu ko¨nnen, wurden allen Objekten die gleichen Typen zugewiesen. Verifiziert man die so modifizierten Story Patterns, so ergibt die Analyse, dass die Story Patterns einen inkorrekten Zustand erzeugen ko¨nnen. In diesem Fall bricht die Analyse ab, sobald ein Gegenbeispiel gefunden wurde. Um die Verifikationszeiten dennoch mit denen des korrekten, typisierten Beispiels vergleichen zu ko¨nnen, wurde der Evaluierungsmodus des Plugins verwendet. Dieser Modus fu¨hrt die Analyse so durch, als wa¨ren 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 fu¨r die graphische Darstellung beno¨tigt. Die Verifikation des gesamten nicht typisierten Beispiels musste nach etwa 12 Stunden erfolglos abgebrochen werden. Eine weitere Analyse der 7 Story Patterns sowie der 3 verbotenen Story Patterns, die im urspru¨nglichen Beispiel den Unfall und die beiden kritischen Situationen modelliert haben, konnte erfolgreich in 1755,8 Sekunden durchgefu¨hrt werden. Tabelle 5.2 stellt die beno¨tigten Verifikationszeiten fu¨r diese(verbotenen) Story Patterns aus dem typisierten und dem nicht typisierten Beispiel gegenu¨ber. Wie schon in Abbildung 5.8, werden auch hier statt der Namen der(verbotenen) Story Patterns deren Gro¨ßen angegeben. Die Zeiten sind jeweils in Sekunden angegeben. Verbotene Story Patterns/ Story Patterns 5 | 5 6 | 6 6 | 4 6 | 10 5 | 9 6 | 10 6 | 11 gesamt 3 | 2 Typen keine Typen 0,4 1,1 0,4 1,4 0,4 2,0 0,4 1,4 0,4 2,1 0,5 4,0 0,8 2,8 3,3 14,8 4 | 4 Typen keine Typen 0,4 7,8 0,4 12,3 0,4 12,9 0,4 26,5 0,4 1207,4 0,5 131,7 0,7 187,8 3,4 1586,4 4 | 4 Typen keine Typen 0,4 6,4 0,5 12,4 0,4 15,7 0,4 10,6 0,4 22,4 0,5 61,5 0,7 25,6 3,3 154,6 Tabelle 5.2: Vergleich der Verifikationszeiten mit und ohne Typen Wie der Tabelle 5.2 zu entnehmen ist, beno¨tigt die Verifikation ohne Typen deutlich la¨nger 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 zusa¨tzlichen(verbotenen) Story Patterns sind gro¨ßer als die(verbotenen) Story Patterns der ControlledMovement -Kultur und auch die Anzahl von Objekten mit demselben Typ ist gro¨ßer. Ein Grund fu¨r 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 Ergebnisgraphmuster 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 berechnet jedoch jedes mo¨gliche 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. Daru¨ber hinaus wurde in[GSK + 06] eine erste Idee pra¨sentiert, die es ermo¨glicht die(verbotenen) Story Patterns symbolisch zu codieren. Auf diese Weise brauchen die Ergebnisgraphmuster nicht mehr

130 KAPITEL 5. WERKZEUGUNTERSTU¨ TZUNG einzeln aufgeza¨hlt werden, sondern ko¨nnen zu Mengen zusammengefasst werden. Um die Ergebnisgraphmuster zu bestimmen, die Ru¨ckwa¨rtsanwendung der Regeln durchzufu¨hren und fu¨r die resultierenden Startgraphmuster zu pru¨fen, ob diese eines der verbotenen Story Patterns oder die Anwendungsbedingung eines ho¨her priorisierten Story Patterns enthalten, wird der BDDbasierte Interpreter CroCoPat[BNL05] verwendet. 5.5 Zusammenfassung In diesem Kapitel wurde die Werkzeugunterstu¨tzung fu¨r die Modellierung und Verifikation der Software mechatronischer Systeme vorgestellt. Die Fujaba Real-Time Tool Suite unterstu¨tzt die Modellierung der Softwarearchitektur sowohl durch Klassendiagramme als auch durch Komponentendigramme. Fu¨r die Modellierung des Koordinationsverhaltens bietet Fujaba Real-Time Statecharts. Die in den Statecharts aufgerufenen 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 Aufwandsabscha¨tzung aus Kapitel 3 besta¨tigt. 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 Mo¨glichkeit, automatisch Code zu generieren. Dies bietet den Vorteil, dass Eigenschaften, die durch die formale Verifikation nachgewiesen wurden, auch durch die Implementierung erfu¨llt werden.

Kapitel 6 Verwandte Arbeiten Der in den Kapiteln 2 und 3 vorgestellte Ansatz ermo¨glicht 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 unterstu¨tzt und automatisiert wird. In diesem Kapitel sollen nun verwandte Arbeiten betrachtet werden. Ein ausfu¨hrlicher Vergleich des gesamten Modellierungs- und Verifikationsprozesses und seiner Umsetzung in der Fujaba Real-Time Tool Suite mit verwandten Ansa¨tzen wurde von Burmester in[Bur05] vorgenommen. An dieser Stelle soll ein Vergleich des in Kapitel 3 vorgestellten Ansatzes zur Verifikation von Graphtransformationssystemen mit anderen existierenden Ansa¨tzen 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 fu¨hren ko¨nnen. Die zweite betrachtete Kategorie stellen Ansa¨tze dar, bei denen Model Checking Techniken dazu eingesetzt werden, um bestimmte Eigenschaften fu¨r ein Graphtransformationssystem nachzuweisen. Diese Ansa¨tze werden in Abschnitt 6.2 beschrieben. In Abschnitt 6.3 werden Verifikationstechniken fu¨r Graphtransformationssysteme erla¨utert, die auf Petrinetzanalysetechniken basieren. 6.1 Korrektheit per Konstruktion Der von Heckel und Wagner in[HW95] vorgestellte Ansatz diente als Basis fu¨r den in Kapitel 3 vorgestellten Ansatz zur Verifikation von Graphtransformationssystemen. Der Ansatz von Heckel und Wagner ermo¨glicht es, Graphtransformationsregeln so zu modifizieren, dass bestimmte strukturelle Eigenschaften eines beliebigen Graphen bei der Regelanwendung erhalten bleiben. In der AGG Tool Suite 1 wurde dieser Ansatz prototypisch umgesetzt[Mat01]. Die Regeln werden im Single Pushout Ansatz angewendet. Ihre Anwendung kann durch Conditional Constraints, die zur linken Regelseite hinzugefu¨gt werden, eingeschra¨nkt 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. 1 http://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 Pra¨misse P und der Konklusion Q ; Wobei es einen totalen Homomorphismus gibt, der die Pra¨misse auf die Konklusion abbildet. Ein Graph erfu¨llt ein Konsistenzconstraint, wenn es einen Homomorphismus gibt, der die Pra¨misse P auf den Graphen abbildet und der so erweitert werden kann, dass er neben P auch die Konklusion Q auf den Graphen abbildet. Ein Graph wird als konsistent bezeichnet, wenn er die Konsistenzbedingung erfu¨llt. Ein Graphtransformationssystem ist konsistent, wenn jede Anwendung einer Regel auf einen konsistenten Graphen wieder einen konsistenten Graphen erzeugt. Das Ziel des Ansatzes aus[HW95] besteht darin, die Regeln eines Graphtransformationssystems 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 Konsistenzbedingungen verbunden wird. Dabei werden jedoch nur die Fa¨lle beru¨cksichtigt, 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 angewendet. Daraus resultiert wieder ein Graph. Dieser Graph stellt dann ein zusa¨tzliches 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 eingefu¨hrten Konsistenzbedingungen entspricht der Definition der induktiven Invarianten. Beide Begriffe bezeichnen Eigenschaften, die, wenn sie von einem Graphen erfu¨llt sind, durch die Anwendung einer beliebigen Regel erhalten bleiben. Ein Unterschied zwischen den beiden Ansa¨tzen besteht in der Verwendung von negativen Anwendungsbedingungen in Regeln und verbotenen Graphmustern bzw. graphischen Konsistenzconstraints. Die negative Anwendungsbedingung einer Regel oder eines verbotenen Graphmusters aus Kapitel 3 kann aus einer Menge von Graphen bestehen, die Alternativen beschreiben. Dagegen kann die Pra¨misse einer Regel oder eines Konsistenzconstraints in[HW95] nur aus einem Graphen bestehen. Der Ansatz von Heckel und Wagner bietet zwar die Mo¨glichkeit zusa¨tzlich zur Pra¨misse noch eine Konklusion anzugeben, diese kann bei Regeln aus einer Menge von Graphen bestehen, bei Konsistenzbedingungen nur aus genau einem Graphen, allerdings haben die Pra¨missen eine andere Semantik als die negativen Anwendungsbedingungen aus Kapitel 3. Eine Regel ist nach[HW95] anwendbar bzw. ein Konsistenzconstraint erfu¨llt, wenn die Pra¨misse mittels eines Homomorphismus auf den Anwendungsgraphen abbildbar ist und der verwendete 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 u¨berfu¨hrt werden kann. Zum einen indem bei einer Regelanwendung ein Element erzeugt wird, das Teil der Anwendungsbedingung des verbotenen Graphmusters ist. Zum andere kann eine Regel ein Element lo¨schen, das zur negativen Anwendungsbedingung, aber nicht zur Anwendungsbedingung des verbotenen Graphmusters geho¨rt. Beim Nachweis induktiver Invarianten, wie er in dieser Arbeit vorgestellt wurde, werden beide Fa¨lle beru¨cksichtigt. Dagegen wird in[HW95] nur der erste Fall betrachtet.

6.1. KORREKTHEIT PER KONSTRUKTION 133 Bei der Modifikation der Graphtransformationsregeln nach[HW95] wird jedes Konsistenzconstraint unabha¨ngig von den anderen Constraints betrachtet. Das kann dazu fu¨hren, dass eine Regel unno¨tig um zusa¨tzliche Conditional Constraints erweitert wird. Das ist genau dann der Fall, wenn ein Konsistenzconstraint c 1 nur verletzt werden kann, wenn die betrachtete Regel auf einen Graphen angewendet wird, der zwar das Constraint c 1 erfu¨llt, aber inkonsistent in Bezug auf ein zweites Konsistenzconstraint c 2 ist. Im schlimmsten Fall kann die Anwendung einer Regel auch ohne Modifikation keine inkonsistenten Graphen erzeugen, der Ansatz fu¨gt aber fu¨r jedes Konsistenzconstraint und jede seiner mo¨glichen Verklebungen mit der rechten Regelseite ein neues Conditional Constraint zur linken Regelseite hinzu. Um eine so erweiterte Regel anwenden zu ko¨nnen, muss fu¨r jedes Conditional Constraint u¨berpru¨ft werden, ob es erfu¨llt ist. Dies kann einen erheblichen Mehraufwand fu¨r die spa¨tere Regelanwendung bedeuten. Im Gegensatz dazu werden beim Nachweis von induktiven Invarianten die verbotenen Graphmuster nicht unabha¨ngig voneinander betrachtet. Nachdem das Ergebnisgraphmuster gebildet wurde, wird die entsprechende Regel ru¨ckwa¨rts auf das Muster angewendet. Fu¨r das resultierende Startgraphmuster wird dann u¨berpru¨ft, ob es ein verbotenes Muster entha¨lt. Kann ein beliebiges verbotenes Graphmuster im Startgraphmuster gefunden werden, so hat die Regelanwendung einen inkorrekten Graphen in einen anderen inkorrekten Graphen u¨berfu¨hrt. Die Zahl der gebildeten Ergebnisgraphmuster entspricht der Zahl der Verklebungen(zumindest fu¨r den Fall, dass die Regel ein Element erzeugt, das Teil der Anwendungsbedingung des verbotenen Graphmusters ist). Im Gegensatz zum Ansatz aus[HW95] mu¨ssen diese Ergebnisgraphmuster jedoch nur einmal zur Verifikation betrachtet werden, wa¨hrend die Konsistenzconstraints bei jeder Regelanwendung wieder u¨berpru¨ft werden mu¨ssen. Die Verwendung des Single Pushout Ansatzes kann sogar dazu fu¨hren, dass Conditional Constraints zur linken Regelseite hinzugefu¨gt werden, die eine Regelanwendung verhindern, obwohl diese nicht in einem inkonsistenten Graphen enden. Dies ist genau dann der Fall, wenn bei der Ru¨ckwa¨rtsanwendung der Regel Kanten implizit gelo¨scht 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 zuna¨chst ru¨ckwa¨rts auf einen Graphen G 1 an und dieselbe Regel dann wieder in Vorwa¨rtsrichtung auf den resultierenden Graphen, so erha¨lt man nicht den Graphen G 1 , da die implizit gelo¨schte Kante nicht wieder erzeugt wird. Der Ansatz hat also zuviele Conditional Constraints erzeugt. Um solche Probleme zu verhindern, wurde in Kapitel 3 der DPO iso eingefu¨hrt. Insgesamt gibt es einige Parallelen zwischen dem Ansatz von Heckel und Wagner und dem in Kapitel 3 vorgestellten Ansatz. Allerdings fu¨hrt das Hinzufu¨gen von zusa¨tzlichen Graphen zur negativen Anwendungsbedingung dazu, dass die U¨ berpru¨fung zur Laufzeit, ob die entsprechende Regel anwendbar ist, la¨nger dauert als zuvor. Dies ist dann kritisch, wenn eine Regelanwendung auch ohne die zusa¨tzlichen Graphen nicht anwendbar wa¨re, bzw. nicht zu einer Inkonsistenz fu¨hren kann. Es ist jedoch vorstellbar, die beiden Ansa¨tze zu kombinieren, sodass zuna¨chst eine U¨ berpru¨fung der Regeln durchgefu¨hrt wird und nur im Fehlerfall eine Modifikation der Regeln erfolgt. Dazu mu¨sste jedoch der Ansatz aus[HW95] zuna¨chst 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 Anwendung einer Regel ein Element lo¨scht und dadurch eine Sicherheitseigenschaft verletzt. Zudem erfolgt bei Koch et al. eine Modifikation einer Regel nur dann, wenn ihre Anwendung zu einem inkorrekten Graphen fu¨hren kann. Mit dem Verfahren, das Koch et al. in[KMPP02] vorstellen, ist es mo¨glich eine obere Schranke zu bestimmen, die angibt, wann die Anwendungen der Regeln ausgehend von einem gegebenen Startgraphen spa¨testens zu einem inkorrekten Graphen fu¨hren mu¨ssen. Die maximale Pfadla¨nge wird in Abha¨nigkeit vom gegebenen Startgraphen sowie der Anzahl der Regeln bestimmt. Mittels dieser maximalen Pfadla¨nge kann dann ein beschra¨nktes Model Checking (engl. bounded Model Checking) durchgefu¨hrt werden, d.h. ausgehend vom Startgraphen wird der Zustandsraum des Systems durch Anwendung der Regeln aufgebaut(siehe dazu auch Abschnitt 6.2). Fu¨r jeden erzeugten Graphen wird u¨berpru¨ft, ob er korrekt ist. Kann ein Graph erzeugt werden, der inkorrekt ist, bricht die Analyse ab. Sonst wird die Analyse fu¨r jeden der Pfade solange durchgefu¨hrt bis er zu Ende ist, d.h. keine Regelanwendung mehr mo¨glich ist, oder bis der betrachtete Pfad die maximale Pfadla¨nge 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 fu¨r den Fall, dass die Anwendung einer Regel ein Element lo¨scht und dadurch eine Eigenschaft verletzt und modifiziert eine Regel nur dann, wenn sie einen inkorrekten Graphen erzeugt, unterliegt aber ansonsten den gleichen Einschra¨nkungen. Um die maximal zu betrachtende Pfadla¨nge bestimmen zu ko¨nnen, mu¨ssen die Regeln im Vergleich zu denen von Heckel und Wagner deutlich eingeschra¨nkt werden. So darf eine Regel entweder Elemente erzeugen oder lo¨schen, aber nicht beides. Zudem du¨rfen nur Regeln, die Elemente lo¨schen, eine negative Anwendungsbedingung besitzen. Diese beiden Einschra¨nkungen der Regeln und vor allem die letztere sind jedoch fu¨r die hier betrachteten mechatronischen Systeme zu stark. Daru¨ber 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 Mo¨glichkeit, die Korrektheit eines Graphtransformationssystems nachzuweisen, stellt das Model Checking dar. Die Grundlage fu¨r das Model Checking von Graphtransformationssystemen wurde von Heckel et al. in[HEWC97] eingefu¨hrt. Aufbauend auf dieser Idee ko¨nnen Graphtransformationssysteme auf zwei Arten mittels Model Checking verifiziert werden. Zum einen ko¨nnen die Systeme auf die Eingabesprache eines existierenden Model Checkers abgebildet werden, so wie dies in CheckVML und OBGG erfolgt. Zum anderen ist es auch mo¨glich, Model Checking Techniken direkt auf Graphtransformationssysteme anzuwenden. Ein solcher Model Checker fu¨r Graphtransformationssysteme ist Groove(siehe auch Abschnitt 5.2). In[HEWC97] haben Heckel, Ehrig, Wolter und Corradini die Grundlage fu¨r das Model Checking von Graphtransformationssystemen eingefu¨hrt. Die von den Autoren betrachteten Re-

6.2. MODEL CHECKING VON GRAPHTRANSFORMATIONSSYSTEMEN 135 geln werden im Double Pushout Ansatz angewendet und du¨rfen keine negative Anwendungsbedingung besitzen. Die Graphen der betrachteten Systeme sind typisiert. Ansa¨tze, die auf dem Ansatz von Heckel et al. aufbauen und in Werkzeugen realisiert wurden, sind der CheckVML-Ansatz von Varro` et al.(Check Visual Modeling Languages,[SV03, Var04], der Groove-Ansatz von Rensink(GRaph-based Oject-Oriented VErification 2 , siehe Abschnitt 5.2 und[Ren03, Ren04]) sowie der OBGG-Ansatz von Dotti et al.(Object-Based Graph Grammars, [DFRS03]). Wobei sowohl bei Varro` als auch bei Rensink der Single Pushout Ansatz zur Regelanwendung verwendet wird. Der OBGG-Ansatz verwendet dagegen den klassischen Double Pushout Ansatz ohne negative Anwendungsbedingungen. Zusa¨tzlich werden die Regeln in diesem Ansatz so eingeschra¨nkt, dass Objekte nicht gelo¨scht werden du¨rfen. Die Idee der Ansa¨tze besteht darin, ein gegebenes Graphtransformationssystem auf ein Transitionssystem(z.B. Kripkestruktur oder Graphtransitionssystem, siehe Abschnitt 5.2) abzubilden. Jeder Zustand eines solchen Transitionssystems entspricht dann einem Graphen. Der Startzustand entspricht dem Initialgraphen des Graphtransformationssystems. Kann eine Regel auf einen bestimmten Graphen angewendet werden, so existiert im Transitionssystem fu¨r diese Regelanwendung eine Transition. Der Ausgangszustand der Transition repra¨sentiert den Anwendungsgraphen und der Zielzustand den aus der Regelanwendung resultierenden Graphen. Heckel et al. verwenden zur Beschreibung der Eigenschaften, die durch die Verifikation nachgewiesen werden sollen, graphische Konsistenzbedingungen(siehe Abschnitt 6.1) bzw. temporallogische Formeln. Eine temporallogische Formel fu¨r Graphtransformationssysteme setzt sich aus den u¨blichen 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 werden 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 u¨berfu¨hrt, 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 verschiedene Arten erfolgen. In CheckVML wird ein Graphtransformationssystem zuna¨chst auf einen abstrakten Zustandsautomaten(engl. abstract state machine) abgebildet. Ein solcher abstrakter 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 speziellen Model Checker fu¨r Graphtransformationssysteme entwickelt. Die Abbildung von Graphtransformationssystemen auf Transitionssysteme ermo¨glicht die Verwendung von Model Checkern zur Verifikation, d.h. sie kann dazu verwendet werden, einen Nachweis operationaler Invarianten zu fu¨hren. Durch diese Technik ko¨nnen jedoch nur Systeme mit endlichem Zustandsraum betrachtet werden. Um zu erreichen, dass das zu verifizierende System einen endlichen Zustandsraum hat, verwendet CheckVML ein beschra¨nktes Model Checking. Dazu muss a priori festgelegt werden wie viele Objekte von einem Typ zur Laufzeit erzeugt werden du¨rfen. Nach[RSV04] ist CheckVML deshalb fu¨r Systeme mit vielen dyna2 http://www.cs.utwente.nl/ groove

136 KAPITEL 6. VERWANDTE ARBEITEN misch erzeugten Objekten nicht so gut geeignet wie Groove. Diese Tatsache war ein Grund fu¨r 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 verhindern. Das bedeutet, wenn das System aus zu vielen Zusta¨nden besteht, ist das Model Checking nicht mehr mo¨glich. Zwar unterstu¨tzen CheckVML und Groove verschiedene Optimierungstechniken, es ist jedoch trotzdem nicht mo¨glich, Systeme mit mehr als 700.000 Zusta¨nden mittels CheckVML und 500.000 Zusta¨nden mittels Groove zu verifizieren[RSV04]. Um u¨berhaupt ein Model Checking durchfu¨hren zu ko¨nnen, wird von allen vorgestellten Ansa¨tzen/Werkzeugen ein Initialgraph beno¨tigt. Da fu¨r mechatronische Systeme nicht garantiert werden kann, dass diese einen endlichen Zustandsraum besitzen und der Initialgraph zum Verifikationszeitpunkt noch nicht bekannt sein muss, sind Ansa¨tze zum Model Checking von Graphtransformationssystemen in dieser Doma¨ne nur begrenzt einsetzbar. Gegen die Verwendung des OBGG-Ansatzes spricht zudem die starke Einschra¨nkung der Regeln. Kompositionale Verifikation Um Graphtransformationssysteme mit großem, aber endlichem Zustandsraum verifizieren zu ko¨nnen, schla¨gt Heckel in[Hec98] und Heckel, Lajios und Menge in[HLM05] eine kompositionale 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 urspru¨nglichen Anfangszustand entspricht, aber auf die in der Sicht zula¨ssigen Typen eingeschra¨nkt ist. Ebenso entsprechen die Regeln der Sicht den Regeln des Gesamtsystems, werden aber auf die Typen der Sicht eingeschra¨nkt. 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 fu¨r eine Sicht nachgewiesen wurden, auch im Gesamtsystem gelten. Damit die Dekomposition Auswirkungen auf die Verifikation hat, muss sie so gewa¨hlt werden, dass die Anwendung einer Regel nur in mo¨glichst wenigen Sichten Auswirkungen hat. Die Dekomposition muss manuell vom Entwickler durchgefu¨hrt werden. Ist die Dekomposition erfolgt, so kann die Verifikation erfolgen. Dabei wird die in[HEWC97] beschriebene Idee verwendet, um jede der Sichten unabha¨ngig von allen anderen Sichten zu verifizieren. Mittels eines solchen kompositionalen Vorgehens lassen sich auch Systeme mit gro¨ßerem Zustandsraum verifizieren. Allerdings muss die Dekomposition in Sichten manuell durch den Entwickler erfolgen, was fehleranfa¨llig ist. Bei der Verifikation der Story Patterns ist eine solche manuelle Dekomposition in Teilsysteme, die voneinander unabha¨ngig verifiziert werden ko¨nnen, nicht notwendig. Sie ergibt sich aus der Verwendung der Kulturhierarchien. Wurden die Sichten gut gewa¨hlt, ermo¨glicht der Ansatz zwar die Verifikation von Graphtransformationssystemen mit einem großen Zustandsraum, die mit einem nicht-kompositionalen Vorgehen nicht verifiziert werden ko¨nnen, 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 fu¨r ein Graphtransformationssystem nachzuweisen. Baldan, Corradini und Ko¨nig[BCK01, BK02, BCK, BCK04] sowie Padberg und Enders[PE02] verwenden dagegen Petrinetztechniken zur Analyse von Graphtransformationssystemen. Da die Anwendung beider Ansa¨tze starken Restriktionen unterliegen, die in mechatronischen Systemen im Allgemeinen nicht erfu¨llt werden und es fu¨r beide Ansa¨tze keine Werkzeugunterstu¨tzung gibt, sollen die beiden Ansa¨tze hier nur kurz skizziert werden. In beiden Ansa¨tzen erfolgt die Regelanwendung im Double Pushout Ansatz, wobei die Regeln keine negativen Anwendungsbedingungen besitzen du¨rfen. Zudem beno¨tigen beide Ansa¨tze einen Initialgraphen, um die Analyse durchfu¨hren zu ko¨nnen. 6.3.1 Approximierte Entfaltung Das Ziel von Baldan, Corradini und Ko¨nig[BCK01, BK02, BCK, BCK04] besteht darin, Graphtransformationssysteme mittels existierender Techniken zu verifizieren. Dazu werden die Graphtransformationssysteme, auch solche mit unendlichem Zustandsraum, durch eine approximierte Entfaltung(engl. apporixmated unfolding) auf eine endliche Struktur, die so genannten Petrigraphen, abgebildet. Ein Petrigraph besteht aus einem Petrinetz und einem Graphen. Die Transitionen des Petrinetzes entsprechen den Regelanwendungen des urspru¨nglichen Graphtransformationssystems. Jeder Graph, der durch das Graphtransformationssystem erzeugt werden kann, entspricht einer erreichbaren Markierung des Petrinetzes, sodass zur Verifikation des Systems existierende Petrinetztechniken verwendet werden ko¨nnen. Durch die approximierte Entfaltung entsteht ein Petrigraph, der aus einem Graphen und einem 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 einer erreichbaren Markierung im Petrinetzes des Petrigraphen entspricht. Deshalb gilt, dass jede Eigenschaft, die im Graphtransformationssystem erfu¨llt ist, auch im Petrigraphen erfu¨llt ist. Bei der Verifikation auf dem Graphen ko¨nnen Erreichbarkeitsanalysen durchgefu¨hrt und Verklemmungen erkannt werden. Die Analyse des Petrinetzes ermo¨glicht zudem den Nachweis von Lebendigkeitseigenschaften und Transitionsinvarianten. Dieser Ansatz ist jedoch fu¨r die Analyse von mechatronischen Systeme nicht geeignet, da er starken Restriktionen unterliegt. Zu den bereits zu Beginn dieses Abschnitts genannten Einschra¨nkungen kommt, dass durch die Regeln nur Kanten gelo¨scht werden du¨rfen. Knoten du¨rfen dagegen nur neu erzeugt werden. Diese Restriktion wird in einem mechatronischen System im Allgemeinen nicht erfu¨llt. 6.3.2 Regelinvarianten in Graphtransformationssystemen Das Ziel von Padberg und Enders[PE02] besteht darin, Petrinetzanalysetechniken auf Graphtransformationssysteme zu u¨bertragen.

138 KAPITEL 6. VERWANDTE ARBEITEN Die Autoren u¨bertragen die Begriffe Markierung(engl. marking), Schalten von Transitionen(engl. firing), Erreichbarkeit von Markierungen(engl reachable), Lebendigkeit des Netzes (engl. liveness), Beschra¨nkung(engl. bounded) und vorallem Transitionsinvarianten. Die ersten fu¨nf Begriffe ko¨nnen direkt auf Graphtransformationssysteme u¨bertragen werden, z.B. entspricht ein erreichbarer Graph im Graphtransformationssystem einer erreichbaren Markierung im Petrinetz. Da Graphtransformationssysteme ma¨chtiger sind als Petrinetze, ist eine direkte U¨ bertragung der Transitionsinvarianten auf Regelinvarianten nicht mo¨glich. Eine Transitionsinvariante besagt, dass nach dem Schalten einer beliebigen Sequenz von Transitionen die urspru¨ngliche Markierung wieder erreicht wird. Dementsprechend besagt eine Regelinvariante, dass die Anwendung einer Sequenz von Regeln wieder im urspru¨nglichen Graphen endet. Eine Sequenz von Regeln ist eine Regelinvariante, wenn alle Elemente, die durch die Anwendungen der Regeln gelo¨scht werden, durch die Anwendungen auch wieder erzeugt werden. Um festzustellen, ob dies der Fall ist, werden die Regeln der Sequenz zu einer Regel mit multiplen Pushout zusammengefasst. Gilt dann, dass es einen Isomorphismus gibt, der die linke Seite des multiplen Pushouts L auf die rechte Seite R abbildet, so stellt die Sequenz der Regeln einen Regelinvariante dar. Abgesehen davon, dass der Ansatz zur Analyse einen Startgraphen beno¨tigt und die Regeln keine negativen Anwendungsbedingungen enthalten du¨rfen, ist es nicht mo¨glich, beschriftete bzw. typisierte Graphen zu verwenden. Das Hauptproblem dieses Ansatzes besteht jedoch darin, dass jede mo¨gliche Regelsequenz betrachtet werden muss. Da in einer solchen Sequenz jede Regel beliebig oft auftreten kann, gibt es unendlich viele Mo¨glichkeiten 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 Vorgehensweise erla¨utert, die dazu verwendet werden ko¨nnen, die Korrektheit von Graphtransformationssystemen zu garantieren. Der erste dazu vorgestellte Ansatz modifiziert die Regeln eines Graphtransformationssystems so, dass nur korrekte Zusta¨nde durch die Regelanwendung erzeugt werden ko¨nnen. Allerdings erfolgt eine solche Modifikation auch dann, wenn die Regel schon vorher korrekt war, wodurch die negativen Anwendungsbedingungen der Regeln unno¨tig vergro¨ßert werden. Der darauf aufbauende Ansatz, der eine Regel nur dann vera¨ndert, wenn deren Anwendung zu einem Fehler fu¨hren kann, beno¨tigt einen Startgraphen und schra¨nkt die Ausdruckssta¨rke der Transformationsregeln stark ein. Die u¨brigen Ansa¨tze verifizieren, ob ein gegebenes Graphtransformationssystem korrekt ist. Diese Ansa¨tze beno¨tigen alle einen Startgraphen, um die Verifikation durchfu¨hren zu ko¨nnen. Nur der Ansatz zur approximierten Entfaltung von Baldan, Corradini und Ko¨nig ist zur Verifikation von Graphtransformationssystemen mit unendlichen Zustandsra¨umen geeignet, unterliegt aber anderen Einschra¨nkungen, die eine Anwendung des Ansatzes fu¨r die Verifikation der Software 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 Modellierung 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 zuku¨nftige Arbeiten gegeben werden. 7.1 Zusammenfassung Ein mechatronisches System kann als Operator-Controller-Modul aufgefasst werden, dessen Informationsverarbeitung in die Bereiche Controller, reflektorischer Operator und kognitiver Operator unterteilt ist. Die Software, die zur Informationsverarbeitung im reflektorischen Operator eingesetzt wird, ist fu¨r die Steuerung des Controllers sowie fu¨r die Koordination mit anderen OCMs verantwortlich. Da die Software des reflektorischen Operators sicherheitskritisch ist, bestand das Ziel dieser Arbeit darin, einen Ansatz zur kompositionalen Modellierung und Verifikation der Software zu entwickeln. Der vorgestellte Ansatz baut auf den existierenden Konzepten der M ECHATRONIC UML auf und erweitert diese. In der M ECHATRONIC 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 unabha¨ngig von den anderen Koordinationsmustern und Komponenten verifiziert werden. Im Gegensatz zu den meisten anderen kompositionalen Ansa¨tzen ist es nicht notwendig, zuna¨chst 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: Interagieren mehrere Komponenteninstanzen ausschließlich u¨ber Instanzen der Koordinationsmuster, so ist diese Interaktion sicher. Allerdings sind mechatronische Systeme sehr dynamisch. Daraus folgt, dass bei der Instanzierung einer Komponente nicht bekannt ist, mit welchen anderen Komponenten sie zur Laufzeit interagieren muss. Da in mechatronischen Systemen zudem nur begrenzte Speicher- und Rechenkapazita¨ten vorhanden sind, ist es nicht mo¨glich, zwischen jedem Paar von Komponenteninstanzen alle mo¨glichen Muster zu instanzieren. Stattdessen ist es notwendig, zur Laufzeit die beno¨tigten Koordinationsmuster zu instanzieren und nicht mehr beno¨tigte Instanzen eines Koordinationsmusters wieder zu lo¨schen. Eine Methode, die ein Koordinationsmuster instanziert, kann als Story Pattern modelliert werden. Ein solches Story Pattern wird dann durch das komponenteninterne Real-Time Statechart als entry()-, do()- oder exit()-Methode in einem Zustand aufgerufen oder als Seiteneffekt beim Schalten einer Transition ausgefu¨hrt. Bei der Verifikation der Komponente wird davon ausgegangen, dass die aufgerufenen Methoden korrekt sind, sie werden durch das Model Checking nicht u¨berpru¨ft. 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 Systemzustand vorkommenden Objekten entsprechen und dessen Kanten die Links des Systemzustands darstellen. Ein Story Pattern, das Objekte und Links erzeugt oder lo¨scht, stellt dann eine spezielle Form einer Graphtransformationsregel dar. Sicherheitseigenschaften, die bei der Anwendung einer solchen Regel erhalten bleiben mu¨ssen, werden durch Graphmuster spezifiziert. Eigenschaften, die kritische Situationen oder Unfa¨lle modellieren und niemals auftreten du¨rfen, werden als verbotene Graphmuster beschrieben. Auch diese Graphmuster ko¨nnen durch Story Patterns dargestellt werden. Die meisten der existierenden Ansa¨tze zur Verifikation von Graphtransformationssystemen beno¨tigen zum einen einen initialen Graphen, also einen Anfangszustand des Systems. Zum anderen muss gelten, dass ausgehend vom Initialgraphen nur endlich viele Graphen durch die Anwendung der Regeln erreichbar sind. Da diese Einschra¨nkungen in einem mechatronischen System zumeist jedoch nicht erfu¨llt sind, wurde in dieser Arbeit ein Ansatz vorgestellt, der diesen Einschra¨nkungen 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 ru¨ckwa¨rts gefu¨hrt, d.h. fu¨r einen inkorrekten Graphen wird gepru¨ft, ob dieser das Resultat einer Regelanwendung auf einen korrekten Graphen ist. Fu¨r eine Graphtransformationsregel gilt, dass sie nur Auswirkungen auf Elemente des Anwendungsgraphen 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 fu¨hren, d.h. einen Graphen erzeugen, der ein verbotenes Graphmuster entha¨lt. Zum einen, wenn sie ein Element erzeugt, sodass die Anwendungsbedingung des verbotenen Graphmusters erfu¨llt ist, die negative Anwendungsbedingung jedoch nicht. Zum anderen, wenn sie ein Element der negativen Anwendungsbedingung lo¨scht.

7.2. AUSBLICK 141 Diese Fakten ko¨nnen beim Nachweis induktiver Invarianten ausgenutzt werden. Statt vollsta¨ndige 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 repra¨sentiert die Menge aller Graphen, auf die die rechte Regelseite und das verbotene Graphmuster abgebildet werden ko¨nnen. Da das Ergebnisgraphmuster ein verbotenes Graphmuster entha¨lt, beschreibt es eine Menge von inkorrekten Graphen. Zudem entha¨lt das Ergebnisgraphmuster die rechte Regelseite, sodass eine Ru¨ckwa¨rtsanwendung der entsprechenden Regel auf das Ergebnisgraphmuster mo¨glich ist. Wird die Regel ru¨ckwa¨rts auf das Ergebnisgraphmuster angewendet, so resultiert das Startgraphmuster. Entha¨lt 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 u¨berfu¨hrt werden kann, der das Ergebnisgraphmuster entha¨lt und somit inkorrekt ist. Das Verfahren kann auch fu¨r Systeme mit unendlich großem Zustandsraum angewendet werden. Daru¨ber hinaus wird zur Verifikation kein Initialgraph beno¨tigt. In einer Aufwandsabscha¨tzung wurde gezeigt, dass der Ansatz linear in der Anzahl der Regeln und verbotenen Graphmuster, aber exponentiell in der Gro¨ße der Graphen der Regel und verbotenen Graphmuster ist. Das Verfahren wurde als Plugin in der Fujaba Real-Time Tool Suite prototypisch realisiert. In einer Evaluierung konnte gezeigt werden, dass das Verfahren trotz seiner Komplexita¨t 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 Verifikationsprozess abgeschlossen. Eine Verifikation des gesamten Modells ist nicht notwendig und meistens auf Grund der Gro¨ße des Modells auch nicht mo¨glich. Die vorgestellten Modellierungsund 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 spa¨ter im mechatronischen System wirklich ausgefu¨hrt wird, die verifizierten Sicherheitseigenschaften erfu¨llt, muss er automatisch generiert werden. Da zur Modellierung nur Diagrammarten verwendet werden, fu¨r die auch eine formale Semantik definiert wurde, ist eine solche automatische Codegenerierung mo¨glich. 7.2 Ausblick Im Fachgebiet Softwaretechnik laufen zurzeit verschiedene Arbeiten, in denen die M ECHATRO 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(siehe dazu auch[Bur05]). In diesem Abschnitt soll genauer auf die Erweiterungsmo¨glichkeiten des Ansatzes zum automatischen Nachweis induktiver Invarianten eingegangen werden. Dieser Ansatz wurde dazu entwickelt, um die Methoden, die durch Story Patterns beschrieben und in einem mechatronischen System ausgefu¨hrt werden, verifizieren zu ko¨nnen. Die

142 KAPITEL 7. ZUSAMMENFASSUNG UND AUSBLICK Ausfu¨hrung einer solchen Methode, d.h. die Anwendung eines Story Patterns auf eine Instanzsituation fu¨hrt dazu, dass neue Objekte und Links erzeugt oder existierende Objekte und Links gelo¨scht werden. Ein wichtiges Konzept der objektorientierten Modellierung, das zwar durch die Story Patterns, nicht aber durch den vorgestellten Verifikationsansatz, unterstu¨tzt wird, ist die Vererbung. Um auch Story Patterns verifizieren zu ko¨nnen, in denen Vererbung verwendet wurde, ist eine Erweiterung des Ansatzes notwendig. Neben der Vererbung unterstu¨tzen 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 ihrer mo¨glichen Verbindungen zu spezifizieren, ko¨nnen Kardinalita¨ten spezifiziert werden. Diese geben fu¨r ein Objekt an, wieviele andere Objekte von einem bestimmten Typ adjazent zu ihm sein ko¨nnen. Um diese Kardinalita¨ten bei der Verifikation beru¨cksichtigen zu ko¨nnen, mu¨ssen zusa¨tzliche verbotene Graphmuster angegeben werden. Dies ist zwar prinzipiell mo¨glich, hat sich jedoch bei der Evaluierung des Ansatzes in der Fujaba Real-Time Tool Suite als eine sehr la¨stige Arbeit herausgestellt. Deshalb sollte der Ansatz so erweitert werden, dass die Kardinalita¨ten bei der Verifikation beru¨cksichtigt werden ohne das explizit zusa¨tzliche verbotene Graphmuster spezifiziert werden mu¨ssen. Die Story Patterns werden dazu verwendet, um Methoden eines mechatronischen Systems zu spezifizieren. Zurzeit ist es unter bestimmten Umsta¨nden mo¨glich, mit dem Ansatz von Seibel [Sei05] festzustellen, wie lange diese Ausfu¨hrung maximal dauert. Eine explizite Modellierung und Verifikation von Zeit und Zeiteigenschaften wird momentan jedoch nicht von den Story Patterns unterstu¨tzt 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 Modellierung und die Verifikation der Story Patterns aufgenommen werden. Story Patterns stehen meist nicht allein, sondern beschreiben eine Aktivita¨t eines Story Diagramms. Wird ein Story Diagramm auf eine Instanzsituation angewendet, so wird zuna¨chst das Story Pattern der Startaktivita¨t angewendet. Dann das Story Pattern der na¨chsten Aktivita¨t und so weiter, bis das Story Pattern der Stopaktivita¨t angewendet wurde. Eine Sicherheitseigenschaft ist eine induktive Invariante eines Systems, wenn ein Story Diagramm angewendet auf eine korrekte Instanzsituation wieder in einer korrekten Instanzsituation resultiert. Die Instanzsituationen nach dem Anwenden des Story Patterns der Startaktivita¨t und vor der Anwendung der Stopaktivita¨t mu¨ssen die Sicherheitseigenschaft nicht erfu¨llen. Der in Kapitel 3 vorgestellte Ansatz ist zur Verifikation solcher Story Diagramme im Allgemeinen aufgrund seiner Komplexita¨t nicht anwendbar. Fu¨r sehr einfache Story Diagramme mit relativ kleinen Story Patterns sollte eine Anwendung des Ansatzes jedoch mo¨glich sein. Alle bisher vorgestellten Erweiterungsmo¨glichkeiten fu¨hren dazu, dass die Komplexita¨t des Ansatzes weiter steigt. Um diese Komplexita¨t in den Griff zu bekommen, reichen die Mittel, die bisher im Plugin zum automatischen Nachweis induktiver Invarianten eingesetzt werden, jedoch nicht aus. Eine Mo¨glichkeit, die Verifikation trotz der erho¨hten Komplexita¨t durchfu¨hren zu ko¨nnen, besteht darin, das Verifikationsproblem auf ein Constraint-Solving-Problem abzubilden. Zum Lo¨sen des Problems kann dann ein existierender Constraint-Solver(z.B. ILOG

7.2. AUSBLICK 143 Solver 1 ) verwendet werden. Zudem wurde in[GSK + 06] eine Idee skizziert, wie man das Problem symbolisch kodieren und dadurch den Verifikationsaufwand verringern kann. Dazu werden die Ergebnisgraphmuster in Mengen zusammengefasst. Die Bildung dieser Mengen sowie die Ru¨ckwa¨rtsanwendung der Regeln und der Test, ob die resultierenden Startgraphmuster korrekt sind, erfolgt mittels des BDD-basierten Interpreters CroCoPat[BNL05]. Eine weitere Mo¨glichkeit, der Komplexita¨t entgegenzuwirken, besteht darin, die Kompositionalita¨t der Modellierung bei der Verifikation sta¨rker auszunutzen. So wurden in Abschnitt 2.3.2 die Kulturhierarchien eingefu¨hrt, um mechatronische Systeme kompositional modellieren und verifizieren zu ko¨nnen. 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 u¨bergeordneten Kulturen beru¨cksichtigt werden. Untergeordnete Kulturen oder Kulturen, die in anderen Zweigen der Hierarchie angeordnet sind brauchen nicht beru¨cksichtigt werden. Es ist jedoch vorstellbar, dass Verifikationsergebnisse aus ho¨heren Hierarchien bei der Verifikation untergeordneter Kulturen ausgenutzt werden ko¨nnen. Beispielsweise haben die Verhaltensregeln einer ho¨heren Hierarchieebene eine geringere Priorita¨t als die einer untergeordneten Ebene. Die Instanzierungs- und Verhaltensregeln erfu¨llen die Sicherheitseigenschaften ihrer Hierarchieebene und aller ho¨heren Ebenen. Da die Verhaltensregeln der ho¨heren Ebenen nur anwendbar sind, wenn keine Regel der aktuell betrachteten Kultur anwendbar ist, sollten sie auch deren Sicherheitseigenschaften nicht verletzen ko¨nnen. Neben der Erweiterung, die es ermo¨glicht, noch ausdrucksta¨rkere Story Patterns zu verifizieren, besteht auch die Mo¨glichkeit 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 u¨berpru¨fen. Wird bei dieser U¨ berpru¨fung fu¨r eine Regel ein Gegenbeispiel generiert, das zeigt, dass die Regel inkorrekt 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, ermo¨glicht auch seine Anwendung in anderen Kontexten. Beispielsweise ist es dann mo¨glich, die von Tichy et al.[TSG04, TGSP05, TG05] vorgestellten Regeln zur Selbstadaption und zur Selbstreparatur zu verifizieren. Auf diese Weise ko¨nnte nicht nur die Sicherheit eines Systems erho¨ht werden, sondern auch seine Verla¨sslichkeit(engl. reliability). Außerdem ist es dann mo¨glich, die Konsistenzbedingungen der von Gehrke in[Geh05] aufgestellten Regeln zur Modelltransformation zu verifizieren. 1 www.ilog.com

144 KAPITEL 7. ZUSAMMENFASSUNG UND AUSBLICK

Literaturverzeichnis [ACD90] A LUR , R.; C OURCOUBETIS , C.; D ILL , 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] A LUR , Rajeev; D ILL , 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] A LUR , Rajeev; D ILL , David L.: A theory of timed automata. In: Theoretical Computer Science 126(1994), Nr. 2, S. 183­235 [BCK] B ALDAN , Paolo; C ORRADINI , Andrea; K O ¨ NIG , 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] B ALDAN , Paolo; C ORRADINI , Andrea; K O ¨ NIG , Barbara: A Static Analysis Technique for Graph Transformation Systems. In: K.G.L ARSEN (Hrsg.); M.N IELSEN (Hrsg.): Proceedings of the 12th International Conference on Concurrency Theory(CONCUR 2001), Aalborg, Denmark Bd. 2154, Springer-Verlag Heidelberg, 2001, S. 381­395 [BCK04] B ALDAN , Paolo; C ORRADINI , Andrea; K O ¨ NIG , Barbara: Verifying Finite-State Graph Grammars: An Unfolding-Based Approach. In: G ARDNER , Philippa(Hrsg.); Y OSHIDA , Nobuko(Hrsg.): Proceedings of the 15th International Conference on Concurrency Theory(CONCUR 2004), London, UK Bd. 3170, Springer-Verlag Heidelberg, 2004, S. 83­98 [Bec05] B ECKER , Basil: Automatische U¨ berpru¨fung Induktiver Invarianten fu¨r Graphtransformationssysteme. Paderborn, Deutschland, Universita¨t Paderborn, Studienarbeit, 2005 [BG03] B URMESTER , Sven; G IESE , Holger: The Fujaba Real-Time Statechart PlugIn. In: G IESE , Holger(Hrsg.); Z U ¨ NDORF , Albert(Hrsg.): Proceedings of the 1st International Fujaba Days 2003, Kassel, Deutschland Bd. tr-ri-04-247, Universita¨t Paderborn, 2003, S. 1­8 [BGH + 05] B URMESTER , Sven; G IESE , Holger; H IRSCH , Martin; S CHILLING , Daniela; T ICHY , Matthias: The Fujaba Real-Time Tool Suite: Model-Driven Development of Safety-Critical, RealTime Systems. In: Proceedings of the 27th International Conference on Software Engineering(ICSE 2005), St. Louis, Missouri, USA, ACM Press, 2005, S. 670 ­ 671 145

146 LITERATURVERZEICHNIS [BGHS04] B URMESTER , Sven; G IESE , Holger; H IRSCH , Martin; S CHILLING , 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] B URMESTER , Sven; G IESE , Holger; O BERSCHELP , Oliver: Hybrid UML Components for the Design of Complex Self-optimizing Mechatronic Systems. In: A RAUJO , Helder(Hrsg.); V IEIRA , Alves(Hrsg.); B RAZ , Jose(Hrsg.); E NCARNACAO , Bruno(Hrsg.); C ARVALHO , Marina(Hrsg.): Proceedings of 1st International Conference on Informatics in Control, Automation and Robotics(ICINCO 2004), Setubal, Portugal, INSTICC Press, 2004, S. 222­229 [BGS05a] B ECKER , Basil; G IESE , Holger; S CHILLING , 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, Universita¨t Paderborn, 2005, S. 45 ­ 48 [BGS05b] B URMESTER , Sven; G IESE , Holger; S CHA ¨ FER , 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), Nu¨rnberg, Deutschland, Springer Verlag, 2005(Lecture Notes in Computer Science(LNCS)), S. 1­15 [BGT05] B URMESTER , Sven; G IESE , Holger; T ICHY , Matthias: Model-Driven Development of Reconfigurable Mechatronic Systems with Mechatronic UML. In: A SSMANN , Uwe(Hrsg.); R ENSINK , Arend(Hrsg.); A KSIT , Mehmet(Hrsg.): Model Driven Architecture: Foundations and Applications Bd. 3599, Springer-Verlag Heidelberg, 2005, S. 47 ­ 61 [BK02] B ALDAN , Paolo; K O ¨ NIG , Barbara: Approximating the Behaviour of Graph Transformation Systems. In: C ORRADINI , A.(Hrsg.); E HRIG , H.(Hrsg.); K REOWSKI , H.-J.(Hrsg.); R OZENBERG , G.(Hrsg.): Proceedings of the 1st International Conference on Graph Transformation(ICGT 2002), Barcelona, Spanien Bd. 2505, Springer-Verlag Heidelberg, 2002, S. 14­29 [BNL05] B EYER , Dirk; N OACK , Andreas; L EWERENTZ , Claus: Efficient Rational Calculation for Software Analysis. In: IEEE Transactions on Software Engineering 31(2005), Nr. 2, S. 137­149 [BTG04] B URMESTER , Sven; T ICHY , Matthias; G IESE , Holger: Modeling Reconfigurable Mechatronic Systems with Mechatronic UML. In: A SSMANN , U.(Hrsg.): Proceedings of Model Driven Architecture: Foundations and Applications(MDAFA 2004), Linko¨ping, Sweden, 2004, S. 155 ­ 169 [Bur02] B URMESTER , Sven: Generierung von Java Real-Time Code fu¨r zeitbehaftete UML Modelle, Universita¨t Paderborn, Paderborn, Deutschland, Diplomarbeit, 2002 [Bur05] B URMESTER , Sven: Model-Driven Engineering of Reconfigurable Mechatronic Systems(erscheint). Paderborn, Deutschland, Universita¨t Paderborn, Dissertation, 2005

LITERATURVERZEICHNIS 147 [CGP02] C LARK , Edmund M.; G RUMBERG , Orna; P ELED , Doron A.: Model Checking. 4. MIT Press, 2002 [Cha03] C HARPENTIER , Michel: Composing Invariants. In: A RAKI , Keijiro(Hrsg.); G NESI , Stefania (Hrsg.); M ANDRIOLI , 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] D OTTI , Fernando L.; F OSS , Luciana; R IBEIRO , Leila; S ANTOS , Osmar M.: Verification of Distributed Object-Oriented Systems. In: N AJM , Elie(Hrsg.); N ESTMANN , Uwe(Hrsg.); S TEVENS , Perdita(Hrsg.): Proceedings of the 6th Internation Conference on Formal Methods for Open Object-Based Distributed Systems(FMOODS 2003), Paris, Frankreich Bd. 2884, Springer-Verlag Heidelberg, 2003, S. 261 ­ 275 [FNT98] F ISCHER , Thorsten; N IERE , Jo¨rg; T ORUNSKI , Lars: Konzeption und Realisierung einer integrierten Entwicklungsumgebung fu¨r UML, Java und Story-Driven-Modeling. Paderborn, Deutschland, Univerisity of Paderborn, Diplomarbeit, 1998 [FNTZ98] F ISCHER , Thorsten; N IERE , Jo¨rg; T ORUNSKI , Lars; Z U ¨ NDORF , Albert: Story Diagrams: A new Graph Rewrite Language based on the Unified Modeling Language. In: E NGELS , Gregor (Hrsg.); R OZENBERG , 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] G IESE , Holger; B URMESTER , Sven: Real-Time Statechart Semantics/ Universita¨t Paderborn. Paderborn, Deutschland, 2003(tr-ri-03-239). ­ Forschungsbericht [GBK + 03] G IESE , Holger; B URMESTER , Sven; K LEIN , Florian; S CHILLING , Daniela; T ICHY , Matthias: Multi-Agent System Design for Safety-Critical Self-Optimizing Mechatronic Systems with UML. In: H ENDERSON -S ELLERS , B.(Hrsg.); D EBENHAM , J.(Hrsg.): 2nd International 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] G IESE , Holger; B URMESTER , Sven; S CHA ¨ FER , Wilhelm; O BERSCHELP , Oliver: Modular Design and Verification of Component-Based Mechatronic Systems with OnlineReconfiguration. In: Proceedings of 12th ACM SIGSOFT Foundations of Software Engineering 2004(FSE 2004), Newport Beach, USA, ACM Press, 2004, S. 179­188 [Ge05] G AUSEMEIER , Ju¨rgen; ET AL .: Sonderforschungsbereich 614- Selbstoptimierende Systeme des Maschinenbaus, 2. Fo¨rderperiode, Finanzierungsantrag. Bd. 1. Universita¨t Paderborn, 2005 [Geh05] G EHRKE , Matthias: Entwurf mechatronischer Systeme auf Basis von Funktionshierarchien und Systemstrukturen(erscheint), Universita¨t Paderborn, Dissertation, 2005 [Gei02] G EIGER , Leif: Design Level Debugging mit Fujaba, Technische Universita¨t Braunschweig, Studienarbeit, 2002

148 LITERATURVERZEICHNIS [Gie03] G IESE , Holger: A Formal Calculus for the Compositional Pattern-Based Design of Correct Real-Time Systems/ Universita¨t Paderborn. Paderborn, Deutschland, 2003(tr-ri-03-240). ­ Forschungsbericht [GS04] G IESE , Holger; S CHILLING , Daniela: Towards the Automatic Verification of Inductive Invariants for Invinite State UML Models/ Universita¨t Paderborn. Paderborn, Deutschland, 2004 (tr-ri-04-252). ­ Forschungsbericht [GSK + 06] G IESE , Holger; S CHILLING , Daniela; K LEIN , Florian; B ECKER , Basil; B EYER , Dirk: Symbolic 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] G IESE , Holger; S CHILLING , Daniela; T ICHY , Matthias; B URMESTER , Sven; S CHA ¨ FER , Wilhelm; F LAKE , Stephan: Towards the Compositional Verification of Real-Time UML Designs / Universita¨t Paderborn. Paderborn, Deutschland, 2003(tr-ri-03-241). ­ Forschungsbericht. ­ 1­47 S [GTB + 03] G IESE , Holger; T ICHY , Matthias; B URMESTER , Sven; S CHA ¨ FER , Wilhelm; F LAKE , Stephan: 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] H ECKEL , Reiko; E NGELS , Gregor: Graph Transformation and Visual Modeling Languages. In: Bulletin of the European Association for Theoretical Computer Science(EATACS)(2000), Nr. 71 [Hec98] H ECKEL , Reiko: Compositional Verification of Reactive Systems Specified by Graph Transformation. In: A STESIANO , Egidio(Hrsg.): Proceedings of the 1st International Conference on Fundamental Approaches to Software Engineering(FASE 1998), Held as Part of the European Joint Conferences on the Theory and Practice of Software(ETAPS 1998), Lisabon, Protugal Bd. 1382, Springer-Verlag Heidelberg, 1998, S. 138­153 [HEWC97] H ECKEL , Reiko; E HRIG , Hartmut; W OLTER , Uwe; C ORRADINI , 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] H IRSCH , Martin; G IESE , Holger: Towards the Incremental Model Checking of Complex RealTime UML Models. In: G IESE , Holger(Hrsg.); Z U ¨ NDORF , Albert(Hrsg.): Proceedings of the 1st International Fujaba Days 2003, 13.-14.October, Kassel, Deutschland Bd. tr-ri-04247, Universita¨t Paderborn, 2003 [HHT96] H ABEL , Annegret; H ECKEL , Reiko; T AENTZER , Gabriele: Graph Grammars with Negative Application Conditions. In: Fundamenta Informatikae 26(1996), Nr. 3- 4, S. 287 ­ 313 [Hir04] H IRSCH , Martin: Effizientes Model Checking von UML-RT Modellen und Realtime Statecharts mit UPPAAL, Universita¨t Paderborn, Diplomarbeit, 2004

LITERATURVERZEICHNIS 149 [HLM05] H ECKEL , Reiko; L AJIOS , Georgios; M ENGE , Sebastian: Modulare Analyse Stochastischer Graphtransformationssysteme. In: Software Engineering Bd. 64, Gesellschaft fu¨r Informatik, 2005, S. 141­152 [HOG04] H ESTERMEYER , Thorsten; O BERSCHELP , Oliver; G IESE , Holger: Structured Information Processing For Self-optimizing Mechatronic Systems. In: A RAUJO , Helder(Hrsg.); V IEI RA , Alves(Hrsg.); B RAZ , Jose(Hrsg.); E NCARNACAO , Bruno(Hrsg.); C AVALHO , Marina (Hrsg.): Proceeings of the 1st International Conference on Informatics in Control, Automation and Robotics(ICINCO 2004), Setubal, Portugal, INSTICC Pess, 2004, S. 230­237 [Hol03] H OLZMAN , Gerard J.: The SPIN Model Checker: Primer and Reference Manual. Addision Wesley Professional, 2003 [HW95] H ECKEL , Reiko; W AGNER , Annika: Ensuring consistency of conditional graph rewriting- a constructive approach. In: C ORRADINI , Andrea(Hrsg.); M ONTANARI , Ugo(Hrsg.): Proceedings of Joint Computergraph/Semagraph Workshop on Graph Rewriting and Computation (SEGRAGRA 1995), Volterra, Italien Bd. 2, Elsevier, 1995 [KG04] K LEIN , Florian; G IESE , Holger: Advanced separation of concerns for mechatronic multiagent 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] K LEIN , Florian; G IESE , Holger: Separation of concerns for mechatronic multi-agent systems through dynamic communities. In: C HOREN , Ricardo(Hrsg.); G ARCIA , Alessandro (Hrsg.); L UCENA , Carlos(Hrsg.); R OMANOVSKY , Alexander(Hrsg.): Software Engineering for Multi-Agent Systems III: Research Issues and Practical Applications Bd. 3390. Springer Verlag, 2005, S. 272­289 [Kin95] K INDLER , Ekkart: Invariants, composition, and substitution. In: Acta Informatika 32(1995), S. 299 ­ 312 [KMPP02] K OCH , Manuel; M ANCINI , Luigi V.; P ARISI -P RESICCE , Francesco: Decidability of Safety in Graph-Based Models for Access Control. In: G OLLMANN , D.(Hrsg.); K ARJOTH , G. (Hrsg.); W AIDNER , M.(Hrsg.): Proceedings of the 7th European Symposium on Research in Computer Security(ESORICS 2002), 14.-16.Oktober, Zu¨rich, Schweiz Bd. 2502, SpringerVerlag Heidelberg, 2002, S. 229 ­ 243 [KPP03] K OCH , Manuel; P ARISI -P RESICCE , Francesco: UML Specificationd Access Control Policies and their Formal Verification/ George Mason University. Fairfax, USA, 2003(ISE-TR-0310). ­ Forschungsbericht [LPY97] L ARSEN , K.; P ETTERSSON , P.; Y I , W.: UPPAAL in a Nutshell. In: Springer International Journal of Software Tools for Technology 1(1997), Nr. 1 [Mat01] M ATZ , Michael: Konzeption und Implementierung eines Verfahren zum Nachweis der Konsistenz in einer attributierten Graphgrammatik, Technische Universita¨t Berlin, Diplomarbeit, 2001

150 LITERATURVERZEICHNIS [NNWZ00] N ICKEL , Ulrich A.; N IERE , Jo¨rg; W ADSACK , Jo¨rg P.; Z U ¨ NDORF , Albert: Roundtrip Engineering with FUJABA. In: E BERT , J.(Hrsg.); K ULLBACH , B.(Hrsg.); L EHNER , F.(Hrsg.): Proceedings of the 2nd Workshop on Software-Reengineering(WSR00), Bad Honnef, Germany, Fachberichte Informatik, Universita¨t Koblenz-Landau, 2000 [NNZ00] N ICKEL , Ulrich A.; N IERE , Jo¨rg; Z U ¨ NDORF , 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] O BERSCHELP , Oliver; H ESTERMEYER , Thorsten; G IESE , Holger: Strukturierte Informationsverarbeitung fu¨r selbstoptimierende mechatronische Systeme. In: G AUSEMEIER , Ju¨rgen (Hrsg.); W ALLASCHECK , Ju¨rgen(Hrsg.): Proceedings of the 2nd Paderborner Workshop Intelligente Mechatronische Systeme, Paderborn, Deutschland Bd. 145, 2004, S. 43­56 [PE02] P ADBERG , Julia; E NDERS , Bettina E.: Rule Invariants in Graph Transformation Systems for Analyzing Safety-Critical Systems. In: C ORRADINI , Andrea(Hrsg.); E HRIG , Hartmut (Hrsg.); K REOWSKI , Hans-Jo¨rg(Hrsg.); R OZENBERG , 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] R ENSINK , Arend: Towerds[sic] Model Checking Graph Grammars. In: L EUSCHEL , M. (Hrsg.); G RUNER , S.(Hrsg.); P RESTI , 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] R ENSINK , Arend: The GROOVE Simulator: A Tool for State Space Generation. In: P FALZ , John(Hrsg.); N AGL , Manfred(Hrsg.); B O ¨ HLEN , Boris(Hrsg.): Proceedings of the 2nd Workshop on Applications of Graph Transformations with Industrial Relevance(AGTIVE 2004), Charlottesville, USA Bd. 3062, Springer-Verlag Heidelberg, 2004, S. 479­485 [Roz97] [RSV04] R OZENBERG , Grzegorz: Handbook of Graph Grammars and Computing by Graph Transformation. Bd. 1. Foundations. World Science Publishing Co. Pte. Ltd., 1997 R ENSINK , Arend; S CHMIDT , A´ kos; V ARRO ´ , Da´niel: Model Checking Graph Transformations: A Comparison of Two Approaches. In: E HRIG , Hartmut(Hrsg.); E NGELS , Gregor (Hrsg.); P ARISI -P RESICCE , Francesco(Hrsg.); R OZENBERG , Grzegorz(Hrsg.): Proceedings of the 2nd International Conference on Graph Transformations(ICGT 2004), Rom, Italien Bd. 3256, Springer-Verlag Heidelberg, 2004, S. 226 ­ 241 [Ruf01] R UF , Ju¨rgen: RAVEN: Real-Time Analyzing and Verification Environment. In: Journal on Universal Computer Science(J.UCS), Springer 7(2001), Nr. 1, S. 89 ­ 104 [Sei05] S EIBEL , Andreas: Story Diagramme fu¨r eingebettete Echtzeitsysteme, Universita¨t Paderborn, Studienarbeit, 2005 [Ste05] S TECKER , Alexander: Model Checking von Real-Time Statecharts mit RAVEN. Paderborn, Deutschland, Universita¨t Paderborn, Studienarbeit, 2005 [Sto96] S TOREY , Neil R.: Safety Critical Computer Systems. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1996

LITERATURVERZEICHNIS 151 [SV03] S CHMIDT , A´ kos; V ARRO ´ , Da´niel: CheckVML: A Tool for Model Checking Visual Modeling Languages. In: S TEVENS , Perdita(Hrsg.); W HITTLE , Jon(Hrsg.); B OOCH , 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] S ZYPERSKI , Clemens: Component Software- Beyond Object-Oriented Programming. 2. Addison-Wesley, 2002 [TG05] T ICHY , Matthias; G IESE , 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 Computing(VL/HCC 2005), Dallas, USA, 2005, S. 67 ­ 74 [TGSP05] T ICHY , Matthias; G IESE , Holger; S CHILLING , Daniela; P AULS , Wladimir: Computing Optimal Self-Repair Actions: Damage Minimization versus Repair Time. In: L EMOS , Roge´rio de(Hrsg.); R OMANOVSKY , Alexander(Hrsg.): Proceedings of the Workshop on Architecting Dependable Systems(WADS 2005), held at the International Conference on Software Engineering(ICSE 2005),St. Louis, USA, ACM Press, 2005 [TSG04] T ICHY , Matthias; S CHILLING , Daniela; G IESE , Holger: Design of Self-Managing Dependable 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. ­ Forschungsbericht [Var04] V ARRO ´ , Da´niel: Automated Formal Verification of Visual Modeling Languages by Model Checking. In: Software and System Modeling 3(2004), Nr. 2, S. 85­113 [Wen03] W ENDEHALS , Lothar: 10 Steps to Build a Fujaba Plugin. 2003. ­ http://www.se.eecs.unikassel.de/~fujabawiki/index.php/HowTos [Zu¨n01] Z U ¨ NDORF , Albert: Rigorous Object Oriented Software Development with Fujaba. Paderborn, Deutschland, Universita¨t 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 -, ControlledMovement - und CoordinatedMovement -Kultur definiert. Fu¨r die Regeln der Movement -Kultur sowie der CoordinatedMovement -Kultur konnte gezeigt werden, dass sie bezu¨glich der Sicherheitseigenschaften korrekt sind. Die Regeln werden in Abschnitt A.1 erla¨utert. Zusa¨tzlich wird in Abschnitt A.1.3 fu¨r jede Regel deren Priorita¨t und die im Evaluierunsabschnitt(Abschnitt 5.4) eingefu¨hrte Gro¨ße angegeben. Die Sicherheitseigeschaften, die in jeder der drei Kulturen gelten mu¨ssen, werden ebenfalls in diesem Kapitel(in Abschnitt A.2) erla¨utert. Fu¨r die Sicherheitseigenschaften wird auch die jeweilige Gro¨ße angegeben. Der Ansatz aus Kapitel 3 und die entsprechende Implementierung in der Fujaba Real-Time Tool Suite(Abschnitt 5.3) beru¨cksichtigen zurzeit nicht die im Klassendiagramm spezifizierten Kardinalita¨ten. Deshalb werden in Abschnitt A.2.3 verbotene Graphmuster beschrieben, die bei der Verifikation dazu verwendet wurden, die Kardinalita¨ten zu modellieren. Zu jedem dieser Graphmuster wird auch seine Gro¨ße genannt. A.1 Regeln In diesem Abschnitt werden alle Regeln des Shuttle -Beispiels in Form von Story Pattern dargestellt und erla¨utert. Der Abschnitt ist in drei Unterabschnitte gegliedert. Der erste Abschnitt A.1.1 beschreibt die Regeln der Movment -Kultur. Diese entha¨lt die Regeln member , noMember , moveNext , approachSwitch sowie moveSwitch . In Abschnitt A.1.2 werden die Regeln der ControlledMovement -Kultur vorgestellt. Diese Kultur entha¨lt alle Regeln der ihr u¨bergeordneten Movement -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 u¨bergeordneten Movement - und ControlledMovment -Kulturen entha¨lt 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 Story Pattern dargestellt und erla¨utert. Die Verhaltensregeln der Movement -Kultur beschreiben die Grundfunktionalita¨t eines Shuttle s, die Vorwa¨rtsbewegung sowohl auf einer geraden Strecke als auch beim Anna¨hern und Passieren einer Weiche. Mo¨chte ein Shuttle einen Track befahren, der zu einer anderen ControlledArea geho¨rt als der Track , auf dem es sich zur Zeit befindet, so muss es zuna¨chst in die Community der neuen ControlledArea aufgenommen werden. Dazu wird zwischen dem Shuttle und der ControlledArea ein neuer contains -Link erzeugt, falls es diesen noch nicht gibt. Die Zugeho¨rigkeit eines Track s zu einer ControlledArea wird nicht direkt durch Links definiert. Stattdessen entha¨lt jede ControlledArea eine BaseStation . Alle Track s, die von der BaseStation u¨berwacht werden, sind automatisch Teil der ControlledArea . Deshalb ist in der Regel member in Abbildung A.1, die die Aufnahme eines Shuttle s in einer ControlledArea beschreibt, auch das entsprechende BaseStation -Objekt angegeben. Abbildung A.1: Die Regel member Wa¨hrend die member -Regel die Aufnahme eines Shuttle s 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 geho¨rt, sobald es ein Track befa¨hrt, dass nicht von der BaseStation der ControlledArea u¨berwacht wird. Die Regel moveNext (siehe Abbildung A.3) beschreibt die Fahrt eines Shuttle s auf gerader Strecke, d.h. wenn keine Weiche in der Na¨he 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 fu¨hren, dass sich zwei Shuttle s auf einem Track befinden. Da die Regel nicht fu¨r die Weichenfahrt eines Shuttle s anwendbar sein soll, darf der Track auf den das Shuttle rs1 als na¨chstes fahren mo¨chte (dargestellt durch den next -Link) keine Weiche sein, d.h. sie darf nur rt1: Track als Vorga¨nger haben. Dies wird durch das negative Objekt rt5 vom Typ Track dargestellt. Um eine Kollision von zwei Shuttle s zu vermeiden, muss zudem gelten, dass sich auf den beiden Track s rt2 und rt3 , auf die das Shuttle rs1 als na¨chstes und u¨berna¨chstes fahren mo¨chte, 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 erfu¨llt, so kann die Regel angewendet werden und rs 1 weiterfahren. In diesem Fall wird der locatedOn -Link gelo¨scht und ein neuer zwischen dem Shuttle und rt2 erzeugt. Außerdem muss die Angabe, auf welchen Track das Shuttle als na¨chstes und u¨berna¨chstes fahren mo¨chte, aktualisiert werden. Dazu wird der next -Link zwischen dem Shuttle und rt2 gelo¨scht 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 kollidieren, werden zwei weitere Regeln beno¨tigt. Die erste, approachSwitch aus Abbildung A.4, beschreibt, wie sich ein Shuttle einer Weiche na¨hert. Die Weiche wird durch den Track rt3 dargestellt, der mit rt2 und rt5 zwei Vorga¨nger hat. Durch seine beiden next -Links gibt das Shuttle zu verstehen, dass es diese Weiche passieren mo¨chte. Damit dies jedoch sicher geschehen kann, darf sich auf dem na¨chsten Track rt2 , aber auch auf der Weiche selber, kein weiteres Shuttle befinden. Bei einer Weiche ko¨nnen auch Shuttle s vom parallelen Track kommen. Fu¨r eine sichere Weichendurchfahrt darf sich auf diesem parallelen Track ( rt 5 ) kein anderes Shuttle befinden. Ist die Anwendungsbedingung der Regel erfu¨llt, so wird das Shuttle , wie in der moveNext Regel, auf den na¨chsten 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 ko¨nnen, 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 fa¨hrt. Außerdem darf sich auch kein anderes Shuttle auf dem Track befinden, auf den das Shuttle als u¨berna¨chstes fahren mo¨chte( rt4 ). Kann die Regel angewendet werden, so fa¨hrt 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 u¨bernommen, die in der u¨bergeordneten Movement -Kultur definiert sind. Zu diesen fu¨nf Regeln

A.1. REGELN 157 fu¨gt die ControlledMovement -Kultur zwei Instanzierungsregeln hinzu, die Regel createPublication sowie die Regel deletePublication . Diese beiden Regeln sind dafu¨r verantwortlich eine Instanz einen Publication -Koordinationsmusters zwischen einem Shuttle und einer BaseStation zu erzeugen bzw. zu lo¨schen. Die Instanzierung bzw. das Lo¨schen einer solchen Instanz entspricht einer Anmeldung bzw. Abmeldung eines Shuttle s 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 BaseStation anmelden. Ist das Shuttle angemeldet, so sendet die BaseStation Informationen u¨ber alle anderen bei ihr gemeldeten Shuttle s. Auf diese Weise erfahren die Shuttle , welche anderen Shuttle s sich in ihrer Na¨he befinden und ko¨nnen entsprechend fu¨r 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 na¨chstes auf einen Track fahren mo¨chte, der von einer BaseStation u¨berwacht wird, mit dem das Shuttle noch kein Publication -Koordinationsmuster ausfu¨hrt, 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 Verla¨sst das Shuttle eine ControlledArea , so kann es sich bei der entsprechenden BaseStation 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 u¨berwacht, auf dem sich das Shuttle zur Zeit befindet, noch einen Track , auf den das Shuttle als na¨chstes oder u¨berna¨chstes fahren mo¨chte. Dargestellt wird dies durch die negativen monitors Links, die die BaseStation zu den Track s hat, zu denen das Shuttle einen locatedOn -Link oder einen next -Link besitzt. Wird die Anwendungsbedingung der Regel erfu¨ll, so wird die entsprechende Instanz des Publication -Koordinationsmusters gelo¨scht.

158 ANHANG A. DAS SHUTTLE -BEISPIEL Abbildung A.7: Die Regel deletePublication A.1.3 Die Regeln der CoordinatedMovement -Kultur Die CoordinatedMovement -Kultur u¨bernimmt zum einen die fu¨nf Regeln der Movement -Kultur und zum anderen die beiden Regeln der ControlledMovement -Kultur. Zu diesen sieben Regeln fu¨gt sie eine weitere Verhaltensregeln und drei weitere Instanzierungregeln hinzu. In der CoordinatedMovement -Kultur wird das DistanceCoordiantion -Koordinationsmuster eingefu¨hrt, damit zwei Shuttle s einen Konvoi bilden ko¨nnen. Die Konvoibildung erfolgt indem der Abstand zwischen zwei Shuttle s reduziert wird. Die Minimierung des Abstandes der beiden Shuttle s wird dadurch modelliert, dass die beiden Shuttle s nun auf benachbarten Track s fahren du¨ rfen. Die Instanzierung des DistanceCoordination -Musters zwischen zwei Shuttle s erfolgt durch die in Abbildung A.8 gezeigt createDC -Regel. Diese Regel ist anwendbar, wenn zwei Shuttle s hintereinanderherfahren und zwischen den Track s, 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 ausfu¨hrt und dabei die frontRole u¨bernommen hat oder das hintere Shuttle das Muster ausfu¨hrt und dabei bereits die rearRole u¨bernommen hat. In diesem Fall existiert entweder bereits ein DistanceCoordiantion -Muster zwischen den beiden Shuttle s oder zwischen den beiden Shuttle s 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 Shuttle s auf einer normalen Strecke befinden. Um auch die rechtzeitige Instanzierung des Musters an einer Weiche garantieren zu ko¨nnen, wird eine weitere Regel, die Regel createDCSwitch , die in Abbildung A.9 dargestellt ist, beno¨tigt. In dieser Regel stellt der Track rt3 die Weiche dar. Das Shuttle rs2 befindet sich na¨her an der Weiche und hat deshalb das Vorfahrtsrecht vor dem Shuttle rs1 . Das bedeutet, dass rs2 im DistanceCoordination -Muster die Rolle frontRole u¨bernimmt, wa¨hrend rs1 die rearRole u¨bernimmt. Das entsprechende Muster wird jedoch nur instanziert, wenn rs 2 noch in keiner Instanz des DistanceCoordination -Musters als front agiert und rs1 in noch keiner Instanz von DistanceCoordination 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 Shuttle s existiert. Es kann aber auch sein, dass rs1 bereits im Konvoi fa¨hrt und ein anderes Shuttle vor sich hat, in diesem Fall muss sich das vordere Shuttle mit rs2 koordinieren. Eine dritte Mo¨glichkeit besteht darin, dass rs2 schon in einem Konvoi fa¨hrt 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 ausfu¨hren und seine Fahrt fortsetzen. Ist die Anwendungsbedingung der Regel erfu¨llt, so wird eine Instanz des DistanceCoordination -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, ko¨nnen die beiden Shuttle s einen Konvoi bilden. Dazu wird die Regel moveDC (siehe Abbildung A.10) angewendet. Die Bildung des Konvois erfolgt, indem der Abstand zwischen den beiden Shuttle s verringert wird, sodass die beiden Shuttle s sich auf direkt aufeinander folgenden Track s befinden. Ist zwischen den beiden Shuttle s ein Track frei, so wird das hintere der beiden Shuttle s durch moveDC auf diesen Track gesetzt.

160 ANHANG A. DAS SHUTTLE -BEISPIEL Abbildung A.10: Die Regel moveDC Trennen sich die Wege der beiden Shuttle s oder ist das vordere Shuttle schneller als das hintere, so wird der Konvoi aufgelo¨st. In diesem Fall muss auch die Instanz des DistanceCoordination -Musters gelo¨scht werden. Dies ist deshalb erforderlich, da ein Shuttle ho¨chstens u¨ber zwei Instanzen des DistanceCoordination -Musters mit anderen Shuttle s kommunizieren kann; Einmal u¨bernimmt es dabei die rearRole und einmal die frontRole . Wu¨rde eine nicht mehr beno¨tigte Musterinstanz nicht gelo¨scht, so wu¨rde dies dem Shuttle die Mo¨glichkeit nehmen, einen Konvoi mit einem anderen Shuttle zu bilden. Die Regel deleteDC in Abbildung A.11 ist fu¨r das Lo¨schen einer Instanz des DistanceCoordination -Musters zusta¨ndig. Die Regel lo¨scht eine solche Instanz, wenn sich das vordere Shuttle nicht mehr auf einem Track befindet, auf den das hintere Shuttle als na¨chstes oder u¨berna¨chstes fahren mo¨chte. Dies wird dargestellt durch die beiden negativen locatedOn -Links des vorderen Shuttle s. Abbildung A.11: Die Regel deleteDC Priorita¨ten und Gro¨ßen der Regeln Nachdem in den vorangegangenen Abschnitten alle Regeln des Shuttle -Beispiels erla¨utert wurden, werden in diesem Abschnitt ihre Priorita¨ten aufgelistet. Zudem wird fu¨r jede Regel deren Gro¨ße angegeben. Dabei entspricht die Gro¨ß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 gelo¨scht werden(siehe dazu auch Abschnitt 5.4) bzw. negativ sind. Die Priorita¨ten und Gro¨ßen der Regeln werden in Tabelle A.1 aufgefu¨hrt. Regel member noMember moveNext approachSwitch moveSwitch createPublication deletePublication createDC moveDC deleteDC Priorita¨t 10 11 0 1 2 8 9 5 3 7 Gro¨ ße Objekte Links 69 69 89 10 11 9 10 7 10 58 89 8 10 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 Shuttle -Beispiels erla¨utert. Im folgenden Abschnitt A.2.1 sollen nun die Sicherheitseigenschaften erla¨utert werden, die diese Regeln einhalten mu¨ssen. Diese Sicherheitseigenschaften werden durch verbotenen Graphmuster bzw. verbotene Story Patterns modelliert. Neben den fu¨nf Sicherheitseigenschaften werden in Abschnitt A.2.3 weitere acht verbotene Story Patterns gezeigt. Diese werden beno¨tigt, da der Ansatz aus Kapitel 3 und dessen Umsetzung aus Abschnitt 5.3 die im Klassendiagramm gegebenen Kardinalita¨ten nicht beru¨cksichtigt. A.2.1 Sicherheitseigenschaften In den drei Kulturen wurden insgesamt fu¨nf Sicherheitseigenschaften spezifiziert. Davon stellt das verbotene Graphmuster collision der Movement -Kultur einen Unfall dar. Die u¨brigen vier verbotenen Graphmuster stellen kritische Situationen dar. Die verbotenen Graphmuster der Movement -Kultur Die Movement -Kultur entha¨lt 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 Track s so kurz sind, dass nur jeweils ein Shuttle darauf passt, ist ein Unfall eingetreten, wenn sich zwei Shuttle s 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. Fa¨hrt 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 einfa¨hrt ohne in die entsprechende Community aufgenommen zu werden. 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 ControlledArea u¨berwacht 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 u¨bergeordneten Movement -Kultur: collision und notMember . Daru¨ber 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 u¨berwacht, das Publication -Muster auszufu¨hren. Dies ist deshalb kritisch, da das Shuttle dann keine Informationen u¨ber die Positionen der anderen Shuttle s der ControlledArea , zu der die BaseStation geho¨rt, erha¨lt und auch die anderen Shuttle s 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 mu¨ssen alle Sicherheitseigenschaften erfu¨llen, die in den u¨bergeordneten Kulturen, Movement und ControlledMovement , spezifiziert sind. Zusa¨tzlich zu diesen drei Sicherheitseigenschaften gelten in der CoordinatedMovement -Kultur auch noch die beiden Eigenschaften impendingCollision und impendingCollisionSwitch . Beide Sicherheitseigenschaften sind in Form von verbotenen Story Patterns spezifiziert. Das verbotene Story Pattern impendingCollision beschreibt eine kritische Situation. Diese ist eingetreten, wenn zwei Shuttle s hintereinanderherfahren, das vordere Shuttle sich auf dem Track befindet, auf den das hintere als na¨chtes fahren mo¨chte, die beiden Shuttle s das DistanceCoordination -Muster jedoch nicht miteinander ausfu¨hren. DistanceCoordination -Muster miteinander auszufu¨hren. In diesem Fall droht eine Kollision, da die beiden Shuttle s mit sehr geringem Abstand hintereinanderherfahren, das vordere Shuttle jedoch keine Ru¨cksicht auf das hintere nimmt. Wu¨rde das vordere Shuttle plo¨tzlich 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 Shuttle s auf den parallelen Track s direkt vor einer Weiche befinden, jedoch nicht das DistanceCoordination -Muster miteinander ausfu¨hren. Einerseits wu¨rde in diesem Fall die Vorwa¨rtsbewegung eines Shuttle s dazu fu¨hren, dass sich die beiden Shuttle s auf zwei aufeinander folgenden Track s befinden, ohne jedoch das DistanceCoordination -Muster auszufu¨hren, dies wu¨rde dann der kritischen Situation impendingCollision entsprechen. Zum anderen wa¨re in diesem Fall aber auch nicht geregelt, welches Shuttle die Weiche zuerst passieren darf Somit

164 ANHANG A. DAS SHUTTLE -BEISPIEL ko¨nnten beide Shuttle s weiterfahren und wu¨rden sich dann auf demselben Track befinden, was eine Kollsion der beiden Shuttle s bedeutet. Diese kritische Situation, impendingCollisionSwitch , wird in Abbildung A.16 dargestellt. Abbildung A.16: Die kritische Situation impendingCollisionSwitch A.2.3 Kardinalita¨ten Da der Ansatz aus Kapitel 3 und dessen Umsetzung aus Abschnitt 5.3 die im Klassendiagramm gegebenen Kardinalita¨ten nicht beru¨cksichtigt, mu¨ssen diese durch zusa¨tzlich verbotene Graphmuster spezifiziert werden. Wird dies nicht gemacht, so erha¨lt man bei der Verifikation Gegenbeispiele, 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 Kardinalita¨ten 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 Abbildung A.18: singleLocatedOn 165 Abbildung A.19: unumbigousLocatedOn Story Pattern unambigousLocatedOn , Abbildung A.19, dass ein Shuttle locatedOn -Links zu unterschiedlichen Track s hat. Wa¨hrend 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 na¨chstes fahren mo¨chte. Deshalb ist es nicht erlaubt, dass ein next -Link auf den selben Track zeigt wie der locatedOn -Link des Shuttle s. Dies wird durch das verbotene Story Pattern locatedOnNext aus Abbildung A.20 dargestellt. Abbildung A.20: locatedOnNext Um eine sichere Fahrt eines Shuttle s garantieren zu ko¨nnen, muss es immer zwei next Links besitzen, die anzeigen, auf welche Track s das Shuttle als na¨chstes und u¨berna¨chstes fahren mo¨chte. Die beiden next -Links du¨rfen jedoch nicht zum selben Track -Objekt zeigen. Diese Eigenschaft 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. Wa¨hrend die bisher in diesem Abschnitt betrachteten verbotenen Story Patterns Aussagen u¨ber ein Shuttle und seine Links gemacht haben, schra¨nken die folgenden verbotenen Story Patterns das Schienensystem ein. Die verbotenen Story Pattern singleSuccessor , Abbildung A.23, und twoWayTracks , Abbildung A.24, beschreiben, dass zwischen zwei Track s nur genau ein successor -Link sein darf. Dabei verbietet singleSuccessor , dass sich zwischen zwei Track s 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 Track s 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 ho¨chstens zwei Vorga¨nger oder Nachfolger haben darf. Das verbotene Story Pattern tooManyPredecesors in Abbildung A.25 zeigt, dass ein Track mehr als zwei Vorga¨nger hat. Dem gegenu¨ber verbietet das Story Pattern tooManySuccessors in Abbildung A.26, dass ein Track mehr als zwei Nachfolger hat. Abbildung A.25: tooManyPredecesors A.2.4 Gro¨ßen der verbotenen Graphmuster Nachdem in den voran gegangenen Abschnitten die verbotenen Graphmuster erla¨utert wurden, werden in der Tabelle A.2 die Gro¨ßen der verbotenen Graphmuster aufgelistet.

A.2. VERBOTENE GRAPHMUSTER 167 Abbildung A.26: tooManySuccessors Verbotene Graphmuster collision notMember noPublication impendingCollision impendingCollisionSwitch singleLocatedOn unumbigousLocatedOn locatedOnNext singleNext tooManyNext singleSuccessor twoWayTracks tooManyPredesesors tooManySuccessors Gro¨ ße Objekte Links 32 44 44 56 68 22 32 22 22 43 22 22 43 43 Tabelle A.2: Charakteristiken der verbotenen Graphmuster im Shuttle -Beispiel

168 ANHANG A. DAS SHUTTLE -BEISPIEL

Anhang B Theoretische Ergebnisse und Beweisskizzen Fu¨r die in Kapitel 3 aufgefu¨hrten Lemmata und Theoreme sollen in diesen Kapitel deren Beweise skizziert werden. B.1 Graphmuster Lemma 1.( Implikation von Teilgraphmustern ) Fu¨r zwei Graphmuster p und p gilt: ( p p) ( G G[ p]: G|= p) und ( G G[ p]: G|= p) ( p p). (B.1) (B.2) Beweis: Implikation B.1: Um zu zeigen, dass die Implikation stimmt, muss zum einen gezeigt werden, dass es einen Isomorphismus gibt, der P auf G abbildet und zum anderen, dass es keinen Isomorphismus gibt, er ein P^ P ^ auf G abbildet. Per Definition gilt ( p p) iso ISO: P iso P und  G G[ p], iso ISO: G P iso G . Daraus folgt  iso ISO: iso:= iso iso , fu¨r diesen Isomorphismus iso gilt P iso G . Womit die erste Forderung erfu¨llt ist. Nach Definition 20 gilt  P^ P ^ , P^ P ^ , iso iv  ISO: iso| P = iso ( P^\( P\ iso( P))) iso iv P^ . Aus  iso ISO: P iso G und  P^ P ^ , iso ISO: iso| P = iso P^ iso G folgt, dass  P^ P ^ , iso v  ISO:( P^\( P\ iso( P))) iso v G und damit gilt auch  P^ P ^ , iso vi  ISO: iso vi | P = iso P^ iso vi G . Damit ist auch die zweite Forderung erfu¨llt 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. Fu¨r zwei Graphen G 1 , G 2  G , die typkonform zu G sind, gilt, dass auch ihre Vereinigung G 1  G 2 typkonform 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 G 1 und G 2 gebildet wird, ist auch die Vereinigung typkonform zu G . Lemma 3. Fu¨r zwei Graphen G 1 , G 2  G , die typkonform zu G sind, gilt, dass auch der Schnitt G 1  G 2 und die Subtraktion G 1 \ G 2 typkonform sind. Beweis: Beide Graphen sind typkonform zu G , somit ist das Bilden des Schnitts und der Subtraktion mo¨glich. 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. Fu¨r zwei Graphen G 1 , G 2  G und einen totalen Graphhomomorphismus m M: G 1  G 2 gilt, dass G 1 genau dann typkonform zu G ist, wenn G 2 typkonform zu G ist. Beweis: Die Definition 9 verlangt fu¨r einen totalen Graphhomomorphismus, dass er die Knotenund Kantenbeschriftungen erha¨lt. Existiert ein m M: G 1  G 2 so gilt, dass entweder beide Graphen G 1 und G 2 typkonform zum Typgraphen G sind oder beide Graphen nicht typkonform sind. Theorem 1. Fu¨r jeden typkonformen Graphen G 1  G und jede typkonforme Graphtransformationsregel [ L, L ^ ] r R gilt: falls ein G 2  G existiert, mit G 1 |= r G 2 , so ist auch G 2 typkonform. Beweis: Die Regel [ L, L ^ ] r R ist auf den Graphen G 1 anwendbar, wenn  iso ISO: L iso G und  L^ L ^ , iso: iso| L = iso P^ iso G gilt. Nach Lemma 4 gilt, dass Homomorphismen die Typkonformita¨t erhalten. Kann die Regel unter dem Auftreten o mit o: o| L = iso angewendet werden, so werden aus G 1 durch Subtraktion alle Elemente entfernt auf die die Elemente aus L\ R abgebildet werden ko¨nnen, d.h. G 1 := G 1 \ o( L\ R) . Da die Subtraktion nach Lemma 3 die Typkonformita¨t erha¨lt, ist der resultierende Graph G 1 typkonform zu G . G 1 wird nun um alle Elemente aus R\ L erweitert, d.h. G 2 := G 1  o( R\ L) . Da die Vereinigung nach Lemma 2 die Typkonformita¨t erha¨lt, ist G 2 typkonform zu G . Lemma 5. Wird eine typkonforme Regel [ L, L ^ ] r R wie in Definition 27 erweitert und die erweiterte Regel auf einen typkonformen Graphen G im DPO iso angewendet, so erfu¨llt die Regelanwendung die Lose-Kanten-Bedingung. Beweis: Sei [ L re , L ^ re ] re R re eine erweiterte Regel, G 1  G ein Anwendungsgraph und G 2  G ein Ergebnisgraph, wobei G 1 und G 2 typkonform zu G sind und es gilt G 1 |= re G 2 . Angenommen, die Anwendung von r unter Auftreten o auf den Graphen G 1 erzeugt eine lose Kante, d.h.  e E G 1 , e E L re : o( e)= e( ( src( e) ( N L re \ N R re )) ( tgt( e) ( N L re \ N R re ))) . Das bedeutet, es mu¨ssen zwei Fa¨lle 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 ( N L \ N R ): o( n)= src( e) . Da r re anwendbar ist bedeutet das, dass es keinen Graphen L^ re  L ^ re gibt, der die Anwendung verbietet, d.h.  L^ re  L ^ re : N L^ re := N L re  { n} , E L^ re := E L re  { e} , src L^ re := src L re ( x) n : : x E L re x== e , tgt L^ re := tgt L re ( x) n : : x E L re x== e , l N L^re ( x):= l N Lre ( x) t n : : x N L re x== n und l E L^re ( x):= l E Lre ( x) t e : : x E L re x== e . Da fu¨r jede korrekt typisierte Kante, die inzident zu einem zu lo¨schenden Knoten ist, ein Graph zur negativen Anwendungsbedingung hinzugefu¨gt wird, gilt auch, dass fu¨r jede korrekt typisierte Kante e mit o( n)= src( e) 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) gelo¨scht wird und aus der Kanten o( e) eine lose Kante wird, folgt daraus, dass e nicht korrekt typisiert ist. Diese ist jedoch ein Widerspruch zur Annahme, da G 1 typkonform zu G ist. Fall 2: erfolgt analog zu Fall 1. B.3 Erweiterte Graphtransformationen Theorem 2.( Ru¨ ckwa¨ rtsanwendung einer Graphtransformationsregel im DPO iso ) Fu¨r jede Graphtransformationsregel [ L, L ^ ] r R , ihr Inverses [ L - 1 , L ^ - 1 ] r - 1 R - 1 und ein Auftreten o von r in G 1 gilt im DPO iso : G 1 |= ( r, o) G 2  G 2 |= ( r - 1 , o - 1 ) G 1 . Beweis: " " : Da G 2 G 1 entstanden ist, muss durch die Anwendung von es einen Isomorphismus iso r unter dem Auftreten o  ISO geben, fu¨r den auf gilt den Graphen iso= o - 1 | L - 1  L - 1 iso G 2 . Somit ist r - 1 anwendbar wenn gilt  L^ - 1  L ^ - 1 , iso ISO: iso| L - 1 = iso L^ iso G 2 . Die Menge L ^ - 1 kann in zwei Teilmengen unterteilt werden: Die erste Menge L ^ 1 1 entha¨lt alle Graphen L^ - 1  L ^ - 1 , die durch die Anwendung von extendNAC erzeugt wurden, um eine Anwendung von r - 1 zu verhindern, wenn andernfalls lose Kanten entstehen. Die zweite Menge L ^ 2 1  L ^ - 1 entha¨lt alle Graphen L^ - 1 , die durch die Konvertierung der negativen Anwendungsbedingung L ^ entstanden sind. Fu¨r die Graphen der Menge L ^ 1 1 gilt, dass ihre Knoten entweder auch in L - 1 enthalten sind oder adjazent zu Knoten sind, die bei der Anwendung von r - 1 gelo¨scht und damit durch die Anwendung von r erzeugt werden. Da Knoten, die durch die Anwendung von r erzeugt wurden, nur adjazent zu Knoten sein ko¨nnen, die zu R und somit auch zu L - 1 geho¨ren, gibt es keinen Isomorphismus iso ISO der einen Graphen aus L ^ - 1 auf G 2 abbildet und fu¨r den gilt iso| L - 1 = iso . Somit wird die Regelanwendung durch die Teilmenge L ^ 1 1 nicht verhindert. Fu¨r die Menge L ^ 2 1 gilt, dass ihre Graphen durch die Konvertierung der negativen Anwendungsbedingung L ^ von r entstanden sind, d.h.  L^ - 1  L ^ 2 1 , L^ L ^ : L^|= L ( r, o) R L^ - 1 . Da die Graphen aus L ^ 2 1 durch die Anwendung der gleichen Regel entstanden sind, wie der Graph G 2 , gilt, dass es nur dann einen Isomorphismus iso 1  ISO geben kann, der einen Graphen L^ - 1  L ^ 2 1 auf G 2 abbildet, wenn es einen Isomorphismus iso 2  ISO und einen Graphen L^ L ^

172 ANHANG B. THEORETISCHE ERGEBNISSE UND BEWEISSKIZZEN gibt, sodass gilt L^ iso 2 G 1 und L^|= L ( r, o) R L^ - 1 . Dies ist jedoch ein Widerspruch, da r auf G 1 anwendbar ist. Somit wird die Anwendung von r - 1 auf G 2 unter dem Auftreten o - 1 auch durch die Menge L ^ 2 1 nicht verhindert. " " : erfolgt analog zu " ". Theorem 3. Fu¨r eine Graphtransformationsregel [ L, L ^ ] r R und zwei Graphmuster p:=[ P, hat P], p:=[ P, P ^ ] gilt im DPO iso : ( p|=|= r p) ( G 1 , G 2  G, iso ISO: P P G 1  G 2 :( G 1 |= p G 1 |= r, iso| L R G 2 ) ( G 2 |= p)). B ne e r w d e e is r : b"ei den" : Annahme ( G 1 folgenden Fa¨lle |= p G|= ( r, iso| R L ) gelten:(1)  iso I G 2 ) SO  ( G 2 : iso| P |= = p) iso gilt  P nicht. iso Dann muss eiG 2 oder es gilt (2)  P^ P ^ , iso ISO: iso| P = iso| P  P^ iso G 2 . Fall(1): falls kein solcher Isomorphismus iso existiert, muss gelten  n N P , e E P : iso( n)= undefiniert iso( e)= undefiniert . Da iso alle Elemente aus P auf G 1 abbildet und p|=|= r p gilt muss n (oder e ) entweder(a) nur in P aber nicht in P enthalten sein und somit durch die Anwendung von r erzeugt werden oder(b) n (oder e ) ist sowohl Teil von P als auch von P wird aber durch die Anwendung von r gelo¨scht, d.h. n ( N L \ N R ) (bzw. e ( E L \ E R ) ). (a) da p|=|= r, o p gilt, muss r den Knoten n (bzw. die Kante e ) erzeugen, d.h. n ( N R \ N L ) (bzw. e ( E R \ E L ) ). Dann wird n (bzw. e ) jedoch auch bei der Anwendung von r unter dem Auftreten o auf G 1 erzeugt und ist somit auch in G 2 enthalten. (b) n (bzw. e ) geho¨rt sowohl zu P als auch zu P , dann muss die Anwendung von r unter o das Element lo¨schen, in diesem Fall wird das Element aber auch gelo¨scht, wenn r unter o auf p angewendet wird und somit wu¨rde nicht p|=|= ( r, o) p gelten. Fall 2: es gilt  P^ P ^ , iso ISO: iso| P = iso| P  P^ iso G 2 . Da p|=|= r p und G 1 |= p gilt, muss P^ durch die Anwendung von r erzeugt worden sein. Die Menge P ^ setzt sich aus zwei Teilmengen zusammen.(a) Die erste Menge, P ^ 1 , entha¨lt alle P^ , die durch extendNAC erzeugt werden.(b) Die zweite Menge, P ^ 2 , entha¨lt alle P^ , fu¨r die gilt  P^ P ^ : P^|= L r R P^ . (a) extendNAC pru¨ft fu¨r jeden durch r neu erzeugten Knoten im Typgraphen, Knoten von welchem Typ adjazent zum neuen Knoten sein ko¨nnen. Fu¨r jeden dieser Knoten wird ein Graph in die negative Anwendungsbedingung eingefu¨gt. Somit beschreiben die P^ P ^ 1 , dass ein neu erzeugter Knoten nur adjazent zu Knoten aus R sein kann. Daraus folgt, dass  P^ P ^ 1 , iso ISO: P^ iso G 2 . (b)  P^ P ^ 2 , P^ P ^ : P^|= L r R P^ , daraus folgt, dass P^ durch die Anwendung von r unter dem Auftreten o nur entstehen kann, wenn P^ durch einen Isomorphismus aus G 1 abgebildet werden kann, dann wu¨rde aber G 1 |= p gelten, was eine Widerspruch zur Voraussetzung ist. Aus Fall " " : 1 und zuerst Fwailrld2gfeozlegitg"t, ". dass P alle Graphen G 1 und G 2 , fu¨r die gilt G |= ( r, o) P |= p G 1 gilt. Die rechte Seite der |= ( r, o) G 2 . Somit ko¨nnen Implikation gilt fu¨r G 1 und G 2 beliebig

B.4. SYSTEMEIGENSCHAFTEN UND INVARIANTEN 173 gewa¨hlt werden, also auch G 1 = P und G 2 = P . Daraus folgt dann P= G 1 |= r G 2 = P , dies entspricht P|= r P . Angenommen der rechte Teil der Implikation gilt, der linke aber nicht, d.h. ( p|=|= ( r, o) p) ( p ( p|=|= ( r, o) |=|= ( r, o) p) p) . Da  ( G 1 , P|= ( r, o) P G 2  G, iso gilt, muss  ISO: P auch P P G 1  P  G 2 : gelten. ( G 1 |= Nach p G " |= ( r " , o) gilt G 2 )  ( G 2 |= p)) . Wegen P P und ( p|=|= ( r, o) p) muss dann jedoch gelten ( P^ P, iso ISO: P^ iso G 2 ) ( G 2 |= p) , was aber ein Widerspruch zur Voraussetzung ist. Theorem 4. Fu¨r eine Graphtransformationsregel [ L, L ^ ] r R , ihr Inverses [ L - 1 , L ^ - 1 ] r - 1 R - 1 , zwei Graphmuster p:=[ P, P ^ ] und p:=[ P, P ^ ] und ein Auftreten o: L R P P gilt im DPO iso : ( p|=|= ( r, o) p) ( p|=|= ( 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 , G Si , R S ) , falls T[,  ]= . ( B G e 1 w | e = is: ( r " , o) G 2 " : Da eine G|= ) induktive Invariante ( G 2 |= ) . Damit gilt ist, gilt  G 1 , G 2  G[ G ], dann auch T[,  ]= . r R, o ISO:  G 2 " |= " ) . : Aus T[,  ] Deshalb gilt folgt  r  r R,  R, G 1 , G 2  G[ G ], o G 1 , G 2  G[ G ], o ISO ISO:(( G 1 |= ( r, o) :( ( G 1 |= ( r, o) G 2 G 2  G  G|= |= )  ) ( G|=) ) . Das ist a¨quivalent zu  r R, G 1 , G 2  G[ G ], o ISO:( G 1 |= ( r, o) G 2  G 1 |= )  ( G 2 |= ) und somit ist eine induktive Invariante. Lemma 7. Fu¨r eine Sicherheitseigenschaft der Form j J (  p j ) und ein System S:=( G[ G ], G Si , R S ) ist die Menge T[,  ] genau dann nicht leer und somit das System inkorrekt, wenn gilt:  G , G  G[ G ], r R S , o ISO: ( G |= ( r, o) G ) ( i J: G |= p i ) ( j J: G |= p j ). (B.3) Beweis: Folgt direkt aus der Definition von T[,  ] und der Struktur der Sicherheitseigenschaften.

174 ANHANG B. THEORETISCHE ERGEBNISSE UND BEWEISSKIZZEN B.5 Nachweis von induktiven Invarianten Lemma 8. Fu¨r eine Graphtransformationsregel [ L, L ^ ] r R und ein Graphmuster p:=[ P, P ^ ] gilt im DPO iso :  G, G G, o ISO: G|= ( r, o) G G|= o p G|= iso p (( R\ L) o( P)= ) ( iso ISO, P^ P ^ : iso| P = o| P  L R P^= ). (B.4) Beweis: Annahme die Implikation gilt nicht, d.h. es gilt(1) dass ( R\ L) iso( P)= und(2)  iso ISO, P^ P: iso| P = iso ( L R iso( P))= . (1) es gilt ( R\ L) iso( P)= n N P , e E P :( iso( n) ( N G 1 \ N G 2 )) ( iso( e) ( E G 1 \ E G 2 )) P iso G 1 . (2) es gilt  iso ISO, P^ P ^ : iso| P = iso L R iso( P^)= n N P^ : iso( n) ( L R) . Nach(1) gilt P iso G 1 . Somit muss die Anwendung von r einen Knoten aus ( N P^ \ N P ) oder eine Kante aus ( E P^ \ E P ) entfernen. Fu¨r alle Knoten aus ( N P^ \ N P ) gilt, wegen der Verwendung des DPO iso , dass es einen Pfad zu einem Knoten aus P gibt. Das bedeutet, dass ein Knoten aus N P^ \ N P entfernt oder in diese Menge eingefu¨gt werden kann, wenn ein adjazenter Knoten n explizit durch die Regel erhalten bleibt, d.h. es muss gelten n ( N L  N E  iso( N P^ )) . Ebenso kann eine Kante aus ( E P^ \ E P ) nur gelo¨scht werden, wenn ein inzidenter Knoten n explizit erhalten bleibt. Da die Menge ( N L  N E  iso( N P^ )) leer ist, muss somit gelten, dass  P^ P: P^ iso G 1 . Beide Punkte zusammen ergeben einen Widerspruch zur Annahmen. Lemma 9. Fu¨r ein System S:=( G , G i , R S ) und eine Sicherheitseigenschaft : = j J (  p j ) gilt im DPO iso  i J, r R : ( egm EGM ( r, p i ), sgm, o ISO:( egm|=|= ( r - 1 , o - 1 ) sgm) ( j J: p j  sgm)) ( G 1 , G 2  G[ G ]:( G 1 |= ( r, o) G 2  G 2 |= p i ) ( j J: G 1 |= p j )). Beweis: Angenommen, die Implikation gilt nicht. Dann gilt ( G 1 , G 2  G[ G ], o ISO: ( G 1 |= ( r, o) G 2  G 2 |= p i ) ( j J: G 1 |= p j )) , d.h.  G 1 , G 2  G[ G ]:( G 1 |= ( r, o) G 2 G 2 |= P i ) und es gilt  j J: G 1 |= p j . Da  j J: G 1 |= p j gilt, folgt daraus, dass die Anwendung von r unter dem Auftreten o auf G 1 p i erzeugt haben muss. Nach Lemma 8 muss G 2 ein Element enthalten, auf das o ein Element der rechten Regelseite von r abbildet und auf das zusa¨tzlich ein Element aus p i abgebildet werden kann. Da die Menge T GP ( r, p i ) alle mo¨glichen Ergebnisgraphmuster fu¨r r und p i entha¨lt, muss gelten  egm T GP ( r, p i ): G 2 |= egm . Aus Theorem 2 folgt dann, dass die zu r inverse Regel r - 1 auf G 2 angewendet werden kann. Diese Regelanwendung resultiert in einem Graphen G 1 fu¨r den gilt G|= sgm . G 1 |= impliziert nach Bedingung B.1 aus Lemma 1, dass es keinen Zeugen fu¨r ein verbotenes Graphmuster in G 1 gibt. Somit muss gelten  j J: p j  sgm . Dies stellt jedoch ein Widerspruch zur Voraussetzung dar.

B.5. NACHWEIS VON INDUKTIVEN INVARIANTEN 175 Theorem 5. Fu¨r ein System S:=( G , G Si , R S ) ist die Sicherheitseigenschaft : = j J (  p j ) genau dann eine induktive Invariante, wenn gilt:  i J, r R S , egm EGM ( r, p i ), sgm, o ISO: ( egm|=|= ( r - 1 , o - 1 ) sgm) ( j J: p j  sgm). (B.5) Beweis: Nach Lemma 9 gilt, dass  j J, r R S , G 1 , G 2  G[ G ], o ISO:( G 1 |= ( r, o) G 2  G 2 |= p i ) j J: G|= p j . Dies entspricht, da : = j J (  p j ) ,  G 1 , G 2  G[ G ], r R S , o ISO:( G 1 |= ( r, o) G 2  G 2 |= ) G|= . Nach Lemma 7 muss dann T[,  ]= gelten. Lemma 6 garantiert dann, dass eine induktive Invariante von S ist.

176 ANHANG B. THEORETISCHE ERGEBNISSE UND BEWEISSKIZZEN

Anhang C Algorithmen In diesem Kapitel werden Algorithmen in Pseudocode-Notation beschrieben, die die theoretischen Ergebnisse aus Kapitel 3 darstellen. C.1 Graphtransformationen Dieser Abschnitt beschreibt die Algorithmen, die beno¨tigt werden, um Graphtransformationsregeln 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 DPO iso Ansatz korrekt angewendet werden(Abschnitt C.1.1). C.1.1 Negative Anwendungsbedingungen Damit eine Graphtransformationsregel im DPO iso Ansatz angewendet wird, muss garantiert werden, dass sowohl die Identifikationsbedingung als auch die Lose-Kanten-Bedingung bei jeder Regelanwendung erfu¨llt werden. Die Erfu¨llung der Identifikationsbedingung wird dadurch erreicht, dass das Auftreten einer Regel in einem Anwendungsgraphen durch einen Isomorphismus gegeben sein muss. Damit die Lose-Kanten-Bedingung immer erfu¨llt wird, muss die linke Regelseite so erweitert werden, dass die Regel nur dann anwendbar ist, wenn bei der Anwendung keine losen Kanten entstehen. Der Algorithmus, der diese Erweiterung beschreibt, ist im folgenden Abschnitt gegeben. Durch die Erweiterung der linken Regelseite um zusa¨tzliche Graphen in der negativen Anwendungsbedingung, ko¨nnen 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 gro¨ßere der beiden Graphen aus der negativen Anwendungsbedingung entfernt werden. Immer wenn dieser gro¨ßere Graph eine Regelanwendung verhindert, kann der entsprechende Match auch dazu verwendet werden, um den kleineren Graphen auf den Anwendungsgraphen abzubilden. 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 negativen Anwendungsbedingung vornimmt. Als Eingabe erha¨lt der Algorithmus eine Regel [ L, L ^ ] r R sowie den dazu geho¨rigen Typgraph G . Die a¨ußere For-Schleife betrachtet alle Knoten, die gelo¨scht werden sollen. In den Zeilen 5 bis 18 werden fu¨r jeden dieser Knoten alle inzidenten Kanten betrachtet, die den zu lo¨schenden Knoten als Startknoten haben. Ist die Kante kein Teil der linken Regelseite, so wird ein Graph erzeugt, der neben der linken Regelseite diese Kante entha¨lt. 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 hinzugefu¨gt. In den Zeilen 19 bis 33 wird der Fall betrachtet, dass der zu lo¨schende Knoten Zielknoten einer Kante ist, die nicht durch die Regel gelo¨scht wird. 01: Set<Graph> extendNAC(Set<Graph>( L, L ^ , R), Graph G ) 02: begin 03: Set<Graph> addNAC= L ^ 04: forall n N L - N R do 05: forall ( l N ( n), t e , n) correctT ypedEdges( G ) do 06: // edge with source in L but not in R 07: if( e E L ) then 08: E:= E L  { e} 09: if( n N L ) then 10: N:= N L  { n} 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: l N := x.if(x== n') then t n else l N ( x) fi 15: l E := x.if(x== e) then t e else l E ( x) fi 16: addN AC.add( N, E, src, tgt, l N , l E ) 17: fi 18: end 19: forall( n, t e , l N ( n)) correctT ypedEdges( G ) do 20: // edge with target in L but not in R 21: if( e E L ) then 22: E:= E L  { e} 23: if( n N L ) then 24: N:= N L  { n} 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: l N := x.if( x== n) then t n else l N ( x) fi 29: l E := x.if( x== e) then t e else l E ( x) fi 30: addN AC.add( N, E, src, tgt, l N , l 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 erfu¨llt

C.1. GRAPHTRANSFORMATIONEN 179 Der Algorithmus minimizeNAC Der Algorithmus zur Minimierung von negativen Anwendungsbedingungen ist in Abbildung C.2 dargestellt. Dieser Algorithmus pru¨ft in Zeile 4 bis 10 fu¨r jeden Graphen L^ der negativen Anwendungsbedingung, ob es einen anderen Graphen L^ gibt, der Teilgraph von L^ ist. Kann kein solcher Graph gefunden werden, wird L^ in die minimale negative Anwendungsbedingung aufgenommen, Zeile 11. Als Ru¨ckgabe 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 ^  L ^ do 04: Boolean f lag:= true ; 05: forall L ^  L ^ -{ L ^ } do 06: if(  iso: iso| L )= id L  L ^ iso L ^ ) then 07: f lag:= f alse 08: fi 09: end 10: if( f lag= true ) then HL:= HL { L ^ } fi 11: end 12: return HL 13: end Abbildung C.2: Algorithmus minimizeNAC zur Minimierung von negativen Anwendungsbedingungen C.1.2 Anwendung von Graphtransformationsregeln Nachdem eine Graphtransformationsregel um zusa¨tzliche Graphen in der negativen Anwendungsbedingung erweitert wurde, kann ihre Anwendung erfolgen. Der Algorithmus der eine Regelanwendung im DPO iso Ansatz vornimmt, wenn diese erweitert wurden, ist im folgenden Abschnitt gegeben. Der Algorithmus apply Der Algorithmus, der die Anwendung einer Regel r auf einen Graphen G beschreibt ist in Abbildung C.3 gegeben, wobei iso das Auftreten von r in G beschreibt. In Zeile 02 wird u¨berpru¨ft, ob der u¨bergebene Isomorphismus die linke Regelseite auf einen Teilgraphen des Anwendungsgraphen abbildet. Ist dies nicht der Fall, so kann die Regel nicht angewendet werden. Andernfalls wird ein neuer Isomorphismus gewa¨hlt, der den u¨bergebenen 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 Anwendungsgraphen 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 Regelseite enthalten sind, werden durch den Isomorphismus in den Anwendungsgraphen eingefu¨gt. Der resultierende Graph wird dann(Zeile 09) zuru¨ckgeliefert.

180 ANHANG C. ALGORITHMEN 01: Graph apply(Graph G, Rule L r R , Isomorphism iso) 02: if( L iso G ) then 03: choose Isomorphism iso': R G with iso| L = iso iso( R\ L) G= 04: //apply rule 05: T G:=( G\ iso( L\ R)) iso( 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 eingefu¨hrten Algorithmus ist es mo¨glich, eine Regel in Vorwa¨rtsrichtung auf einen Anwendungsgraphen anzuwenden. Wurde die Regel zuvor um zusa¨tzliche Graphen in der negativen Anwendungsbedingung erweitert, so erfu¨llt diese Regelanwendungen die Identifikations- und die Lose-Kanten-Bedingung des Eingeschra¨nkten Single Pushout Ansatz. Eine Regelanwendung im Single Pushout Ansatz kann auch in Ru¨ckwa¨rtsrichtung erfolgen. Außerdem ist es nicht nur mo¨glich, eine Regel auf einen Anwendungsgraphen, sondern auch auf ein Graphmuster anzuwenden. Die beno¨tigten Algorithmen zur Ru¨ckwa¨rtsanwendung von Graphtransformationsregeln werden im folgenden Abschnitt C.2.1 erkla¨rt. Der Algorithmus zur Anwendung einer Graphtransformationsregel auf ein Graphmuster ist Inhalt von Abschnitt C.2.2. C.2.1 Ru¨ ckwa¨rtsanwendung von Graphtransformationsregeln Nachdem beschrieben wurde, wie eine Regel im DPO iso Ansatz korrekt in Vorwa¨rtsrichtung angewendet wird, soll in diesem Abschnitt die Ru¨ckwa¨rtsanwendung betrachtet werden. Auch bei der Ru¨ckwa¨rtsanwendung mu¨ssen die Identifikations- und die Lose-Kanten-Bedingung des DPO iso Ansatz erfu¨llt werden. Der Algorithmus reverse vera¨ndert eine Graphtransformationsregel so, dass sie in Ru¨ckwa¨rtsrichtung angewendet werden kann und dabei die Bedingungen des DPO iso Ansatz einha¨lt. Dazu ist es zuna¨chst 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 Regelanwendung apply aus Abbildung C.3. Der Algorithmus convertNAC Damit eine Regel korrekt in Ru¨ckwa¨rtsrichtung angewendet werden kann, muss ihre negative Anwendungsbedingung angepasst werden. Dies ist aus verschiedenen Gru¨nden erforderlich. Als

C.2. ERWEITERTE GRAPHTRANSFORMATIONEN 181 erstes wird bei einer Ru¨ckwa¨rtsanwendung aus der urspru¨nglichen linken Regelseite die neue rechte Regelseite und diese darf keine negative Anwendungsbedingung besitzen. Zweitens, auch bei einer Ru¨ckwa¨rtsanwendung mu¨ssen die Identifikations- und die Lose-Kanten-Bedingung des DPO iso Ansatzes eingehalten werden. Um die negative Anwendungsbedingung konvertieren zu ko¨nnen, mu¨ssen zuna¨chst alle Graphen aus der negativen Anwendungsbedingung entfernt werden, die eine Regelanwendung verhindern, wenn andernfalls lose Kanten entstehen wu¨rden(Zeilen 04 bis 06). Die verbleibenden Graphen der negativen Anwendung werden dann(Zeilen 07 bis 12) transformiert, indem die Regel(ohne negative Anwendungsbedingung) darauf angewendet wird. Durch das Entfernen aller Graphen, die eine Regelanwendung verhindern, sollten andernfalls lose Kanten entstehen, wird gewa¨hrleistet, dass die Regel nur auf solche Graphen angewendet wird, bei denen keine losen Kanten zuru¨ckbleiben. Nachdem diese Graphen modifiziert wurden, mu¨ssen nun die Graphen hinzugefu¨gt 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 ^] r R ) 02: begin 03: Set<Graph> HL':= 04: Set<Graph> enac:= extendNAC( [ L, L ^] r R, G ) 05: //delete all graphs of the NAC which relate to a dangling edge 06: Set<Graph> HL:= { L ^  L ^ | L ^  enac: L ^  L ^ } 07: while HL = do 08: choose L ^ in HL 09: L ^ := apply( L ^ , L r R) 10: HL:= HL \{ L ^ } 11: HL':= HL'  { L ^ } 12: end 13: return HL extendN AC( R r - 1 L, G ) 14: end Abbildung C.4: Algorithmus convertNAC zum Konvertieren von negativen Anwendungsbedingungen Der Algorithmus reverse Der Algorithmus reverse Abbildung C.5 beschreibt die Transformation einer Graphtransformationsregel, sodass ihre Anwendung mittels des Algorithmus apply aus Abbildung C.3 die Bedingungen des DPO iso Ansatzes erfu¨llt. 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 resultierende 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 L und R vertauscht(Zeile 05). Das bedeutet, aus der urspru¨nglichen Nachbedingung, der rechten Regelseite R , wird die neue Anwendungsbedingung und aus der urspru¨nglichen Anwendungsbedingung L die neue Nachbedingung.

182 ANHANG C. ALGORITHMEN 01: GraphRule reverse( GraphRule[ L, L ^] r R, Graph G ) 02: begin 03: Set<Graph> nac:= convertNAC( [ L, L ^] r R, G ) 04: nac:= minimizeNAC( [ R, nac] r - 1 L ) 05: return [ R, nac] r - 1 L 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 vera¨ndern. Dabei muss jedoch beru¨cksichtigt werden, dass das Graphmuster eine negative Anwendungsbedingung besitzen kann. Diese negative Anwendungsbedingung muss durch die Regelanwendung ebenfalls transformiert werden. Der Algorithmus, der eine Regel auf ein Graphmuster anwendet, wird im Folgenden beschrieben. Der Algorithmus applyRuleToPattern Der Algorithmus, der die Anwendung einer Regel r auf ein Graphmuster p beschreibt, ist in Abbildung C.6 gegeben. Die if-Anweisung in Zeile 02 pru¨ft, ob die linke Regelseite ein Teilgraphmuster des Graphmusters [ P, P ^ ] ist. Ist dies der Fall, wird in den Zeilen 03 bis 16 das Auftreten o der linken und rechten Regelseite bestimmt. Dieses Auftreten bildet Elemente der linken Regelseite mittels des Isomorphismus aus der if-Anweisung auf Elemente der Graphmusters ab. Fu¨r Elemente, die nur Teil der rechten Regelseite sind, wird die Identita¨tsfunktion verwendet. Das Auftreten wird dann dazu verwendet, um alle Elemente, die zur linken, aber nicht zur rechten Regelseite geho¨ren aus dem Muster zu entfernen(Zeile 19). Elemente, die zur rechten aber nicht zur linken Regelseite geho¨ren, werden mit Hilfe von o in das Muster eingefu¨gt, 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 P ^ angepasst, indem die Regel r auf jeden der Graphen angewendet wird. Da [ L, L ^ ] ein Teilgraphmuster von [ P, P ^ ] , ist eine Anwendung der Regel auf jeden Graphen aus P ^ immer mo¨glich. Da die Regel r auf ein Graphmuster angewendet wird, wird auch die konvertierte negative Anwendungsbedingung von r in die negative Anwendungsbedingung von p aufgenommen. Dies ist in Zeile 32 beschrieben. Als Ergebnis liefert der Algorithmus ein Graphmuster p:=[ P P ^ ] , wobei P durch die Anwendung der Regel auf P erzeugt wird und P ^ sich aus den konvertierten negativen Anwendungsbedingungen von p und r zusammensetzt. C.3 U¨ berpru¨ fung induktiver Invarianten Nachdem die Algorithmen zur Regelanwendung in Vorwa¨rts- und Ru¨ckwa¨rtsrichtung betrachtet wurden und ein Algorithmus zur Anwendung einer Regel auf Graphmuster vorgestellt wurde, ko¨nnen nun die Algorithmen eingefu¨hrt werden, die den Nachweis induktiver Invarianten durchfu¨ hren.

C.3. U¨ BERPRU¨ FUNG INDUKTIVER INVARIANTEN 01: GraphPattern applyRuleToPattern( GraphP attern[ P, P ^] , Rule r [ L, math ^ calL] R, isomorphism iso, Graph G ) begin 02: if( ( L iso G) ( L ^  L ^ , P P ^ , iso: iso - 1 | P= iso ( P ^ \( P\ iso( P))) iso L ^ ) then 03: //build the occurence o:= o n , o e by extending iso 04: o n := x . if( x N L ) then 05: iso n 06: else 07: if( x N R \ N L ) then 08: id 09: fi 10: fi 11: o e := x . if( x E L ) then 12: iso e 13: else 14: if( x E R \ E L ) then 15: id 16: fi 17: fi 18: //build new Graph P' with P|= r P 19: //first remove all elements that belong to L but not to R 20: P:= P\ o( L\ R) 21: //add elements that belong to R but not to L 22: P:= P ( R\ L) 23: //all other elements remain unchanged 24: // P ^ is build of adjusted P ^ and L ^ 25: // P ^ has to be converted by applying r to all graphs in P ^ 26: Set<Graph> P ^ := 27: for( P ^  P ^ ) do 28: Graph P ^ := apply( P ^ , r L R, o) 29: P ^ := P ^  P ^ 30: end 31: //add converted L ^ to P ^ 32: P ^ := P ^  convertN AC( r [ L, L] R, G ) 33: return[ P, P ^ ] 34: else 35: return[ P, P ^ ] 36: fi 37: end 183 Abbildung C.6: Algorithmus applyRuleToPattern , der die Anwendung einer Graphtransformationsregel auf ein Graphmuster beschreibt Dazu wird zuna¨chst die Menge aller Ergebnisgraphmuster mittels des Algorithmus buildTGP gebildet(siehe Algorithmus in Abbildung C.7). Dabei ko¨nnen jedoch redundante Ergebnisgraphmuster entstehen, d.h. die vom Algorithmus zuru¨ck gelieferte Menge entha¨lt Paare von Ergebnisgraphmustern, 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 fu¨hrt und diese beiden Algorithmen aufruft, wurde bereits in Abschnitt 3.7.2 erla¨utert.

184 ANHANG C. ALGORITHMEN C.3.1 Bildung von Ergebnisgraphmustern Der wichtigste Algorithmus beim Nachweis induktiver Invarianten ist der Algorithmus buildTGP , der die Ergebnisgraphmuster erzeugt. Dieser Algorithmus wird als na¨chstes vorgestellt. Die Menge der zuru¨ckgelieferten Ergebnisgraphmuster, kann redundante Ergebnisgraphmuster enthalten. Das bedeutet, die Menge entha¨lt Paare von Graphmustern bei denen das eine ein Teilgraphmuster 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 Ergebnisgraphmuster kann mit dem Algorithmus reduceTGP aus Abbildung C.8 erfolgen. Der Algorithmus buildTGP Der Algorithmus buildTGP erzeugt fu¨r eine Graphtransformationsregel [ L, L ^ ] r R und ein verbotenes Graphmuster [ P, P ^ ] alle mo¨glichen 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 vervollsta¨ndigt. 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 Anwendungsbedingung 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. Zusa¨tzlich 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 mu¨ssen diese Teilgraphen jedoch mindestens ein Element enthalten, das nicht auch zur rechten Regelseite geho¨rt. Anschließend(Zeile 09) wird die Menge aller Teilgraphen der Anwendungsbedingung des verbotenen Graphmusters gebildet. Fu¨r jedes Paar, bestehend aus einem Teilgraphen der linken Regelseite und einem Teilgraphen der Anwendungsbedingung des verbotenen Graphmusters, wird bestimmt, ob es einen Teilgraphisomorphismus gibt, der den Teilgraphen des verbotenen Graphmusters auf den Teilgraphen der linken Regelseite abbildet(Zeile 13). Ist dies der Fall(Zeile 14), so wird dieser Isomorphismus verwendet, um die Anwendungsbedingung des Ergebnisgraphmusters aus der linken Regelseite und der Anwendungsbedingung des verbotenen Graphmusters zu bilden. Anschließend wird die Menge aller Isomorphismen bestimmt, die den gefundenen Isomorphismus erweitern(Zeile 17). Diese Isomorphismen werden dazu verwendet, um die negativen Anwendungsbedingungen des Ergebnisgraphmusters zu bilden. Dazu werden zum einen alle Graphen der negativen Anwendungsbedingung der linken Regelseite um den Anwendungsgraphen 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 hinzugefu¨gt.

C.3. U¨ BERPRU¨ FUNG INDUKTIVER INVARIANTEN 185 Die Bildung der zweiten Teilmenge ist Inhalt der Zeilen 38 bis 58. In Zeile 41 wird zuna¨chst die Menge  LS - 1 neu gebildet. Dabei besteht LS - 1 aus allen Teilgraphen der linken Regelseite, bei denen es mindestens ein Element gibt, das auch zur rechten Regelseite geho¨rt. Dann wird die Menge aller Teilgraphen aller Graphen der negativen Anwendungsbedingung des verbotenen Graphmusters gebildet(Zeile 41). Fu¨r jedes Paar, bestehend aus einem Graphen der linken Regelseite 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 na¨chstes 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 negativen 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 hinzugefu¨gt. Die Menge aller Ergebnisgraphmuster wird dann zuru¨ckgeliefert(Zeile 59). Der Algorithmus reduceTGP Der zuvor vorgestellte Algorithmus buildTGP bestimmt fu¨r eine Regel und einem verbotenen Graphmuster alle mo¨glichen Ergebnisgraphmuster. Dabei entstehen jedoch redundante Graphmuster, 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 Verifikationsalgorithmus, da dieser fu¨r jedes Ergebnisgraphmuster u¨berpru¨fen 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 pru¨ft fu¨r jedes Paar der Ergebnisgraphmuster aus der u¨bergebenen Menge, ob das Ergebnisgraphmuster tgp ein Teilgraphmuster von tgp ist(Zeilen 05 bis 18). Ist dies der Fall wird tgp aus der Menge der Ergebnisgraphmuster entfernt, Zeile 12. Die minimierte Menge wird dann zuru¨ck gegeben(Zeile 19).

186 ANHANG C. ALGORITHMEN 01: Set<GraphPattern> buildTGP(Rule [ L - 1 , L ^ - 1 ] r - 1 R - 1 , GraphP attern[ P, P ^] ) 02: begin: 03: Set<GraphPattern> T GP:= 04: Graph T GP 05: Graph T G ^ P 06: GraphPattern tgp 07: // ( L - 1 \ R - 1 ) P= 08: Set<Graph> LS - 1 :={ L|( L L - 1 )( ( L - 1 \ R - 1 )= )} 09: Set<Graph> P S:={ P| P P} 10: forall ( L - 1  LS - 1 ) do 11: forall ( P P S) do 12: if(  iso: L - 1 = iso P ) then 13: T GP= L - 1  iso( P) 14: //calculate the NAC 15: //extend all L ^ - 1 by P 16: ISO:={ iso| iso| P = iso} 17: forall( iso ISO ) do 18: forall( L ^ - 1  L ^ - 1 ) do 19: T G ^ P:= L ^ - 1  iso( P) 20: T G ^ P:= T G ^ P T G ^ P 21: end 22: end 23: //extend all P ^ by L - 1 24: forall( iso ISO ) do 25: forall( P ^  P ^ ) do 26: T G ^ P:= L - 1  P ^ 27: T G ^ P:= T G ^ P T G ^ P 28: end 29: end 30: T G ^ P:= minimizeN AC( T G ^ P) 31: tgp:=[ T GP, T G ^ P] 32: T GP:= T GP tgp 33: T G ^ P:= 34: fi 35: end 36: end 37: // L - 1  R - 1  P ^ = 38: T G ^ P:= 39: LS - 1 :={ L - 1 | L -1  ( L - 1  R - 1 )} 40: P ^ S:={ P ^ |( P ^  P ^) } 41: forall( L LS - 1 ) do 42: forall( P ^  P ^ S ) do 43: if(  iso: L - 1 = iso P ^ ) then 44: T GP:= L - 1  iso( P) 45: //calculate the NAC 46: ISO:={ iso| iso| P ^ = iso} 47: forall( iso IS ^ O ) do 48: forall( P ^  P ^ ) do 49: T G ^ P:= L - 1  iso( P ^) 50: T G ^ P:= T G ^ P T G ^ P 51: end 51: end 52: T G ^ P:= minimizeN AC( T G ^ P) 53: tgp:=[ T GP, T G ^ P] 54: T GP:= T GP tgp 55: T G ^ P:= 56: fi 57: end 58: end 59: return T GP 60: end Abbildung C.7: Algorithmus buildTGP zur Bildung der Ergebnisgraphmuster

C.3. U¨ BERPRU¨ FUNG 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 G ^ P] T GP ) do 06: tmpSet:= T GP\ tgp 07: forall( tgp:=[ T GP, T G ^ P] tmpSet ) do 08: if(  iso: T GP iso T GP ) then 09: forall( T G ^ P T G ^ P ) do 10: if(  iso: iso| T GP = iso T G ^ P iso T GP ) then 11: if(  T G ^ P T G ^ P iso: iso - 1 | T GP = iso ( T G ^ P\( T GP\ iso( T GP))) 12: reducedSet:= reducedSet\ tgp 13: fi 14: fi 15: end 16: fi 17: end 18: end 19: return reducedSet 20: end iso T G ^ P ) then 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 Pushout iso 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 Anwendungsbedingung, 68 rechte Regelseite, 41, 65 Typkonformita¨t, 74 Vorbedingung, 41, 64 Graphtransformationssystem, 41, 69 erreichbare Zusta¨nde, 69 typisiertes Graphtransformationssystem, 80 typkonformes Graphtransformationssystem, 80 unendliches Graphtransformationssystem, 69 Graphtransitionssystem, 119 188

INDEX Identifikationsbedingung, 75 starke Identifikationsbedingung, 75 Informationsverarbeitung, 10 Invariante induktive Invariante, iii, 7, 44, 86 operationale Invariante, 44, 86 Komponente, 4, 11 beno¨tigte 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 Absichtserkla¨rung, 27 Instanzierungsregel, 27 Verhaltensregel, 27 Rolle, 27 Subkultur, 27 lose Kante, 75 ha¨ngende 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 189 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, 109 24, UML-Aktivita¨tendiagramm, 22 UML-Klassendiagramm, 13 UML-Objektdiagramm, 23 Unfall, 28 Zustandsautomat, 17 Protokoll-Zustandsautomat, 17 Verhaltens-Zustandsautomat, 17