Eine formale, graphbasierte Semantik für UML Statemachines · Semantik formalisiert werden, wodurch diese dann eindeutig interpretiert und somit auch maschinell analysiert werden

Eine formale, graphbasierte

Semantik für UML Statemachines

Diplomarbeit

Viktor Nesterow

12. Mai 2010

Gutachter:

Zweitgutachter:

Betreuer:

Prof. Dr. Gregor Engels

Prof. Dr. Heike Wehrheim

Dipl.-Inf. Christian Soltenborn

Universität Paderborn

Institut für Informatik

Fakultät für Elektrotechnik, Informatik und Mathematik

Fachgruppe Datenbank- und Informationssysteme

Inhaltsverzeichnis

1. Einleitung 11.1. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Aufbau der Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Einführung in UML Statemachines 52.1. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2. Notationselemente zur Modellierung von UML Statemachines . . . . 6

2.2.1. Einfacher Zustand . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3. Startzustand . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4. Endzustand . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.5. Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.6. Zusammengesetzter Zustand . . . . . . . . . . . . . . . . . . . 102.2.7. Orthogonaler Zustand . . . . . . . . . . . . . . . . . . . . . . 132.2.8. Pseudozustände . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3. Laufendes Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4. Semantic Variation Points . . . . . . . . . . . . . . . . . . . . . . . . 242.5. Nicht behandelte Sprachkonstrukte . . . . . . . . . . . . . . . . . . . 26

3. Dynamic Meta Modeling 273.1. Einführung in DMM . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2. Vom Metamodell zum Laufzeit-Metamodell . . . . . . . . . . . . . . 29

3.2.1. Erstellung eines Laufzeit-Metamodells durch Erweiterung desexistierenden Syntax-Metamodells . . . . . . . . . . . . . . . 30

3.3. Graphtransformationen . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.1. Überblick zu Graphtransformationen . . . . . . . . . . . . . . 323.3.2. Graphtransformationen bei DMM . . . . . . . . . . . . . . . . 33

3.4. Notationselemente bei DMM-Regeln . . . . . . . . . . . . . . . . . . 343.4.1. Elemente und deren Eigenschaften für die Erstellung von DMM-

Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.2. Typen von Regeln und deren Aufrufe . . . . . . . . . . . . . . 38

3.5. Werkzeuge zur Umsetzung von DMM . . . . . . . . . . . . . . . . . . 393.5.1. DMM-Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.2. Transformationstools . . . . . . . . . . . . . . . . . . . . . . . 40

4. DMM-Spezi�kation für UML Statemachines 414.1. Konzept zum Durchlaufen einer Statemachine . . . . . . . . . . . . . 41

i

Inhaltsverzeichnis

4.2. Laufzeit-Metamodell für UML Statemachines . . . . . . . . . . . . . 414.2.1. StateMachineExecution . . . . . . . . . . . . . . . . . . . . . 424.2.2. Marker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.3. HistoryMarker . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.4. RegionProperty . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.5. TransitionProperty . . . . . . . . . . . . . . . . . . . . . . . . 444.2.6. TransitionExecution . . . . . . . . . . . . . . . . . . . . . . . 44

4.3. Transformation einer UML Statemachine in eine Laufzeit-Statemachine 454.4. Regelsatz für UML Statemachines . . . . . . . . . . . . . . . . . . . . 46

4.4.1. Grundlegende Festlegungen zur Beschreibung des Verhaltenseiner UML Statemachine . . . . . . . . . . . . . . . . . . . . . 46

4.4.2. Grundlegende Regeln für UML Statemachines . . . . . . . . . 484.4.3. Regeln für Pseudozustände . . . . . . . . . . . . . . . . . . . 61

4.5. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5. Testen der erstellten DMM-Regeln 755.1. Testgetriebenes Konzept zur Spezi�kation einer Semantik . . . . . . 755.2. Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.2.1. Traces of execution events . . . . . . . . . . . . . . . . . . . . 775.2.2. CTL Generator . . . . . . . . . . . . . . . . . . . . . . . . . . 795.2.3. Testen der DMM-Regeln . . . . . . . . . . . . . . . . . . . . . 80

5.3. Testfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.3.1. Testen des laufenden Beispiels . . . . . . . . . . . . . . . . . . 815.3.2. Parallelität . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6. Zusammenfassung und Ausblick 876.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

A. Anhang 93

ii WS 2009/2010

Abbildungsverzeichnis

2.1. Package BehaviorStateMachines . . . . . . . . . . . . . . . . . . . . . 62.2. Standardnotation eines Zustands . . . . . . . . . . . . . . . . . . . . 72.3. Darstellung einer Transition . . . . . . . . . . . . . . . . . . . . . . . 82.4. Betreten eines zusammengesetzten Zustands mittels Default Entry . 112.5. Explizites Betreten eines zusammengesetzten Zustands . . . . . . . . 122.6. Verlassen eines zusammengesetzten Zustands . . . . . . . . . . . . . 122.7. Betreten eines orthogonalen Zustands mittels Default Entry . . . . . 132.8. Explizites Betreten eines orthogonalen Zustands . . . . . . . . . . . . 142.9. Verlassen eines orthogonalen Zustands . . . . . . . . . . . . . . . . . 152.10. Notation der Pseudozustände in UML Statemachines . . . . . . . . . 152.11. Pseudozustand Junction als static condition branch . . . . . . . . . . 162.12. Pseudozustand Choice als dynamic condition branch . . . . . . . . . 172.13. Betreten und Verlassen eines orthogonalen Zustands mittels Fork und

Join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.14. Pseudozustand Entry Point . . . . . . . . . . . . . . . . . . . . . . . 202.15. Pseudozustand Exit Point . . . . . . . . . . . . . . . . . . . . . . . . 202.16. Pseudozustand Shallow History . . . . . . . . . . . . . . . . . . . . . 212.17. Pseudozustand Deep History . . . . . . . . . . . . . . . . . . . . . . 222.18. Verlassen der Statemachine über ein Terminate . . . . . . . . . . . . 232.19. Modellierung der Abspielmodi eines Autoradios . . . . . . . . . . . . 242.20. Semantic Variation Point default entry rule . . . . . . . . . . . . . . 252.21. Behandlung des Semantic Variation Point default entry rule . . . . . 25

3.1. Ansatz der Technik Dynamic Meta Modeling . . . . . . . . . . . . . 283.2. Ausschnitt aus dem Laufzeit-Metamodell . . . . . . . . . . . . . . . . 303.3. Erweiterung des Syntax-Metamodells zu einem Laufzeit-Metamodell 313.4. Beispiel einer Graphtransformationsregel . . . . . . . . . . . . . . . . 333.5. Beispiel einer DMM-Regel . . . . . . . . . . . . . . . . . . . . . . . . 333.6. Quanti�kationen bei Knoten und Kanten . . . . . . . . . . . . . . . . 37

4.1. Laufzeit-Metamodell für UML Statemachines . . . . . . . . . . . . . 424.2. Bigstep-Regel startStatemachine()# . . . . . . . . . . . . . . . . . . 494.3. Smallstep-Regel enterInitialState() . . . . . . . . . . . . . . . . . . . 494.4. Smallstep-Regel createMarker() . . . . . . . . . . . . . . . . . . . . . 494.5. Bigstep-Regel �reTransition2()# . . . . . . . . . . . . . . . . . . . . 504.6. Verlassen und Betreten von verschachtelten Zuständen . . . . . . . . 514.7. Smallstep-Regel startExitingExecution1() . . . . . . . . . . . . . . . 52

iii

Abbildungsverzeichnis

4.8. Smallstep-Regel startExitingExecution2() . . . . . . . . . . . . . . . 534.9. Smallstep-Regel executeExitBehavior2(r,t) . . . . . . . . . . . . . . . 534.10. Smallstep-Regel executeExitBehavior8(r,t) . . . . . . . . . . . . . . . 544.11. Smallstep-Regel executeExitBehavior3(r,t) . . . . . . . . . . . . . . . 554.12. Smallstep-Regeln destroyMarkerInLeavedRegion(t) . . . . . . . . . . 554.13. Smallstep-Regel startTranstionExecution() . . . . . . . . . . . . . . . 564.14. Smallstep-Regel setMarkersOnTargetStateCon�guration(ns) . . . . . 574.15. Smallstep-Regel setStateCon�guration2(r) . . . . . . . . . . . . . . . 574.16. Smallstep-Regel setStateCon�guration3(r) . . . . . . . . . . . . . . . 584.17. Smallstep-Regel setStateCon�guration(r) . . . . . . . . . . . . . . . . 584.18. Smallstep-Regel executeState7() . . . . . . . . . . . . . . . . . . . . . 594.19. Smallstep-Regel executeState3() . . . . . . . . . . . . . . . . . . . . . 594.20. Smallstep-Regel �nishStateMachine() . . . . . . . . . . . . . . . . . . 604.21. Smallstep-Regeln executeState6() und executeState8() . . . . . . . . 624.22. Bigstep-Regel �reTransition1()# . . . . . . . . . . . . . . . . . . . . 624.23. Smallstep-Regel executeState9() . . . . . . . . . . . . . . . . . . . . . 634.24. Smallstep-Regel initializeTransitionExecution1() . . . . . . . . . . . . 634.25. Smallstep-Regel initializeTransitionExecution2() . . . . . . . . . . . . 644.26. Smallstep-Regel setStateCon�guration4() . . . . . . . . . . . . . . . 644.27. Smallstep-Regel setStateCon�guration5() . . . . . . . . . . . . . . . 654.28. Bigstep-Regel �reTransition5()# . . . . . . . . . . . . . . . . . . . . 664.29. Smallstep-Regel executeState12() . . . . . . . . . . . . . . . . . . . . 674.30. Smallstep-Regel enterRegionsOverEntryPoint() . . . . . . . . . . . . 674.31. Bigstep-Regel �reTransition4()# . . . . . . . . . . . . . . . . . . . . 684.32. Smallstep-Regel executeState13() . . . . . . . . . . . . . . . . . . . . 694.33. Smallstep-Regel initializeHistoryMarker1() . . . . . . . . . . . . . . . 694.34. Smallstep-Regel executeExitBehavior7() . . . . . . . . . . . . . . . . 694.35. Smallstep-Regel initializeHistoryMarker2() . . . . . . . . . . . . . . . 704.36. Smallstep-Regel executeState15() . . . . . . . . . . . . . . . . . . . . 714.37. Smallstep-Regel initializeHistoryMarkers1() . . . . . . . . . . . . . . 714.38. Smallstep-Regel initializeHistoryMarkers4() . . . . . . . . . . . . . . 724.39. Bigstep-Regel �reTransition6()# . . . . . . . . . . . . . . . . . . . . 734.40. Smallstep-Regel terminateStateMachine() . . . . . . . . . . . . . . . 73

5.1. Vergleich zwischen dem Testen von Software und einer Semantik-Spezi�kation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.2. Übersicht des Testablaufs . . . . . . . . . . . . . . . . . . . . . . . . 785.3. Ablauf der execution events . . . . . . . . . . . . . . . . . . . . . . . 795.4. Ermittlung des erwarteten Verhaltens im Transitionssystem . . . . . 805.5. Ausschnitt des Transitionssystems zum laufenden Beispiel . . . . . . 835.6. Transitionssystem zum laufenden Beispiel . . . . . . . . . . . . . . . 845.7. Parallelität im Transitionssystem . . . . . . . . . . . . . . . . . . . . 86

iv WS 2009/2010

1. Einleitung

Als die Menschheit laut biblischen Überlieferungen einst die gleiche Sprache sprach,hatte sie sich zum Ziel gesetzt ein groÿes Projekt umzusetzen, nämlich einen Turm zubauen, der bis zum Himmel reichen sollte. Doch als jenes höhere Wesen vom Himmelherabstieg, um das Vorhaben der Menschen sich anzusehen, erteilte es denen eineLektion, indem es ihre Sprache so verwirrte, dass sie einander nicht mehr verstanden.Daraufhin schlug das Turmbau-Projekt fehl, und die Turmbauer wurden über dieganze Welt verstreut.Die Geschichte macht klar, dass eine gemeinsame Sprache unverzichtbar ist, wenn

es darum geht, groÿe Projekte zu meistern, an denen sich viele Entwickler beteili-gen. Dies gilt nicht etwa nur für das Gebiet Bauwesen, sondern tri�t auf sämtlicheDisziplinen zu, an denen mehrere Teams an gemeinsamen Projekten arbeiten. So istes auch in der Welt der Softwareentwicklung nicht anders. Wenn Softwareentwickleraus verschiedenen Teams zusammentre�en, um z.B. die Schnittstellen der einzelnenModule des zu entwickelnden Softwareprodukts festzulegen, die zur Kommunikationunter diesen dienen sollen, so wird hier ebenfalls eine gemeinsame Sprache verwendet,die unabhängig von den konkreten Programmiersprachen zur Implementierung dereinzelnen Module ist. Die Uni�ed Modeling Language (UML) [7] ist heutzutage der defacto Standard für den objektorientierten Entwurf von komplexen Softwaresystemen.

Die UML ist eine von der Object Management Group (OMG) entwickelte undstandardisierte visuelle Modellierungssprache für die Modellierung von Softwaresys-temen.Die Modellierungskonzepte sind in UML in 13 Spracheinheiten (language units)

aufgeteilt. Eine Spracheinheit de�niert eine Menge von zusammenhängenden Model-lierungselementen, mit denen ein Benutzer eine ausgewählte Eigenschaft eines Sys-tems mit einem bestimmten Formalismus modellieren kann. Durch die SpracheinheitState Machines wird z.B. einem Modellierer ermöglicht, ein diskretes ereignisgesteu-ertes Verhalten zu spezi�zieren, welches sich durch den Formalismus von Statechartsdarstellen lässt.Jede Spracheinheit ist durch eine abstrakte Syntax und durch eine Semantik be-

schrieben. Die abstrakte Syntax ist durch ein Metamodell spezi�ziert und wird tech-nisch durch Klassendiagramme beschrieben und dargestellt. Die Semantik wird ineiner informellen textuellen Form beschrieben.Die informelle Beschreibung der Semantik bringt mehrere Nachteile mit sich. Durch

die textuelle Beschreibung ist die Semantik unpräzise de�niert, sodass ein Freiraumfür Interpretationen entsteht. Dies führt dazu, dass die Semantik von verschiedenenPersonen unterschiedlich gedeutet werden kann. Ein weiterer Nachteil ist, dass eine

1

Kapitel 1. Einleitung

textuell beschriebene Semantik eines UML-Modells nicht maschinell analysiert wer-den kann. Weitere Schwierigkeiten ergeben sich bei der Entwicklung von UML-Tools.Aufgrund des Freiraums für die Interpretation der Semantik sind die Modelle der un-terschiedlichen Hersteller oft zu einander nicht kompatibel und somit untereinandernicht austauschbar.Um die oben erwähnten Nachteile zu beseitigen, muss eine textuell beschriebene

Semantik formalisiert werden, wodurch diese dann eindeutig interpretiert und somitauch maschinell analysiert werden kann.

Eine Möglichkeit, die Semantik einer Modellierungsprache formal zu spezi�zie-ren bietet sich durch den Einsatz der Technik Dynamic Meta Modeling (DMM) [3].Durch den Einsatz von DMM wird es ermöglicht, die Semantik einer visuellen Mo-dellierungssprache, deren Syntax durch ein Metamodell gegeben ist, formal zu spezi-�zieren. Die Erstellung einer formalen Spezi�kation mit Hilfe von DMM besteht imwesentlichen aus folgenden zwei Teilen. Zuerst wird ein Laufzeit-Metamodell erstellt,welches das vorhandene Syntax-Metamodell um Elemente erweitert, die für die Aus-führung und die Semantik des Modells relevant sind. Der zweite Teil besteht auseinem Satz von Graphtransformationsregeln, die beschreiben, wie sich Instanzen desLaufzeit-Metamodells im Laufe der Zeit ändern. Somit de�nieren die Graphtrans-formationsregeln die Semantik der einzelnen Sprachelemente und werden über dasLaufzeit-Metamodell getypt, damit sie auf die Instanzen des Laufzeit-Metamodellsangewendet werden können.

Um die Graphtransformationsregeln auf Instanzen eines Laufzeit-Metamodells ma-schinell anwenden zu können, wird das Softwaretool GROOVE eingesetzt [8]. GROO-VE ist eine Toolsammlung für Graphtransformationen und Modelchecking, die es er-möglicht, aus einem Anfangsgraphen und Graphtransformationsregeln automatischein Transitionssystem zu erzeugen. Mit Hilfe der Graphtransformationsengine vonGROOVE werden die erstellten Regeln auf Instanzen des Laufzeit-Metamodells an-gewendet, wodurch ein Transitionssystem entsteht. Das erzeugte Transitionssystembeschreibt das gesamte Verhalten des zugehörigen Modells.

1.1. Zielsetzung

Ziel dieser Diplomarbeit ist es, für UML Statemachines eine formale Beschreibungder Semantik durch den Einsatz von Dynamic Meta Modeling zu entwickeln. Um eineSemantikspezi�kation mit Hilfe von DMM erstellen zu können, muss zunächst eineEinarbeitung in UML Statemachines, beschrieben in der UML-Spezi�kation, erfol-gen. Nach einer erfolgreichen Analyse der abstrakten Syntax und der Semantik vonUML Statemachines soll ein Konzept entwickelt werden, durch welches die Semantik,bestehend aus einem Laufzeit-Metamodell und einem DMM-Regelsatz, beschriebenwird.Des Weiteren muss eine Einarbeitung in DMM und die Werkzeuge, die DMM um-

2 WS 2009/2010


setzen, erfolgen. Für die Einarbeitung in DMM und in die Werkzeuge werden dieArbeiten von Hausmann [4] und Hornkamp [5] als Grundlage verwendet, in deneneine Semantik für UML Activities erstellt wurde.

Bei der Erstellung der formalen Semantik soll eine testgetriebene Vorgehensweiseverwendet werden (siehe auch [11]). Die Vorgehensweise legt im wesentlichen diefolgenden Schritte fest.Als Erstes muss die Semantik von UML-Statemachines verstanden und analysiert

werden. Im Laufe der Analyse werden Beispielmodelle erstellt, in denen einzelneSprachelemente zum Einsatz kommen. Dabei soll jedes Beispielmodell nach Möglich-keit so erstellt werden, dass es sich möglichst auf die Eigenschaften des untersuchtenSprachelements und dessen Bedeutung konzentriert. Für jedes Beispielmodell wirdein erwartetes Verhalten de�niert, welche die Semantik der in dem Beispielmodelluntersuchten Sprachelemente beschreibt.Ausgehend von den Beispielmodellen und dem zugehörigen erwarteten Verhalten

müssen nun ein Laufzeit-Metamodell und auf diesem basierend Graphtransforma-tionsregeln erstellt werden, durch die das erwartete Verhalten formal beschriebenwird. Das Verhalten jedes Beispielmodells wird somit durch eine Menge von Regelnbeschrieben. Die Regeln sollen mit Hilfe des DMM-Editors (entwickelt von Röhs [9])erstellt werden. Durch den DMM-Editor wird eine automatische Übersetzung derRegeln nach GROOVE ermöglicht.Um eine möglichst hohe Qualität der erstellten Regeln zu erreichen, müssen diese

über den gesamten Verlauf der Erstellung regelmäÿig evaluiert werden. Um die Re-geln zu evaluieren, werden das aktuelle Laufzeit-Metamodell und die vorher erstelltenBeispielmodelle verwendet. Für die Evaluierung werden Testfälle erstellt, in denendas erwartete Verhalten formell ausgedrückt wird. Dabei wird das Verhalten durchFormeln temporärer Logik beschrieben. Dadurch wird es ermöglicht, einen Testfallmit Hilfe eines Modelcheckers in dem für ein Beispielmodell erzeugten Transitions-system auf das erwartete Verhalten zu überprüfen.

Die auf diese Weise entstandene DMM-Semantikspezi�kation, bestehend aus ei-nem Laufzeit-Metamodell und einem Regelsatz, soll anschlieÿend in der schriftlichenAusarbeitung dokumentiert werden.

1.2. Aufbau der Diplomarbeit

In Kapitel 2 wird eine Einführung in UML Statemachines gegeben, in der die Syn-tax und insbesondere die Semantik anhand von konkreten Beispielen, dargestelltdurch Zustandsdiagramme, erläutert wird. In Kapitel 3 wird auf das Dynamic Me-

ta Modeling (DMM) eingegangen, um den Aufbau eines Laufzeit-Metamodells undder Graphtransformationsregeln besser nachvollziehen zu können. Dabei werden nurdie Elemente von DMM beschrieben, die in dieser Arbeit zum Einsatz kommen.Kapitel 4 beschreibt das in dieser Arbeit entwickelte Laufzeit-Metamodell und die

Universität Paderborn WS 2009/2010 3


Umsetzung der Graphtransformationsregeln, die die Semantik anhand des Marker-Konzepts de�nieren. Durch das Marker-Konzept wird eine kontrollierte Reihenfolgeder Abarbeitung des Verhaltens in einer UML Statemachine festgelegt, die durch dieUML-Spezi�kation vorgegeben ist. Um sicherstellen zu können, dass die erstelltenGraphtransformationsregeln auch die Semantik entsprechend der UML-Spezi�kation[7] widerspiegeln, müssen diese getestet werden. Kapitel 5 beschreibt den Aufbauund die Durchführung von Tests anhand von einigen Beispielmodellen. Anschlieÿendwird in Kapitel 6 eine Zusammenfassung über die vorliegende Arbeit gegeben.

4 WS 2009/2010

2. Einführung in UML Statemachines

In diesem Kapitel wird eine Einführung in UML State Machines gegeben. Abschnitt2.1 gibt einen kurzen Überblick über eine Aufteilung von UML Statemachines inzwei Arten. Abschnitt 2.2 beschreibt die Notation und Semantik der im Rahmendieser Arbeit untersuchten Sprachelemente von UML Statemachines. In Abschnitt2.3 wird ein laufendes Beispiel eingeführt, in dem einige der untersuchten Sprachele-mente verwendet werden. Die UML-Spezi�kation de�niert Bereiche, die sogenanntensemantic variation points, in denen die Semantik nicht eindeutig spezi�ziert ist. Beider Entwicklung der formalen Semantik in dieser Arbeit wurde ein für UML State-machines relevanter semantik variation point berücksichtigt, der in Abschnitt 2.4vorgestellt wird. Einige Sprachkonstrukte konnten aus Zeitgründen in dieser Arbeitnicht berücksichtigt werden. Diese werden in Abschnitt 2.5 kurz vorgestellt.

2.1. Überblick

UML Statemachines dienen zur Modellierung des Verhaltens eines Systems. DasVerhalten eines Systems wird durch Zustände, die es annehmen kann, und durchÜbergänge zwischen den Zuständen, die durch interne oder externe Ereignisse in-itiiert werden, modelliert. Eine UML Statemachine gibt somit die Antwort auf dieFrage: �Wie verhält sich das System in einem bestimmten Zustand bei bestimmtenEreignissen?� [10].

UML Statemachines werden in behavioral state machines und in protocol state

machines unterschieden. Bei den protocol state machines handelt es sich um eineSpezialisierung von behavioral state machines, bei der es darum geht die Nutzungvon Protokollen zu modellieren. Das Hauptmerkmal liegt dabei auf der Beschreibungder zulässigen Reihenfolgen von Operationsaufrufen.Behavioral state machines dienen zur Modellierung des Verhaltens eines Systems

oder eines Teils eines Systems. Zum Beispiel kann mit Hilfe von behavioral state ma-

chines das Verhalten eines Objekts modelliert werden. Dabei werden alle möglichen(endlichen) Zustände beschrieben, die das Objekt annehmen kann und wie das Ob-jekt als Ergebnis von Ereignissen die jeweiligen Zuständen erreicht. In der Abbildung2.1 ist das Syntax-Metamodell für behavioral state machines dargestellt, durch dasdie abstrakte Syntax für UML Statemachines festlegt ist.

Durch den beschränkten Zeitrahmen dieser Arbeit musste eine Entscheidung ge-tro�en werden, welcher von den oben erwähnten Bereichen von UML Statemachinesuntersucht werden soll. Im Rahmen dieser Arbeit wurde eine DMM-Spezi�kation

5

Kapitel 2. Einführung in UML Statemachines

für den Teil behavioral state machines erstellt. Der Grund für diese Entscheidungwar, dass der Bereich behavioral state machines eine allgemeinere Beschreibung vonUML Statemachines darstellt, in der auch mehr Sprachelemente verwendet werdenals dies bei den protocol state machines der Fall ist. Im Folgenden ist also bei derVerwendung des Begri�s UML Statemachines, immer der Bereich behavioral state

machines gemeint.

Abbildung 2.1.: Package BehaviorStateMachines (Quelle: [7])

Das in der Abbildung 2.1 dargestellte Klassendiagramm de�niert die abstrakteSyntax für UML Statemachines, die als Grundlage für die Erstellung einer DMM-Spezi�kation dient.

2.2. Notationselemente zur Modellierung von UMLStatemachines

Eine typische UML Statemachine besteht aus den Elementen Zustand, Pseudozu-stand und Transition. Diese Elemente sind jeweils in verschiedene Arten unterteilt.

6 WS 2009/2010


In diesem Abschnitt werden die Sprachelemente aus UML Statemachines beschrie-ben, deren Semantik in dieser Arbeit untersucht wurde, um für diese eine formaleSpezi�kation zu erstellen.

2.2.1. Einfacher Zustand

Ein einfacher Zustand (simple state) bildet eine Situation eines Systems ab, in derenVerlauf eine spezielle Bedingung gilt. Diese spezielle Bedingung wird gerade durchden Zustand und sein Verhalten beschrieben.In der Abbildung 2.2 ist ein Zustand vom Typ simple state mit den Eigenschaf-

ten, die er besitzen kann, dargestellt. Ein einfacher Zustand wird gra�sch durch einRechteck mit abgerundeten Ecken dargestellt. Der Name und die Eigenschaften einesZustands sind durch eine waagrechte Linie unterteilt.

Trigger [Guard] / Verhalten

exit / Verhaltenentry / Verhalten

do / Verhalten

Trigger [Guard] / defer

Zustandsname

Abbildung 2.2.: Standardnotation eines Zustands

Ein Zustand kann optional folgende Arten von Verhalten besitzen:

• entry behavior Sobald ein Zustand über eine Transition, die ihn als Zielbesitzt, betreten wird, wird sein Eintrittsverhalten ausgeführt.

• do behavior Nach dem das Eintrittsverhalten ausgeführt wurde wird die Aus-führung des Zustandsverhalten angestoÿen. Das Zustandsverhalten wird been-det indem es vollständig abgeschlossen wird, oder durch Verlassen des Zustandsunterbrochen.

• exit behavior Wird das Verlassen eines Zustands angestoÿen, so wird seinAustrittsverhalten ausgeführt.

2.2.1.1. Zustände allgemein

Die hier de�nierten Begri�e sind der UML Spezi�kation (aus [7]) entnommen wordenund sollen die grundsätzlichen Eigenschaften von Zuständen erläutern.

Aktiver Zustand Ein Zustand einer UML Statemachine kann während der Ausfüh-rung aktiv oder inaktiv sein. Ein Zustand wird aktiv, falls er über eine Transition,die diesen als Ziel enthält, betreten wird. Ein Zustand wird inaktiv, falls er über eineTransition, die diesen als Quelle enthält, verlassen wird.



Zustandsverhalten (do activity) Das Zustandsverhalten ist das Verhalten, dessenAusführung unmittelbar nach dem Beenden Eintrittsverhaltens angestoÿen wird. Istdas Zustandsverhalten abgeschlossen, so wird ein sogenanntes completion event aus-gelöst, welches als Trigger für eine triggerlose Transition fungiert. Falls von demZustand eine Transition ohne Trigger ausgeht, wird der Zustand über diese verlas-sen. Falls eine vom Zustand ausgehende, mit einem Trigger versehene Transitionfeuert, während im Quellzustand das Zustandsverhalten noch ausgeführt wird, sowird die Ausführung des Zustandsverhaltens abgebrochen und der Zustand über dieTransition verlassen.

2.2.2. Transition

Eine Transition dient einem Übergang von einem Zustand in den nächsten. Bei derAusführung einer Transition wird der Quellzustand verlassen (inaktiv) und der Ziel-zustand betreten (aktiv). Die Standard-Darstellung einer Transition ist eine durch-gezogene, gerichtete Kante, wie in Abbildung 2.3 dargestellt. Üblicherweise trägt eineTransition eine Beschriftung, die aus folgenden Elementen besteht:

• Trigger: der Auslöser für das Schalten einer Transition. Einer Transition könnenauch mehrere Trigger zugeordnet sein, welche dann durch Kommata vonein-ander getrennt werden. Die UML unterscheidet in Abhängigkeit vom Einsatz-zweck verschiedene Arten von Triggern. Da die unterschiedlichen Arten derTrigger bei der Erstellung der formalen Semantik in dieser Arbeit keine Bedeu-tung haben, wird hier ein Trigger allgemein als Auslöser für das Schalten einerTransition angesehen.

• Guard: eine Bedingung, die erfüllt sein muss, damit die Transition beim Auslö-sen des Triggers durchlaufen wird. Besitzt eine Transition sowohl einen Triggerals auch eine Bedingung, so wird beim Auftreten des Triggers die Transitionnur dann ausgeführt, wenn zu diesem Zeitpunkt die Bedingung erfüllt ist. Istdie Bedingung nicht erfüllt, so wird die Transition auch nicht durchlaufen. EineBedingung wird gra�sch durch eckige Klammern umschlossen.

• Verhalten: das Verhalten, das beim Durchlaufen der Transition ausgeführt wird.Nach Anstoÿ der Transition (d.h. der entsprechende Trigger ist eingetreten unddie Bedingung ist erfüllt) wird das an der Transition angetragene Verhaltenausgeführt.

Trigger [Guard] / Verhalten

Abbildung 2.3.: Darstellung einer Transition

8 WS 2009/2010


Schalten von Transitionen Eine Transition kann dann und nur dann schalten,wenn folgende Bedingungen erfüllt sind:

• Alle Quellzustände be�nden sich in einer aktiven Zustandskon�guration.

• Einer der zur Transition zugeordnete Trigger wird ausgelöst.

• Es existiert mindestens ein vollständiger Pfad zwischen der Quellen-Zustands-kon�guration und einer Ziel-Zustandskon�guration, bei dem die Bedingungen(Guards) erfüllt sind.

2.2.3. Startzustand

Ein Startzustand (in UML als initial vertex bezeichnet) bildet den Startpunkt fürdas Betreten einer UML Statemachine. Über die vom Startzustand ausgehende Tran-sition wird der erste Zustand der Statemachine erreicht. Die UML stellt folgendeEinschränkungen für einen Startzustand:

• Ein Startzustand darf höchstens eine ausgehende Transition haben.

• Eine von einem Startzustand ausgehende Transition kann ein Verhalten haben,darf aber keine Trigger oder Guards enthalten. Die UML Spezi�kation erlaubtjedoch für diese Transition einen create-Trigger, der für das Erzeugen des zumodellierenden Objekts zuständig ist (siehe [7], S.589, Constraint [8]).

Durch diese Einschränkungen wird sichergestellt, dass die von dem Startzustand aus-gehende Transition unmittelbar nach dem Starten einer UML Statemachine durch-laufen wird und der Zielzustand betreten wird. Ein Startzustand wird gra�sch durcheinen schwarz ausgefüllten Punkt dargestellt (siehe Abbildung 2.4).

2.2.4. Endzustand

Wird ein Endzustand (in UML als �nal state bezeichnet) betreten, so ist die Region,in der der Endzustand enthalten ist, abgearbeitet. Falls die Region eine direkte Re-gion der UML Statemachine ist, so ist mit dem Betreten des Endzustands in dieserRegion die Abarbeitung der UML Statemachine beendet. Folgende Einschränkungensind seitens der UML Spezi�kation für einen Endzustand gegeben:

• Ein Endzustand darf keinerlei Verhalten (entry-, do-, exit behavior) besitzen.

• Ein Endzustand darf keine ausgehende Transitionen haben.

Ein Endzustand wird gra�sch durch einen schwarzen ausgefüllten Kreis umrandetvon einem nicht ausgefüllten Kreis dargestellt (siehe Abbildung 2.4).



2.2.5. Region

Eine Region ist ein grundlegendes Element einer UML Statemachine oder eines zu-sammengesetzten oder orthogonalen Zustands. In der abstrakten Syntax (siehe Me-tamodell in Abbildung 2.1) wird eine Region als Container für Zustände, Pseudozu-stände und Transitionen de�niert. Dabei besteht eine UML Statemachine aus min-destens einer Region. In der konkreten Syntax wird eine Region durch eine Flächedargestellt, auf der sich die Zustände, Pseudozustände und Transitionen be�nden(siehe Abbildung 2.4).Für die Modellierung von parallelen Abläufen werden mehrere Regionen auf einer

�Ebene� verwendet, d.h. falls eine UML Statemachine oder ein Zustand aus mindes-tens zwei Regionen bestehen, so werden diese parallel abgearbeitet. Solche Regionenwerden als orthogonal bezeichnet. Ein Zustand, der aus mindestens zwei Regionen be-steht, wird dementsprechend als orthogonaler Zustand bezeichnet. In der konkretenSyntax werden orthogonale Regionen durch gestrichelte Linien von einander getrenntdargestellt (siehe Abbildung 2.7).In der UML Spezi�kation sind für die Verwendung von Regionen folgende Ein-

schränkungen festgelegt:

• Eine Region darf höchstens ein Startzustand enthalten.

• Eine Region darf höchstens ein Pseudozustand Shallow History enthalten.

• Eine Region darf höchstens ein Pseudozustand Deep History enthalten.

• Eine Region gehört entweder zu einer Statemachine oder zu einem Zustand

2.2.6. Zusammengesetzter Zustand

Ein zusammengesetzter Zustand (composite state) ist ein Zustand, der aus mindes-tens einer Region besteht, in der wiederum Zustände enthalten sind. Die in einemzusammengesetzten Zustand enthaltene Zustände werden als Unterzustände bezeich-net. Ein Unterzustand kann ein einfacher Zustand oder ein zusammengesetzter Zu-stand sein. Weitere Unterelemente eines zusammengesetzten Zustands sind die be-reits erwähnten Pseudozustände und Transitionen.In dem Beispiel in Abbildung 2.4 enthält der zusammengesetzte Zustand Compo-

site State einen Startzustand, Endzustand, zwei Transitionen und einen einfachenZustand A. Durch die Verschachtelung von Zuständen hat man die Möglichkeit, Ver-halten zu kapseln und die Lesbarkeit von UML Statemachines zu erhöhen. Die UMLSpezi�kation legt eine Reihenfolge fest für die Ausführung des Verhaltens beim Be-treten und Verlassen von zusammengesetzten (verschachtelten) Zuständen.Beim Betreten eines zusammengesetzten Zustands werden folgende zwei Fälle un-

terschieden:

• Default Entry: Falls eine Transition auf dem Rand eines zusammengesetztenZustands endet, so handelt es sich um ein Default Entry. Beim Betreten eines

10 WS 2009/2010


t1

t2

StartzuständeEndzustände

Regionen

Abbildung 2.4.: Betreten eines zusammengesetzten Zustands mittels Default Entry

zusammengesetzten Zustands mittels Default Entry wird zuerst das Eintritts-verhalten des Zustands ausgeführt und anschlieÿend wird in der Region des Zu-stands der Unterzustand, der direkt vom Startzustand erreichbar ist, betretenund sein Eintrittsverhalten ausgeführt. Falls der betretene Zustand wiederumein zusammengesetzter Zustand ist, so wird innerhalb dieses ebenfalls der überein Startzustand erreichbare Zustand betreten und sein Eintrittsverhalten aus-geführt. Dies wird rekursiv fortgesetzt, bis ein einfacher Zustand (simple State)betreten wird.

In Abbildung 2.4 wird der Zustand Composite State mittels Default Entry

betreten. Die Reihenfolge der Ausführung des Verhaltens ist folgende: Nachdem die triggerlose Transition, die den Zustand Composite State als Ziel hat,schaltet, wird als erstes das Verhalten (falls welches vorhanden) dieser Tran-sition ausgeführt. Danach wird der zusammengesetzte Zustand betreten. Hierwird als erstes das Eintrittsverhalten des Zustands Composite State ausgeführt.Danach wird innerhalb des zusammengesetzten Zustands die triggerlose Tran-sition ausgehend vom Startzustand, die den Zustand A als Ziel hat, ausgeführt.Anschlieÿend wird das Eintrittsverhalten des Zustands A ausgeführt.

• Explicit Entry: Wenn eine Transition von auÿen an einem Unterzustandendet, spricht man von einem Explicit Entry. Der Unterzustand wird aktivund bevor sein Eintrittsverhalten ausgeführt wird, wird das Eintrittsverherhal-ten des zusammengesetzten Zustands, der diesen enthält, ausgeführt. Hier giltebenfalls die rekursive Reihenfolge der Ausführung des Verhaltens.

In der Abbildung 2.5 wird der Zustand Composite State mittels Explicit Entrybetreten. Nach dem Schalten der vom Startzustand ausgehenden Transitionwird der Zustand Composite State betreten. Nach dem das Eintrittsverhaltenvon Composite State ausgeführt worden ist, wird das Eintrittsverhalten vonZustand A ausgeführt.



t1 t2

Abbildung 2.5.: Explizites Betreten eines zusammengesetzten Zustands

Ein zusammengesetzter Zustand kann auf drei unterschiedliche Arten verlassenwerden, die in der Abbildung 2.6 dargestellt werden.

• Erreichen des Endzustands: Innerhalb des zusammengesetzten Zustandswird der Endzustand erreicht. Nach dem Betreten des Endzustands wird eincompletion event erzeugt, welches als Trigger für die triggerlose Transitiongilt. Nach dem Schalten der triggerlosen Transition wird der zusammengesetzteZustand verlassen und der Zustand C betreten.

• Trigger für den zusammengesetzten Zustand: Eine Transition, die vomRand des zusammengesetzten Zustands ausgeht, wird ausgeführt. Währendder zusammengesetzte Zustand Composite State und einer der Zustände A, Boder der Endzustand aktiv sind, wird der Trigger t5 ausgelöst. Der ZustandComposite State wird verlassen (inaktiv) und der Zustand D betreten (aktiv).

• Trigger für einen Unterzustand: Eine Transition führt von einem Unterzu-stand aus dem zusammengesetzten Zustand heraus. Falls der Trigger t6 ausge-löst wird, während der Unterzustand B aktiv ist, so wird der zusammengesetzteZustand verlassen und der Zustand E betreten.

t2

t3 t5

t6

t7

t8

t9

Abbildung 2.6.: Verlassen eines zusammengesetzten Zustands

Das Verlassen eines zusammengesetzten Zustands löst eine Reihe von Austritts-verhalten aus. Sobald das Verlassen eines zusammengesetzten Zustands angestoÿen

12 WS 2009/2010


wird (durch Auslösen des entsprechenden Triggers einer ausgehenden Transition),wird das Austrittsverhalten in einer umgekehrten rekursiven Reihenfolge ausgeführt.Das heiÿt, dass als erstes das Austrittsverhalten eines aktiven einfachen Zustandsausgeführt wird. Danach das Austrittsverhalten des zusammengesetzten Zustandesauf der nächst höheren Ebene usw.

2.2.7. Orthogonaler Zustand

Falls ein zusammengesetzter Zustand mehr als eine Region besitzt, so wird dieser alsorthogonaler Zustand (orthogonal state) bezeichnet. Durch den Einsatz von ortho-gonalen Zuständen ist es möglich, parallele Abläufe zu modellieren. Falls ein ortho-gonaler Zustand aktiv ist, so ist in jeder Region ein Unterzustand aktiv. Im Folgen-den wird erklärt, auf welche Arten ein orthogonaler Zustand betreten und verlassenwerden kann und welche Reihenfolgen von Verhalten seitens der UML Spezi�kationfestgelegt sind.

• Default Entry: Eine Transition endet auf dem Rand des orthogonalen Zu-stands. Beim Betreten eines orthogonalen Zustands werden, nachdem dessenEintrittsverhalten ausgeführt wurde, in jeder Region die über die von den Start-zuständen aus erreichbaren Unterzustände betreten. Hier wird ebenfalls dasEintrittsverhalten rekursiv ausgeführt, bis ein einfacher Zustand in der jewei-ligen Region aktiv ist.

In der Abbildung 2.7 wird beim Betreten des Zustands Orthogonal State zuerstdessen Eintrittsverhalten ausgeführt und anschlieÿend werden die Zustände Aund B über die entsprechenden Transitionen betreten und deren Eintrittsver-halten parallel (gleichzeitig) ausgeführt.

t4

t5

t6

OrthogonaleRegionen

Abbildung 2.7.: Betreten eines orthogonalen Zustands mittels Default Entry

• Explicit Entry: Eine externe Transition endet auf dem Rand eines Unterzu-stands in einer der Regionen des orthogonalen Zustands. Nach dem die Transi-tion, die einen Unterzustand als Ziel hat, ausgeführt wurde, wird das Eintritts-verhalten des orthogonalen Zustands ausgeführt. Danach wird das Eintritts-



verhalten des Unterzustands, den die Transition als Ziel hat und gleichzeitig injeder weiteren orthogonalen Region das Eintrittsverhalten der Zustände aus-geführt, die über einen Startzustand erreichbar sind.

In der Abbildung 2.8 wird beim Betreten des Zustands Orthogonal State des-sen Eintrittsverhalten ausgeführt und anschlieÿend das Eintrittsverhalten derZustände A und B. Hier wird ebenfalls das Eintrittsverhalten der Zustände Aund B parallel (gleichzeitig) ausgeführt.

t2

t4

t5

Abbildung 2.8.: Explizites Betreten eines orthogonalen Zustands

Beim Verlassen eines orthogonalen Zustands werden folgende drei Fälle, die inAbbildung 2.9 dargestellt sind, unterschieden:

• Erreichen eines Endzustands in jeder Region: Innerhalb jeder orthogo-nalen Region des orthogonalen Zustands wird der Endzustand erreicht. Nachdem Betreten eines Endzustands in jeder Region wird ein completion event

erzeugt, welches als Trigger für die triggerlose Transition gilt. Nach dem Schal-ten der triggerlosen Transition wird der orthogonale Zustand verlassen und derZustand C betreten.

• Trigger für den orthogonalen Zustand: Eine Transition, die vom Randdes orthogonalen Zustands ausgeht, wird ausgeführt. Während der orthogonaleZustand Orthogonal State und seine Unterzustände A, und B aktiv sind, wirdder Trigger t5 ausgelöst. Der ZustandOrthogonal State wird verlassen (inaktiv)und der Zustand D betreten (aktiv).

• Trigger für einen Unterzustand: Eine Transition führt von einem Unter-zustand aus dem orthogonalen Zustand heraus. Falls der Trigger t8 ausgelöstwird, während der Unterzustand B aktiv ist und in der orthogonalen Regionder Zustand A oder der Endzustand aktiv ist, so wird der orthogonale Zustandverlassen und der Zustand E betreten.

Das Verlassen eines orthogonalen Zustands löst eine Reihe von Austrittsverhal-ten aus. Sobald das Verlassen eines orthogonalen Zustands angestoÿen wird (durch

14 WS 2009/2010


t4

t5t7

t8

t9

t10

t11

Abbildung 2.9.: Verlassen eines orthogonalen Zustands

auslösen des entsprechenden Triggers einer ausgehenden Transition), wird das Aus-trittsverhalten in einer umgekehrten rekursiver Reihenfolge ausgeführt. Das heiÿt,dass als erstes in jeder Region das Austrittsverhalten eines aktiven einfachen Zu-stands ausgeführt wird. Danach das Austrittsverhalten des orthogonalen Zustandesauf der nächst höheren Ebene usw. Falls die orthogonalen Regionen unterschiedlicheVerschachtelungstiefen besitzen, so wird beim Verlassen des orthogonalen Zustandszuerst das Austrittsverhalten eines einfachen Unterzustands in der tiefsten Ebene(Region) ausgeführt. Das Austrittsverhalten von Zuständen in orthogonalen Regio-nen auf gleicher Verschachtelungstiefe wird parallel (gleichzeitig) ausgeführt.

2.2.8. Pseudozustände

In diesem Abschnitt werden die Notation und Semantik für die unterschiedlichenArten von Pseudozuständen beschrieben, die durch die UML Spezi�kation [7] fest-gelegt sind. Die UML de�niert Pseudozustände, um komplexe Beziehungen zwischenZuständen übersichtlicher darzustellen. Dies wird dadurch realisiert, dass Transitio-nen nicht nur zwischen Zuständen modelliert werden, sondern auch über einen odermehrere Pseudozustände gehen dürfen.

Abbildung 2.10.: Notation der Pseudozustände in UML Statemachines

In der Abbildung 2.10 sind die zehn Arten von Pseudozuständen dargestellt, die bei



UML Statemachines zum Einsatz kommen. Der Pseudozustand Initial wurde bereitsin Abschnitt 2.2.3 eingeführt. Im Folgenden werden die Semantik und Verwendungder restlichen Pseudozustände erläutert.

2.2.8.1. Junction

Ein Pseudozustand der Art Junction wird gra�sch durch einen ausgefüllten Kreisdargestellt (siehe Abbildung 2.10). Durch die Verwendung von Junctions hat mandie Möglichkeit, verschiedene Transitionen ohne verbindende Zustände hintereinan-der zu schalten. Dabei kann ein Pseudozustand Junction mehrere eingehende undausgehende Transitionen haben.In der Abbildung 2.11 dient der Pseudozustand Junction dazu, die eingehende

Transition auf zwei ausgehende Transitionen zu verzweigen. Falls der Trigger t2 aus-gelöst wird, während der Zustand A aktiv ist, wird zuerst überprüft, ob eine derBedingungen an der vom Junction ausgehenden Transitionen erfüllt ist. In dem dar-gestellten Beispiel wird immer beim Auslösen des Triggers t2 aus dem Zustand A

der Zustand C betreten. Das heiÿt dass bei Verwendung von Junctions der Pfad vorder Ausführung der ersten Transition festgelegt wird. In dem Beispiel wird in demZustand A der Variable x der Wert 1 zugewiesen. Beim Auslösen des Triggers t2 istalso die Bedingung x>=0 erfüllt und somit wird nach dem Ausführen der Transition(x:=-1) der Zustand C betreten.

t2

t5

t6

Abbildung 2.11.: Pseudozustand Junction als static condition branch

Bei der Benutzung von Junctions kann an genau einer ausgehenden Transitioneine Bedingung mit dem Schlüssel else als Wahrheitswert verwendet werden, diedann gültig ist, wenn an allen anderen ausgehenden Transitionen die Bedingungennicht gültig sind. Ein Pseudozustand Junction wird auch als static condition branch

(siehe [7], S. 542, junction) bezeichnet. Die UML Spezi�kation schreibt vor, dassbezogen auf die gesamte Statemachine, ein Pseudozustand Junction mindestens eineeingehende und eine ausgehende Transition besitzen muss.

2.2.8.2. Choice

Der Pseudozustand Choice wird bei UML Statemachines gra�sch als eine nicht ausge-füllte Raute dargestellt (siehe Abbildung 2.10). Die Verwendung des Pseudozustands

16 WS 2009/2010


Choice bietet die Möglichkeit Abzweigstellen zu modellieren, bei denen die Auswahlder auszuführenden Transitionen vom Ergebnis der auf dem Weg zum Choice be-reits ausgeführten Aktionen abhängt. Transitionspfade, die durch ein Choice gehen,werden in der UML Spezi�kation als dynamic condition branch bezeichnet.Das Beispiel in Abbildung 2.12 veranschaulicht die Verwendung eines dynamic

condition branch. Während der Zustand A aktiv ist, wird der Variable x der Wert1 zugewiesen. Wird nun der Trigger t2 ausgelöst, so schaltet die vom Zustand A

ausgehende Transition und durch das an der Transition angetragene Verhalten wirdder Variable x der Wert -1 zugewiesen. Nach dem die Transition ausgeführt wurde,werden nun an den vom Choice ausgehenden Transitionen die entsprechenden Bedin-gungen ausgewertet. In diesem Fall ist die Bedingung x<0 wahr und somit wechseltdie UML Statemachine in den Zustand B.

t2

t5

t6

Abbildung 2.12.: Pseudozustand Choice als dynamic condition branch

Bei der Verwendung von Choices ist darauf zu achten, dass wenn ein Choice be-treten wird, es immer einen gültigen Pfad zu einem Zielzustand geben muss. Fallsdiese Voraussetzung nicht gegeben ist, so wird das Modell laut UML als fehlerhaftbezeichnet. Um diesen Fall zu vermeiden, emp�ehlt die UML die Verwendung einerBedingung mit dem Schlüsselwort else an einer der vom Pseudozustand Choice aus-gehenden Transitionen. Die UML Spezi�kation schreibt vor, dass bezogen auf diegesamte Statemachine, muss ein Pseudozustand Choice mindestens eine eingehendeund eine ausgehende Transition besitzen.Die Verwendung der Pseudozustände Junction und Choice ermöglicht es, soge-

nannte Transitionsverbunde (compound transitions) zu modellieren. In einem Transi-tionsverbund können mehrere Transitionen zusammengeführt werden oder aber aucheine Transition auf mehrere aufgespalten werden. Bei der Verwendung von Junctionsoder Choices, darf auf einem eindeutigen Pfad in dem einer der beiden Pseudozu-stände enthalten ist, höchstens eine Transition einen Trigger enthalten.

2.2.8.3. Fork

Ein Fork wird gra�sch durch einen vertikalen Balken (siehe Abbildung 2.10) darge-stellt. Der Pseudozustand Fork dient dazu, um eine eingehende Transition in mehrereausgehende Transitionen aufzuspalten, deren Zielzustände sich in unterschiedlichen



orthogonalen Regionen be�nden. Somit wird ein Fork ausschlieÿlich für die Model-lierung von parallelen Abläufen verwendet.In der UML Spezi�kation sind für die Verwendung des Pseudozustands Fork fol-

gende Einschränkungen festgelegt:

• Bezogen auf die gesamte Statemachine muss ein Pseudozustand Fork genaueine eingehende und mindestens zwei ausgehende Transitionen besitzen.

• Alle ausgehenden Transition enden in Zuständen unterschiedlicher Regioneneines orthogonalen Zustands.

• Die ausgehenden Transitionen dürfen weder Trigger noch Bedingungen besit-zen. Diese Einschränkung stellt sicher, dass alle Ziel-Regionen gleichzeitig be-treten werden.

• Eine ausgehende Transition endet immer in einem Zustand.

• Regionen des orthogonalen Zustands, die nicht über eine vom Fork ausgehendeTransition betreten werden, müssen einen Startzustand enthalten, damit siebeim Betreten des orthogonalen Zustands ebenfalls aktiv werden.

In Abbildung 2.13 wird ein Pseudozustand Fork verwendet, um den Zustand Or-

thogonalState zu betreten und die parallele Abarbeitung der Regionen anzustoÿen.Nach dem Schalten der Transition t0 wird das an den vom Fork ausgehenden Tran-

sitionen angetragene Verhalten a1 und a2 parallel ausgeführt und anschlieÿend derZustand OrthogonalState betreten. Die Ausführungsreihenfolge des Verhaltens derZustände ist hier analog wie bereits in Abschnitt 2.2.7 für das Betreten eines ortho-gonalen Zustands beschrieben wurde. Das heiÿt in diesem Beispiel wird nach demSchalten der Transitionen t1 und t2 als Erstes das Eintrittsverhalten des ZustandsOrthogonalState ausgeführt. Danach wird das Eintrittsverhalten der Zustände State1und State2 parallel ausgeführt.

t0

t1/a1

t2/a2 t4/a4

t3/a3

t5

Abbildung 2.13.: Betreten und Verlassen eines orthogonalen Zustands mittels Forkund Join

18 WS 2009/2010


Die Bezeichner (t1, t2) der vom Pseudozustand Fork ausgehenden Transitionenwerden hier lediglich zur Kennzeichnung der Transitionen verwendet und stellen keineTrigger dar.

2.2.8.4. Join

Ein Join wird gra�sch durch einen vertikalen Balken (siehe Abbildung 2.10) darge-stellt. Der Pseudozustand Join dient dazu, um die von unterschiedlichen orthogona-len Regionen ausgehenden Transitionen zu einer Transition zu bündeln. Somit wirdein Join ausschlieÿlich für die Modellierung zum Beenden von parallelen Abläufenverwendet.In der UML Spezi�kation sind für die Verwendung des Pseudozustands Join fol-

gende Einschränkungen festgelegt:

• Bezogen auf die gesamte Statemachine, muss ein Pseudozustand Join mindes-tens zwei eingehende und genau eine ausgehende Transition besitzen.

• Alle eingehenden Transitionen müssen ihre Ursprung in unterschiedlichen Re-gionen eines orthogonalen Zustands haben.

• Die eingehenden Transitionen dürfen weder Trigger noch Bedingungen besit-zen. Diese Einschränkung stellt sicher, dass alle Quell-Regionen gleichzeitigverlassen werden.

• Eine eingehende Transition hat immer einen Zustand als Quelle.

In der Abbildung 2.13 wird ein Pseudozustand Join verwendet, um die paralleleAbarbeitung der Zustände State3 und State4 gleichzeitig zu beenden. Beim Ver-lassen eines orthogonalen Zustands über einen Join wird das Austrittsverhalten ineiner umgekehrten rekursiven Reihenfolge ausgeführt. Falls der Trigger t5 ausgelöstwird, während die Zustände State3 und State4 aktiv sind, so wird gleichzeitig dasAustrittsverhalten der beiden Zuständen angestoÿen und ausgeführt. Nach dem dasAustrittsverhalten von State3 und State4 ausgeführt worden ist, wird das Austritts-verhalten des Zustands OrthogonalState ausgeführt. Danach wird das Verhalten a3

und a4 der in den Pseudozustand Join eingehenden Transitionen parallel ausgeführtund schlieÿlich durch das Schalten der Transition t5 der Endzustand betreten.

2.2.8.5. Entry Point

Ein Pseudozustand Entry Point wird gra�sch durch einen nicht ausgefüllten Kreis(siehe Abbildung 2.10) dargestellt. Ein Entry Point wird zum Betreten von State-machines oder zusammengesetzten Zuständen verwendet. Dabei werden die externenTransitionen, die den Entry Point als Ziel haben, mit den internen Transitionen, dieden Entry Point als Quelle haben, verbunden. Falls eine Statemachine oder ein zu-sammengesetzter Zustand bestehend aus mehreren orthogonalen Regionen über einEntry Point betreten wird, so wird jede dieser Regionen über eine vom Entry Point



/action1 t3 t4/action2

Abbildung 2.14.: Betreten eines zusammengesetzten Zustands über ein Pseudozu-stand Entry Point

ausgehende Transition betreten. Der Hauptzweck bei der Verwendung von Entry

Points liegt darin, dass das Eintrittsverhalten des zu betretenen Zustands zwischender Ausführung des Verhaltens der Transitionen, die durch den Entry Point verbun-den werden, ausgeführt wird. In der Abbildung 2.14 wird der Zustand Composite

State über einen Entry Point betreten. Zuerst wird das Verhalten action1 an derin den Entry Point eingehenden Transition ausgeführt. Dann wird das Eintrittsver-halten von Composite State ausgeführt. Danach wird das Verhalten action2 an derausgehenden Transition ausgeführt und schlieÿlich der Zustand A betreten.

2.2.8.6. Exit Point

Ein Pseudozustand Exit Point wird gra�sch durch einen nicht ausgefüllten Kreis, inden ein Kreuz eingezeichnet ist (siehe Abbildung 2.10), dargestellt. Ein Exit Point

bietet eine Möglichkeit, das Verlassen einer Statemachine oder eines zusammenge-setzten Zustands zu modellieren. Dabei werden die internen Transitionen, die denExit Point als Ziel haben mit den externen Transitionen, die den Exit Point als Quellehaben, verbunden. Der Hauptzweck bei der Verwendung von Exit Points liegt darin,dass das Austrittsverhalten des zu verlassenden Zustands zwischen der Ausführungdes Verhaltens der Transitionen, die durch den Exit Point verbunden werden, aus-geführt wird.

/action1 t2/action2

Abbildung 2.15.: Verlassen eines zusammengesetzten Zustands über den Pseudozu-stand Exit Point

20 WS 2009/2010


In der Abbildung 2.15 wird der Zustand Composite State über ein Exit Point

verlassen. Falls der Trigger t2 ausgelöst wird, während der Zustand A aktiv ist,so wird das Austrittsverhalten des zusammengesetzten Zustands angestoÿen. Zuerstwird das Austrittsverhalten von Zustand A ausgeführt. Dann wird das Verhaltenaction1 an der in den Exit Point eingehenden Transition ausgeführt. Danach wirddas Austrittsverhalten des Zustands Composite State, gefolgt von dem Verhaltenaction2 an der ausgehenden Transition des Exit Points ausgeführt.

2.2.8.7. Shallow History

Ein Pseudozustand Shallow History wird gra�sch durch einen nicht ausgefülltenKreis mit dem Buchstaben H (siehe Abbildung 2.10) dargestellt. Mit einem Shallow

History hat man die Möglichkeit, beim Betreten eines zusammengesetzten Zustandsoder eines Unterzustandsautomaten einen Unterzustand, der als erster aktiv werdensoll, dynamisch zu bestimmen. Das bedeutet, dass beim Verlassen eines zusammen-gesetzten Zustands der Shallow History sich den zuletzt aktiven Unterzustand merkt,sodass beim erneuten Betreten des zusammengesetzten Zustands der vermerkte Un-terzustand als erster aktiv wird. Falls der zusammengesetzte Zustand zum ersten malbetreten wird, so wird der �Standardzustand� als erster aktiv. Als Standardzustandist der Unterzustand gemeint, den die vom Shallow History ausgehende Transitionals Ziel hat.In der Abbildung 2.16 ist ein Beispiel für die Verwendung eines Pseudozustands

Shallow History dargestellt. Falls der zusammengesetzte Zustand zum ersten mal be-treten wird, so wird nach dem Ausführen des Eintrittsverhaltens von Process BCH

das Eintrittsverhalten von Zustand B ausgeführt. Nach dem der zusammengesetz-te Zustand über die Transition t5 verlassen wird, merkt der Shallow History sichden Zustand C als den zuletzt aktiven Zustand der umgebenen Region. Bei einemerneuten Betreten des zusammengesetzten Zustands wird nun nach der Ausführungdes Eintrittsverhaltens von Process BCH das Eintrittsverhalten vom UnterzustandC ausgeführt.

t2

t5t4 t6

Abbildung 2.16.: Betreten eines zusammengesetzten Zustands über den Pseudozu-stand Shallow History



Die UML Spezi�kation legt folgende Einschränkungen für history Pseudozuständefest:

• Ein history Pseudozustand kann höchstens eine ausgehende Transition haben.

• Falls ein zusammengesetzter Zustand beim ersten Betreten über einen Shallow

History betreten wird, so muss von dem history Pseudozustand eine ausge-hende Transition existieren, die den Zustand festlegt, der beim erstmaligenBetreten aktiv werden soll.

2.2.8.8. Deep History

Ein Pseudozustand Deep History wird gra�sch durch einen nicht ausgefüllten Kreismit dem Buchstaben H∗ (siehe Abbildung 2.10) dargestellt. Alle Eigenschaften, dieim vorigen Unterabschnitt für den Pseudozustand Shallow History vorgestellt wur-den, gelten auch für einen Deep History. Ein weitere Eigenschaft des PseudozustandsDeep History ist, dass dieser sich nicht nur den zuletzt aktiven Unterzustand merkt,sondern auch alle zuletzt aktiven Unterzustände der Unterzustande (falls solche exis-tieren).In der Abbildung 2.17 soll diese Eigenschaft, die einen Deep History von einem

Shallow History unterscheidet, verdeutlicht werden. Wird der zusammengesetzte Zu-stand Process BCH zum ersten mal betreten, so wird der Zustand B nach demAusführen des Eintrittsverhaltens von Process BCH aktiv.

t2

t4 t6 t7 t8

Abbildung 2.17.: Betreten eines zusammengesetzten Zustands über den Pseudozu-stand Deep History

Beim Verlassen von Process BCH sind der zusammengesetzte Zustand Process C

und einer seiner Unterzustände C1 oder C2 die zuletzt aktiven Zustände. Wird nunder Zustand Process BCH erneut betreten, so wird nach dessen Eintrittsverhalten dasEintrittsverhalten von Process C ausgeführt und schlieÿlich das Eintrittsverhaltendes zuletzt aktiven Unterzustands (C1 oder C2) von Process C.Falls in dem Beispiel in Abbildung 2.17 anstatt des Deep History ein Shallow

History verwendet wäre, so wäre beim Verlassen nur der Zustand Process C als

22 WS 2009/2010


zuletzt aktiver Zustand vermerkt worden. Das heiÿt, dass ein Shallow History sichnur den direkten Unterzustand eines zusammengesetzten Zustands als den zuletztaktiven Zustand vermerkt.

2.2.8.9. Terminate

Der Pseudozustand Terminate wird gra�sch durch ein Kreuz dargestellt und kannbei der Modellierung in einer Statemachine verwendet werden, um die Ausführungder Statemachine abzubrechen. Eine Statemachine kann entweder mit dem Betreteneines Pseudozustands Terminate oder durch Erreichen eines entsprechenden Endzu-stands beendet werden. Der Unterschied zum Beenden einer Statemachine über einTerminate besteht darin, dass in diesem Fall keinerlei Austrittsverhalten der aktivenZustände ausgeführt wird, nach dem eine Transition schaltet, die ein Terminate alsZiel besitzt.In Abbildung 2.18 sind zwei Möglichkeiten modelliert, um die dargestellte Statema-

chine zu beenden. Falls der Trigger t2 ausgelöst wird, während der Zustand B aktivist, so wird als erstes das Austrittsverhalten von Zustand B ausgeführt. Danach wirddas an der Transition angebrachte Verhalten action2 ausgeführt und schlieÿlich dieStatemachine beendet. Falls der Trigger t3 ausgelöst wird, während der Zustand A

aktiv ist, so wird unmittelbar nach dem Auslösen des Triggers das Verhalten action3

ausgeführt und die Statemachine beendet.

t1

t3/action3

t2/action2

Abbildung 2.18.: Verlassen der Statemachine über ein Terminate

2.3. Laufendes Beispiel

Wie im vorigen Abschnitt bereits erwähnt wurde, dienen UML Statemachines da-zu, um das Verhalten eines Systems oder eines Teilsystems zu modellieren. In derAbbildung 2.19 wird das Verhalten der Abspielmodi eines Autoradios modelliert.Nach dem das Autoradio eingeschaltet wird, schaltet es in den Radiobetrieb, falls

keine CD eingelegt ist. Falls jedoch eine CD eingelegt ist, wechselt das Autoradiobeim Einschalten in den CD-Betrieb. Während eine CD abgespielt wird, kann durchDrücken der Taste �Radio� in den Radiobetrieb umgeschaltet werden. Umgekehrtkann, während das Autoradio sich im Modus �Radiobetrieb� be�ndet, durch dasDrücken der Taste �CD� (bei eingelegter CD) in den CD-Betrieb gewechselt werden.



AM-FM /

AM-FM /

Taste FM /

Taste FM /

[CD eingelegt]

[CD nicht eingelegt]

Taste CD [CD eingelegt] /

Taste Ein /

Taste Aus /

Taste Aus /

Taste Radio /

Abbildung 2.19.: Modellierung der Abspielmodi eines Autoradios

Während der Radiobetrieb aktiv ist, wird eine der drei Radio-Frequenzen AM,FM1 oder FM2 empfangen. Durch die Tasten �AM/FM� und �FM� kann zwischenden entsprechenden Frequenzen umgeschaltet werden. Bei einem erneuten Wechsel inden Radiobetrieb wird automatisch die zuletzt abgespielte Radiofrequenz empfangen.

2.4. Semantic Variation Points

Mit Semantic Variation Points werden in der UML Spezi�kation Stellen bezeichnet,die Freiräume für unterschiedliche Interpretationen bzw. Verfeinerungen bieten. Indiesem Abschnitt wird ein semantic variation point vorgestellt, der beim Betreteneines zusammengesetzten Zustands in einer bestimmten Situation gilt (siehe auch[7], S. 551).

Betreten eines zusammengesetzten Zustands, dessen Region keinen Startzustandenthält Falls eine Transition auf den Rand eines zusammengesetzten Zustands zeigt(siehe Abbildung 2.20), dessen Region keinen Startzustand enthält, so kann dieserFall laut UML-Spezi�kation [7] auf zwei unterschiedliche Weisen interpretiert werden.In dem Fall, wo ein Startzustand pro Region vorausgesetzt wird, wird dieses

Beispiel-Modell als fehlerhaft interpretiert.Eine alternative Interpretation für diesen Fall ist, dass beim Schalten der Transiti-

on t2, der zusammengesetzte Zustand betreten wird, ohne die enthaltenen Regionenoder deren Unterzustände zu betreten. In diesem Fall wird also nur das Verhaltenvon Composite State ausgeführt.

Da eine formale Semantik eindeutig sein muss, d.h. keinen Freiraum für Interpre-tationen bieten darf, muss an dieser Stelle eine Entscheidung getro�en werden, wiedieser Fall behandelt werden soll. Bei der in dieser Arbeit entwickelten Semantik

24 WS 2009/2010


t2

t3

t4

t5 t6 t7

Abbildung 2.20.: Semantic Variation Point default entry rule

sind zusammengesetzte Zustände mit Regionen ohne Anfangszustände unzulässig.Um aber dennoch die Möglichkeit zu bieten, einen zusammengesetzten Zustand, des-sen Regionen keinen Anfangszustand enthalten, zu betreten, ohne die Zustände dieserRegionen zu betreten, kann dieser Fall wie in Abbildung 2.21 dargestellt modelliertwerden.

t1

t3entered over t1

t4 [true]

t5 [false]

t2

t6 t7

Abbildung 2.21.: Behandlung des Semantic Variation Point default entry rule

An dem Pseudozustand Choice wird abgefragt, ob der zusammengesetzte Zustandüber die Transition t1 betreten wurde. Falls dies der Fall ist, so wird über die Tran-sition t4 der Endzustand der Region betreten, ohne die Ausführung jeglichen Ver-haltens innerhalb dieser Region. Falls der zusammengesetzte Zustand nicht über dieTransition t1 betreten wurde, so schaltet die Transition t5 und das für die Regionvorgesehene Verhalten wird ausgeführt.



2.5. Nicht behandelte Sprachkonstrukte

Aufgrund des beschränkten Zeitrahmens wurden bei der Erstellung der formalenSemantik einige Sprachkonstrukte nicht behandelt. Diese werden im folgendem auf-gelistet und kurz erläutert.

Comletion Event Ein completion event fungiert als Trigger für eine triggerloseTransition. Falls ein Zustand eine ausgehende triggerlose Transition besitzt, so wirddurch das Auslösen eines completion events durch den Zustand, dieser über die trig-gerlose Transition verlassen.

Ein completion event wird in folgenden Fällen ausgelöst:

• Abgeschlossenes Zustandsverhalten eines einfachen Zustands: Sobald in einemeinfachen Zustand das Zustandsverhalten (do-Behavior) ausgeführt worden ist,wird ein completion event ausgelöst.

• Erreichen eines Endzustands innerhalb der Regionen eines zusammengesetz-

ten Zustands: Falls innerhalb der Region eines zusammengesetzten Zustandein Endzustand erreicht worden ist, so ist die Abarbeitung dieser Region abge-schlossen. Bei einem einfachen zusammengesetzten Zustand (Zustand mit einerRegion) wird in diesem Fall ein completion event ausgelöst. Im Falle eines or-thogonalen Zustands muss in jeder der orthogonalen Regionen ein Endzustanderreicht werden, damit ein completion event ausgelöst wird.

Zustandsübergänge durch lokale Transitionen Eine lokale Transition hat einenzusammengesetzten Zustand als Quelle und einen Unterzustand oder Pseudozustandinnerhalb des zusammengesetzten Zustands als Ziel. Falls eine lokale Transition schal-tet, so wird in dem Quellzustand kein Austrittsverhalten ausgeführt (da der Quell-zustand nicht verlassen wird), falls solches vorhanden ist.

Variationen des Betretens von orthogonalen Zuständen Falls ein orthogonalerZustand über einen Pseudozustand Fork oder Entry Point betreten wird, so wirdlaut UML Spezi�kation gefordert, dass alle orthogonalen Regionen, die nicht übereinen von den oben erwähnten Pseudozuständen ausgehenden Transitionen betretenwerden, einen Startzustand enthalten müssen, über den diese Regionen dann betretenwerden.

Betreten und Verlassen von Submachine States Eine Statemachine kann Sub-

machine States enthalten, deren Aufgabe es ist, eine Statemachine innerhalb einerStatemachine aufzurufen. Das heiÿt, dass beim Betreten eines Zustands SubmachineState die Statemachine auf die dieser verweist, betreten und abgearbeitet wird.Durch die Verwendung von Submachine States hat man die Möglichkeit Verhalten

zu kapseln, um dieses wiederzuverwenden.

26 WS 2009/2010

3. Dynamic Meta Modeling

Es existieren verschiedene Techniken um die Semantik einer visuellen Modellierungs-sprache formal zu spezi�zieren. Das π-Kalkül ist zum Beispiel ein sehr mächtigerFormalismus, mit dessen Hilfe man die Semantik einer visuellen Modellierungsspra-che spezi�zieren kann. Ein Nachteil des π-Kalküls ist dessen Komplexität, derenBeherrschung ein hohes Hintegrundwissen erfordert, um dieses zu Formalisierungeiner Semantik zu verwenden. Für einen durchschnittlichen Benutzer einer Modellie-rungssprache ist dieses Wissen nicht gegeben.In dieser Arbeit wurde die Technik Dynamic Meta Modeling (DMM) verwendet,

um eine formale Semantik für UML Statemachines zu spezi�zieren. Die Verwendungvon DMM setzt voraus, dass die Syntax der zu spezi�zierenden Modellierungssprachedurch ein Metamodell de�niert ist. DMM ist somit für einen Benutzer, der mit objekt-orientierten Konzepten (Klassendiagramme, Objektdiagramme) vertraut ist, leichtnachvollziehbar. Um mit Hilfe von DMM eine Semantik zu spezi�zieren, muss derBenutzer der Sprache lediglich, das zu Grunde liegende Syntax-Metamodell und diezugehörige (textuell beschriebene) Semantik kennen. Ein weiterer Vorteil von DMMist, dass eine durch DMM formalisierte Semantik durch Modelchecking-Technikenmaschinell analysiert werden kann.In diesem Kapitel wird die Technik DMM allgemein vorgestellt, und die Schritte

erläutert, die notwendig sind um eine Semantik formal zu spezi�zieren. In Abschnitt3.1 wird eine kurze allgemeine Einführung zu DMM (aus [4]) gegeben, in der derAnsatz von DMM erläutert wird. Danach werden in Abschnitt 3.2 der Übergangvom Syntax-Metamodell zum Laufzeit-Metamodell erklärt und in Abschnitt 3.3 dieverschiedenen Techniken zur Graphtransformation vorgestellt. Abschnitt 3.4 erklärtden Aufbau und die zur Verfügung stehende Möglichkeiten für die Erstellung vonDMM-Regeln.Um den Ansatz von DMM besser zu verstehen, wird dieser durch ein konkretes

Beispiel veranschaulicht. In Abbildung 3.2 ist Ausschnitt aus dem konkreten Laufzeit-Metamodell und in Abbildung 3.5 eine Regel aus dem Regelsatz dargestellt. Einedetaillierte Beschreibung der Spezi�kation der Semantik für UML Statemachineswird in Kapitel 4 vorgestellt.

3.1. Einführung in DMM

Durch den Einsatz von DMM wird es ermöglicht, die Semantik einer visuellen Model-lierungssprache, deren Syntax durch ein Metamodell gegeben ist, formal zu spezi�zie-ren. In Abbildung 3.1 wird der DMM-Ansatz dargestellt, der veranschaulichen soll,

27

Kapitel 3. Dynamic Meta Modeling

wie eine formale Spezi�kation für eine visuelle Modellierungssprache erstellt wird.

Syntaxmetamodel

Syntax Definition

Runtime metamodel

DMMRuleset

semanticmapping

typedover

Semantics Definition / DMM Specification

Expression

Model

conforms to

Runtime metamodel

Transition System

conforms to conforms to conforms to

S1

S3

S2

S4

...

...

Abbildung 3.1.: Ansatz der Technik Dynamic Meta Modeling (nach Hornkamp [5])

Die Erstellung einer formalen Spezi�kation mit Hilfe von DMM besteht im we-sentlichen aus den folgenden zwei Teilen.

• Laufzeit-Metamodell Zuerst wird ein Laufzeit-Metamodell erstellt, welchesdas vorhandene Syntax-Metamodell um Elemente erweitert, die für die Aus-führung und die Semantik des Modells relevant sind. Ein Laufzeit-Metamodellwird konkret durch ein Klassendiagramm de�niert, in dem alle vorkommen-den Elemente zur Beschreibung der Syntax und der statischen Semantik durchtypisierte Klassen und Assoziationen festgelegt sind. Eine Instanz des Laufzeit-Metamodells entspricht dann einer Objektstruktur, die durch ein Objektdia-gramm beschrieben werden kann und hier als Laufzeit-Modell bezeichnet wird.Eine Instanz des Laufzeit-Metamodells für UML Statemachines, wird in dieserArbeit als Laufzeit-Statemachine bezeichnet.

• DMM-Regelsatz Der zweite Teil besteht aus einem Satz von Graphtrans-formationsregeln (in der Abbildung 3.1 als DMM Ruleset bezeichnet), die be-schreiben, wie sich Instanzen des Laufzeit-Metamodells im Laufe der Zeit än-dern. Eine Graphtransformationsregel beschreibt ein bestimmtes Objektmusterund legt fest welche Änderungen auf diesem Objektmuster vorgenommen wer-den sollten. Eine Regel aus dem Regelsatz für UML Statemachines könnte zumBeispiel Bedingungen festlegen, die erfüllt sein müssen, um dann Änderungendurchzuführen, die in einer Laufzeit-Statemachine der Ausführung des Verhal-tens eines Zustands entsprechen.

Das Laufzeit-Metamodell und der DMM-Regelsatz bilden zusammen eine formaleSpezi�kation für die Semantik einer Modellierungssprache.

28 WS 2009/2010


Die Abbildung des Syntax-Metamodells auf das Laufzeit-Metamodell (in Abbil-dung 3.1 als semantic mapping bezeichnet) ermöglicht es, aus einem Modell einLaufzeit-Modell zu erstellen.Durch die Anwendung der Graphtransformationsregeln auf ein Laufzeit-Modell

bekommt man ein Transitionssystem. Ein Transitionssystem besteht aus Zuständenund Transitionen (siehe Abbildung 3.1). Jede Transition in dem Transitionssystementspricht der Anwendung einer Regel auf das Laufzeit-Modell. Jeder Zustand indem Transitionssystem entspricht einem Zustand des Laufzeit-Modells, in den dasLaufzeit-Modell durch die Anwendung einer Regel versetzt wurde.Ein Laufzeit-Modell kann allgemein als ein Eingabegraph für das Transitionssys-

tem angesehen werden, d.h. es bildet den Anfangszustand in einem Transitionssys-tem. Nun werden auf das Laufzeit-Modell Graphtransformationsregeln angewandt,falls die Bedingungen, die die jeweiligen Regeln voraussetzen, in dem aktuellen Zu-stand des Laufzeit-Modells gegeben sind. Sind die Bedingungen einer Regel erfüllt,so wird diese auf das Laufzeit-Modell angewendet und führt somit zu einer Zustands-änderung. Der Regelsatz mit den Graphtransformationen sorgt also dafür, dass je-de Zustandsänderung des Laufzeit-Modells zur Laufzeit in einem Transitionssystemdurch Zustände und Transitionen repräsentiert werden. Das erzeugte Transitionssys-tem beschreibt das gesamte Verhalten des zugehörigen Modells. Wie genau solcheGraphtransformationsregeln aussehen und welche Arten es davon gibt, wird in Ab-schnitt 3.3 vorgestellt.In den folgenden zwei Abschnitten werden das Laufzeit-Metamodell und die Graph-

transformationsregeln, die zusammen eine DMM Spezi�kation bilden, anhand vonkonkreten Beispielen genauer erläutert.

3.2. Vom Metamodell zum Laufzeit-Metamodell

Wie im vorigen Abschnitt bereits erwähnt wurde, muss für eine formale Spezi�ka-tion einer visuellen Modellierungssprache das vorliegende Syntax-Metamodell umElemente erweitert werden, die für die Beschreibung der Semantik notwendig sind.Um ein besseres Verständnis für ein Laufzeit-Metamodell zu bekommen, ist in Ab-

bildung 3.2 ein kleiner Ausschnitt aus dem Laufzeit-Metamodell dargestellt, welchesin dieser Arbeit für UML Statemachines entwickelt wurde.

Die mit einer gestrichelten Umrandung dargestellten Klassen repräsentieren einenTeil des Syntax-Metamodells aus der Spezi�kation [7] von UML Statemachines. Klas-sen mit einer durchgezogenen Umrandung repräsentieren einen Teil aus der Mengeder Elemente, um die das Syntax-Metamodell erweitert wurde.Die Klasse StateMachineExecution ist durch die Assoziation executes mit der Klas-

se StateMachine verbunden. Wie aus der Bezeichnung der Assoziation zu erkennenist, dient die Klasse StateMachineExecution der Ausführung einer Statemachine. EineStatemachine besteht aus mindestens einer Region, welche wiederum Elemente vomTyp Vertex enthält. Die Klasse Marker ist über eine Komposition mit der Klasse



StateMachineExecution StateMachine Region

VertexMarker

executes

1

*

0..1 1..*

*

0..1

contained_in0..1 1

marker

region

subvertex

Abbildung 3.2.: Ausschnitt aus dem Laufzeit-Metamodell

StateMachineExecution und durch eine Assoziation contained_inmit der Klasse Ver-tex verbunden. Ein Marker dient dazu, um den Ablauf der Ausführung des Verhaltensder einzelnen Zustände und Transitionen in einer Statemachine zu kontrollieren.Das Syntax-Metamodell für UML Statemachines wird somit um die Elemente

StateMachineExecution und Marker erweitert, um die Semantik formal zu beschrei-ben. Die neu hinzugekommenen Elemente zusammen mit den bereits vorhandenenElementen des Syntax-Metamodells bilden das Laufzeit-Metamodell. Das vollständi-ge Laufzeit-Metamodell für UML Statemachines wird in Kapitel 4.2 vorgestellt.

3.2.1. Erstellung eines Laufzeit-Metamodells durch Erweiterung desexistierenden Syntax-Metamodells

Es gibt zwei Möglichkeiten aus einem Syntax-Metamodell ein Laufzeit-Metamodellzu erstellen.Erstellen eines Metamodells, welches Elemente zur Laufzeit-Information und Ele-

mente aus dem Syntax-Metamodell enthält. Diese Variante eignet sich gut, falls nurein kleiner Teil der Elemente aus einem umfangreichen Syntax-Metamodell in dasMetamodell mit der Laufzeit-Information aufgenommen werden muss. Falls jedochein Groÿteil der Elemente aus dem Syntax-Metamodell in das Laufzeit-Metamodellaufgenommen werden muss, ist die Verwendung dieser Variante nachteilhaft, da hiereine hohe Redundanz entsteht. Da diese Variante in dieser Arbeit nicht angewandtwurde, wird auf sie hier nicht näher eingegangen. Eine detailliertere Beschreibungwird in der Arbeit von Markus Hornkamp [5] anhand eines kleines Beispiels zu UMLActivities vorgestellt.Bei der zweiten Variante sind in dem Metamodell zur Laufzeit-Information nur

die neu hinzugekommenen Elemente vorhanden. Man hat somit zwei Metamodel-le, das Original-Metamodell zur Beschreibung der Syntax und das Metamodell mitder Laufzeit-Information. Zusammen bilden diese beiden Metamodelle ein Laufzeit-Metamodell. In der Abbildung 3.3 ist ein Ausschnitt aus dem Laufzeit-Metamodellfür UML Statemachines dargestellt, das in dieser Arbeit entwickelt wurde. Man siehtlinks einen Ausschnitt aus dem Syntax-Metamodell für UML Statemachines undrechts einen Ausschnitt des Metamodells mit Elementen zur Laufzeit-Information.

30 WS 2009/2010


Das Syntax-Metamodell wird somit um die Elemente zur Laufzeit-Information zueinem Laufzeit-Metamodell erweitert.

Um eine Erweiterung des Syntax-Metamodells zu einem Laufzeit-Metamodell zurealisieren, müssen das Syntax-Metamodell und das Metamodell mit der Laufzeit-Information miteinander verbunden werden. Die Verbindung der beiden Metamodelleist in der Abbildung 3.3 durch die Assoziationen executes und contained_in gra�schdargestellt.

Region

StateMachine

Transition

1

*region

0..1

Vertex

*

subvertex

1

*transition

StateMachineExecution

1

*marker


Marker

1

*

transitionExecution

TransitionExecution

1

*

contained_in

executes

executes

Metamodell: Syntax Metamodell: Laufzeitinformation

0..10..1

Laufzeit-Metamodell

Abbildung 3.3.: Erweiterung des Syntax-Metamodells zu einem Laufzeit-Metamodell

Die Verbindung d.h. sämtliche Assoziationen zwischen dem Syntax-Metamodellund dem Metamodell mit der Laufzeit-Information ist auf Meta-Ebene durch dasEclipse-Plugin EMF realisiert. Um diesen Assoziationen die gewünschten Eigenschaf-ten zu Verscha�en, sind diese durch eine Implementierung in Java realisiert, die inKapitel 4.3 genauer erläutert wird.

Durch die Umsetzung der Assoziationen zwischen den oben beschriebenen Meta-modellen in einer Java-Implementierung, ist es nun möglich aus einer Instanz desSyntax-Metamodells (in diesem Fall aus einer UML Statemachine), eine Instanz desLaufzeit-Metamodells (Laufzeit-Statemachine) zu erzeugen.

Durch die Anwendung des DMM-Regelsatzes auf ein Laufzeit-Modell entsteht einTransitionssystem, welches zu Beginn dieses Kapitels in Abbildung 3.1 bereits vor-gestellt wurde.



3.3. Graphtransformationen

In diesem Abschnitt werden die Graphtransformationen vorgestellt, die unter DMMals DMM-Regelsatz bezeichnet werden. Wie bereits zu Beginn dieses Kapitels er-wähnt wurde, bildet der DMM-Regelsatz den zweiten Teil des DMM-Ansatzes. DieMenge von Regeln beschreibt das dynamische Verhalten eins Laufzeit-Modells wäh-rend der Ausführung. Um ein besseres Verständnis über Graphtransformationen zubekommen, wird im folgenden Abschnitt zuerst eine allgemeine Beschreibung zurGraphtransformationsregeln gegeben und in dem darauf folgenden Abschnitt anhandeines konkreten Beispiels der Aufbau einer DMM-Regel erklärt.

3.3.1. Überblick zu Graphtransformationen

Eine Graphtransformation ist - wie das Wort schon besagt - eine Transformation einesGraphen. Es existieren verschiedene Ansätze zur Graphtransformation (vgl. [1]). Inden Ansätzen werden Regeln benutzt, um einen Ursprungsgraphen oder Anfangsgra-phen, in einen neuen Graphen zu transformieren. Bei DMM dient ein Laufzeit-Modellals Eingabegraph, der dann durch einen Satz von Graphtransformationsregeln wäh-rend der Ausführung verändert (transformiert) wird.In Abbildung 3.4 ist ein Beispiel für eine allgemeine Graphtransformationsregel

dargestellt. Eine Regel besteht aus einer linken Seite L und einer rechten Seite R,wobei beide Seiten jeweils einen Graphen oder Teil-Graphen darstellen. Die Kno-ten und Kanten in einer Regel sind getypt, sodass diese immer einem bestimmtenKnoten-Typen oder Kanten-Typen aus dem Laufzeit-Metamodell entsprechen. EineRegel �matcht�, falls der Graph der linken Seite L in dem Eingabegraph vorhandenist. In diesem Fall kann die Transformation in dem Eingabegraph vorgenommen wer-den, sodass der entsprechende Teilgraph im Eingabegraph durch die Seite R ersetztwird. Elemente, die in L vorkommen und in R nicht vorkommen, werden aus demEingabegraphen gelöscht. Elemente die in R vorkommen, und in L nicht vorkommen,werden dem Eingabegraphen hinzugefügt. In dem Beispiel in der Abbildung 3.4 wirdein Graph G durch die Anwendung einer Regel in einen Graph G' transformiert. DerTeilgraph L bestehend aus den Elementen A,B,C,D, der durch die Regel vorgegebenist, wird im Graph G gefunden und der Graph G wird in den Graph G' transformiert,indem das Element D entfernt wird.

Zwei weitere Ansätze werden von DMM unterstützt: Negative Application Condi-

tions (NACs) und Universally Quanti�ed Structures (UQS). Bei NAC hat man dieMöglichkeit, in einer Regel Elemente zu de�nieren, die in einem Eigabegraphen nichtvorkommen dürfen, damit die Regel angewendet werden kann. Das UQS-Verfahrenbietet die Möglichkeit, Elemente als �beliebig oft vorkommend� zu de�nieren, wo-durch sich weitere unterschiedliche Möglichkeiten ergeben, eine Regel zu beschreiben.Die hier erwähnten Ansätze wurden in dieser Arbeit zur Erstellung von DMM-

Regeln eingesetzt und sind in einigen Regeln, die in Kapitel 4 vorgestellt werden,anzutre�en.

32 WS 2009/2010


Abbildung 3.4.: Beispiel einer Graphtransformationsregel (nach Hausmann [4])

3.3.2. Graphtransformationen bei DMM

Wie bereits erwähnt dient ein Laufzeit-Modell bei DMM als Eingabegraph, auf dendann die DMM-Regeln angewendet werden, um den Graphen zu transformieren undsomit das Verhalten des Laufzeit-Modells zur Laufzeit zu beschreiben. Um eine au-tomatische Ausführung der DMM-Regeln zu ermöglichen, werden diese über dasLaufzeit-Metamodell getypt (siehe Abbildung 3.1 ).In Abbildung 3.5 ist der Aufbau einer DMM-Regel anhand einer konkreten Regel

aus dem DMM-Regelsatz für UML Statemachines dargestellt, der in dieser Arbeitentwickelt wurde. Eine Regel besteht aus Knoten und Kanten. Die Knoten reprä-sentieren Objekte, die Instanzen von Klassen sind, und die Kanten repräsentierendie Beziehungen zwischen den Objekten. Da ein Laufzeit-Modell eine Instanz desLaufzeit-Metamodells ist und die DMM-Regeln über das Laufzeit-Metamodell ge-typt werden, können diese auf ein Laufzeit-Modell angewendet werden.

Abbildung 3.5.: Beispiel einer DMM-Regel



Eine Regel de�niert also erstens ein Objekt-Muster (linke Seite L einer Graph-transformation), das in dem Laufzeit-Modell vorhanden sein muss, damit die Regelangewendet werden kann. Zweitens legt eine Regel fest, welche Änderungen an demzutre�endem Objekt-Muster bei der Ausführung der Regel vorgenommen werden sol-len (rechte Seite R einer Graphtransformation). Bei DMM werden sowohl die linkeSeite L als auch die rechte Seite R einer Regel durch ein Objekt-Muster beschrieben,bei dem die einzelnen Knoten und Kanten mit bestimmten Rollen versehen werden.Die Rollen der einzelnen Elemente legen fest, ob ein Element vorhanden, gelöschtoder neu hinzugefügt werden soll. In der Abbildung 3.5 müssen bis auf die grü-ne Kante alle Elemente (Knoten und Kanten) in einem Laufzeit-Modell vorhandensein, damit die Regel angewendet werden kann. Bei der Ausführung der Regel wirddann der Knoten marker vom Knoten source zum Knoten target bewegt, indem dierote Kante gelöscht und die grüne Kante hinzugefügt wird.

3.4. Notationselemente bei DMM-Regeln

In diesem Abschnitt werden die Eigenschaften von DMM-Regeln näher beschrieben,die bei der Erstellung des Regelsatzes für UML Statemachines verwendet wurden.

3.4.1. Elemente und deren Eigenschaften für die Erstellung vonDMM-Regeln

Eine typische DMM-Regel besteht im wesentlichen aus den Elementen Knoten undKante.

Knoten Ein Knoten wird gra�sch durch ein Rechteck dargestellt und repräsentiertein Objekt, dass eine Instanz einer Klasse aus dem Laufzeit-Metamodell darstellt.

Kante Eine Kante wird gra�sch durch ein gerichtete Kante dargestellt und reprä-sentiert eine Beziehung zwischen zwei Objekten, die der Assoziation zwischen zweiKlassen des Laufzeit-Metamodells entspricht.

3.4.1.1. Rollen von Knoten und Kanten

Die Knoten und Kanten können bei DMM-Regeln mit vier unterschiedlichen Rollenversehen werden.

• exists Die am häu�gsten vorkommende Rolle für ein Element ist die Rolleexists. Dies bedeutet, wie der Name schon besagt, dass die in einer Regel mitexists gekennzeichnete Elemente in dem untersuchten Laufzeit-Modell vorhan-den sein müssen, damit die Regel angewendet werden kann. Die Elemente mitder Rolle exists werden gra�sch in schwarzer Farbe darstellt (Knoten durch

34 WS 2009/2010


eine schwarze Umrandung und Kanten durch schwarze Pfeile). In der Abbil-dung 3.5 besitzen alle Knoten und die Kanten source, target und execute dieexists-Rolle.

• not exists Diese Rolle bildet die Negation zu der Rolle exists. Falls eine Re-gel Elemente mit dieser Rolle besitzt, so dürfen in dem Laufzeit-Modell dieentsprechenden Elemente nicht vorhanden sein, damit diese Regel angewendetwerden kann. Ein Element mit einer not exists-Rolle wird gra�sch wie bei derRolle exists in schwarzer Farbe dargestellt und zusätzlich mit einem allgemei-nen Verbotszeichen1 gekennzeichnet.

• destroy Elemente mit dieser Rolle müssen in dem Laufzeit-Modell vorhandensein, damit eine Regel, in der diese Elemente enthalten sind, ausgeführt werdenkann. Die Ausführung so einer Regel sorgt dafür, dass die mit der destroy-Rollegekennzeichnete Elemente in dem Laufzeit-Modell gelöscht werden. Bei einemKnoten mit einer destroy-Rolle wird der Knoten und die mit ihm verbundenenKanten gelöscht. Bei einer Kante mit einer destroy-Rolle wird nur die Kantegelöscht. Ein Element mit dieser Rolle wird gra�sch in roter Farbe dargestellt.In der Abbildung 3.5 besitzt die Kante contained_in zwischen den Knotensource und marker die destroy-Rolle.

• create Das Gegenteil zum destroy bildet die Rolle create. Für jedes Element(Knoten, Kante) mit dieser Rolle wird bei der Anwendung der Regel ein korre-spondierendes Element in dem Laufzeit-Modell erzeugt. Bei einem Knoten miteiner create-Rolle werden die ein- und ausgehenden Kanten ebenfalls mit derRolle create versehen. Elemente mit dieser Rolle werden gra�sch in grüner Far-be dargestellt. In der Abbildung 3.5 besitzt die Kante contained_in zwischenden Knoten target und marker die create-Rolle.

3.4.1.2. Quanti�kationen bei Knoten und Kanten

Eine weitere Eigenschaft von Knoten und Kanten bei der Erstellung von Regeln istdas Setzen von Quanti�kationen. Durch das Setzen von Quanti�kationen hat mandie Möglichkeit, die Häu�gkeit von Elementen durch eine untere und obere Grenzefestzulegen.

a) 1 Die meist verwendete Quanti�kation ist 1, die sowohl eine obere als auch eineuntere Grenze für die Häu�gkeit eines Elements angibt. Ein Knoten mit dieserQuanti�kation �matcht� mit genau einem korrespondierendem Objekt in ei-nem Laufzeit-Modell. Falls eine Kante die Quanti�kation 1 besitzt, so bedeutetdies, dass zwei Objekte im Laufzeit-Modell über eine Kante direkt verbundensein müssen, damit die Regel �matcht�. Bei Knoten mit einer Quanti�kation 1werden die Ränder durch durchgezogene Linien dargestellt. Bei Kanten sind

1Ein Verbotszeichen entsprechend der BGV A8 P00



dementsprechend die Kanten durch durchgezogene Linien dargestellt. In derAbbildung 3.5 besitzen alle Knoten und Kanten die Quanti�kation 1.

b) 1..* Bei Elementen mit dieser Quanti�kation-Angabe muss in dem Laufzeit-Modell mindestens ein korrespondierendes Objekt oder beliebig viele vorhan-den sein. In der Abbildung 3.6 ist unter Fall 2) der Knoten B mit dieser Quanti-�kation versehen. Die durchgezogene Umrandung bedeutet, es muss mindestensein korrespondierendes Objekt in dem Laufzeit-Modell vorhanden sein. Die zu-sätzliche punktierte Umrandung soll verdeutlichen, dass mehrere Objekte vomKnoten B im Laufzeit-Modell vorkommen dürfen. Falls diese Quanti�kation beiKanten verwendet wird, so bedeutet dies für die über die Kante verbundenenKnoten, dass diese entweder direkt über eine Kante verbunden sein können,oder aber auch indirekt über mehrere Kanten miteinander verbunden sein kön-nen (siehe Fall 3 in Abbildung 3.6).

c) 0..* Besitzt ein Element diese Quanti�kation-Angabe, so muss in dem Laufzeit-Modell ein korrespondierendes Objekt nicht vorhanden sein, und es dürfenaber auch beliebig viele vorkommen. In der Abbildung 3.6 ist unter Fall 1)der Knoten B mit der Quanti�kation 0..* versehen. Diese Quanti�kation wirdgra�sch durch punktierte Umrandungen von zwei hintereinander stehendenRechtecken dargestellt.

d) nested Ein Knoten mit einer Quanti�kation nested trägt die Bedeutung �fürjeden�. Diese Quanti�kation wird in Kombination mit den Quanti�kationen 0..*und 1..* verwendet. In der Abbildung 3.6 ist unter Fall 2) der Knoten A mitder Quanti�kation nested versehen. Die in dem Beispiel dargestellte Teil einerRegel besagt, dass jeder Knoten vom Typ B mit einem Knoten vom Typ Averbunden sein muss. Ein Knoten mit der Quanti�kation nested wird gra�schdurch ein gestrichelt umrandetes Rechteck dargestellt.

Elemente mit den Quanti�kationen 1..* oder 0..* werden als Universally Quan-

ti�ed Structures (UQS) bezeichnet. Falls mehrere über Kanten verbundene Knotenmit einem UQS der gleichen Sorte versehen sind, so bilden diese zusammen einenUQS-Cluster. Ein UQS-Cluster bestehend aus Knoten mit der Quanti�kation 0..*kann nicht mit einem UQS-Cluster bestehend aus Knoten mit der Quanti�kation1..* zu einem neuen UQS-Cluster gebildet werden. Zwei UQS-Cluster der gleichenQuanti�kation können hingegen zu einem neuen UQS-Cluster verbunden werden.

3.4.1.3. Attribute

Eine weitere sehr nützliche Eigenschaft, die von DMM unterstützt wird, ist dieVerwendung von Attributen bei Knoten (siehe auch [2]). Die in einem Laufzeit-Metamodell enthaltenen Klassen können Attribute besitzen und somit können dieseAttribute in den Objekten eines Laufzeit-Modells verwendet werden. Falls in denKnoten einer Regel Attribute verwendet werden, so müssen die Attribut-Werte in

36 WS 2009/2010


A B A B

B

B

A Ba a

...

Ea...or:

matches:

A B Amatches:1)

2)

Quantifier: 1 Quantifier: 0..*

Quantifier: nested Quantifier: 1..*

A Ea A a Ematches:3)

Abbildung 3.6.: Quanti�kationen bei Knoten und Kanten (nach Hornkamp [5])

den Konten der Regel mit den Attribut-Werten der korrespondierenden Objekte imLaufzeit-Modell übereinstimmen, damit die Regel matcht. Bei dem Ausführen derRegel können dann die Werte der Attribute in den entsprechenden Objekten desLaufzeit-Modells verändert werden. In der Abbildung 3.5 besitzt der Knoten Tran-

sitionExecution ein Attribut namens transitionExecuted. In dem Beispiel wird beiVorhandensein des in der Regel beschriebenes Objekt-Musters im Laufzeit-Modellzusätzlich der Wert des Attributs durch die Bedingung transitionExecuted==true

abgefragt. Falls die Bedingung erfüllt ist, wird beim Ausführen der Regel in demLaufzeit-Modell dem Attribut durch eine Wertzuweisung transitionExecuted':=falseder Wert false zugewiesen.

3.4.1.4. EmphasizedAttribute

Bei der Erzeugung eines Transitionssystems unter GROOVE werden die Transitio-nen mit den Namen der angewendeten Regeln beschriftet, damit es möglich ist dieangewendeten Regeln zu identi�zieren. Bei mehreren gleichen Objekt-Mustern wirdeine passende Regel für jedes dieser Objekt-Muster angewendet. Um nun bei derAnwendung einer Regel erkennen zu können auf welchem Objekt-Muster die Regelausgeführt wurde, wird in einem Knoten des Objekt-Musters, welches in der Regelde�niert ist, ein Attribut als EmphasizedAttribute gesetzt. Hier wird üblicherweiseein Attribut gewählt durch dessen Wert das das Attribut enthaltene Objekt eindeutigidenti�ziert werden kann. Die Regel createMarker() in Abbildung 4.4 de�niert z.B. indem Knoten Vertex das Attribut name als EmphasizedAttribute. In einem Transiti-onssystem wird nun bei der Anwendung der Regel createMarker() in den Klammernder Name des entsprechenden Knoten mit angegeben (siehe Abbildung 5.5). Hier seidarauf hingewiesen, dass in einem Laufzeit-Modell bei allen Knoten vom Typ Ver-



tex das Attribut name einen Wert enthalten sollte, durch den der Knoten in demgesamten Laufzeit-Modell eindeutig identi�ziert werden kann.

3.4.2. Typen von Regeln und deren Aufrufe

Eine DMM-Regel besitzt immer genau einen Knoten, der als Kontext-Knoten mar-kiert ist. Dieser Knoten kann wie ein Objekt in der objektorientierten Program-mierung angesehen werden, welches eine bestimmte Eigenschaft aufweist. Die Ei-genschaft dieses Objekts wird in einer Regel durch die mit dem Kontext-Knotenverbundenen Knoten und Kanten beschrieben. Technisch gesehen entspricht jederKnoten in einer Regel einem getypten Objekt aus dem Laufzeit-Metamodell. Dasals Kontext-Knoten markierte Objekt in einer Regel, dient also als Anker, welcher ineinem Laufzeit-Modell nach einem korrespondierendem Objekt sucht, um mit diesemverankert zu werden. Ein Kontext-Knoten wird in einer Regel gra�sch durch eine fetteUmrandung dargestellt. In der Abbildung 3.5 ist der Knoten vom Typ Transition alsKontext-Knoten markiert. Das bedeutet, dass diese Regel im Laufzeit-Modell jedesObjekt vom Typ Transition darauf untersucht, ob das ihn umgebene Objekt-Mustermit der gesamten Regel übereinstimmt.Ein weiterer Mechanismus bei DMM ist der Aufruf von Regeln, der als invoca-

tion bezeichnet wird. Eine invocation trägt den Namen der Regel, die aufgerufenwerden soll, und wird immer auf einem Knoten innerhalb einer Regel aufgerufen.Dieser Knoten wird für die invocation als Ziel-Knoten bezeichnet und stellt für dieaufzurufende Regel den Kontext-Knoten dar. Eine Regel, die durch eine invocationaufgerufen wird, wird erst dann ausgeführt, nachdem die Regel ausgeführt wurde, inder die invocation aufgerufen wird. In der Abbildung 3.5 wird z.B. zuerst die darge-stellte Regel moveMarker() ausgeführt und anschlieÿend wird durch die invocationexecuteState() eine Regel mit dem Namen executeState() aufgerufen und ausgeführt.Falls eine Regel mehrere invocations enthält, dann können diese durchnummeriertwerden, um die Reihenfolge der Ausführung der entsprechenden Regeln festzulegen.

Bei der Erstellung von DMM-Regeln kommen drei unterschiedliche Regel-Typenzum Einsatz. Durch die unterschiedlichen Typen kann der Bau von DMM-Regelnwesentlich komfortabler gestaltet werden. Die Unterschiede und Eigenschaften dereinzelnen Typen sind folgende:

• bigstep Eine Regel vom Typ bigstep kann nicht explizit aufgerufen werden,sondern wartet auf ein Zustand des Laufzeit-Modells, bei dem das Muster derRegel mit einem Muster in dem Laufzeit-Modell übereinstimmt. Sobald diesder Fall ist, �matcht� die Regel und ändert den Zustand des Laufzeit-Modells,indem die in der Regel beschriebenen Änderungen an dem Laufzeit-Modellvorgenommen werden.

• smallstep Eine Regel vom Typ smallstep kann nur dann ausgeführt werden,wenn diese von einer anderen Regel vom Typ bigstep oder smallstep durcheine invocation aufgerufen wird. Bei Regeln dieses Typs wird das Konzept der

38 WS 2009/2010


Parameterübergabe unterstützt, ähnlich wie es in der objektorientierten Pro-grammierung verwendet wird. Durch die Verwendung von Parameter ist dieMöglichkeit gegeben, nicht nur bestimmte Muster von Objekten zu beschrei-ben, sondern gezielt ganz bestimmte Objekte zu identi�zieren. Auÿerdem ist esmöglich, von einer smallstep-Regel verschiedene, gleichnamige Varianten mitunterschiedlichem Inhalt zu erstellen, um beispielsweise verschiedene Situatio-nen für einen bestimmten Kontext abzudecken. Dabei bekommt jede Varianteeine eindeutige Id die sich aus dem Namen der Regel und einer fortlaufendenNummer als Su�x zusammensetzt (z.B. die Smallstep-Regel executeStae() inKapitel 4.4.2.2).

• premise Eine Regel vom Typ premise dient der Wiederverwendbarkeit, d.h.oft verwendete Objekt-Muster, die in anderen Regeln auftauchen, können ineine premise-Regel ausgelagert werden. Eine premise-Regel wird analog einersmallstep-Regel auf einem Knoten durch eine invocation aufgerufen. Eine Re-gel, in der premise-Regeln aufgerufen werden, �matcht� nur dann, wenn das inder Regel beschriebene Muster und zusätzlich das in den aufrufenden premise-Regeln beschriebene Muster in einem Laufzeit-Modell vorhanden ist.

Durch den Einsatz dieser drei Regel-Typen hat man die Möglichkeit, anstatt groÿeunübersichtliche Regeln zu bauen, kleine leichter verständlichere Regeln zu erstellen.

3.5. Werkzeuge zur Umsetzung von DMM

Die Erstellung einer DMM-Spezi�kation für UML Statemachines wurde in der vor-liegenden Arbeit in der Entwicklungsumgebung Eclipse2 umgesetzt. Die Entwick-lungsumgebung wurde dabei durch Plugins erweitert, sodass alle für diese Arbeitbenötigten Implementierungswerkzeuge direkt unter Eclipse zu Verfügung standen.In den folgenden Unterabschnitten werden Werkzeuge vorgestellt, die die technischeUmsetzung von DMM realisieren und eine maschinelle Analyse eines unter DMMerstellten Regelsatzes ermöglichen.

3.5.1. DMM-Editor

Für die Erstellung von DMM-Regeln wurde der auf EMF3 basierte DMM-Editor,entwickelt von [9], eingesetzt. Das Eclipse-Plugin EMF ermöglicht es Metamodelleals Klassendiagramme zu erstellen. Für die Erstellung des Laufzeit-Metamodells fürUML Statemachines wurde das Syntax-Metamodell aus dem Eclipse UML2-Plugin4

verwendet.Beim Anlegen eines Regelsatzes in dem DMM-Editor werden zwei Dateien mit den

Endungen .ruleset und .ruleset_diagram erzeugt. Die Datei mit der Endung .rule-

set_diagram repräsentiert die gra�sche Darstellung aller in dem Regelsatz erstellten2http://www.eclipse.org3Eclipse Modeling Framework4org.eclipse.uml2.uml



Regeln. Die Datei mit der Endung .ruleset speichert den gesamten Regelsatz in einerBaumartigen Struktur. Der DMM-Editor unterstützt alle Features für die Erstellungvon DMM-Regeln, die in den vorigen Abschnitten dieses Kapitels vorgestellt wurden.

3.5.2. Transformationstools

Um eine automatische Anwendung des DMM-Regelsatzes auf ein Laufzeit-Modellzu gewährleisten wurde das Softwaretool GROOVE [8] eingesetzt. GROOVE ist ei-ne Toolsammlung für Graphtransformationen und Modelchecking, die es ermöglicht,aus einem Anfangsgraphen und Graphtransformationsregeln automatisch ein Tran-sitionssystem zu erzeugen. Mit Hilfe der Graphtransformationsengine von GROOVEwerden die erstellten Regeln auf Instanzen des Laufzeit-Metamodells angewendet,wodurch ein Transitionssystem entsteht. Durch den Einsatz von GROOVE, könnendie DMM-Regeln maschinell analysiert werden. In Kapitel 5 wird beschreiben wiedie Analyse des für UML Statemachines erstellten Regelsatzes durchgeführt wurde.Bevor aus einem Anfangsgraphen durch GROOVE ein Transitionssystem erzeugt

werden kann, müssen das Laufzeit-Modell und der DMM-Regelsatz in ein Formatüberführt werden, welches von GROOVE verarbeitet werden kann. Für die Umwand-lung eines Laufzeit-Modells in einen Anfangsgraphen wurde das an der UniversitätPaderborn entwickelte Softwaretool EMF2GROOVE eingesetzt. Für die Umwand-lung des DMM-Regelsatzes nach Graphtransformationen wurde das SoftwaretoolDMM2GXL verwendet, welches ebenfalls an der Universität Paderborn entwickeltworden ist.

40 WS 2009/2010

4. DMM-Spezi�kation für UML

Statemachines

In diesem Kapitel wird die in dieser Arbeit erstellte DMM-Spezi�kation für UMLStatemachines vorgestellt. Zu Beginn wird in Abschnitt 4.1 das Marker-Konzept fürdas Abarbeiten einer Statemachine eingeführt. In Abschnitt 4.2 wird das Laufzeit-Metamodell vorgestellt, welches die nötigen Elemente für die Umsetzung des Marker-Konzepts enthält. Die Transformation einer UML Statemachine in eine Laufzeit-Statemachine wird in Abschnitt 4.3 erläutert. In Abschnitt 4.4 werden die DMM-Regeln aus dem erstellten DMM-Regelsatz vorgestellt, die das dynamische Verhaltenvon UML Statemachines beschreiben. Anschlieÿend wird in Abschnitt 4.5 über denEntwicklungsstand der DMM-Spezi�kation diskutiert.

4.1. Konzept zum Durchlaufen einer Statemachine

Bei der Abarbeitung einer UML Statemachine wird jeder zulässige Pfad vom Startzu-stand zum Endzustand als möglicher Durchlauf einer UML Statemachine betrachtet.Die Abarbeitung einer UML Statemachine kann man sich wie folgt vorstellen. EinMarker bewegt sich, angefangen beim Startzustand, entlang der durch Ereignisse ak-tivierten Transitionen und Zustände bis ein Endzustand erreicht wird. Dabei be�ndetsich der Marker zu jedem Zeitpunkt in genau einem Zustand einer Statemachine, essei denn dass die Statemachine aus mehreren Regionen besteht. Im letzten Fall be-�ndet sich ein Marker zu jedem Zeitpunkt in genau einem Zustand pro Region. Beieinem Zustandsübergang wird eine Transition passiert und währenddessen wandertder Marker entlang der Transition. Einer Transition kann ein Verhalten zugeordnetsein, welches beim Schalten der Transition ausgeführt wird. Während dieses Verhal-ten ausgeführt wird verweilt der Marker auf der Transition.

4.2. Laufzeit-Metamodell für UML Statemachines

Das Laufzeit-Metamodell besteht aus dem Syntax-Metamodell für UML Statemachi-nes und den zusätzlichen Elementen, die für die Beschreibung und Ausführung desVerhaltens benötigt werden. In der Abbildung 4.1 ist das Laufzeit-Metamodell fürUML Statemachines dargestellt. Der linke Teil in der Abbildung stellt die Elemen-te des Syntax-Metamodells dar, die durch Assoziationen eine direkte Beziehung zuden neu hinzugekommenen Elementen für die Laufzeit-Information haben. Der rech-te Teil der Abbildung repräsentiert die Elemente, die für die Laufzeit-Information

41

Kapitel 4. DMM-Spezi�kation für UML Statemachines

benötigt werden.In den folgenden Unterabschnitten werden die Eigenschaften der einzelnen Ele-

menten aus dem Laufzeit-Metamodell erläutert.

Behavior

StateMachine

Vertex

State

- isComposite: boolean- isOrthogonal: boolean- isSimple: boolean- isSubmachineState: boolean

Pseuodstate

- kind: PseudostateKind

Region

Namespace

Transition

- kind: TransitionKind

BehaviorExecution

- hasStarted: boolean


HistoryMarker

RegionProperty

TransitionExecution

- transitionExecuted: boolean

transition

1

+region1..*

+stateMachine0..1

+subvertex

*

+container

0..1

* containedRegions*

+region

*

+state 0..1

*

regionProperties

*

historyMarker

*

transitionExecution

1

contained_in

1

0..1

contained_in

1

0..1

mark

1

1

region

1

commonAncestor

1

1

executes

1

*

executes

1

+transition*

+container1

TransitionProperty

*

transitionProperties

1

1

Marker

- doBehaviorExecuted: boolean- entryBehaviorExecuted: boolean- exitBehaviorExecuted: boolean

0..1*

marker

Metamodell: Syntax Metamodell: Laufzeitinformation

Abbildung 4.1.: Laufzeit-Metamodell für UML Statemachines

4.2.1. StateMachineExecution

Die Klasse StateMachineExecution bildet das oberste Element, das als Container fürdie restlichen Elemente dient, die zur Laufzeit-Information für die DMM-Spezi�kationbenötigt werden. Diese Klasse ist eine Spezialisierung der Klasse BehaviorExecution,die in der Arbeit von Hornkamp [5] erstellt wurde und in dieser Arbeit wiederverwen-det wird. Die Klasse BehaviorExecution besitzt eine Referenz executes auf die KlasseBehavior aus dem Syntax-Metamodell und dient der Beschreibung des Ausführungvon Verhalten. Da die Klasse StateMachine von der Klasse Behavior erbt (vgl. UML

42 WS 2009/2010


Spezi�kation [7]), gilt die Beziehung executes zwischen den Klassen StateMachine-

Execution und StateMachine (siehe Abbildung 4.1) ebenfalls.

4.2.2. Marker

In Abschnitt 4.1 wurde das Marker-Konzept zum Durchlaufen einer Statemachi-ne eingeführt. Durch die Klasse Marker (und der restlichen Hilfsklassen) wird dieStruktur für die Umsetzung des Marker-Konzepts realisiert. Das heiÿt, dass wäh-rend der Ausführung einer Laufzeit-Statemachine markiert ein Marker (Instanz derKlasse Marker) die aktiven Zustände einer Statemachine und wird durch Zustands-übergänge zu den Zielzuständen bewegt, die als nächste aktiv werden sollen.Die Klasse besitzt eine Assoziation contained_in zu der Klasse Vertex aus dem

Syntax-Metamodell. Da die Klassen State und Pseudostate Spezialisierungen derKlasse Vertex sind, gilt die Beziehung contained_in für diese Klassen ebenfalls (sieheAbbildung 4.1). Diese Assoziation ermöglicht es einem Zustand oder einem Pseudo-zustand (die in Kapitel 2 eingeführt wurden) innerhalb einer Laufzeit-Statemachineeinen Marker zuzuordnen.Um die Reihenfolge für die Ausführung der einzelnen möglichen Verhalten von Zu-

ständen entsprechend der UML Spezi�kation festzulegen, werden folgende Attributeverwendet:

• entryBehaviorExecuted: durch die Zuweisung eines Wahrheitswerts (true, false)wird gekennzeichnet, ob das Eintrittsverhalten (entryBehavior) des durch denMarker markierten Zustands bereits ausgeführt worden ist.

• doBehaviorExecuted: durch die Zuweisung eines Wahrheitswerts (true, false)wird gekennzeichnet, ob das Zustandsverhatlen (doBehavior) des durch denMarker markierten Zustands bereits ausgeführt worden ist.

• exitBehaviorExecuted: durch die Zuweisung eines Wahrheitswerts (true, false)wird gekennzeichnet, ob das Austrittsverhatlen (exitBehavior) des durch denMarker markierten Zustands bereits ausgeführt worden ist.

Durch das Erzeugen, Bewegen und Zerstören von Markern und dem Verändern derWerte der oben vorgestellten Attribute, wird also zur Laufzeit der aktuelle Zustandeiner Statemachine beschrieben. All diese Operationen werden durch die Regeln ausdem DMM-Regelsatz auf Instanzen der KlasseMarker in einer Laufzeit-Statemachineangewendet.

4.2.3. HistoryMarker

In den Abschnitten 2.2.8.7 und 2.2.8.8 von Kapitel 2 wurden die PseudozuständeShallow History und Deep History eingeführt. Die Aufgabe dieser Pseudozustän-de ist es sich den zuletzt aktiven Zustand in einer entsprechenden Region zu mer-ken. Um diese Eigenschaft in der DMM-Spezi�kation umzusetzen, wird im Laufzeit-



Metamodell das Element HistoryMarker verwendet (siehe Abbildung 4.1). Ein His-

toryMarker wird in einer Laufzeit-Statemachine durch entsprechende DMM-Regelnverwaltet (erzeugt, bewegt und zerstört). Durch die Assoziation mark wird die Re-gion einer Laufzeit-Statemachine markiert, in der sich der HistoryMarker be�ndet.Die Assoziation contained_in zeigt auf einen Zustand oder Pseudozustand in demsich der HistoryMarker be�ndet.

4.2.4. RegionProperty

Die Klasse RegionProperty ist durch eine Assoziation region mit der Klasse Regionaus dem Syntax-Metamodell verbunden. Durch die Assoziation containedRegions

können zwei Instanzen der Klasse RegionProperty zueinander in Beziehung stehen.Da eine Region zusammengesetzte Zustände enthalten kann, die wiederum Regionenenthalten, wird die Klasse RegionProperty dazu verwendet, um für jede Region zuermitteln ob diese Unterregionen enthält. Diese Eigenschaft wird benötigt um bei derAusführung einer Laufzeit-Statemachine einen HistoryMarker bei der Verwendungeines Pseudozustands Deep History zu verwalten.

4.2.5. TransitionProperty

Eine Transition besitzt laut UML Spezi�kation eine Quelle und ein Ziel. Diese kön-nen vom Typ State oder Pseudostate sein. Die Quelle und das Ziel einer Transitionkönnen sich in unterschiedlichen (verschachtelten) Regionen be�nden. Durch das Ele-ment TransitionProperty und die Assoziation commonAncestor zu der Klasse Name-space (siehe Abbildung 4.1) wird die gemeinsame Region die als nächster �Vorfahre�für die Quelle und das Ziel einer Transition gilt, ermittelt.

4.2.6. TransitionExecution

Eine Transition kann laut UML Spezi�kation ein Verhalten besitzen. Dieses Verhaltenwird zwischen der Ausführung des Austrittsverhaltens des Quellzustands und derAusführung des Eintrittsverhaltens des Zielzustands einer Transition ausgeführt.

Wie dem Laufzeit-Metamodell in Abbildung 4.1 zu entnehmen ist, kann einerTransition in einer Laufzeit-Statemachine ein Element TransitionExecution über ei-ne Assoziation executes zugeordnet werden. Desweiteren besitzt die Klasse Transi-tionExecution ein Attribut transitionExecuted, welches durch die Wertzuweisungentrue oder false identi�ziert, ob das an der Transition angetragene Verhalten bereitsausgeführt worden ist. Das Attribut transitionExecuted wird durch entsprechendeDMM-Regeln zur Laufzeit verwaltet.

44 WS 2009/2010


4.3. Transformation einer UML Statemachine in eineLaufzeit-Statemachine

Eine UML Statemachine ist eine Instanz des zugrundeliegenden Syntax-Metamodells.Durch eine Transformation, die in Java realisiert wurde, wird eine UML Statemachi-ne, dem Laufzeit-Metamodell entsprechend zu einer Laufzeit-Statemachine erweitert.Eine UML Statemachine muss also um die Elemente und deren Assoziationen, die

in Abbildung 4.1 im rechten Teil des Laufzeit-Metamodells dargestellt sind, erweitertwerden. Die Syntax der neu hinzugekommenen Elemente des Laufzeit-Metamodellswird durch das Eclipse-Plugin EMF durch Codegenerierung erzeugt.Um eine UML Statemachine in eine Laufzeit-Statemachine zu transformieren, müs-

sen von den Elementen zur Laufzeit-Information Instanzen erzeugt und den entspre-chenden Instanzen der UML Statemachine zugeordnet werden. Die Erzeugung derInstanzen wird in der Java-Klasse StateMachineConverter implementiert. Im Folgen-den werden die Instanzen der einzelnen Elemente aufgelistet und deren Bedeutungerläutert:

• RegionProperty : jeder Region der ausgewählten Statemachine wird eine In-stanz der Klasse RegionProperty über die Beziehung region zugeordnet. Fallseine Region durch enthaltene zusammengesetzte Zustände Regionen enthält, sowerden die den Regionen zugehörigen regionProperties miteinander über dieBeziehung containedRegions verbunden. Diese Beziehung gilt rekursiv für alleUnterregionen einer Region (Transitive Hülle bzgl. der Relation containedRe-

gions).

• TransitionProperty : jeder Transition der ausgewählten Statemachine wird ei-ne Instanz der Klasse TransitionProperty über die Beziehung transition zu-geordnet. Eine Instanz der Klasse TransitionProperty ist über die BeziehungcommonAncestor mit einer Instanz der Klasse Namespace verbunden. Für jedeTransition einer Laufzeit-Statemachine wird über ein Objekt transitionProper-ty die Region gespeichert, die der nächste gemeinsame Vorfahre von der Quelleund dem Ziel der Transition ist.

• TransitionExecution: jeder Transition der ausgewählten Statemachine wird eineInstanz der Klasse TransitionExecution über die Beziehung executes zugeord-net.

• StateMachineExecution: eine Statemachine ist durch die Beziehung executesmit einer Instanz der Klasse StateMachineExecution verbunden.

Von den Klassen Marker und HistoryMarker werden Instanzen durch das An-wenden von entsprechenden DMM-Regeln zur Laufzeit erzeugt, so dass diese beidenElemente ausschlieÿlich für die Beschreibung des dynamischen Verhaltens verwendetwerden.



Die Transformation wird in der Entwicklungsumgebung Eclipse durchgeführt, indem man per Rechtsklick die gewünschte UML Statemachine (Datei mit der Endung.uml) auswählt und dann die Operation �Convert UML State Machine to RuntimeModel� auswählt. Durch das Starten dieser Operation wird die oben beschriebeneTransformation einer UML Statemachine in eine Laufzeit-Statemachine durchge-führt. Die auf diese Weise erzeugte Laufzeit-Statemachine dient als Eingabegraphfür das Transitionssystem, welches durch das Anwenden des DMM-Regelsatzes aufdie Laufzeit-Statemachine dann erzeugt werden kann.

4.4. Regelsatz für UML Statemachines

In diesem Abschnitt wird der für UML Statemachines erstellte DMM-Regelsatz vor-gestellt der den zweiten Teil der DMM-Spezi�kation bildet. Der DMM-Regelsatzbesteht aus etwa 90 Regeln und diese alle hier ausführlich vorzustellen würde denRahmen dieser Arbeit sprengen. Daher werden hier als Erstes die grundlegendenRegeln, die in jeder Laufzeit-Statemachine zur Anwendung kommen, vorgestellt. Da-nach werden die Regeln gezeigt, die das Verhalten der in den Beispiel-Modellen vonKapitel 2 vorgestellten Sprachelementen formal beschreiben.

4.4.1. Grundlegende Festlegungen zur Beschreibung des Verhaltenseiner UML Statemachine

Zu Beginn dieses Kapitel wurde das Marker-Konzept zur Abarbeitung einer UMLStatemachine vorgestellt. Dabei wird jeder Pfad vom Startzustand zum Endzustandals möglicher Durchlauf einer UML Statemachine betrachtet. Während eine UMLStatemachine durchlaufen wird, be�ndet diese sich stets in einem von zwei möglichenSzenarien:

• Gültige Zustandskon�guration: die UML Statemachine be�ndet sich in ei-nem Zustand bei dem entweder kein Verhalten ausgeführt wird oder es wirddas Zustandsverhalten (doBehavior) von den zur Zeit aktiven Zuständen aus-geführt. In dem Beispiel in Abbildung 2.19 be�ndet sich das Autoradio ineiner gültigen Zustandskon�guration während es eingeschaltet ist und z.B. dieFrequenz F1 abgespielt wird. Während eine UML Statemachine sich in einergültigen Zustandskon�guration be�ndet, kann diese durch Eintreten von Ereig-nissen, die einen oder mehrere Trigger auslösen in den Zustand �Durchführungeiner Zustandskon�guration� versetzt werden. Dies ist immer dann der Fall,wenn ein Trigger von einer oder mehreren ausgehenden Transitionen eines ak-tiven Zustands ausgelöst wird.

• Durchführung einer Zustandskon�guration: während dieser Phase wirdein Zustandsübergang durchgeführt, d.h. es wird das Austrittsverhalten in denzu verlassenden Zuständen gefolgt von dem Verhalten der schaltenden Transi-tion und schlieÿlich dem Eintrittsverhalten der zu betretenen Zuständen ausge-führt. In dem Beispiel in Abbildung 2.19 entspricht dies z.B. dem Wechsel vom

46 WS 2009/2010


CD-Betrieb in den Radiobetrieb, welcher durch das drücken der Taste �Radio�ausgelöst werden kann. Die Durchführung einer Zustandskon�guration ist einatomarer Prozess, d.h. dieser wird durch keine Ereignisse unterbrochen. Nachdem eine Zustandskon�guration durchgeführt worden ist, be�ndet sich eineUML Statemachine wieder in einer gültigen Zustandskon�guration.

In Kapitel 2 wurden in Abschnitt 2.2.2 die von der UML-Spezi�kation vorge-schriebene Bedingungen, die für das Schalten einer Transition erfüllt sein müssen,vorgestellt. Diese Bedingungen werden hier noch mal aufgelistet:

• Alle Quellzustände be�nden sich in einer aktiven Zustandskon�guration.

• Einer der zur Transition zugeordneter Trigger wird ausgelöst.

• Es existiert mindestens ein vollständiger Pfad zwischen der Quellen-Zustands-kon�guration und einer Ziel-Zustandskon�guration, bei dem die Bedingungen(Guards) erfüllt sind.

Wie im vorigen Kapitel bereits erwähnt wurde, beschreibt ein Transitionssystemdas gesamte Verhalten einer Laufzeit-Statemachine, d.h. es werden alle möglichenPfade vom Startzustand zum Endzustand durch das erzeugte Transitionssystem dar-gestellt. Auf jedem der erzeugten Pfade wird die korrekte (entsprechend der UMLSpezi�kation) Ausführungsreihenfolge der einzelnen Verhalten von Zuständen undTransitionen dargestellt.Um eine Erzeugung eines Transitionssystems zu gewährleisten, in dem das gesamte

Verhalten, d.h. alle möglichen Pfade vom Startzustand zum Endzustand dargestelltwerden, müssen bezüglich der letzten zwei Bedingungen für das erfolgreiche Schalteneiner Transition, folgende Vereinfachungen getro�en werden:

• Alle Trigger an den Transitionen sind aktiv (ausgelöst): zu jedem Zeit-punkt in dem sich eine Laufzeit-Statemachine in einer gültigen Zustandskon�-guration be�ndet, werden alle Trigger ausgelöst.

• Alle Bedingungen an den Transitionen sind erfüllt: immer wenn einTrigger ausgelöst wird, ist die an der entsprechenden Transition angebrachteBedingung (falls solche vorhanden ist) erfüllt.

Wären diese Vereinfachungen nicht gegeben, so würde man in einem Transiti-onssystem immer nur einen möglichen Durchlauf einer Laufzeit-Statemachine vomStartzustand zum Endzustand darstellen. Dieser dargestellte Pfad könnte dann auchnoch durch Fehlen der entsprechenden Trigger oder durch nicht erfüllte Bedingungendazu führen, das ein Endzustand der zu beschreibenden Laufzeit-Statemachine nichterreicht wurde. Das bedeutet, das man auf diese Weise nur einen bestimmten Teil(gegeben durch die zum betrachteten Zeitpunkt gesetzten Trigger und Bedingungen)des Verhaltens einer Laufzeit-Statemachine durch das Transitionssystem beschreibenwürde.



Durch die oben festgelegten Vereinfachungen für die Trigger und Bedingungen beieiner Laufzeit-Statemachine wird somit durch die Anwendung des DMM-Regelsatzesauf eine Laufzeit-Statemachine, ein Transitionssystem erzeugt, welches das gesam-te Verhalten einer UML Statemachine beschreibt. Jeder Zustand in einem auf dieseWeise erzeugten Transitionssystem beschreibt entweder eine gültige Zustandskon�-guration einer UML Statemachine oder einen Abschnitt des atomaren Prozesses, beidem eine Zustandskon�guration einer UML Statemachine durchgeführt wird.

4.4.2. Grundlegende Regeln für UML Statemachines

In diesem Abschnitt werden die grundlegenden Regeln vorgestellt, die für eine be-liebige UML Statemachine, die einen Startzustand und einen Endzustand besitzt,gelten.

4.4.2.1. Starten einer UML Statemachine

Um das Verhalten einer UML Statemachine durch ein Transitionssystem zu be-schreiben, wird der DMM-Regelsatz auf die zur UML Statemachine korrespondie-rende Laufzeit-Statemachine angewendet. Die Laufzeit-Statemachine ist der Initial-Zustand für das zu erzeugende Transitionssystem. Während die Laufzeit-Statemachi-ne sich in diesem Initial-Zustand be�ndet, muss diese mit den für die Ausführung be-nötigten Markern versehen werden, um dann im weiteren Verlauf entsprechend demMarker-Konzept, alle möglichen Pfade vom Startzustand zum Endzustand durch dasTransitionssystem darzustellen.

Die Bigstep-Regel startStatemachine()#, die in Abbildung 4.2 dargestellt ist, sorgtdafür, dass die Ausführung der UML Statemachine angestoÿen wird. Damit dieseRegel matcht, muss das durch die Regel de�nierte Objektmuster in der vorliegen-den Laufzeit-Statemachine vorhanden sein. Das heiÿt, es muss ein Objekt vom TypStateMachineExecution über einer Referenz executes mit einem Objekt vom TypStatemachine vorhanden sein. Durch die in Abschnitt 4.3 beschriebene Transforma-tion wird gewährleistet, dass eine UML Statemachine in eine Laufzeit-Statemachinetransformiert wird und somit das durch die Regel beschriebene Objektmuster gege-ben ist.Ein weiteres Merkmal, welches erfüllt sein muss damit die Regel matcht, ist der

Wert der boolean Variable hasStarted (siehe Abbildung 4.2), der als zusätzlicheBedingung für das erfolgreiche Matchen der Regel erfüllt sein muss. Ist diese Be-dingung ebenfalls erfüllt, so matcht die Regel startStatemachine()# und durch dieAusführung der Regel wird der Variable hasStarted wird der Wert true zugewiesen.Hierdurch wird sichergestellt, das diese BigstepRegel nur einmal für die vorliegendeLaufzeit-Statemachine matcht, da ansonsten diese Regel unendliche Male matchenwürde.Als nächster Schritt wird bei der Ausführung der Regel startStatemachine()#

durch eine invocation die Smallstep-Regel enterInitialState() aufgerufen.

48 WS 2009/2010


Abbildung 4.2.: Bigstep-Regel startStatemachine()# zum Starten einer UML State-machine

Die Smallstep-Regel enterInitialState(), dargestellt in Abbildung 4.3 setzt voraus,dass jede orthogonale Region (falls vorhanden) in der vorliegenden Statemachineeinen Startzustand (Pseudozustand Initial) enthält. Durch die Anwendung dieserRegel wird als Nächstes die Regel createMarker() auf einem Startzustand in jederorthogonalen Region der Laufzeit-Statemachine aufgerufen.

Abbildung 4.3.: Smallstep-Regel enterInitialState() zur Initialisierung der Startzu-stände

Die Regel createMarker (siehe Abbildung 4.4) erzeugt einen Marker und weistdiesen über die Referenz contained_in dem Knoten zu, auf dem sie aufgerufen wurde.

Abbildung 4.4.: Smallstep-Regel createMarker() zur Erzeugung von Markern

Mit Hilfe der drei oben vorgestellten Regeln wird also eine UML Statemachinemit Marker-Objekten versehen, um dann die Ausführungsreihenfolge des Verhaltensdurch die möglichen Pfade vom Startzustand zum Endzustand in der vorliegendenStatemachine durch das zu erzeugende Transitionssystem darzustellen.Nun kann durch die Anwendung von passenden Regeln die Erzeugung des Transi-

tionssystem fortgesetzt werden. In dem nächsten Unterabschnitt wird erläutert wiedas Verhalten bei der Durchführung einer Zustandskon�gurtaion abgearbeitet wird.



4.4.2.2. Durchführung einer Zustandskon�guration

In Abschnitt 4.4.1 wurde festgelegt, dass eine aktive Statemachine sich stets in einemvon zwei möglichen Szenarien (�Gültige Zustandskon�guration� oder �Durchführungeiner Zustandskon�guration�) be�ndet. Nachdem eine Statemachine gestartet wirdund für alle Startzustände der direkten Regionen der Statemachine Marker erzeugtworden sind, be�ndet sich diese in einer gültigen Zustandskon�guration. Das heiÿt,dass alle Trigger ausgelöst und Bedingungen erfüllt sind, um einen Zustandsüber-gang anzustoÿen, dessen Durchführung der Durchführung einer Zustandskon�gura-tion entspricht.In dem in dieser Arbeit erstellten DMM-Regelsatz existieren fünf sich gegenseitig

ausschlieÿende Bigstep-Regeln namens �reTransition()#, von denen jede in einer be-stimmten gültigen Zustandskon�guration matcht und durch die Ausführung diesereine Durchführung einer Zustandskon�guration angestoÿen wird. Falls es sich beider Quelle der zu schaltenden Transition um ein Element vom Typ State, also einemZustand, handelt, so wird durch eine Reihenfolge von Smallstep-Regel-Aufrufen dasAustrittsverhalten des Quellzustands angestoÿen. Danach wird das an der schalten-den Transition angetragene Verhalten ausgeführt und schlieÿlich durch das Betretendes Zielzustands dessen Eintrittsverhalten ausgeführt.In Abbildung 4.5 wird eine von fünf existierenden Regeln zur Durchführung einer

Zustandskon�guration dargestellt. Die Regel setzt voraus, dass die Quelle und dasZiel der Transition Zustände (States) sein müssen. Die Bedingung entryBehaviorExe-cuted==true in dem im Quellzustand enthaltenen Marker setzt zusätzlich voraus,dass die Regel nur bei einer gültigen Zustandskon�guration matcht, d.h. jeglichesEintrittsverhalten ist in den Quellzuständen der zu schaltenden Transition bereitsausgeführt worden.

Abbildung 4.5.: Bigstep-Regel �reTransition2()#

Sind alle Voraussetzungen für das Matchen der Regel erfüllt, so wird diese aus-geführt. Durch die Ausführung der Regel werden die Regeln startExitingExecuti-

on(ns,t), startTransitionExecution() und setMarkersOnTargetStateCon�guration(ns)

aufgerufen. Die Ausführungsreihenfolge der aufzurufenden Regeln ist durch eine demRegel-Aufruf vorangehende Nummer (siehe Abbildung 4.5) festgelegt. Durch die Aus-

50 WS 2009/2010


führung der genannten Regeln werden die folgenden drei Schritte in der angegebenenReihenfolge angestoÿen und durchgeführt:

1. Verlassen der Quellzustände der schaltenden Transition: hier wird die Ausfüh-rungsreihenfolge des Austrittsverhaltens der Zustände ermittelt, die durch dasSchalten einer Transition verlassen werden. Nachdem diese ermittelt wordensind, wird durch den Aufruf und die Ausführung entsprechender Regeln dasAustrittsverhalten der Quellzustände als ausgeführt markiert.

2. Schalten der Transition: Die Transition wird als ausgeführt markiert.

3. Betreten der Zielzustände der schaltenden Transition: Hier wird die Ausfüh-rungsreihenfolge des Eintrittsverhaltens der Zustände ermittelt, die durch denZustandsübergang aktiv werden sollen. Nachdem diese ermittelt worden sind,wird durch die Ausführung entsprechender Regeln das Eintrittsverhalten derZielzustände als ausgeführt markiert.

Das Ausführen dieser drei Schritte soll im Folgenden genauer erläutert werden.

Verlassen der Quellzustände einer zu schaltenden Transition Hier wird als Ers-tes die Regel startExitingExecution(ns,t) aufgerufen, der die Objekte ns vom TypNamespace und t vom Typ Transition als Parameter übergeben werden. Das Objektns enthält die eindeutige Id der Region, die der nächste gemeinsame Vorfahre derZustände source und target ist. Diese Information wird benötigt, um beim Verlassender Quellzustände einer Transition den Zustand zu identi�zieren, dessen Austritts-verhalten als letztes ausgeführt wird. Dies soll anhand des Beispiels in Abbildung 4.6genauer erklärt werden.

Quellzustand von t1 Zielzustand von t1Region, die der nächste gemeinsame Vorfahre der Zustände comState2 und C ist

t1/act1

Abbildung 4.6.: Verlassen und Betreten von verschachtelten Zuständen

Unter der Annahme, dass die Quellzustände der Transition mit dem Trigger t1sich in einer gültigen Zustandskon�guraion be�nden (grün umrandete bzw. ausge-füllte Zustände), soll durch das Auslösen des Triggers t1 die Durchführung einer



Zustandkon�guration angestoÿen und ausgeführt werden. Die Quelle der zu schal-tenden Transition ist der zusammengesetzte Zustand compState2. Da beim Schaltender Transition der zusammengesetzte Zustand compState1 ebenfalls verlassen wird,muss dessen Austrittsverhalten als letzte Aktion beim Verlassen der Quellzuständeder Transition ausgeführt werden.Die Region, die der nächste gemeinsame Vorfahre des Quell -und Zielzustands einer

Transition ist, dient hier also als Abbruchbedingung für die rekursive Ausführung desAustrittsverhaltens der zu verlassenden Quellzustände bei einem Zustandsübergang.

Wie in Kapitel 2.2 bereits vorgestellt wurde, wird beim Verlassen eines zusammen-gesetzten Zustands als Erstes das Austrittsverhalten eines einfachen Zustands, dersich auf tiefster Ebene innerhalb des zusammengesetzten Zustands be�ndet, ausge-führt. In Abbildung 4.6 wäre dies der Zustand A. Um den aktiven Unterzustandzu ermitteln, wird durch den Regel-Aufruf startExitingExecution(ns,t) innerhalbder Bigstep-Regel �reTransition()# aus Abbildung 4.5, eine von zwei existierendenSmallstep-Regeln aufgerufen. Bezogen auf das Beispiel in Abbildung 4.6 matcht zu-erst die Regel startExitingExecution1(ns,t), die in Abbildung 4.7 dargestellt ist. Hierwerden die Objekte r und t als Parameter für den reursiven Regel-Aufruf startExi-tingExecution(r,t) weitergereicht. Das Objekt r entspricht dabei der Region, derenId durch den Typ Namespace in der Regel �reTransition()# in Abbildung 4.5 ange-geben wurde.

Abbildung 4.7.: Smallstep-Regel startExitingExecution1()

Durch die Ausführung der Regel startExitingExecution1(r,t) wird durch den re-kursiven Regel-Aufruf startExitingExecution(r,t) entweder die gleiche Regel oder dieRegel startExitingExecution2(r,t) aufgerufen. Die Regel startExitingExecution2(r,t),dargestellt in Abbildung 4.8, gilt als Abbruchbedingung für den rekursiven Aufrufinnerhalb startExitingExecution1(r,t). Das heiÿt, sobald die Regel aus Abbildung4.8 matcht, so bedeutet dies, dass der aktive Zustand (der einen Marker mit derBedingung entryBehaviorExecuted==true enthält) auf der untersten Ebene des zu-sammengesetzten Zustands ermittelt wurde.

52 WS 2009/2010


Abbildung 4.8.: Smallstep-Regel startExitingExecution2()

Durch den Regel-Aufruf executeExitBehavior(r,t) in der Regel startExitingExecu-tion2(r,t) wird mit der Ausführung des Austrittsverhaltens begonnen.In dem DMM-Regelsatz für UML Statemachines existieren acht Varianten der

Smallstep-Regel executeExitBehavior(r,t). Im Folgendem werden drei Varianten die-ser Regel vorgestellt, die bei dem Beispiel in Abbildung 4.6 zur Anwendung kommen.Als erste matcht die Regel executeExitBehavior2(r,t), die in Abbildung 4.9 darge-

stellt ist. Diese Regel setzt voraus, dass der Kontext-Knoten ein einfacher Zustandsein muss, der ein Unterzustand von einem zusammengesetzten Zustand ist. Weite-re Voraussetzungen für das erfolgreiche Matchen der Regel sind die Bedingungen inden Objekten marker und superMarker, durch die sichergestellt werden soll, dass vordem Austrittsverhalten des zusammengesetzten Zustands das Austrittsverhalten desUnterzustands ausgeführt werden soll.

Abbildung 4.9.: Smallstep-Regel executeExitBehavior2(r,t)

Sobald die Regel matcht, wird durch die Ausführung dieser in dem im einfachen Zu-stand enthaltenen Marker durch die Wertzuweisung exitBehaviorExecuted==true,das Austrittsverhalten als abgeschlossen markiert. Zusätzlich wird auf dem zusam-mengesetzten Zustand durch einen rekursiven Aufruf dessen Austrittsverhalten an-



gestoÿen. Bezogen auf das Beispiel in Abbildung 4.6 wird durch das Anwenden dieserRegel das Austrittsverhalten des Zustands A ausgeführt.Durch den rekursiven Aufruf matcht die Regel executeExitBehavior8(r,t), die in

Abbildung 4.10 dargestellt ist. Durch die Anwendung dieser Regel wird das Austritts-verhalten des zusammengesetzten Zustands compState2 als abgeschlossen markiert.


Durch den Regel-Aufruf destroyMarkerInLeavedRegion(t) wird der Marker, derin dem Zustand A enthalten ist, gelöscht. Danach wird durch den rekursiven Auf-ruf executeExitBehavior(r,t) das Austrittsverhalten auf dem Zustand compState1

angestoÿen.In diesem Fall matcht die Regel executeExitBehavior3(r,t), die in Abbildung 4.11

dargestellt ist. Der Zustand compState1 ist hier direkt in der Region r, die als Pa-rameter übergeben wurde, enthalten. Durch die Anwendung dieser Regel wird dierekursive Ausführung des Austrittsverhaltens abgeschlossen. Zusätzlich wird hier aufden Zuständen compState2 und compState1 die Regel destroyMarkerInLeavedRe-

gion(t) aufgerufen. Durch den Parameter t vom Typ Transition wird entschieden,welche von den zwei existierenden Regeln, die in Abbildung 4.12 dargestellt sind,aufgerufen werden soll. Die Regel im linken Teil der Abbildung matcht dann, wennder Zustand, auf dem die Regel aufgerufen wurde, nicht die direkte Quelle der zuschaltenden Transition ist. Falls es sich jedoch bei dem Zustand um die Quelle derTransition t handelt, so matcht die Regel, die im linken Teil der Abbildung dargestelltist. Hier kann man sehen, dass durch die Anwendung dieser Regel der im Zustandenthaltene Marker nicht zerstört wird. Dieser Schritt ist notwendig, da der im Quell-zustand der Transition enthaltene Marker später für das Betreten des Zielzustands

54 WS 2009/2010


der Transition benötigt wird.Durch die Ausführung der hier vorgestellten Regeln ist das Verlassen der Quellzu-

stände der schaltenden Transition aus dem Beispiel in Abbildung 4.6 abgeschlossen.Im nächsten Unterabschnitt wird das Schalten der Transition vorgestellt, das denzweiten Schritt bei der Durchführung einer Zustandskon�guration bildet.


Abbildung 4.12.: Smallstep-Regeln destroyMarkerInLeavedRegion(t)

Schalten (Ausführen) einer Transition Nachdem in den Quellzuständen einer zuschaltenden Transition das Austrittsverhalten ausgeführt wurde (siehe Abbildung4.5), wird nun mit der Ausführung der Transition fortgefahren. Dies geschieht durchden Aufruf der Regel startTransitionExecution(), die in Abbildung 4.13 dargestelltist.



Abbildung 4.13.: Smallstep-Regel startTranstionExecution()

Wie aus dem Laufzeit-Metamodell bekannt ist, ist jede Transition einer Laufzeit-Statemachine über eine Referenz execute mit einem Objekt vom Typ TransitionExe-cution verbunden. Durch die Ausführung der Regel startTransitionExecution() wirddie entsprechende Transition einer Laufzeit-Statemachine durch die WertzuweisungtransitionExecuted':=true als ausgeführt markiert. Bezogen auf das Beispiel in Ab-bildung 4.6 wird durch die Wertzuweisung der Regel die Transition t1 als ausgeführtmarkiert.

Betreten der Zielzustände einer Transition Nachdem das Schalten der Transitionals ausgeführt markiert worden ist, wird durch den Regel-Aufruf setMarkersOnTar-

getStateCon�guration(ns) (siehe Abbildung 4.5) der letzte Schritt für die Durchfüh-rung einer Zustandskon�guration angestoÿen. Als erstes müssen alle Zielzuständeder Transition mit einem Marker versehen werden. Danach wird die Ausführung desEintrittsverhalten angestoÿen. Dabei ist zu beachten, dass mit dem Eintrittsverhal-ten des Zustands begonnen wird, der direkter Unterzustand der Region ist, die dernächste gemeinsame Vorfahre des Quell -und Zielzustands der Transition ist. Bezogenauf das Beispiel in Abbildung 4.6 wäre dies der Zustand compState3.Durch die Ausführung der Regel setMarkersOnTargetStateCon�guration(ns), die

in Abbildung 4.14 dargestellt ist, wird der Marker vom Quellzustand einer ausgeführ-ten Transition zum Zielzustand der Transition bewegt. In dem Beispiel in Abbildung4.6 wird durch den Aufruf dieser Regel der in dem Zustand compState2 enthalteneMarker zum Zustand C bewegt. Dabei werden die Werte der Attribute des Markersund der TransitionExecution durch Zuweisungen auf false zurückgesetzt. Die Regionr, die dem gröÿten gemeinsamen Vorfahren der Zustände compState2 und C ent-spricht, wird hier als Parameter an die Regel setStateCon�guration(r) übergeben,die auf dem Zielzustand der Transition aufgerufen wird. Von dieser Regel existierensechs Varianten, die für unterschiedliche Szenarien ausgelegt sind.Die Regel setStateCon�guration2(r), dargestellt in Abbildung 4.15 setzt voraus,

dass der Zustand, auf dem diese aufgerufen wurde, einen Marker enthält. Durcheinen rekursiven Aufruf wird auf dem übergeordnetem Zustand die gleiche Regelbzw. eine von den sechs passenden Varianten der Regel setStateCon�guration(r),deren Objektmuster auf die vorliegende Situation passt, aufgerufen.

56 WS 2009/2010


Abbildung 4.14.: Smallstep-Regel setMarkersOnTargetStateCon�guration(ns)

Abbildung 4.15.: Smallstep-Regel setStateCon�guration2(r)

Die Regel in Abbildung 4.15 wird auf dem Zustand C aus dem Beispiel in Ab-bildung 4.6 aufgerufen, und durch die Ausführung dieser wird auf dem ZustandcompState3 die Regel setStateCon�guration3(r), die in Abbildung 4.16 dargestelltist, aufgerufen. Durch die Ausführung dieser Regel wird in dem Zustand compState3

ein Marker erzeugt, und auf dem gleichem Zustand wird die Rekursion durch einenRegel-Aufruf fortgesetzt. Falls es sich bei dem vorliegendem Zustand (hier comp-State3) um einen orthogonalen Zustand handeln würde, so wäre durch die Ausfüh-rung der Regel, in jeder orthogonalen Region, die einen Startzustand besitzt, fürdiesen ein Marker erzeugt worden.Nachdem in dem Zustand compState3 ein Marker erzeugt worden ist, wird durch

den rekursiven Aufruf die Regel setStateCon�guration(r), die in Abbildung 4.17 dar-gestellt ist, aufgerufen. Durch diese Regel wird die Rekursion abgebrochen, d.h. derdirekte Unterzustand (hier compState3) der Region r, die der nächste gemeinsameVorfahre von dem Quell -und Zielzustand der Transition t1 ist, besitzt bereits einenMarker.Durch die Ausführung der Regel aus Abbildung 4.17 wird mit der Ausführung

des Eintrittsverhaltens der Zielzustände der Transition t1 begonnen. In dem in die-



Abbildung 4.16.: Smallstep-Regel setStateCon�guration3(r)

Abbildung 4.17.: Smallstep-Regel setStateCon�guration1(r) als Abbruch der Rekur-sion

ser Arbeit erstellten DMM-Regelsatz existieren 18 Varianten der Smallstep-RegelexecuteState(), von denen durch ein bestimmtes vorliegendes Zustands-Szenario derLaufzeit-Statemachine eine Regel matcht. Für die Ausführung des Eintrittsverhal-tens von Zustand compState3 wird die Regel executeState7(), die in Abbildung 4.18dargestellt ist, aufgerufen.Durch die Ausführung der Regel wird das Eintrittsverhalten von Zustand comp-

State3 durch die Zuweisung entryBehaviorExecuted':=true in dem entsprechendemMarker als ausgeführt markiert. Falls es sich beim Zustand compState3 um einenorthogonalen Zustand mit Regionen, die Startzustände enthalten, handeln würde,so würde als nächstes die Ausführung der von diesen Startzuständen ausgehendenTransitionen, gefolgt von dem Eintrittsverhalten der Zielzustände dieser Transitio-nen, angestoÿen werden (siehe Regel-Aufruf executeTransition() in Abbildung 4.18).Da jedoch der Zustand compState3 keine solche Regionen besitzt, wird durch denrekursiven Aufruf einer Regel executeState() mit der Ausführung des Eintrittsver-haltens des Unterzustands C fortgefahren.Für die Ausführung des Eintrittsverhaltens von Zustand C ist die Regel execute-

State3() zuständig, die in Abbildung 4.19 dargestellt ist. Die Regel setzt voraus, dassdas Eintrittsverhalten in dem übergeordnetem Zustand (in diesem Fall compState3)

58 WS 2009/2010


Abbildung 4.18.: Smallstep-Regel executeState7()

als ausgeführt markiert ist. Desweiteren wird vorausgesetzt, dass der Zustand, derden Kontext-Knoten bildet (hier Zustand C), keine eingehende Transition besitzt, dievon einem Pseudozustand Fork kommt. Diese Forderung spielt für die Ausführungdes Eintrittsverhaltens keine Rolle, ist jedoch erforderlich, um das Matchen dieserRegel bei bestimmten Szenarien (in denen eine andere Variante der gleichnamigenRegel matcht) auszuschlieÿen.

Abbildung 4.19.: Smallstep-Regel executeState3()

Durch die Ausführung der Regel executeState3() aus Abbildung 4.19, ist das Ein-trittsverhalten aller Zielzustände der Transition t1 aus dem Beispiel in Abbildung4.6 abgeschlossen markiert.Die Ausführung des Eintrittsverhaltens der Zielzustände einer geschalteten Transi-

tion bildet den dritten und letzten Schritt bei der Durchführung einer Zustandskon-



�guration. Somit ist die Durchführung einer Zustandskon�guration, bestehend ausden Schritten �Verlassen der Quellzustände�, �Schalten der Transition� und �Betretender Zielzustände� abgeschlossen.

Nachdem die Durchführung einer Zustandskon�guration abgeschlossen worden ist,be�ndet sich eine vorliegende Laufzeit-Statemachine in einer gültigen Zustandskon-�guration, sodass wieder eine von den fünf zu Verfügung stehenden Bigstep-Regelnnamens �reTransition()# auf das vorliegende Szenario angewendet werden kann, umdie Durchführung einer weiteren Zustandskon�guration anzustoÿen.Die in der Abbildung 4.5 dargestellte Regel kommt immer dann zur Anwendung,

wenn es sich bei der Quelle und dem Ziel einer gegebenen Transition um Zustän-de (States) handelt. Wie in Kapitel 2 eingeführt wurde, kann eine Transition alsQuelle oder Ziel auch Pseudozustände enthalten. Da Pseudozustände laut UML-Spezi�kation kein Verhalten besitzen können, sieht die Durchführung einer Zustands-kon�guration in diesen Fällen etwas anders aus. Falls z.B. bei einer gültigen Zu-standskon�guration in einer Laufzeit-Statemachine die Quelle einer zu schaltendenTransition ein Pseudozustand ist, so wird bei der Durchführung einer Zustandskon�-guration durch eine entsprechende Bigstep-Regel �reTransition()# der erste Schritt(Verlassen der Quellzustände) weggelassen.

4.4.2.3. Beenden einer UML Statemachine

Während eine Statemachine durchlaufen wird, wandert ein Marker auf einem Pfadvom Startzustand zum Endzustand über die dazwischen liegenden Zustände, Pseu-dozustände und Transitionen. Wann immer ein Marker einen Zustand betritt, wirddurch entsprechende Regeln ein Prozess angestoÿen, durch den der Zustand abgear-beitet wird, d.h. sein Verhalten durch entsprechende Attrirbutwerte als ausgeführtmarkiert wird. In dem Syntax-Metamodell für UML Statemachines ist festgelegt, dassein Endzustand (FinalState) eine Spezialisierung des Zustands (State) ist, d.h. dieKlasse FinalState erbt von der Klasse State (siehe Syntax-Metamodell in Abbildung2.1).Bei der Regel �nishStateMachine(), die in Abbildung 4.20 dargestellt ist, han-

delt es sich um eine SmallStep-Regel, die von einer Regel executeState() aufgerufenwird. Diese Regel sorgt dafür, dass alle Marker in den Endzuständen der vorliegen-den Statemachine zerstört werden und somit ist ein Pfad vom Startzustand zumEndzustand komplett abgearbeitet worden.

Abbildung 4.20.: Smallstep-Regel �nishStateMachine() zum Beenden einer UMLStatemachine

60 WS 2009/2010


In dem nächsten Abschnitt werden die wesentlichen Regeln vorgestellt, die dieEigenschaften und die Funktionsweise von Pseudozuständen bei der Modellierung inStatemachines beschreiben.

4.4.3. Regeln für Pseudozustände

In Kapitel 2 wurde eine Einführung in UML Statemachines gegeben, in der auch dieEigenschaften von Pseudozuständen und deren Zweck bei der Verwendung in State-machines vorgestellt wurden. Im Folgenden werden die DMM-Regeln vorgestellt, wel-che der Abarbeitung von Pseudozuständen dienen. Hier soll noch mal daran erinnertwerden, dass ein Pseudozustand kein Verhalten (entry-, do-, exitBehavior) besitzenkann. Das bedeutet, dass während ein Pseudozustand einen Marker enthält, sich dievorliegende Laufzeit-Statemachine in keiner gültigen Zustandskon�guration be�ndet,d.h. eine Durchführung einer Zustandskon�guration noch nicht abgeschlossen ist.

4.4.3.1. Junction und Choice

Der Sinn und Zweck beim Einsatz der Pseudozustände Junction und Choice wurde inKapitel 2.2.8.1 und 2.2.8.2 anhand konkreter Beispielmodelle vorgestellt. Dabei wirddie Verwendung eines Pseudozustands Junction als static condition branch und dieVerwendung eines Pseudozustands Choice als dynamic condition branch bezeichnet(siehe auch UML Spezi�kation [7], S. 542).Durch die in Kapitel 4.4.1 festgelegten Vereinfachungen für Trigger und Bedin-

gungen bei der Beschreibung des Verhaltens einer UML Statemachine durch einTransitionssystem folgt, dass sowohl ein Junction als auch ein Choice eine identischeSemantik aufweisen und somit auch durch identische Regeln beschrieben werden.

Bei der Beschreibung der Durchführung einer Zustandskon�guration wird als ab-schlieÿender Schritt das Eintrittsverhalten der Zielzustände einer Transition ausge-führt. Dies gilt jedoch nur dann, wenn es sich bei dem Ziel der vorliegenden Transitionum einen Zustand (State) handelt. Falls das Ziel der Transition ein Pseudozustand(Pseudostate) ist, so muss der bei diesem Pseudozustand angekommene Marker übereine ausgehende Transition durch geeignete Regeln zum nächsten Ziel weiter bewegtwerden (bis ein Zustand erreicht wird).In der Abbildung 4.21 sind zwei Regeln dargestellt, die durch eine invocation

executeState() bei der Ausführung eines abschlieÿenden Schrittes der Durchführungeiner Zustandskon�guration aufgerufen werden, falls es sich bei dem Ziel-Knoten umeinen entsprechenden Typen (Junction oder Choice) handelt.Die Ausführung der in der Abbildung 4.21 dargestellten Regeln bewirkt keine Än-

derung. Die Verwendung solcher Smallstep-Regeln ist in der in dieser Arbeit erstelltenDMM-Spezi�kation notwendig, da bei der Durchführung einer Zustandskon�gurationdurch die Anwendung einer entsprechenden Regel �reTransiton()#, die Ausführungdes Betretens der Ziele einer Transition immer einen Aufruf einer Smallstep-RegelexecuteState() zu Folge hat.



Abbildung 4.21.: Smallstep-Regeln executeState6() (links) und executeState8()

(rechts) zum Durchlaufen eines Choices und Junctions

Um einen bei einem Junction oder Choice angekommenen Marker über ausge-hende Transitionen zum nächsten Ziel weiter zu bewegen, kommt die Bigstep-Regel�reTransition1()# zum Einsatz, die in Abbildung 4.22 dargestellt ist.

Abbildung 4.22.: Bigstep-Regel �reTransition1()#

Diese Regel wird nicht nur zum Schalten einer Transition verwendet, die einenJunction oder Choice als Quelle besitzt, sondern gilt für einen beliebigen Pseudozu-stand, der die Quelle einer vorliegenden Transition darstellt. Durch die Ausführungdieser Regel wird die Ausführung der von dem Pseudozustand ausgehenden Tran-sition angestoÿen und anschlieÿend über den Aufruf setMarkersOnTargeStateCon-

�guration(r) und der Ausführung der entsprechenden Regel (siehe Abbildung 4.14)der Marker zum Ziel der Transition bewegt, um da entweder ein Eintrittsverhaltenanzustoÿen (falls das Ziel ein Zustand ist) oder den Marker zum nächst möglichenZiel zu bewegen (falls das Ziel ein Pseudozustand ist).

4.4.3.2. Fork

Wie bereits in Kapitel 2 eingeführt wurde, wird ein Pseudozustand Fork verwen-det, um einen orthogonalen Zustand zu betreten und dann eine parallele Ausfüh-rung der Regionen anzustoÿen. Anhand des Beispiels in Abbildung 2.13 wurde dieparallele Ausführung zweier Regionen vorgestellt. An diesem Beispiel werden hierdie Regeln vorgestellt, die für das Betreten eines orthogonalen Zustands in einerLaufzeit-Statemachine über einen Pseudozustand Fork zuständig sind.Sobald der Pseudozustand Fork als Ergebnis der Durchführung einer Zustands-

kon�guration betreten wird, wird durch einen Regel-Aufruf executeState() die RegelexecuteState9(), die in Abbildung 4.23 dargestellt ist, aufgerufen. Durch die Aus-führung dieser Regel wird eine von zwei existierenden Varianten der Regel initiali-zeTransitionExecution() aufgerufen. In Abbildung 4.24 ist die Regel initializeTransi-

62 WS 2009/2010


Abbildung 4.23.: Smallstep-Regel executeState9() zur Abarbeitung des Pseudozu-stands Fork

tionExecution1() dargestellt, deren Aufgabe es ist, eine von einem Fork ausgehendeTransition auszuführen und anschlieÿen durch den rekursiven Aufruf initializeTransi-tionExecution() entweder sich selbst oder die Regel initializeTransitionExecution2(),durch die die Rekursion beendet wird, aufzurufen.

Abbildung 4.24.: Smallstep-Regel initializeTransitionExecution1() zur Ausführungder vom Fork ausgehenden Transitionen

Bei der Ausführung der Regel initializeTransitionExecution1(), die in Abbildung4.24 dargestellt ist, wird als Erstes die Regel startTransitionExecution() aufgerufen,wodurch die entsprechende Transition als Ausgeführt gekennzeichnet wird. Bezogenauf das Beispiel in Abbildung 2.13 wird die Regel initializeTransitionExecution1()ein mal ausgeführt, wodurch eine vom Pseudozustand Fork ausgehende Transition(t1 oder t2) als ausgeführt markiert wird.Danach wird durch den rekursiven Aufruf initializeTransitionExecution() die Re-

gel, die in Abbildung 4.25 dargestellt ist, aufgerufen.Durch die Ausführung dieser Regel ist die Rekursion beendet und nachdem die

zweite vom Fork ausgehende Transition (in Abbildung 2.13) ausgeführt worden ist,wird durch den Regel-Aufruf setStateCon�guration(r) die Regel setStateCon�gura-tion4(r) aufgerufen, durch die in jedem Zielzustand der ausgehenden Transitioneneines Forks ein Marker erzeugt wird. Diese Regel ist in Abbildung 4.26 dargestellt.



Abbildung 4.25.: Smallstep-Regel initializeTransitionExecution2()

Abbildung 4.26.: Smallstep-Regel setStateCon�guration4() zur Erzeugung von Mar-kern in allen über ein Fork betretenen Regionen

Nachdem durch die Ausführung der Regel setStateCon�guration4(r) für die Zu-stände State1 und State2 Marker erzeugt worden sind, wird in der gleichen Regeldurch einen rekursiven Aufruf auf dem orthogonalen Zustand OrthogonalState dieRegel setStateCon�guration5(r) aufgerufen, die in Abbildung 4.27 dargestellt ist.Hier wird zuerst durch den Aufruf createMarker() ein Marker in dem Zustand Or-

thogonalState erzeugt und durch die Rekursion setStateCon�guration(r) wiederumeine für das vorliegende Szenario passende Regel aufgerufen. In diesem Fall matchtdie Regel setStateCon�guration1(r) (siehe Abbildung 4.17 ), durch die die Rekursionunterbrochen und die Ausführung des Eintrittsverhaltens angestoÿen wird. Durch die

64 WS 2009/2010


Abbildung 4.27.: Erzeugen eines Marker im orthogonalen Zustand

Ausführung der Regel setStateCon�guration1(r) wird durch den Regel-Aufruf execu-teState() eine Variante der gleichnamigen Regel ausgeführt, wodurch das Eintritts-verhaltens vom Zustand OrthogonalState als ausgeführt markiert wird. Danach wirddas Eintrittsverhalten der Unterzustände State1 und State1 als ausgeführt markiert.Hierbei werden durch entsprechende Regeln in dem erzeugendem Transitionssystemzwei Pfade gebildet, durch die die parallele Abarbeitung der Zustände State1 undState2 dargestellt werden soll. Auf einem Pfad wird die Ausführung des Eintritts-verhaltens von Zustand State1 gefolgt vom Eintrittsverhalten von Zustand State1

dargestellt. Auf dem anderen Pfad wird die Ausführung in umgekehrter Reihenfolgedargestellt.Auf diese Weise werden im Transitionssystem mehrere Pfade erzeugt, die eine

Permutation für die Ausführung der betretenen Zustände in orthogonalen Regionendarstellen. Durch die Permutation wird in einem Transitionssystem eine paralleleAusführung von Verhalten beschrieben (siehe auch Abschnitt Parallelität in Kapitel5.3.2).

4.4.3.3. Join

Der Pseudozustand Join wird bei der Modellierung in UML Statemachines verwen-det, um einen parallelen Ablauf in einem orthogonalen Zustand zu beenden. In Ab-bildung 2.13 wurde dies anhand eines Beispiels dargestellt und erläutert. Bezogenauf dieses Beispiel entspricht das Auslösen des Trigger t5 dem Matchen der Bigstep-Regel �reTransition5()#, die in Abbildung 4.28 dargestellt ist.Die Regel setzt voraus, dass in allen Quellzuständen der in den Pseudozustand Join

eingehenden Transitionen das Eintrittsverhalten bereits ausgeführt worden ist, d.h.es muss eine gültige Zustandskon�guration vorliegen. Durch die Ausführung dieserRegel werden weitere Regeln aufgerufen, deren Ausführung dann den Zustandsüber-gang von den Quellzuständen des Pseudozustands Join zum Zielzustand beschreibt.



Abbildung 4.28.: Bigstep-Regel �reTransition5()# zum Verlassen eines orthogonalenZustands über ein Pseudozustand Join

Durch den Regel-Aufruf startExitingExecution(r,t1) werden weitere Regeln aufge-rufen, deren Ausführung die Ausführung des Austrittsverhaltens der Zustände State3und State4, gefolgt vom Austrittsverhalten des orthogonalen Zustands Orthogonal-State veranlasst.Als nächstes werden dann durch den Regel-Aufruf initializeTransitionsToExecute()

die in den Pseudozustand Join eingehenden Transitionen ermittelt und als ausgeführtmarkiert. Die Marker in den Quellzuständen werden beim Verlassen dieser zerstört;dadurch ist es erforderlich im Pseudozustand Join einen neuen Marker zu erzeugen,um den Zustandsübergang fortzusetzen. Dies geschieht durch den Aufruf und dieAusführung der Regel createMarker().Als nächster Schritt wird die Regel startTransitionExecution() aufgerufen und aus-

geführt, wodurch die vom Join ausgehende Transition als ausgeführt markiert wird.Danach wird durch den Aufruf der Regel setMarkersOnTargetStateCon�guration(r)

der Zielzustand betreten, um dessen Eintrittsverhalten auszuführen.

4.4.3.4. Entry Point

Wie in Kapitel 2 bereits erläutert wurde, dient die Verwendung von Entry Points

hauptsächlich dem Zweck, das Eintrittsverhalten des zu betretenden Zustands zwi-schen der Ausführung des Verhaltens der Transitionen, die durch einen Entry Point

verbunden sind, auszuführen. Dies wurde anhand eines Beispiel in Abbildung 2.14dargestellt und erläutert.Hier werden nur die Regeln vorgestellt, die zur Anwendung kommen, sobald beim

Durchlaufen einer UML Statemachine ein Entry Point betreten worden ist.

66 WS 2009/2010


Nachdem die in den Entry Point eingehende Transition (siehe Abbildung 2.14)ausgeführt worden ist, wird die Regel executeState12(), die in Abbildung 4.29 dar-gestellt ist, aufgerufen. Die Regel setzt voraus, dass in den Unterzuständen eineszusammengesetzten Zustands keine Marker enthalten sind. Bezogen auf das Beispielin Abbildung 2.14 wird durch die Ausführung dieser Regel das Eintrittsverhalten desZustands Composite State ausgeführt.

Abbildung 4.29.: Smallstep-Regel executeState12() zur Ausführung des Eintrittsver-halten eines über einen Entry Point betretenen Zustands

Anschlieÿend wird durch den Regel-Aufruf enterRegionsOverEntryPoint() die Re-gel aufgerufen, die in Abbildung 4.30 dargestellt ist. Durch die Ausführung dieserRegel wird die Regel executeTransition() aufgerufen und dadurch die vom Entry

Point ausgehende Transition als ausgeführt markiert und der Unterzustand A betre-ten.

Abbildung 4.30.: Smallstep-Regel enterRegionsOverEntryPoint()

4.4.3.5. Exit Point

Der Hauptzweck bei der Verwendung von Exit Points liegt darin, dass das Austritts-verhalten des zu verlassenden Zustands zwischen der Ausführung des Verhaltens derTransitionen, die durch den Exit Point verbunden werden, ausgeführt wird. Dieswurde anhand eines Beispiels in Abbildung 2.15 dargestellt und erläutert.Für das Verlassen eines zusammengesetzten Zustands über ein Exit Point ist die

in der Abbildung 4.31 dargestellte Bigstep-Regel �reTransition4()# zuständig. Das



Matchen der Regel entspricht dem Auslösen eines Triggers, der einer Transition zu-geordnet ist, die als Quelle einen Zustand und als Ziel einen Exit Point hat. Bezogenauf das Beispiel in Abbildung 2.15 entspricht das Auslösen des Triggers t2 der Aus-führung der Regel �reTransition4()#. Hier wird durch das Ausführen dieser Regelals Erstes das Austrittsverhalten von Zustand A als ausgeführt markiert. Danachschaltet die vom Zustand A ausgehende Transition, und schlieÿlich wird das Ziel(Exit Point) der Transition durch den Regel-Aufruf setMarkersOnTargetStateCon�-

guration(r) betreten.

Abbildung 4.31.: Verlassen eines zusammengesetzten Zustands über ein Exit Point

Durch den Regel-Aufruf setMarkersOnTargetStateCon�guration(r) werden weite-re Regeln aufgerufen, so dass das Austrittsverhalten des Zustands Composite Stateausgeführt wird. Danach matcht die Bigstep-Regel �reTransition1()#, die in Abbil-dung 4.22 vorgestellt wurde. Durch die Ausführung dieser Regel wird die vom Exit

Point ausgehende Transition ausgeführt und anschlieÿend das Ziel dieser Transitionbetreten.

4.4.3.6. Shallow History

In Kapitel 2.2.8 wurde anhand eines Beispiels in Abbildung 2.16 die Semantik desPseudozustands Shallow History bei der Modellierung in Statemachines erläutert.Hier werden die wesentlichen Regeln vorgestellt, durch die die Semantik beschriebenwird.Sobald in einer Laufzeit-Statemachine ein Pseudozustand Shallow History betre-

ten wird, so wird durch den Regel-Aufruf executeState() die Regel executeState13()aufgerufen, die in Abbildung 4.32 dargestellt ist.Durch diese Regel wird eine von zwei existierenden Regeln namens initializeHis-

toryMarker() aufgerufen. Bezogen auf das Beispiel in Abbildung 2.16 wird beimersten Betreten des Zustands Process BCH durch den Regel-Aufruf initializeHisto-ryMarker() die Regel initializeHistoryMarker1() aufgerufen, die in Abbildung 4.33dargestellt ist.Durch die Ausführung dieser Regel wird in dem Zustand B ein HistoryMarker

erzeugt und die vom Pseudozustand Shallow History ausgehende Transition als aus-geführt markiert. Hier sei darauf hingewiesen, dass die Regel in Abbildung 4.33 nur

68 WS 2009/2010


Abbildung 4.32.: Betreten eines Zustands über ein Shallow History

Abbildung 4.33.: Initialisierung der HistoryMarker

beim erstmaligen Betreten des Zustands Process BCH matcht.Nun wird durch das Anwenden weiterer Regeln, die gröÿtenteils in Abschnitt

4.4.2.2 eingeführt wurden, irgendwann der Zustand C erreicht und sein Eintrittsver-halten als ausgeführt markiert, so dass eine gültige Zustandskon�guration vorliegt.Durch das Matchen einer passenden Bigstep-Regel �reTransition()# (siehe Abbil-dung 4.5) wird eine Durchführung einer Zustandskon�guration angestoÿen. Als Ers-tes werden die Quellzustände (Zustand C und Process BCH) der durch den Triggert5 schaltenden Transition verlassen. Nachdem das Austrittsverhalten von Zustand Cdurch eine entsprechende Regel als ausgeführt markiert worden ist, wird mit der Aus-führung des Austrittsverhaltens von Zustand Process BCH fortgefahren. Hierfür istdie Regel executeExitBehavior7(r), die in Abbildung 4.34 dargestellt ist, zuständig.

Abbildung 4.34.: Verlassen eines über ein Shallow History betretenen Zustands



Durch die Ausführung dieser Regel wird das Austrittsverhalten vom Zustand Pro-

cess BCH als ausgeführt markiert. Um beim Verlassen eines Zustands, der über eineShallow History betreten wurde, sich den zuletzt aktiven Zustand zu merken, werdendie Regeln destroyHistoryMarker() und createHistoryMarker() in der vorgegebenenReihenfolge aufgerufen und ausgeführt. Bezogen auf das Beispiel in Abbildung 2.16wird durch die Ausführung der genannten Regeln der im Zustand B enthaltene His-toryMarker gelöscht und in dem Zustand C ein neuer HistoryMarker erzeugt.Falls nun der Zustand Process BCH erneut betreten wird, so muss unmittelbar

nach der Ausführung des Eintrittsverhaltens von Zustand Process BCH das Ein-trittsverhalten von Zustand C ausgeführt werden.

Abbildung 4.35.: Ermittlung des zuletzt aktiven Zustands

In Abbildung 4.32 wurde die Regel namens executeState13() vorgestellt, derenAusführung eine von zwei existierenden Regeln namens initializeHistoryMarker()

aufruft. Bei einem erneuten Betreten des Zustands Process BCH wird durch die-sen Aufruf die Regel initializeHistoryMarker(), die in Abbildung 4.35 dargestellt ist,aufgerufen. Die Ausführung dieser Regel sorgt dafür, das der im Pseudozustand Shal-low History enthaltene Marker zum Zustand C bewegt wird. Da alle Regeln, die zurAusführung des Verhaltens eines Zustands zuständig sind, einen Marker in diesemvoraussetzen, ist somit sichergestellt, dass nach der Ausführung des Eintrittsverhal-tens von Zustand Process BCH das Eintrittsverhalten von Zustand C ausgeführtwird.

4.4.3.7. Deep History

Die Semantik eines Psuedozustands Deep History unterscheidet sich von der einesShallow History nur dadurch, dass durch diesen zusätzlich alle aktiven Zuständein den indirekten Unterregionen eines zusammengesetzten Zustands beim Verlassenvermerkt werden müssen. Dieser Unterschied wurde in Kapitel 2.2.8.8 anhand einesBeispiels vorgestellt und diskutiert. Zu Beginn von Kapitel 2 wurde in Abbildung 2.19für die Modellierung der Abspielmodi eines Autoradios der Pseudozustand Shallow

History mitverwendet. Dabei sollte durch diesen der im Radiobetrieb zuletzt aktiveSender vermerkt werden, um bei einem erneutem Umschalten vom CD-Betrieb inden Radiobetrieb den zuletzt aktiven Sender abzuspielen. Anhand dieses Beispiels

70 WS 2009/2010


werden im Folgenden die Regeln vorgestellt, die für die Ermittlung der zuletzt akti-ven Zustände zuständig sind.

Sobald der Pseudozustand Deep History im Laufe der Durchführung einer Zu-standskon�guration betreten wird, wird durch einen Regel-Aufruf executeState() dieRegel executeState15() aufgerufen, die in Abbildung 4.36 dargestellt ist.

Abbildung 4.36.: Betreten eines zusammengesetzten Zustands über ein Deep History

Durch die Ausführung dieser Regeln wird zuerst eine Variante der Regel initia-lizeHistoryMarkers() und danach eine Variante der Regel initializeHistoryMarker()

aufgerufen. Von der Regel initializeHistoryMarkers() existieren vier Varianten, vondenen je nach vorliegender Situation eine matcht. Die Aufgabe dieser Regeln ist eszu ermitteln, ob in den zusammengesetzten Unterzuständen innerhalb des zusam-mengesetzten Zustands bereits HistoryMarker existieren, und wenn ja, dann sollenin diesen Zuständen Marker erzeugt werden. Bezogen auf das Beispiel in Abbildung2.19 soll hierdurch ermittelt werden, ob das Autoradio nach dem Einschalten bereitsin dem Radiobetrieb gewesen war, und wenn ja, welcher der Sender zuletzt abgespieltwurde.Falls das Autoradio nach dem Einschalten zum ersten Mal in den Radiobetrieb

versetzt wurde, so wird durch den Regel-Aufruf initializeHistoryMarkers() die Re-gel initializeHistoryMarkers1() aufgerufen, die in Abbildung 4.37 dargestellt ist. DieAusführung dieser Regel nimmt keinerlei Änderungen an der Statemachine vor, dabeim ersten Betreten des Zustands Radiobetrieb lediglich der Regel-Aufruf initiali-zeHistoryMarker() (siehe Regel executeState() in Abbildung 4.36) eine Änderung inder Statemachine vornimmt. In diesem Fall wird die bereits in Abbildung 4.33 vor-gestellte Regel initializeHistoryMarker1() ausgeführt, wodurch beim Autoradio imRadiobetrieb den Sender AM gewählt und abgespielt wird.

Abbildung 4.37.: Erstes Betreten eines Zustands über ein Deep History

Sollte das Autoradio nun irgendwann im Radiobetrieb durch das Drücken der Taste



AM/FM in den Sender FM gewechselt werden, so wird hier standardmäÿig (beimerstem Betreten) die Frequenz FM1 gewählt und abgespielt. Durch das Drückender Taste CD-Betrieb wechselt das Autoradio in den CD-Betrieb. Beim Verlassenwird durch die Ausführung entsprechender Regeln in dem Zustand FM und in demZustand FM1 jeweils ein HistoryMarker erzeugt. Bei einem erneuten Betreten desRadiobetriebs (über die Taste �Radiobetrieb�) wird durch die Ausführung der RegelexecuteState15() (siehe Abbildung 4.36) zuerst die in Abbildung 4.38 dargestellteRegel initializeHistoryMarkers4() aufgerufen.

Abbildung 4.38.: Smallstep-Regel initializeHistoryMarkers4(): Erneutes Betreten ei-nes Zusammengesetzten Zustands über ein Deep History

Durch die Ausführung dieser Regel wird in dem Zustand FM1 (der einen History-

Marker enthält) durch den Aufruf und die Ausführung der Regel createMarker() einMarker erzeugt. Danach wird durch den Regel-Aufruf initializeHistoryMarker()(sieheAbbildung 4.36) die bereits in Abbildung 4.35 dargestellte Regel initializeHistory-Marker2() aufgerufen und ausgeführt, wodurch in dem Zustand FM ein Marker er-zeugt wird.Nachdem alle nötigen Regeln zur Initialisierung von Markern im Zielzustand aus-

geführt worden sind, ist der Sender FM mit der Frequenz FM1 ausgewählt und wirdnun abgespielt.Auf diese Weise wird die Semantik eines Pseudozustands Deep History unter Ver-

wendung von HistoryMarkern in den entsprechenden Regeln formal beschrieben.

4.4.3.8. Terminate

Die Semantik des Pseudozustands Terminate wurde in Abbildung 2.18 vorgestelltund erläutert. Die Besonderheit dabei war, dass sobald ein Trigger einer Transitionauslöst, die als Ziel einen Pseudozustand Terminate hat, so wird keinerlei Austritts-verhalten in den Quellzuständen der schaltenden Transition ausgeführt. Statt dessenwird nur die Transition ausgeführt und schlieÿlich die UML Statemachine beendet.Das Beenden einer Statemachine durch Betreten eines Terminates wird durch dieRegel �reTransition6()# beschrieben, die in Abbildung 4.39 dargestellt ist.

72 WS 2009/2010


Abbildung 4.39.: Beenden einer Statemachine über ein Terminate

Durch die Ausführung dieser Regel werden die Regeln startTransitionExecution()

und terminateStateMachine() in der angegebenen Reihenfolge aufgerufen und ausge-führt. Durch Ausführung der Regel startTransitionExecution() wird die schaltendeTransition als ausgeführt markiert.

Abbildung 4.40.: Löschen der Marker in den Zuständen der Statemachine

Durch die Ausführung der Regel terminateStateMachine(), die in Abbildung 4.40dargestellt ist, werden die in der Statemachine enthaltenen Marker gelöscht. Auf dieseWeise wird die Abarbeitung einer vorliegenden Statemachine durch das Erreicheneines Pseudozustands Terminate beendet.

4.5. Diskussion

Zu Beginn dieses Kapitels wurde in Abschnitt 4.4.1 vorgestellt, dass während ei-ne UML Statemachine durchlaufen wird, diese zu jedem Zeitpunkt sich entweder indem Zustand �Gültige Zustandskon�guration� oder im Zustand �Durchführung einerZustandskon�guration� be�ndet. Während eine Statemachine sich in einer gültigenZustandskon�guration be�ndet, wird durch das Auslösen eines Triggers an einerTransition die Durchführung einer Zustandskon�guration angestoÿen. Das Anstoÿender Durchführung einer Zustandskon�guration wurde in dieser Arbeit ausschlieÿ-lich durch Bigstep-Regeln realisiert. Die Durchführung einer Zustandskon�gurationist ein atomarer Prozess, so dass dieser durch keine Ereignisse abgebrochen werdenkann. Der gesamte DMM-Regelsatz ist somit basierend auf dem in Abschnitt 4.4.1



vorgestellten Szenario aufgebaut.Der in dieser Arbeit entwickelte DMM-Regelsatz kann nun verwendet werden, um

das Verhalten einer UML Statemachine durch ein Transitionssystem zu beschreiben.Dabei gibt es gewisse Einschränkungen seitens der DMM-Spezi�kation, durch dienicht für jede beliebige UML Statemachine ein Transitionssystem erzeugt werdenkann. Dies ist darin begründet, dass es in dem für diese Arbeit vorgegebene Zeitrah-men nicht möglich war, alle Sprachelemente bzw. die Kombinationen dieser durchBeispielmodelle zu untersuchen, um für diese dann entsprechende DMM-Regeln zuentwickeln. Durch die testgetriebene Vorgehensweise wurde bei der Erstellung desDMM-Regelsatzes so vorgegangen, das zuerst durch minimale Beispielmodelle dieSemantik der einzelnen Sprachelemente von UML Statemachines untersucht wurde,um diese dann durch DMM-Regeln formal zu beschreiben. Für die Kombination derSprachelemente in einer UML Statemachine wurden nur wenige Beispielmodelle er-stellt und untersucht. Das Beispielmodell in Abbildung 2.19 ist z.B. eins von denBeispielmodellen, bei dem mehrere Sprachelemente (Choice, Deep History, SimpleStates, Composite States) zum Einsatz kommen. Allein durch die Verwendung vonzusammengesetzten Zuständen, die theoretisch eine unendliche Verschachtelungstie-fe ermöglichen, wächst die Zahl der möglichen Beispielmodelle ebenfalls auf eineunendlich hohe Zahl hinaus.Um eine höhere Abdeckung der Sprachkonstrukte der Semantik von UML Statema-

chines zu erreichen, wäre der nächste sinnvolle Schritt, die Untersuchung der verschie-denen Möglichkeiten der Modellierung von Parallelität. Die erstellten DMM-Regelnbehandeln z.B. parallele Abläufe bei denen unter der Verwendung des Pseudozu-stands Fork alle orthogonalen Regionen eines Zustands über die vom Fork ausge-henden Transitionen betreten werden. Die UML erlaubt aber auch, dass nicht alleorthogonalen Regionen über Fork betreten werden müssen. Bei diesen Regionen wirdvorausgesetzt, dass diese über einen Startzustand verfügen müssen, der für das Be-treten dieser Regionen zuständig ist.Eine weitere Möglichkeit der Modellierung von parallelen Abläufen, die bei der

Erstellung der DMM-Regeln nicht berücksichtigt wurde, ist die Verwendung desPseudozustands Entry Point. Die UML erlaubt es einen Entry Point sowohl für dasBetreten von zusammengesetzten Zuständen als auch von orthogonalen Zuständenzu verwenden. In dieser Arbeit wurde die Verwendung eines Entry Points lediglichfür das Betreten eines zusammengesetzten Zustands untersucht.Somit stellt die in dieser Arbeit entwickelte DMM-Spezi�kation lediglich einen

Prototypen dar, um das Verhalten von UML Statemachines formal zu beschreiben.

74 WS 2009/2010

5. Testen der erstellten DMM-Regeln

Nach dem der DMM-Regelsatz für UML Statemachines erstellt wurde, kann die for-male Semantik eingesetzt werden, um z.B. mit Hilfe eines Modelcheckers die Qualitätvon Modellen zu testen. Falls aber die zu Grunde liegende Semantik fehlerhaft ist, sohat das Testen von Modellen durch Modelchecking keine Aussagekraft über die Qua-lität dieser Modelle. Dies ist etwa vergleichbar mit der Durchführung von Unit-Testsfür Java-Programme mit einer fehlerhaften JVM (Java Virtual Machine). Die einzel-nen Java-Programme entsprächen dabei den zu testenden Modellen (um die Qualitätdieser durch das Modelcheking zu untersuchen) und die JVM der zugrundeliegendenformalen Semantik. Durch eine fehlerhafte JVM könnte dann eine Funktion eineszu testenden Java-Programms fälschlicherweise als korrekt interpretiert werden. Umsolche Fehlerquellen zu vermeiden, muss also in erster Linie der Interpreter (JVM)einer verwendeten Sprache fehlerfrei sein.Bezogen auf die Sprache UML Statemachines, muss also in erster Linie die Quali-

tät der formalen Semantik sichergestellt werden. Um also bei der erstellten Semantikeine möglichst hohe Qualitätsstufe zu erzielen, müssen alle im DMM-Regelsatz vor-kommenden Regeln getestet werden.In Abschnitt 5.1 wird die Vorgehensweise erläutert, die bei der Erstellung und dem

Testen der DMM-Regeln verwendet wurde. In Abschnitt 5.2 wird der Testablaufim Detail vorgestellt. Anhand des laufenden Beispiels aus Abbildung 2.19 wird inAbschnitt 5.3 exemplarisch ein Testfall vorgestellt.

5.1. Testgetriebenes Konzept zur Spezi�kation einerSemantik

Die Erstellung des DMM-Regelsatzes basiert auf einer testgetriebenen Vorgehens-weise, die in der Verö�entlichung [11] von C. Soltenborn und G. Engels, beschriebenwird. Die Vorgehensweise ist dabei folgende:

1. Erstellen von Beispielmodellen und Festlegen des zugehörigen erwarteten Ver-

haltens: Nach dem die Semantik der einzelnen Sprachelemente, beschriebenin einer Spezi�kation (in textueller Form), ausführlich untersucht worden ist,werden Beispielmodelle erstellt, in denen die untersuchten Sprachelemente zurAnwendung kommen. Dabei sollen zuerst möglichst kleine Beispielmodelle er-stellt werden, in denen ein bestimmtes Sprachelement untersucht wird. Daserwartete Verhalten des Beispielmodells wird dann durch ein oder mehrere tra-ces of execution events ausgedrückt. Ein trace of execution events de�niert eine

75

Kapitel 5. Testen der erstellten DMM-Regeln

Abfolge von Aktionen (execution events), die der Ausführung des Verhaltensder in dem Beispielmodell verwendeten Sprachelemente entspricht.

2. Erstellen von DMM-Regeln anhand der vorliegenden Beispielmodelle: Nun wer-den mit Hilfe der Beispielmodelle und der zugehörigen traces of execution

events Regeln erstellt, die die Semantik der in den Beispielmodellen untersuch-ten Sprachelemente beschreiben. Dabei sollen die Regeln durch das Anwendenauf ein Beispielmodell das erwartete Verhalten durch ein erzeugtes Transiti-onssystem darstellen.

3. Erstellung und Durchführung von Tests zu den bereits erstellten Regeln: Nach-dem die Semantik der in den Beispielmodellen untersuchten Sprachelementedurch eine Menge von erstellten Regeln formal beschrieben wird, muss über-prüft werden, ob diese Regeln auch das erwartete Verhalten beschreiben. Dabeiwird das Verhalten, welches durch die Anwendung der Regeln auf ein Bei-spielmodell in einem Transitionssystem dargestellt wird, mit dem erwartetemVerhalten verglichen, welches durch die traces of execution events ausgedrücktwird.

Bei der Erstellung neuer Regeln müssen die bereits existierenden Tests regel-mäÿig ausgeführt werden, um somit zu überprüfen, ob durch die neu hinzuge-kommenen Regeln die Semantik in den bereits untersuchten Beispielmodellennicht verfälscht wird.

In Abbildung 5.1 wird ein Vergleich zwischen dem Testen einer Semantik-Spezi�ka-tion und dem konventionellen Testen von Software veranschaulicht. Beim Testen einesSoftwaresystems besteht ein Test aus Eingabedaten und einer erwarteten Ausgabe,die durch die Verarbeitung der Eingabedaten durch das Softwaresystem erwartetwird. Falls die Ausgabe des Softwaresystems mit der erwartete Ausgabe überein-stimmt, so ist der Test erfolgreich, d.h. das Softwaresystem verhält sich wie ge-wünscht.

Beim Testen einer Semantik-Spezi�kation (rechter Teil in Abbildung 5.1) bestehtein Test aus einem Beispielmodell, welches die Eingabedaten für die zu testendeSemantik-Spezi�kation darstellt, und dem erwarteten Verhalten. Bei der Ausführungdes Tests wird die Semantik-Spezi�kation auf ein Beipielmodell angewendet, wo-durch ein Transitionssystem erzeugt wird, welches das Verhalten des Beispielmodellsdarstellt. Der Test ist erfolgreich, falls das aktuelle Verhalten mit dem erwartetenVerhalten übereinstimmt.

Um eine bessere Vorstellung vom Testen einer Semantik-Spezi�kation zu bekom-men, wird im nächsten Abschnitt eine detaillierte Beschreibung über den Testablaufgegeben.

76 WS 2009/2010


Abbildung 5.1.: Vergleich zwischen dem Testen von Software (links) und einerSemantik-Spezi�kation (rechts) (Quelle: [11])

5.2. Testumgebung

In diesem Abschnitt wird der Testablauf für das Testen des DMM-Regelsatzes fürUML Statemachines und die dafür benötigten Werkzeuge vorgestellt. In Abbildung5.2 ist eine Übersicht über einen Testablauf dargestellt. Das erwartete Verhalten einerUML Statemachine wird durch sogenannte traces of execution events beschrieben,deren Aufbau in Unterabschnitt 5.2.1 erläutert wird. Die zu einer UML Statema-chine zugehörigen traces of execution events liegen in einer speziellen Form vor undsind in einer Text-Datei aufgelistet. Die traces of execution events werden mit Hilfeeines Java-Programms CTL Generator (siehe Unterabschnitt 5.2.2) in CTL-Formelntransformiert. Die resultierenden CTL-Formeln werden gegen das durch die Anwen-dung des DMM-Regelsatzes auf ein Laufzeit-Modell resultierende Transitionssystemgetestet. Diese Aufgabe wird von dem GROOVE-Modelchecker durchgeführt, der inUnterabschnitt 5.2.3 vorgestellt wird.

5.2.1. Traces of execution events

Ein trace of execution events de�niert eine Reihenfolge für die Ausführung des Ver-haltens von Zuständen und Transitionen beim Durchlauf einer UML Statemachinevom Startzustand zum Endzustand. Im Folgenden werden die unterschiedlichen Ver-halten, die eine Transition oder ein Zustand besitzen können, als execution events

bezeichnet. Ein trace of execution events besteht aus einer Menge von execution

events, die untereinander durch einen Pfeil �->� sequentiell geordnet sind.

Um einen Durchlauf durch eine UML Statemachine durch die Ausführung desVerhaltens von Transitionen und Zuständen in einem trace zu beschreiben, wurdenfolgende Bezeichnungen festgelegt, durch die die jeweiligen execution events ausge-drückt werden:

• InitialStateExecutes(Startzustandsname): diese Bezeichnung entspricht der Aus-führung des Startzustands einer UML Statemachine. Ein trace beginnt immer



traces of execution events

UML Statemachine

Laufzeit- Statemachine

GROOVEStartzustand

GROOVEGrammatik

GROOVEGenerator

CTL Formeln Transitions-system

CTL Generator

TransformationConverter

EMF2GROOVE

DMM-Regelsatz

transformiert

transformiert transformiert

transformiert

DMM2GXL

beschreiben

Test-Ergebnis

erzeugt

GROOVEModelchecker

Eingabedaten

Verarbeitungseinheiten

Eingabedaten zur Evaluierung

Ausgabe

Abbildung 5.2.: Übersicht des Testablaufs (nach Hornkamp [5])

mit diesem execution event.

• �reTransition(Trigger-Name): entspricht dem Auslösen eines Triggers.

• TransitionExecutes(Trigger-Name): entspricht der Ausführung einer Transiti-on, die durch das Auslösen des angegeben Triggers ausgeführt wird.

• StateExecutes(Zustandsname): entspricht der Ausführung des Eintrittsverhal-tens des angegebenen Zustands.

• StateExecutesDo(Zustandsname): entspricht der Ausführung des Zustandsver-haltens des angegebenen Zustands.

• StateExecutesExit(Zustandsname): entspricht der Ausführung des Austritts-verhaltens des angegebenen Zustands.

Ein Durchlauf des in Abbildung 5.3 dargestellten Ausschnitts aus einer UML State-machine wird somit durch die Form

StateExecutesExit(A) -> TransitionExecutes(t1) -> StateExecutes(B)

in einem trace angegeben. Hiermit wird festgelegt, dass zuerst das Austrittsver-halten von Zustand A ausgeführt wird, gefolgt von der Ausführung der Transitiont1 und der anschlieÿenden Ausführung des Eintrittsverhaltens von Zustand B.

78 WS 2009/2010


t1

Abbildung 5.3.: Ablauf der execution events

Der GROOVE-Modelchecker setzt voraus, dass das erwartete Verhalten durchCTL-Formeln beschrieben wird. Um die traces of execution events aus dem obenbeschriebenen Format in CTL-Formeln zu transformieren, wird ein Java-Programmnamens CTL Generator (siehe Abbildung 5.2) verwendet, das im nächsten Unterab-schnitt vorgestellt wird.

5.2.2. CTL Generator

Um das erwartete Verhalten mit dem tatsächlichen Verhalten zu vergleichen, müssendie im vorigen Unterabschnitt eingeführten Bezeichnungen für die execution events

beim Durchlauf einer Statemachine den entsprechenden Regeln aus dem DMM-Regelsatz zugeordnet werden. Dieser Schritt ist notwendig, damit die execution eventdurch entsprechende Regel-Bezeichnungen ersetzt werden, damit diese in einem Tran-sitionssystem durch den GROOVE-Modelchecker identi�ziert werden können. Dabeiwerden einem execution event aus dem trace eine oder mehrere Regeln aus demDMM-Regelsatz zugeordnet. Ein execution event, der nun durch einen Namen einerRegel ausgedrückt wird, muss noch zusätzlich in einer für den Modelchecker ver-ständlichen Form vorliegen. Hier wird ein Dialekt der temporalen Logik verwendet(siehe auch [6]).Um etwa die Existenz einer Regel r in einem Pfad im Transitionssystem abfra-

gen zu können, muss die Regel durch die Formel EF(r) ausgedrückt werden. Hierwird durch EF(r) die Bedingung gestellt, dass irgendwo auf einem Pfad zwischendem Startzustand und Endzustand im Transitionssystem die Regel r zur Anwen-dung kommen muss.

Das erwartete Verhalten für das Beispiel in Abbildung 5.3 wird aus dem trace

StateExecutesExit(A) -> TransitionExecutes(t1) -> StateExecutes(B)

im CTL-Format in die Form

EF(activeState.StateExecutesExit(A) & EXEF(transition.TransitionExecutes(t1)

& EXEF(targetState.StateExecutes(B)))

transformiert. Durch diese Formel wird angegeben, dass es im Transitionssystemeinen Pfad geben muss, bei dem nach der Ausführung der Regel activeState.StateExe-cutesExit(A) irgendwann die Regel transition.TransitionExecutes(t1) ausgeführt wirdund danach irgendwann die Regel targetState.StateExecutes(B) ausgeführt wird.



Das Java-Programm CTL-Generator wurde in dieser Arbeit implementiert, um diein den traces festgelegten execution events auf die korrespondierenden Regeln ausdem DMM-Regelsatz abzubilden. Um diese dann in CTL-Formeln zu überführen,wurden bereits existierende Methoden verwendet.

5.2.3. Testen der DMM-Regeln

Nachdem das erwartete Verhalten für ein Beispielmodell in CTL-Formeln transfor-miert ist, wird durch den GROOVE-Modelchecker überprüft, ob das durch das Tran-sitionssystem beschriebene Verhalten mit dem erwarteten Verhalten übereinstimmt(siehe Abbildung 5.2). In Abbildung 5.4 ist ein Beispiel für ein allgemeines Transiti-onssystem abgebildet. Es existieren hier drei mögliche Pfade vom Startzustand zumEndzustand. Diese drei Pfade repräsentieren die möglichen Durchläufe einer UMLStatemachine, die durch DMM-Regeln erzeugt worden sind. Um jetzt das Transiti-onssystem gegen das erwartete Verhalten zu testen, kommen die CTL-Formeln zumEinsatz. Angenommen, dass folgende traces of execution events in CTL-Formelnvorliegen:

trace1: EF(r1 & EXEF(r3 & EXEF(r2 & EXEF(r9))))

trace2: EF(r1 & EXEF(r6 & EXEF(r4 & EXEF(r9))))

Das erwartete Verhalten, welches trace1 beschreibt, wird im Transitionssystem(siehe Abbildung 5.4) in dem Pfad, der durch die grüne gerichteten Kanten gekenn-zeichnet ist, gefunden. Obwohl die Regel r7 in trace1 nicht angegeben wurde, im Pfadaber auftaucht, handelt es sich hier dennoch um einen gültigen Pfad, da in trace1

lediglich vorausgesetzt wird, dass nach der Ausführung der Regel r3 irgendwann dieRegel r2 ausgeführt wird. Das heiÿt, r2 muss nicht unmittelbar nach r3 ausgeführtwerden.

r2

r1r9

r9r7

r8

r6

r3

r4r5

r5 EndzustandStartzustand

Regel

Abbildung 5.4.: Ermittlung des erwarteten Verhaltens im Transitionssystem

Das erwartete Verhalten, welches durch trace2 vorgegeben ist, existiert in demvorliegendem Transitionssystem nicht. Die roten gerichteten Kanten repräsentieren

80 WS 2009/2010


hier die Suche nach einem Pfad für trace2. Da kein Pfad existiert, auf dem die Regelr6 und danach irgendwann die Regel r4 ausgeführt werden, gilt der Test für trace2als nicht bestanden. Unter der Voraussetzung, dass das erwartete Verhalten unddas korrespondierende Beispielmodell korrekt angegeben worden sind, müssen nundie entsprechende Regeln untersucht und gegebenenfalls modi�ziert werden, so dassdiese dann das erwartete Verhalten korrekt beschreiben.Durch die Erstellung neuer Regeln kann es vorkommen, dass das bereits erfolgreich

getestete Verhalten von einigen Beispielmodellen nicht mehr gegeben ist. In diesenFällen müssen die Transitionssysteme der betro�enen Beispielmodelle erneut unter-sucht, und die für das fehlerhafte Verhalten zuständigen Regeln angepasst werden.

5.3. Testfälle

In den folgenden zwei Unterabschnitten wird anhand von zwei Beispielen veranschau-licht, welche Transitionssysteme aus diesen erzeugt werden und wie diese gegen daserwartete Verhalten getestet werden.

5.3.1. Testen des laufenden Beispiels

In diesem Unterabschnitt werden zwei traces of execution events vorgestellt, die einenTeil des erwarteten Verhaltens zum laufenden Beispiel aus Abbildung 2.19 beschrei-ben.

Der wohl einfachste Durchlauf der Statemachine aus Abbildung 2.19 ist, das Ein-schalten des Autoradios (bei eingelegter CD) und anschlieÿendes Ausschalten desAutoradios. Dieser Durchlauf ist durch den unten stehenden trace of execution eventsbeschrieben:

InitialStateExecutes->TransitionExecutes(Taste Ein)

->TransitionExecutes(tEnterCDBetrieb)->StateExecutes(CD-Betrieb)

->�reTransition(Taste Aus)->StateExecutesExit(CD-Betrieb)

->TransitionExecutes(Taste Aus)->StateExecutes(�nalState)

Da zwischen den Abspielmodi des Autoradios beliebig oft gewechselt werden kannund bei jedem Wechsel in den Radiobetrieb eines der drei zu Verfügung stehen-den Frequenzbänder (AM, FM1, FM2) zusätzlich ausgewählt werden kann, ergebensich hierdurch eine ganze Reihe von möglichen Durchläufen der Statemachine. EinDurchlauf der Statemachine mit einem mehrmaligen Wechsel zwischen dem Radio-und CD-Betrieb hat einen recht groÿen (und unübersichtlichen) trace of execuion

events zu Folge.Der unten stehende trace of execution events beschreibt folgendes Verhalten des

Autoradios: Nach dem Einschalten des Autoradios wird der CD-Betrieb aktiv. Da-nach wird über die Taste �Radiobetrieb� auf Radiobetrieb umgeschaltet. Hier wirdbeim erstmaligen Wechsel in den Radiobetrieb standardmäÿig das Frequenzband AM



gewählt und abgespielt. Durch Drücken der Taste �AM/FM� schaltet das Autora-dio auf das Frequenzband FM1 um. Über die Taste �CD-Betrieb� wird erneut inden CD-Betrieb gewechselt und anschlieÿend über die Taste �Aus� das Autoradioausgeschaltet.

InitialStateExecutes->TransitionExecutes(Taste Ein)

->TransitionExecutes(tEnterCDBetrieb)->StateExecutes(CD-Betrieb)

->�reTransition(Taste Radio)->StateExecutesExit(CD-Betrieb)

->TransitionExecutes(Taste Radio)->StateExecutes(Radiobetrieb)

->TransitionExecutes(tLeaveHistoryState)->StateExecutes(AM)

->�reTransition(tEnterFM)->StateExecutesExit(AM)

->TransitionExecutes(tEnterFM)->StateExecutes(FM)

->TransitionExecutes(tInitialFM)->StateExecutes(FM1)

->�reTransition(Taste CD)->StateExecutesExit(FM1)->StateExecutesExit(FM)

->StateExecutesExit(Radiobetrieb)->TransitionExecutes(Taste CD)

->StateExecutes(CD-Betrieb)->�reTransition(Taste Aus)

->StateExecutesExit(CD-Betrieb)->TransitionExecutes(Taste Aus)

->StateExecutes(�nalState)

Bei der Transformation der oben erwähnten traces of execution events entstehensehr lange CTL-Formeln, die an dieser Stelle aus Übersichtsgründen nicht dargestelltwerden1.Durch die Anwendung des DMM-Regelsatzes auf die korrespondierende Laufzeit-

Statemachine des Beispielmodells aus Abbildung 2.19 wird ein Transitionssystemerzeugt, welches in Abbildung 5.6 dargestellt ist. Durch die hohe Anzahl der er-zeugten Zustände und Transitionen kann das Transitionssystem hier nicht im Detailveranschaulicht werden. In der Abbildung 5.5 wird ein kleiner Ausschnitt gezeigt, indem ein paar Regeln und die daraus resultierende Zustände leserlich dargestellt sind.Die meisten Regeln werden mit einem Parameter (EmphasizeAttribute) versehen,

der einen Knoten kennzeichnet, auf dem die Regel aufgerufen wurde (siehe auch Ka-pitel 3.4.1.4). Dadurch können die möglichen Durchläufe einer UML Statemachine indem Transitionssystem nachvollziehbar dargestellt werden, d.h. mann kann hierdurchablesen, auf welchem Knoten bzw. Objekt-Muster eine Regel angewendet wurde. Derviel wichtigere Vorteil ist aber, dass es hierdurch möglich wird, zu überprüfen, obeine bestimmte Regel in einer bestimmten Situation ausgeführt wurde.Bei einem Test wird dies dann dadurch sichergestellt, dass der Parameter in dem

execution event eines traces ebenfalls angegeben wird. Bei dem Vergleichen des tat-sächlichen Verhaltens mit dem erwartetem Verhalten müssen also auÿer der Über-einstimmung der Regeln auch die Knoten, auf denen die Regeln angewendet wurden,übereinstimmen. In jedem trace of execution events des laufenden Beispiels wird z.B.zu Beginn festgelegt, dass die Transition �Taste Ein� die erste auszuführende Tran-sition auf einem Pfad-Durchlauf ist. In dem zugehörigen Transitionssystem wird das

1diese können bei der eingerichteten Entwicklungsumgebung in der Konsole unter Eclipse (sieheCD-Inhalt im Anhang) nach der Durchführung der entsprechenden Tests eingesehen werden

82 WS 2009/2010


.

.

.

Abbildung 5.5.: Ausschnitt des Transitionssystems zum laufenden Beispiel

Auslösen des Triggers �Taste Ein� durch die Regel t.�reTransition_1#(Taste Ein)

beschrieben und durch Aufrufe weiterer Regeln der Zustandsübergang beschrieben(siehe Abbildung 5.5). Da die Regel t.�reTransition_1#() bei der Erzeugung desTransitionssystems mehrmals zur Anwendung kommt, ist hier die Verwendung desParameters EmphasizeAttribute notwendig, um den Zustand einer Statemachine ein-deutig identi�zieren zu können, der vor der Anwendung der genannten Regel gegoltenhat.Bei dem Testen des laufenden Beispiels werden in erster Linie die Regeln un-

tersucht, die die Semantik des Pseudozustands Deep history beschreiben. Bei derBeschreibung des Verhaltens des laufendes Beispiels entsteht ein Transitionssystem,welches in Abbildung 5.6 dargestellt ist. Da das Transitionssystem recht groÿ undunübersichtlich ist, werden an dieser Stelle folgende Daten zur Information mitgeteilt:

• Anzahl der erzeugten Transitionen: 706

• Anzahl der erzeugten Zustände: 636

• Anzahl der verwendeten Regeln: 43

Obwohl das laufende Beispiel ein recht kleines übersichtliches Beispielmodell dar-stellt, entsteht bei der Beschreibung des Verhaltens ein groÿes, teilweise unübersicht-liches Transitionssystem.



Abbildung 5.6.: Transitionssystem zum laufenden Beispiel

Bei Sprachelementen, die durch Transitionssysteme mit einer hohen Anzahl anPfaden für die möglichen Durchläufe eines zugrundeliegenden Beispielmodells be-schrieben werden, ist die Erstellung der traces of execution events ein relativ hoherAufwand, falls hier alle möglichen Pfade berücksichtigt werden sollen.

84 WS 2009/2010


In dem Transitionssystem in Abbildung 5.6 entsteht die hohe Anzahl der Zyklen,durch die möglichen Kombinationen des Umschaltens zwischen dem CD und Radio-betrieb und bei Radiobetrieb dem Wechsel zwischen den einzelnen Frequenzbändern.

5.3.2. Parallelität

Um parallele Abläufe einer Statemachine in einem Transitionssystem beschreiben zukönnen, wird eine Methode verwendet, die anhand des Beispiels in Abbildung 2.13veranschaulicht werden soll. Hier werden die vom Pseudozustand Fork ausgehendenTransitionen parallel ausgeführt. Parallel soll hier nicht heiÿen, das die Ausführungsynchron beendet werden muss, da die Aktionen a1 und a2 unterschiedlich langeAusführungszeiten aufweisen können.In einem korrespondierendem Transitionssystem werden durch entsprechende Re-

geln Pfade generiert die die möglichen Ausführungsreihenfolgen beschreiben. Dasheiÿt, es wird ein Pfad erzeugt, in dem zuerst die Transition t1 gefolgt von Transitiont2 ausgeführt werden. In einem alternativen Pfad wird die Ausführung der genann-ten Transitionen in einer umgekehrten Reihenfolge dargestellt. Durch die Existenzbeider Pfade im Transitionssystem wird die parallele Ausführung der Transitionent1 und t2 beschrieben.Nachdem die orthogonalen Regionen betreten worden sind und das Eintrittsverhal-

ten des Zustands OrthogonalState ausgeführt worden ist, wird nun mit der paralle-len Ausführung der Zustände State1 und State2 fortgefahren. Hier wird die paralleleAusführung analog zu der Ausführung der oben beschriebenen Transitionen darge-stellt. Das heiÿt, es gibt einen Pfad, auf dem State1 gefolgt von State2 ausgeführtwerden, und einen Pfad, auf dem State2 gefolgt von State1 ausgeführt werden.Um durch entsprechende traces die parallele Ausführung von execution events

(Ausführung von Zuständen oder Transitionen) überprüfen zu können, müssen diemöglichen Pfade, die für die Beschreibung der parallelen Ausführung zuständig sind,in den traces angegeben werden. Das Betreten des Zustands OrthogonalState wirdin den traces durch die unten dargestellten execution events beschrieben:

trace1: ... ->TransitionExecutes(t0)->TransitionExecutes(t1)->TransitionExecutes(t2)

->StateExecutes(OrthogonalState)->StateExecutes(State1)->StateExecutes(State2)->...







In der Abbildung 5.7 ist das resultierende Transitionssystem dargestellt, welchesdas gesamte Verhalten des Beispielmodells aus Abbildung 2.13 beschreibt.



Initialisierung der Statemachne undBetreten des Psueodzustands Fork

Variationen der Ausführung der vom Pseudozustand Forkausgehenden Transitionen

Variationen der Ausführungdes Einttrittsverhaltens derZustände State1 und State3

Variationen der Zuständsübergängeinnerhalb der orthogonalen Regionen

Variationen der Ausführung desAustrittsverhaltens der ZuständeState2 und State4

Variationen der Ausführung der in den Pseudozustand Joineingehenden Transitionen

Betreten des Endzustands undBeenden der Statemachine

Abbildung 5.7.: Transitionsystem zum Besipiel aus Abbildung 2.13

86 WS 2009/2010

6. Zusammenfassung und Ausblick

In diesem Kapitel wird in Abschnitt 6.1 eine Zusammenfassung über die Ergebnissedieser Arbeit gegeben. Anschlieÿend wird in Abschnitt 6.2 ein Ausblick über mögli-che Weiterentwicklungen der erstellten DMM-Spezi�kation für UML Statemachinesgegeben.

6.1. Zusammenfassung

Die Formalisierung der Semantik einer visuellen Modellierungssprache ist eine her-ausfordernde Aufgabe: Zum Einen muss man die Semantik im Detail verstandenhaben, um diese korrekt zu interpretieren. Zum Anderen muss diese dann durch einegeeignete Technik formal beschrieben werden.

In dieser Arbeit wurde eine formale graphbasierte Semantik für UML Statemachi-nes erstellt. Für die Erstellung der formalen Semantik wurde die Technik Dynamic

Meta Modeling (DMM) eingesetzt. Die DMM-Spezi�kation für UML Statemachineswurde durch die folgenden vier Schritten umgesetzt.Ausgehend von dem zugrundeliegenden Syntax-Metamodell und der textuellen

Beschreibung der Semantik, die durch die UML Spezi�kation de�niert sind, wurdendie einzelnen Sprachelemente untersucht und deren Eigenschaften und Verhalten inKapitel 2 vorgestellt.In Kapitel 3 wurden die Grundlagen des Dynamic Meta Modeling eingeführt. Dabei

wurden die notwendigen Schritte erläutert, die erforderlich sind, um die Semantikeiner auf einem Syntax-Metamodell basierenden Modellierungssprache mit DMMformal zu spezi�zieren.Der Hauptteil dieser Arbeit - die Erstellung einer DMM-Spezi�kation für UML

Statemachines - wurde in Kapitel 4 im Detail vorgestellt. Ausgehend von dem entwi-ckelten Marker-Konzept wurde das Syntax-Metamodell zu einem Laufzeit-Metamodellerweitert, welches alle für die Beschreibung der Semantik benötigten Elemente ent-hält. Weiterhin wurde der DMM-Regelsatz erstellt, der die formale Beschreibung desdynamischen Verhaltens von UML Statemachines de�niert. Um das Verhalten vonUML Statemachines durch die Anwendung der DMM-Spezi�kation in einem Transi-tionssystem darzustellen, wurde das Softwaretool GROOVE eingesetzt.Um die Qualität der formalen Semantik zu überprüfen, mussten die DMM-Regeln

getestet werden. In Kapitel 5 wurde die Vorgehensweise erläutert, die verwendetwurde, um schon während der Erstellung der ersten DMM-Regeln diese auf daserwartete Verhalten zu überprüfen. Hier wurde ebenfalls GROOVE als Modelchecker

87

Kapitel 6. Zusammenfassung und Ausblick

eingesetzt. Dabei wurden die Regeln, durch die ein Transitionssystem erzeugt wird,gegen das erwartete Verhalten getestet, welches durch sogenannte traces of executionevents de�niert wurde.Das Ergebnis dieser Arbeit ist eine formale DMM-Spezi�kation, durch die die Se-

mantik von UML Statemachines beschrieben wird und in Transitionssystemen dar-gestellt werden kann.

6.2. Ausblick

Da die in dieser Arbeit erstellte DMM-Spezi�kation nicht alle Sprachelemente unddie möglichen Kombinationen dieser untereinander abdeckt, soll die Spezi�kationlediglich als Prototyp betrachtet werden. Im Folgenden werden die Aspekte aufge-zählt, die bei der Weiterentwicklung der DMM-Spezi�kation für UML Statemachinesberücksichtigt werden sollten.

Nicht behandelte Sprachkonstrukte In Abschnitt 2.5 wurden Sprachkonstrukteaus der UML Spezi�kation für Statemachines aufgelistet, die bei der Erstellung derSemantik nicht berücksichtigt wurden. Um eine formale Semantik für diese zu rea-lisieren, müsste man weitere Beispielmodelle erstellen und die existierenden DMM-Regeln darauf untersuchen, ob durch diese bereits ein Teil des erwarteten Verhaltensbeschrieben wird. Bei einigen Sprachkonstrukten müsste man sowohl das Laufzeit-Metamodell erweitern als auch weitere DMM-Regeln erstellen. Die neue hinzugekom-menen DMM-Regeln müssten dann auf das erwartete Verhalten untersucht werden.Da bei der systematischen Vorgehensweise der Erstellung und Testen von DMM-

Regeln in erster Linie die grundlegenden Sprachelemente und Konstrukte untersuchtwurden, konnten die in Abschnitt 2.5 aufgelisteten Sprachkonstrukte, die in komple-xeren Beispielmodellen zur Verwendung kommen, aufgrund des beschränkten Zeit-rahmens nicht mehr berücksichtigt werden.

Qualität der DMM-Regeln Die erstellten Regeln wurden auf das erwartete Ver-halten getestet, in dem diese auf ein Beispielmodell angewendet wurden, um dannanschlieÿend das tatsächliche Verhalten (dargestellt durch ein Transitionssystem) mitdem erwartetem Verhalten (de�niert durch traces of execution events) zu vergleichen.Um eine höhere Qualität der Regeln zu gewährleisten, müssten diese weiteren Testsunterzogen werden, in denen komplexere Beispielmodelle mit weiteren Kombinatio-nen der untersuchten Sprachelemente zum Einsatz kommen.Die weiteren Tests würden überprüfen, ob die erstellten Regeln angewendet auf

die komplexeren Beispielmodelle, die neue Zustandsszenarien (durch Kombinationder Sprachelemente) bzgl. der bereits existierenden Beispielmodellen darstellen, dasVerhalten der entsprechenden Statemachines korrekt beschreiben. Hier müsste manfür die neu erstellten Beispielmodelle das zugehörige erwartete Verhalten ebenfallsdurch traces of execution events angeben, um das tatsächliche Verhalten mit demerwarteten Verhalten zu vergleichen.

88 WS 2009/2010

Kapitel 6. Zusammenfassung und Ausblick

Qualität der Tests Bei den automatisierten Tests ist es zur Zeit so, dass bei derÜberprüfung des erwarteten Verhaltens eines durch ein Transitionssystem beschrie-benen Beispielmodells nur überprüft wird, ob die in den traces of execution events

angegebenen Durchläufe einer UML Statemachine in dem Transitionssystem vor-handen sind. Falls das Transitionssystem aber weitere Pfade für einen Durchlaufder korrespondierenden Statemachine enthält, die in den traces of execution events

nicht angegeben worden sind, so sollte man die Möglichkeit haben, solche Fälle alsfehlerhaft zu identi�zieren. Das heiÿt, das tatsächliche Verhalten, erzeugt durch dieRegeln, wird von dem erwartetem Verhalten nicht vollständig überdeckt.Da bei komplexen Beispielmodellen die Beschreibung in einem groÿen Transitions-

system resultiert, ist es hier hingegen wünschenswert, nur einen bestimmten Teil deserwarteten Verhaltens durch traces of execution events anzugeben. Hier wäre es einenormer Zeitaufwand, alle möglichen Durchläufe in den traces zu de�nieren.Da es also bei kleinen Beispielmodellen einfach ist, das gesamte Verhalten durch

traces zu de�nieren, bei groÿen Modellen aber zunehmend aufwendig wird, sollte dieForderung einer exakten Überdeckung des erwarteten Verhaltens mit dem tatsächli-chen Verhalten bei den Tests als Option zu Verfügung stehen.

Ein weiteres Kriterium für die Verbesserung der Qualität von Tests wäre eine op-tionale Möglichkeit, die traces of execution events in CTL-Formeln zu transformie-ren, die strikte Aktionsabläufe fordern. Durch die Nutzung des CTL-Operators EFwerden Bedingungen für irgendeinen Folgezustand überprüft. Es ist aber durchausdenkbar, dass in manchen Situationen die Bedingung eines direkten Folgezustandsüberprüft werden muss. Um diese Möglichkeit zu Verfügung stellen zu können, müsstedie Testumgebung um diese Option erweitert werden, indem man einen entsprechen-den CTL-Operator in die Testumgebung integrieren würde.


Literaturverzeichnis

[1] Baresi, L., and Heckel, R. Tutorial Introduction to Graph Transforma-tion: A Software Engineering Perspective. In ICGT '02: Proceedings of the

First International Conference on Graph Transformation (London, UK, 2002),Springer-Verlag, pp. 402�429.

[2] Bauer, E. Enhancing the Dynamic Meta Modeling Formalism and its Eclipse-

based Tool Support with Attributes, Bachelor thesis. University of Paderborn,2008.

[3] Engels, G., Hausmann, J. H., Heckel, R., and Sauer, S. Dynamic MetaModeling: A Graphical Approach to the Operational Semantics of BehavioralDiagrams in UML. In A. Evans, S. Kent, and B. Selic UML, 2000 - The Uni�ed

Modeling Language. Springer-Verlag Berlin, 2000.

[4] Hausmann, J. H. Dynamic Meta Modeling. PhD thesis, Universität Paderborn,2005.

[5] Hornkamp, M. A Formal, Graph-Based Semantics for UML Activities. Mas-ter's thesis, Universität Paderborn, 2009.

[6] Kröger, F., and Merz, S. Temporal Logic and State Systems. SpringerBerlin, 2008.

[7] Object Management Group. OMG Uni�ed Modeling Language (OMG

UML), Superstructure, 2009.

[8] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation.In Applications of Graph Transformations with Industrial Relevance (AGTIVE)

(Berlin, 2004), J. L. Pfaltz, M. Nagl, and B. Böhlen, Eds., vol. 3062 of LectureNotes in Computer Science, Springer Verlag, pp. 479�485.

[9] Röhs, M. A Visual Editor for Semantics Speci�cations Using the Eclipse Gra-

phical Modeling Framework, Bachelorarbeit, 2008.

[10] Rupp, C., Queins, S., and Zengler, B. UML 2 glasklar, third ed. HanserFachbuchverlag, August 2007.

[11] Soltenborn, C., and Engels, G. Towards Test-Driven Semantics Speci-�cation. In Proceedings of the 12th International Conference on Model Driven

Engineering Languages and Systems (MODELS 2009), Denver, Colorado (USA)

(Berlin/Heidelberg, 2009), B. S. A. Schürr, Ed., Springer, pp. 378�392.

91

A. Anhang

CD-ROM mit dem folgenden Inhalt:

• Diplomarbeit in PDF-Format

• Eclipse-Umgebung mit allen benötigten Plugins

• DMM-Spezi�kation für UML Statemachines

• Java-Programm zur Transformation eines Modell in ein Laufzeit-Modell

• Test-Framework

93

Selbstständigkeitserklärung

Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig ohne die HilfeDritter verfasst und keine anderen als die angegebenen und bei Zitaten kenntlichgemachten Quellen und Hilfsmittel verwendet habe.

Paderborn, den 12. Mai 2010

Documents

Eine formale, graphbasierte Semantik für UML Statemachines · Semantik formalisiert werden, wodurch diese dann eindeutig interpretiert und somit auch maschinell analysiert werden