Softwaretechnik. Kapitel 11 : Zustandsdiagramme. Statecharts / State Machines Historisches. State Machines in UML Verwendung in OO

Transkript

1 Statecharts / Historisches Softwaretechnik Kapitel 11 : Zustandsdiagramme Kurt Stenzel, Hella Seebach Statecharts entstanden als Verallgemeinerung von Automaten Beschreibung von Zustandsübergangsystemen Konzept unabhängig von Objekt Orientierung entwickelt von David Harel (ca. 1987) hauptsächliche Anwendung: Modellierung reaktiver, eingebetteter Systeme z. B.: Steuerung von Ampeln, Fahrstühlen, Gleisanlagen, Hardwareschaltungen etc. unter dem Namen in UML integriert Softwaretechnik Kapitel 11 2 in UML Verwendung in OO bisher: Kommunikation zwischen den verschiedenen Elementen in der OO Entwicklung: Verhalten eines Elements Element = Objekt / Teilsystem (oder Vertreter: Fassade) Beschreibung der Zustände, die ein Element beim Erhalt verschiedener Nachrichten durchläuft mögliche Lebensgeschichten (life cycles) sinnvoll für zustandsabhängige Objekte d. h. Reaktion auf Nachricht hängt vom Zustand ab in UML typische Anwendungsfälle für Session oder Use Case Controller (Ablauf muss bestimmte Reihenfolge einhalten) Protokolle zu externen Systemen (sekundäre Akteure): Modem, Chipkartenleser, Sensoren/Aktoren etc. Teilsysteme, die separat entwickelt werden: Transaktionsverwalter einer Datenbank Protokolle zwischen separat entwickelten Teilsystemen: Client Server Protokolle Softwaretechnik Kapitel 11 3 Softwaretechnik Kapitel 11 4

2 Beispiel POST Notation Zustände durch benamte Rechtecke mit abgerundeten Ecken Ein Zustand ist entweder aktiv oder nicht (dynamisch!) Transitionen durch Pfeile mit Annotation Annotation: Ereignis[Bedingung] /Aktion Alle Elemente sind optional Semantik: Wenn Zustand aktiv ist, und Ereignis eintrifft, und Bedingung wahr ist, dann Zustandsübergang und Ausführen der Aktion (andernfalls passiert nichts) Initialzustand durch Pfeil von ausgefülltem Kreis Endzustand durch Pfeil zu umkringeltem Kreis Softwaretechnik Kapitel 11 5 Softwaretechnik Kapitel 11 6 Ereignisse (events) mögliche Arten von Ereignissen: Aufrufereignis (call event) Operation [Bedingung] / Aktion Endeereignis (completion event) [Bedingung] / Aktion Änderungsereignis (change event) when(test)[bedingung]/ Aktion Signalevent Signal [Bedingung] / Aktion Timeevent after(5 sec/min/...) [Bedingung] / Aktion Ereignisse Semantik erzeugte Ereignisse werden am Ende einer sog. Event Queue einsortiert das erste Ereignis dieser Queue ist das aktive Ereignis d.h. es ist immer nur ein Ereignis aktiv Transitionen werden von aktiven Ereignissen ausgelöst nach einem Schritt ist das aktive Ereignis abgearbeitet Softwaretechnik Kapitel 11 7 Softwaretechnik Kapitel 11 8

3 Aufruf und Endeereignisse call event Event ist UML Operation, d. h. Methodenaufruf sollte in der Klasse deklariert sein completion event wird erzeugt, sobald do action ( später) des Quellzustands beendet ist Zustand ohne do action: wird sofort erzeugt meistens wird Zustand sofort wieder verlassen Änderungsereignisse change event wird erzeugt, sobald Bedingung von falsch zu wahr wechselt Beispiel: when(x > y) zu dem Zeitpunkt, wo sich die beteiligte Variablen (hier: x,y) so ändern, dass Bedingung (x > y) von falsch zu wahr wechselt oft vorkommende Fälle ( state Zustand eines anderen Objekts) when(in s) (d. h. Zustand s wurde betreten) when(not in s) (d. h. Zustand s wurde verlassen) gut, um leicht spezifizieren zu können eventuell schwierig zu implementieren (Listeners für Methoden zum Setzen von x,y) Softwaretechnik Kapitel 11 9 Softwaretechnik Kapitel Signalereignisse Zeitereignisse signal event Signale (signal event) Sensor, Tastatur, Exception, Timer, Interrupt etc. Nachricht vs. Signal: ein definierter Empfänger vs. Signal mehrere oder Broadcast synchron vs. asynchron Signale meist durch Unterklassen einer Klasse Signal modelliert Dependency <<sends>>, wenn A an B ein Signal sendet Beispiel: Timer sendet Alarme, Methode sendet Exceptions time events kennen Timer: Ereignisse wie: 5 Sekunden nach Eintritt in Zustand oder: am um 12:30 Notation: after bzw. at: after(5 sec) [Bedingung] / Aktion at( :30) [Bedingung] / Aktion Softwaretechnik Kapitel Softwaretechnik Kapitel 11 12

4 Beispiel zusammengesetzte Zustände Notation zusammengesetzte Zustände zusammengesetzter Zustand: composite state Ein Zustand kann Unterzustände haben Notation durch Schachtelung XOR Zustand : Genau einer der Unterzustände ist aktiv Schachtelungstiefe beliebig Gesamtdiagramm kann als zusammengesetzter Zustand gesehen werden Softwaretechnik Kapitel Softwaretechnik Kapitel Zusammengesetzte Zustände Betreten und Verlassen Beispiel parallele Zustände Betreten eines zusammengesetzten Zustands Transition an zusammengesetzten Zustand selbst (default entry): Betreten des initialen Unterzustands Transition an Unterzustand: Betreten dieses Unterzustands Verlassen eines zusammengesetzten Zustands Transition von einem Unterzustand aus dem zusammengesetzten Zustand heraus Transition von dem zusammengesetzten Zustand selbst: Wenn Ereignis eintritt, wird Zustand verlassen (egal, welcher Unterzustand gerade aktiv ist) Ereignis = completion event: Zustand wird verlassen, wenn Endzustand erreicht ist Softwaretechnik Kapitel Softwaretechnik Kapitel 11 16

5 parallele Zustände ein Objekt kann mehrere Zustände verwalten (Aber: Überlegen, ob nicht besser durch 2 Objekte realisiert!) ein paralleler Zustand enthält mehrere Regionen Regionen sind durch gestrichelte Linie getrennt Jede Region enthält wieder Zustände Und Semantik : in jeder Region gibt es mindestens einen aktiven Zustand Initialzustand für jede Region separat Alle aktiven Zustände reagieren simultan auf die Nachricht parallele Zustände Betreten Betreten eines parallelen Zustands Transition an zusammengesetzten Zustand selbst (default entry): Betreten der initialen Unterzustände Transition an jeweils einen Unterzustand in jeder Region (fork): Betreten dieser Unterzustände Transition an nur einen Unterzustand in einer Region: Betreten dieses Unterzustands und des initialen Unterzustands der anderen Region. Softwaretechnik Kapitel Softwaretechnik Kapitel parallele Zustände Verlassen Verlassen eines parallelen Zustands Transition von dem parallelen Zustand selbst: Wenn Ereignis eintritt, wird Zustand verlassen (egal, welche Unterzustände gerade aktiv sind) Ereignis = completion event: Zustand wird verlassen, wenn alle Endzustände in allen Regionen erreicht sind Transition von jeweils einem Unterzustand in jeder Region (join): Verlassen des Zustands, wenn alle Unterzustände aktiv sind Transition von einem Unterzustand einer Region aus dem parallelen Zustand heraus: Zustand wird verlassen (egal, welcher Unterzustand in der anderen Region gerade aktiv ist) Forks und Joins In Parallelzustände führende Transitionen mit Forks gezeichnet Aus Parallelzuständen führende Transitionen mit Joins gezeichnet E2 E1 E3 E5 E5 E5 E5 E4 Softwaretechnik Kapitel Softwaretechnik Kapitel 11 20

6 Shallow History Aktionen Pfeil zu H (istory) Zustand (flach): Der Unterzustand, aus dem der Zustand verlassen wurde, wird wiederhergestellt grob: ein Programm wird ausgeführt UML bietet Notation für ein paar übliche Konstrukte Aufruf einer Methode obj.msg(args) Erzeugung eines Objekts new classname(args) Löschen eines Objekts object.destroy() senden eines Signals send(signal) (Programme, Zuweisungen,... ) meist werden in der Aktion nur die relevanten Nachrichten an die Umgebung (oder Parallelzustände) genannt Softwaretechnik Kapitel Softwaretechnik Kapitel Aktionen in Zuständen Konsistente Zustandskonfiguration Zustände können auch Aktionen enthalten: Zustand do / Aktion1 entry / Aktion2 exit / Aktion3 Ereignis [Bedingung] / Aktion4 entry und do Action werden ausgeführt, sobald der Zustand betreten wird der Zustand kann erst verlassen werden, wenn die entry Action beendet ist die do Action wird abgebrochen, sobald der Zustand verlassen wird wenn die do Action endet, wird ein completion event ausgelöst die exit Action wird ausgeführt, sobald der Zustand verlassen wird Aktionen können auch an Ereignisse und Bedingungen geknüpft werden Nach Ausführung eines Schrittes muss eine State Machine immer in einer konsistenten Zustandskonfiguration sein. Bedingungen für konsistente Zustandskonfiguration: Falls das Zustandsdiagramm aktiv ist, ist auch immer genau ein Top Level Zustand aktiv. Falls ein zusammengesetzter Zustand aktiv ist, so ist genau einer seiner direkten Kind Zustände aktiv. Falls ein paralleler Zustand aktiv ist, so ist in jeder seiner Regionen genau ein direkter Kind Zustand aktiv. Falls ein Zustand aktiv ist, so ist auch sein Eltern Zustand aktiv. Softwaretechnik Kapitel Softwaretechnik Kapitel 11 24

7 Konflikte In einem Schritt werden immer alle ausführbaren und nicht in Konflikt stehenden Transitionen ausgeführt Faustregel: 2 Transitionen sind im Konflikt, falls ihr gleichzeitiges Ausführen zu einer inkonsistenten Zustandskonfiguration führt Verschiedene Transitionen gleichzeitig möglich Indeterminismus, falls auf gleicher Ebenen Verschiedene Ebenen: niederere Ebene hat Priorität Indeterministische Schritte Parallelität bei Aktionen: Beide Transitionen schalten (Reihenfolge indeterministisch) Ergebnis der Zuweisung unspezifiziert (X = 0: 1 oder 2 oder 3?) derartige Konflikte vermeiden Softwaretechnik Kapitel Softwaretechnik Kapitel Beispiel Geldautomat Beispiel: Implementierung? Softwaretechnik Kapitel Softwaretechnik Kapitel 11 28

8 Implementierung in Java Implementierung in Java Möglichkeit 1: gar nicht. Oberfläche sorgt für richtige Reihenfolge Möglichkeit 2: expliziter Zustand, geschachtelte if s: enteritem(...) { if (state == EnteringItems) then Case1 else /* state!= EnteringItems */ print_errormessage } Möglichkeit 1: gar nicht. Oberfläche sorgt für richtige Reihenfolge Möglichkeit 2: expliziter Zustand, geschachtelte if s: enteritem(...) { if (state == EnteringItems) then Case1 else /* state!= EnteringItems */ print_errormessage } Möglichkeit 3: Polymorphie verwenden! Softwaretechnik Kapitel Softwaretechnik Kapitel Patterns Zustand Controller mit State Pattern Name: Zustand (state) Problem: Das Verhalten eines Objekts auf eine Nachricht ist abhängig vom Zustand des Objekts. Die Methoden enthalten Fallunterscheidung über endlich viele Fälle. Lösung: eigene Klasse Zustand definieren Objekt erhält Zustand als Attribut jeder Einzelfall wird Unterklasse Methoden überladen Softwaretechnik Kapitel Softwaretechnik Kapitel 11 32

9 Beispiel: Code State Pattern Bemerkungen POST: enteritem(...) state.enteritem(this,...); Controlstate: enteritem(post po,...) { print_errormessage } class EnteringItems extends Controlstate { enteritem(post po,...) { Case1; po.state = this; } endsale(post po) {... po.state=waitingforpayment.theinstance(); } } Die Klassen des Zustands sind zustandslos! es gibt nur einen Zustand EnteringItems alle Unterklassen als Singletons realisieren! kein Speicherverbrauch parallele Zustände = mehrere Zustandsattribute Nachricht an alle schicken zusammengesetzte Zustände Klassenhierarchie Softwaretechnik Kapitel Softwaretechnik Kapitel Zustände Noch ein Problem Pattern Kommandos Manche Objekte müssen auf große Zahl von Ereignissen hören Methoden e1(), e2(),... Ereignisse verändern im Wesentlichen den Zustand alle ähnlich geht s besser? Name: Kommando (command) Problem: ein Objekt erhält viele ähnliche Kommandos/Ereignisse? Wie implementieren? Lösung: Polymorphie anwenden: Definiere eine Klasse Command Eine Unterklasse pro Kommando Nur eine Methode execute() zum Ausführen Softwaretechnik Kapitel Softwaretechnik Kapitel 11 36

10 Pattern: Kommando Diskussion Zusammenfassung execute ist ein Interpreter erlaubt: Speicherung der Kommandos in Historie Undo() für Kommandos einfach möglich: Speichere notwendige Info während execute im Kommando andere Operationen möglich: Sortieren nach Priorität ( Scheduling ) Gruppieren zu Transaktionen Problem: nicht ohne weiteres verträglich mit Zustands Pattern weiterer UML Diagrammtyp: zur Modellierung von Zuständen und Reaktion auf (externe) Ereignisse Einsatz für reaktive, eingebettete Systeme, Protokolle, Controller Strukturelemente: Zustände, Transitionen, Events zusammengesetzte Zustände, parallele Zustände, fork, join Semantik: Event Queue, aktive Zustände konsistente Konfiguration, Konflikte Implementierung: State Pattern, Command Pattern Softwaretechnik Kapitel Softwaretechnik Kapitel 11 38