.
Softwaretechnik WS2011 - Zustandsdiagramm
Zustandsdiagramm Aufgabe B13
Umsetzungsvorschlag
ArgoUML-Projektdatei: B13.zargo
Zusätzliche Annahmen:
Ich bin, um einen sinnvollen Endzustand zu erhalten, davon ausgegangen, dass der CD-Spieler sich nur ausschalten läßt, wenn keine CD eingelegt ist. Wenn man ihn
auch mit eingelegter CD ausschalten kann, gibt es mehr Zustandsübergänge zum Endzustand und damit auch zum Startzustand.
Das Öffnen der Lade ist nur möglich, wenn man die Wiedergabe gestoppt hat. Eine gerade laufende CD kann also nicht direkt ausgeworfen werden.
Auch das dient der Reduktion der Menge der Übergänge.
Anmerkung 1 von Hr. Igler zu diesem Diagramm:
Eine andere Möglichkeit, den Anfangs- und Endzustand interpretieren wäre: Endzustand = CD-Player wurde vernichtet. Bei dieser Interpretation
würde man den Endzustand im Diagramm vermutlich weglassen, da dieser, z.B. in der Entwicklungsabteilung eines CD-Player-Herstellers, zunächst
einmal nicht interessant sein wird.
Anmerkung 2 von Hr. Igler zu diesem Diagramm:
Im Diagramm zu Aufgabenblatt C, Teil 3 findet sich ebenfalls ein Sequenzdiagramm zu diesem Beispiel. Hier ist der Akt des CD-Einlegens/Entfernens durch eigene Zustände modelliert:
die Lade ist offen, und jetzt kann der "Benutzer" bei "gefüllter" Lade die CD entnehmen oder bei leerer Laed eine neue CD einlegen". Die Begründung des Unterschieds
zu meinem Diagramm liegt in unterschiedlicher Sichtweise: ich habe nur den CD-Player modelliert, ohne Berücksichtung des Benutzers. In diesem Fall
weiß der CD-Player überhaupt nicht, woher die CD kommt. Erst nach dem Lade-Schließen (Benutzeraktion) wird geprüft, ob etwas eingelegt ist. Diese Prüfung habe ich
in Umgangssprache an den Zustandsübergang geschrieben.
In Hr. Iglers Variante ist auch das Einlegen der CD relevant für den Blick auf das Gesamtsystem, auch wenn dieser Akt bei einem Stück Hardware nichts mit
der Hardware an sich zu tun hat - wohl aber für die Modellierung des gesamten CD-Player-Ablaufprozesses relevant ist. In der Geschäftswelt könnte dies z.B.
der Fluß von Daten aus der Außenwelt in die Software sein. Dies ist für die eigentliche Software nicht wichtig, wohl aber für das Verständnis des Gesamtprozesses.
Notationselemente:
- Ein Zustandsübergang ("transition") besteht aus folgenden Teilen (alle drei optional):
Signal [Guard] / Verhalten
"Signal" kann z.B. ein Methodenname sein, oder auch eine Useraktion in Pseudocode.
"Guard" ist eine Bedingung, die erfüllt sein muss, damit dieser Zustandsübergang erfolgt. Ist zwingend benötigt, wenn mehr als ein Zustandsübergang mit dem
gleichem Signal einen Zustand x verläßt. Man kann den Guard allerdings auch bei eindeutigen Übergängen eintragen, wenn man die Bedingung hervorheben will
oder wenn dieser Übergang nicht jedesmal möglich ist (so könnte "next_track" verboten sein, wenn man die CD bis zum Ende gespult hat)
"Verhalten": beschreibt eine Änderung des Systems durch den Zustandsübergang. Es empfiehlt sich, das "Verhalten" nur zu modellieren, wenn z.B. ein
besonderes Augenmerk auf dem Zustand von bestimmten Variablen während des Ablaufs des Zustandsdiagramms liegt.
Im Beispiel wird nach dem Einlegen einer CD oder beim "next_track"-Zustandsübergang (also durch mehrere unterschiedliche Übergänge)
eine Variable "Aktueller Track" gesetzt.
- Ein Zustand kann außer seinem Namen außerdem unterschiedliche Verhalten haben:
entry / Verhalten
: beim Betreten des Zustands erfolgt eine bestimmte Aktion. Im Beispiel wird beim Einlegen einer CD die Anzahl an Tracks
eingelesen. Meine Modellierung ist hier vermutlich nicht perfekt, eventuell wäre es geschickter gewesen, zwei Zustände für "CD frisch eingelegt"
(nur hier erfolgt das Einlesen der CD) und "CD liegt schon im Player"
zu definieren. Aber zumindest zeigt es ein Beispiel für ein "entry"-Verhalten.
do / Verhalten
: diese Aktion erfolgt während das System sich in diesem Zustand befindet. Ein Beispiel ist das Spielen der CD.
exit / Verhalten
: Verhalten vor dem Verlassen des Zustands - hier kein sinnvolles Beispiel gefunden ;-).
- Entscheidung:
Eine Entscheidung kann verwendet werden, wenn ein Signal aufgrund unterschiedlicher Bedingungen zu unterschiedlichen Ergebnis-Zuständen führt.
Die Entscheidung selbst wird durch eine Raute dargestellt. Am Pfeil zur Raute steht der Name des Signals und ein eventuelles Verhalten. An den Pfeilen, die die Raute verlassen,
folgen die Guards, die zur Auswahl des Zielzustands führen. Anmerkung: die Variable, die für die Entscheidung geprüft wird, kann auch in die Entscheidungs-Raute
geschrieben werden (in der Raute steht z.B. "x", die Guards enthalten nur die Prüfbedingung ohne Variable, also z.B. "[ > 0]"). ArgoUML lässt dies aber leider nicht zu.
Gemäß meinem UML-Buch wird bei einer Entscheidung zuerst die Transition ausgeführt, die zur Raute führt (d.h. das Verhalten der Transition wird ausgeführt).
Erst danach werden die Bedingungen geprüft, die zur Auswahl der Transition führen.
Um das also auf das Beispiel anzuwenden: das Verhalten könnte sein "Schublade einfahren", die Entscheidung, die darauf folgt ist "liegt eine CD in der Schublade oder nicht?".
- Kreuzung:
Hier ist der feine Unterschied zur Entscheidung: an den Pfeilen zum "Kreuzung"-Symbol steht nur das "Signal". "Guard" und "Verhalten" folgen erst
zwischen Kreuzung und Zielzustand. Bei einer Kreuzung steht also die Entscheidung bereits aufgrund des Systemzustands beim Verlassen des Ausgangszustands fest,
sie erfolgt nicht erst durch Aktionen während der Transition.
Im Beispiel wird die Transition "Benutzer drückt den Close-Knopf" ausgeführt, und bevor der CD-Player die Lade schließt, werden die Bedingungen ausgewertet
und danach das Verhalten ("Lade schließen"), durchgeführt.
Es muss dem CD-Player also schon vor dem Schließen der Lade bekannt sein, ob eine CD einliegt oder nicht - aber sofern der CD-Player keinen Außensensor hat,
ist hier eine "Entscheidung" vermutlich angebrachter.
Eine "Kreuzung" ist im Prinzip nur eine optische Vereinfachung des Diagramms, man könnte auch Einzel-Transitions ziehen.
Es ist möglich, bei einer Kreuzung mehrere Eingangs- und mehrere Ausgangs-Pfeile/Transitions zu haben. Die Eingangspfeile können auch mit unterschiedlichen Signalen
versehen sein.
Anmerkung: ArgoUML hat für "Entscheidung" und "Kreuzung" andere Symbole verwendet als mein UML-Buch. Ich habe mich in den beiden obigen Bildern an mein Buch
gehalten und das ArgoUML-Bild für die "Kreuzung" nachgetrickst: für den nicht ausgefüllten Kreis kann man in den Eigenschaften als "Füllfarbe"
schwarz verwenden.
Stand 20.02.2013
Historie:
18.11.2011: Erstellt
21.11.2011: im vollen Zustandsdiagramm ein paar Übergänge korrekt mit Verben benannt. "Entscheidung": Verhalten zugefügt, Anmerkung zur Positionierung der
zu prüfenden Variablen. Anmerkung zu alternativer Modellierung der Start-/Endzustände.
22.11.2011: Seite offiziell online gestellt. ArgoUML-Projektdatei
30.11.2011: Anmerkung 2 by Hr. Igler und aktualisiertes Diagramm
12.12.2012: Hinweis zur Füllfarbe der Kreuzung
20.02.2013: Korrektur des Zustandsdiagramms: von "stopped" kann man die Lade öffnen, Pfeil "stop" von "playing" zu "new CD inserted" entfernt.