Zustandsautomaten modellieren: Entry-, Exit- und Final-Zustände

Beim Modellieren eines Zustandsautomaten kommt man oft an den Punkt, an dem man darüber nachdenken muss, wie man in Regionen des Automaten eintritt und sie wieder verlässt. In itemis CREATE stehen dafür grundsätzlich drei strukturelle Elemente zur Verfügung, um ein gezieltes Ein-, Aus- und Abschlussverhalten des Zustandsautomaten zu definieren. Diese Elemente heißen Entry Point, Exit Point und Final State. Ein typischer Anwendungsfall für eine feinere Steuerung von Ein- und Ausstieg innerhalb eines Zustandsautomaten ist die Fehlerbehandlung als Alternative zum normalen Ausführungsfluss.

Der Entry-Pseudo-Zustand

Wenn ein Zustandsautomat startet oder der Kontrollfluss eine Region betritt, legt ein Entry fest, welcher Zustand zuerst aktiviert wird. Ein Entry ist ein sogenannter Pseudo-Zustand, hat genau eine ausgehende Transition, keinen Trigger und keine Guard-Bedingung. Er wird als gefüllter Kreis dargestellt.

Ein Entry ohne Namen wird als Default Entry bezeichnet. Er entspricht dem Initial-Zustand in UML. Eine Region enthält genau einen Default Entry. Darüber hinaus bietet itemis CREATE Named Entry Points als Alternativen, die es ermöglichen, je nach gewähltem Einstiegspunkt unterschiedliches Verhalten zu implementieren. Enthält eine Region mehrere Entries, müssen diese innerhalb der Region eindeutig benannt sein.

Das explizite Betreten einer Region über einen Named Entry erfolgt durch Angabe einer Transition Property an einer Transition, die in den umgebenden Zustand führt, in der Form: # > entry-name.

Der Zustandsautomat in Abbildung „Entry state" zeigt die Verwendung von Named Entry Points. Der zusammengesetzte Zustand Handle result enthält einen Default Entry sowie einen Entry namens failure. Die Transition von Zustand A nach Handle result legt fest, dass beim Auftreten eines Fehlerereignisses der Zustand Handle result über den Entry Point failure betreten wird, was zur Aktivierung des Unterzustands Handle failure führt.

Der Exit-Pseudo-Zustand

Ein Exit ist ein Pseudo-Zustand, der verwendet wird, um einen zusammengesetzten Zustand zu verlassen und zu deaktivieren. Exits sind das Gegenstück zu Entries. Ein Exit kann mehrere eingehende Transitionen haben, aber keine ausgehende. Er wird als ungefüllter Kreis mit einem X-förmigen Kreuz dargestellt.

Im Gegensatz zur UML erlaubt itemis CREATE, dass eine Region mehrere Exits enthält. Jeder Exit muss entweder einen eindeutigen Namen innerhalb seiner Region haben oder der einzige Default Exit sein. Wenn ein Exit erreicht wird, werden alle Zustände in den anderen Regionen desselben zusammengesetzten Zustands sofort deaktiviert – das Erreichen eines Exits in einer Region hat also gravierende Auswirkungen auf alle anderen Regionen, da diese ebenfalls verlassen werden.

Verlässt der Kontrollfluss eine Region über einen Named Exit, muss es eine ungesicherte ausgehende Transition mit einer Transition Property wie # exit-point-1 > [ exit-point-2 > ] geben, die den Exit abfängt und damit den Ausführungsfluss nach außen beeinflusst.

Entry- und Exit-Points kombinieren

Der Zustandsautomat in Abbildung „Entries and exits" zeigt, wie beide Pseudo-Zustände zusammenspielen. Er enthält zwei zusammengesetzte Zustände:

• Der zusammengesetzte Zustand Process modelliert einen Prozess mit zwei Durchläufen (Zustände A und B). Verlaufen beide Durchläufe erfolgreich, wird der zusammengesetzte Zustand über den Exit-Knoten no_problem verlassen. Tritt in A oder B ein Fehler auf, setzt sich der Ausführungsfluss zum Exit Point problem fort und verlässt den zusammengesetzten Zustand dort.
• Der zusammengesetzte Zustand Handle result ist dafür vorgesehen, das Verarbeitungsergebnis zu behandeln, ob Erfolg oder Misserfolg. Er hat zwei Entry Points: success und failure.

Die Frage ist, wie die Exit Points von Process mit den entsprechenden Entry Points von Handle result verbunden werden. Die Transition von Process nach Handle result links lautet # no_problem> >success. Das bedeutet: Wenn der Quellzustand über den Exit Point no_problem verlassen wird, soll der Zielzustand am Entry Point success betreten werden. Die Spezifikation der Transition rechts ist analog: Wenn der Quellzustand über den Exit Point problem verlassen wird, soll der Zielzustand am Entry Point failure betreten werden. Die Reihenfolge von Exit und Entry Points in einer Transition-Spezifikation ist dabei irrelevant. Entscheidend ist die Position des >-Zeichens:

• Steht das >-Zeichen rechts von einem Namen, wie in exit_name>, bezeichnet dieser Name einen Exit.
• Steht das >-Zeichen links von einem Namen, wie in >entry_name, bezeichnet dieser Name einen Entry.

Alternativ hätte Process mit zwei verschiedenen Fehler-Exit-Zuständen modelliert werden können, etwa error_1 und error_2. Damit ließe sich auf unterschiedliche Fehlerbedingungen verschieden reagieren, während beide dennoch mit einem einzigen Fluss abgefangen werden könnten. Eine Transition mit # >error_1 >error_2 problem> würde dies ermöglichen.

Der Final State

Ein Final State bezeichnet das Ende des Ausführungsflusses eines Zustandsautomaten oder einer Region und wird als ungefüllter Kreis mit einem kleineren, gefüllten schwarzen Kreis darin dargestellt. Ein Final State kann mehrere eingehende Transitionen haben, aber keine ausgehenden. Innerhalb einer Region ist nur ein Final State erlaubt, aber jede Region kann ihren eigenen Final State haben. Final States haben außer einem Namen keine weiteren Eigenschaften.

Wenn eine Region ihren Final State erreicht, hält der Kontrollfluss dort an und wartet, bis alle anderen orthogonalen Regionen – falls vorhanden – ihren jeweiligen Final State erreicht haben. Darin liegt der wesentliche Unterschied zu Exits. Das bedeutet auch, dass Final States echte Zustände im eigentlichen Sinne sind – sie können aktiv sein –, während Entry und Exit Points Pseudo-Zustände sind, die ausschließlich dazu dienen, Zustände über Regionsgrenzen hinweg zu verbinden.

Model-Driven Software Development bei itemis — Modellieren Sie Zustandsautomaten mit Entry-, Exit- und Final-Zuständen in itemis CREATE: Model-Driven Software Development →