Zustandsdiagramm

Pseudozustände

Neben den drei Zustandstypen gibt es noch eine allgemeine Einteilung von Zuständen: echte Zustände, in denen sich ein System dauerhaft befinden kann und Pseudozustände, die ein System nicht dauerhaft einnehmen kann.

Der Pseudozustand ist ein Element, das den Ablauf eines Zustandsautomaten beeinflusst. Er ist kein echter Zustand, denn es gibt keine Wertekombinationen, die dieser Zustand repräsentiert.

Die UML 2.5 kennt zehn unterschiedliche Pseudozustände. Jeder beschreibt eine spezielle Eigenschaft, die die Zustandsübergänge steuert:

• der Startzustand (engl. initial)
• der Endzustand (engl. final)
• die Gabelung (engl. fork)
• die Synchronisation (engl. join)
• die Kreuzung (engl. junction)
• die Entscheidung (engl. choice)
• der Eintrittspunkt (eng. entry point)
• der Austrittspunkt (engl. exit point)
• die flache Historie (engl. shallow history)
• die tiefe Historie (eng. deep history)

Historie-Zustände werden verwendet, wenn im Zuge einer Transition wieder zu demselben Zustand zurückgefunden werden soll, der vor Eintreten der Transition aktiv war. Mit dem flachen und dem tiefen Historie-Zustand gibt es zwei Arten von Historie-Zuständen. Die flache Historie stellt auf derselben Ebene den vorherigen Zustand wieder her, während der tiefe History-Zustand den zuletzt aktiven Subzustand über eine gesamte Schachtelungstiefe hinweg aktiviert. Grundsätzlich darf jeder Zustand nur maximal einen flachen und einen tiefen Historie-Zustand besitzen.

Diskrete Zustände sind klar voneinander abgegrenzte Zustände, in denen sich ein System befinden kann. Jeder dieser Zustände ist eindeutig definiert, und das System kann nur durch wohl definierte Übergänge von einem Zustand in einen anderen wechseln.

Ein Beispiel dafür ist eine Ampel mit den Zuständen Rot, Gelb und Grün, zwischen denen sie nach festen Regeln wechselt.

Zustandsdiagramme sind weniger geeignet, wenn ein System keine klar trennbaren Zustände hat. Beispiele dafür sind:

• Ein Thermostat, das die Temperatur kontinuierlich regelt, anstatt zwischen festen „kalt“ oder „warm“-Zuständen zu wechseln.
• Ein neuronales Netz oder KI-Modell, bei dem Zustände probabilistisch oder dynamisch sind.
• Parallele Prozesse, bei denen mehrere Zustände gleichzeitig auftreten können, wie etwa im Multithreading einer Software.

Ein Zustandsdiagramm eignet sich also besonders dann, wenn das System sich in klar definierte Zustände mit eindeutigen Übergängen einteilen lässt.

Zustandsdiagramme werden häufig im Bereich der Embedded Systems für die Überwachung, Steuerung und Regelung von Funktionen oder die Daten- bzw. Signalverarbeitung genutzt. Eingebettete Systeme – als Kombination aus Software und Hardware – verrichten oft unsichtbar für den Nutzer Dienste in Autos, Flugzeugen, Kühlschränken oder Aufzügen. Sie steuern die Geldausgabe am Bankautomaten und sorgen für den Aqua Stop bei der Spülmaschine.

Auch ganze Wirtschaftsbereiche wie die Medizintechnik, die Unterhaltungsbranche, die Kommunikationsinsdustrie oder das Transportwesen verlassen sich auf eingebettete Systeme und damit auch auf Zustandsdiagramme. Und selbst in unterschiedlichen Unternehmensbereichen, die sich im weitesten Sinne um die Produktion der Produkte kümmern, also bspw. das Produkt- und Projektmanagement oder das Requirements Engineering, ist die Verwendung von Zustandsdiagrammen weit verbreitet.

Ursprung des Zustandsdiagramms

Zustandsdiagramme gehen auf ein Konzept von David Harel, einem israelischen Professor für Informatik, zurück, der bereits 1987 „Statecharts: A Visual Formalism for Complex Systems“¹ veröffentlichte. Erst später wurde das Zustandsdiagramm als eins von 14 Diagrammarten in die Unified Modeling Language (UML) und baugleich in die Systems Model Language (SysML) aufgenommen. Dabei wurde das Konzept um hierarchisch verschachtelte Zustände, orthogonale Bereiche und Aktionen erweitert, die gleichzeitig vom Zustand des Systems und einem auslösenden Ereignis abhängen können. Auch die Verwendung von Eintritts- und Austritts-Aktionen, die eher zustands- als aktionsorientiert sind, wurde integriert. Damit haben UML-Zustandsautomaten Eigenschaften der Mealy²- und Moore³-Automaten übernommen.

Die UML 2.5 definiert darüber hinaus sogenannte

• behavioral state machines, die Verhalten von Systemen, Sys­temteilen oder Instanzen einer Klasse modellieren,
• und protocol state machines, die Protokolle, die von einem System­element realisiert werden, dokumentieren.

 

Zustandsdiagramme sind ein sehr gutes Instrument zur Beschreibung von Systemen und ihrem möglichen Verhalten. Sie bieten folgende Vorteile:

• Der Lebenszyklus eines Objekts, von der Initialisierung bis zur Freigabe, lässt sich modellieren. Damit wächst das gemeinsame Verständnis der Beteiligten über das modellierte Objekt.
• Die erlaubten Zustände eines Objekts und die Ereignisse, die durch Zustandsübergänge ausgelöst werden, lassen sich beschreiben. Dadurch wird das Verhalten des Objekts sichtbar und nachvollziehbar.
• Sie lassen sich einfach und in vielen Situationen verwenden, zumal selbst ungeübte Leser sie mit ein wenig Übung leicht verstehen.
• Sie helfen dabei, komplexe Abläufe zu strukturieren und zu visualisieren, wodurch Fehler und Unstimmigkeiten frühzeitig erkannt werden können.
• Sie können als Dokumentation für die spätere Wartung und Weiterentwicklung eines Systems dienen, da sie eine klare und präzise Darstellung des Systemverhaltens bieten.
• Sie eignen sich gut für die Simulation und Validierung von Systemen, bevor diese implementiert werden.

Trotz ihrer Vorteile gibt es auch einige Herausforderungen bei der Verwendung von Zustandsdiagrammen:

• Bei sehr komplexen Systemen kann das Diagramm schnell unübersichtlich werden, insbesondere wenn es viele Zustände und Übergänge gibt.
  Die Erstellung eines detaillierten Zustandsdiagramms kann zeitaufwendig sein, insbesondere wenn viele Sonderfälle berücksichtigt werden müssen.
• Nicht alle Systeme oder Prozesse lassen sich sinnvoll mit Zustandsdiagrammen darstellen, insbesondere wenn das Verhalten nicht eindeutig durch diskrete Zustände beschrieben werden kann.
• Änderungen im System erfordern oft eine Anpassung des Diagramms, was zusätzlichen Pflegeaufwand bedeutet.
• Manche Entwickler bevorzugen andere Modellierungsmethoden wie Aktivitätsdiagramme oder Sequenzdiagramme, da diese für bestimmte Anwendungsfälle besser geeignet sein können.

 

Zustandsdiagramme sind universell einsetzbar, sollten jedoch gezielt verwendet werden, insbesondere für komplexe Systeme oder Prozesse, bei denen sie einen echten Mehrwert bieten. Bei einfach strukturierten Objekten kann ihr Nutzen hingegen eher gering sein. Um eine einheitliche und verständliche Darstellung zu gewährleisten, empfiehlt es sich, auf standardisierte Notationen wie UML 2.5 oder ihre Entsprechung in der SysML zurückzugreifen. Ein gut strukturiertes Zustandsdiagramm sollte von links oben nach rechts unten verlaufen, um eine intuitive Leseführung zu ermöglichen.

Da zu viele Details die Übersichtlichkeit beeinträchtigen können, ist es oft sinnvoll, komplexe Zusammenhänge in untergeordnete Diagramme auszulagern. Gleichzeitig sollte geprüft werden, ob Zustandsdiagramme die beste Darstellungsform sind oder ob sie durch andere Methoden ergänzt werden sollten, da sie zwar oft der Dokumentation in Tabellen überlegen sind, aber nicht in jeder Situation die optimale Wahl darstellen. Besonders wichtig ist es, dass die Zustände und Übergänge klar definiert sind und das System durch diskrete Zustände eindeutig beschrieben werden kann.

Damit Zustandsdiagramme ihren Zweck bestmöglich erfüllen, sollten sie auf die Zielgruppe abgestimmt sein. Entwickler benötigen oft detaillierte technische Darstellungen, während für Manager oder Kunden eine vereinfachte, übersichtliche Version hilfreicher sein kann. Durch eine durchdachte Gestaltung und den gezielten Einsatz lassen sich Zustandsdiagramme effizient und zielführend nutzen.