UML-Zustandsdiagramme: Folgen von Objektzuständen sichtbar machen

Beim Entwickeln eines Produkts oder dem Programmieren von Software helfen UML-Zustandsdiagramme dabei, den Lebenszyklus der einzelnen Objekte bildhaft und verständlich darzustellen. Obwohl ein solches Diagramm nur aus wenigen Elementen besteht, trägt es bei einer korrekten Anwendung entscheidend zum Erfolg des Endprodukts bei. Warum und in welchen Fällen sich ein solches Diagramm lohnt und wie Sie ein eigenes UML-Zustandsdiagramm erstellen, erfahren Sie in den folgenden Abschnitten.

Was ist ein Zustandsdiagramm?

Ein UML-Zustandsdiagramm (auch: Zustandsübergangsdiagramm, state diagram, state machine diagram) visualisiert Zustände eines endlichen Automaten, also eines Verhaltensmodells bestehend aus Aktionen und Zuständen bzw. Zustandsübergängen. Dabei sieht das Diagramm für jedes Objekt des Modells sowohl einen Anfangs- als auch einen Endzustand sowie mindestens ein Zwischenzustand vor. Damit macht es das Zustandsdiagramm möglich, den kompletten Lebenszyklus eines Systems bzw. eines Teilsystems oder einzelner Komponenten bzw. Klassen abzubilden – egal, ob es sich beispielsweise um die Prozesse einer Kaffeemaschine, eines E-Book-Readers oder einer technischen Komponente in einem Fahrzeug handelt.

Das Zustandsdiagramm ist eines von insgesamt 14 Diagrammarten der Unified Modeling Language (UML) und der Systems Model Language (SysML). Es geht zurück auf ein Konzept von David Harel, das dieser im Jahr 1987 in der wissenschaftlichen Arbeit „Statecharts: A Visual Formalism for Complex Systems“ veröffentlichte. Weitere UML-Diagrammtypen sind beispielsweise das Anwendungsfalldiagramm und das Komponentendiagramm.

Welchen Einsatzzweck haben UML-Zustandsdiagramme?

Wie bereits erwähnt, steht bei Zustandsdiagrammen das Ziel im Fokus, das Verhalten eines Systems so genau wie möglich zu beschreiben. Unter anderem soll die grafische Darstellung der einzelnen Prozesse am Ende folgende Fragen beantworten können:

  • Was passiert, wenn das Objekt sich in einem spezifischen Zustand befindet?
  • Welcher Zustand muss eintreten, damit es sein Verhalten ändert?
  • Was sind die auslösenden Aktionen?
  • Welche Eigenschaften muss das Objekt haben, um den Zustand wechseln zu können?

UML-Zustandsdiagramme kommen in der Konsequenz überall dort zum Einsatz, wo es sinnvoll ist, Zustände und Übergangsbedingungen für einen optimierten Entwicklungsprozess zu visualisieren. Besonders beliebt sind sie etwa bei der Konzeption eingebetteter Systeme (Embedded Systems), da diese im Hintergrund diverse automatisierte Signale und Prozesse verarbeiten, die es optimal aufeinander abzustimmen gilt. Ein Zustandsdiagramm unterstützt Entwickler in diesem Fall dadurch, dass es alle relevanten Steuerungs- und Regelungsfunktion visualisiert und so auf einen Blick verfügbar macht.

Einfach erklären lässt sich der Nutzen von Zustandsdiagrammen am Beispiel der Waschmaschinenfunktion „Aqua Stop“: Diese reguliert, wann die Wasserversorgung einer Waschmaschine unterbrochen wird. Im Rahmen eines UML-Zustandsdiagramms kann sie als eigenes System verstanden werden. Die grafische Darstellung macht in diesem Fall sichtbar, in welchem Zustand und unter welchen Bedingungen das Prinzip „Aqua Stop“ greift.

Hinweis

In vielfältigen Industriezweigen wie der Medizintechnik oder dem Transportwesen werden Zustandsdiagramme zur Erklärung komplexer Sachverhalte eingesetzt. Auch im Produkt- und Projektmanagement sowie im Requirements Engineering finden Zustandsdiagramme Verwendung.

Zustandsdiagramm: Aufbau und Komponenten im Überblick

UML-Zustandsdiagramme basieren zwar nur auf einigen wenigen Elementen – durch die geschickte Kombination dieser Komponenten lassen sich aber auch komplexe Zustandsabfolgen problemlos abbilden. Was sind die wichtigsten Bestandteile und wie sieht der grundlegende Aufbau eines Zustandsdiagramms aus?

Zustände

Zustände sind die zentrale Komponente eines Zustandsdiagramms. Alle echten Zustände werden dabei immer mit einem Rechteck dargestellt, das abgerundete Ecken hat. Eine Tür kann beispielsweise zwei Zustandswerte besitzen:

Zustände einer Tür im Zustandsdiagramm dargestellt
Zwei mögliche Zustände einer Tür: Sie kann geöffnet oder geschlossen sein, aber nicht beides gleichzeitig.

Bleibt man bei dem Zustandsdiagramm-Beispiel zur Darstellung der Zustände einer Tür, muss in der Konsequenz folgende Bedingung immer erfüllt sein:

  • Das Objekt befindet sich immer in einem der jeweiligen Zustände: Die Tür ist also entweder offen oder geschlossen, aber niemals gleichzeitig offen und geschlossen.

In komplexeren Zustandsdiagrammen kann das Rechteck in bis zu drei Bereiche unterteilt werden, die Verhaltensspezifikationen darstellen (siehe Transition).

Transition: Wie wechselt ein Zustand?

Um von einem Zustand in den nächsten zu gelangen, muss ein Ereignis ausgelöst werden, das einen Übergang darstellt. Dieser Zustandsübergang (Transition) verbindet die Zustände miteinander –visuell dargestellt mittels eines Pfeils. Es kann Bedingungen geben, damit ein solcher Übergang ausgelöst werden kann. Prinzipiell wird in UML-Zustandsdiagrammen zwischen inneren und äußeren Transitionen unterschieden. Während äußere Transitionen beim Zustandsdiagramm-Erstellen obligatorisch sind, müssen innere Transitionen nicht unbedingt Bestandteil des Diagramms sein.

In dem Zustandsdiagramm eines Fahrstuhlsystems kann beispielsweise für die Aktion „Fahrstuhltür schließen“ die Bedingung angegeben sein, dass diese zuvor mindestens fünf Sekunden geöffnet sein muss, bevor der Zustand von „auf“ nach „zu“ wechselt.

Äußere Transition: Zustand wechselt

Bei den Transitionen wie im folgenden Beispiel eines UML-Zustandsdiagramms handelt es sich um sogenannte äußere Transitionen. Dabei hat die Transition zur Folge, dass das Objekt in einen anderen Zustand wechselt (entry/exit).

Beispiel: Wird der Alarm eines Radioweckers ausgelöst, wechselt der Zustand von „Alarm aktiviert“ zu „Alarm deaktiviert“. Der Zustand ändert sich.

Zustandsdiagramm-Beispiel: Äußere Transition
Bei dem Auslösen eines Weckeralarms wechselt das Objekt den Zustand: War die Alarmfunktion gerade noch aktiviert, ist sie nun deaktiviert.

Innere Transition: Zustand bleibt unverändert

Bei einer inneren Transition wird keine Zustandsveränderung ausgelöst, jedoch eine Aktivität.

Beispiel: In einem Buchhaltungssystem kann auf eine nicht bezahlte Rechnung das automatische Verschicken einer Rechnung erfolgen (äußere Transition). Wird als Reaktion auf einen fehlenden Ausgleich eine Mahnung verschickt, dann handelt es sich beim Verschicken der Mahnung um eine innere Transition. Es erfolgt nämlich zwar eine Aktivität „Verschicken der Mahnung“, die Rechnung verbleibt aber bis auf weiteres in ihrem Zustand „unbezahlt“.

Ereignisse: Warum wechseln Zustände?

Ereignisse (Actions) können näher beschreiben, unter welchen Bedingungen ein Zustand verlassen wird, um in den nächsten Zustand zu wechseln. Beim Übergang vom Startzustand zum ersten echten Zustand ist es nicht notwendig, weitere Ereignisangaben sind optional. Wird kein Ereignis angegeben, bedeutet dies, dass es automatisch eintritt, sobald alle Aktivitäten in vorherigen Zuständen abgeschlossen sind.

Ein KEIN-Ereignis (Trigger/ANY-Trigger) besagt, dass das Ereignis grundsätzlich immer vorhanden ist. Ereignisse können als Verhaltensspezifikation innerhalb des Zustands benannt werden oder innerhalb des Zustandsübergangs benannt werden (siehe Transition).

Ein auslösendes Ereignis muss die folgenden drei Bedingungen erfüllen:

  • entry: Das Ereignis wird beim Eintritt in einen Zustand automatisch ausgelöst, d. h. in allen hereinkommenden Übergängen.
  • exit: Das Ereignis wird beim Verlassen eines Zustandes ausgelöst, d. h. in allen abgehenden Übergängen.
  • do: Das Ereignis wird immer wieder ausgelöst, wenn der Zustand nicht gewechselt wird.

Diese Verhaltensspezifikationen können innerhalb des Zustands notiert werden, um vereinfacht darzustellen, unter welchen Verhaltensweisen sich der Zustand ändert. Für die grafische Darstellung solcher Auslöser gibt es zwei Möglichkeiten: Einmal können sie innerhalb des entsprechenden Zustands ausgewiesen werden, wie folgendes Zustandsdiagramm-Beispiel verdeutlicht:

Zustandsdiagramm-Beispiel: Zustand mit auslösenden Ereignissen
Der Zustand einer Tür ist „geschlossen“. Um in diesen Zustand zu kommen, muss zunächst das Ereignis „Tür schließen“ (entry) erfolgen. Wird der Zustand verlassen, erfolgt das Ereignis „Tür öffnen“ (exit). Während des Zustands gilt „Tür ist (durchgehend) geschlossen“ (do).

Alternativ können Ereignisse über dem Transition-Pfeil angegeben werden:

Darstellung zweier aufeinanderfolgender Zustände mit Ereignis und Transition
In einfachen Zustandsdiagrammen werden Ereignisse über dem Transition-Pfeil angegeben.

Pseudozustände

Wenn Steuerungselemente den Ablauf eines Zustandsautomaten beeinflussen, aber keine Wertebelegungen besitzen, bezeichnet man diese in UML-Zustandsdiagrammen als Pseudozustände. UML 2, die aktuelle Version der Unified Modeling Language, kennt zehn verschiedene dieser Pseudozustände:

  • Startzustand (engl. initial): keine eingehende und exakt eine ausgehende Transition, die den Anfangszustand preisgibt
  • Endzustand (engl. final): keine ausgehende Transition, Ende der Verhaltensabfolge
  • Gabelung (engl. fork): Aufspaltung in mehrere parallele Zustände
  • Synchronisation (engl. join): Vereinigung von mehreren parallelen Zuständen
  • Kreuzung (engl. junction): Knotenpunkt zum Hintereinanderschalten mehrerer Transitionen
  • Entscheidung (engl. choice): Knoten, von dem mehrere alternative Transitionen auf Basis einer zuvor getroffenen Entscheidung starten können
  • Eintrittspunkt (engl. entry point): Zusammenfassung gleichartiger, in einen zusammengesetzten Zustand einlaufenden Transitionen
  • Austrittspunkt (engl. exit point): Zusammenfassung gleichartiger, aus einem zusammengesetzten Zustand auslaufender Transitionen
  • Flache Historie (engl. shallow history): Speicherung des letzten aktiven Unterzustands eines zusammengesetzten Zustands
  • Tiefe Historie (engl. deep history): Speicherung des letzten aktiven Unterzustands aller Hierarchie-Ebenen eines zusammengesetzten Zustands

Special: Untergeordnetes Diagramm

Je nach Komplexität sind Unterzustände möglich, die ein detailliertes Bild des Objektzustandes und der möglichen Verhaltensweisen geben. Solche komplexeren Erklärungen in UML-Zustandsdiagrammen sind in insbesondere in technischen Kontexten die Regel.

  • composite state: Hierbei kann ein Zustand tiefgehender definiert werden.

Beispiel: Eine Tür kann sich im Zustand „auf“ und „zu“ befinden. Unterzustände des Zustandes „zu“ könnten „aufgeschlossen“ oder „zugeschlossen“ sein.

  • submachine state: Hierbei wird einem Zustand ein untergeordnetes Zustandsdiagramm zugefügt. Unterzustände, die aus mehreren Subzuständen bestehen, werden komplexe Zustände genannt. Die verschiedenen Subzustände können unabhängig voneinander durchlaufen werden, aber auch in Beziehung zueinander stehen.

Beispiel: In einem Smartphone ist die Weckerfunktion nur eine von vielen Funktionen, mit denen mehrere Zustände verbunden sein können. Wenn mehrere Alarme für unterschiedliche Wochentage und Uhrzeiten programmiert sind, handelt es sich dabei um Subzustände, die unabhängig voneinander ablaufen.

Zustandsdiagramm erstellen: Beispiel für ein einfaches Zustandsdiagramm

Ein Zustandsdiagramm lässt sich auf die unterschiedlichsten Objekte anwenden. Im folgenden Beispiel sollen die verschiedenen Elemente anhand der grafischen Darstellung der Zustände einer Rechnung vorgestellt werden. Die wichtigsten Elemente eines UML-Zustandsdiagramms werden wie folgt dargestellt:

Zustandsdiagramm erstellen: Die wichtigsten Elemente
Die wichtigsten Elemente in UML-Zustandsdiagrammen

Zusammengesetzt und auf das Beispiel übertragen sieht das einfache Diagramm wie folgt aus:

Grafisches Beispiel einer inneren Transition
Dieses Beispiel eines UML-Zustandsdiagramms zeigt eine innere Transition.

Nach dem Startpunkt als Pseudozustand befindet sich die Rechnung im Zustand „geschrieben“ (written). Es folgt im besten Falle die Transition zum Zustand „bezahlt“ (paid). Dieser Übergang kann noch näher beschrieben werden, indem er mit dem Ereignisnamen „verschicken“ versehen wird.

Ist die Rechnung beglichen, befindet sich die Rechnung im Zustand „bezahlt“. Bevor dieser Zustand erreicht wird, kann es nötig werden, eine „Mahnung“ (reminder) zu verschicken. Da die Rechnung hierbei nicht den Zustand ändert, es sich jedoch um eine Aktivität handelt, ist es eine innere Transition. Wird die Rechnung nicht beglichen, werden bis zu drei Mahnungen verschickt.

War dieser Artikel hilfreich?