Zustandsdiagramm (UML)

Grundidee und theoretische Grundlage

Ein Zustandsdiagramm (englisch state diagram) ist eine der 14 Diagrammarten der UML für Software und andere Systeme. Es stellt einen endlichen Automaten grafisch in einer UML-Sonderform dar. Damit kann entweder das Verhalten eines Systems oder die zulässige Nutzung seiner Schnittstelle spezifiziert werden.

Das Diagramm zeigt, welche Zustände ein Zustandsautomat zur Laufzeit annehmen darf und welche Ereignisse Übergänge zwischen ihnen auslösen. Die dargestellte hypothetische Maschine befindet sich zu jedem Zeitpunkt in genau einem Zustand einer endlichen Menge von Zuständen.

UML-Zustandsautomaten sind eine objektbasierte, von UML übernommene und erweiterte Variante von Harel-Zustandsdiagrammen. Wichtige Erweiterungen gegenüber traditionellen endlichen Automaten sind hierarchisch verschachtelte Zustände und orthogonale Bereiche. Sie verbinden Eigenschaften von Mealy-Automaten, bei denen Aktionen von Zustand und auslösendem Ereignis abhängen, mit Eigenschaften von Moore-Automaten, bei denen Eintritts- und Austritts-Aktionen stärker zustandsorientiert sind.

Aufbau des Diagramms und Zustände

Ein Zustandsautomat besteht aus Knoten (englisch vertices) und Zustandsübergängen (englisch transitions). Knoten sind entweder Zustände oder Pseudo-Zustände. Ein Zustandsdiagramm ist somit ein Graph: Zustände sind die Knoten, Zustandsübergänge die Kanten.

Ein Zustand wird normalerweise als Rechteck mit abgerundeten Ecken und einem Namen dargestellt. Pfeile zwischen den Zuständen stehen für mögliche Übergänge und tragen die Ereignisse als Beschriftung, die sie auslösen. Andere Diagrammformen außerhalb der UML verwenden teilweise Kreise, Ellipsen oder einfache Rechtecke.

Ein Zustand modelliert eine Situation, in der eine bestimmte, unveränderliche Bedingung gilt. Diese Invariante ist meist nur implizit; sie kann auch ausdrücklich als Einschränkung am Zustand angegeben werden. Befindet sich ein Objekt in einem Zustand, können die dort spezifizierten inneren Aktivitäten ausgeführt werden. Bei einer zweigeteilten Darstellung steht der Zustandsname oben; unten können innere Aktivitäten stehen, wobei eine Aktivität mehrere Aktionen enthalten kann.

Einem Zustand können vier Verhaltensspezifikationen zugeordnet werden: entry behaviour beim Eintritt, exit behaviour beim Verlassen, doActivity während des Aufenthalts sowie event behaviour beim Eintritt eines bestimmten Events. Beim Event-Verhalten wird ein tatsächliches Event angegeben, etwa „mouseOver / peep“.

Transitionen und ihre Arten

Eine Transition verbindet einen Quell- mit einem Zielknoten. Ihr kann ein Effekt (englisch effect) zugeordnet werden, also ein Verhalten, das beim Durchlaufen ausgeführt wird. Ein Wächterausdruck (englisch guard) schützt eine Transition: Sie darf nur durchlaufen werden, wenn dieser Ausdruck wahr ist.

Die Syntax lautet: „Ereignis (Argumente) [Bedingung] / Aktivität“.

Innere Transitionen reagieren auf ein Ereignis durch eine Aktivität, ohne einen Zustandsübergang auszulösen. Da der Zustand gleich bleibt, werden keine entry- oder exit-Aktivitäten ausgeführt. Sie werden innerhalb eines Zustands modelliert. Entry- und exit-Aktivitäten nutzen dieselbe Notation, aber mit den Schlüsselwörtern entry beziehungsweise exit statt eines auslösenden Ereignisses.

Bei einer äußeren Transition wird ein Zustand verlassen und ein anderer betreten. Dabei werden vorhandene exit-Aktivitäten des Quellzustands sowie entry-Aktivitäten des Zielzustands ausgeführt. Eine Selbsttransition ist eine besondere äußere Transition, bei der Quell- und Zielzustand identisch sind.

Pseudo- und History-Zustände

Ein Pseudozustand ist ein Steuerungselement für den Ablauf eines Zustandsautomaten. Anders als ein echter Zustand besitzt er keine Wertebelegungen. UML2 kennt unter anderem den Startzustand (initial), der keine eingehenden und genau eine ausgehende Transition hat, sowie den Terminator (terminate), der keine ausgehenden Transitionen hat; das modellierte Objekt hört dann auf zu existieren.

Weitere Pseudo-Zustände sind join zur Vereinigung paralleler Kontrollflüsse, fork zur Aufspaltung in parallele Zustände, junction, choice für alternative ausgehende Transitionen sowie entry point und exit point.

History-Zustände ermöglichen die Rückkehr in den zuletzt aktiven Subzustand eines komplexen Zustands, nachdem dieser durch eine äußere Transition verlassen wurde. Bei einer Transition von außen zum History-Zustand wird der alte Subzustand aktiviert; entry-Aktivitäten laufen dabei sequenziell von außen nach innen. Ein History-Zustand darf beliebig viele eingehende, aber nur eine ausgehende Kante haben. Diese Kante hat weder Ereignisse noch Bedingungen und bestimmt den Subzustand für den Fall, dass es noch keinen letzten aktiven Subzustand gibt oder der komplexe Zustand regulär über einen Endzustand verlassen wurde.

Jeder komplexe Zustand darf höchstens einen flachen und einen tiefen History-Zustand besitzen. Die flache Historie speichert eine Ebene und stellt einen Zustand auf derselben Ebene wieder her. Die tiefe Historie merkt sich die zuletzt aktiven Subzustände über die gesamte Schachtelungstiefe.

Typische Einsatzformen

Ein Verhaltenszustandsautomat (englisch behavioral state machine) modelliert das Verhalten eines Modellelements. Als Beispiel wird das Verhalten einer Waschmaschine spezifiziert.

Ein Protokollzustandsautomat (englisch protocol state machine) beschreibt dagegen die zulässige Nutzung der Verhaltensmerkmale eines Classifiers. Als Beispiel dient ein Webservice zur Flugreservierung: Der Automat legt die Reihenfolge der aufzurufenden Operationen fest. Ein Flug kann nur gebucht werden, wenn er zuvor erfolgreich reserviert wurde; ein einmal gebuchter Flug kann nicht mehr storniert werden.