Mocek Thesis

1. Christian MocekErweiterung des CASE-Werkzeugs DAVEum einen Code-Generatorfr LEGO MindstormsDiplomarbeit7. Mai 2006 Gutachter:Universitt Dortmund Lehrstuhl fr Software-Technologie Prof. Dr. Ernst-Erich Doberkat Baroper Strae 301 Dipl.-Inform. Jrg Pleumann 44227 Dortmund

3. Vorwort Dass mir die Leidenschaft meiner Kindheit am Ende des Studiums begegnet, htte ich mir niemals trumen lassen. Schon als kleines Kind war ich von LEGO, insbesondere LEGO Technik, begeistert und freue mich auch heute immer wieder, wenn ich mit meinem Neen die kleinen bunten Steine zusammensetzen kann. Auf der Suche nach einem Thema fr meine Diplomarbeit stie ich dann auf eins, welches mich vom ersten Augenblick an interessierte: Die Steuerung von LEGO Mindstorms-Robotern mit Hil- fe von Zustandsdiagrammen. Nach einigen Vorgesprchen mit meinem Betreuer sowie Gutachter Jrg Pleumann und langen berlegungen - mit zugegeben einigem Zwei- fel, ob sich dieses Unterfangen berhaupt realisieren lsst - entschied ich mich dafr, diese Herausforderung anzunehmen. Denn wer hat schon die Mglichkeit, in seiner Di- plomarbeit mit LEGO spielen zu drfen? Natrlich von einem rein wissenschaftlichen Standpunkt betrachtet, versteht sich. So begann eine Zeit unzhliger Stunden Arbeit, einigen frustrierenden Momenten und vielen Gesprchen ber das Thema mit meinem Betreuer. Doch letztlich haben sich all die Mhen gelohnt, als die ersten Roboter ihre Aufgaben mit Hilfe von Zustandsdiagrammen lsten und die letzten Zeilen dieser Arbeit getippt waren.An dieser Stelle bedanke ich mich fr die Hilfe all jener Personen, die mich in der langen Zeit in irgendeiner Weise untersttzt haben diese Arbeit zu erstellen. Zunchst bedanke ich mich bei meinen Eltern, die immer an mich geglaubt haben und denen diese Arbeit gewidmet ist. Ganz besonderer Dank gilt zudem Jrg Pleumann, welcher mir jederzeit verstndnisvoll geholfen und meine hugen Fragen geduldig beantwortet hat. Insbesondere mchte ich auch Peter Segschneider und seiner Frau Christel sowie Nina Schilf fr ihre Freundschaft und moralischen Untersttzung in der langen Zeit danken. Ein weiterer Dank gilt meinen Korrekturlesern, die sich eisern auf der Suche nach Fehlern durch diesen Text gelesen haben. Herten, im Mai 2006 Christian Mocek

5. Inhaltsverzeichnis1 Thema der Arbeit1 1.1 Motivation der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Geplantes Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Grundbegrie 5 2.1 Zustandsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 2.1.1 Elemente und Semantik von Zustandsdiagrammen. . . . . . . .5 2.1.2 Implementierungsanstze . . . . . . . . . . . . . . . . . . . . . . 11 2.2 LEGO Mindstorms Roboter . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.1 Aufbau der Hardware . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.2 Programmierung der LEGO-Roboter . . . . . . . . . . . . . . . . 153 Lsungsansatz 17 3.1 Zielplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Ansatzpunkte zur Integration in DAVE . . . . .. . . . . . . . . . . . . 18 3.2.1 Die Simulationsmaschine . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.2 Wahl der zu verwendenden Datenstruktur. . . . . . . . . . . . . 19 3.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4 Gesamtaufbau . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 194 Das Statechart-Framework21 4.1 Konzeptioneller Aufbau . . . . . . . .. . . . . . . . . . . . . . . . . . . 21 4.1.1 Zeitgesteuerte Transitionen . . . . . . . . . . . . . . . . . . . . . 22 4.1.2 Segmentierte Transitionen . . . . . . . . . . . . . . . . . . . . . . 23 4.1.3 Hierarchie und Nebenlugkeit . . . . . . . . . . . . . . . . . . . 25 4.2 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2.1 Speicherplatzoptimierungen . .. . . . . . . . . . . . . . . . . . . 31 4.2.2 Berechnung des LCA . . . . . .. . . . . . . . . . . . . . . . . . . 32 4.2.3 Verwendung des Frameworks . . . . . . . . . . . . . . . . . . . . 33 4.3 Unittests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Integration der RCX-Elemente in Zustandsdiagramme 41 5.1 Startsymbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2 Grundregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.3 Initialisieren der Sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.4 Verarbeiten eines Ereignisses . . . . . . . . . . . . . . . . . . . . . . . . 44 5.5 Aktionen und Bedingungen . . . . . . . . . . . . .. . . . . . . . . . . . 44

6. InhaltsverzeichnisVI5.5.1 Ausgnge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.5.2 Sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.5.3 Variablen .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.5.4 LC-Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 Steuerung des RCX mit Hilfe des Frameworks49 6.1 Ausgnge . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 49 6.1.1 Aktionen . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 50 6.1.2 Bedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2 Sensoren . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 51 6.2.1 Notwendige Optimierungen . . . . .. . . . . . . . . . . . . . . . 51 6.2.2 Ereignisse . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 53 6.2.3 Aktionen und Bedingungen . . . . .. . . . . . . . . . . . . . . . 53 6.3 Variablen und einfache Arithmetik . . . . . . . . . . . . . . . . . . . . . 547 Codegenerierung 57 7.1 Das XML-Format von DAVE . . . . . . . . . . . . . . . . . . . . . . . . 57 7.2 Verarbeitung der XML-Datei . . . . . . . . . . .. . . . . . . . . . . . . 59 7.2.1 Implementierung in Java . . . . . . . . . . . . . . . . . . . . . . . 59 7.2.2 Freemarker . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 59 7.2.3 Transformationen mittels XSL und XPath. . . . . . . . . . . . . 60 7.3 Die Codegenerierung im Detail . . . . . . . . . . . . . . . . . . . . . . . 62 7.3.1 Umsetzung mittels XSLT . . . . . . . . .. . . . . . . . . . . . . 62 7.3.2 Interpretieren der EBNF-Regeln . . . . .. . . . . . . . . . . . . 65 7.3.3 Aktivieren und Deaktivieren der Sensoren. . . . . . . . . . . . . 66 7.3.4 Aufbau des Zustandsdiagramms . . . . . .. . . . . . . . . . . . . 68 7.3.5 Aktionen und Bedingungen . . . . . . . .. . . . . . . . . . . . . 738 Anbindung an DAVE mittels Ant 759 Anwendungsbeispiele 79 9.1 Aufgaben fr die LEGO-Testunterlage . . . . . . . . . . . . . . . . . . . 79 9.1.1 Aufgabe 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 9.1.2 Aufgabe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 9.1.3 Aufgabe 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 9.2 Eine Sortieranlage fr LEGO-Steine .. . . . . . . . . . . . . . . . . . . 83 9.2.1 Aufgabe 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 9.2.2 Aufgabe 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 9.2.3 Aufgabe 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8710 Fazit8911 Ausblick 91

7. InhaltsverzeichnisVII A Testflle93 A.1 Einfache Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 A.2 Hierarchische Zustnde . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 A.3 Nebenluge Zustnde . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96B Bauplne101 B.1 Ein mobiler Roboter fr die Testunterlage . . . . . . . . . . . . . . . . . 101 B.1.1 Linker Motorblock . . . . . . . . . . . . . . . . . . . . . . . . . . 101 B.1.2 Rechter Motorblock . . . . . . . .. . . . . . . . . . . . . . . . . 104 B.1.3 Zusammenbau der Komponenten . . . . . . . . . . . . . . . . . . 106 B.2 Eine Sortiermaschine fr LEGO-Steine . .. . . . . . . . . . . . . . . . . 110 B.2.1 Klappe . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 110 B.2.2 Frderband . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 111 B.2.3 Unterbau . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 113 B.2.4 Zusammenbau der Komponenten . . . . . . . . . . . . . . . . . . 119 B.2.5 Kiste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

8. Inhaltsverzeichnis VIII

9. Abbildungsverzeichnis 1.1Das CASE-Werkzeug DAVE . . . . . . . . . . . . . . . . . . . . . . . . . 21.2Verwendung von Zustandsdiagrammen in eingebetteten Systemen . . . .3 2.1Umsetzung eines endlichen Automaten in prozeduralen Quelltext . . .. 122.2Umsetzung des Beispielautomaten mit Hilfe des State-Patterns . . . . . 132.3Beispiel der Abbildung von Hierarchie und Nebenlugkeit in die Klas- senhierarchie objektorientierter Sprachen auf Basis des State-Patterns . 132.4Klassendiagramm des FSM-Frameworks von Bosch und van Gurp . . .. 142.5Der RCX-Baustein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1Aufbau des Gesamtkonzepts . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1Konzeptioneller Aufbau des Frameworks ohne Bercksichtigung hierar- chischer und nebenluger Zustnde . . . . . . . . . . . . . . . . . . . . 224.2Erweiterung der Klassen State und Transition fr zeitgesteuerte Tran- sitionen, sowie Einfhrung der Klasse PseudoState . . . . . . . . . . .. 23 Verarbeitung segmentierter Transitionen fr den Fall x = 0 . . . . . .4.3 . 244.4Ereignisverarbeitung auf dem Oder-Zustand . . . . . . . . . . . . . . .. 254.5Transitionsverhalten bei hierarchischen Zustnden . . . . . . . . . . .. 264.6Erweiterung des Frameworks um Hierarchie . . . . . . . . . . . . . . . . 274.7Ablauf der execute-Methode einer Transition . . . . . . . . . . . . . .. 284.8Erweiterung des Frameworks um Nebenlugkeit . . . . . . . . . . . . . 294.9Klassendiagramm der Implementierung des Frameworks . . . . . . . . . 304.10 Beispieldiagramm fr die Umsetzung in den Quelltext . . . . . . . . .. 354.11 Klassendiagramm zur Implementierung der Testflle . . . . . . . . . .. 374.12 Beschreibung des Pfads, welcher beim Durchlauf durch das Diagramm zurckgelegt wird . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 384.13 Beispieldiagramm fr einen Testfall . . . . . . . . . . . . . . . . . . . .. 394.14 Ablauf eines Testfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.1Beispieldiagramm zur Verwendung der spezizierten Syntax . . . . . . . 47 6.1Framework-Erweiterung zur Steuerung der Ausgnge des RCX . . . . . 506.2Framework-Erweiterung zur Steuerung der Sensoren des RCX . . . . . . 526.3Framework-Erweiterung zum Rechnen mit dem RCX . . . . . . . . . . . 55 8.1DAVE nach der Integration und Ausfhrung des Ant-Skripts . . . . . . 78 9.1LEGO-Testunterlage fr den Lichtsensor . . . . . . . . . . . . . . . . . . 79

10. Abbildungsverzeichnis X 9.2Modell des Roboters fr die Testunterlage . . . . . . . . . . . . . . . . . 80 9.3Ablauf einer einfachen Rundfahrt auf der Testunterlage . . .. . . . . . 80 9.4Modizierte Testunterlage . . . . . . . . . . . . . . . . . . . . . . . . . . 81 9.5Ablauf einer Rundfahrt auf der modizierten Testunterlage . . . . . . . 81 9.6Zhlen der grnen Blcke auf der Testunterlage . . . . . . . .. . . . . . 82 9.7Zustandsdiagramm fr Aufgabe 3 . . . . . . . . . . . . . . . .. . . . . . 83 9.8LEGO-Modell der Sortieranlage fr LEGO-Steine. . . . . . .. . . . . . 84 9.9Konzept einer einfachen Sortieranlage fr LEGO-Steine . . . . . . . . . 84 9.10 Aufbau des Rotationssensors . . . . . . . . . . . . . . . . . . . . . . . . 85 9.11 Sortieren verschiedener LEGO-Steine anhand ihrer Farbe . .. . . . . . 86 9.12 Erweiterung des bisherigen Sortierers . . . . . . . . . . . . . . . . . . . . 87 9.13 Sequenzielles Fllen der Kisten mit Hilfe der Sortiermaschine . . . . . . 88

11. Kapitel 1 Thema der Arbeit Da die Anforderungen an heutige Softwaresysteme immer weiter ansteigen, wird auch deren Entwicklung immer komplexer und kostspieliger. Um den berblick ber Struk- turen und Ablufe in dem System behalten zu knnen, ist deren Dokumentation schon in der Planungsphase enorm wichtig. Denn zum einen erleichtert dies anderen Ent- wicklern sich einzuarbeiten und zum anderen knnen durch solch eine Dokumentation frhzeitig Designfehler oder -mngel entdeckt werden. Die Abstraktionsebene reicht von der allgemeinen Beschreibung von Anwendungsfllen bis hin zur konkreten Im- plementierung und Beschreibung von Objektverhalten. Ein hierbei immer wichtiger gewordenes Hilfsmittel ist die von der Object Management Group eingefhrte Unied Modelling Language (OMG, 2003). Aus diesem Grund ist es daher unerlsslich, die Studenten im Rahmen von bungen und Projektarbeiten an die Modellierung von Software mittels UML heranzufhren.Da jedoch die normalen Modellierungstools fr die Lehre aufgrund ihrer Komplexi- tt und des hohen Preises ungeeignet sind, wurden im Rahmen des MuSoft-Projektes (Doberkat und Engels, 2002) mehrere Werkzeuge entwickelt, welche im Funktions- umfang explizit auf die Lehre ausgelegt sind. Eines dieser Programme ist der an der Dortmunder Universitt entstandene Dortmunder Automatenvisualisierer und -editor (Pleumann, 2003). DAVE (siehe Abbildung 1.1) beschrnkt sich auf die Modellierung und Simulation von Zustandsdiagrammen1 - einer Verallgemeinerung von endlichen Automaten, die unter anderem um Hierarchie und Nebenlugkeit erweitert wurden. 1.1 Motivation der Arbeit Das Ziel von DAVE ist das anschauliche Vermitteln der Syntax und Semantik von Zustandsdiagrammen. Hierbei ist eine wesentliche Komponente die Simulation: Die Studenten sind in der Lage, ihre Modelle auszufhren und somit deren Laufzeitver- halten zu beobachten. Um einen besseren Bezug zwischen der abstrakten graphischen Notation und dem Objekt, dessen Verhalten beschrieben wird, herzustellen, untersttzt DAVE die Simulation zustzlich durch multimediale Animationen (zum Bei- spiel eine Waschmaschine). Aufgrund dieses Bezugs von etwas Abstraktem zu et- 1 Essei angemerkt, dass sich DAVE auf die in der UML-Spezikation beschriebene Syntax und Semantik bezieht (OMG, 2003). Diese unterscheidet sich etwas von der von Harel beschriebenen (Harel, 1987). Die wesentlichen Konzepte sind jedoch gleich.

12. 1. Thema der Arbeit 2 Abbildung 1.1.: Das CASE-Werkzeug DAVEwas Anschaulichem kann den Studenten der Nutzen und die Semantik von UML- Zustandsdiagrammen besser vermittelt werden. Eine genaue Beschreibung des Werk- zeugs ndet sich in (Pleumann, 2004). Umfangreiche Untersuchungen haben gezeigt, dass DAVE, und damit auch dessen didaktisches Konzept, von den Studenten mehrheitlich positiv aufgenommen wurde (Kamphans u. a., 2004).In der Realitt werden Zustandsdiagramme oft im Bereich eingebetteter Systeme zur Spezikation und Verikation des Systemverhaltens verwendet (siehe Abbildung 1.2), da sich Fehler nachtrglich nicht oder nur zu hohen Kosten korrigieren lassen. Anima- tionen knnen also dazu genutzt werden, die real existierenden eingebetteten Systeme nachzuahmen, zu testen und im Rahmen der Lehre den Studierenden Aufgaben zu stellen, die an lebensnahe Anforderungen angelehnt sind.Letztlich ist diese Art der Visualisierung aber auch nur ein Versuch, die Kluft zwischen der abstrakten Notation von Zustandsdiagrammen und der Realitt zu berwin- den, um das Lernen zu erleichtern. Daher stellt sich die Frage, ob es nicht mglich ist, den Studenten ein reales eingebettetes System zur Verfgung zu stellen, an dem sie die praktische Anwendung von Zustandsdiagrammen trainieren knnen. Ein kostengnsti- ger Ansatz ist die Verwendung des Mindstorms Robotics Invention System 2.0 (LEGO, 2005), welches von der Firma LEGO im Rahmen ihrer Produktreihe LEGO Technik eingefhrt wurde. Dieses System verfgt ber einen programmierbaren Baustein und kann dazu genutzt werden einfache Roboter zu bauen. Die Programmierung erfolgt ber eine proprietre graphische Sprache, welche fr Kinder ausgelegt ist. Alterna-

13. 1.2. Zielsetzung 3 (a) Zwei Sensoren tasten den Boden ab und (b) Das zugehrige Zustandsdiagramm des melden dem Roboter, wenn die Fahrbahn Roboters. Die beiden Motoren reagierenerfasst wirdauf die Farbe des Untergrunds, welche dieSensoren melden Abbildung 1.2.: Beispiel fr die Verwendung von Zustandsdiagrammen ineingebetteten Systemen: Die Aufgabe besteht darin, dass ein Roboter einem vorgegebenen Weg folgttiven, welche eine klassische Programmierung zulassen, nden sich im Open-Source- Bereich und haben als Zielgruppe Programmierer, die eine vollstndige Kontrolle ber den Baustein erhalten wollen.Neben der praktischen Anwendung bietet das System einen fr die Lehre sehr wichtigen Zusatzfaktor, nmlich die Steigerung der Lernmotivation. Die LEGO-Roboter fgen eine spielerische Komponente zu den Lernaufgaben hinzu. Durch jene und die Mglichkeit, dass die Studenten selbst etwas kreieren knnen, kann die intrinsische Motivation gesteigert werden. Bei den Lernenden erhht sich durch Neugier, Spa und Interesse die Motivation, die bungen zu erledigen (Heidelberg, 2000). Ein weiterer Vorteil ist die Frderung der Gruppenarbeit: Es knnen Aufgaben gestellt werden, die vom Umfang her komplex sind und in Gruppen gelst werden mssen. Ein Beispiel hierfr ist die Realisierung eines Hochregallagers in einer Fallstudie an der Universi- tt Paderborn. Die dort gemachten Erfahrungen zeigen, dass der Einsatz der LEGO- Roboter von den Studenten mehrheitlich positiv aufgenommen wurde (Magenheim und Scheel, 2004). 1.2 Zielsetzung Da die LEGO-Roboter didaktisch erfolgreich eingesetzt wurden, sie ein einfaches eingebettetes System sind und die Verbindung zu Zustandsdiagrammen naheliegend ist, bietet es sich an Mindstorms in der Lehre einzusetzen und in ein didaktisches Werkzeug zu integrieren. Aufgrund der Tatsache, dass die Syntax und Semantik von Zustandsdia- grammen und nicht die Programmierung von LEGO-Robotern im Vordergrund stehen soll, muss nach einer Lsung gesucht werden, die es ermglicht die Programmierung

14. 1. Thema der Arbeit 4 vollkommen transparent zu gestalten. Die vorliegende Diplomarbeit behandelt die Inte- gration der LEGO-Roboter in das didaktische Werkzeug DAVE unter Bercksichtigung eben genannter Prmisse. Die Studenten sollen in der Lage sein, ihre Zustandsdiagram- me in DAVE zu modellieren und ber diese das Verhalten der Roboter zu spezizieren.Um eine hchstmgliche Akzeptanz seitens der Studenten zu erreichen, ist es ebenfalls erforderlich, dass die Syntax zur Steuerung der Roboter-Elemente sehr einfach zu erlernen ist und sich problemlos in die Notation von Zustandsdiagrammen integrieren lsst. Der zustzliche Lernaufwand muss also mglichst minimal sein.Bei nherer Betrachtung lsst sich erkennen, dass aus den in DAVE gegebenen Infor- mationen ber das modellierte Zustandsdiagramm ein Quellcode generiert und kompiliert werden muss, welcher als ausfhrbares Programm in den Roboter eingeladen werden kann. Um dieses Ziel zu erreichen, mssen im Rahmen der Diplomarbeit die folgenden Fragen geklrt werden: Welche Elemente von Zustandsdiagrammen sollen untersttzt werden? In welcher Relation stehen die gewhlten Elemente von Zustandsdiagrammen zu den elektro-mechanischen Bauteilen der LEGO-Roboter und wie lsst sich diese Relation im Diagramm darstellen? Wie knnen Zustandsdiagramme und deren Semantik in Quellcode abgebildet werden? Welche Daten stellt DAVE zur Verfgung und wie knnen diese verarbeitet werden, um daraus den bentigten Quellcode zu generieren? 1.3 Geplantes Vorgehen Die Arbeit gliedert sich in drei Teile. Im ersten Teil werden die notwendigen Grundbe- grie zum Thema Zustandsdiagramme und dem LEGO Mindstorms Invention System aufgearbeitet, damit eine Integration von LEGO in DAVE geplant und umgesetzt werden kann. Anschlieend werden im zweiten Teil die Konzepte und deren Umsetzung erlutert. Kapitel 3 beschreibt das gewhlte Gesamtkonzept der Kopplung beider Wel- ten. Auf dem gewhlten Ansatz aufbauend werden in den darauf folgenden Kapiteln 4 bis 8 die einzelnen Teile des Konzepts und deren Umsetzung behandelt. In Kapitel 9 des dritten Teils werden exemplarisch einige praktische Aufgaben fr den bungs- betrieb vorgestellt. Zum Abschluss der Arbeit werden rckblickend die Ergebnisse zusammengefasst und ein Ausblick auf mgliche Erweiterungen gegeben.

15. Kapitel 2 Grundbegrie Wie im vorherigen Abschnitt bemerkt wurde, ist es notwendig einige Grundbegrie aufzuarbeiten, ohne die die notwendigen Designentscheidungen zur Realisierung der Aufgabe nicht getroen werden knnen. Dieses Kapitel ist in zwei Teile aufgeteilt, welche die wichtigen Themengebiete behandeln. In Abschnitt 2.1 wird nher auf die fr die Arbeit relevanten Elemente von Zustandsdiagrammen eingegangen und es werden verschiedene Anstze zu deren Implementierung vorgestellt. Abschnitt 2.2 widmet sich dem LEGO Mindstorms Robotics Invention System und geht zunchst auf die technischen Details der Hardware ein, bevor verschiedene Mglichkeiten der Programmierung vorgestellt werden. 2.1 Zustandsdiagramme Zustandsdiagramme wurden erstmals 1987 von David Harel erwhnt und basieren auf einer Verallgemeinerung der Konzepte von endlichen Automaten (Harel, 1987). Sie knnen als gerichtete Graphen angesehen werden, die das Verhalten eines Objekts beschreiben und komplementr zu Sequenz- und Kollaborationsdiagrammen sind, welche die Interaktion verschiedener Objekte darstellen. Die beiden wesentlichen Erweiterun- gen seitens Harel waren die Einfhrung von Hierarchie und Nebenlugkeit, auf die im weiteren Verlauf noch eingegangen wird. Von der OMG wurden die vorgestellten Konzepte aufgegrien und fr die Verwendung in der UML leicht modiziert.Im Folgenden werden die Elemente und deren Semantik behandelt, wie sie in der Version 1.5, einer Untermenge der aktuellen Version 2.0, der UML-Spezikation (OMG, 2003) aufgefhrt sind und fr die eine Untersttzung in DAVE und LEGO Mindstorms vorgesehen ist. Eine genauere Beschreibung ndet sich in (Hitz und Kappel, 2003).2.1.1 Elemente und Semantik von Zustandsdiagrammen Zustnde und Aktionen Aufgrund der Graphenstruktur besitzen die Diagramme Knoten und (gerichtete) Kan- ten. Die Knoten reprsentieren die Zustnde, die das Objekt einnehmen kann, whrend die Kanten Zustandswechsel, die so genannten Transitionen, darstellen. Zustnde werden im Diagramm durch Rechtecke mit gerundeten Ecken dargestellt und knnen mit

16. 2. Grundbegrie 6 einem, den Zustand beschreibenden, Namen und Aktionen versehen werden. Hierbei werden im Rahmen der Diplomarbeit zwei Typen von Zustandsaktionen unterschie- den: Die entry-Aktion wird ausgefhrt, sobald der Zustand aktiviert, d. h. erreicht wird. Analog hierzu existiert die exit-Aktion, welche beim Verlassen des Zustands ausgefhrt wird. Zustzlich existiert noch die do-Aktion, die nach der entry-Aktion ausgefhrt wird, whrend der Zustand aktiv ist. Fr diese ist keine Untersttzung vorgesehen. Sie wird an dieser Stelle nur der Vollstndigkeit halber aufgefhrt. Die Aktionen haben keine spezielle Form und knnen im Prinzip beliebiger Natur sein. Sprich es ist mglich, Pseudocode ebenso zu verwenden wie konkrete Methodenaufru- fe in einer Programmiersprache oder Ausgaben von Ereignissen.Neben den normalen Zustnden beschreibt die UML noch eine weitere Art von Zustandstypen, die so genannten Pseudozustnde. Sie dienen einzig der Modellierung und sind keine echten Zustnde des Objekts. Daher kann ihnen keine Aktion zugeordnet werden bzw. das Objekt in ihnen verweilen.Damit bekannt ist, welcher Zustand bei Beginn der Bearbeitung aktiviert werden muss, wird dem Diagramm ein Pseudozustand, der so genannte Startzustand zugewiesen. Fr diesen gilt, dass von ihm nur Transitionen abgehen drfen. Analog zum Startzustand existiert der Endzustand. Dieser ist ein normaler Zustand, der jedoch keine Aktionen beinhalten kann. Fr diesen gilt, dass keine Transition den Zustand verlassen darf.Zustandsbergnge Ereignisse Der Wechsel zwischen zwei Zustnden wird in der Regel ber ein Er- eignis angestoen. Dies ist laut OMG (2003) das Ergebnis einer beliebigen Aktion innerhalb des Systems oder in der das System umfassenden Umgebung. Obwohl die Form eines Ereignisses nicht explizit festgelegt ist, unterscheidet die UML zwischen vier verschiedenen Ereignistypen, von denen hier nur die beiden fr die Arbeit relevanten erwhnt werden sollen: Das SignalEvent umfasst den zuletzt genannten Fall, dass das Ereignis durch eine Aktion auerhalb des Systems generiert wurde, whrend das TimeEvent auf einer Aktion innerhalb des Systems beruht. Ereignisse werden nur vom jeweils aktuell aktiven Zustand verarbeitet.Gehen von einem Zustand nur mit Ereignissen markierte Transitionen ab, so verweilt das Objekt so lange in dem Zustand, bis ein Ereignis auftritt, welches einen Zustandsbergang auslst. Ereignisse, welche im aktuellen Zustand keiner Transition zugeordnet sind, gehen verloren. Fr bergnge ohne Ereignismarkierung gilt die Be- endigung aller Aktionen des Zustands als Trigger. Tritt ein Ereignis auf, wird die derzeit aktive Aktion sofort unterbrochen und der Zustand verlassen. Bedingungen und Aktionen Neben einem Ereignis kann einer Transition eine Bedingung und eine Aktion zugeordnet werden. Erstere wird mittels der Schreibweise [y] und letztere durch /z an der Transition kenntlich gemacht. Bedingungen sorgen dafr, dass das Schalten nur dann mglich ist, wenn diese erfllt ist. So lsst sich beispielsweise verschiedenen Tran-

17. 2.1. Zustandsdiagramme 7 sitionen eines Zustands dasselbe Ereignis zuordnen. Abhngig von den Bedingungen knnen aber unterschiedliche Aktionen ausgefhrt oder verschiedene Zielzustnde erreicht werden.Prinzipiell ist es bei Zustandsbergngen allerdings mglich, ein nichtdeterminis- tisches Zustandsdiagramm zu modellieren, in welchem mehrere Transitionen gleichzeitig schalten knnen. In diesem Fall wird seitens der UML-Spezikation keine genaue Semantik vorgegeben. Somit bleibt es frei zu entscheiden, welche der Transitionen schalten kann. Fr die Markierung von Zustandsbergngen ergibt sich als Schreib- weise also Ereignis[Bedingung]/Aktion.Zeitgesteuerte Transitionen Durch das Schlsselwortafter (x) wird das TimeEvent gekennzeichnet. Dieses de-niert einen bestimmten Typ Zustandsbergang, die zeitge-steuerte Transition. Nach Ablauf der konstanten Zeitspan- ne x wird ein Ereignis getriggert, sodass die Transition bei erfllter Bedingung schalten kann. Als zeitlicher Bezug wird bei diesem Ereignistyp der Zeitpunkt des Eintritts in den aktuellen Zustand angenommen. Segmentierte Transitionen Ein weiterer Aspekt von Zu- standsdiagrammen sind die so genannten segmentierten Tran- sitionen. Mit ihnen ist es mglich, mehrere Zustandsbergnge miteinander zu verketten, um beispielsweise zu erreichen, dass in jeder Teiltransition eine Aktion ausgefhrt wird. Ebenfalls bieten sie die Mglichkeit, Verzweigungen zu modellieren. Die Verknpfung segmentierter Transitionen wird im Diagramm durch einen Pseudozustand in Form eines schwarzen Kreises dargestellt, der Verbindungsstelle.Eine segmentierte Transition ist immer atomar, d. h. sie schaltet entweder ganz oder gar nicht. Vor dem Zustandsbergang muss von der segmentierten Transition geprft werden, ob es einen Weg zum nchsten Zustand gibt. Doch es gibt noch eine weitere Besonderheit, die bercksichtigt werden muss: Nur dem ersten Segment der Transition darf ein Ereignis zugewiesen werden, whrend alle Segmente Bedingungen und Aktionen halten knnen.Hierarchische Zustnde In komplexen Systemen ist es hug notwendig, Sachverhalte zunchst zu abstrahieren und deren tatschliche Arbeitsweise in einem nachfolgenden Schritt genauer zu modellieren. Zustandsdiagramme bieten die Bildung von Zustandshierarchien an. Diese Oder-Verfeinerung ermglicht es, einen komplexen Zustand in Unterzustnde zu zer- legen, die den Sachverhalt genau beschreiben. Sobald das Objekt diesen Oder-Zustand erreicht, bendet es sich automatisch immer in genau einem Unterzustand der Verfei- nerung. Durch diese Schachtelung treten neue Besonderheiten auf, die im Folgenden behandelt werden. Start- und Endzustnde Innerhalb einer Oder-Verfeinerung muss bekannt sein, welcher Unterzustand bei Erreichen aktiviert wird bzw. wann der Zustand beendet

18. 2. Grundbegrie 8 ist. Diese Information wird, genau wie beim Diagramm selbst, mittels eines Start- und Endzustands dargestellt. Das Vorhandensein dieser Zustnde ist allerdings nicht immer notwendig. Warum dies so ist, wird im nchsten Abschnitt deutlich. Betreten und Verlassen des Zustands Es lassen sich zwei Arten unterscheiden, wie ein komplexer Zustand aktiviert werden kann:1. Eine ankommende Transition endet direkt am Oder-Zustand. In einem solchenFall ist es notwendig, dass in der Verfeinerung ein Startzustand speziziert ist.2. Eine ankommende Transition endet an einem beliebigen Subzustand der Verfei-nerung. In diesem Fall wird die Grenze des Oder-Zustands berschritten. Daherist kein Startzustand notwendig, da dieser implizit durch den Zielzustand derTransition gegeben ist.Das Verlassen des Zustands ndet im Wesentlichen analog statt:1. Der Zustand kann ber eine Transition verlassen werden, die von der Oder-Verfeinerung abgeht. Handelt es sich um einen bergang ohne Ereignismarkie-rung, die so genannte Beendigungstransition, kann diese nur schalten, falls dieBearbeitung in der Verfeinerung abgeschlossen ist. In diesem Fall ist das Vor-handensein eines Endzustands notwendig.2. Der Zustand kann ber eine Transition verlassen werden, die von einem Un-terzustand abgeht und als Ziel einen Zustand auerhalb der Oder-Verfeinerungbesitzt.Zustandsbergnge Transitionen in Hierarchien fhren bei nherer Betrachtung zu zwei Fragen, fr die eine Semantik bestimmt werden muss. Zunchst muss geklrt werden, was fr ereignismarkierte Transitionen gilt, die vom Oberzustand wegfhren. Denn laut Semantik bendet sich das Objekt zu jedem Zeitpunkt, whrend der Oder-Zustand aktiv ist, in genau einem der Unterzustn- de. Damit diese top-level-Ereignisse trotzdem verarbeitet werden knnen, werden die von der Oder-Verfeinerung abgehenden Transitionen an alle Unterzustnde vererbt. Anders ausgedrckt bedeutet dies, dass jeder Unterzustand alle ereignismarkierten Zustandsbergnge der Oberzustnde kennt, die sich auf dem Pfad vom Zustand zur Wurzel des Baums benden, der durch die Hierarchie aufge- spannt wird.Hieraus leitet sich die nchste Frage ab: Was passiert, wenn in einem Unterzustand eine geerbte Transition berschrieben wird, das heit auf dasselbe Ereignis reagiert wie die vom Oberzustand geerbte Transition? In diesem Fall existieren ggf. mehrere mgliche bergnge, die in einem Schritt schalten knnen. Es wird eine Vorrangsre- gel bentigt, die festlegt, welche der Transitionen schalten kann. Hierzu werden den Zustandsbergngen Prioritten zugeordnet, was zu folgender Regel fhrt:

19. 2.1. Zustandsdiagramme 9 Denition: Vorrangsregel Sei t1 eine vom Zustand s1 wegfhrende Transition und s1 ein transitiv erreichbarer Unterzustand von s2 . t2 ist ein von s2 wegfhrender Zustandsbergang mit derselben Ereignismarkierung wie t1 . Dann hat die verschachtelte Transition t1 eine hhere Prioritt als t2 (OMG, 2003). Es werden immer die bergnge schalten, die in der Hierarchie weiter unten ange- siedelt sind und das Verhalten des komplexen Zustands spezizieren. Anhand dieser Regel lsst sich die Idee der Verfeinerung von Zustnden erkennen. History-Zustnde In vielen Systemen ist es zum Teil notwendig zu wissen, in welcher Konguration sich der komplexe Zustand beim letzten Verlassen befun- den hat. Mit dieser Information kann die Bearbeitung an derselben Stelle fortgefhrt werden, an der sie zuletzt unterbrochen wurde. Diese Ablaufhistorie wird in hierarchischen Zustnden ber Pseudozustnde mo- delliert. Diese History-Zustnde werden im Diagramm durch H bzw. H gekennzeichnet und lassen sich in zwei Kategorien unterteilen:1. Die ache Historie (H) eines Oder-Zustands speichert den zuletzt aktiven Sub-zustand.2. Die tiefe Historie (H ) eines Oder-Zustands speichert alle Zustnde fr die gilt,dass sie aktiv sind und sich auf dem Pfad vom hierarchischen Zustand zu einemBlatt des Hierarchiebaums benden. Im Gegensatz zu klassischen Statecharts muss fr die History-Zustnde der UML- Zustandsdiagramme eine Starttransition angegeben werden. Diese geht vom History- Zustand aus und fhrt zu dem Zustand, der aktiviert werden soll, falls noch keine Historie vorliegt. Dies ist genau dann der Fall, wenn der Oder-Zustand das erste Mal betreten wird. Andernfalls wird der Zustand aus der Historie bzw. die Zustnde der tiefen Historie aktiviert.Nebenluge Zustnde Eine weitere Neuerung gegenber endlichen Automaten ist die Modellierung von Ne- benlugkeit. Hierbei handelt es sich um einen Zustand, welcher mindestens zwei gleichzeitig aktive Subzustnde besitzt. Diese bilden die einzelnen Regionen des Zustands. Daher wird dieser Typ auch als Und-Zustand bezeichnet. Die Regionen werden ber eine gestrichelte Linie im Diagramm voneinander getrennt. Nebenlugkeit zieht jedoch konzeptionelle Konsequenzen nach sich, auf die im Folgenden eingegangen wird. Regionen In einer Und-Verfeinerung werden die einzelnen Regionen durch hierarchische Zustnde beschrieben, sodass die dort beschriebene Semantik hier ebenfalls anzuwenden ist. Grundstzlich sind alle Regionen der Verfeinerung aktiv, sobald der

20. 2. Grundbegrie10 Und-Zustand betreten wird. Sie knnen als eine Art Prozesse angesehen werden, die parallel innerhalb der Verfeinerung laufen. Es knnen also nicht einzelne Bereiche ausgeschal-tet werden. Ankommende Ereignisse werden immer vonallen Regionen verarbeitet, was dazu fhren kann, dassmehrere Regionen das Ereignis verarbeiten und somitpotenziell verschiedene Transitionen gleichzeitig schal-ten knnen. Zustzlich werden wie bei hierarchischenZustnden die wegfhrenden ereignismarkierten Transi- tionen der Verfeinerung an jede Region - also an alle Unterzustnde - vererbt und bergnge mit hherer Prioritt beim Schalten bevorzugt. Betreten und Verlassen des Und-Zustands Wird der Zustand aktiviert, muss dafr gesorgt werden, dass alle Regionen ebenfalls aktiviert werden. Analog mssen alle Bereiche deaktiviert werden, sobald der Zustand verlassen wird. Wie bei der Oder-Verfeinerung lassen sich je zwei Flle unterscheiden: 1. Endet die ankommende Transition am Und-Zustand, muss fr alle Regionen einStartzustand angegeben werden. 2. Endet die ankommende Transition an einem Unterzustand genau einer Region,wird die Oder-Verfeinerung implizit betreten und alle anderen Regionen mssenan dem jeweiligen Startzustand aktiviert werden. Es mssen n 1 Startzustndevorhanden sein. Das Verlassen des Zustands ndet im Wesentlichen analog statt: 1. Erreichen alle Regionen ihre Endzustnde, kann der Und-Zustand ber die Be-endigungstransition verlassen werden. Die Regionen werden an den jeweiligenEndzustnden synchronisiert. 2. Schaltet eine Transition von einem Unterzustand einer beliebigen Region undhat ein Ziel auerhalb der Und-Verfeinerung, werden alle Regionen unabhn-gig von ihrem derzeit aktuellen Zustand verlassen und der nebenluge Zustanddeaktiviert. Eben diese Semantik gilt auch fr vom Superzustand geerbte ereig-nismarkierte Transitionen. Komplexe Transitionen Bei genauerer Betrachtung wurden bisher zwei Flle behandelt, wie Regionen aktiviert werden knnen. Zum einen explizit und zum anderen implizit. Im ersten Fall beginnen alle Bereiche an ihren Startzustnden, im letzteren n 1 Regionen an ihrem Startzustand und eine an einem beliebigen Subzustand, nmlich dem Ziel der Transition. Es fehlt noch der Fall, dass m Regionen an einem beliebigen Unterzustand beginnen, wobei 1 < m < n ist. Sicherlich knnen die Startzu- stnde so angelegt werden, dass sie das gewnschte Verhalten widerspiegeln, doch was ist, wenn dies nicht gewnscht ist? Die Startzustnde knnen beispielsweise die Stan- dardkonguration modellieren, whrend in einem Spezialfall die Oder-Verfeinerung in einer anderen Konguration beginnen soll.

21. 2.1. Zustandsdiagramme11Um dieses Verhalten abbilden zu knnen, existieren die komplexen Transitionen. Sie zeichnen sich dadurch aus, dass der Kontrolluss aufgeteilt wird, also aus einer ankommenden Transition mehrere generiert werden. Somit kann pro Region maximal eine neue Transition entstehen, deren Ziel ein Zustand in der Region ist. Ein analoger Fall lsst sich natrlich auch fr das Verlassen der Oder-Verfeinerung beschreiben. Somit bieten komplexe Transitionen zwei Funktionsarten:1. Das Aufteilen einer in mehrere Transitionen, um direkt Unterzustnde der einzel-nen Regionen anspringen zu knnen. Bereiche, die von der komplexen Transitionnicht bercksichtigt werden, also keine Zustandsbergnge in diese fhren, wer-den automatisch an ihren Startzustnden aktiviert.2. Das Synchronisieren einzelner Regionen, um den Zustand zu verlassen, sobaldbestimmte Unterzustnde erreicht werden. Bereiche, die von der komplexen Tran-sition nicht bercksichtigt werden, also keine bergnge aus diesen Regionenfhren, werden unabhngig von ihrem aktuellen Zustand automatisch beendet.In der Modellierung werden hierfr zwei Pseudozustnde bercksichtigt, die beide durch einen schwarzen Synchronisationsbalken gekennzeichnet werden. Dieser Balken entspricht dem Fork-Zustand genau dann, wenn er eine 1 : n-Abbildung reprsentiert, d. h. aus einer ankommenden Transition mehrere abgehende werden. Als Join-Zustand wird er dann bezeichnet, wenn er eine n : 1-Abbildung reprsentiert, also mehrere ein- gehende Transitionen synchronisiert und zu einer abgehenden zusammenfasst.2.1.2 Implementierungsanstze Nachdem die fr die Arbeit relevanten Elemente von Zustandsdiagrammen und deren Semantik errtert wurden, sollen im Folgenden verschiedene Mglichkeiten behandelt werden, diese in Quellcode abzubilden. Die vorgestellten Konzepte basieren auf den klassischen Methoden der Implementierung endlicher Automaten.Prozedurale Implementierung Mittels prozeduraler Programmiersprachen lassen sich endliche Automaten einfach und ezient ber geschachtelte switch-case-Anweisungen implementieren. Hierzu wird der aktuelle Zustand in einer globalen Variable gehalten, whrend Aktionen als Prozedur implementiert werden. Ein einfacher endlicher Automat liee sich wie in Abbildung 2.1 darstellen.Um ein Ereignis verarbeiten zu knnen, wird zunchst der aktuelle Zustand gewhlt und fr diesen geprft, ob er das Ereignis verarbeiten kann. Durch die Kapselung der Aktionen in einzelne Prozeduren ist es mglich diese wiederzuverwenden. Des Weiteren lsst sich insgesamt ein Programm erzeugen, welches wenig Speicher bentigt und in der Regel schnell ist. Jedoch hat diese Implementierung auch essenzielle Nachteile: Der Quelltext wird schnell unbersichtlich, schlecht wartbar und fehleranfllig.

22. 2. Grundbegrie12 i n t s t a t e = A ; . . . void fsm ( e v e n t ) { switch ( s t a t e ) case A: switch ( e v e n t ) case x : a cti on X ( ) ; s t a t e = B ; break ; case y := a cti on Y ( ) ; s t a t e = A ; break ; break ; case B : switch ( e v e n t ) case y : a c t i o n Z ( ) ; s t a t e = A ; break ; break ; } Abbildung 2.1.: Umsetzung eines endlichen Automaten in prozeduralen Quelltext Oder- bzw. Und-Verfeinerungen lassen sich nicht abbilden und mssen zunchst aus dem Diagramm entfernt werden, ohne die Semantik einzuschrnken (Harel, 1987). Dieses Pltten ist allerdings problematisch, da die resultierende Anzahl der Zustnde enorm gro werden kann.Objektorientierte Anstze Das State-Pattern Eine Alternative bietet der objektorientierte Ansatz. Fr endliche Automaten hat sich das von Erich Gamma vorgestellte State-Entwurfsmuster etabliert (Gamma u. a., 1995). Das zentrale Konzept ist die Kapselung der Zustnde in einzelne Objekte, welche von einer abstrakten Basisklasse alle Methoden erben und bei Bedarf berschreiben. Methoden reprsentieren die Aktionen einer Transition. Zu- dem gibt es den Kontext, welcher den Zugri zum endlichen Automaten anbietet und eine Referenz auf den derzeit aktuellen Zustand hlt. Die Aufgabe des Kontext besteht darin, ankommende Ereignisse (die Methodenaufrufe) an den aktuellen Zustand weiter zu delegieren. Der oben dargestellte Beispielautomat kann mit Hilfe des State-Patterns wie in Abbildung 2.2 implementiert werden.Auch hier lsst sich erkennen, dass die essenziellen Elemente nicht untersttzt werden. Es muss eine Lsung gefunden werden, die es erlaubt das Entwurfsmuster sowie Hierarchie und Nebenlugkeit zu verwenden. In (Ali und Tanaka, 1999) wird eben dieses Problem behandelt und eine Lsung vorgestellt. Die Idee ist das Verwenden der Vererbungshierarchie zur Darstellung der Oder-Verfeinerung. Das heit, eine von A erbende Klasse B ist Unterzustand von A. Hier ist zu erkennen, dass die Semantik der Vererbung von Transitionen erfllt ist, da sich dies eins zu eins auf die Klassenhier-

23. 2.1. Zustandsdiagramme 13Abbildung 2.2.: Umsetzung des Beispielautomaten mit Hilfe des State-Patterns archie abbilden lsst. Oen bleibt, wie sich nebenluge Zustnde realisieren lassen. Die Lsung ist naheliegend: In Zustandsdiagrammen besteht eine Und-Verfeinerung aus mindestens zwei hierarchischen Zustnden. Also hlt der Und-Zustand eine Refe- renz auf eine Oder-Verfeinerung. Genau dies wird in dem Ansatz von Ali und Tanaka verwendet. Der Und-Zustand ist eine Klasse, welche Referenzen auf die Regionen hlt und die einzelnen Ereignisse an die Regionen delegiert (siehe Abbildung 2.3). = Abbildung 2.3.: Beispiel der Abbildung von Hierarchie und Nebenlugkeit in dieKlassenhierarchie objektorientierter Sprachen auf Basis des State-Patterns Der Ansatz von Gurp und Bosch Beim State-Pattern ist das zentrale Konzept der Zustand. Dies fhrt dazu, dass Elemente wie Aktionen und Transitionen nicht als eigenes Objekt reprsentiert werden, sondern implizit in der Zustandsklasse versteckt sind. Ein alternativer Ansatz wurde von Jilles van Gurp und Jan Bosch vorgestellt (van Gurp und Bosch, 1999). Dieser verlagert das Konzept auf die explizite Modellierung der Elemente endlicher Automaten als eigene Objekte. Hier wird nicht der Zustand, sondern die Transition als zentrales Element betrachtet. Diese kennt den Zielzustand und die auszufhrende Aktion, whrend der Zustand seine abgehenden Transitionen kennt und diese mit einem Ereignis verknpft.Der Kontext dient als Schnittstelle des Zustandsdiagramms zur Anwendung und leitet die Ereignisse an den jeweils aktuellen Zustand weiter. Dieser prft in seiner Liste

24. 2. Grundbegrie14 Abbildung 2.4.: Klassendiagramm des FSM-Frameworks von Bosch und van Gurp aus (Ereignis, T ransition)-Tupeln, ob das Ereignis verarbeitet werden kann und fhrt den bergang ggf. aus. Aktionen werden mittels des Command-Patterns (Gamma u. a., 1995) ausgefhrt, sodass verschiedenartige Aktionen implementiert, aber diese auch wiederverwendet werden knnen. Da ein Ziel in dem Ansatz die Wiederverwendbarkeit des Zustandsdiagramms ist, werden ablaufspezische Daten nur im Kontext verwaltet. Dies bedeutet, dass sich verschiedene Kontexte dasselbe Diagramm teilen knnen. Aus diesem Grund wird in der Implementierung der Kontext als Referenz mit bergeben (siehe Abbildung 2.4). Jedoch fehlt auch in diesem Ansatz die Untersttzung der wesentlichen Elemente von Zustandsdiagrammen und beschrnkt sich auf die Abbildung endlicher Automa- ten. Die Laufzeitsemantik, Hierarchie und Nebenlugkeit muss explizit implementiert werden, whrend sie beim Ansatz von Ali und Tanaka implizit auf Elemente der Pro- grammiersprache abgebildet werden. 2.2 LEGO Mindstorms Roboter Das LEGO Mindstorms Robotics Invention System wurde erstmals im Jahr 1998 vorgestellt und basiert auf einer Zusammenarbeit der Firma LEGO mit dem Massachusetts Institute of Technology (MIT). Es erweitert die Produktlinie LEGO Technik um einen frei programmierbaren Baustein und ermglicht so das Erstellen elektro-mechanischer Komponenten wie zum Beispiel Roboter. Aufgrund der Freiheiten, die LEGO mit seinem System bietet, ist es mglich eine Vielfalt verschiedenster Roboter zu bauen. Daher soll in diesem Abschnitt zunchst auf die Hardware nher eingegangen werden, bevor anschlieend die verfgbaren Mglichkeiten der Programmierung beleuchtet werden.2.2.1 Aufbau der Hardware Bei dem von LEGO verwendeten RCX-Baustein handelt es sich um einen Mikrocon- troller der Firma Hitachi mit 16MHz. Der Controller besitzt zur Interaktion mit der Umwelt drei Eingnge fr Sensoren und drei Ausgnge. Derzeit existieren Druck-, Rotations-, Licht- und Temperatursensoren sowie Motoren und Lampen, welche an

25. 2.2. LEGO Mindstorms Roboter15 Abbildung 2.5.: Der RCX-Baustein die Ausgnge angeschlossen werden knnen. Es stehen dem Anwender 32KB RAM und 16KB ROM zur Verfgung. Im ROM werden low-level-Funktionen und Basistrei- ber zur Steuerung der Ausgnge, Sensoren und der Infrarot-Schnittstelle bereitgestellt. ber letztere wird der RCX mit einer Firmware versorgt, die das Betriebssystem darstellt und die Programmierung ermglicht. Die 32KB Arbeitsspeicher stehen nicht ausschlielich fr eigene Programme zur Verfgung, sondern halten neben dem Programm auch dessen Laufzeitobjekte und die Firmware. Somit steht je nach verwendeter Firm- ware unterschiedlich viel Speicher fr eigene Programme und Daten zur Verfgung.2.2.2 Programmierung der LEGO-Roboter Die Firma LEGO bietet ein eigenes Betriebssystem an, welches jedoch nicht mittels einer Hochsprache programmiert werden kann. Stattdessen wird eine graphische Mo- dellierungssprache angeboten, die ber eine proprietre Windows-Software verwendet werden kann. Diese erstellt aus dem Modell schlielich das Programm fr den RCX- Baustein. Im Wesentlichen wird also dasselbe Vorgehen verwendet, welches im Rah- men dieser Diplomarbeit behandelt werden soll: Aus einer graphischen Modellierung ein ausfhrbares Programm zu erstellen.Da die Modellierungssprache von LEGO fr Kinder ausgelegt ist, lassen sich komplexe Ablufe nur umstndlich bis gar nicht beschreiben. Ziel verschiedener Entwickler war es eine Mglichkeit zu schaen, mit der die Roboter klassisch programmiert werden knnen. Aus diesem Grund wurden alternative Betriebssysteme entwickelt, wobei die drei bekanntesten jeweils kurz beleuchtet werden.Not Quite C Basierend auf der original LEGO-Firmware implementiert NQC (Baum und Hansen, 2004) eine eigene prozedurale Programmiersprache, die an C angelehnt ist. Objektori- entierte Konzepte lassen sich hier also nicht umsetzen.

26. 2. Grundbegrie16 BrickOS Das ursprnglich von Markus L. Noga entwickelte Betriebssystem BrickOS (Noga, 2002) ersetzt das Original der Firma LEGO. Als Compiler wird der GCC verwendet, sodass der Quellcode nativ fr den Hitachi-Prozessor kompiliert und gelinkt wird. Pro- gramme knnen in der Hochsprache C++ entwickelt werden und bietet demnach auch die Mglichkeiten dieser Sprache, inklusive Bibliotheken wie der Standard Template Library und der manuellen Speicherverwaltung.LeJOS Das auf TinyOS aufbauende LEGO Java Operating System (Solorzano, 2000) implementiert eine virtuelle Maschine fr Java und ersetzt wie BrickOS die Firmware von LEGO. Programme lassen sich in Java, und somit objektorientiert, implementieren. LeJOS greift auf eine abgespeckte Java API zurck, die die essenziellen Klassen der Sun API nachbildet. Im Gegensatz zum Original bietet diese virtuelle Maschine keine Garbage Collection an, die das Aufrumen von Objekten bernimmt. Einmal angelegte Objekte bleiben die komplette Laufzeit des Programms im Speicher bestehen. Diese drei Mglichkeiten der Programmierung des RCX gehren zu den bekanntesten und am meisten eingesetzten. Im nchsten Kapitel werden zunchst die Vor- und Nachteile der einzelnen Lsungen diskutiert. Auf diesem Ergebnis aufbauend, werden die vorgestellten Anstze zur Implementierung von Zustandsdiagrammen verglichen und begutachtet, um daraus ein Konzept und eine Vorgehensweise fr diese Diplom- arbeit abzuleiten.

27. Kapitel 3 Lsungsansatz Das Konzept zur Durchfhrung der Integration von LEGO Mindstorms in DAVE basiert auf mehreren Voraussetzungen und Anforderungen. Zunchst soll die Frage diskutiert werden, auf welcher technischen Basis die Programmierung des RCX durchgefhrt werden soll. 3.1 Zielplattform Es wurden die drei Laufzeitumgebungen NQC, BrickOS und LeJOS kurz vorgestellt. Natrlich hngt die Auswahl auch mit dem gewnschten Programmierkonzept und dem verfgbaren Speicherplatz des RCX zusammen. Ausgehend von den vorgestellten Implementierungsanstzen lsst sich zusammenfassen, dass der prozedurale Ansatz den Vorteil hat, dass die resultierenden Programme in der Regel klein sind. Das objektorientierte Programmierparadigma erleichtert hingegen die Implementierung, da auf das Pltten von Zustandsdiagrammen verzichtet werden kann und somit ein komplexer Schritt entfllt. Daher werden im Rahmen dieser Arbeit nur objektorientierte Anstze verfolgt, was zur Konsequenz hat, dass NQC nicht nher betrachtet wird.BrickOS bietet die Vorteile, dass mittels C++ der Speicher des RCX frei verwaltet werden kann und nativer Maschinencode fr den im RCX verbauten Hitachi-Prozessor generiert wird. Diese beiden Punkte haben zur Folge, dass sehr kleine Programme entstehen, sodass der verfgbare Speicher ezient ausgenutzt werden kann. Allerdings bedingt C++ durch seine Konzepte und dem freien Speicherzugri potenziell eine relativ hohe Fehleranflligkeit. Es mssen sprachbedingte Probleme beachtet werden, wie zum Beispiel zyklische Abhngigkeiten bei der Einbindung der Header-Dateien. Diese Argumente erschweren zwar die Implementierung, bilden aber noch kein Aus- schlusskriterium. Das wichtigste Argument gegen BrickOS ist, dass der Einsatz in der Lehre geplant ist und somit gewhrleistet sein muss, dass die Studenten ohne zustz- lichen Aufwand die Funktionalitt aus DAVE heraus auch zu Hause nutzen knnen. Dies ist bei BrickOS in dieser geforderten Form allerdings nicht ohne weiteres mglich, da diese Plattform auf freien Unix-Werkzeugen basiert, welche unter Windows nur mit erheblichem Aufwand verwendet werden knnen. Selbst die Installation von BrickOS unter Unix-Systemen ist nicht trivial.LeJOS hingegen wird in Form von jar-Dateien ausgeliefert, welche keine weitere Installation erforderlich machen. Daher knnen die bentigten Elemente von LeJOS

28. 3. Lsungsansatz18 direkt in DAVE mitgeliefert werden, ohne dass die Studenten zustzliche Installations- routinen ausfhren mssen. Zudem wird mit Java eine moderne Programmiersprache angeboten, welche nicht nur betriebssystemunabhngig ist, sondern sich auch gut in DAVE einbinden lsst, weil dieses in selbiger Sprache implementiert ist. Da es sich bei LeJOS nur um eine abgespeckte Variante einer Java-Laufzeitumgebung handelt, mssen allerdings Einschrnkungen hingenommen werden: Einmal angelegte Objekte knnen nicht mehr freigegeben werden und belegen den allokierten Speicher bis zur Programmbeendigung. Die Firmware verbraucht einen hohen Anteil an Speicher des RCX, sodass fr eigene Programme und Daten nur ca. 9 Kilobyte zur Verfgung stehen.Durch die fehlende Garbage Collection, die groe Firmware und die Tatsache, dass Java-Programme im Allgemeinen relativ gro sind, besteht die Gefahr, dass nur klei- nere Zustandsdiagramme umgesetzt werden knnen. Da dies fr die Lehre keine wesentliche Einschrnkung ist, erscheint LeJOS als erste Wahl und soll als Basis fr die weiteren konzeptionellen Entscheidungen dienen. 3.2 Ansatzpunkte zur Integration in DAVE Ein weiterer wichtiger Aspekt ist die Analyse der Konzepte von DAVE, um mgliche Ansatzpunkte zu nden, an denen die Integration angesetzt werden kann. Da ein we- sentliches Alleinstellungsmerkmal dieser Software die Simulation der Diagramme ist, existiert in DAVE eine Simulationsmaschine fr Zustandsdiagramme. Sie basiert auf dem um Hierarchie und Nebenlugkeit erweiterten Ansatz von Bosch. Die Persistenz- schicht zum Speichern wird durch das LIMO-Framework realisiert. Dieses schreibt die Datenstruktur zur Beschreibung eines Zustandsdiagramms in einem einfachem XML- Format auf die Festplatte. Es ergeben sich zwei Fragestellungen: Kann die vorhandene Simulationsmaschine verwendet werden und welche Form der Datenstruktur soll als Basis der Integration dienen? Die nchsten beiden Abschnitten behandeln diese Fragen. 3.2.1 Die Simulationsmaschine Zunchst stellt sich die Frage wie sich die in DAVE vorhandene Laufzeitumgebung fr Zustandsdiagramme verwenden lsst. Dies lsst sich leicht beantworten, denn die vorhandene Implementierung ist zu umfangreich, um sie im RCX verwenden zu knnen. Modikationen an der existierenden Laufzeitumgebung knnten zwar durchgefhrt werden, knnen aber zu unerwnschten Seiteneekten innerhalb DAVEs fhren, sodass zustzliche Tests des gesamten Programms notwendig sind. Diese Aspekte implizieren die Planung und Realisierung einer eigenen, speicherminimalen Simulationsmaschine, die vllig unabhngig von DAVE ist.

29. 3.3. Implementierung19 3.2.2 Wahl der zu verwendenden Datenstruktur Der zweite Aspekt ist die zu verwendende Datenstruktur. Als Basis knnen entweder die Klassen verwendet werden, welche DAVE zur Beschreibung des Diagramms zur Verfgung stellt, oder aber die rein textuelle Reprsentation in Form der XML-Datei. Beim ersten Ansatz muss die Simulationsmaschine entwickelt werden, whrend beim letzteren zustzlich eine geeignete Datenstruktur geplant und programmiert werden muss. Trotzdem ist die Verwendung der XML-Datei sinnvoller. Denn fr die existierenden DAVE-Klassen ist nicht klar, ob sich diese in einer speicherplatzoptimierten Simulationsmaschine ohne Modikation verwenden lassen. nderungen der Quellen fhren jedoch zu schon oben genanntem Problem. Somit ist letztlich eine sehr lose Kopplung an DAVE der zu whlende Weg. Einzig die Codegenerierung ist an spezische Teile, nmlich das XML-Format, gekoppelt, whrend der Rest eine Wiederver- wendbarkeit auerhalb von DAVE gewhrleistet. Diese Datei wird als Eingabe fr ein Ant-Skript (Davidson, 1999) dienen, welches die notwendigen Schritte zur Fertigstel- lung des RCX-Programms automatisiert (siehe Kapitel 8). 3.3 Implementierung Da eine sehr lose Kopplung an DAVE gewhlt wird, soll dieser Ansatz auch auf die LEGO-spezischen Teile ausgedehnt werden. Diese Entscheidung basiert ebenfalls auf der Idee, einzelne Komponenten wiederverwenden zu knnen. Wie lsst sich die Implementierung realisieren? Hierzu werden im ersten Schritt die von LeJOS generierten Programme nher betrachtet. Dabei fllt auf, dass die Ver- wendung von Klassen speichertechnisch teuer ist. Pro Klasse entsteht je nach deren Umfang ein Speicherverbrauch von rund 500 bis 1024 Bytes. Jede Instanz kostet hingegen im Durchschnitt nur wenige Bytes. Das Ziel ist daher die Anzahl an Klassen mglichst minimal zu halten und stattdessen viele Objekte zu erzeugen. Der Implementierungsansatz von Ali und Tanaka fllt dadurch auf, dass er eine groe Anzahl an Klassen generiert, nmlich mindestens so viele wie Zustnde existieren. Zudem erfordert dieser Ansatz, dass die Codegenerierung den Quelltext jedes einzelnen Zustands in Form einer Klasse erzeugt. Denn innerhalb dieser existiert spezischer Quelltext fr die Transitionen und Aktionen des Zustandsdiagramms. Dies fhrt zu einer enormen Steigerung der Komplexitt bei der Codegenerierung. Wnschenswert wre hingegen ein Framework, welches eine einfache Programmierschnittstelle bietet, die bei der automatischen Erzeugung des Quelltexts aus der XML-Datei verwendet werden kann. 3.4 Gesamtaufbau Die Hauptprobleme liegen in der Entwicklung eines Frameworks zur Reprsentation und Ausfhrung von Zustandsdiagrammen, welches mit den begrenzten Ressourcen des RCX verwendbar ist und der berlegung, wie aus der XML-Datei Quellcode generiert

30. 3. Lsungsansatz20 Abbildung 3.1.: Aufbau des Konzepts. Die Nummern in den Kreisen geben die Kapitel an, in denen der jeweilige Teil behandelt wird, whrend die mit Ant gekennzeichneten Pfeile die Schritte angeben, die ber das Ant-Skript automatisiert werden. werden kann. In Abbildung 3.1 ist der geplante Aufbau zu sehen. Nach dem Spei- chern des Diagramms in DAVE wird die XML-Datei in Quelltext transformiert. Die- ser variable Teil verwendet die Programmierschnittstellen des statischen Teils, nmlich des Frameworks. Aus dem generierten Quelltext kann schlielich mittels vorhandener Werkzeuge das Programm kompiliert, gelinkt und in den RCX hochgeladen werden. Diese Schritte werden mittels Ant automatisiert.Das Framework selbst soll auf dem Ansatz von Bosch und van Gurp basieren, jedoch um die bentigten Elemente fr Zustandsdiagramme erweitert. Durch die Verwendung dieses Ansatzes kann die Anzahl der Klassen auf ein Minimum reduziert werden, indem die einzelnen Elemente von Zustandsdiagrammen explizit durch eine Klasse reprsentiert werden. Somit steigt nur die Anzahl der Instanzen. Zustzlich kann das Frame- work in zwei Teile getrennt werden. Zum einen die eigentliche Laufzeitumgebung fr Zustandsdiagramme und zum anderen die LEGO-spezischen Teile. So lsst sich erreichen, dass das Framework auch unabhngig von LEGO wiederverwendet werden kann, etwa in anderen eingebetteten Umgebungen.Weitere Vorteile dieser Vorgehensweise sind erkennbar: Die Codegenerierung verein- facht sich erheblich, da sie sich auf die Erzeugung genau einer einzigen Klasse beschrn- ken kann. Und der statische Teil des Systems kann automatisiert getestet werden, was bei komplexem, dynamisch generierten Quelltext nur mit Aufwand mglich ist.Es lassen sich insgesamt vier Teilaufgaben entdecken, die in den folgenden Kapiteln bearbeitet werden. Die erste Aufgabe besteht in der Planung der Laufzeitumgebung fr Zustandsdiagramme (Kapitel 4). Die zweite Aufgabe lsst sich in zwei Bereiche splitten. Zunchst muss berlegt werden, wie die RCX-spezischen Elemente in die Notation von Zustandsdiagrammen eingebettet werden knnen (Kapitel 5), bevor deren technische Umsetzung, also die LEGO-Erweiterung des Frameworks, beschrieben werden kann (Kapitel 6). Die dritte Aufgabe ist die Planung und Umsetzung der Code- generierung (Kapitel 7), gefolgt von der letzten Aufgabe, der Integration der einzelnen Teile in Form eines Automatisierungs-Skripts (Kapitel 8).

31. Kapitel 4 Das Statechart-Framework4.1 Konzeptioneller Aufbau Die genannten Anforderungen an das zu entwickelnde Framework fr Zustandsdia- gramme erfordern zunchst konzeptionelle Vorberlegungen. Als Basis dient das von Bosch und van Gurp vorgestellte Framework fr endliche Automaten, dessen Imple- mentierung in Abbildung 2.4 zu sehen ist. Wie beim State-Pattern wird auch bei diesem ein Kontext eingesetzt, welcher den aktuellen Zustand kennt und Ereignisse an diesen delegiert. Allerdings wird dem Kontext ein weiterer Zweck zugeteilt: Bosch und van Gurp adressieren das Problem der mehrfachen Nutzung des Automaten und kapseln ablaufspezische Daten, wie z. B. Variablenwerte, in dem Kontext. Dies bedeutet, dass ein Zustand nur ein Teil der Infrastruktur des Automaten ist und somit verschiedene Kontexte gleichzeitig auf denselben Automaten zugreifen knnen. Daher wird in den Methoden dispatch und execute jeweils eine Referenz des aktuellen Kontexts bergeben, sodass Aktionen und Zustnde die Mglichkeit haben, Daten in diesem zu setzen und abzufragen. Der fr dieses Framework gewhlte Ansatz sieht hingegen nicht die mehrfache Nutzung desselben Diagramms mit unterschiedlichen Kontexten vor.Im Gegensatz zu endlichen Automaten knnen Zustandsdiagramme Hierarchien beinhalten, sodass es mglich ist, dass mehrere Zustnde gleichzeitig aktiv sind. Die Menge der aktuell aktiven Zustnde wird im Folgenden als Konguration bezeichnet. Das Zustandsdiagramm bendet sich zu jedem Zeitpunkt in einer eindeutigen Kongu- ration. Da nicht die Infrastruktur des Diagramms mehrfach genutzt werden soll, ist es nicht notwendig die Information ber die Konguration im Kontext zu speichern, sondern kann in die Zustnde des Diagramms verlagert werden. Das heit, jeder Zustand wei zu jedem Zeitpunkt, ob er aktiviert ist.Wozu dient also der Kontext? Werden zunchst Hierarchien und nebenluge Zu- stnde auer acht gelassen, fllt diesem dieselbe Aufgabe wie beim State-Pattern zu, nmlich ein eingehendes Ereignis an den aktuell aktiven Zustand weiterzuleiten. Da ein Zustand ebenfalls ein Ereignis verarbeitet, lsst sich der Kontext als ein Spezial- fall eines Zustands ansehen, in dem nur die Ereignisverarbeitung berschrieben wird und die Zusatzinformation des aktuell aktiven Unterzustands bekannt ist. Der Kontext kann als zusammengesetzter Zustand betrachtet werden. Diese Sichtweise wird spter bei der Implementierung der hierarchischen und nebenlugen Zustnde helfen.

32. 4. Das Statechart-Framework22 Abbildung 4.1.: Konzeptioneller Aufbau des Frameworks ohne Bercksichtigunghierarchischer und nebenluger Zustnde Ereignisse knnen in Zustandsdiagrammen beliebiger Natur sein. Dieser Umstand und die Tatsache, dass als Zielsetzung die Erweiterbarkeit des Frameworks zugrunde liegt, stellt entsprechende Anforderungen an die Konzeption. Bei Bosch werden Er- eignisse durch eine Zeichenkette reprsentiert, was jedoch unexibel ist. Stattdessen eignet sich das Command-Entwurfsmuster: In einer Schnittstelle wird eine Methode deklariert, welche in einer implementierenden Klasse ausprogrammiert wird und vom Framework verwendet werden kann. Dieses Verfahren wird von Bosch fr die Aus- fhrung von Aktionen verwendet. Da sich dieses Muster fr Aktionen eignet, sollen hiermit ebenfalls Bedingungen und Ereignisse realisiert werden.Beim Aktivieren bzw. Deaktivieren werden mehrere Schritte durchgefhrt (Setzen der Status-Variablen, ggf. Ausfhren der Entry- bzw. Exit-Aktion), weshalb diese in einer jeweiligen Methode gekapselt werden. In Abbildung 4.1 ist eine Implementie- rung des bisherigen Konzepts in Form eines Klassendiagramms dargestellt. Bis hierher hnelt der Aufbau dem von Bosch bis auf wenige Details. Allerdings sind einige fr Zustandsdiagramme spezische Elemente noch nicht bercksichtigt worden. 4.1.1 Zeitgesteuerte Transitionen Bei zeitgesteuerten Transitionen ist die Zeit relevant, die seit dem Betreten des aktuell aktiven Zustands vergangen ist. Als Besonderheit sei angemerkt, dass im Falle von Hierarchien der Oberzustand einen lngeren Zeitraum aktiv sein kann als seine Unter- zustnde. Daher muss jeder Zustand die Zeit kennen, die seit seiner letzten Aktivierung vergangen ist und die Klasse muss um diese Information erweitert werden. Um mglichst exibel zu sein, soll das Hochzhlen der Zeit von auen ber einen Zeitgeber gesteuert werden knnen. Hier gibt es prinzipiell zwei Lsungsanstze. Beim ersten Ansatz wird eine konkrete Ausprgung der Event-Schnittstelle implementiert, whrend der zweite Ansatz eine zustzliche Methode timeout(ms) vorsieht. Da das Ziel

33. 4.1. Konzeptioneller Aufbau23 Abbildung 4.2.: Erweiterung der Klassen State und Transition fr zeitgesteuerteTransitionen, sowie Einfhrung der Klasse PseudoState ist, die Anzahl der Klassen mglichst gering zu halten, wird der zweite Ansatz verfolgt. Hieraus resultiert, dass eine Transition die zu wartende Zeit nicht als Instanz der Event- Klasse speichert, sondern als reinen Integer-Wert. Beim Schalten der Transition wird zunchst geprft, ob die zu wartende Zeit abgelaufen ist. Neben der Verwaltung der Zeit ist es in beiden Fllen notwendig, beim Betreten des Zustands in der Methode activate() die Zeit zurckzusetzen. Abbildung 4.2 zeigt die nderungen an den Klassen.4.1.2 Segmentierte Transitionen Eine weitere Besonderheit in Zustandsdiagrammen ist die Verbindungsstelle als Pseu- dozustand fr segmentierte Transitionen. Pseudozustnde haben zwei Gemeinsamkei- ten, nmlich dass diesen keine Entry- bzw. Exit-Aktion zugewiesen und nicht in ihnen verweilt werden kann. Der erste Punkt trit ebenso auf den Endzustand zu, obwohl es sich hier streng genommen um keinen Pseudozustand handelt. Trotzdem wird nur eine neue Klasse PseudoState ergnzt, welche auch den Endzustand reprsentiert (siehe Abbildung 4.2).Die zur Verbindungsstelle hinfhrende Transition darf nur dann schalten, wenn es einen Weg zu einem normalen Zustand gibt. Diese Prmisse muss durch das erste Segment sichergestellt werden, sodass dieses vor der tatschlichen Ausfhrung solch einen Weg suchen muss. Hierzu bedient sich das Framework einer Tiefensuche. Eine auszufhrende Transition berprft grundstzlich mit ihrer Methode allowed() die ggf. vorhandene Bedingung und schlielich, ob es sich bei dem Zielzustand um einen echten Pseudozustand, also nicht dem Endzustand, handelt. Falls ja, wird die Tiefensuche gestartet, indem auf dem Pseudozustand die Methode lookup() aufgerufen wird, die ihrerseits fr alle ausgehenden Transitionen die Methode allowed() aufruft. Erst, wenn ein Weg zu einem normalen Zustand gefunden wurde, wird der Quellzustand de- und der Zielzustand aktiviert. Da es sich bei der Verbindungsstelle um einen Pseudozu-

34. 4. Das Statechart-Framework 24 x=0 Abbildung 4.3.: Verarbeitung segmentierter Transitionen fr den Fall x = 0

35. 4.1. Konzeptioneller Aufbau25 Abbildung 4.4.: Ereignisverarbeitung auf dem Oder-Zustand stand handelt, wird dieser automatisch bei Aktivierung sofort wieder verlassen, indem mittels dispatch(null) die Ereignisverarbeitung neu angestoen wird. In Abbildung 4.3 ist dieser Ablauf dargestellt.4.1.3 Hierarchie und Nebenlugkeit Im Gegensatz zu Bosch und van Gurp muss das zu entwickelnde Framework noch um die beiden essenziellen Elemente der Hierarchiebildung und der Verwendung von Nebenlugkeit erweitert werden.Hierarchische Zustnde Die von Oder-Verfeinerungen aufgebaute Struktur ist die eines Baums. Ziel ist es somit innerhalb des Frameworks solch eine Baumstruktur aufzubauen. Hier ist die oben vorgestellte Sichtweise des Kontexts als Spezialfall eines Zustands hilfreich. Bisher stellt der Kontext auf oberster Hierarchieebene das Zustandsdiagramm dar und kennt den aktuell aktiven Zustand auf der darunterliegenden Ebene. Dieses Kon- zept lsst sich auf die Oder-Verfeinerung anwenden: Diese ist ein Spezialfall eines Zustands, welcher jeweils genau einen aktiven Unterzustand hat. Also genau das, was der Kontext auf oberster Hierarchieebene abbildet. Da die Klasse Context eine Generalisierung der Klasse State ist, kann vom Kontext einfach eine neue Klasse abgeleitet werden, die das Spezialverhalten eines hierarchischen Zustands reprsentiert. Der Kontext wird zu einer abstrakten Basisklasse fr hierarchische Zustnde. Beim Aktivieren eines Zustands meldet er dies seinem Vater- knoten. Zur Abbildung der Baumstruktur muss die Zustandsklasse erweitert werden. Jedem Zustand muss sein Vaterknoten bekannt sein. Der einzige Zustand ohne Va- terknoten ist das Diagramm selbst, welches knftig durch die Klasse Statechart reprsentiert wird. Das Diagramm ist also ein zusammengesetzter Zustand und bildet immer den Wurzelknoten der Baumstruktur. Ereignisverarbeitung Im Gegensatz zu normalen Zustnden ist die Verarbeitung eines eingehenden Ereignisses komplexer, da die in Abschnitt 2.1.1 beschriebene Vor- rangsregel bercksichtigt werden muss. Hierzu muss die entsprechende Methode in der abgeleiteten Klasse berschrieben werden, um das Ereignis zunchst an den aktiven Unterzustand zu propagieren. Die Vererbung von Transitionen wird implizit durchgefhrt. D. h. beim Aufbau des Diagramms mssen vererbte Transitionen nicht explizit fr die Unterzustnde ange-

36. 4. Das Statechart-Framework26 =Abbildung 4.5.: Transitionsverhalten bei hierarchischen Zustnden legt werden. Falls der Unterzustand das Ereignis nicht verarbeiten kann, wird geprft, ob die Oder-Verfeinerung eine Transition besitzt, die auf das Ereignis reagieren kann. Jedoch muss eine Besonderheit bercksichtigt werden, um die Semantik korrekt abzubilden: Ist der Endzustand der Oder-Verfeinerung noch nicht erreicht worden, mssen alle Beendigungstransitionen von der Verarbeitung ausgeschlossen werden. Konnte hingegen der Unterzustand das Ereignis verarbeiten, ist dessen Behandlung auf dem Oder-Zustand abgeschlossen. Abbildung 4.4 zeigt den Ablauf solch einer Verarbeitung. Transitionen Wie bei Bosch kennen die bergnge bisher nur den Zielzustand, um diesen zu aktivieren. Bei der Verwendung von Hierarchien reicht diese einfache Sichtweise nicht mehr aus, da es jetzt mglich ist, dass beim Schalten einer Transition mehrere Zustnde (de-)aktiviert werden mssen. Im Beispiel aus Abbildung 4.5 werden beim Ausfhren der Transition zum Zustand r automatisch auch die Zustnde p und q aktiviert. Analoges gilt fr den bergang von r nach y. Hierbei werden q und p automatisch de- und x aktiviert. Eine Transition muss also den Pfad vom Quell- zum Zielzustand im durch die Hier- archie aufgespannten Baum bercksichtigen. Hierzu wird der kleinste gemeinsame Vor- fahre (LCA = Least common ancestor) berechnet (OMG, 2003). Alle Zustnde von der Quelle zum LCA werden deaktiviert, analog werden alle Zustnde auf dem Pfad vom LCA zum Ziel aktiviert. In obigem Beispiel ist der gemeinsame Vorfahre bei allen drei Transitionen das Zustandsdiagramm selbst, also der Wurzelknoten. Fr die Implementierung bedeutet dies, dass bei der Erzeugung einer Transition der Quell- und Zielzustand bergeben werden muss und anhand der Hierarchie zwei Zustandsmengen berechnet werden. History-Zustnde Die beiden History-Zustandsarten knnen sehr einfach implementiert werden. Hierzu wird eine Tiefensuche auf dem Oder-Zustand ausgefhrt, welche alle derzeit aktiven Knoten in einer Liste speichert. Die Suchtiefe beschrnkt sich bei einem normalen History-Zustand auf Eins. Diese Sicherung wird beim De- aktivieren der Oder-Verfeinerung durchgefhrt. Beim Betreten des History-Zustands werden entsprechend der gespeicherten Liste die Zustnde wieder aktiviert bzw. dieser beim erstmaligen Betreten automatisch ber seine ausgehende Transition verlassen. Die Implementierung beschrnkt sich daher auf die Erweiterung der Klasse fr Pseudo- zustnde um eine Tiefensuche und die Mglichkeit der Speicherung einer Zustandsliste. Abbildung 4.6 zeigt die entsprechenden Erweiterungen des Frameworks.

37. 4.1. Konzeptioneller Aufbau 27 Abbildung 4.6.: Erweiterung des Frameworks um Hierarchie Nebenluge Zustnde Nebenlugkeit als der zweite zentrale Aspekt von Zustandsdiagrammen wird durch das Hinzufgen einer neuen Klasse ConcurrentState erreicht. Diese ist wie die Oder- Verfeinerung ein Kontext. Der essenzielle Unterschied ist, dass nicht genau ein Unterzu- stand aktiv ist, sondern alle Unterzustnde gleichzeitig. Regionen wiederum sind Oder- Verfeinerungen, denen als Vaterknoten der nebenluge Zustand zugewiesen wird.Ereignisverarbeitung Die Verarbeitung eines eingehenden Ereignisses funktioniert im Wesentlichen genauso wie bei hierarchischen Zustnden (siehe Abbildung 4.4). Der Hauptunterschied ist der, dass das Ereignis nicht an einen Unterzustand, sondern an alle Regionen delegiert und kein Startzustand gesetzt wird.Hierbei muss beachtet werden, dass ein Oder-Unterzustand das Ereignis nur dann verarbeiten kann, wenn die Und-Verfeinerung aktiv ist: Wird beispielsweise der nebenluge Zustand aus einer Region heraus ber eine Transition verlassen, drfen die restlichen Bereiche das Signal nicht weiter verarbeiten. Sobald ein Unterzustand das Ereignis behandeln konnte, gelten dieselben Ablufe wie bei hierarchischen Zustnden.Das Framework selbst untersttzt in dieser Form keine echte Nebenlugkeit, sondern bearbeitet wie Ali und Tanaka die einzelnen Regionen sequenziell. Die Neben- lugkeit entsteht dadurch, dass alle Regionen im gleichen Schritt der Simulation auf das Ereignis reagieren knnen.Transitionen Diese haben bisher die Eigenschaft, dass ihnen eine Liste an Zustn- den bekannt ist, die beim Schalten aktiviert bzw. deaktiviert werden mssen. Bei der

38. 4. Das Statechart-Framework28 Abbildung 4.7.: Ablauf der execute-Methode einer Transition Und-Verfeinerung entsteht ein Problem: Wird direkt ein Unterzustand einer Region angesprungen, stehen in der Liste der zu aktivierenden Zustnde die Und-Verfeinerung an Position n, die Region an n + 1 und der Unterzustand an n + 2. Da beim Betreten des Und-Zustands automatisch alle Regionen aktiviert werden mssen, entsteht ein Konikt, denn die Aktivierung erfolgt immer an den Startzustnden der Bereiche. Es muss also eine Mglichkeit geschaen werden, die es erlaubt einzelne Regio- nen bei der Aktivierung des Und-Zustands zu ignorieren. Hierzu wird in der Klasse ConcurrentState eine Liste von Regionen gepegt, die nicht automatisch aktiviert werden sollen. Diese Liste wird dynamisch zur Laufzeit von der Transition gefllt, indem geprft wird, ob der Zielzustand des bergangs in einer Region liegt oder die Und- Verfeinerung selbst ist. Bei der Deaktivierung des Zustands wird diese Liste geleert. Abbildung 4.7 zeigt den Ablauf beim Schalten einer Transition. Gabelung einer Transition Die Implementierung des Fork-Zustands ist mit der Erweiterung der Und-Verfeinerung um eine Menge der nicht automatisch zu aktivierenden Regionen einfach zu erreichen. Es wird dasselbe Prinzip angewendet wie bei Transitionen: Zunchst wird ein Weg zu einem normalen Zustand gesucht. Ist dieser gefunden worden, wird bei Erreichen des Fork-Zustands die Liste der Transitionen durchlaufen und die jeweiligen Regionen ermittelt, die ignoriert werden mssen. Erst danach werden die ausgehenden Transitionen nacheinander ausgefhrt. Es reicht, dieses Vorgehen in der Klasse PseudoState in der Methode activate() zu programmieren. Vereinigung mehrerer Transitionen Das Gegenstck zur Gabelung ist die Syn- chronisation der einzelnen Regionen am Join-Zustand. Die Beendigungstransition wird automatisch ausgefhrt, wenn alle Regionen ihren jeweiligen Endzustand erreicht haben. Diese Prmisse ist beim Join-Zustand nicht erfllt. Stattdessen bilden all diejeni- gen Zustnde einen gltigen Endzustand der Und-Verfeinerung, die eine Transition zum Join-Zustand besitzen. Im Folgenden wird diese Zustandsmenge als Endkongu- ration bezeichnet. Es gibt prinzipiell zwei Stellen, an denen solch eine Endkonguration gespeichert

39. 4.2. Implementierung29Abbildung 4.8.: Erweiterung des Frameworks um Nebenlugkeitwerden kann. Entweder im Und- oder im Join-Zustand. Da diese Menge mit letzterem Typ assoziiert wird, soll diese dort gehalten werden. Die Klasse PseudoState bietet hierfr zudem schon die bentigte Infrastruktur an. Der Anwender des Frameworks ist dafr verantwortlich, dass dem Join-Zustand diese Endkonguration bekannt gemacht wird. Die Methode lookup() fhrt neben der obligatorischen Tiefensuche im Falle des Typs Join zustzlich die Prfung aus, ob die angegebenen Zustnde aktiv sind. Diese einfache Implementierung birgt jedoch den Nachteil, dass nicht alle Aktionen ausgefhrt bzw. Bedingungen geprft werden, die an den zum Join-Zustand hinfh- renden Transitionen stehen. Das Klassendiagramm aus Abbildung 4.8 zeigt die nderungen an dem Framework, die zur Realisierung der Nebenlugkeit notwendig sind. 4.2 Implementierung Im Folgenden wird die Implementierung des Frameworks beschrieben und auf Opti- mierungen aufmerksam gemacht, die durch die Beschrnkungen des RCX notwendig wurden. Die Programmquellen sind in dem Paket statechart.base untergebracht. In Abbildung 4.9 ist die Implementierung des Frameworks zu sehen. Diese unterscheidet sich vom prinzipiellen Aufbau her nicht von dem vorgestellten Konzept. Aufgrund der Anforderungen an das Framework wurden jedoch einige nderungen erforderlich.

40. 4. Das Statechart-Framework 30Abbildung 4.9.: Klassendiagramm der Implementierung des Frameworks

41. 4.2. Implementierung 31 4.2.1 Speicherplatzoptimierungen Insgesamt besteht das vorgestellte Framework aus einer mglichst minimalen Anzahl an Klassen. Allerdings ist dies nur der erste Schritt um Speicherplatz zu sparen. Die nchsten Abschnitte beschreiben die weiteren wesentlichen Optimierungen.Verwaltung von Listen Zunchst fllt auf, dass die zu verwaltenden Listen in einer Klasse ber den vom JDK zur Verfgung gestellten Vektor einen enormen Speicherplatzverbrauch verursachen. Selbiges gilt fr die Reimplementierung der Vektor-Klasse in LeJOS. Die Grnde hierfr liegen an zwei Stellen:1. Es werden sehr viele Komfortmethoden angeboten, die die Handhabung der Klas-se vereinfachen sollen. Hierzu zhlen z. B. unterschiedliche Parameterlisten.2. Die Methoden enthalten im Allgemeinen einen Programmcode, der prft, ob dieangegebenen Parameter im Denitionsbereich liegen. Da die Verwaltung der Listen ausschlielich im Framework stattndet und der An- wender keinen direkten Zugri auf diese erhlt, knnen die beiden aufgefhrten Punkte als Ansatz zur Platzersparnis verwendet werden. Hierzu werden unntige Methoden nicht implementiert und Sicherheitsberprfungen ausgeklammert. Dies fhrt dazu, dass eine eigene Klasse Vector verwendet wird, die minimale Funktionalitt besitzt und somit platzsparend ist. Zustzlich wird durch die ausschlieliche Sichtbarkeit der Klasse in dem Paket statechart.base sichergestellt, dass diese nur innerhalb des Pakets Verwendung ndet. Als Basis dient die gleichnamige Klasse aus dem LeJOS-Paket.Verwendung statischer Methoden An einigen Stellen werden Berechnungsmethoden verwendet, die in allen Instanzen einer Klasse verwendet werden und nicht auf Klassenvariablen zugreifen. Hier ist ein einfacher Trick die Verwendung von statischen Methoden.Zeitereignis Da wie in der Konzeption beschrieben kein Timeout-Ereignis als Klasse realisiert ist, die Verarbeitung der Ereignisse aber ber die dispatch-Methode stattndet, wird als bergabeparameter null als Zeitereignis vereinbart. Die timeout-Methoden erhhen bei Aufruf nur die aktuelle Zeit im Zustand. Anschlieend wird seitens der Klasse Statechart auf dem derzeitigen Zustand die Ereignisverarbeitung angestoen (siehe Listing 4.1).Objekterzeugung innerhalb des Frameworks Ein essenzieller Punkt ist das Vermeiden von Objekt-Instanziierungen mittels new innerhalb des Frameworks bei der Ereignisverarbeitung. Dies fhrt zu potenziell un- berschaubar vielen Objekten und somit im Rahmen des RCX schnell zu einem Spei- cherberlauf. Objekte werden im Framework daher nur whrend der Konstruktion des

42. 4. Das Statechart-Framework32Listing 4.1: Implementierung des Zeitereignis in den Klassen Statechart und State // S t a t e c h a r t K l a s s e public void t i m e o u t ( i n t time ) { c u r r e n t S t a t e . t i m e o u t ( time ) ; c u r r e n t S t a t e . d i s p a t c h ( null ) ; }// S t a t e K l a s s e protected void t i m e o u t ( i n t time ) { currentTime += time ; } Zustandsdiagramms instanziiert. Sobald alle Zustnde, Transitionen, Aktionen, Er- eignisse und Bedingungen angelegt wurden, ndet nur noch die Ereignisverarbeitung mittels der timeout- und dispatch-Methoden statt. Neue Objekte werden zu diesem Zeitpunkt seitens des Frameworks nicht mehr instanziiert.4.2.2 Berechnung des LCA Eines der bisher noch nicht bercksichtigten Elemente ist die Berechnung des kleins- ten gemeinsamen Vorfahrens zweier Knoten. Diese ndet in der statischen Methode calculateStateSet der Klasse Transition statt. Aullig ist der Rckgabewert. Hier- bei handelt es sich um ein zweidimensionales Feld, welches die zu (de-)aktivierenden Zustnde beinhaltet. Dieses Array wird fr jede Transition einmal in der bentigten Gre erzeugt, sodass hier eine optimale Speicherausnutzung stattndet. Die Berech- nung selbst folgt einem einfachen Algorithmus: 1. Speichere den Pfad vom Startzustand zum Wurzelknoten der Hierarchie. 2. Speichere den Pfad vom Endzustand zum Wurzelknoten der Hierarchie. 3. Whle die Lnge min des krzeren Pfads. 4. Setze i = 0. 5. Solange i < min ist, vergleiche von der Wurzel ausgehend die Elemente der beiden Pfade an Position i.a) Falls die Elemente gleich sind, setzte i = i + 1. b) Falls die Elemente ungleich sind, stoppe den Vergleich. i 1 ist der LCA.Fr die Umsetzung fllt auf, dass in den Schritten eins und zwei temporre Variablen bentigt werden, die den Pfad sichern. Da dieser beliebig lang werden kann, muss in

43. 4.2. Implementierung33 der Implementierung ein dynamisches Feld verwendet werden. Die Klasse Vector bietet sich hier an, bringt aber auch ein Problem mit sich: In jedem Aufruf des Algorithmus werden zwei Objekte mittels new angelegt. Insgesamt werden bei n Transitionen 2n temporre Vektoren angelegt und somit unntiger Speicherplatz verschwendet. Statt- dessen werden auerhalb der statischen Methode zwei ebenfalls statische Hilfsvektoren angelegt, sodass diese wiederverwendet werden knnen und 2n 2 Objekte wegfallen. Nach der Berechnung des LCA mssen die zu (de-)aktivierenden Zustnde nur noch in das hierzu angelegte Feld kopiert werden. Listing 4.2 zeigt den zugehrigen Quelltext.4.2.3 Verwendung des Frameworks Ein weiteres Ziel ist die einfache Verwendung des Frameworks. Aus diesem Grund werden entlich sichtbare Hilfsfunktionen in den Klassen zur Verfgung gestellt, die die Handhabung erleichtern und bei der Konstruktion syntaktisch korrekter Zustands- diagramme helfen sollen. Hierzu zhlen zum Beispiel die Methoden getStart() und respektive getEnd() auf dem Kontext. Hierdurch wird nicht nur sichergestellt, dass der Zugri auf diese beiden Zustnde einfach ist, sondern auch dass ein Kontext nur einen Start- bzw. Endzustand1 besitzen kann. hnliche Komfortmethoden bieten die hierarchischen Zustnde zur Ermittlung des History-Zustands und die Pseudozustn- de, um fr die Vereinigung von Transitionen die Endkonguration angeben zu knnen. Nebenluge Zustnde bieten die Mglichkeit, mittels addRegion() eine neue Region zu ergnzen. Fr die so ermittelten Zustnde wird der Kontext automatisch gesetzt, sodass der Anwender diesen nicht explizit setzen muss. Eine Besonderheit bieten Zustandsbergnge. Die Verknpfung von einem Zustand mit einer Transition ndet automatisch beim Anlegen selbiger statt. Das heit, es wird dem Startzustand automatisch mitgeteilt, dass dieser eine neue abgehende Transition erhlt. So knnen Zustandsbergnge mit nur einer Programmzeile angelegt werden. Insgesamt bietet das Framework aufgrund dieser wenigen Hilfsfunktionen und mit der Erweiterbarkeit durch die Interfaces Action, Guard und Event eine sehr einfache Programmier-Schnittstelle fr den Anwender. Die Verwendung funktioniert immer nach dem selben Muster: 1. Anlegen der Zustnde (einfache, hierarchische, nebenluge, Regionen und Pseu-dozustnde). 2. Aufbau der Hierarchie mittels der Methode setContext(). 3. Falls Join-Zustnde verwendet werden, die Endkongurationen angeben. 4. Erzeugen der Transitionen. Anschlieend ist das Zustandsdiagramm einsatzbereit und kann in der Hauptpro- grammschleife verwendet werden, welche Timeout-Signale und Ereignisse an das Dia- gramm sendet. Ein Beispiel einer mglichen Programmschleife ist in Kapitel 7.3 zu 1 DieModellierung lsst mehrere Endzustnde zu. Diese knnen jedoch immer zu einem zusammengefasst werden, sodass dies keine Einschrnkung darstellt.

44. 4. Das Statechart-Framework 34Listing 4.2: Quelltext aus der Klasse Transition zur Berechnung des LCA private s t a t i c V e c tor s t a = new Vector ( 2 0 ) ; private s t a t i c V e c tor s t d = new Vector ( 2 0 ) ;private s t a t i c S t a t e [ ] [ ] c a l c u l a t e S t a t e S e t ( S t a t e s t a r t , S t a t e end ) { // Pfad vom S t a r t zum Wurzelknoten e r m i t t e l n std . c l e a r ( ) ; State s = s t a r t ; while ( s != nu ll ) { s t d . add ( 0 , s ) ; i f ( s . c o n t e x t instanceof H i e r a r c h i c a l S t a t e | | s . c o n t e x t instanceof C o n c u r r e n t S t a t e ) { s = ( State ) s . context ; } e l s e s = nu ll ; } ... // Q u e l l t e x t f r s t a a n a l o g // b e r e c h n e n d e s LCAi n t min = s t a . s i z e ( ) < s t d . s i z e ( ) ? s t a . s i z e ( ) : s t d . s i z e ( ) ;i n t l c a = min 1 ; // G i l t f a l l s s t a r t=end . min i s t mind . 1i f ( s t a r t != end ){f o r ( l c a = 0 ; l c a < min ; l c a ++)i f ( s t a . g e t ( l c a ) != s t d . g e t ( l c a ) ) break ;} // a n l e g e n d e s A u s g a b e a r r a y sS t a t e [ ] [ ] s t a t e s = new S t a t e [ 2 ] [ ] ;s t a t e s [ 0 ] = new S t a t e [ s t d . s i z e ( ) l c a ] ;s t a t e s [ 1 ] = new S t a t e [ s t a . s i z e ( ) l c a ] ; // k o p i e r e n d e r zu ( de ) a k t i v i e r e n d e n Zustndef o r ( i n t i = s t a t e s [ 0 ] . l e n g t h 1 , j = l c a ; i >= 0 ; i , j ++)s t a t e s [ 0 ] [ i ] = ( State ) std . get ( j ) ; f o r ( i n t i = 0 , j = l c a ; i < s t a t e s [ 1 ] . l e n g t h ; i ++, j ++)s t a t e s [ 1 ] [ i ] = ( State ) sta . get ( j ) ; return s t a t e s ; }

45. 4.3. Unittests 35Abbildung 4.10.: Beispieldiagramm fr die Umsetzung in den Quelltext nden. Das Beispiel aus Listing 4.3 soll den Aufbau des Quelltextes verdeutlichen. Hierzu wird das in Abbildung 4.10 dargestellte Zustandsdiagramm mit dem Frame- work umgesetzt2 . Durch diesen einfachen und vor allem strukturell immer gleich aufgebauten Quell- text, ist eine weitere Anforderung erfllt: Die Vereinfachung der Codegenerierung da- hingehend, dass nur eine Klasse generiert werden muss, in der das Framework verwendet wird. Eine genaue Beschreibung ndet sich in Kapitel 7. 4.3 Unittests Im Rahmen der Entwicklung ist das Testen der Software ein stetiger Begleiter. Da- her soll dieser Schritt vollkommen automatisiert durchgefhrt werden. Hierzu bietet sich die Verwendung von JUnit (Clark u. a., 2006) als Testumgebung an. Allerdings soll an dieser Stelle nur ein Verfahren erlutert werden, mit dem sich die Seman- tik von Zustandsdiagrammen testen lsst und wie dieser Testaufbau mittels JUnit umgesetzt werden kann. Die eigentlichen Testflle sind im Anhang A zu nden. Da der RCX-Baustein keine Mglichkeit zum automatisierten Testen anbietet, werden die Prfungen auf die Laufzeitumgebung fr Zustandsdiagramme beschrnkt.Das Testen von Zustandsdiagrammen basiert in diesem Ansatz auf einer einfachen Erkenntnis: Der Durchlauf durch das Diagramm lsst sich komplett als eindeutiger Pfad beschreiben. Hierbei wird jeweils registriert und aufgezeichnet, wann ein Zustand aktiviert, deaktiviert oder eine Aktion ausgefhrt wird. Das Testen besteht letztlich darin, den durchlaufenen Pfad mit dem Soll-Pfad zu vergleichen. In letzterem wird vorgegeben, in welcher Reihenfolge die Zustnde (de-)aktiviert und Aktionen ausgefhrt werden mssen.Hierbei scheinen die nebenlugen Zustnde Probleme zu bereiten, denn theoretisch kann die Reihenfolge, in der die Regionen ein eingehendes Ereignis verarbeiten, immer unterschiedlich sein, je nachdem welcher Prozess als nchstes die CPU-Zeit zugewiesen bekommt. Dies wrde ein wesentlich komplexeres Vorgehen erfordern, um die beiden Pfade zu vergleichen, da fr jede nebenluge Region der Pfad aufgeteilt werden mss- te. Um dies zu vermeiden, wird im Folgenden ohne Beschrnkung der Allgemeinheit 2 Die verwendeten Aktionen und Signale sind mit Pseudocode angegeben.

Mocek Thesis

Technology

Transcript of Mocek Thesis