Zustandsdiagramm (UML)

Das Zustandsdiagramm (englisch state diagram) ist eins der 14 Diagrammarten der Sprache UML für Software und andere Systeme. Es stellt einen endlichen Automaten in einer UML-Sonderform grafisch dar und wird benutzt, um entweder das Verhalten eines Systems oder die zulässige Nutzung der Schnittstelle eines Systems zu spezifizieren.

Die in der UML verwendete Diagrammform ist eine Variante des Zustandsübergangsdiagramms. Neben dieser Diagrammform gibt es in der Informatik und der Telekommunikation weitere Formen, die sich nicht grundsätzlich, wohl aber in der Ausdrucksmächtigkeit unterscheiden.

Der in UML-Zustandsdiagrammen abgebildete Typ von Zustandsautomat ist eine objektbasierte Variante von Harel-Zustandsdiagrammen,^[1] die von der UML aufgenommen und erweitert wurden. UML-Zustandsautomaten überwinden Einschränkungen von traditionellen endlichen Automaten und erhalten ihre größten Vorteile. Das UML-Zustandsdiagramm führt neue Konzepte von hierarchisch verschachtelten Zuständen und orthogonalen Bereichen ein und erweitert den Begriff der Aktion entsprechend. UML-Zustandsautomaten haben zugleich Eigenschaften von Mealy- und Moore-Automaten. Sie unterstützen Aktionen, die zugleich vom Zustand des Systems und einem auslösenden Ereignis abhängen, wie in Mealy-Automaten, ebenso wie Eintritts- und Austritts-Aktionen, die eher zustands- als aktionsorientiert sind, wie in Moore-Automaten.

Ein Zustandsdiagramm zeigt die zur Laufzeit erlaubten Zustände eines Zustandsautomaten (z. B. eines Objektes oder auch eines Systems) an und gibt Ereignisse an, die seine Zustandsübergänge auslösen. Damit beschreibt ein Zustandsdiagramm eine hypothetische Maschine (endlicher Automat), die sich zu jedem Zeitpunkt in genau einem Zustand einer endlichen Menge von Zuständen befindet.

Die Zustände in einem Zustandsdiagramm werden durch Rechtecke mit abgerundeten Ecken (in anderen Diagrammformen außerhalb von UML häufig auch Kreise, Ellipsen oder einfache Rechtecke) dargestellt. Die Pfeile zwischen den Zuständen symbolisieren mögliche Zustandsübergänge. Sie sind mit den Ereignissen beschriftet, die zu dem jeweiligen Zustandsübergang führen.

Der in einem Diagramm dargestellte Zustandsautomat besteht aus Knoten (englisch vertices) und (Zustands-)Übergängen (englisch transitions). Die Transitionen verbinden Quell- und einen Zielknoten. Jeder Knoten ist entweder ein Zustand (englisch state) oder aber ein so genannter Pseudo-Zustand (englisch pseudo state).

Ein Zustandsdiagramm ist ein Graph mit Zuständen als Knoten und Zustandsübergängen als Kanten. Ein Zustand wird im Diagramm als Rechteck mit abgerundeten Ecken dargestellt und mit dem Namen des Zustands beschriftet. Befindet sich ein Objekt in einem Zustand, so können alle sogenannten inneren Aktivitäten auf diesem Objekt ausgeführt werden, die in diesem Zustand spezifiziert sind. In diesem Fall ist die Darstellung des Zustands zweigeteilt. Im oberen Abschnitt des Rechtecks kann der Name des Zustands notiert werden. Im unteren Abschnitt können u. a. innere Aktivitäten angeführt werden, wobei eine Aktivität mehrere Aktionen beinhalten kann.^[2] Ein Zustand modelliert eine Situation, in der eine bestimmte, unveränderliche Bedingung gilt. Meistens ist diese Invariante nur implizit gegeben; will man sie explizit formulieren, kann man sie als Einschränkung dem Zustand zuordnen.

Dem Zustand können drei Verhaltensspezifikationen, zum Beispiel in Form einer Aktivität oder einer Interaktion, zugeordnet werden:

• ein Verhalten, das ausgeführt wird, wenn der Zustandsautomat in den Zustand eintritt (engl. entry behaviour)
• ein Verhalten, das ausgeführt wird, wenn der Zustandsautomat den Zustand verlässt (engl. exit behaviour)
• ein Verhalten, das ausgeführt wird, während sich der Zustandsautomat im Zustand befindet (engl. doActivity)
• ein Verhalten, das ausgeführt wird, wenn ein bestimmtes Event eintritt. (eng. event behaviour)

Im Gegensatz zu den ersten drei Verhalten wird beim Event-Verhalten ein tatsächliches Event im Zustand angegeben (z. B.: mouseOver / peep).

Graphisch wird ein Zustand meistens als Rechteck mit abgerundeten Ecken dargestellt, leicht unterschiedliche Darstellungsformen sind aber auch möglich, siehe Beispiele in der Abbildung rechts.

Eine Transition (Übergang) verbindet einen Quell- und einen Zielknoten. Der Transition kann eine Verhaltensspezifikation zugeordnet sein, die das Verhalten beschreibt, das ausgeführt wird, wenn die Transition durchlaufen wird. Dieses Verhalten heißt Effekt (englisch effect). Ein Wächterausdruck (engl. guard) kann die Transition schützen: die Transition kann nur durchlaufen werden, wenn der Wächterausdruck wahr ist.

Man unterscheidet zwischen inneren und äußeren Transitionen. Innere Transitionen bezeichnen die Reaktion auf ein Ereignis, das eine Aktivität, nicht aber einen Zustandsübergang auslöst. Da es zu keiner Zustandsänderung kommt, werden auch keine entry- oder exit-Aktivitäten ausgeführt. Entry- und exit-Aktivitäten werden in derselben Notation modelliert, benötigen aber die Schlüsselwörter entry bzw. exit anstatt der Bezeichnung des auslösenden Ereignisses, um anzugeben, dass die jeweilige Aktivität beim Betreten bzw. Verlassen des Zustands ausgeführt wird. Innere Transitionen werden innerhalb von Zuständen modelliert. Wird als Reaktion auf ein Ereignis ein Zustand verlassen und ein anderer Zustand betreten, spricht man von einer äußeren Transition. Im Zuge des Zustandsübergangs werden etwaige exit-Aktivitäten des Quellzustands sowie entry-Aktivitäten des Zielzustands ausgeführt. Eine spezielle äußere Transition ist die Selbsttransition, bei der der Quellzustand und der Zielzustand identisch sind. Abbildung zeigt Beispiele für innere und äußere Transitionen.^[2]

History-Zustände werden verwendet, wenn nach einer äußeren Transition, die aus einem komplexen Zustand hinausführt, später wieder zu demselben Subzustand zurückgefunden werden soll, der vor Eintreten der Transition aktiv war. Der History-Zustand merkt sich, welcher Subzustand eines komplexen Zustands zuletzt aktiv war. Führt eine Transition von außen zum History-Zustand, so aktiviert dieser den »alten« Subzustand und alle entry-Aktivitäten werden sequenziell von außen nach innen durchgeführt. Ein History-Zustand kann beliebig viele eingehende Kanten besitzen, aber nur eine ausgehende Kante. Die ausgehende Kante darf keine Ereignisse und keine Bedingungen aufweisen und hat als Ziel den Subzustand, der aktiv werden soll, falls der komplexe Zustand zuvor noch nie aktiv war und damit kein »letzter aktiver Subzustand« existiert, oder falls der komplexe Zustand zuletzt regulär über das Erreichen eines Endzustands verlassen wurde. Es gibt zwei Arten von History-Zuständen, den flachen History-Zustand und den tiefen History-Zustand. Jeder komplexe Zustand darf nur maximal einen flachen und einen tiefen History-Zustand besitzen. Der flache History-Zustand stellt den Zustand wieder her, der direkt auf derselben Ebene im komplexen Zustand liegt wie der flache History-Zustand selbst. Der tiefe History-Zustand hingegen merkt sich den zuletzt aktiven Subzustand über die gesamte Schachtelungstiefe hinweg.^[2]

Ereignis (Argumente) [Bedingung] / Aktivität

Der Pseudozustand ist ein Steuerungselement, das den Ablauf eines Zustandsautomaten beeinflusst. In einem Pseudozustand existieren im Unterschied zu einem echten Zustand keine Wertebelegungen.

Die UML2 kennt folgende Pseudo-Zustände:

• der Startzustand (engl. initial)

Besitzt keine eingehenden Transitionen und nur genau eine ausgehende Transition, die angibt, in welchem Zustand begonnen wird.

• der Terminator (engl. terminate)

Besitzt keine ausgehenden Transitionen. Das Objekt, dessen Verhalten modelliert wird, hört auf zu existieren.

• die Vereinigung (engl. join)

Vereinigung des Kontrollflusses von mehreren parallelen Zuständen

• die Gabelung (engl. fork)

Aufspaltung des Kontrollflusses in mehrere parallele Zustände

• die Kreuzung (engl. junction)
• die Entscheidung (engl. choice)

Knoten, von dem mehrere alternative Transitionen ausgehen können.

• der Eintrittspunkt (engl. entry point)
• der Austrittspunkt (engl. exit point)

Historische Zustände können jenen internen Zustand in einem komplexen Zustand speichern, von dem die Transition (vor einer Unterbrechung) ausgegangen ist. Zu einem späteren Zeitpunkt kann zu diesem Zustand über Transitionen aus übergeordneten Zuständen zurückgekehrt werden, wobei alle entry-Aktivitäten erneut ausgeführt werden.

• die flache Historie (engl. shallow history)

Der flache Historiezustand speichert eine Ebene.

• die tiefe Historie (engl. deep history)

Im tiefen Historiezustand werden alle Zustände über die gesamte Schachtelungstiefe hinweg gespeichert.

Ein Verhaltenszustandsautomat (engl. behavioral state machine) modelliert das Verhalten eines Modellelements. Der Zustandsautomat in der Abbildung links spezifiziert zum Beispiel das Verhalten einer Waschmaschine.

Ein Protokollzustandsautomat (englisch protocol state machine) spezifiziert die zulässige Nutzung der Verhaltensmerkmale eines Classifiers.

In der Abbildung links ist zum Beispiel ein Webservice spezifiziert, über den Flüge reserviert werden können. Der zugeordnete Protokollzustandsautomat spezifiziert, in welcher Reihenfolge die Operationen des Webservice aufzurufen sind. Aus der Spezifikation geht zum Beispiel hervor, dass ein Flug nur gebucht werden kann, wenn er zuvor erfolgreich reserviert wurde oder dass ein einmal gebuchter Flug nicht mehr gestrichen werden kann.

• Christoph Kecher: UML 2.0 – Das umfassende Handbuch. Galileo Computing, 2006, ISBN 3-89842-738-2. 
• Heide Balzert: Lehrbuch der Objektmodellierung – Analyse und Entwurf mit der UML 2. Elsevier Spektrum Akademischer Verlag, 2005, ISBN 3-8274-1162-9. 
• David Harel: Statecharts: A Visual Formalism for Complex Systems. In: Science of Computer Programming. Band 8, 1987, S. 231–274 (archive.org [PDF; 1,9 MB] verfasst 1984/86). 

1. ↑ Harel, David: Statecharts: A Visual Formalism for Complex Systems. (PDF; 1,9 MB) 1987, archiviert vom Original; abgerufen am 9. März 2011 (englisch). 
2. ↑ ^{a b c} Martina Seidl, Marion Brandsteidl, Christian Huemer, Gerti Kappel: UML @ Classroom Eine Einführung in die objektorientierte Modellierung. (PDF; 393 kB) In: Technische Universität Wien. 2012, abgerufen am 14. Mai 2012.