Zustandsautomaten (Stichworte)

Transkript

1 Zustandsautomaten (Stichworte) Udo Kelter Zusammenfassung dieses Lehrmoduls Zustandsautomaten sind erweiterte Formen von endlichen Automaten bzw. einfachen Zustandsübergangsdiagrammen. Die UML 2.0 definiert zwei Arten von Zustandsautomaten: Verhaltenszustandsautomaten und Protokollzustandsautomaten. Beide basieren auf den gleichen Grundlagen, weisen aber diverse Detailunterschiede auf. Dieses Lehrmodul stellt vor allem die Besonderheiten von Verhaltenszustandsautomaten vor: spezielle Arten von Triggern, Pseudozustände und Transitionspfade sowie zusammengesetzte Zustände. Vorausgesetzte Lehrmodule: obligatorisch: Zustandsübergangsdiagramme Petri-Netze Stoffumfang in Vorlesungsdoppelstunden: 1.0 1

2 Zustandsautomaten (Stichworte) 2 Inhaltsverzeichnis 1 Motivation und Einordnung Steuerungsmodelle in der UML Herkunft der Konzepte von Zustandsautomaten Verhaltens- vs. Protokollzustandsautomaten Zustände 5 3 Transitionen Allgemeine Form einer Transition Arten von Triggern Guards Pseudozustände und Transitionspfade Pseudozustand Kreuzung (junction) Pseudozustand Auswahlknoten (choice pseudo state) Pseudozustand Startzustand (initial pseudostate) Pseudozustand Terminator (terminate pseudostate) Pseudozustand Gabelung (fork) Pseudozustand Vereinigung (join) Zusammengesetzte Zustände Zusammengesetzte Zustände mit nur einer Region Historien Pseudozustand flache Historie (shallow history) Pseudozustand tiefe Historie (deep history) Regionen Literatur Index Dieser Text darf für nichtkommerzielle Nutzungen als Ganzes und unverändert in elektronischer oder gedruckter Form beliebig weitergegeben werden und in WWW-Seiten, CDs und Datenbanken aufgenommen werden. Jede andere Nutzung, insb. die Veränderung und Überführung in andere Formate, bedarf der expliziten Genehmigung. Die jeweils aktuellste Version ist über erreichbar.

3 Zustandsautomaten (Stichworte) 3 1 Motivation und Einordnung Grundformen von ZÜD (endliche Automaten) und Petri-Netzen sind Kernkonzepte zur Beschreibung von sequentiellen und/oder parallelen Steuerungen / Algorithmen mit einer sehr klaren Semantik + theoretischem Fundament aber Nachteile hinsichtlich der Modellierung realer Systeme: keine Berücksichtigung von Daten und datenabhängigen Steuerungen keine Abstraktionshierarchien, durch die komplexere Modelle strukturiert und besser verstehbar / entwickelbar werden diverse Erweiterungen bessere Modellierungsfähigkeiten Verlust der klaren semantischen Grundlage, viele interessierende Eigenschaften nicht mehr entscheidbar 1.1 Steuerungsmodelle in der UML 2.0 (nach vielen Irrungen und Umwegen über die UML 1.*...) 1. Zustandsautomaten (state machines): endlichen Automaten (Mealy- und Moore-A.) + weitere Zutaten Modell = gerichteter Graph, Knoten modellieren Zustände; können Tokens beinhalten / puffern; in beschränktem Umfang auch parallele Teilzustände möglich Kanten modellieren Zustandsübergänge, hierbei komplizierte Fallunterscheidungen möglich; Kante ist i.d.r. mindestens mit einem Ereignis beschriftet 2. Aktivitätsdiagramme: Programmablaufplan + Petri-Netz Modell = gerichteter Graph,

4 Zustandsautomaten (Stichworte) 4 Knoten: modellieren Funktionen / Verarbeitungsschritte, aktive Systemteile Kanten: Kontroll- und Datenflüsse, transportieren Daten- oder Kontrolltoken zwischen Aktionen, beinhalten Ablaufsteuerung viele gemeinsame Diagrammelemente in beiden Diagrammtypen, insb. bei der Ablaufsteuerung aber teilweise verschiedene Bedeutung, Verwechslungsgefahr 1.2 Herkunft der Konzepte von Zustandsautomaten Zustandsautomaten beinhalten diverse schon erlernte bzw. andiskutierte Konzepte (werden hier nur kurz wiederholt) von Zustandsübergangsdiagrammen: Zustände mit internen Aktionen Zustandsübergänge mit Ereignissen, bedingten Transitionen und Aktionen von Petri-Netzen: Plätze als Tokenpuffer Transitionen mit mehreren Eingangs- oder Ausgangsplätzen 1.3 Verhaltens- vs. Protokollzustandsautomaten Verhaltenszustandsautomat (behavioral state machine) mit Aktionen / Verhalten an Transitionen, wie in Lehrmodul ZÜD beschrieben Protokollzustandsautomat (protocol state machine): ohne Aktionen / Verhalten an Transitionen Konzentration auf Zustandsübergänge, Darstellung der Vor- und Nachbedingungen für Zustandsübergänge Darstellung von Invarianten in Zuständen beide Arten mit gleichen Grundlagen, aber diversen Detailunterschieden; Protokollzustandsautomaten werden hier nicht detailliert behandelt

5 Zustandsautomaten (Stichworte) 5 2 Zustände Allgemeine Form eines Zustands: Zustandsname entry / Verhalten exit / Verhalten do / Verhalten Trigger [Guard] / Verhalten Trigger [Guard] / defer Verhalten bei Betreten / Aktivierung eines Zustands: 1. Zustand wird aktiv, wenn eine hereinkommende Transition durchlaufen wird 2. sofort nach der Aktivierung wird das Eintrittsverhalten (entry /...) ausgeführt wird nie abgebrochen; währenddessen ankommende Ereignisse werden in einer FIFO-Schlange gepuffert 3. sofort danach wird das Zustandsverhalten (do /...) ausgeführt Verhalten bei Verlassen eines Zustands: 1. Zustand wird verlassen, wenn ein Ereignis eintritt, das zum Durchlaufen einer herausgehenden Transition führt 2. falls das Eintrittsverhalten des aktuellen Zustands noch nicht abgearbeitet ist, wird dies erst komplett abgearbeitet 3. falls das Zustandsverhalten abläuft, wird es abgebrochen 4. danach wird das Austrittsverhalten (exit /...) ausgeführt 5. erst danach ist der Zustand inaktiv. interne Transitionen in einem Zustand (Trigger [Guard] /...): Wirkung analog zum allgemeinen Fall einer Transition, die einen Zustandswechsel bewirkt, aber kein Durchlaufen des Ein- und Austrittsverhaltens

6 Zustandsautomaten (Stichworte) 6 defer führt in bestimmten Situationen zu einer späteren Verarbeitung des Triggers (Details später) 3 Transitionen Denkweise ist stark von kommunizierenden Objekten (um nicht zu sagen GUI-Programmierung...) beeinflußt: Ereignisse (Trigger) sind i.d.r. Operationsaufrufe gemäß der Schnittstelle des Typs des Objekts Aufrufe können von anderen Objekten kommen, aber auch vom gleichen Objekt Verhalten an Transitionen fehlt häufig, weil meist das Verhalten im Zielzustand abläuft (also Zuordnung der Aktionen wie bei Moore-Automaten) Vorteil: man kann über verschiedene Transitionen das gleiche Verhalten auslösen Ereignisverarbeitung in der UML 2.0: sehr komplexes Verarbeitungsmodell diverse Details offen (semantic variation points), um verschiedene Applikationsbereiche mit gegensätzlichen Anforderungen bedienen zu können problematisch 3.1 Allgemeine Form einer Transition allgemeine Form einer Transition bei einem Verhaltenszustandsautomaten: Trigger [Guard] / Verhalten

7 Zustandsautomaten (Stichworte) 7 allgemeine Form einer Transition bei einem Protokollzustandsautomaten (ProtocolTransition): [Guard] Operation / [Nachbedingung] Besonderheiten von Protokollzustandsautomaten: nur Operationsaufrufe als Trigger Notationsreihenfolge Guard Trigger/Operation vertauscht keine Aktionen (Implementierung von Verhalten), sondern nur Nachbedingungen (Wirkung des Verhaltens) Guard in beiden Fällen gleich kompaktere Notation bei mehreren Transitionen mit gleichem Ausgangszustand, Guard, Verhalten und Zielzustand: nur ein Pfeil, unterschiedliche Trigger mit Kommata getrennt angeben 3.2 Arten von Triggern hier für Verhaltens-ZA, analog für Protokoll-ZA SignalTrigger: Empfang eines externen Ereignisses; Darstellung: Signal [Guard] / Verhalten Situation: Objekt / System ist in Zustand, empfängt externes Ereignis, im Guard genannte Bedingungen sind erfüllt; Objekt / System geht infolgedessen in Zustand über. gut für kommunizierende Objekte in verteilten Systemen geeignet (asynchrone Aufrufe) CallTrigger: Aufruf einer Operation des Objekts; Darstellung:

8 Zustandsautomaten (Stichworte) 8 Operation [Guard] / Verhalten Situation: Objekt / System ist in Zustand, empfängt Aufruf der genannten Operation mit den im Guard genannten Bedingungen und geht infolgedessen in Zustand über Schreibweise z.t. in der Form operation() Parameter der Operation können zusätzlich angegeben werden und im Guard und in den Aktionen benutzt werden. ChangeTrigger: Zustandsänderung; Darstellung: [Guard] / Verhalten Situation: Objekt / System ist in Zustand, eine der im Guard genannten Variablen ändert ihren Wert, Guard evaluiert anschließend zu WAHR, Objekt / System geht infolgedessen in Zustand über Kein expliziter Trigger, Trigger wird sozusagen implizit durch Wertänderungen generiert TimeTrigger: absolute oder relative Zeitangaben erlaubt after (3 sec/min/...) / Verhalten ,10:45 / Verhalten Trigger wird implizit durch Zeitablauf nach Betreten des Zustands bzw. Erreichen des absoluten Zeitpunkts generiert AnyTrigger: für nicht explizit genannte, restliche Trigger

9 Zustandsautomaten (Stichworte) 9 all / Verhalten Zitat UML Superstructure, 2006, Abschnitt : A transition trigger associated with AnyReceiveEvent specifies that the transition is to be triggered by the receipt of any message that is not explicitly referenced in another transition from the same vertex. Any AnyReceiveEvent is denoted by the string all used as the trigger. Kommentar überflüssig. Woanders heißt das else oder otherwise und ist klar verständlich 3.3 Guards Guards können beliebige Bedingungen enthalten, müssen zu jedem Zeitpunkt eindeutig auswertbar sein Mehrere Guards für den gleichen Trigger: zu einem Zustand können zum gleichen Trigger mehrere Transitionen mit i.a. unterschiedlichen Guards vorhanden sein Frage 1: dürfen 2 oder mehr Guards den gleichen Fall abdecken? Antwort: ja, Auswahl der Transition dann zufällig Frage 2: müssen die Guards alle Fälle abdecken? Antwort: nicht unbedingt s. folgende Folie Konventionen zur Interpretation nicht abgedeckter Fälle: 1. irrelevant: eingetroffenes Ereignis bewirkt keine Zustandsänderung und wird ignoriert entspricht der Notationskonvention in ZÜD!

10 Zustandsautomaten (Stichworte) schwerer Fehler: eingetroffenes Ereignis hätte eigentlich gar nicht kommen dürfen und kann nicht sinnvoll verarbeitet werden; System ist in einem inkonsistenten Zustand und wird beendet / Objekt wird aufgelöst ( Panik ) oder Übergang zu einer Standard- Fehlerbehandlung 3. bitte warten : eingetroffenes Ereignis ist im Prinzip OK, kommt aber zu unpassender Zeit und soll später verarbeitet werden hierzu explizite Aktionsangabe.../defer Nur an internen Transitionen erlaubt! aufgeschobenes Ereignis kommt in einen event pool zu diesem Objekt / System und löst ggf. später eine Transition aus, nachdem sich der Zustand und/oder in Guards benutzte Variablen geändert haben viele Details offen, z.b. Strategie, wie aus mehreren aufgeschobenen Ereignissen das nächste zu verarbeitende gewählt wird 4 Pseudozustände und Transitionspfade Beispiel: Auswahl anzeigen ausgewählt [rot] /... [grün] /... fertig [erfolgreich] / gratulieren alles rot alles grün fertig [Fehler] / Fehlermeldung Merkmale von Pseudozuständen:

11 Zustandsautomaten (Stichworte) 11 sind zwar Knoten im Zustandsnetzwerk, repräsentieren aber keinen Zustand! d.h. dort kann kein Token parken (Vorsicht: deswegen ist der Endzustand kein Pseudozustand!) haben ein- und ausgehende Transitionen mit teilweise unvollständigen Beschriftungen bilden Transitionspfade Transitionspfade: beginnen und enden in echten Zuständen (also Knoten, die keinen Pseudozustand repräsentieren) können beliebig lang sein können unterschiedliche Pseudozustände als Etappen haben die kompletten Pfade werden in einem Schritt ( atomar ) durchlaufen, inkl. der Prüfung aller Guards und Ausführung aller Aktionen an den Transitionen nur Transitionspfade, auf denen alle Guards erfüllt sind, können durchlaufen werden es ist zulässig, daß mehrere Guards bzw. Pfade wahr sind! dann wird ein erlaubter Pfad zufällig ausgewählt 4.1 Pseudozustand Kreuzung (junction) Darstellung als schwarzer Kreis (wie Startknoten, aber geringfügig kleiner) mit einer oder mehreren hereinkommenden und herausgehenden Transitionen einer der ausgehenden Transitionen darf else als Guard haben; ist erfüllt, wenn die Guards aller anderen ausgehenden Transitionen nicht erfüllt sind

12 Zustandsautomaten (Stichworte) 12 alle Guards werden ausgewertet, bevor irgendwelche Aktionen ausgeführt werden ( static conditional branch ) d.h. Aktionen werden erst nach Durchlaufen aller Verzweigungen ausgeführt tückisch! entspricht nicht der Lesereihenfolge Aktionen besser nur an die letzten Transitionen der (Teil-) Pfade erlauben kompakte Darstellung ähnlicher Transitionen in Transitionspfaden (s.o. Beispiel) 4.2 Pseudozustand Auswahlknoten (choice pseudo state) A stellt eine bedingte Verzweigung dar Guards wie bei einer Kreuzung, inkl. else- Konstrukt Aktionen an eingehenden Transitionen werden ausgeführt, bevor nachfolgende Guards ausgewertet werden (UML-Diktion: dynamic conditional branch )!! kann zu sehr komplizierten Ablauflogiken führen das ist der Hauptunterschied zu einer Kreuzung Raute kann innen einen Variablennamen enthalten, auf den sich die Test in den Guards beziehen (syntaktischer Zucker...) 4.3 Pseudozustand Startzustand (initial pseudostate) nur einmal erlaubt (pro Region, s.u.) nur eine ausgehende Transition erlaubt diese darf eine Aktion haben, aber keinen Trigger oder Guard

13 Zustandsautomaten (Stichworte) Pseudozustand Terminator (terminate pseudostate) stellt Löschung des Objekts / Systems dar kein Austrittsverhalten aus dem Zustand mehr (anders als beim Endzustand) 4.5 Pseudozustand Gabelung (fork) Notation wie Petri-Netz-Transition mit einem Eingangsplatz ausgehende Transitionen (bzw. Transitionspfadsegmente) dürfen keine Guards oder Aktionen haben und müssen in unterschiedlichen Regionen (s.u.) eines zusammengesetzten Zustands enden keine allgemeinen Petri-Netze hiermit darstellbar 4.6 Pseudozustand Vereinigung (join) Notation wie Petri-Netz-Transition mit einem Ausgangsplatz ankommende Transitionen (bzw. Transitionspfadsegmente) dürfen keine Guards oder Aktionen haben und müssen in unterschiedlichen Regionen eines zusammengesetzten Zustands starten 5 Zusammengesetzte Zustände Begriff zusammengesetzter Zustand faßt zwei völlig verschiedene Dinge zusammen:

14 Zustandsautomaten (Stichworte) baumartige Zustandshierarchien wie in Lehrmodul ZÜD dargestellt: ein nichtelementarer Zustand (innerer Konten des Zustandsbaums) hat mehrere Unterzustände und das System befindet sich immer in genau einem der Unterzustände 2. autarke Teilzustände wie in Petri-Netzen 1, die durch eigene Tokens repräsentiert werden autarke Teilzustände werden als Regionen repräsentiert zusammengesetzter Zustand hat i.a.: eine oder mehrere Regionen pro Region mehrere Unterzustände, darunter i.a. einen Startzustand Darstellung: durch Schachtelung der Zeichenflächen Zustandsname oft nicht innen, sondern als Reiter oben auf den Rechteck Trennung der Regionen durch gestrichelte Linie ggf. oben eigener Abschnitt mit entry / exit / do-angaben Beispiel: Geld erhalten Fahrschein drucken... Wechselg.ausgeben... Quittung fragen..[..] also zusammengesetzte Zustände im wörtlichen Sinn, der Gesamtzustand des Systems setzt sich aus den Teilzuständen zusammen

15 Zustandsautomaten (Stichworte) Zusammengesetzte Zustände mit nur einer Region Betreten eines zusammengesetzten Zustands: 1. direkter Übergang in einen Unterzustand (Explicit Entry): Transitionspfeil überquert Grenze der Zeichenfläche und endet an einem Unterzustand Z unschön, widerspricht dem information hiding über die Details des zusammengesetzten Zustands 2. Default Entry: Transitionspfeil endet an der Grenze der Zeichenfläche Z... Übergang zum inneren Startzustand und von dort aus spontan weiter... Frage: immer innerer Startzustand vorhanden? Antwot: Nein UML-Diktion: semantic variation point 2 3. Transition von innen endet an der Grenze der Zeichenfläche Z... Übergang zum inneren Startzustand und von dort aus spontan weiter; kein Durchlaufen des Aus- und Eintrittsverhaltens 2 Deutsch: niemand weiß, wie es weitergeht...

16 Zustandsautomaten (Stichworte) 16 Verlassen eines zusammengesetzten Zustands: 1. ein Endzustand wird erreicht: sofern außen eine triggerlose Transition vorhanden, wird diese ausgelöst 2. eine Transition, die für den gesamten zusammengesetzten Zustand gilt (d.h. der Transitionspfeil beginnt am Rand der Zeichenfläche), feuert 3. direkter Übergang aus einem Unterzustand nach außen (analog zum Explicit Entry): Transitionspfeil überquert Grenze der Zeichenfläche und endet außerhalb bei allen Varianten, den zusammengesetzten Zustand zu verlassen, wird das Austrittsverhalten ausgelöst 5.2 Historien Motivation: Beispiel einer Zustandshierarchie.Y4??? System ist in einem speziellen Unterzustand Beispiel: Unterzustand.Y4 des zusammeng. Zustands irgendein Trigger führt zum Verlassen des Zustands später gewünscht: Rückkehr zum gleichen Unterzustand, von dem aus der zusg. Zustand () zuletzt verlassen wurde Geht nicht mit bisherigen Mitteln, weil dieser Unterzustand nicht statisch festliegt man bräuchte ein Gedächtnis, das sich für jeden zusammengesetzten Zustand merkt, in welchem Unterzustand man das letzte Mal war

17 Zustandsautomaten (Stichworte) 17 Aufgabe: wie könnte man dieses Gedächtnis explizit mit Hilfe eines zusätzlich eingebauten Petri-Netzes realisieren? Lösung des Problems: mit Historienzuständen Pseudozustand flache Historie (shallow history) H Beispiel: dargestellt als Kreis mit H in der Mitte nur als Unterzustand eines zusammengesetzten Zustands erlaubt 0 oder 1 ausgehende zu Transition erlaubt keine von innen ankommende Transition erlaubt... H... Verhalten beim Betreten des Zustands über den Historien- Knoten: 1. wenn das System vorher schon einmal im Zustand war: seinerzeit aktiven Zustand auf dieser Verfeinerungsebene betreten 2. andernfalls, wenn vom Historien-Knoten eine Transition zu einem Zustand ausgeht: in den Zielzustand dieser Transition (default shallow history state) übergehen 3. andernfalls, wenn Startknoten auf dieser Verfeinerungsebene vorhanden: dort ausgehender Transition folgen 4. andernfalls: fehlerhaftes Modell oder unklare Situation

18 Zustandsautomaten (Stichworte) Pseudozustand tiefe Historie (deep history) H* dargestellt als Kreis mit H* in der Mitte alles wie bei flacher Historie, bis auf folgenden Unterschied Verhalten, wenn der über den Historien-Knoten erreichte Zielknoten selbst wieder zusammengesetzt ist: flache Historie: Zielknoten wird neu betreten (über den lokalen Startzustand) tiefe Historie: dort zuletzt aktiver Unterzustand wird betreten usw. rekursiv abwärts für jeden Verfeinerungsschritt muß der zuletzt aktive Zustand bekannt sein 5.3 Regionen Betreten eines Zustands mit Regionen 1. default entry: Transition endet am Rand des Zustands Wirkung: pro Region wird der Startzustand aktiviert 2. explicit entry: eine oder mehrere Transitionen (die von außen aus einer Gabelung stammen) überqueren den Rand des zusammengesetzten Zustands und enden in inneren Zuständen (pro Region max. 1)

19 Zustandsautomaten (Stichworte) 19 Wirkung: die direkt angesteuerten Zustände werden aktiv; in Regionen, in denen keine Transition endet, wird der Startzustand aktiviert Verlassen eines Zustands mit Regionen 1. wenn in allen Regionen der Endzustand erreicht und außen eine triggerlose Transition vorhanden ist: diese feuern Regionen, die schon den Endzustand erreicht haben, warten darauf, daß alle anderen Regionen ebenfalls den Endzustand erreichen und ignorieren währenddessen alle Trigger 2. wenn eine Transition für den zusammengesetzten Zustand feuert: alle internen Zustände werden sofort inaktiv 3. wenn einetransition für einen Unterzustand, die außerhalb des zusammengesetzten Zustands endet, feuert: alle internen Zustände werden sofort inaktiv, d.h. auch alle anderen Regionen werden abgebrochen Literatur [PN] Kelter, U.: Lehrmodul Petri-Netze ; 2003 [ZUED] Kelter, U.: 2003 Lehrmodul Zustandsübergangsdiagramme ;