t2informatik » Wissen kompakt » Zustandsdiagramm

Was ist ein Zustandsdiagramm?

Was visualisieren Zustandsdiagramme, wo kommen sie zum Einsatz und welche Vorteile bieten sie?

Zustandsdiagramm – Definition

Ein Zustandsdiagramm – auch state diagram, state machine diagram oder Zustandsübergangsdiagramm genannt – visualisiert eine Folge von Zuständen, die ein Objekt im Lebenszyklus einnehmen kann. Es wird benutzt, um das Verhalten eines Systems, eines Teilsystems, einer Komponente oder einer Klasse zu beschreiben. Auch die Verwendung von Schnittstellen eines Systems lässt sich durch Zustandsdiagramme spezifizieren. Besonderes Augenmerk wird auf die Übergänge zwischen verschiedenen Zuständen des Objekts, die auslösenden Aktionen und die Eigenschaften des Objekts, die es vor dem Zustandswechsel besitzt oder besitzen muss, gelegt.

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.0 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.

Einsatzbereiche

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, Schiffen, Kühlschränken, Aufzügen, Fertigungsanlagen, TV-Geräten, Rolltreppen, Mobiltelefonen oder Waschmaschinen. 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.

Der endliche Automat

Ein Zustandsdiagramm zeigt eine Folge von Zuständen eines Objekts und visualisiert, durch welche Aktionen Zustandswechsel stattfinden. Damit beschreibt ein Zustandsdiagramm einen endlichen Automaten, der sich zu jedem Zeitpunkt in einer Anzahl endlicher Zustände befindet. Ein Automat ist endlich, wenn die Menge der Zustände, die er annehmen kann, endlich ist. Dabei speichert der Automat die Zustände, die vom Systemstart bis zum aktuellen Zeitpunkt durchlaufen wurden. Ein Zustandswechsel zeigt eine Änderung an und wird durch logische Bedingungen beschrieben. Nur wenn diese erfüllt sind, wird der Zustandsübergang ausgelöst.

Vorteile von Zustandsdiagrammen

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

  • 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.
  • Zustandsdiagramme lassen sich einfach und in vielen Situationen verwenden, zumal selbst ungeübte Leser sie mit ein wenig Übung leicht verstehen.

Die wichtigen Begriffe bei Zustandsdiagrammen

Zustände

Die UML 2.0 unterscheidet drei Zustandstypen:

  • den einfachen Zustand,
  • den zusammengesetzten Zustand, auch als composite state bezeichnet,
  • und den Unterzustandsautomatenzustand – im Englischen schlicht als submachine state bezeichnet.

Ein einfacher Zustand hat keine Unterzustände und kann verschiedene Aktivitäten und  Transitionen umfassen. Grundsätzlich müssen bei der Modellierung von Objekten in Zustandsdiagrammen folgende Voraussetzungen erfüllt werden:

  • Das Objekt befindet sich immer in genau einem der definierten Zustände.
  • Das Objekt befindet sich nie in keinem der definierten Zustände.
  • Das Objekt befindet sich nie gleichzeitig in mehreren Zuständen.

Beim composite state sind Unterzustände möglich. Beispielsweise könnte eine Tür zwei Zustände aufgeschlossen und zugeschlossen kennen und im aufgeschlossenen Zustand geöffnet oder geschlossen sein. Geöffnet und geschlossen wären entsprechende Unterzustände.

Der submachine state beschreibt einen Zustand, der Unterzustände enthält, die in einem untergeordneten Zustandsdiagramm dargestellt werden. Zustände, die aus mehreren Subzuständen zusammengesetzt sind, nennt man auch komplexe Zustände. Wenn der komplexe Zustand und genau ein Subzustand aktiv sind, spricht man von disjunkten Subzuständen. Durch eine Teilung des Zustands in Regionen können Subzustände auch nebenläufig und gleichzeitig aktiv sein. Hier spricht man vom orthogonalen Zustand bzw. Superzustand.

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.0 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.

Transitionen

Zustandsübergänge von einem Zustand zum nächsten werden als Transition bezeichnet. Sie werden durch Ereignisse ausgelöst. Transitionen verbinden zwei Zustände, also einen Quell- und einen Zielknoten. Der Transition kann eine Verhaltensspezifikation zugeordnet sein, die das Verhalten beschreiben, das zum Zustandswechsel führt. Das ausgelöste Verhalten wird als Effekt bezeichnet. Zusätzlich gibt es Wächterausdrücke, die dafür sorgen, dass Transitionen nur durchlaufen werden, wenn der Wächterausdruck wahr ist.

Es gibt zwei Arten von Zustandsübergängen:

  • Innere Transitionen bezeichnen die Reaktion auf ein Ereignis, das eine Aktivität aber keinen Zustandsübergang auslöst. Aufgrund der fehlenden Zustandsänderung werden auch keine entry- oder exit-Aktivitäten ausgeführt (siehe Ereignisse).
  • Äußere Transitionen führen durch die Reaktion auf ein Ereignis zu einem Zustandswechsel. Entsprechend werden auch mögliche entry- oder exit-Aktivitäten ausgeführt. Eine besondere äußere Transition ist die Selbsttransition, bei der der Quellzustand und der Zielzustand identisch sind.

Transition im Zustandsdiagramm - Wissen kompakt - t2informatik

Ereignisse

Ereignisse lösen Transitionen aus. Sie bestehen aus einem Namen und den zugeordneten Argumenten. Ein Zustand kann Bedingungen an ein Ereignis knüpfen, die erfüllt sein müssen bevor ein spezifischer Zustand durch ein Ereignis eingenommen wird. Für ein Ereignis bestehen grundsätzlich drei mögliche Verhaltensweisen:

  • 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, solange der Zustand nicht gewechselt wird (engl. do activity)

Darüber hinaus gibt es auch ein Verhalten, das ausgeführt wird, wenn ein Event eintritt (engl. event behaviour), bspw. ein „Peep“-Geräusch bei einem Mouse Over. Neben solchen Signal Events gibt es Call Events beim Empfang von Nachrichten, Time Events für Zustandsübergänge im Zeitablauf oder zu definierten Zeitpunkten und Change Events. Bei einem Change Event wird eine Bedingung permanent überprüft und ein entsprechender Zustandswechsel ausgelöst  sofern keine Überwachungsbedingung dies blockiert. Im Unterschied dazu wird eine Bedingung nur geprüft, wenn ein zugeordnetes Ereignis eintritt. Die Bedingung selbst kann keinen Zustandsübergang auslösen.

Zustandsdiagramm Guide - t2informatik Download

Jetzt den Zustandsdiagramm Guide kostenlos downloaden.

Alles Wichtige über das Zustandsdiagramme, wichtige Begriffe, Vorteile und Herausforderungen auf 8 Seiten zum Mitnehmen.

Hier klicken »

Herausforderungen für Unternehmen

Die sinnvolle Nutzung von Zustandsdiagrammen

Zustandsdiagramme sind universell einsetzbar. Sie lassen sich im Projekt- und Produktmanagement, im Änderungs- und Risikomanagement, oder beim Requirements Engineering sinnvoll nutzen. Sie helfen bei der Beschreibung von Systemverhalten und bei der Definition von Anforderungen. Durch ihren logischen Aufbau mit spezifizierten Zuständen, Transitionen, Ereignissen und Bedingungen eignen sie sich hervorragend für die Modellierung von Workflows mittels Software. Die Visualisierung der verschiedenen Elemente in Form von Zustandsdiagrammen ist meist der Dokumentation mit Tabellen überlegen. Dennoch müssen sich Unternehmen entscheiden, für welche Objekte sie Zustandsdiagramme zur Beschreibung verwendet wollen. Nur weil Zustandsdiagramme eine einfache Möglichkeit zur Visualisierung bieten, bedeutet dies nicht, dass Organisationen fortan nur noch entsprechende Diagramme skizzieren sollten. Es empfiehlt sich, Zustandsdiagramme nur bei komplexen Objekten zu verwenden, denn bei einfach strukturierten Objekten ist der Mehrwert beim Einsatz von Zustandsdiagrammen eher gering.

Grundsätzlich sollten die Verhaltensdiagramme so gestaltet werden, dass sie von links oben nach rechts unten gut lesbar sind. Ein Zustandsdiagramm soll zwar das gesamte Verhalten eines Zustandsautomaten beschreiben, dennoch kann es sehr sinnvoll sein, Details in untergeordneten Diagrammen zu verfeinern. Hier ist ein wenig Übung gefragt. Grundsätzlich bietet aber die UML 2.0 Notation bzw. ihre Entsprechung in der SysML eine klare und gut verständliche Struktur, die leicht zu erstellen und zu verstehen ist.

Gerne stellen wir Ihnen Wissen, Erfahrung und 100% Leidenschaft für Ihre Softwareentwicklung und Anforderungsanalyse zur Verfügung. Wir helfen Ihnen bei der Erhebung, Strukturierung und Verwaltung von Anforderungen und achten dabei auf Konsistenz, Vollständigkeit und Nachvollziehbarkeit. Wir unterstützen Sie beim Identifizieren von technischen Zusammenhängen, modellieren Zustandsdiagramme und berücksichtigen Stakeholder, Ziele und Randbedingungen. Und wir realisieren Ihre Projekte anhand Ihrer Anforderungen.

Hier erfahren Sie mehr zum Thema Softwareentwicklung »

Weitere Details und Hintergründe

Share This