In diesem Kapitel wird die Kurzbezeichnung Methode ZA für alle Theorieelemente zur Erfassung und Darstellung von Zustandsautomaten eingeführt.

12.1 Einführung

Für die UML-Autoren sind die in diesem Abschnitt vorgestellten Zustandsautomaten (state machines) (endliche) Automaten [OMG 2003a, S. 370].

Einordnung

Um was geht’s?

Im Mittelpunkt des Geschehens steht hier jeweils ein Objekt (im Sinne der objektorientierten Theorie) mit den Zustandsübergängen die es erleben und den Zuständen, die es annehmen kann. So wie z.B. ein (Geschäfts-)Objekt Rechnung vom Zustand Neu (nach der Erstellung) zu Offen (nach Zusendung zum Kunden) und letztendlich zu Bezahlt finden kann.

Interpretiert man die Zustandsänderungen als Ausdruck von Verhalten, wie es die UML-Autoren tun, kann man wie folgt definieren:

Ein Zustandsautomat beschreibt das Verhalten eines Objektes im Zeitablauf, indem die Lebenszyklen von Objekten mit den verschiedenen möglichen Objektzuständen und den Zustandsübergängen modelliert werden [Rumbaugh, Jacobson und Booch 2005, S. 665].

Es geht also erstens nur um einzelne Objekte und zweitens nur um deren Verhalten. Insbesondere geht es nicht um die Interaktionen zwischen Objekten.

Der Lebenszyklus eines Objekts besteht aus Zuständen, in denen Objekte eine bestimmte Zeit verharren und auf Ereignisse warten [Anmerkung] . Das ist für die UML-Autoren die zentrale Vorstellung bei diesem Theorieelement und sie ist auch naheliegend – zumindest für Systeme. Ob sie auch für die Untersuchung wichtiger Aspekte von Geschäftsprozessen taugt, wird im folgenden untersucht.

Ereignisse lösen Zustands-
änderungen aus

Bei diesem Theorieelement sind somit Ereignisse von großer Bedeutung. Sie lösen die Zustandsübergänge aus und ermöglichen damit die Modellierung der dynamischen Aspekte.

Die UML-Autoren unterscheiden zwei Typen von Zustandsautomaten, die Behavioral State Machines und die Protocol State Machines. Sie werden hier mit Verhaltenszustandsautomat bzw. Protokollzustandsautomat übersetzt. Beide nutzen weitgehend dasselbe Instrumentarium, sind aber doch etwas verschieden.

Verhalten
und
Protokoll

Verhaltenszustandsautomaten

Die Verhaltenszustandsautomaten drücken das Verhalten von Teilen eines Systems aus. Es geht um die Modellierung von diskretem Verhalten durch endliche Automaten. Somit geht es auch um das Verhalten von Modellelementen, z.B. von einzelnen Instanzen. Näheres hierzu in den nächsten Abschnitten.

Verhaltens­modellierung

Protokollzustandsautomaten

Bei Protokollzustandsautomaten geht es darum, das Nutzungsprotokoll von Teilen eines Systems festzuhalten. In der Sprache der UML-Autoren: Sie modellieren die zulässigen Transitionen, die ein Classifier auslösen kann. Damit erlauben die Protokollzustandsautomaten, den Lebenszyklus von Objekten bzw. die Abfolge von Methodenaufrufen festzuhalten. Die Besonderheiten dieser Automaten sind in Abschnitt 13.4 zusammengestellt.

Protokollierung

Verhalten?

In beiden Versionen von Zustandsautomaten wird Verhalten wie folgt modelliert: Als ein Durchqueren eines Graphen von Zustandsknoten, wobei die Zustandsknoten durch eine oder mehrere Übergangskanten verbunden sind und das Durchqueren durch das Aktivieren einer Serie von Ereignissen gesteuert wird.

Verhalten =
Durchqueren eines Graphen

12.2 Grundlagen

12.2.1 Elemente

Den Kern eines Zustandsautomaten stellt also ein Objekt dar. Die Betonung liegt auf der Einzahl. Es geht tatsächlich um ein einzelnes Objekt, dessen Zustände betrachtet werden. Z.B. um einen Geldautomaten oder auch nur um die Leseeinheit eines solchen. Oder um das Geschäftsobjekt Rechnung, das im Rahmen eines Finanz- und Mahnwesens sehr unterschiedliche Zustände annehmen kann.

Objekte

Verwirrung entsteht hier manchmal, weil ein Objekt natürlich aus anderen Objekten zusammengesetzt sein kann und hier auch wieder diesbezüglich („um was geht es genau“) eine klare Festlegung getroffen werden muß. Dies zeigt schon das Beispiel Geldautomat sehr deutlich. Geldautomaten bestehen aus zahlreichen Komponenten. Jede dieser Komponenten kann ebenfalls aus Komponenten bestehen, usw. Und alle arbeiten zum Zwecke der Aufgabenerfüllung zusammen, wie es sich für ein System eben gehört.

Objekt
in Objekt
in Objekt …

Ein solches Objekt hat Zustände, die es annehmen kann. Typischerweise durchläuft es im Rahmen seiner Existenz eine ganze Reihe solcher Zustände, deren Gesamtheit hier aber auch anderswo als Lebenszyklus bezeichnet wird. Der Geldautomat ist z.B. zu Beginn, wenn wir uns ihm nähern, in einem Bereitschaftszustand (Leerlauf, Warten auf Kunde). Danach in so unterschiedlichen Zuständen wie Karte lesen, Geld auszahlen, Kontoinformationen ausgeben und hoffentlich nicht Karte einziehen.

Lebenszyklus eines Objekts

Eine Rechnung kann wie oben schon angemerkt die Zustände Neu, Offen, Bezahlt, aber auch Rückbuchbar bezahlt, (Im) Widerspruch, usw. annehmen. Vgl. hierzu die Beispiele unten.

Der Übergang von einem Zustand zu einem anderen wird als Transition bezeichnet. Dabei können von einem Zustand aus durchaus alternative weitere Zustände erreicht werden, d.h. es kann von einem bestimmten Zustand aus verschiedene Transitionen geben.

Transitionen

Ausgelöst wird eine Zustandsänderung durch ein Ereignis, das zu einem bestimmten Zeitpunkt eintritt und selbst keine Zeit in Anspruch nimmt. Welche Zustandsänderung eintritt, hängt von dem Ereignis und dem Objektzustand zum Zeitpunkt des Ereignisses ab.

Ereignisse

Eine genauere Erklärung folgt gleich mit der Vorstellung der grafischen Darstellung von Zustandsautomaten.

Grafische Darstellung

Die grafische Darstellung von Zustandsautomaten erfolgt durch Zustandsübergangsdiagramme, die im Kern aus folgenden Elementen bestehen:

• einem Startzustand
• Zuständen eines Objektes
• Transitionen (Zustandsänderungen, Zustandsübergängen)
• einem Schlusszustand oder mehreren

Implizit ist auch ein Operator dabei, wenn von einem Zustand zu mehreren anderen alternative Zustandsübergänge vorliegen (exklusives Oder).

Die Zustände werden durch Rechtecke mit abgerundeten Ecken dargestellt. Im Rechteck wird der jeweilige Zustand des Objektes angegeben. Dasselbe Objekt taucht mit unterschiedlichen Zuständen mehrfach in einem Zustandsautomat auf.

Zustände – grafisch

Die Beschriftung der Rechtecksymbole für Zustände kann unterschiedlich sein. Im einfachsten Fall steht die Bezeichnung des Zustandes in der Mitte des Rechtecks, wie in der folgenden Abbildung. Hier soll der Grundzustand eines Geldautomaten beschrieben sein.

Die Transitionen werden durch Pfeillinien zwischen je zwei Zuständen dargestellt. Das Rechteck am Pfeilanfang gibt den Zustand des Objekts vor der Transition (Zustand 1) und das am Ende des Pfeils den Zustand nach der Transition (Zustand 2) an.

Die Pfeile für die Transitionen sind beschriftet:

Ereignis
[Bedingung]
Aktion

• mit dem auslösenden Ereignis, d.h. dem Ereignis, durch das es zur Zustandsänderung kommt
• mit einer Bedingung (in eckigen Klammern) für das Eintreten des Zustandsübergangs
• mit einer Aktion, die im Zuge der Transition auszuführen ist, die also zum nächsten Zustand führt

Beispiele (Geldautomat, Geschäftsobjekt Rechnung):

• EC-Karte wurde eingesteckt [Karte lesbar] Karte lesen
• Betrag wurde angefordert [Konto gedeckt] Auszahlen
• Rechnung erstellt [Zustellung gelungen] Rechnung als offen deklarieren
• Rechnung erstellt [Zustellung gescheitert] Rechnung als nicht zustellbar deklarieren

Es müssen nicht immer alle drei Elemente angegeben werden, die Beschriftung sollte aber klarstellen, wodurch die Transition nötig wurde.

Die folgende Abbildung zeigt die grafische Darstellung von Transitionspfeilen, jeweils zusammen mit dem Ausgangs- und Schlusszustand.

Ein Zustandsübergangsdiagramm beginnt mit einem Startsymbol und endet mit einem Endesymbol (oder mit mehreren). Entsprechend befindet sich der Zustandsautomat als Ganzes im Anfangszustand (initial pseudo state) bzw. im Schlusszustand (final state). Im Diagramm geht dann vom Anfangszustand genau ein Transitionspfeil aus, beim Schlusszustand kommt mindestens einer an.

Anfang und Ende

Der Zustandsautomat als Ganzes wird i.d.R. in ein Rechteck gepackt und mit seiner Bezeichnung beschriftet. Vgl. hierzu die folgenden Beispiele.

Kommt es nicht zu einem ordnungsgemäßen Ende bei den Zustandsübergängen des Zustandsautomaten wird auch das in der grafischen Darstellung angegeben, durch die Angabe eines Ausstiegspunktes (exit point). An diesem wird durch eine Beschriftung der Ausstieg spezifiziert.

Abbruch

Weitere grafische Elemente spielen nur in der Vertiefung eine Rolle und werden dort vorgestellt.

12.2.2 Zustände

Anmerkung: Die Ausführungen dieses Abschnitts beziehen sich auf Verhaltenszustandsautomaten (vgl. zu Protokollzustandsautomaten Abschnitt 13.4).

Zumindest umgangssprachlich verbinden wir im Deutschen mit dem Begriff Zustand etwas festes, stabiles, statisches. Wenn wir vom Autoverkäufer hören müssen, dass der Gebrauchtwagen, den wir in Zahlung geben möchten, in einem schlechten Zustand sei, dann ist es so. Ebenso, wenn wir vor Arbeitsbeginn den eigenen Zustand als “topfit” oder auch “müde/matt/schlapp” feststellen müssen. Oder wenn die Rechnung in den Zustand nicht eintreibbar gerät, dann ist das nicht nur bedauerlich, sondern etwas festes.

Ist das Objekt aber zusammengesetzt aus zusammenwirkenden Elementen (also ein System), dann ist dem nicht so. Dann ist ein Zustand etwas dynamisches, etwas, was u.U. auch aufrechterhalten werden muß.

Dynamik im Zustand

Dies wird noch nicht so deutlich darin, wie die UML-Autoren einen Zustand definieren:

Ein Zustand modelliert eine Situation [Anmerkung] , in der einige (normalerweise implizite) Bedingungen stabil sind [OMG 2003a, S. 477].

Zustand, Definition

Hier kann man sich durchaus noch etwas statisches vorstellen, zumal mit „implizit“ hier Bedingungen „innerhalb“ des Zustandes gemeint sind, nicht die der „Umwelt“. Bei einer Rechnung, um im obigen Beispiel zu bleiben, wäre das auch so.

Zustand, statisch

Betrachten wir aber ein Systembeispiel, z.B. einen Geldautomaten, wird deutlich, dass die Definition auch Zustände solcher Objekte umfasst. Nehmen wir wieder einen Geldautomaten. Er beginnt mit einem Wartezustand, dem Leerlauf:

• Bereit EC-Karte zu lesen.

Nach dem Einlesen der Karte (dem Ereignis) kommt er in den Zustand

• „Nutzer identifizieren, konkret: Geheimzahl anfordern“

Usw. Der Zustandsübergang wurde also durch das Ereignis Karte eingesteckt, Karte gelesen ausgelöst und ist mit einer Aktion verbunden, dem Einlesevorgang. Dazwischen verharrt er im jeweiligen Zustand.

Anmerkung: Die Begriffe „Aktion“ und „Aktivität“ werden hier, wenn nicht ausdrücklich anders vermerkt, im umgangssprachlichen Sinn gebraucht und nicht im Sinne der Kapitel rund um Aktionen und Aktivitäten (9 und 10).

Betrachtet man obige Beispiele genauer, wird deutlich, dass ein Zustand auf einer tieferen (System-)Ebene oftmals durch aktives Handeln aufrecht erhalten werden muss. Der Zustand „Bereit EC-Karte zu lesen“ bedeutet in Wirklichkeit, dass der Geldautomat ständig die Sensoren des Kartenlesegeräts abfragt, ob eine Karte reingesteckt wurde. Ähnlich ist es mit vielen Zuständen, gerade bei Beispielen aus der Systemanalyse.

Zustand, dynamisch

Dort ist aber meist die Aktivität des Zustandes weniger verdeckt als im gerade beschriebenen Beispiel. Z.B. ist im ersten Beispiel des folgenden Abschnitts der Zustand wähleBetrag oder eingebenBetrag gleich als aktiv erkennbar.

Dass dies nicht immer so ist, zeigt wiederum das Beispiel aus dem Anwendungsbereich Mahnwesen (vgl. Abbildung unten). Ein Geschäftsobjekt Rechnung ist z.B. Neu, d.h. gerade erstellt. Da gibt es keine „Tiefenstruktur“. Auch nicht nach der Zustellung zum Kunden, wenn die Rechnung in den Zustand Offen gerät.

Aktivität im Zustand

Somit können bei Zustandsautomaten statische oder dynamische Bedingungen vorliegen. Z.B. eine statische Situation dergestalt, dass ein Objekt darauf wartet, dass ein externes Ereignis eintritt. Oder eben dynamische Bedingungen, die einen Zustand herstellen und aufrechterhalten.

Letzteres bedeutet: Das betrachtete Modellelement kommt in den Zustand, wenn die Aktivität beginnt und verlässt ihn, sobald die Aktivität vollendet ist. Z.B. Abfragen der Sensoren des Kartenlesegeräts beim Geldautomaten.

Zustand durch Aktivität

Dies erweitert das Konzept des Zustandes doch sehr stark, denn hier ist dann tatsächlich mit dem Zustand auch eine Aktivität verbunden. Vgl. dazu auch die einführenden Beispiele unten. Es verwischt aber ein wenig den Unterschied zwischen Transitionen und Zuständen. Z.B. kann damit eine Aktivität „Karte lesen“ bei einem Geldautomaten auch als Zustand definiert werden: Objekt ist im Zustand „lesend“.

Für die konkrete Modellierung bedeutet es, dass die Abgrenzung zwischen Aktivitäten innerhalb und außerhalb eines Zustandes bei der Modellierung ständig bedacht werden muss. Zumindest bei Zustandsautomaten aus dem Bereich der Systemanalyse kann dies gleichbedeutend sein mit der Frage, bis zu welcher Systemtiefe modelliert wird.

12.2.3 Einführende Beispiele

Die beiden Beispiel sind einführend und deshalb einfach gehalten. Zuerst ein Beispiel aus dem Bereich der Systemanalyse bzw. des Software Engineerings (Systembeispiel), dann eines mit Bezug zu Geschäftsprozessen (Prozessbeispiel).

Beispiel 1 – Geldautomat (Systembeispiel)

Das Objekt, um das es geht, ist ein Geldautomat (ATM, automated teller machine). Die Rechtecke mit abgerundeten Ecken repräsentieren somit die Zustände des Geldautomaten, die Pfeile die Zustandsübergänge. Die Beschriftung der Transitionen zumindest mit dem auslösenden Ereignis ist v.a. dann wichtig, wenn mehrere Pfeile von einem Zustand weggehen, wie im folgenden Beispiel. In einem solchen Fall sind die Transitionen alternativ und können daher als durch ein exklusives Oder verknüpft angesehen werden.

Objekt Geldautomat

Gleich nach dem Anfangszustand wird mit dem Zustand wähleBetrag der Zustandsautomat aktiv. Von diesem Zustand aus gibt es drei mögliche Transitionen:

Ein Zustand, drei
Zustandsübergänge
(Transitionen)

• Betrag gewählt [Wahl korrekt]. Zustand ändern in Schlusszustand (fertig)

Normalerweise ginge es hier natürlich nicht gleich in den Schlusszustand, sondern es würde zur Auszahlung weitergehen. Aber für dieses Teilsystem (LeseBetrag) ist es so richtig.

• Anderer Betrag angefordert [Wahl korrekt]. Zustand ändern in eingebenBetrag
• Abbruch angefordert [Wahl korrekt]. Ausstieg. Dies führt zum Ausstieg.

Kommt es also zu einem gültigen Auszahlungsbetrag ist der Automat mit seinen Aktivitäten am Ende und der Schlusszustand erreicht.

Schluss durch Auszahlung

Wird keiner der auf der Anzeige angeführten Beträge gewünscht (andererBetrag) geht es weiter zum Zustand eingebenBetrag. Die dritte Transition signalisiert, dass dem Nutzer auch die Möglichkeit des Abbruchs gegeben wird. Der Pfeil führt zu einem Ausstiegspunkt, der den Abbruch symbolisiert.

Der zweite Zustand, eingebenBetrag, hat ebenfalls mehrere abgehende Transitionen.

• Betrag eingegeben [Eingabe korrekt] Zustand ändern in Schlusszustand.
• Abbruch angefordert [Wahl korrekt]. Dies führt zum Ausstieg.

Entweder klappt also die Eingabe des Betrags, dann drückt der Transitionspfeil zum Schlusszustand das positives Ende aus, oder es kommt zum Abbruch, dann führt der Transitionspfeil zum Ausstiegspunkt.

Schluss durch Abbruch

Das obige Beispiel enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Einen Anfangszustand  
• Einen Schlusszustand 
• Einen Ausstiegspunkt 

Außerdem zwei Zustände mit mehreren abgehenden Transitionen.

Was an diesem Beispiel aus [OMG 2003a] auffällt, ist der dynamische Charakter der Zustände. Tatsächlich stellen sie Aktivitäten (im allgemeinen Sinn) von Systemkomponenten dar, die einen Zustand des Gesamtsystems herbeiführen und aufrechterhalten.

Zustände mit
Aktivitäten

Beispiel 2 – Rechnung (einfach) (Prozessbeispiel)

Die folgende Abbildung zeigt einige Zustände, die eine Rechnung, z.B. bei einem WebShop, annehmen kann. Das ist hier die einfache Variante, die etwas ausführlichere und realitätsnähere findet sich in Abbildung 13.5-1 und eine weitgehend vollständige in Abbildung 13.5-2.

Nach dem Anfangszustand ist die gerade erstellte Rechnung im Zustand Neue Rechnung. Von diesem Zustand aus sind zwei alternative Transitionen möglich:

Neu
Offen
Nicht zustellbar

• Rechnung ist zuzustellen [Zustellung gelungen] Rechnungsstatus offen setzen. Dies führt zum Zustand Offen.
• Rechnung ist zuzustellen [Zustellung gescheitert] Rechnungsstatus nicht zustellbar setzen. Dies führt zum Zustand Nicht zustellbar.

Auch vom Zustand Offen aus sind mehrere Zustandsübergänge möglich:

Bezahlt
Rückbuchbar
Nicht bezahlt

• Zahlung per Überweisung [Zahlung korrekt]. Damit ändert sich der Zustand in Bezahlt (Rechnung bezahlt)
• Zahlung per Lastschrift [Zahlung korrekt]. Damit ändert sich der Zustand in Rückbuchbar bezahlt.
• Drei Wochen vergangen [Zahlung nicht erfolgt]. Damit ändert sich der Zustand in Nicht bezahlt.

Der Zustand Rückbuchbar bezahlt rührt daher, weil per Lastschrift eingezogene Rechnungsbeträge innerhalb eines bestimmten Zeitraums (hier werden sechs Wochen angenommen) wieder zurückgefordert werden können. Von diesem Zustand zum Zustand Bezahlt führt dann eine Transition, die den Ablauf dieser Frist ohne Rückholung angibt:

• Sechs Wochen vergangen [keine Rückbuchung]. Damit ändert sich der Zustand in (Rechnung) Bezahlt.

Das obige Beispiel enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Einen Anfangszustand 

• Zahlreiche Transitionen 
• Drei Schlusszustände

Außerdem mehrere Zustände mit mehr als einer abgehenden Transition.

Vgl. die Varianten dieses Zustandsübergangsdiagramms in den Abbildungen 13.5-1 (mittelgroß) und 13.5-2 (umfassend).

Beispiel 3 – Kundenanfrage (Prozessbeispiel)

Dass auch ein Vorgang, bei dem man es auf den ersten Blick nicht annehmen würde, als Zustandsautomat dargestellt werden kann, zeigt das folgende Beispiel. Hier handelt es sich tatsächlich um einen Geschäftsprozess, allerdings um einen sehr einfachen rund um ein einzelnes Geschäftsobjekt.

Geschäftsprozess
als Zustandsautomat

Das Objekt, um das es geht, soll eine Kundenanfrage sein. Ganz konkret als schriftliches Objekt und damit im Geschäftsprozesssinne als Geschäftsobjekt und abstrakt als der ganze Vorgang drumherum.

Die Kundenanfrage ist im Unternehmen eingetroffen und damit im Zustand zu bearbeiten. Eine erste Prüfung (Machbarkeitsprüfung) kann zu drei Ergebnissen und damit zu drei neuen denkbaren Zuständen führen:

Anfrage machbar?

• Anfrage eingetroffen [Machbarkeit bejaht] Anfrage bearbeiten
• Anfrage eingetroffen [Machbarkeit verneint] Anfrage absagen
• Anfrage eingetroffen [Rückfragen notwendig] rückfragen (Anfrage ist im Zustand Rückfragen)

Das “Objekt” Kundenanfrage gerät dann in den jeweiligen Zustand: Rückfragen, in Arbeit oder Anfrage abgesagt. Vom Zustand Anfrage abgesagt geht es dann gleich weiter zum Schlusszustand.

Vom Zustand in Arbeit aus sind zwei Zustandsübergänge denkbar:

Kapazität vorhanden?

• Produktionskapazität ist zu prüfen [Kapazität reicht] Kapazität prüfen
• Produktionskapazität ist zu prüfen [Kapazität reicht nicht] Anfrage absagen

Vom Zustand Produktionskapazität geprüft aus sind ebenfalls zwei Transitionen möglich:

Material vorhanden?

• Materialbestand ist zu prüfen [Materialbestand reicht] Neuen Zustand anlegen: Materialbestand geprüft
• Materialbestand ist zu prüfen [Materialbestand reicht nicht] Anfrage absagen

Vom Zustand Materialbestand geprüft aus gibt es (hier) eine Transition:

• Anfrage ist zuzusagen [Prüfungen erfolgreich] Anfrage zusagen

Auf die Erfassung eines eventuellen Scheiterns an dieser Stelle wird verzichtet. Damit ist die Kundenanfrage im Zustand zugesagt, beim positiven Ergebnis also, und es folgt der Schlusszustand.

Das Zustandsübergangsdiagramm macht auch deutlich, wann der Zustand Anfrage abgesagt eintritt:

• Falls die Produktionskapazität nicht reicht
• Falls der Materialbestand nicht reicht
• Falls die Machbarkeit gleich zu Beginn verneint wurde

Das obige Beispiel enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Einen Anfangszustand
• Zahlreiche Transitionen
• Einen Schlusszustand

Außerdem mehrere Zustände mit mehr als einer abgehenden Transition.

Das obige Beispiel stellt einen reinen Ablauf dar, wie es bei Geschäftsprozessen normalerweise der Fall ist, was die Formulierung der Übergänge etwas schwierig macht, insbesondere was die auszuführende Aktion angeht.

Im Gegensatz hierzu geht es bei Systemen eher um das Zusammenspiel von Komponenten, innerhalb derer allerdings oft auch Abläufe bzw. Durchgänge vorliegen.

Soweit die Grundstruktur von Zustandsautomaten und Zustandsübergangsdiagrammen. Im folgenden wird diese nun schrittweise erweitert und vertieft.

12.3 Vertiefung

12.3.1 Strukturierte Knoten

Ausgehend von der grundsätzlichen Definition (“Ein Zustandsautomat ist ein Graph …”) und der Tatsache, dass Graphen Knoten haben, können die Zustände in Zustandsübergangsdiagrammen als Knoten bezeichnet werden.

Knoten

Dieser Begriff ist notwendig, weil es a) verschiedene andere Knoten in Zustandsautomaten gibt und b) ein Zustand hier nicht nur ein einfacher Zustand, sondern – wie oben schon gezeigt – ein tief strukturiertes Gebilde sein kann.

Folgende Zustandstypen werden in der UML unterschieden:

Zustandstypen

• einfacher Zustand (simple state)
• zusammengesetzter Zustand (composite state), mit den Untertypen einfacher zusammengesetzter Zustand (simple composite state) und orthogonaler Zustand (orthogonal state)
• Zustand, der einen Zustandsautomaten enthält (submachine state)

Regionen

Liegt eine Untergliederung eines Zustandes oder Zustandsautomaten vor, nennt man die einzelnen Bereiche Regionen. Sie enthalten ebenfalls Zustände und Transitionen. Der Zustand insgesamt wird durch die Bildung von Regionen zu einem zusammengesetzten Zustand (composite state).

Die Regionen werden auch als „orthogonal part“ bezeichnet. Der Begriff „orthogonal“ bedeutet hier, dass jede Region eine Menge von Knoten und Transitionen hat, die sich gegenseitig nicht überschneiden, die also voneinander unabhängig sind.

Orthogonalität

Die Aufteilung eines Zustandes oder eines Zustandsautomaten in Regionen wird grafisch durch gestrichelte Linien dargestellt. Vgl. die folgende Abbildung. Jede Region kann einen Namen haben und enthält die verschachtelten nicht überlappenden Zustände und die Übergänge zwischen diesen.

Grafische Darstellung von Regionen

Der Bereich mit der Bezeichnung des gesamten Zustandes wird, wie in der folgenden Abbildung gezeigt, an das umschließende Rechteck angefügt oder in einem eigenen Bereich eingefügt, wie es das nächste Beispiel zeigt.

Jeder Zustand, der sich in einer Region eines zusammengesetzten Zustandes befindet, wird Subzustand (substate) dieses zusammengesetzten Zustandes genannt. Er wird direkter Subzustand (direct substate) genannt, wenn er in keinem anderen Zustand enthalten ist, ansonsten indirekter Subzustand (indirect substate).

Subzustände,
direkt und indirekt

Vgl. für Zustände mit Regionen die Beispiele in den Abbildungen 13.3-2, 13.3-5 und 13.3-14.

Beispiele

Einfacher Zustand

Ein einfacher Zustand hat im Gegensatz zu obigem keine Subzustände, d.h. er hat keine Regionen und keinen untergeordneten Zustandsautomaten (vgl. unten).

Der dritte Zustandstyp, der oben aufgelistet wurde, Zustand der einen Zustandsautomaten enthält (submachine state), wird unten erläutert.

Schlusszustände – auch in Regionen

Bei der Vorstellung der Grundlagen wurde das Element Schlusszustand bereits eingeführt. Hier kann es nun vertieft betrachtet werden.

Bei einem Schlusszustand handelt es sich um eine spezielle Art von Zustand, dessen Eintreten bedeutet, dass die übergeordnete (ihn enthaltende) Region abgeschlossen ist, d.h. dass die Abschlussbedingung erfüllt ist.

Falls die übergeordnete Region direkt in einem Zustandsautomaten enthalten ist und dessen andere Regionen ebenfalls abgeschlossen sind, dann bedeutet es, dass der ganze Zustandsautomat abgeschlossen ist.

Betrachten wir dazu das folgende Beispiel. Es handelt sich um einen Auszug von Abbildung 13.3-14, die in Anlehnung an [OMG 2003a, S. 486, Figure 386] entstand. Der Zustand – Studieren – umfasst drei Regionen mit jeweils eigenen Zuständen und Transitionen. Wenn in allen drei Regionen von Studieren jeweils der Schlusszustand erreicht ist, ist auch der im Zustand enthaltene Zustandsautomat (dazu gleich unten mehr) beendet.

Das obige Beispiel enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Mehrere Regionen
• Zahlreiche Subzustände
• Mehrere Schlusszustände in Regionen  
• Mehrere Anfangszustände in Regionen

Es handelt sich somit um einen zusammengesetzten Zustand.

Für einen solchen Schlusszustand gelten folgende Bedingungen. Er hat …

• keine wegführenden Transitionen
• keine Regionen
• keine Verweise auf einen untergeordneten Automaten
• keine Anfangsaktivität (vgl. unten)
• keine Schlussaktivität (vgl. unten)
• keine Zustandsaktivität (vgl. unten)

Die grafische Darstellung eines Schlusszustandes wurde oben schon vorgestellt: ein Kreis, der einen kleineren schwarz eingefärbten Kreis umgibt. Die Transition zum Schlusszustand wird nicht beschriftet.

12.3.2 Pseudozustände

Anmerkung: Pseudozustände gibt es nur in Verhaltenszustandsautomaten.

Mit Pseudozustand bezeichnen die UML-Autoren verschiedene Typen von Knoten in Graphen von Zustandsautomaten. Es sind keine Zustände, sie werden aber trotzdem in der Modellierung benötigt. Typischerweise werden sie benutzt, um Transitionen in Beziehung zu setzen. Zum Beispiel, indem eine einzelne Transition, die zu einer Gabelung (fork vertex) führt, mit einer Menge von Transitionen kombiniert wird, die von der Gabelung wegführen. Damit erhält man eine Verbundtransition (vgl. Abschnitt 13.3-8), die zu einer Menge von voneinander unabhängigen Zielzuständen führt.

Zustände verknüpfen

Folgende Pseudozustände gibt es:

• Initialknoten (initial vertex)
• Beenden-Knoten (terminate)
• deepHistory-Knoten (history vertex)
• shallowHistory-Knoten (history vertex)
• Verknüpfer (join vertex)
• Gabelung (fork vertex)
• Verbindungsknoten (junction vertex)
• Auswahlknoten (choice vertex)
• Einstiegspunkt (entry point)
• Ausstiegspunkt (exit point)

Initialknoten

Ein Initialknoten stellt einen voreingestellten Knoten dar, von dem genau eine Transition zum voreingestellten Standardzustand eines zusammengesetzten Zustandes führt. In einer Region kann höchstens ein solcher Initialknoten sein.

Anfangszustand

Ein Initialknoten wird als kleiner schwarz eingefärbter Kreis dargestellt. Zur grafischen Darstellung vgl. die folgenden Beispiele.

deepHistory-Pseudozustand

Ein Pseudozustand des Typs deepHistory repräsentiert die letzte aktive Konfiguration des zusammengesetzten Zustandes, die diesen Pseudozustand direkt enthält (direkter Subzustand)

Geschichte 1 – tief

. Zum Beispiel die Zustandskonfiguration, die aktiv war, als der zusammengesetzte Zustand zuletzt verlassen wurde [OMG 2003a, S. 470].

Hier spielt also die zeitliche Dimension eine Rolle. Es geht darum, eine bestimmte Zustandskonfiguration festzuhalten und verfügbar zu machen.

Ein zusammengesetzter Zustand kann höchstens einen solchen deepHistory-Knoten haben und höchstens eine Transition darf zu ihm führen. Diese Transition wird benutzt, wenn der zusammengesetzte Zustand nie vorher aktiv war.

Ein Pseudozustand des Typs deepHistory wird durch einen Kreis dargestellt, in dem sich die Zeichenfolge H* befindet. Er hat Gültigkeit für die Region des Zustandes, in der er enthalten ist.

Grafische Darstellung

Stellen wir uns vor, der Geldautomat führt, nachdem der Kunde seine EC-Karte eingesteckt hatte, die Kontoabfrage durch. Mitten in dieser kommt es zu einem Stromausfall. Wenn dann im Pseudozustand festgehalten ist, in welchem Zustand die einzelnen Teilsysteme waren, kann bei einem Neustart die alte Konfiguration wiederhergestellt werden.

Beispiel

Die UML-Autoren betonen noch, dass in der neuesten Fassung der UML der enthaltende Zustand nicht verlassen werden muss, um deepHistory zu definieren. Dies bedeutet, dass deepHistory Ziel von Transitionen von innerhalb des enthaltenden Zustandes sein kann und nicht nur von Zuständen von außerhalb.

shallowHistory-Pseudozustand

Ein Pseudozustand des Typs shallowHistory repräsentiert den letzten aktiven Subzustand des Zustandes, der den Pseudozustand enthält, aber nicht die Subzustände dieses Subzustandes.

Geschichte 2 – flach

Nehmen wir wieder das obige Beispiel eines Geldautomaten und den Stromausfall während der Kontoabfrage. Wäre ein shallowHistory – Knoten vorhanden, dann würde der Zustand des Lesegeräts festgehalten, nicht aber die Zustände seiner Komponenten.

Beispiel

Ein zusammengesetzter Zustand kann höchstens einen solchen Knoten haben. Eine Transition zu dem shallowHistory-Knoten ist gleichbedeutend mit einer Transition, die zu dem letzten aktiven Subzustand eines Zustandes führt.

Ein Pseudozustand des Typs shallowHistory wird durch einen Kreis dargestellt, in dem sich der Buchstabe H befindet. Er hat Gültigkeit für die Region des Zustandes, in der er enthalten ist.

Grafische Darstellung

Verknüpfer

Verknüpfer (join vertices) dienen dazu, mehrere Transitionen zu vereinigen, die von Knoten aus verschiedenen orthogonalen Regionen stammen (eine UND-Verknüpfung der Transitionen). Die Transitionen, die zu einem solchen Knoten führen, dürfen keine Wächter oder Trigger haben. Zur grafischen Darstellung vgl. Abbildung 13.3-5.

Verschmelzung

Gabelung

Gabelungen (fork vertices) erlauben es, eine ankommende Transition in zwei oder mehr Transitionen aufzuteilen, die bei orthogonalen Zielknoten enden. Mit orthogonalen Knoten sind hier solche gemeint, die sich in verschiedenen Regionen eines zusammengesetzten Zustandes befinden.

Gabelung

Das bedeutet, dass es einen Zustandsübergang von einem Zustand zu mehreren gibt (eine UND-Verzweigung der Transitionen), was in den Grundlagen (vgl. oben) nicht vorgesehen ist. Ebenso umgekehrt mit den Verknüpfern: Von mehreren Zuständen gibt es einen Zustandsübergang zu genau einem. Auch dies gibt es in den Grundlagen nicht.

Die Transitionen, die von einer Gabelung weggehen, dürfen keine Wächter oder Trigger haben. Vgl. die folgende Abbildung.

Die Einführung dieser Pseudoknoten Gabelung und Verknüpfer ist nötig, weil ein einfaches Anlegen der wegführenden Transitionen an den Zustand mit der Standardsituation verwechselt würde, bei der dann entweder der eine oder der andere Zustandsübergang aktiv würde (exklusives Oder zwischen den Transitionen). Dasselbe gilt für die Verknüpfer.

Die grafische Darstellung von Gabelungen und Verknüpfern ist wie in Kapitel 10 bei den Aktivitäten gezeigt: Ein Balken, zu dem eine Transition hinführt und mehrere weg (Gabelung) oder umgekehrt (Verknüpfer).

Grafische Darstellung

Die folgende Abbildung enthält einige der oben eingeführten Elemente. Von einem Zustand (Setup) erfolgen gleichzeitig Transitionen zu A1 und B1. Dies wird durch die Gabelung erfasst. Von den zwei Zuständen A2 und B2 geht es zu einem einzigen Zustand Cleanup weiter. Dies wird durch den Verknüpfer erfasst.

Von einem Zustand zu zweien
und von zweien zu einem.

Die Bezeichnung des Zustandes ist hier, wie oben schon für Regionen eingeführt, an der oberen Kante in einem Rechteck angegeben. Alle Varianten zur grafischen Darstellung von Zuständen sind in Abschnitt 13.3.6 zusammengefasst.

Das obige Beispiel enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Eine Gabelung (fork) auf der linken Seite

• Zwei orthogonale Regionen
• Einen Verknüpfer (join) auf der rechten Seite

Außerdem zeigt es den Zustandsübergang von einem Zustand (Setup) zu zweien (A1, B1) und von zweien (A2, B2) zu einem (Cleanup).

Verbindungsknoten

Verbindungsknoten (junction vertices) sind semantikfreie Knoten, die benutzt werden, um mehrere Transitionen zu verketten. Sie werden benutzt, um Pfade mit Verbundtransitionen (vgl. Abschnitt 13.3.-8) zwischen Zuständen zu erstellen.

Semantikfreie
Verbindungsknoten

Zum Beispiel kann ein Verbindungsknoten benutzt werden, um mehrere ankommende Transitionen in eine einzige wegführende Transition zusammenzuführen. Umgekehrt können sie auch benutzt werden, um eine ankommende Transition in mehrere wegführende aufzusplitten, die unterschiedliche Wächter-Bedingungen haben.

Im letztgenannten Fall sind die wegführenden Transitionen, deren Wächter-Bedingungen FALSE ergeben, abgeschaltet. Ein vordefinierter Wächter , der ELSE genannt wird, kann für höchstens eine wegführende Transition definiert werden. Diese Transition wird aktiv, falls alle anderen Wächter der anderen Transitionen nicht gültig werden.

Else-Bedingung

Durch Verbindungspunkte wird ein sog. statisch bedingter Zweig (static conditional branch) realisiert. Diese unterscheiden sich von dynamisch bedingten Zweigen, die durch Auswahlknoten (choice vertices) realisiert werden. Vgl. den nächsten Abschnitt.

Ein Verbindungsknoten wird durch einen kleinen schwarzen Kreis dargestellt, wie in der folgenden  Abbildung gezeigt.

Grafische Darstellung

Auswahlknoten

Auswahlknoten (choice vertices) führen zu einer dynamischen Überprüfung der Wächter der Trigger der wegführenden Transitionen. Dadurch wird ein dynamisch bedingter Zweig (dynamic conditional branch) realisiert. Er erlaubt das Aufteilen von Transitionen in mehrere wegführende Pfade so, dass die Entscheidung, welcher Pfad genommen werden soll, eine Funktion des Ergebnisses früherer Aktionen sein kann, die im selben Schritt ausgeführt wurden. In dieser letztgenannten Eigenschaft steckt das Motiv für die Wahl der Bezeichnung dynamisch bedingter Zweig.

Dynamische Überprüfung

Falls mehr als ein Wächter wahr ergibt, wird ein beliebiger genommen. Falls keiner wahr ergibt, ist das Modell fehlerhaft. Um dies zu vermeiden wird empfohlen, bei jedem Auswahlknoten eine wegführende Else-Transition zu definieren.

Ein Auswahlknoten wird als rautenförmiges Symbol dargestellt, zu dem eine Transition führt und von dem mehrere weggehen.

Grafische Darstellung

Angenommen, alle Wächter mit Triggern von Transitionen die von einem Auswahlknoten wegführen, sind binäre Ausdrücke mit einem gemeinsamen linken Operanden, dann kann die Darstellung vereinfacht werden. Dann kommt der linke Operand in das rautenförmige Symbol und der jeweilige Rest des Wächter-Ausdrucks auf die wegführende Transition.

Alternative für die grafische Darstellung

Beenden-Knoten

Das Erreichen eines Pseudozustandes vom Typ Beenden (terminate) bedeutet, dass die Ausführung des Zustandsautomaten beendet wird. Ein solcher Pseudozustand wird als Kreuz dargestellt.

Der Pseudozustand Ausstiegspunkt wird am Ende des nächsten Abschnitts erläutert.

12.3.3 Zustandsautomaten im Zustand

Anmerkung: Die Ausführungen dieses Abschnitts betreffen nur die Verhaltenszustandsautomaten.

Oben wurde schon gezeigt, dass Zustände nicht einfach Zustände sind (im umgangssprachlichen Sinn), sondern dass sie Tätigkeiten bzw. Tätigkeitsfolgen enthalten können, die den jeweiligen Zustand realisieren. In diesem Abschnitt gehen wir nun noch einen Schritt weiter und betrachten ein Konstrukt, das erlaubt, ganze Zustandsautomaten in einen Zustand einzubetten.

Automat im Zustand

Es geht also um verschachtelte Strukturen. Genauer, um die Verschachtelung von Tätigkeitsfolgen, nicht nur in zwei sondern in beliebig vielen Ebenen. Die Motivation dafür ist klar: Systeme enthalten nun mal Systeme und dies muss auch modelliert werden können.

System
im System
im System ...

Dieses Enthaltensein wird dann hier über die Zustandsautomaten modelliert. Das zentrale Instrument dabei ist, in einem Zustand eines Zustandsautomaten einen anderen (untergeordneten) Zustandsautomaten zu platzieren. So wie im untenstehenden Beispiel im Zustand LeseBetrag:LeseBetragSM der Zustandsautomat LeseBetragSM enthalten ist (Abbildungen 13.3-10 und 13.3-11). Damit sind dann bereits die ersten zwei Ebenen realisiert. Setzt man dasselbe auch mit dem eingebetteten Zustandsautomaten (auch er hat in einem Zustand wieder einen Zustandsautomaten) fort, ist die dritte Ebene realisiert. Usw.

Automat
im Automat
im Automat ...

Eine Schwierigkeit hierbei stellt die Verknüpfung dar: Wie werden die beiden Zustandsautomaten, der auf der jeweils oberen Ebene und der untergeordnete, miteinander verknüpft? Wie werden die Ergebnisse des im Zustand eingebetteten Zustandsautomaten an den Zustand übergeben, so dass dieser damit mit seinen anderen Zuständen interagieren kann?

Verknüpfung über Ebenen

Da die Erfahrung zeigt, dass dieses Thema abstrakt nicht ganz einfach zu verstehen ist, werden die folgenden Ausführungen auch mit einem anschaulichen Beispiel in den nächsten zwei Abbildungen erläutert.

Beispiel – erste Abbildung

Zuerst ein einfacher Zustandsautomat (LeseBetragSM). Er wurde schon oben als einführendes Beispiel verwendet (vgl. die Beschreibung dort). Hier spielt er nun aber eine besondere Rolle, weil er in einem Zustand des nächsten Zustandsautomaten wieder auftritt. Dies deutet auch das Anhängsel SM (submachine) an die Bezeichnung an.

LeseBetragSM

Für die Betrachtung der Verschachtelung unten soll hier geklärt werden, wie dieser Zustandsautomat beendet werden kann. Zum einen, sozusagen erfolgreich, durch den Schlusszustand, zum anderen durch den Ausstiegspunkt, der benötigt wird, falls es zu einem Abbruch kommt.

Das Beispiel der nächsten Abbildung zeigt den Zustandsautomaten Geldautomat. Dieser enthält fünf Zustände:

Zustandsautomat
mit einem Zustand, der einen
Zustandsautomaten
enthält

• PrüfeKarte
• LeseBetrag:LeseBetragSM
• PrüfeTransaktion
• FreigebenKarte

Der Zustand LeseBetrag:LeseBetragSM ist nun genau so einer, um den es hier geht: Er verweist auf einen Zustandsautomaten und zwar auf den der vorigen Abbildung mit der Bezeichnung LeseBetragSM.

LeseBetrag:Lese­BetragSM

Insgesamt beschreibt dieser Zustandsautomat einige Aspekte von Geldautomaten. Der Initial-Pseudozustand führt zum ersten Zustand, PrüfeKarte. Ergab die Prüfung, dass die Karte in Ordnung ist, gibt es einen Zustandsübergang zum Zustand LeseBetrag:LeseBetragSM, in dem der Einlesevorgang modelliert ist, der also einen eigenen Zustandsautomaten enthält. Zu diesem unten mehr. Von diesem aus gibt es zwei mögliche Transitionen, die zum Abbruch oder zur Prüfung der Transaktion führen. Ein Abbruch oder die Prüfung der Transaktion führen zum Zustand FreigebenKarte.

Beschreibung

Beispiel – zweite Abbildung

Das obige Beispiel enthält u.a. folgende Komponenten:

• Mehrere Zustände

• Mehrere Transitionen
• Einen Zustandsautomaten im Zustand  

Außerdem einen Ausstiegspunkt am Zustand.

In diesem Abschnitt wird es begrifflich etwas „anstrengend“. Die US-Amerikaner können leichter Substantive mit tief verschachtelter Semantik bilden als wir. So können sie, von submachine ausgehend, die Begriffe submachine state, submachine state machine und submachine composite state machine bilden.

Anmerkung zur Begrifflichkeit

Im Deutschen würde sich eine Übersetzung in Substantive merkwürdig anhören: Subzustandsautomat-Zustandsautomat.

Deshalb wurde für die komplexen Begriffe eine „beschreibende“ Übersetzung gewählt:

• submachine = untergeordneter Zustandsautomat
• submachine state = Zustand eines untergeordneten Zustandsautomaten
• submachine state machine = untergeordneter Automat eines Zustandsautomaten oder auch Subautomat eines Zustandsautomaten

Außerdem wird hier öfters auf die Originalbezeichnung verwiesen.

Doch nun zurück zum Thema dieses Abschnitts, der Einbettung von Zustandsautomaten (die dann quasi untergeordnet sind) in Zustände.

Hier enthält der Zustandsautomat Geldautomat einen Zustand, LeseBetrag, der selbst wieder einen Zustandsautomaten enthält: LeseBetragSM. Die Schreibweise ist wie folgt: Zuerst die Bezeichnung des Zustandes, dann – nach einem Doppelpunkt – die Bezeichnung des eingebetteten Zustandsautomaten:

<Zustandsbezeichnung> : <Bezeichnung Zustandsautomat>

Im obigen Beispiel also LeseBetrag:LeseBetragSM. Auf diese Weise enthält also ein Zustand einen Zustandsautomaten. So sehen es die UML-Autoren, wenn sie von submachine state und von submachine state machine sprechen:

Zustand, der einen Zustandsautomaten enthält

“A submachine state specifies the insertion of the specification of a submachine state machine.” [OMG 2003a, S. 478]

Ein Zustand, der einen Zustandsautomaten enthält (submachine state), legt somit fest, wie der untergeordnete Zustandsautomat in den übergeordneten eingefügt ist.

Der Zustandsautomat, der den Zustand mit dem untergeordneten Zustandsautomaten (submachine state) enthält, wird der enthaltende Zustandsautomat  genannt. Hier im Beispiel ist dies Geldautomat.

Enthaltender
Zustandsautomat

Derselbe Zustandsautomat kann mehr als einmal untergeordneter Zustandsautomat (submachine) sein. Im Beispiel: LeseBetragSM könnte also mehr als einmal vorkommen.

Verknüpfung von übergeordnetem und untergeordnetem Zustands­automat

Verschachtelt man auf diese Weise Zustände, muss deren Verknüpfung geklärt werden. Kommt der eingebettete (untergeordnete) Zustandsautomat zu seinem „normalen“ Abschluss, muss dies „nach oben“ deutlich werden, kommt er zu einem anderen, z.B. zu einem Abbruch, ebenfalls. Und dies alles ist in vollem Umfang zu leisten, also auch bei mehreren Ebenen.

Der Standardweg vom eingebetteten Zustandsautomat (im Beispiel: LeseBetragSM) über den Zustand im übergeordneten Automat (LeseBetrag:LeseBetragSM) zum übergeordneten Zustandsautomaten (Geldautomat) wird einfach grafisch dadurch ausgedrückt, dass der Transitionspfeil an der Grenzlinie des Zustands mit dem untergeordnten Zustandsautomat (im Beispiel: LeseBetrag:LeseBetragSM in Geldautomat) endet, bzw. von diesem ausgeht, ganz ohne Verknüpfungspunkte.

Normale Beendigung – Standardweg

Methodisch bedeutet dies, dass der Initialknoten des eingebetteten Zustandsautomaten aktiv wird. Durch diesen wird der voreingestellte Standardzustand (im Beispiel: wähleBetrag) realisiert.

Genauso wird die „normale“ Beendigung dargestellt. Wird im eingebetteten Zustand der Schlusszustand erreicht, aktiviert dies im übergeordneten Zustandsautomaten die Transition, die von dem Zustand abgeht, der den Automat enthält. Klingt kompliziert, ist es aber nicht, wie das Beispiel zeigt:

Wird in LeseBetragSM der Schlusszustand erreicht, ist in Geldautomat der Zustand LeseBetrag:LeseBetragSM abgearbeitet und die von ihm abgehende („normale“) Transition (zu PrüfeTransaktion) wird aktiviert.

Bei nicht normaler Beendigung erfolgt die Wegweisung durch grafische Elemente (Verknüpfungspunkte), die Einstiegs- und Ausstiegspunkte genannt werden.

Nicht normale Beendigung

Pseudozustand Einstiegspunkt

Ein Pseudozustand vom Typ Einstiegspunkt (entry point) stellt einen Zugang in den Zustandsautomaten dar. In jeder Region des Zustandsautomaten gibt es eine einzige Transition zu einem solchen Knoten innerhalb derselben Region.

Zugang in den Automaten

Ein Einstiegspunkt wird als kleiner Kreis auf der Grenzlinie der Abbildung dargestellt. Die Bezeichnung wird angefügt.

Grafische Darstellung

Pseudozustand Ausstiegspunkt

Ein Beispiel für einen Ausstiegspunkt wurde oben schon eingeführt (vgl. Abbildung 13.3-10). Ein Ausstiegspunkt signalisiert die Beendigung eines Zustandsautomaten. Weitere Erläuterungen folgen hier unten am Beispiel.

Ausgang

Er wird als kleiner Kreis mit einem Kreuz dargestellt und auf der Grenzlinie der Abbildung platziert. Die Bezeichnung wird angefügt.

Grafische Darstellung

Doch nun zurück zur nicht normalen Beendigung und deren Modellierung. Dafür gilt: Wird ein Ausstiegspunkt in einer Region des Zustandsautomaten erreicht, die sich auf einen Zustand eines untergeordneten Zustandsautomaten bezieht, bedeutet dies, dass dieser Zustand verlassen wird und dass die Transition, die diesen Ausstiegspunkt als Quelle in dem übergeordneten Zustandsautomaten hat, ausgeführt wird.

Im Beispiel: Der Zustandsautomat LeseBetragSM hat einen Ausstiegspunkt. Wird dieser erreicht, wird im übergeordneten Zustandsautomat Geldautomat (Abbildung 13.3-11) der Zustand LeseBetrag:LeseBetragSM verlassen (über den dortigen Ausstiegspunkt) und die Transition, die vom Ausstiegspunkt ausgeht (Abbruch angefordert …), ausgeführt.

Der eingebettete Zustand (im Beispiel LeseBetragSM) enthält also a) mindestens einen Zustand, der einen entsprechenden Ausgang hat (im Beispiel eingebenBetrag), b) mindestens eine Transition zum Ausstiegspunkt und c) den Ausstiegspunkt selbst. Letzterer wird auf die Grenzlinie platziert.

Das grafische Element für den Zustand eines untergeordneten Zustandsautomaten kann grundsätzlich auch mehrere solcher Aus- bzw. Einstiegspunkte aufweisen.

Dieses Konstrukt, Zustände mit untergeordneten Zustandsautomaten (submachine states), bei denen durch Einstiegs- und Ausstiegspunkte die Verknüpfung erfolgt, ist eingeführt worden, um eine Skalierbarkeit von Zustandsautomaten mit untergeordneten Zustandsautomaten sicherzustellen und um Kapselung (im Sinne der objektorientierten Theorie) zu ermöglichen.

Zweck:

Damit (durch die – evtl. rekursive – Abspaltung bestimmter Tätigkeitsfolgen) kann somit die Wiederverwendbarkeit von Modellfragmenten bzw. von Systemkoponenten (nach der Realisierung) gesichert werden.

Natürlich spiegelt dieses Konstrukt aber auch die Tatsache wider, dass Systeme andere Systeme enthalten, durchaus auf mehreren Ebenen, was hiermit auf einfache Weise modelliert werden kann.

12.3.4 Transitionen zu Zuständen

Transitionen wurden im Grundlagenteil nur bzgl. einfacher Zustände vorgestellt. Nun, nachdem die tiefe mögliche Strukturierung von Zuständen und Zustandsautomaten eingeführt wurde, können auch die Transitionen vertieft betrachtet werden.

Zu einem eingebetteten/enthaltenen Zustand

Eine Transition zu einem Zustand, der einen Zustandsautomaten enthält (einbettender Zustand) ist gleichbedeutend mit einer Transition zum Initialknoten in jeder Region desselbigen. In der folgenden Abbildung 13.3-14 bedeutet somit der Initialknoten links oben und die von ihm ausgehende Transition zum eingebetteten Zustand, dass alle drei Initialknoten der Regionen aktiv werden.

Zu einem Schlusszustand

Eine Transition zu einem Schlusszustand stellt den Abschluss der Aktivität in der eingebetteten Region dar.

Der Abschluss der Aktivität in allen orthogonalen Regionen stellt den Abschluss der Aktivität im gesamten eingebetteten Zustand dar und löst ein Abschlussereignis bezüglich dieses eingebetteten Zustandes aus. Der Abschluss der am weitesten oben angesiedelten Regionen eines Zustandes bedeutet seine Beendigung.

Abschluss in
verschachtelten
Strukturen

Im folgenden Beispiel von Abbildung 13.3-14 hat dies folgende Bedeutung: Das Erreichen der Schlusszustände in allen drei Regionen führt zur Beendigung des gesamten eingebetten Zustandes, was die Transition zum Zustand Bestanden auslöst.

Beispiel Leistungserbringung

Im folgenden Beispiel ist der Zustandsautomat Studieren eingebettet in den Zustand Leistungserbringung. Außerdem enthält das Beispiel viele der in den letzten Abschnitten besprochenen Elemente und Konstrukte.

Zustand im Zustand

Der eingebettete Zustand mit den Regionen kann auf zwei verschiedenen Arten enden. Entweder positiv, wie oben beschrieben, dadurch dass alle drei Schlusszustände erreicht werden. Dann greift die Transition zum Zustand Bestanden.

Oder durch Nichtbestehen der Abschlussprüfung. Tritt dies ein, wird die Transition von Abschlussprüfung nach Durchgefallen ausgelöst.

Das obige Beispiel enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Einen einbettenden Zustand
• Einen Zustand mit Regionen
• Einen Zustandsautomaten im Zustand
• Mehrere orthogonale Regionen in einem Subzustand
• Einen Initialknoten (Anfangszustand), der den eingebetteten Zustand aktiviert 
• Schlusszustände in Regionen   
• Initialknoten in Regionen 

Außerdem ein Beispiel für die Beendigung eines Subzustandes.

Dieses Beispiel macht den dynamischen Charakter von Zuständen, wie er oben eingeführt wurde, besonders deutlich. Die Zustände sehen aus wie Aktivitäten. “Abschlussprüfung” ist dann hier in einem Zustandsautomat ein Zustand, etwas in dem man sich befindet, obwohl es tatsächlich (auch) einen Vorgang darstellt.

Reflektion

Damit ist die Unterscheidung von Aktivitätsbeschreibung und Zustandsbeschreibung teilweise aufgehoben.

12.3.5 Semantik von Zuständen

Ein bestimmter Zustand ist während der Ausführung des Zustandsautomaten aktiv oder inaktiv. Er wird aktiv, wenn er als Ergebnis einer Transition eintritt und er wird inaktiv, wenn er durch eine Transition „verlassen“ wird.

Aktiv oder inaktiv

Ein Zustand kann auch als Ergebnis ein und derselben Transition beendet werden oder eintreten. In einem solchen Fall wird die Transition Selbsttransition (self transition) genannt (vgl. hierzu das Beispiel in Abbildung 13.3-17).

Transition auf sich selbst

Für jeden Zustand gibt es eine Anfangsaktivität (entry activity) und eine Schlussaktivität (exit activity). Immer wenn ein Zustand eintritt, führt er seine Anfangsaktivität aus, vor allem anderen. Umgekehrt führt er, wenn er verlassen wird, als letzten Schritt seine Schlussaktivität aus.

Anfangs- und Schlussaktivität

Anmerkung: Der Begriff „Aktivität“ wird hier im allgemeinen fachsprachlichen Sinn verwendet, nicht im Sinn von Kapitel 10.

Zwischen der Anfangs- und der Schlussaktivität muss sich ja auch noch etwas tun. Dieser Teil der Aktivität eines Zustandes wird Zustandsaktivität genannt (do activity). Sie wird ausgeführt, während der Zustandsautomat im jeweiligen Zustand ist und startet, wenn der Zustand eintritt, nach der Anfangsaktivität.

Zustandsaktivität

Falls die Aktivität fertig wird, während der Zustand noch aktiv ist, führt dies zu einem Abschlussereignis (completion event). Für den Fall, dass es eine nach außen führende abschließende Transition gibt, wird der Zustand dann verlassen.

Abschlussereignis

Hierarchischer Zustandsautomat

In einem hierarchischen Zustandsautomaten (hierarchical state machine) kann mehr als ein Zustand zu einem Zeitpunkt aktiv sein. Dabei gilt: Ist der Zustandsautomat in einem einfachen Zustand, der in einem zusammengesetzten Zustand enthalten ist, dann sind alle zusammengesetzten Zustände, die entweder direkt oder transitiv den einfachen Zustand enthalten, ebenfalls aktiv.

Darüberhinaus gilt, da der Zustandsautomat als Ganzes und einige seiner zusammengesetzten Zustände in dieser Hierarchie orthogonal sein können (d.h. Regionen enthalten), dass der aktuelle aktive „Zustand“ durch eine Menge von Zustandsbäumen repräsentiert wird, beginnend mit den obersten Zuständen der „Wurzel-Regionen“ runter zu den individuellen einfachen Zuständen auf den Blättern. Ein solcher Zustandsbaum wird als Zustandskonfiguration (state configuaration) bezeichnet.

Zustands-
konfiguration

Außer bei der Ausführung eines Zustandsüberganges gelten folgende Invarianten immer für Zustandskonfigurationen:

• Ist ein zusammengesetzter Zustand aktiv und nicht orthogonal, dann ist genau einer seiner Subzustände (substates) aktiv.
• Ist der zusammengesetzte Zustand aktiv und orthogonal, dann sind alle seine Regionen aktiv, ein Subzustand (substate) in jeder Region

Zutritt zu einem nicht-orthogonalen zusammengesetzten Zustand

Beim Eintritt in einen zusammengesetzten Zustand werden die folgenden Fälle unterschieden:

• Der voreingestellte Zugang wird grafisch durch eine ankommende Transition angezeigt, die am äußeren Rand des zusammengesetzten Zustandes endet. In diesem Fall wird die voreingestellte Transition genommen. Gibt es einen Wächter auf dem Trigger der Transition, muss er wahr sein. Die Eingangsaktivität des zusammengesetzten Zustandes wird vor der Aktivität ausgeführt, die mit der Starttransition verknüpft ist.
• Geht die Transition gezielt zu einem bestimmten Subzustand des zusammengesetzten Zustandes, dann wird der Subzustand aktiv und seine Anfangsaktivität wird, nach der Ausführung der Anfangsaktivität des zusammengesetzten Zustandes, ausgeführt. Diese Regel gilt rekursiv, falls die Transition auf einem transitiv verschachtelten Subzustand endet.
• Endet die Transition auf einem shallowHistory-Pseudozustand, wird der aktive Subzustand zum letzten aktiven Subzustand vor diesem Eintritt, es sei denn, der letzte aktive Subzustand ist der Schlusszustand oder falls dieser Zutritt der erste in diesen Zustand ist.

In den beiden letztgenannten obigen Fällen erfolgt der Zutritt zum vor­eingestellten History-Zustand. Das ist der Subzustand, der das Ziel der Transition ist, die vom History-Pseudozustand herrührt. Falls keine solche Transition festgelegt ist, ist die Situation fehlerhaft definiert und der Umgang mit ihr ist nicht festgelegt. Falls der durch die History definierte aktive Subzustand ein zusammengesetzter Zustand ist, dann geht es mit der voreingestellten Anfangsaktivität weiter.

Shallow history -Eintritt

Für einen deepHistory-Pseudozustand gilt dasselbe mit der Ausnahme, dass die Regel rekursiv auf alle darunter liegenden Ebenen in der aktiven Zustandskonfiguration angewandt wird.

Deep history – Eintritt

Zutritt zu einem orthogonalen zusammengesetzten Zustand

Immer wenn ein orthogonaler zusammengesetzter Zustand betreten wird, wird jede seiner orthogonalen Regionen betreten, entweder per Voreinstellung oder ausdrücklich.

Endet die Transition am Rand des zusammengesetzten Zustandes, dann werden auch, mit Hilfe der Voreinstellungen, alle Regionen betreten.

Falls die Transition gezielt zu einer bestimmten oder zu mehreren bestimmten führt (bei einer Gabelung), dann werden diese Regionen explizit betreten und die anderen nach der Voreinstellung.

Verlassen nicht-orthogonaler Zustände

Wird ein zusammengesetzter Zustand verlassen, wird der aktive Subzustand rekursiv verlassen. Das bedeutet, dass die Schlussaktivitäten nacheinander ausgeführt werden, beginnend mit dem innersten aktiven Zustand in der aktuellen Zustandskonfiguration.

Verlassen eines orthogonalen Zustandes

Wird ein orthogonaler Zustand verlassen, wird jede seiner Regionen verlassen. Danach werden die Schlussaktivitäten des Zustandes ausgeführt.

Zustand eines untergeordneten Zustandsautomaten

Ein Zustand eines untergeordneten Zustandsautomaten (submachine state) ist semantisch gleichbedeutend mit dem zusammengesetzten Zustand, der durch den untergeordneten Zustandsautomaten definiert ist. Erreichen und Verlassen des zusammengesetzten Zustandes erfolgt, im Gegensatz zu einem einfachen zusammengesetzten Zustand, mittels Einstiegs- und Ausstiegspunkten.

Hin und weg durch Einstiegs- und
Ausstiegspunkte

Erreichen

Ein untergeordneter Zustandsautomat eines zusammengesetzten Zustandsautomaten (submachine composite state machine) kann durch seinen voreingestellten Initialknoten (Pseudozustand) oder durch einen seiner Einstiegspunkte betreten werden. Es kann also sein, dass der Zutritt zu einem nicht-orthogonalen oder einem orthogonalen zusammengesetzten Zustand mit Regionen erfolgen muss.

Der Zutritt über den Initialknoten bedeutet dasselbe wie für gewöhnliche zusammengesetzte Zustände. Ein Einstiegspunkt ist gleichbedeutend mit einem Verbindungsknoten oder einer Gabelung, für den Fall, dass der zusammengesetzte Zustand orthogonal ist. Der Zutritt über einen Einstiegspunkt bedeutet, dass die Eingangsaktivität des zusammengesetzten Zustandes ausgeführt wird, danach folgen die Transitionen (eine oder mehrere) vom Einsteigspunkt zu dem Zielzustand bzw. den Zielzuständen innerhalb des zusammengesetzten Zustandes. Genau wie für die voreingestellten Starttransitionen müssen die Wächter-Bedingungen der Trigger dieser Starttransitionen wahr sein, damit das Modell fehlerfrei ist.

Zutritt über
Initialknoten

Verlassen

Auf ähnliche Weise kann ein Zustandsautomat verlassen werden: als Ergebnis davon, dass der Schlusszustand erreicht wird, durch eine Gruppentransition, die für alle Subzustände (des untergeordneten Automaten eines zusammengesetzten Zustandsautomaten) (submachine state composite state) gilt, oder durch irgendeinen seiner Ausstiegspunkte.

Ausstiegs­
möglichkeiten

Das Verlassen durch einen Schlusszustand oder durch eine Gruppentransition hat hier dieselbe Bedeutung wie für einfache zusammengesetzte Zustände. Ein Ausstiegspunkt ist gleichbedeutend mit einem Verbindungsknoten bzw. Verknüpfer für den Fall, dass der zusammengesetzte Zustand orthogonal ist. Verlassen durch einen Ausstiegspunkt bedeutet, dass die erste Aktivität der Transition mit dem Ausstiegspunkt als Ziel ausgeführt wird, gefolgt von der Schlussaktivität des zusammengesetzten Zustandes. Falls mehrere erste Aktivitäten vorliegen, gilt entsprechendes.

Verlassen durch Schlusszustand oder Gruppentransition

12.3.6 Grafische Darstellung von Zuständen

Die grafische Darstellung von Zuständen wurde oben ja schon in den Beispielen vorgestellt. Hier nun zusammenfassend die Darstellung aller Varianten.

Für einfache Zustände gibt es zwei Grundformen. Sie bestehen aus einem Rechteck mit abgerundeten Ecken und der Bezeichnung des Zustandes entweder in diesem oder in einem separaten Rechteck an der oberen Randlinie. Letztere Lösung wird üblicherweise für die Bezeichnung eines zusammengesetzten Zustandes gewählt, der orthogonale Regionen hat. Vgl. das Beispiel in Abbildung 13.3-5.

Einfache Zustände

Die grafische Darstellung von Zuständen kann auch unterteilt werden. Die Trennung erfolgt durch eine horizontale Linie. Die folgende Abbildung zeigt ein Beispiel (vgl. auch die Abbildungen 13.3-17 und 13.3-18).

Zustände mit Bereichen

Mögliche Bereiche eines Zustandes sind:

• Namensbereich – für die Bezeichnung
• Bereich für die internen Aktivitäten
• Bereich für die internen Transitionen

Ein zusammengesetzter Zustand hat zusätzlich ein Feld für die Angabe der Zerlegungen.

Im Namensbereich wird die (optionale) Bezeichnung des Zustandes festgehalten. Falls es sich um den Zustand eines untergeordneten Zustandsautomaten handelt, wird der Name des entsprechenden Zustandsautomaten als Zeichenfolge mit einem Doppelpunkt nach der Bezeichnung des Zustandes angegeben, wie oben gezeigt.

Namensbereich

Im Bereich für die internen Aktivitäten steht eine Liste der Aktivitäten oder Zustandsaktivitäten, die ausgeführt werden, wenn der Zustand aktiv ist. Für jede Aktivität gibt es eine Bezeichnung und einen Ausdruck. Die Bezeichnung hält fest, unter welchen Bedingungen die Aktivität aufgerufen wird, der Ausdruck legt die Aktivität fest. Vgl. die obige Abbildung 13.3-16 für ein Beispiel.

Bereich für die
internen Aktivitäten

Einige Aktivitätsbezeichnungen sind reserviert, können also nicht als Ereignisbezeichnungen verwendet werden:

• entry für die Anfangsaktivität
• exit für die Schlussaktivität
• do für die Zustandsaktivität

Im Bereich für die internen Übergänge steht eine Liste der internen Transitionen. Die Gestaltung ist wie die bei Triggern. Jede Ereignisbezeichnung kann mehr als einmal pro Zustand auftreten, wenn die Wächter-Bedingungen verschieden sind. Die Ereignisparameter und die Wächter-Bedingungen sind optional. Falls das Ereignis Parameter hat, können sie in dem Ausdruck, der die Aktivität festlegt, durch die aktuelle Ereignisvariable genutzt werden.

Bereich für die
internen Zustandsübergänge

Zusammengesetzte Zustände

Im Zerlegungsbereich wird der Aufbau des Zustandes durch Regionen, andere Zustände und Transitionen angegeben. Ergänzend kann in einem eigenen Bereich eine Abbildung die Verschachtelung angeben.

Zerlegungsbereich

In einigen Fällen kann es sinnvoll sein, die Zusammensetzung des zusammengesetzten Zustandes zu verbergen. Zum Beispiel können eine große Anzahl von Zuständen in einem zusammengesetzten Zustand verschachtelt sein und einfach nicht alle in den Platz passen, der für die Abbildung zur Verfügung steht.

Zusammensetzung
verbergen

In diesem Fall wird der zusammengesetzte Zustand durch ein einfaches grafisches Symbol repräsentiert. Dieses wird üblicherweise im rechten unteren Eck (vgl. Abbildung 13.3-18 für die Darstellung) eingefügt. Die Inhalte des zusammengesetzten Zustandes werden in einer eigenen Abbildung gezeigt.

12.3.7 Beispiele für zusammengesetzte Zustände

Beispiel 1 – Zustände im Zustand

Das folgende Beispiel zeigt einen einbettenden Zustand (Wählen). In den eingebetteten Zuständen sind auch die Eingangs-, Ausgangs- und eine Zustandsaktivität angegeben.

Zustände im Zustand

Der Zustand beschreibt in einfacher Form das Wählen einer Telefonnummer in klassischen Fernsprechanlagen. Der Initialknoten führt zum ersten Zustand. Er beginnt mit dem Starten des Wähltons (Eingangsaktivität) und endet mit dessen Abstellung (Schlussaktivität), wenn die erste Ziffer gewählt wird. Dies löst die erste Transition aus.

Der zweite Zustand beschreibt den Wählvorgang, der – bis die n Ziffern eingegeben sind – dank der Selbsttransition immer wieder startet und endet. Falls die Nummer gültig ist, kommt es zum Schlusszustand (vgl. zu diesem Anwendungsbereich auch das ausführlichere Beispiel in Abbildung 13.5-3).

Das obige Beispiel enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Eine Selbsttransition 
• Mehrere Eingangsaktivitäten (ZA)
• Eine Schlussaktivität
• Mehrere Transitionen
• Eine Zustandsaktivität (ZA)

Außerdem einen Zustandsautomat in einem Zustand und somit einen einbettenden Zustand.

Beispiel 2 – Verborgener zusammengesetzter Zustand

Das zweite Beispiel zeigt einen verborgenen zusammengesetzten Zustand. Das Symbol in der unteren rechten Ecke signalisiert, dass der Zustand im Detail an anderer Stelle beschrieben ist.

Verborgener
zusammengesetzter Zustand

Beispiel 3 – Zustandsautomat eines Subzustandes

Das nächste Beispiel zeigt einen Zustand, der auf einen Zustandsautomaten verweist (vgl. Abbildung 13.3-11 für eine anderes Beispiel). Entsprechend sind die Bezeichnungen: Der Zustand heißt Fehlerbehandlung, es ist ein Subzustand. Der untergeordnete Zustandsautomat hat die Bezeichnung FehlerbehandlungSM, er ist an anderer Stelle spezifiziert. Insgesamt hat das Element dann die Bezeichnung Fehlerbehandlung:Fehler­behand­lungSM.

Zustandsautomat
eines
Subzustandes

Betrachten wir die Verknüpfung zwischen den zwei Ebenen, die ankommenden und die wegführenden Transitionen. Die ankommenden geben sozusagen den Input für den Subzustandsautomaten an, die wegführenden seinen Output.

Zuerst die ankommenden Transitionen. Die Transition, die durch das Ereignis „error1“ ausgelöst wird, endet bei Einstiegspunkt „Sub1“ des Zustandsautomaten FehlerbehandlungSM. Dieser Einstiegspunkt muss also dort vorliegen. Die Transition "error3”, die auf der Grenzlinie endet, führt dazu, dass die voreingestellte Starttransition dieses Subzustandsautomaten benutzt wird.

Ankommende Transitionen

Bei den wegführenden Transitionen zeigt das Beispiel folgendes. Eine Transition geht über einen Ausstiegspunkt weg (subEnd). Ein entsprechender Ausstiegspunkt muss also auch im Subzustandsautomaten vorliegen. Eine andere Transition geht von der Grenzlinie des Zustandes aus. Sie wird aktiv, wenn im Subzustandsautomaten FehlerbehandlungSM der Schlusszustand erreicht wurde.

Abgehende Transitionen

Das Symbol rechts unten gibt an, dass der Aufbau des zusammengesetzten Zustandes an dieser Stelle verborgen wird (vgl. oben).

Verborgener
zusammengesetzter
Zustand

Das obige Beispiel enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Einen Einstiegspunkt (Sub1)
• Einen Ausstiegspunkt (subEnd)
• Das Symbol für einen verborgenen zusammengesetzten Zustand 

Außerdem eine Transition, die auf der Grenzlinie endet und eine, die von der Grenzlinie ausgeht.

12.3.8 Transitionen vertieft

Hier nun, zusammengefasst und vertiefend, weitere Anmerkungen zu Transitionen.

Definition

Eine Transition ist eine gerichtete Beziehung zwischen einem Quell- und einem Zielknoten. Sie kann Teil einer Verbundtransition (vgl. unten) sein, die den Zustandsautomat von einer Zustandskonfiguration in eine andere bringt und die damit die vollständige Antwort des Zustandsautomaten auf ein bestimmtes Ereignis darstellt.

Von einem Zustand in den nächsten

Auch hier gibt es Wächter, die das Aktivieren der Transition überwachen. Der Wächter kommt zum Einsatz, wenn ein Ereignis durch den Zustandsautomaten ausgelöst wird. Ergibt die Prüfung den Wahrheitswert wahr, wird die Transition aktiviert, ansonsten wird sie nicht ausgeführt. Wächter dürfen keine Seiteneffekte haben.

Der Quellknoten einer Transition kann ein Zustand oder ein Pseudozustand sein. Folgende Einschränkungen gelten (vgl. [OMG 2003a, Seite 498f], dort finden sich auch textlich ausformulierte Beispiele):

Ausgangspunkte

• Eine Gabelung oder eine Verknüpfung darf keine Wächter oder Trigger haben.
• Eine Gabelung muss immer zu einem Zustand führen.
• Ein Verknüpfer muss immer von einem Zustand kommen.
• Transitionen, die von einem Pseudozustand ausgehen, dürfen keine Trigger haben.
• Eine Starttransition auf der obersten Ebene (Region eines Zustandsautomaten) hat entweder keinen Trigger oder einen der Form create.

Gruppentransitionen

Transitionen, die von zusammengesetzten Zuständen (composite states) herrühren, werden Gruppentransitionen (group transitions) genannt. Wenn sie ausgelöst sind, verlassen sie die Subzustände des zusammengesetzten Zustandes in dem sie ihre Schlussaktivitäten ausführen. Dies beginnt mit den innersten Zuständen der aktiven Zustandskonfiguration.

Transitionen von zusammengesetzten Zuständen

Eine solche Transition mit einem Ziel außerhalb des zusammengesetzten Zustandes bedeutet, dass die Schlussaktivität des zusammengesetzten Zustandes ausgeführt wird. Ist das Ziel innerhalb, geschieht dies natürlich nicht.

Verbundtransitionen

Eine Verbundtransition (compound transition) stellt einen semantisch vollständigen Pfad aus einer Transition oder aus mehreren dar. Er kommt von einer Menge von Zuständen (im Gegensatz zu Pseudozuständen) und zielt auf eine Menge von Zuständen.

Von und zu einer Menge von Zuständen

Damit stellt eine Verbundtransition eine azyklische ununterbrochene Kette von Transitionen dar, die mittels der Pseudozustände Verknüpfer, Verbindungspunkt, Auswahlknoten oder Gabelung verknüpft sind und die den Weg von einer Menge von Quellzuständen zu einer Menge von Zielzuständen angeben.

Für eine Selbsttransitionen stellt derselbe Zustand die Quell- und die Zielmenge dar.

Eine einfache Transition, die zwei Zustände verbindet, ist ein Sonderfall einer Verbundtransition.

Interne Transitionen

Eine interne Transition wird ausgeführt, ohne den Zustand, in dem sie definiert ist, zu verlassen oder wieder zu betreten. Dies gilt auch, falls der Zustandsautomat in einem verschachtelten Zustand ist.

Abschlusstransitionen und Abschlussereignisse

Eine Abschlusstransition (completion transition) ist eine Transition, die als Quelle einen zusammengesetzten Zustand, einen Zustand mit untergeordnetem Zustandsautomaten oder einen Ausstiegspunkt hat. Sie hat keine expliziten Trigger, obwohl ein Wächter definiert sein kann.

Wenn alle Transitionen, Eingangsaktivitäten und Zustandsaktivitäten im jeweiligen aktuellen Zustand erledigt sind, wird ein Abschlussereignis (completion event) erzeugt. Dieses Ereignis ist der implizite Trigger für eine Abschlusstransition. Das Abschlussereignis tritt vor allen anderen Ereignissen im Ereignisraum ein und hat keine Parameter.

Zum Beispiel wird eine Abschlusstransition, die von einem orthogonalen zusammengesetzten Zustand ausgeht, automatisch aktiviert, sobald alle orthogonalen Regionen ihren Schlusszustand erreicht haben.

Sind mehrere Abschlusstransitionen für einen Zustand definiert, dann sollten sie sich gegenseitig ausschließen (über die Wächter-Bedingungen).

Wächter (Guard)

In einer einfachen Transition mit einem Wächter wird dieser ausgewertet bevor die Transition ausgelöst wird.

In Verbundtransitionen mit mehreren Wächtern werden alle geprüft bevor eine Transition ausgelöst wird, es sei denn es gibt Auswahlknoten entlang einem Pfad oder entlang mehrerer. Die Abfolge, in der die Wächter ausgewertet werden, ist nicht definiert.

Mehrere Wächter

Gibt es Auswahlknoten in einer Verbundtransition werden nur die Wächter ausgewertet, die davor liegen, gemäß obiger Regel. Wächter nach einem Auswahlknoten werden ausgewertet, falls und wenn der Knoten erreicht wird (nach der gleichen Regel wie oben).

Ausführung von Transitionen

Jede Transition, mit Ausnahme von internen und lokalen Transitionen, verursacht zweierlei: Das Verlassen eines Quellzustandes und das Eingehen eines Zielzustandes. Diese zwei Zustände, die zusammengesetzt sein können, werden als die Hauptquelle und das Hauptziel einer Transition bezeichnet.

Vom Quellzustand zum Zielzustand

Der LCA-Zustand (LCA= least common ancestor/letzter gemeinsamer Vorgänger) einer Transition ist der niedrigste zusammengesetzte Zustand, der alle expliziten Quellzustände und alle expliziten Zielzustände der Verbundtransition enthält.

Im Falle von Verbindungspunkten werden nur die Zustände, die in Beziehung stehen zum dynamisch ausgewählten Pfad, als explizite Ziele betrachtet, d.h., umgeleitete Zweige werden nicht betrachtet.

Falls der LCA nicht ein orthogonaler Zustand ist, ist die Hauptquelle der Transition ein direkter Subzustand des letzten gemeinsamen Vorgängers, der die expliziten Quellzustände enthält, und das Hauptziel ist ein Subzustand des letzten gemeinsamen Vorgängers, der die expliziten Zielzustände enthält.

Für den Fall, dass der LCA ein orthogonaler Zustand ist, sind Hauptquelle und Hauptziel der orthogonale Zustand selbst. Der Grund ist: Wird eine orthogonale Region verlassen, muss der gesamte orthogonale Zustand verlassen werden.

12.3.9 Ereignisraum und Ereignisverarbeitung

Das Konzept des Ereignisraumes wurde schon mehrfach bei den einzelnen Konstrukten erwähnt. 

Was ist nun der Ereignisraum eines Zustandsautomaten? Da jeder Zustandsautomat im Rahmen der Metamodellierung der UML-Autoren auf einen Verhaltensclassifier zurückgeht (also dessen Spezialisierung ist), bestimmt dieser den Ereignisraum.

Quelle des Ereignisraumes

Ist der Zustandsautomat eine Methode und gehört somit zu einem Verhaltensmerkmal eines Classifier, liefert dieser den Ereignisraum.

Wie werden die Ereignisse verarbeitet? Die Vorstellung der UML-Autoren ist, dass der Zustandsautomat die Ereignisse eintreten lässt. Die Reihenfolge in der sie abgearbeitet werden, ist nicht definiert, wodurch die Möglichkeit bleibt, verschiedene auf unterschiedlichen Prioritäten beruhende Abläufe zu modellieren.

Ereignis-
verarbeitung

Die Semantik der Ereignisverarbeitung basiert auf der run-to-comple­tion – Annahme. Diese sagt, dass ein Ereignis nur dann vom Ereignisraum genommen und realisiert werden kann, falls die Verarbeitung des vorigen aktuellen Ereignisses vollständig fertig ist.

Eins nach dem
anderen

Die Verarbeitung eines einzelnen Ereignisses durch einen Zustandsautomaten wird als run-to-completion step bezeichnet. Vor dem Beginn eines run-to-completion step ist der Zustandsautomat in einer stabilen Zustandskonfiguration bei der alle Eingangs-, Ausgangs- und internen Aktivitäten vervollständigt sind (aber nicht notwendigerweise die Zustandsaktivitäten). Die gleichen Bedingungen gelten, wenn der run-to-completion step vervollständigt ist.

Auf diese Weise wird ein Ereignis nie verarbeitet, während der Zustandsautomat in einem Zwischenzustand oder in einer inkonsistenten Situation ist. Der run-to-completion step ist die Passage zwischen zwei Zustandskonfigurationen des Zustandsautomaten.

Keine unklaren Zustände

12.4 Protokollzustandsautomaten

Die Protokollzustandsautomaten haben grundsätzlich denselben Aufbau wie die Verhaltenszustandsautomaten. Sie beschreiben aber nicht Systemverhalten, sondern die Nutzungsprotokolle eines Systems und geben somit die legalen Transitionen an, die ein Classifier ausführen kann.

Nutzungsprotokolle eines Systems

Zustände

Zwei Unterschiede gibt es zwischen Zuständen in Verhaltens- und in Protokollzustandsautomaten:

• Einige Elemente von Verhaltenszustandsautomaten gibt es bei Protokollzustandsautomaten nicht: Eingangsaktivität, Schlussaktivität und Zustandsaktivität.
• Zustände in Protokollzustandsautomaten können eine Invariante haben. Deren textliche Bezeichnung wird nach oder unter der Bezeichnung des Zustandes in eckigen Klammern angegeben (vgl. die folgende Abbildung).

Transitionen

Eine Protokolltransition legt eine zulässige Transition für eine Operation fest. Transitionen von Protokollzustandsautomaten haben die folgenden Informationen: eine Vorbedingung (Wächter), einen Trigger und eine Nachbedingung. Mit einem entsprechenden Text kann in einer Abbildung der Transitionspfeil versehen werden.

[Vorbedingung]
Ereignis
/ [Nachbedingung]

Jede Protokolltransition steht mit höchstens einer Operation in Beziehung, die zum Kontextclassifier[4] des Protokollzustandsautomaten gehört.

Zustandsautomaten

Ein Protokollzustandsautomat wird immer in Zusammenhang mit einem Classifier definiert. Er legt fest, welche Operationen des Classifiers in welchem Zustand und unter welchen Bedingungen aufgerufen werden können, wodurch auch die erlaubten Aufruffolgen auf den Operationen des Classifiers festgelegt werden.

Zulässige Operationen

Damit gibt ein Protokollzustandsautomat die möglichen und erlaubten Transitionen auf den Instanzen seines Kontextclassifiers an, zusammen mit den Operationen, die die Transitionen „tragen“.

Auf diese Weise kann ein Lebenszyklus einer Instanz erzeugt werden, indem die Reihenfolge, in der die Operationen aktiviert werden können und die Zustände, die eine Instanz im Laufe seiner Existenz erlebt, festgehalten werden.

Folgende Einschränkungen gelten:

• Ein Protokollzustandsautomat darf nur einen Kontextclassifier haben, keinen Verhaltenskontext (behavioral feature context). Den letztgenannten haben dagegen die Verhaltenszustandsautomaten.
• Alle Transitionen von Protokollzustandsautomaten müssen Protokolltransitionen sein.

Protokollzustandsautomaten helfen, die Einsatzmöglichkeiten der Operationen eines Classifiers und die Aufgaben, für die ein Classifier geeignet ist, zu definieren, indem sie folgendes festlegen:

Einsatz der Operationen

• in welchem Kontext (unter welchen Zuständen und Vorbedingungen) die Operationen genutzt werden können
• ob es eine “protocol order“ zwischen ihnen gibt
• welches Ergebnis aus ihrem Einsatz erwartet wird

Die Nutzung von Vor- und Nachbedingungen bei Operationen ist eine Technik, die sehr gut geeignet ist, solche Festlegungen zu treffen. Jedoch werden sie auf der Ebene der Operationen definiert und liefern daher keinen geschlossenen Überblick auf der Classifierebene.

Vor- und Nachbedingungen bei Operationen

Es kann sein, dass Protokollzustandsautomaten nicht alle Vor- und Nachbedingungen von Operationen ausdrücken können. In diesem Fall können zusätzliche Bedingungen auf der Operationenebene hinzugefügt werden. Formal geschieht dann folgendes: Die Vorbedingung einer Operation wird zu den Bedingungen, die von dem Protokollzustandsautomaten abgeleitet wurden, hinzugefügt (logisches UND), als Vorbedingung der Operation. Entsprechendes gilt für Nachbedingungen.

Der Protokollzustandsautomat definiert alle erlaubten Transitionen für jede Operation. Er muss alle Operationen repräsentieren, die eine bestimmte Zustandsänderung für eine Klasse erzeugen können. Operationen, die keine Transitionen erzeugen, werden in dem Protokollzustandsautomaten nicht dargestellt.

Protokollzustandsautomaten bilden ein Werkzeug, um die Interfaces von Klassen zu formalisieren und drücken nichts anderes aus als Regeln für die Widerspruchsfreiheit und Korrektheit bei der Implementierung der dynamischen Aspekte von Klassen.

Ziel: Widerspruchs-
freiheit und Korrektheit

Protocol state machines constitute a means /ein Mittel, Werkzeug to formalize the interface of classes, and do not express anything except consistency rules for the implementation or dynamics of classes.

Die Interpretation von Protokollzustandsautomaten kann unterschiedlich sein:

• Deklarative Protokollzustandsautomaten, die für jede Operation die zulässigen Transitionen festlegen. Die genauen Bedingungen für das Auslösen der Transitionen werden nicht festgelegt.
• Ausführbare Protokollzustandsautomaten, die alle Ereignisse, auf die ein Objekt reagieren und mit denen es umgehen kann, festlegen und die auch noch die damit zusammenhängenden Transitionen angeben. In diesem Fall sind die zulässigen Transitionen für Operationen genau die ausgelösten Transitionen.

Die Darstellung für beide Interpretationen ist dieselbe. Der Unterschied besteht darin, dass die zweite die dynamischen Aspekte betont.

Grafische Darstellung

Die Darstellung von Protokollzustandsautomaten ist der von Verhaltens­zustandsautomaten sehr ähnlich. Das Schlüsselwort {protocol} wird bei der Bezeichnung des Zustandsautomaten platziert.

Die folgende Abbildung zeigt ein Beispiel. Die Tür (der Kontextclassifier) kann die drei Zustände geöffnet, zu und verschlossen annehmen. Vom Zustand geöffnet kann nur der Zustand zu erreicht werden, von diesem entweder offen oder verschlossen. Somit drückt die Abbildung auch aus, dass die Tür erst verschlossen werden kann, wenn sie zugemacht wurde.

Tür als Kontextclassifier

Das obige Beispiel enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Mehrere Protokolltransitionen
• Mehrere Zustände in einem Protokollzustandsautomaten 

Außerdem das Beispiel eines Kontextclassifiers.

12.5 Beispiele von Verhaltenszustandsautomaten

12.5.1 Prozessbeispiel Rechnung (mittelgroß)

Während das Beispiel in Abbildung 13.2-6 (Rechnung – einfach) aufgrund seiner Abgehobenheit tatsächlich den Eindruck eines Prozessbeispiels macht, ist dies hier nicht mehr so eindeutig. Aufgrund der Detaillierung sind wir hier doch schon recht nahe an der programmmäßigen Realisierung. Noch mehr im folgenden Beispiel (Rechnung – umfassend). Es soll aber doch bei dieser Kennzeichnung als Prozessbeispiel bleiben, da Rechnung tatsächlich ein Geschäftsobjekt ist und – zum Beispiel – auf System- bzw. Programmebene noch weiter zerlegt werden müsste (Rechnungskopf, Rechnungspositionen).

Prozessbeispiel?

Erscheinungsformen einer Rechnung

In einem Mahnwesen spielt – natürlich – die Rechnung eine prominente Rolle. Sie kann auch sehr viele unterschiedliche Zustände einnehmen. Diese werden hier dargestellt.

Anmerkung: Die Aktion, die als dritter Teil der Transition angegeben wird, ist hier sehr oft schlicht das Setzen des neuen Zustandes. Sie wird zur Verdeutlichung einige Male angegeben, meist aber weggelassen.

Aktion = Setzen des neuen Zustandes

Nach der Erstellung der Rechnung ist sie für das System existent und im Zustand Neue Rechnung. Nach der Übersendung zum Kunden kommt sie in den Zustand Offen.

Neu

Zahlungsart Lastschrift

Durch eine Abbuchung im Lastschriftverfahren geht die Rechnung in den Zustand Rückbuchbar bezahlt über. Sind sechs Wochen vergangen, kann die Zahlung vom Kunden nicht mehr zurückgebucht werden und die Rechnung geht in den Zustand Bezahlt über.

Rückbuchbar bezahlt

War die Lastschrift gar nicht möglich, geht die Rechnung von Offen in den Zustand Lastschrift verweigert über. Folgende Gründe sind dafür möglich:

Lastschrift verweigert

• das Konto existierte nicht mehr
• das Konto war nicht gedeckt
• der Kunde hat der Bank gegenüber die Abbuchungsgenehmigung widerrufen

… wird bezeichnet, falls der Kunde bei der Rückbuchung der Lastschrift gleichzeitig gegen die Rechnungsstellung protestiert und Gründe dafür anführt, dass diese nicht zulässig oder nicht korrekt ist.

Zahlungsart Überweisung

Falls Überweisung vereinbart war hat der Kunde ebenfalls eine Rechnung erhalten, es wird aber auf den Zahlungseingang gewartet. Die Frist für die Zahlung ist zwei Wochen. Systemintern wird eine Woche dazugegeben für die Zustellung der Rechnung, für den Zahlungsverkehr, usw. Wird die Rechnung innerhalb von 21 Tagen überwiesen, geht sie in den Zustand Bezahlt, ansonsten in den Zustand Nicht bezahlt über.

Bezahlt oder
Nicht bezahlt

Nicht bezahlt

Aus dem Zustand Nicht bezahlt führen zwei Transitionen:

• Handelte es sich zuvor um eine Überweisung, wird eine Zahlungserinnerung verschickt und die Rechnung geht in diesen Zustand Zahlungserinnerung über.
• Handelte es sich zuvor um eine Lastschrift bzw. um eine danach erfolgte Rücklastschrift, kommt die Rechnung gleich in den Zustand 1. Mahnung.

Zahlungserinnerung + Zahlungsfrist

Wird bei einer Zahlungserinnerung kein Zahlungseingang innerhalb von 21 Tagen festgestellt, kommt es zu einer 2. Erinnerung, falls der Kundenstatus Plus ist. Ist der Kundenstatus Minus, kommt es gleich zur 1. Mahnung. Falls auf eine eventuelle 2. Mahnung wiederum kein Zahlungseingang innerhalb von 21 Tagen erfolgt, kommt es ebenfalls zur 1. Mahnung.

Erinnerungen und Mahnungen,
je nach Kundenstatus

Selbstverständlich kann die Rechnung aus allen Mahnstufen durch Überweisung in den Zustand Bezahlt gelangen.

1. Mahnung + Zahlungsfrist

Wird eine Rechnung im Zustand 1. Mahnung nicht innerhalb von 21 Tagen beglichen, geht sie entweder in den Zustand 2. Mahnung oder in den Zustand Inkassobüro über. In den Zustand 2. Mahnung kommt sie, falls es sich um einen Neukunden handelt oder falls – bei einem Altkunden – in den letzten drei Jahren keine Zahlungsschwierigkeiten aufgetreten waren (Kundenstatus Plus). In den Zustand Inkassobüro kommt sie, falls es sich um einen Altkunden handelt, bei dem in den letzten drei Jahren schon mal Zahlungsschwierigkeiten auftraten (Kundenstatus Minus).

2. Mahnung und Inkassobüro

2. Mahnung + Zahlungsfrist

Wird eine Rechnung im Zustand 2. Mahnung nicht innerhalb von 21 Tagen beglichen, wird sie einem Rechtsanwalt, der ein Inkassobüro betreibt, übergeben und geht in den entsprechenden Zustand über.

Nicht einzutreiben

Falls keine Bezahlung der Rechnung möglich ist, muss sie storniert werden und erreicht den entsprechenden Zustand.

Storniert

Dies ist in der Regel nur nach dem Zustand Inkassobüro möglich. In Ausnahmefällen wird dieser Zustand auch vom Zustand Offen aus erreicht, falls gleich erkannt wird, dass keine Eintreibung möglich ist. Eine weitere Ursache konnte sein, dass eine neue Rechnung gar nicht zustellbar ist. Dann durchläuft die Rechnung die Zustände Neue Rechnung, Nicht zustellbar und Storniert.

Vgl. die Varianten dieses Zustandsübergangsdiagramms in den Abbildungen 13.2-6 (einfach) und 13.5-2 (umfassend).

12.5.2 Prozessbeispiel Rechnung (umfassend)

Baut man das Beispiel noch etwas aus indem man die möglichen Widersprüche von Kunden einbaut, was ja für die Geschäftsprozesse eines Unternehmens von großer Bedeutung ist, erhält man das Zustandsdiagramm der folgenden Abbildung. Hier wird ein neuer Zustand der Rechnung, in Widerspruch, eingeführt und in die Zustandsübergang eingebaut.

Neuer Zustand:
(in) Widerspruch

Die Abbildung zeigt auch die Grenzen der grafischen Darstellbarkeit von Zustandsautomaten auf.

Widersprüche

Wird in einem der Zustände Offen, Zahlungserinnerung, 2. Erinnerung, 1. Mahnung oder 2. Mahnung ein Widerspruch gegen die Rechnung erhoben wechselt sie in den Zustand Widerspruch. Beispiel für die vollständige Transitionsbeschriftung:

Wege zum Zustand Widerspruch

Widerspruch ist eingegangen [Widerspruch ist zu prüfen] Rechnungsstatus in Widerspruch ändern

Aus dem Zustand Rückbuchbar bezahlt kommt die Rechnung in den Zustand Widerspruch, falls eine Rücklastschrift erfolgte.

Falls aus dem Zustand Inkassobüro ein Widerspruch erfolgt, wird er vom verantwortlichen Rechtsanwalt im Rahmen seiner allgemeinen Tätigkeit bearbeitet.

Jeglicher Widerspruch wird von der Abteilung Zahlungsüberwachung geprüft. Wird festgestellt, dass er nicht berechtigt ist, geht die Rechnung in den jeweiligen vorherigen Zustand zurück. Ist der Widerspruch berechtigt, geht die Rechnung in den Zustand Gutschrift über. Der Zustandsübergang:

Widerspruch ist zu bearbeiten [Widerspruch ist berechtigt] Gutschrift ausstellen und Rechnungsstatus ändern

Vgl. die Varianten dieses Zustandsübergangsdiagramms in den Abbildungen 13.2-6 (einfach) und 13.5-1 (mittelgroß).

Die obigen Beispiele enthalten u.a. folgende Komponenten bzw. Besonderheiten:

• Einen Anfangszustand

• Zahlreiche Transitionen
• Mehrere Schlusszustände

Außerdem mehrere Zustände mit mehr als einer abgehenden Transition.

12.5.3 Systembeispiel Telefonanlage

Die folgende Abbildung zeigt ein Zustandsdiagramm für ein einfaches Telefonobjekt. In Ergänzung zum Anfangszustand hat der Zustandsautomat einen Einstiegspunkt, der activeEntry genannt wird. In Ergänzung zum Schlusszustand einen Ausstiegspunkt, der abgebrochen genannt wird.

Die Zustände sind alle „dynamisch“, sie werden durch Aktivitäten (dieser Begriff wird hier, wie immer außerhalb von Kapitel 10, im umgangssprachlichen Sinn verwendet) aufrecht gehalten. Vgl. die Diskussion hierzu zu Beginn des Kapitels (Abschnitt 13.2.2).

„Dynamik“

Dies ist auch an den Zustandsaktivitäten erkennbar, die in den meisten Zuständen angegeben sind, wodurch es dann zu den Elementen mit Bereichen kommt.

Standarddurchgang

Betrachten wir einen Standarddurchgang. Die Anlage ist nach ihrer Aktivierung bzw. wenn der Nutzer den aktiven Zustand durch Auflegen beendet im Leerlauf. Wird der Hörer abgenommen, wird der Subzustandsautomat Aktiv gestartet, was bedeutet, dass sein Startknoten den Zustand Wählton aktiviert.

Leerlauf

Kommt es hier zu einer Pause von 15 Sekunden, gerät die Anlage in den Zustand Zeitablauf (time out) und eine Nachricht wird abgespielt.

Zeitablauf

Werden nun Ziffern gewählt, gerät die Anlage in den Zustand Wählen. Dieser Zustand hat eine Selbsttransition und ruft sich solange selber auf bis alle Ziffern gewählt sind.

Wählen

Vom Zustand Wählen gibt es drei mögliche Zustandsübergänge:

• zu Verbinden, falls alle Nummern gewählt sind und die Nummer gültig ist: Ziffern gewählt(n) [vollständig] /connect
• zu Ungültig, falls die Ziffern insgesamt keine gültige Nummer darstellen. Ziffern gewählt(n) [ungültig]. Dieser Zustand spielt dann eine Nachricht ab.
• zu Zeitablauf, falls 15 Sekunden Pause bei der Eingabe entstehen: nach (15 Sek.)

Betrachten wir den weiteren Verlaut, falls die Verbindung zustande kam. Hier gerät die Anlage entweder in den Zustand Besetzt oder Rufton. Falls der Angerufene abnimmt, kommt die Anlage in den Zustand Sprechen.

Verbindung zustandegekommen

Die beiden Elemente am unteren Ende deuten die Abschaltung der Anlage an. Entweder durch das Abschalten (Schlusszustand) der Anlage oder durch einen Abbruch.

Auf der linken Seite ist die normale Beendigung des Gesprächs modelliert. Falls der Anrufer auflegt, wird die Verbindung unterbrochen und die Anlage ist wieder im Leerlauf, aus dem sie durch das Abnehmen des Hörers kommen kann.

Das obige Beispiel enthält u.a. folgende Komponenten bzw. Besonderheiten:

• MehrereAnfangszustände 
• Einen Ausstiegspunkt (abgebrochen)
• Mehrere Bereiche für interne Aktivitäten (ZA)
• Einen Einstiegspunkt (activeEntry)
• Einen Schlusszustand
• Eine Selbsttransition (Wählen)
• Zahlreiche Transitionen
• Mehrere Zustände mit Bereichen
• Zahlreiche Zustandsaktivitäten (ZA)  

Außerdem zwei Zustände mit mehreren abgehenden Transitionen.

12.6 Zustandsautomaten und Unternehmensmodellierung

Welchen Beitrag können Zustandsautomaten zu einer Unternehmensmodellierung leisten?

Eine erste Antwort ist schnell gegeben: Der Beitrag wird im Bereich der Ablauf-/Prozessmodellierung liegen, denn von ihrer ursprünglichen Aufgabe her, der Modellierung von Softwaresystemen, ist nur das in der Methode angelegt.

Wenn schon, dann Ablaufmodellierung

Die Präzisierung der Antwort ist schwieriger. Vor allem muß dabei zwischen den zwei Typen von Zustandsautomaten unterschieden werden, die oben recht deutlich wurden:

• „Fixe und Flache“ Zustandsautomaten (so sollen sie hier genannt werden). Dies sind die mit fixen („festen“) Zuständen, die ein Objekt, das nicht weiter strukturiert (unterteilt) wird, modellieren und deren Objektzustände nicht durch Aktivitäten[5] erzeugt und aufrecht erhalten werden müssen. Diese Objekte werden zwar bei jedem Zustandsübergang verarbeitet, ihr „Zustand“ im Sinne der Ausprägung ihrer Attributsausprägungen verändert sich bei jedem Zustandsübergang, aber ihre einzelnen Zustände sind fix. Vgl. das Beispiel Rechnung oben und auch die Diskussion hierzu in Abschnitt 13.2.2.
• „Dynamische und tiefe“ Zustandsautomaten. Diese haben dynamische Zustände, die durch Aktivitäten (im umgangssprachlichen Sinn) erzeugt und aufrechterhalten werden, und die auch noch tief verschachtelt sein können (Zustandsautomat im Zustand, usw.).

„Fixe und flache“ Zustandsautomaten

Dynamisch und tief

Diese eignen sich hervorragend für das, für das sie ja auch gemacht sind, für die Verfolgung der verschiedenen Zustände eines Objekts (hier: eines Geschäftsobjekts). Die Zustandsänderungen stellen dabei Verarbeitungsschritte dar und spiegeln direkt einen Prozessablauf wider. Allerdings einen rund um ein einzelnes (Geschäfts-)Objekt. Vgl. das oben angeführte Beispiel Rechnung.

Geschäftsobjekte in ihren Zuständen verfolgen

Die Darstellung dieser Lebenszyklen eines Objekts als Zustandsdiagramm kann bei komplexen Anwendungen sehr sinnvoll sein, z.B. zur Vorbereitung der Programmierung. Sie stellen damit Detailanalysen aus dem weiten Feld der Prozessanalyse dar.

Einen weiteren Beitrag können sie aber nicht leisten. Sie eignen sich damit auch nicht zur Prozessmodellierung, auch wenn oben ein typischer Geschäftsprozess als Zustandsautomat dargestellt wurde (Kundenanfrage). Eine solche Darstellung eines Zustandsautomaten als Geschäftsprozess ist in Wirklichkeit nur die Beschreibung der Zuständsübergänge als Ablauf.

„Dynamische und tiefe“ Zustandsautomaten

Betrachtet man diesen Typ Zustandsautomat mit den zwei Merkmalen

• Zustände als etwas aktives mit innerer „dynamischer“ Struktur
• Verschachtelung der Zustände, d.h. „Tätigkeit in Tätigkeit“ usw.

dann ist man deutlich näher an den notwendigen Basiselementen einer Methode zur Prozessmodellierung (vgl. unten). Damit sind grundsätzlich auch wichtige Aspekte von Geschäftsprozessen modellierbar. Denn das Objekt kann ja beliebig weit gefasst werden. Z.B. als das Mahnwesen im Beispiel WebShop oder als Leistungserbringung eines Unternehmens.

Im folgenden Abschnitt nun der Abgleich mit diesen Basiselementen.

12.6.1 Tauglichkeit für die Prozessmodellierung

Dieser Abgleich soll in Anlehnung an die in Abschnitt 15.3 vorgestellten Basiskomponenten einer Methode zur Prozessmodellierung durchgeführt werden. Sie enthalten die für eine Modellierung von Tätigkeitsfolgen im einfachsten Fall notwendigen Theorieelemente. Die Nummerierung ist die von Abschnitt 15.3.

(1) Elementare Tätigkeiten

Die Einteilung der Gesamtaufgabe in einzelne Tätigkeiten und damit in Tätigkeitsfolgen ist gegeben. So wie das Objekt Geldautomat tatsächlich aus vielen Komponenten besteht, besteht der Geschäftsprozess eben aus seinen Teilaufgaben. So wie die Kompenenten zum Zwecke der Aufgabenerfüllung im System zusammenwirken, tun es die Teilaufgaben im Geschäftsprozess.

Zerlegung

Dies gilt für die „fixen und flachen“ Zustandsautomaten weniger als für die „dynamischen und tiefen“. Bei ersteren steckt die Tätigkeit nur in der Transition, als dritter Teil derselbigen.

Tätigkeit in der Transition

Bei zweiteren dagegen zusätzlich auch in den Aktivitäten im Zustand (entry-, do-, exit-activity). Hier kann man sich bereits eine Verschachtelung vorstellen, da dieses Konzept sehr dem Gegensatz von Funktions- und Prozessmodellierung ähnelt.

Tätigkeit auch im Zustand

(2) Träger der Tätigkeiten

Ein solches Konzept ist hier nicht vorgesehen. Betrachten wir zwei Beispiele. Wenn die Rechnung vom Status Neu zu Offen übergeht, gibt es keine Möglichkeit, einen Handelnden festzuhalten, obwohl es natürlich einen gibt. Wenn im Geldautomat die eingeschobene Karte gelesen wird ist ebenfalls keiner im Modell direkt erkennbar.

Der Grund ist einfach die Systemorientierung der UML-Autoren. Träger der Aktivitäten ist (implizit, unbewusst) das jeweilige System (das technische oder das Softwaresystem), da ist das Festhalten eines Trägers bei einer einzelnen „Handlung“ (einem Systemschritt) nicht sinnvoll.

Systemorientierung

(3) Informationen auf Trägern aller Art

Typ „fix und flach“

Nur ein „flaches“ Objekt

Bei diesem Typ Zustandsautomat ist das Objekt selbst (im Prozessumfeld also typischerweise ein Geschäftsobjekt) der Informationsträger, der betrachtet wird. Weitere Information findet sich in den Tansitionen. Dies sind aber Informationen, die zu den Zustandsänderungen führen, die also die „Dynamik“ des Geschehens realisieren und insofern hier nicht zählen.

Dies reicht natürlich für eine Prozessmodellierung nicht aus. Welcher Geschäftsprozess kommt schon mit nur einem (Geschäfts-)­Objekt aus?

Typ „dynamisch und tief“

Bei diesem Typ Zustandsautomat spielen „Informationen auf Trägern aller Art“ keine Rolle, da im Prozessumfeld als Objekt einfach der ganze Geschäftsprozess genommen wird, z.B. die Leistungserbringung in einem Unternehmen, und im Systemumfeld das ganze System (Geldautomat). Dann werden die einzelnen Teilaufgaben einfach hintereinander gelegt oder auch verschachtelt.

Nur ein Objekt, aber tief verschachtelt

Die einzelnen Zustände enthalten dann Automaten, Subautomaten, usw. Die Zustandsänderung besteht darin, zum nächsten Abschnitt („Zustand“) zu kommen bzw. vertikal einen Subautomaten zu betreten bzw. zu verlassen. So wie bei den im Kapitel vorgestellten Beispielen Geldautomat (vgl. insbes 13.3-10 und 13.3-11) und Telefonanlage (vgl. insbesondere Abbildung 13.5-3).

Von Informationsverarbeitung im hier gemeinten Sinn also keine Spur. Würde man also, um in einem Prozessbeispiel zu bleiben, die Leistungserbringung horizontal und vertikal so zerlegen, dass der ganze Geschäftsprozess in einen Zustandsautomaten abbildbar wäre, könnte man die einzelne Informationsverarbeitung zwar in die Zustände reinschreiben, ein Deutlichmachen der Informationsträger wäre darüberhinaus aber nicht möglich.

Keine Informations-
verarbeitung

Zur Verdeutlichung stelle man sich vor, man müsse in Abbildung 13.3-14 die im dort beschriebenen Prozess sicher zahlreichen Informationsträger (z.B. zu durchgeführten Prüfungen) im Modell ausdrücken.

Dies kann man „den Zustandsautomaten“ auch nicht vorwerfen. Aber man muss es denen sagen, die denken, man könne damit Geschäftsprozesse modellieren.

(4) Informationsverarbeitung

Hierzu gibt es eine Entsprechung in Zustandsautomaten, zumindest in denen mit dynamischen Zuständen. Die Informationsverarbeitung kann im Zustand angegeben werden. Z.B. könnte für einen Geschäftsprozess Leistungserbringung der Zustand Kalkulation die Anfangsaktivität Daten zusammenstellen, die Zustandsaktivität Kalkulation durchführen und die Schlussaktivität Ergebnis versenden haben. Klingt etwas seltsam, wäre aber von der Methode her machbar.

Informations-
verarbeitung in
Anfangs-
Zustands-
Schlussaktivitäten

Trotz aller solcher Bemühungen bliebe es bei dem im vorigen Punkt beschriebenen Defizit, dass die Informationsobjekte nur implizit vorhanden sind.

(5) Ereignisse

Ein Ereigniskonzept ist vorhanden. Ereignisse lösen die Zustands­über­gänge aus. Sie sind auch, bei dynamischen Zuständen, für die Strukturierung der Verarbeitungsschritte im Zustand verantwortlich.

(6) Kontrollfluss

Dieses Konzept liegt vor und zwar in vielfältiger Form. Zum einen durch das Zusammenwirken in der Abfolge mit Hilfe der Transitionen. Dieses Aufeinanderfolgen der einzelnen Tätigkeiten wird hier durch drei Aspekte beschrieben:

Aufeinanderfolgen

• dem Ereignis, durch das es zur Zustandsänderung kommt,
• einer Bedingung für das „Voranschreiten“ (das Eintreten des Zustandsübergangs) und
• einer Aktion, die im Zuge der Transition auszuführen ist, die also zum nächsten Zustand führt.

Zum anderen durch das Zusammenwirken über verschachtelte Elemente. Die Frage des Zusammenwirkens von Tätigkeitsfolgen verschiedener Ebenen ist gründlich gelöst (vgl. die Diskussion um orthogonale Regionen usw. oben). Wenn also eine Aufgabe in sich strukturiert ist, gibt es einen Subautomaten und auch dieser kann wiederum strukturiert sein, d.h. einen Automaten enthalten.

Tiefenstruktur

Dieses Strukturmerkmal ist für die Geschäftsprozessmodellierung sinnvoll. Mit den obigen Punkten ist eine einfache Realisierung eines Kontrollflusses, wie er für Geschäftsprozesse benötigt wird, möglich.

Trotz dieser grundsätzlichen Eignung gibt es auch Defizite. Was Zustandsautomaten zum Beispiel nicht bieten, sind äquivalente Operatoren. Im Kernbereich (wenn es nicht um orthogonale Regionen geht, die durch Transitionen parallel gestartet werden) wird nur das exklusive Oder angeboten. D.h. ein Zustand geht (aus einer Auswahl) immer zu genau einem neuen Zustand über. Das ist naheliegend für das Zustandskonzept, damit auch ein Stück weit für Systeme, aber nicht für Geschäftsprozesse.

Defizit:

Wenig
Verzweigung-
möglichkeiten

Dass es im Kernbereich keinen UND-Operator gibt, überrascht natürlich nicht. Ein Zustand kann nicht in zwei Zustände übergehen. Allerdings kann ein UND-Operator durch Verschachtelung ausgedrückt werden, wenn z.B. ein Zustand mit Regionen angelegt wird (vgl. Abbildung 13.3-2). Dies führt dazu, dass die (gegenüber Systemen) erweiterte Länge (eines Geschäftsprozesses) nur durch Verschachtelung erfasst werden kann. Typisch für Geschäftsprozesse ist aber Länge, nicht Tiefe, so dass hier insgesamt komplexe Modelle entstehen.

Kein UND

oder doch?



Länge, nicht Tiefe

Dass die UML-Autoren dieses Defizit im Kontrollflusskonzept bemerkt haben, zeigen die Pseudoknoten und ihr Umfeld (Verknüpfer, Gabelung, …). Doch diese decken das Defizit nicht wirklich. Sie wirken künstlich aufgepfropft, da bei ihnen das Grundkonzept („Zustände“) nicht mehr erkennbar ist. Vgl. die Beispiele in den Abbildungen 13.5 und 13.6. Man gewinnt an dieser Stelle den Eindruck, dass die Methode ZA unter allen Umständen prozesstauglich gemacht werden sollte.

Dieses Defizit ist ein starkes Hindernis für eine nicht-triviale Prozessmodellierung mit Zustandsübergängen bzw. Zustandsautomaten.

Hindernis

(7) Ebenen – Kapselung

Ein solches Konzept ist direkt nicht vorgesehen, könnt aber durch die im vorigen Punkt beschriebene vertikale Strukturierung gelöst werden. Wenn also z.B. der Zustand selbst sehr „abgehoben“ formuliert wird („Angebot erstellen“) und der „Subautomat“ (z.B. Kalkulation erstellen) nur angeführt, aber nicht detailliert beschrieben wird.

(8) Verweise, Verknüpfungen

Verweise und Verknüpfungen von einem Zustandsautomaten zum anderen sind direkt nicht vorgesehen, könnten aber durch ein grafisches Element (ähnlich dem Ausstiegspunkt) leicht realisiert werden.

(9) Zeitliche Dimension

Die zeitliche Dimension liegt im Kern der Methode ZA vor, als Lebenszyklus des Objekts, um das es geht. Die Bedeutung der zeitlichen Dimension zeigt sich auch darin dass die History Pseudozustände definiert werden können, sozusagen als „Netz“, in das das System im Krisenfall fällt. Mehr liegt nicht vor.

Lebenszyklus

(10) Träger

Ein ähnliches Konstrukt liegt hier in den Objekten vor, um die es beim jeweiligen Zustandsautomat geht. Also im „flachen und fixen“ Fall das Geschäftsobjekt, im „dynamischen und tiefen“ Fall der Automat.

12.6.2 Verknüpfung mit der übrigen objektorientierten Theorie

Die Verknüpfung dieses Theorieelements mit den übrigen Bereichen der objektorientierten Theorie ist ansatzweise gegeben.

Bei diesem Typ Zustandsautomat dadurch, dass das zu betrachtende Objekt ein Geschäftsobjekt sein kann, das in den Datenbeständen erfasst sein muss, sich also in der objektorientierten Datenbank finden könnte. Durch die Attribute, Methoden, usw.

Fix und flach

Eine weitere Verknüpfung ist dadurch denkbar, dass sich die Methoden in den Zustandsübergängen spiegeln.

Bei diesem Typ Zustandsautomat vor allem durch die Methoden, die sich in den Zustandsübergängen widerspiegeln. Dann aber auch durch die „activities“ der dynamischen Zustände (entry-, do-, exit), die sich in einem integrierten objektorientierten Modell als Klassenmethoden wiederfinden.

Dynamisch und tief

12.6.3 ZA und EPK im direkten Vergleich

Wenigstens kurz soll hier noch betrachtet werden, wie es um die Übertragung von Zustandsautomaten in eine Methode der Standardprozessmodellierung (hierfür wurde die Methode EPK gewählt) steht. Ist sie möglich? Wo liegen die Probleme? Mehr dazu in WebZumBuch_UM01.

Von ZD zu EPK

Angesichts der obigen Ausführungen überrscht es nicht, das die Übertragung problemlos möglich ist, wenn man sich auf die Grundstruktur – die Übergänge von einem Zustand zum anderen – beschränkt.

Das folgende Beispiel soll dies veranschaulichen. Dabei wird das Beispiel Rechnung – einfach von oben in eine EPK übertragen.

Vgl. Abbildung 13.2-6

Transitionen mit ihrem Aufbau (bei Verhaltenszustandsautomaten) Ereignis [Bedingung] Aktion können direkt in Kontrollflusselemente übersetzt werden. Im einfachsten Fall gibt das Ereignis einen Hinweis auf eine durchgeführte Aktivität, und die Aktion einen Hinweis auf die nächste zu realisierende Aktivität. Falls mehr als eine Transition von einem Zustand abgeht, gibt die Bedingung Hinweise auf die Verzweigung im Rahmen eines exklusiven Oders.

Transitionen zu Kontrollfluss-
elementen

Zustandsautomat Rechnung – einfach

Der Startvorgang des Zustandsautomaten wird einfach zu einem Startereignis. Die beiden Transitionen, die vom Zustand Neue Rechnung weggehen, sind Ausdruck des Zustellversuchs, der in der EPK als Funktion modelliert wird. Entsprechend den beiden Transitionen mit den Bedingungen Zustellung gescheitert und Zustellung gelungen wird in der Ereignisgesteuerten Prozesskette ein exklusives Oder (XOder-Operator) gesetzt.

Start

Die Aktionen bestehen in diesem Zustandsautomaten aus der jeweils notwendigen Statusveränderung. Sie wurde einmal angeführt (Rechnung ist zuzustellen [Zustellung gelungen] Status Offen setzen), ansonsten weggelassen. In der EPK müssen sie aber angeführt werden, da hier zur Syntax gehört, dass Ereignisse und Aktionen sich im Kontrollfluss ablösen müssen.

Statusänderung
=
Aktion

Auch die Zeitaspekte sind in Ereignisgesteuerten Prozessketten abbildbar. Hier wurde einfach nach der Änderung des Rechnungsstatus auf Offen eine Wartefunktion (Warten auf den Zahlungseingang) gesetzt, die entweder zum rückbuchbaren Zahlungseingang, zur erfolgten Überweisung oder zum Ablauf der Frist führt.

Zeitaspekte

Nach der rückbuchbaren Bezahlung kann dann noch eine Funktion Warten ob Rückbuchung eingebaut werden, die dann den Tatbestand erfasst, dass erst nach 6 Wochen vollständige Sicherheit bzgl. der Lastschrift vorliegt.

Die restliche EPK sollte selbsterklärend sein.

Die andere Richtung

Die Übertragung in die andere Richtung (von EPKs zu Zustandsautomaten) ist nur so möglich, dass der gesamte Geschäftsprozess als Zustand aufgefasst wird und dann in Subzustände unterteilt wird. Man nutzt in diesem Fall die ausgefeilten Möglichkeiten der Verschachtelung von „Automaten“ für die Abbildung der Prozesslogik. So etwas ist ansatzweise möglich, führt aber nicht zu überzeugenden Ergebnissen, vor allem auch nicht in der grafischen Gestaltung.

Von EPK nach ZA

Dies kann aus Platzgründen hier nicht dargestellt werden. Vgl. WebZumBuch_UM01.

12.6.4 Zusammenfassung

Nimmt man alle Faktoren zusammen (Methodenelemente, Darstellungstechnik, Methodenphilosophie,…), dann muß man feststellen, dass mit den Zustandsautomaten ganz einfach eine andere Ebene modelliert wird als in der Geschäftsprozessmodellierung. Es ist eine, die sehr nahe am zu erstellenden Programm ist.

Systemorientierung

Das macht auch die Wortwahl der UML-Autoren immer wieder deutlich, die (außerhalb der Beispiele) meist auf die programmnahe Systemebene ausgerichtet ist. Nur hin und wieder, v.a. auch in den Beispielen, wird Bezug auf Abläufe genommen, die für Geschäftsprozesse typisch sind.

Es ist im Übrigen nicht verwunderlich, dass die Verschachtelung (von Zuständen / Zustandsautomaten) so stark betont wird. Ohne diese wären Zustandsautomaten nur eine sehr eingeschränkte Angelegenheit. Mit dieser aber und mit einer bereit angelegten obersten Ebene („der ganze Geldautomat“) kann hier umfassend Systemverhalten beschrieben werden. Bis zur Programmebene, bzw. (bei technischem Gerät) bis zur technischen Realisierung.

Verschachtelung

Soweit die Antwort auf die Frage nach der grundsätzlichen Tauglichkeit der Methode ZA für die Unternehmensmodellierung (hier speziell Prozessmodellierung).

Antwort 1

Nimmt man den schon mehrfach angesprochenen Trend zur vollständigen Automatisierung von Geschäftsprozessen (vgl. auch Kapitel 14) mit in die Betrachtung, was ändert sich dann? Können Zustandsautomaten / Zustandsübergangsdiagramme in diesem Bereich für die systemnahe Prozessmodellierung eingesetzt werden (vgl. Abschnitt 15.1 für die Ebenen der Prozessmodellierung)?

Automatisierung


Neue Frage

Angesichts der oben beschriebenen Defizite ist das nur schwer vorstellbar, zumal für diese Aufgabe die Aktivitätsdiagramme zur Verfügung stehen.

Antwort 2

Ein sinnvoller Einsatz der Zustandsautomaten kann daher wie folgt umrissen werden:

• Die des Typs „fix und flach“ können für Detailanalysen komplexer Situationen rund um ein Geschäftsobjekt dienen (vgl. das Beispiel Rechnung oben).
• Die des Typs „dynamisch und tief“ können der unmittelbaren Vorbereitung der Programmierung dienen, kommen also „nach“ der Unternehmensmodellierung.

Vgl. hierzu auch die Gesamteinschätzung in Kapitel 14.