Zustandsmodellierung

Ziel

Die Zustandsmodellierung dient dazu, den Lebenszyklus einer einzelnen Entität präzise und eindeutig zu beschreiben: die Menge der Zustände, die sie einnehmen kann, die Reihenfolge, in der sie von einem zum anderen wechselt, die Ereignisse und Bedingungen, die diese Wechsel steuern, und die dabei ausgelösten Aktionen. Eine Entität ist ein Geschäftsobjekt mit einem Lebenszyklus, der einen Anfang und ein Ende hat, ein Schadenfall, ein Auftrag, eine Bewilligung, ein Vertrag. BABOK verortet den Einsatz der Technik dort, wo die Entität ein komplexes Verhalten und komplexe Regeln zeigt, die dieses Verhalten steuern (§10.44): es ist dieses doppelte Kriterium, das die Kosten des Modells rechtfertigt. Das Ergebnis ist ein Zustandsdiagramm mit dem Text, der es dokumentiert, oft einer Zustandstabelle vorangestellt, die seinen Inhalt erhebt.

Die Entscheidung, die das Modell stützt, ist die der legalen Übergänge: welche Änderungen aus welchem Zustand erlaubt sind und welche nicht. Ein Schadenfall kann nicht erledigt werden, bevor er anerkannt wurde, und diese Regel, die ein Anforderungstext in Absätzen vergräbt, macht ein Zustandsmodell sichtbar und prüfbar. Es ist die entitätszentrierte Sicht. Ein Datenmodell zeigt die statische Struktur, welche Entitäten es gibt und wie sie zusammenhängen; ein Zustandsmodell zeigt das dynamische Verhalten einer von ihnen über die Zeit. Die Prozessmodellierung wiederum verfolgt den Fluss der Aktivitäten über mehrere Entitäten; das Zustandsmodell nimmt eine Entität und sammelt alles, was ihr legal widerfahren kann, über alle Prozesse hinweg, die sie berühren.

Anwendung

Wann einzusetzen

• Entität mit reichem, regelgesteuertem Lebenszyklus: viele Zustände, bedingte Übergänge, Verhalten, das vom aktuellen Status abhängt.
• Die Übergangsregeln sind die Anforderung: entscheidend ist, welche Änderungen aus welchem Zustand erlaubt und welche verboten sind.
• Statusgesteuertes Verhalten: die Ereignisse, auf die die Entität reagiert, ändern sich je nach Zustand, in dem sie sich befindet.
• Von mehreren Prozessen durchlaufenes Objekt: eine entitätszentrierte Sicht sammelt, was die Prozessmodelle verstreuen.

Wann nicht einzusetzen

• Einfache Entität, zwei oder drei Status: den Status als Attribut des Datenmodells zu erfassen genügt, ohne die Kosten eines Zustandsmodells.
• Die Frage ist der Arbeitsfluss über mehrere Entitäten: gehört zur Prozessmodellierung.
• Die Frage ist die statische Struktur und die Beziehungen der Entitäten: zum Datenmodell und seinem Entity-Relationship-Diagramm greifen.

Beschreibung

Ein Business Analyst muss nicht die gesamte Notation der Zustandsmaschinen beherrschen, um sie zu nutzen. Er muss eine Handvoll Elemente lesen können und oft die Elizitation moderieren, die sie hervorbringt. Der Rest, zusammengesetzte Zustände, parallele Regionen, Historie, gehört zur detaillierten Modellierung.

Zustände, Übergänge, Ereignisse und Wächter

Ein Zustand ist ein Status, den die Entität über die Zeit hält, während dessen sie auf eine definierte Menge von Ereignissen reagiert und Aktivitäten ausführen kann. Er wird als Rechteck mit abgerundeten Ecken gezeichnet, das einen Namen trägt. Ein Übergang ist ein einseitiger Pfeil, der von einem Quellzustand zu einem Zielzustand führt, und er wird in der Richtung gelesen, in die er zeigt. Seine Beschriftung folgt der Form Ereignis [Wächter] / Aktion: das Ereignis, das ihn auslöst, ein optionaler Wächter, eine Bedingung in Klammern, die wahr sein muss, damit der Übergang stattfindet, und eine optionale Aktion, die beim Übergang ausgeführt wird. Zwei Pseudozustände begrenzen den Zyklus: ein voll ausgefüllter schwarzer Punkt markiert den Anfangszustand, den Punkt, an dem die Entität entsteht, und ein umkreister Punkt markiert den Endzustand, an dem die Entität geschlossen und ihr Zyklus abgeschlossen ist.

Übergänge sind nicht zwingend linear. Eine Entität kann einen Zustand überspringen, zu einem früheren Zustand zurückkehren oder auf demselben Zustand eine Schleife bilden. Ein Übergang kann bedingt sein, ausgelöst durch ein Ereignis unter einem Wächter, oder automatisch, ausgelöst durch den Abschluss der Aktivitäten des Zustands oder durch den Ablauf einer Frist. Es ist diese Kombination, die dem Modell seine Präzision gibt: es sagt, was der Entität widerfahren kann, aus welchem Zustand und unter welcher Bedingung.

Die Zustandstabelle

Vor dem Zeichnen wird erhoben. Die Zustandstabelle ist die Low-Tech-Form desselben Modells: eine Zeile pro Übergang, mit dem Ausgangszustand, dem Ereignis und seinem Wächter, der Aktion und dem Zielzustand. BABOK empfiehlt sie, um die Fachexperten die Zustände und Ereignisse benennen zu lassen, bevor das Diagramm gezeichnet wird (§10.44), und sie bleibt die beste Grundlage für diesen Austausch, denn ein Experte, der vor einem Diagramm zögert, füllt bereitwillig eine Tabelle Zeile für Zeile aus.

Die Fallstricke

Der häufigste Fallstrick ist es, ein Attribut für einen Zustand zu halten. Ein Zustand ändert die Ereignisse, auf die die Entität reagiert, und die Übergänge, die legal werden, während ein Attribut nur eine Angabe ist, die sie trägt. « Hohe Priorität » oder « hoher Betrag » sind keine Zustände, sie steuern keinen Übergang. Der Test ist einfach: ändert der Wert nicht, was als Nächstes geschehen kann, ist es ein Attribut.

Die übrigen Fallstricke liest man alle am Graphen ab. Ein fehlender Übergang lässt ein Ereignis, das in einem Zustand eintreten kann, ohne definierte Antwort, und das Abgleichen jedes Zustands gegen jedes Ereignis bringt sie zum Vorschein. Ein unerreichbarer Zustand, zu dem kein Übergang führt, deutet auf tote Modellierung oder einen anderswo vergessenen Übergang, denn jeder Nicht-Anfangszustand braucht mindestens einen eingehenden Pfeil. Ein Senkenzustand, nicht final und ohne ausgehenden Übergang, fängt die Entität, die nie mehr herauskommt, während jeder Zustand ausser dem finalen einen Ausgang braucht. Den Endzustand wegzulassen verdeckt die Regeln zum Schliessen, Archivieren oder Löschen der Entität. Bleibt die Übermodellierung: eine Zustandsmaschine für eine einfache Entität zu bauen verbraucht Expertenzeit für wenig Ertrag.

KI-Überlegungen

Ein Sprachmodell leistet zwei Dienste bei dieser Technik. Der erste ist die Ableitung einer Kandidaten-Zustandsmaschine: es liest Geschäftsregeln, einen Anforderungstext oder die Protokolle eines bestehenden Systems und schlägt Zustände, Übergänge und ihre Ereignisse vor. Bei einem Altsystem, dessen Verhalten nirgends dokumentiert ist, korrigiert sich der erhaltene Entwurf schneller, als sich ein leeres Blatt füllt. Der zweite ist die Vollständigkeitsprüfung, eine geregelte Arbeit, die sich gut für die Maschine eignet: einen unerreichbaren Zustand, einen Senkenzustand ohne Ausgang, einen fehlenden Übergang für ein bekanntes Ereignis oder das Fehlen eines Endzustands zu melden.

Die Grenze ist geschäftlicher Natur. Einen Zustand von einem Attribut zu unterscheiden setzt voraus zu wissen, ob der Wert das Verhalten tatsächlich steuert, was allein das Geschäft entscheidet. Ob ein Übergang legal ist, ob ein Schadenfall direkt von Eingegangen zu Abgelehnt wechseln kann, ist eine Geschäftsregel, die der Text nicht zuverlässig liefert, und ein falscher Übergang lässt das Modell lügen. Das Sprachmodell neigt zudem zur Übermodellierung, dazu, Zustände zu erzeugen, die verkappte Attribute sind. Jeder Vorschlag der Maschine ist ein Entwurf, der den Fachexperten und dem Business Analyst vorgelegt wird, der die Unterscheidung zwischen Zustand und Attribut hält.

Beispiele

Das Konzept, das das Beispiel sichtbar macht, ist das Lesen einer Zustandsmaschine an einer einzelnen Entität: die Zustände, ein Übergang, der zugleich ein Ereignis, einen Wächter und eine Aktion trägt, ein Schritt zurück und die Anfangs- und Endpseudozustände. Der Fall ist der Lebenszyklus eines Schadenfalls bei einem Versicherer, zu einem Diagramm zusammengesetzt.

Ein einziger Übergang trägt das Wesentliche der Notation. Der Übergang von In Prüfung zu In Begutachtung ist mit Deckung bestätigt [Betrag > CHF 10'000] / Experten beauftragen beschriftet: das Ereignis ist die Bestätigung der Deckung, der Wächter in Klammern beschränkt den Übergang auf Beträge über CHF 10'000, und die Aktion beauftragt im Moment des Übergangs einen Experten. Dasselbe Ereignis führt unter dem umgekehrten Wächter [Betrag ≤ CHF 10'000] direkt zu Anerkannt: ein einziger Wächter teilt ein Ereignis in zwei Ausgänge. In Begutachtung löst sich anschliessend je nach abgegebenem Gutachten zu Anerkannt oder Abgelehnt auf. Die Rückkehr von Warten auf Unterlagen zu In Prüfung zeigt, dass ein Übergang nicht zwingend ein Fortschritt ist, denn der Schadenfall kehrt zur Prüfung zurück, sobald die Unterlagen eingegangen sind. Der ausgefüllte Punkt markiert den Eintritt des Schadenfalls in das System, und die beiden Endzweige, Erledigt und Abgelehnt, erreichen den Endzustand. Wenige Zustände und ihre Übergänge genügen, um die ganze Notation zu tragen, die ein Business Analyst lesen können muss.

Visualisierungen

Die Form trägt den Sinn und liest sich ohne Legende. Das abgerundete Rechteck sagt einen über die Zeit gehaltenen Status. Der Pfeil sagt einen legalen Übergang, und er wird in der Richtung gelesen, in die er zeigt, denn die Regel ist gerichtet. Die Beschriftung sagt das Ereignis, das den Übergang auslöst, den Wächter in Klammern, der ihn bedingt, und die beim Übergang ausgeführte Aktion. Der ausgefüllte Punkt sagt die Geburt der Entität, der umkreiste Punkt ihr Ende. Ein Leser, der diese fünf Zeichen kennt, liest ein Zustandsdiagramm ohne weitere Stütze, auch das des Schadenfalls.

Kosten

Werkzeuge

Ein Whiteboard genügt für einen ersten Entwurf, wenige Zustände und ihre Übergänge passen auf eine Fläche und werden im Stehen mit den Experten korrigiert. Die Zustandstabelle liegt in einem Tabellenkalkulationsblatt, der natürlichen Form der Elizitation vor dem Zeichnen. Allgemeine Diagramm-Werkzeuge, diagrams.net, Lucidchart oder Visio, tragen UML-Zustandsmaschinen-Schablonen und liefern ein sauberes, teilbares Diagramm, geeignet, solange es eine Diskussionsgrundlage bleibt. Spezialisierte UML-Modellierungswerkzeuge, Enterprise Architect, Visual Paradigm, StarUML oder Modelio, halten das Zustandsdiagramm als eine Sicht eines kohärenten Modells, prüfen es und verknüpfen es mit den anderen Diagrammen. Textgenerierende Werkzeuge, PlantUML oder Mermaid, beschreiben ein Zustandsdiagramm in wenigen Zeilen versionierbaren Textes, was einem neben dem Code gehaltenen Modell entspricht. Über die Dokumentation hinaus dient ein Zustandsmodell mitunter direkt als Konfiguration, denn Workflow-Engines und Software-Zustandsmaschinen führen den Lebenszyklus aus, den das Modell beschreibt.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.44 State Modelling: die Definition der Technik, die Entität mit komplexem Verhalten und komplexen Regeln, die Elemente Zustand, Übergang, Ereignis und Bedingung, die Zustandstabelle und die Grenze der Übermodellierung.
• OMG (Object Management Group), Unified Modeling Language (UML) Specification, Version 2.5.1, State Machines: die Spezifikation, welche die Notation der Zustandsmaschinen definiert, Zustände, mit Ereignis-Wächter-Aktion beschriftete Übergänge, Anfangs- und Endpseudozustände. Der normative Anker der Notation.
• David Harel, « Statecharts: A Visual Formalism for Complex Systems », Science of Computer Programming, Bd. 8, Nr. 3 (1987), S. 231-274: der grundlegende Artikel des Statechart-Formalismus, auf dem die Zustandsmaschinen von UML beruhen.