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
2. II
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 ih- re 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
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, unter-
sttzt 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 mehr- heitlich
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 zwi- schen 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 wich- tigen 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 ein- gebettetes 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 eben- falls
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 kom-
piliert 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 wer- den, 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 wer- den 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, wel- che 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 techni- schen 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 be-
schreiben 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 wer- den 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 rele-
vanten 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 ver- weilt 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 mit-
tels 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
er- reicht werden.Prinzipiell ist es bei Zustandsbergngen
allerdings mglich, ein nichtdeterminis- tisches Zustandsdiagramm zu
modellieren, in welchem mehrere Transitionen gleichzei- tig
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
mo- dellieren. 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 fh- ren bei nherer Betrachtung zu zwei Fragen, fr die
ei- ne Semantik bestimmt werden muss. Zunchst muss ge- klrt werden,
was fr ereignismarkierte Transitionen gilt, die vom Oberzustand
wegfhren. Denn laut Semantik be- ndet sich das Objekt zu jedem
Zeitpunkt, whrend der Oder-Zustand aktiv ist, in genau einem der
Unterzustn- de. Damit diese top-level-Ereignisse trotzdem verarbei-
tet 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 dersel- ben 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 zu- letzt 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
gleich- zeitig aktive Subzustnde besitzt. Diese bilden die
einzelnen Regionen des Zustands. Daher wird dieser Typ auch als
Und-Zustand bezeichnet. Die Regionen werden ber ei- ne 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 hierar- chische 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 be-
handelt, wie Regionen aktiviert werden knnen. Zum einen explizit
und zum anderen implizit. Im ersten Fall beginnen alle Bereiche an
ihren Startzustnden, im letzte- ren 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
ankommen- den 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 kom- plexe 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 end- liche
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 wer- den. 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 vorge- stellt 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 sei-
nem 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 dar- stellt und die Programmierung ermglicht. Die
32KB Arbeitsspeicher stehen nicht aus- schlielich 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 kom- plexe 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) imple- mentiert 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 bekanntes- ten 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 ba- siert auf mehreren
Voraussetzungen und Anforderungen. Zunchst soll die Frage disku-
tiert 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
objektori- entierte 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 ent- stehen, sodass der
verfgbare Speicher ezient ausgenutzt werden kann. Allerdings
bedingt C++ durch seine Konzepte und dem freien Speicherzugri
potenziell eine re- lativ 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 we- sentliche 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 existie-
renden 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 spezi-
sche 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 hin- gegen 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 reprsen- tiert 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 errei- chen, 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 de- ren 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 berge- ben, 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 be- inhalten, 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, son- dern
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 ech- ten
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 hierarchi- schen 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
re- prsentiert 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 ab- zubilden: Ist der
Endzustand der Oder-Verfeinerung noch nicht erreicht worden, ms-
sen 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 imple- mentiert 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. die- ser 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 ne- benluge
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, son-
dern 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 wer- den
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 aktivie- renden 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, die- ses 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 ha- ben.
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 nde- rungen 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 hier- fr
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 einfa- che
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 zusammen- gefasst 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 verwen-
det 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 vor- gegeben, 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.