Zustandsdiagramm
Zustandsdiagramme sind keine Erfindung der UML, sie gehen auf David Harels Zustandsautomaten, entwickelt in den 80er Jahren, zurück. Diese Darstellungsform wurde in die UML aufgenommen.
Ein Zustandsdiagramm zeigt eine Folge von Zuständen, die ein Objekt im Laufe seines Lebens einnehmen kann, und die Ursachen der Zustandsänderungen. Man kann für ein Objekt den Zustand und die Änderung des Zustandes in Abhängigkeit von ausgeführten Operationen modellieren. Dabei wird besonderer Wert auf die Übergänge von einem Zustand in den nächsten gelegt. Man kann so ein Objekt von der Initialisierung bis zur Freigabe modellieren. Das Zustandsdiagramm beschreibt, durch welche Operationen oder Ereignisse die Zustände des Objekts geändert werden. Weiters ist aus ihnen ersichtlich, welche Belegung die Attribute des Objekts vor dem Übergang besitzen oder besitzen müssen.
Ein Objekt kann als Zustandsdiagramm/-„System“ modelliert werden unter der Voraussetzung, dass Sie eine Liste von Zuständen angeben können, für die gilt:
- Das Objekt befindet sich immer (zu jedem beliebigen Zeitpunkt seiner Existenz) in einem Zustand dieser Liste, anders ausgedrückt:
- Das Objekt befindet sich nie in keinem der genannten Zustände (wenn doch, dann fehlt Ihnen zumindest ein Zustand in der Liste).
- Nie in mehreren Zuständen Ihrer Liste zugleich (wenn doch, dann haben Sie die Untergliederung in Zustände falsch gewählt).
Abb. 28: Beispiel State-Machine-Diagram
Ein Objekt in einem Zustand kann dort ruhen, es ist aber auch möglich, in Zuständen „Aktivität“ vorzusehen.
Befindet sich ein Objekt in einem Zustand, dann können durchaus auch Subzustände für diesen Zustand modelliert werden, z. B. in einem untergeordneten Diagramm (Composite Element/Child Diagramm). Ist das Verhalten in einem Zustand prozeduraler Natur, dann kann das Subdiagramm natürlich auch ein Verhaltensdiagramm anderer Art sein.
Zustandsdiagramme müssen einen Anfangszustand und können einen Endzustand haben. Zustandsübergänge, sogenannte Transitionen, werden stets durch ein Ereignis ausgelöst (z. B. Bedingung, Time-out, …).
Zustände (States)
Zustände werden durch abgerundete Rechtecke modelliert. Sie können einen Namen beinhalten und optional durch horizontale Linien in bis zu drei Bereiche eingeteilt werden. Im obersten Bereich steht der Name des Zustandes. Wenn der Name nicht angegeben wird, handelt es sich um einen anonymen Zustand. In einem weiteren Bereich können existierende Zustandsvariablen mit der für diesen Zustand typischen Wertebelegung angeführt werden. Der dritte Bereich innerhalb des Zustandssymbols kann eine Liste von internen Ereignissen, Bedingungen und aus ihnen resultierende Operationen enthalten.
Ereignis steht dabei für drei mögliche Verhaltensweisen:
- entry – löst automatisch die angegebene Aktivität beim Eintritt in einen Zustand aus, also bei allen hereinkommenden Übergängen.
- exit – löst automatisch beim Verlassen eines Zustandes aus, also bei allen abgehenden Übergängen.
- do – wird immer wieder ausgelöst, solange der Zustand nicht gewechselt
Zustandsübergänge (Transitions)
Übergänge von einem Zustand zum nächsten werden durch Ereignisse ausgelöst. Ein Ereignis besteht aus einem Namen und einer Liste möglicher Argumente. Ein Zustand kann Bedingungen an dieses Ereignis knüpfen, die erfüllt sein müssen, damit dieser Zustand durch dieses Ereignis eingenommen wird. Diese Bedingungen können unabhängig von einem speziellen Ereignis sein.
Gleichzeitig mit einem Zustandsübergang kann eine Aktion durchgeführt werden. Die Notation einer Transition sieht folgendermaßen aus:
Ereignis [Bedingung] / Action
„Ereignis“, „[Bedingung]“ und „/Action“ sind allesamt optionale Bestandteile. Der Ereigniseintrag am Übergang vom Startpunkt zum ersten State darf fehlen. Auch an anderen Übergängen kann das Ereignis weggelassen werden. Ist dies der Fall, wird der Zustand automatisch gewechselt, wenn alle Aktivitäten des vorhergehenden Zustandes abgearbeitet wurden (entry..). Das KEIN-Ereignis (Trigger) wird auch als ANY-Trigger bezeichnet, dieses Ereignis ist IMMER vorhanden.
Symbole
Die folgende Tabelle enthält die Symbole der Zustandsdiagramme.
| Name/Symbol | Verwendung |
|---|---|
 | Der Zustand eines Objekts wird durch ein Rechteck mit abgerundeten Ecken symbolisiert. Innerhalb dieses Symbols wird der Zustand benannt. |
 | Der Startpunkt des Zustandsdiagramms wird mit einem gefüllten Kreis dargestellt. Er ist identisch mit der Objekterzeugung. Nur ein Startpunkt pro State-Diagram ist zulässig und muss vorhanden sein. Die Anordnung des Startpunkts ist freigestellt. |
 | Die Kette der Zustandsübergänge endet mit der Objektzerstörung. Der Endpunkt wird mit einem gefüllten Kreis dargestellt, den ein konzentrischer Kreis umgibt. Bei endlos laufenden Prozessen kann dieses Symbol in der Zeichnung fehlen, es darf aber auch mehrfach eingetragen werden. Das Token kehrt ggf. an das Ende der Activity im übergeordneten Diagramm, die das Unterdiagramm aufgerufen hat, zurück. |
 | Über einen Pfeil wird der Übergang (Transition) eingezeichnet. Der Pfeil wird mit dem Namen Auslösers (Trigger) beschriftet, die den Objektzustand ändert. Sie können in eckigen Klammern eine Restriktion [Guard] angeben, die bewirkt, dass nur bei deren Erfüllung der Objektzustand geändert wird. Zusätzlich kann hinter „/“ eine Aktivitätenliste, die beim Übergang auszuführen ist, angegeben werden. Guard und Aktivitätenliste sind optional, auch der Trigger (Auslöser) kann fehlen – am Übergang von Initial und wenn ein ANY-Trigger modelliert wird. |
Beispiel
Hochlauf eines Bankomaten und Hauptzustände. Beim Einschalten durchläuft der Bankomat einen Selbsttest. Abhängig davon, wie dieser ausgeht, wird die Grundstellung erreicht oder der Störungszustand. Zusätzlich wurde vorgesehen, dass bei überlanger Dauer des Selbsttests auch der Störungszustand eingenommen wird. Wird die Karte eingeschoben, erfolgt die Kartenprüfung. Abhängig von ihrem Ergebnis gelangt das Gerät in die Pin-Abfrage oder in den Abbruchzustand. Die weitern States wie Betragsabfrage, Verfügbarkeitsprüfung, usw. sind nicht mehr dargestellt.
Die Kettensymbole zeigen an, dass Subdiagramme vorhanden sind, die das Verhalten in den Zuständen näher beschreiben. Es besteht die Freiheit als Subdiagramme beliebige Verhaltensdiagramme zu verwenden, es muss sich nicht unbedingt um weitere Zustandsdiagramme handeln.
Abb. 29: Beispiel Zustandsdiagramm „Bankomathochlauf“
