Action disabled: recent

Zustandsdiagramme

Die UML-Zustandsdiagramme gehen auf die von David Harel in den 1980er Jahren entwickelten Zustandsautomaten zurück.

Bei den Basiskonzepten haben Sie gelernt, dass Objekte Zustände besitzen. Das UML-Zustandsdiagramm ist ein Ausdrucksmittel, welches immer dann angewendet werden sollte, wenn im Mittelpunkt der Betrachtung ein komplexes zustandsorientiertes Problem steht. Des Weiteren ist die softwareseitige Implementation einer Zustandsmaschine nicht trivial. SiSy ist in der Lage, aus dem UML-Zustandsdiagramm den entsprechenden Quellcode zu generieren. Die automatisch generierte Zustandsmaschine verringert den Aufwand und reduziert die Fehleranfälligkeit gegenüber einer manuellen Implementation enorm. Zustandsmaschinen sind oft zyklisch und laufen, solange ein Objekt existiert. Die Zustandsänderungen sind in der Regel an Ereignisse und Bedingungen geknüpft. Das Zustandsdiagramm zeigt nur Zustände und Zustandswechsel eines Objektes, jedoch keine objektübergreifenden Sachverhalte. Ein Objekt kann aber durchaus mehrere Zustandsmaschinen gleichzeitig, also parallel, besitzen.

Zustandsdiagramme zeigen mögliche Zustände und Zustandswechsel eines Objektes.

Das folgende Zustandsdiagramm zeigt welchen Zustand uind welche Zustandswechsel ein Objekt mindestens hat auch ohne eine explizit realisierte Zustandsmaschine.

Die wichtigsten Modellierungselemente des Zustandsdiagramms sind:

  • Zustände
  • Zustandsübergänge
  • Pseudozustände: Startknoten, Endknoten
  • Zustandsaktionen: entry, do, exit

Zustände

Ein Objektzustand repräsentiert zu einem oder mehreren determinierten, konkreten Eigenschaftswerten (Zustandsattribute) zuordenbares Verhalten (Aktivitäten). Die dem Zustand zuordenbaren Aktivitätstypen sind zum Beispiel:

  • entry, einmaliges Verhalten beim Einnehmen des Zustandes
  • do, wiederholtes Verhalten während des Zustandes
  • exit, einmaliges Verhalten beim Verlassen des Zustandes

Die Notation von Zuständen erfolgt wie bei der Aktion und Aktivität als Rechteck mit abgerundeten Ecken. Zusätzlich ist es üblich, den Zustand detailliert darzustellen. Ähnlich wie bei der Klasse wird das Zustandssymbol unterteilt und es können zustandsbestimmende Attribute und Aktionen angegeben werden. Wichtig ist, dass ein Zustand nicht als etwas statisches angesehen wird. Ein Objekt führt während es sich in einem Zustand befindet auch immer das dem zustand zugeordnete Verhalten aus. Deshalb ist es üblich die Zustandsaktivitäten auch mit zu modellieren.

Pseudozustände

inital node, Startknoten

Der Startknoten repräsentiert in nicht hierarchisierten Zustandsdiagrammen im einfachsten Fall den Zustand bevor das Objekt existiert. Zweckmäßigerweise sollte immer nur eine ausgehende Kante modelliert werden. Die Notation des Startknotens ist ein kleiner, ausgefüllter Kreis.

final node, Endknoten

Ein Endknoten repräsentiert in einer einfachen Zustandsmaschine den Zustand nach dem das Objekt zerstört wurde. Es ist möglich und auch üblich Zustandsmaschinen als endlose zyklische Automaten zu modellieren. In dem Falle wird das zerstören des Objektes nicht modelliert und der Endknoten fehlt in der Darstellung. Die Notation des Endknotens ist ein kleiner ausgefüllter Kreis im Kreis.

Zustandsübergänge

transition, Zustandsübergang

Der Übergang von einem Zustand in den anderen bedeutet in jedem Fall Verhalten. Es passiert also etwas und der Übergang verbraucht auch Zeit. Es wird konkretes Verhalten ausgeführt und damit finden wir die Zustandsübergänge im Programmcode als eine entsprechende Codesequenz. Die Zustandsübergänge können durch Ereignisse und Bedingungen ausgelöst werden. Das Ereignis spezifiziert wann der Übergang stattfindet. Letztlich ist ein Ereignis im Quellcode eine Operation der Klasse des Objektes. In eingebetteten Systemen kann das auch eine dem Objekt zugeordnete Interrupserviceroutine (ISR) sein. Bedingungen (Guards) drücken aus unter welchen Konditionen ein Übergang zulässig ist. Die Notation von Zustandsübergängen erfolgt durch eine gerichtet Linie (Pfeil) mit Beschriftung (Ereignis [Bedingung] / Aktion).

Mit dem Zustandsdiagramm in SiSy programmieren

Eine kleine Erweiterung sollte unser Projekt noch erfahren. Ein ButtonClickAndHold verfügt für die Nutzerinteraktion nicht nur über das Click-Ereignis, sondern auch über Ereignisse, die ein langes Halten des Tasters durch den Nutzer signalisieren. Wir wollen das lange Halten des Tasters nutzen, um die LED wieder auszuschalten. Ziehen Sie dazu eine Operation auf die Klasse Taster und überschreiben Sie die Operation onHoldStart. Ergänzen Sie den Quellcode dieser Operation mit dem Befehl app.led.off(); . Unsere kleine Anwendung erfüllt jetzt folgende Anforderungen:

  • nach dem Einschalten zeigt die LED den Blinkcode 1 an
  • bei jedem Click auf den Taster wird der Blinkcode um eins erhöht
  • durch langes Halten des Tasters wird die LED ausgeschaltet

Bei dieser Gelegenheit schauen wir uns an, wie die Entwickler dieses schon nicht mehr ganz triviale Verhalten des Tasters konstruiert haben. Selektieren Sie den Baustein ButtonClickAndHold. Wählen Sie im Kontextmenü (rechte Maustaste) Quelldiagramm öffnen.

BILD

Dort finden Sie das Attribut state. Aus diesem können Sie im Kontextmenü nach unten wählen und gelangen zum Zustandsdiagramm für Button.

BILD

Die Modellierung von Zustandsdiagrammen wird im myAVR Lehrbuch Software Engineering für Embedded Systems näher beschrieben. SiSy ist in der Lage, aus solchen Zustandsdiagrammen den kompletten Quellcode, der die Zustandsmaschine realisiert, zu generieren und in die zugehörige Klasse einzubetten. Das Ergebnis ist in diesem Fall ein Taster, der zuverlässig entprellt ist und die Fähigkeit hat, auf Click und Halten unterschiedlich zu reagieren.

Videozusammenfassung

<flashplayer width=„640“ height=„500“ position=„0“>file=http://youtu.be/???</flashplayer>

Weiterführendes