Statecharts / State Machines Historisches • 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 State Machines in UML integriert

Softwaretechnik Kapitel 11 : Zustandsdiagramme Kurt Stenzel, Hella Seebach

Softwaretechnik‐Kapitel‐11

2

State Machines in UML Verwendung in OO

State Machines in UML typische Anwendungsfälle

• bisher: Kommunikation zwischen den verschiedenen  Elementen • State Machines 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

• State Machines 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

State Machines Beispiel POST

State Machines 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

State Machines Ereignisse (events)

State Machines Ereignisse ‐ Semantik

mögliche Arten von Ereignissen: • Aufrufereignis (call event)

• 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

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 Softwaretechnik‐Kapitel‐11

7

Softwaretechnik‐Kapitel‐11

8

State Machines Aufruf‐ und Endeereignisse

State Machines Änderungsereignisse

call event • Event ist UML‐Operation, d. h. Methodenaufruf • sollte in der Klasse deklariert sein

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)

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

Softwaretechnik‐Kapitel‐11

9

Softwaretechnik‐Kapitel‐11

State Machines Signalereignisse

State Machines Zeitereignisse

signal event • Signale (signal event) Sensor, Tastatur, Exception, Timer, Interrupt etc. • Nachricht vs. Signal:

time events • State Machines kennen Timer: Ereignisse wie: ”5 Sekunden nach Eintritt in Zustand“ oder: ”am 10.01.2007 um 12:30“ • Notation: after bzw. at:

– ein definierter Empfänger vs. Signal mehrere oder Broadcast – synchron vs. asynchron

after(5 sec) [Bedingung] / Aktion

• Signale meist durch Unterklassen einer Klasse ”Signal“  modelliert • Dependency , wenn A an B ein Signal sendet • Beispiel: Timer sendet Alarme, Methode sendet  Exceptions Softwaretechnik‐Kapitel‐11

10

at(10.01.2007 12:30) [Bedingung] / Aktion

11

Softwaretechnik‐Kapitel‐11

12

State Machines Beispiel zusammengesetzte Zustände

State Machines 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‐11

13

Zusammengesetzte Zustände Betreten und Verlassen

Softwaretechnik‐Kapitel‐11

14

State Machines 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‐11

15

Softwaretechnik‐Kapitel‐11

16

State Machines parallele Zustände

parallele Zustände Betreten

• 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

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‐11

17

Softwaretechnik‐Kapitel‐11

18

parallele Zustände Verlassen

State Machines Forks und Joins

Verlassen eines parallelen Zustands • Transition von dem parallelen Zustand selbst:

• In Parallelzustände führende Transitionen mit Forks gezeichnet • Aus Parallelzuständen führende Transitionen mit Joins gezeichnet

– 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) Softwaretechnik‐Kapitel‐11

19

E1

E5 E5

E2 E3

E5

E4

E5

Softwaretechnik‐Kapitel‐11

20

State Machines Shallow History

State Machines 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‐11

21

State Machines Aktionen in Zuständen

Softwaretechnik‐Kapitel‐11

22

State Machines Konsistente Zustandskonfiguration

• Zustände können auch Aktionen enthalten:

• Nach Ausführung eines Schrittes muss eine State  Machine immer in einer konsistenten  Zustandskonfiguration sein. • Bedingungen für konsistente Zustandskonfiguration:

Zustand do / Aktion1 entry / Aktion2 exit / Aktion3 Ereignis [Bedingung] / Aktion4

– 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.

• 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 Softwaretechnik‐Kapitel‐11

23

Softwaretechnik‐Kapitel‐11

24

State Machines Konflikte

State Machines Indeterministische Schritte

• 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

Softwaretechnik‐Kapitel‐11

25

Beispiel Geldautomat

• 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‐11

26

State Machines Beispiel: Implementierung?

Softwaretechnik‐Kapitel‐11

27

Softwaretechnik‐Kapitel‐11

28

State Machines Implementierung in Java

State Machines Implementierung in Java

• Möglichkeit 1: gar nicht. Oberfläche sorgt für richtige  Reihenfolge • Möglichkeit 2: expliziter Zustand, geschachtelte if’s:

• Möglichkeit 1: gar nicht. Oberfläche sorgt für richtige  Reihenfolge • Möglichkeit 2: expliziter Zustand, geschachtelte if’s:

enterItem(...) {

enterItem(...) {

if (state == EnteringItems) then Case1 else /* state != EnteringItems */ print_errormessage

if (state == EnteringItems) then Case1 else /* state != EnteringItems */ print_errormessage

}

}

• Möglichkeit 3: Polymorphie verwenden!

Softwaretechnik‐Kapitel‐11

29

Patterns Zustand

Softwaretechnik‐Kapitel‐11

30

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‐11

31

Softwaretechnik‐Kapitel‐11

32

State Pattern Bemerkungen

Beispiel: Code POST: enterItem(...) state.enterItem(this,...);

• 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

Controlstate: enterItem(POST po, ...) { print_errormessage } class EnteringItems extends Controlstate { enterItem(POST po,...) { Case1; po.state = this; } endSale(POST po) { ... po.state=WaitingForPayment.theInstance(); } } Softwaretechnik‐Kapitel‐11

33

Softwaretechnik‐Kapitel‐11

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:

Softwaretechnik‐Kapitel‐11

34

– Definiere eine Klasse Command – Eine Unterklasse pro Kommando – Nur eine Methode execute() zum Ausführen

35

Softwaretechnik‐Kapitel‐11

36

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:

• weiterer UML Diagrammtyp: State Machines • 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

– Sortieren nach Priorität (”Scheduling“) – Gruppieren zu Transaktionen

• Problem: nicht ohne weiteres verträglich mit  Zustands‐Pattern Softwaretechnik‐Kapitel‐11

37

Softwaretechnik‐Kapitel‐11

38