Post on 06-Mar-2018
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013
Die State Machine –Zaubertrank der UML
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 2
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Agenda State Machine – Was ist das?
Definition, Darstellung in UML, EntwurfstippsEinsatz zur funktionalen Systemspezifikation und QualitätssicherungSysteme aus kommunizierenden State Machines
Grundforderungen der UMLEinfluss auf die ArchitekturAktive Objekte als State Machines
Entwurf, QualitätssicherungVorbereitung zur Codegenerierung
Erhöhte Systemsicherheit durch State MachinesÜberwachung von Hardware und Nutzern und gegenseitige ÜberwachungDefinition und Kontrolle von Protokollen
Einsatz in Integration und TestHardware- und BenutzersimulationTestautomaten
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 3
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Was ist überhaupt eine State Machine?
(Finite) State Machine = Zustandsautomat (Endlicher Automat)
Beim Stichwort "Automat" müssten doch alle Glocken klingen:Kaffeeautomat
Geldautomat
Einparkautomatik
Automatisierungstechnik
Büroautomatisierung
Automatisches Getriebe
...
Aber nur Wenige sehen da einen Zusammenhang.Warum eigentlich?
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 4
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Was ist ein Endlicher Automat?
Für Informatiker vielleicht ein Horror aus dem Studium."Automatentheorie und formale Sprachen": Durchfallquoten > 60%Auszug Wikipedia:
Für Andere ein Horror, weil sie davon gehört haben."Das ist so theoretisch, das ist nur was für promovierte Informatiker."
Für die Wenigen, die übrig bleiben, ein Ansatz zur Lösung (fast) aller Probleme.
Automatisierung mit Automaten – was denn sonst?
( beim ( beim MealyMealy--AutomatenAutomaten))
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 5
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Was ist ein Endlicher Automat?
Das Ganze mal ganz einfach:Ein "Endlicher Automat" ist ein (Teil-)System, das sich zu jedem Zeitpunkt in einem von endlich vielen stationären Zuständen (State) befindet.
Trifft ein Ereignis (Event) ein, das in diesem Zustand definiert ist, so führt der Automat in (theoretisch) unendlich kurzer Zeit einen Übergang in einen neuen Zustand aus (Transition). Dabei können Aktionen ausgeführt werden.
Aktivitäten, d.h. Aufgaben, die nicht in unendlich kurzer Zeit erledigt werden können, können nur während des Aufenthalts in einem State bearbeitet werden. Sie können durch ein Event abgebrochen werden oder sich selber beenden; Letzteres führt zu einem "Completion Event" an sich selbst.
Ein "Erweiterter Endlicher Automat" verwaltet außer seinem Zustand noch weitere Variable, die den Zustandsübergang beeinflussen und in Aktionen geändert werden können.
Darstellung (hier): UML State Machine Diagram
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 6
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
stm KaffeeautomatGesamt
Ruhe Auswahl Bezahlen
Zubereiten Wechselgeld ausgeben
Warten
taste muenze
[zu viel]
fertig
taste muenze
fertig
[passt]becher_entnommen
Darstellung eines Endlichen Automaten in UML
Beispiel: Kaffeeautomat (noch ohne Aktionen)Dieser Automat wird ein mal initialisiert und arbeitet dann als Kreisprozess
State
Event Transition
Guard Condition
InitialPseudostate
kein Event Auslösung durch
"completion event"
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 7
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
stm GesamtMitActions
Ruhe
entry / zeigHinweis(bereit)
Auswahl
entry / ermittleGetraenkentry / zeigAuswahl
Bezahlen
entry / berechneRestbetragentry / zeigRestbetrag
Zubereiten
entry / zeigHinweis(zubereiten)do / zubereitenexit / zeigHinweis(entnehmen)
Wechselgeld ausgeben
do / wechselgeld_ausgeben
Initial
Warten
becher_entnommen [zu viel][passt]
muenze
muenze
taste
taste
Darstellung eines Endlichen Automaten in UML
Jetzt mit Actions und ActivitiesImmer noch Entwurfsstadium:
exit: Wird immer ausgeführt, wenn der State verlassen wird
do: Wird ausgeführt, bis es sich selbst beendet oder durch ein Event abgebrochen wird
entry: Wird immer ausgeführt, wenn der State betreten wird
Completion Event etwas genauer: Wird immer dann
erzeugt, wenn der State alle entry- und do- Befehle
ausgeführt hat, falls vorhanden, sonst sofort nach
dem Betreten des State.
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 8
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Wie kommt man darauf?z.B. aus User Stories:
Als Kunde möchte ich Wahltasten drücken, um mein Getränk zu wählen.Als Kunde möchte ich nach jedem Tastendruck angezeigt bekommen, was ich gewählt habe, was es kostet, und was ich dazu wählen kann.Als Kunde möchte ich nach der Auswahl Münzen einwerfen, um zu bezahlen.Als Kunde möchte ich nach jedem Münzeinwurf angezeigt bekommen, wie viel ich noch bezahlen muss.Als Kunde möchte ich, dass mein Getränk zubereitet wird, sobald ich genug bezahlt habe, und dass mir das angezeigt wird.Als Kunde möchte ich Wechselgeld bekommen, wenn ich zu viel bezahlt habe.Als Kunde möchte ich angezeigt bekommen, wann ich meinen Becher entnehmen kann, damit ich das nicht zu früh tue oder unnötig warte.Als Kunde möchte ich informiert werden, wenn der Automat wieder bereit ist.
Entwurf eines Automaten
stm GesamtM itActions
Ruhe
entry / ze igHinweis(bere i t)
Ausw ahl
entry / erm i ttleGetraenkentry / ze igAuswahl
Bezahlen
entry / berechneRestbetragentry / ze igRestbetrag
Zubereiten
entry / ze igHinweis(zubere i ten)do / zubere i tenexi t / ze igHinweis(entnehm en)
Wechselgeld ausgeben
do / wechselge ld_ausgeben
Ini tia l
Warten
becher_entnom m en [zu vie l ][passt]
m uenze
m uenze
taste
taste
Jetzt aus der Sicht des Automaten:Ich bin ein Kaffeeautomat im Ruhezustand.
Jemand beginnt, Tasten zu drücken.Ich zeige ihm nach jedem Tastendruck, was er
gewählt hat, was es kostet, und was er noch dazu wählen kann.
Jemand beginnt, Münzen einzuwerfen.
Ich zeige ihm nach jeder Münze, wie viel er noch zahlen muss.
Wenn er genug bezahlt hat, bereite ich sein Getränk zu und zeige ihm das an.
Wenn er zu viel bezahlt hat, gebe ich ihm außerdem Wechselgeld aus.
Wenn das Getränk fertig ist, zeige ich ihm das an.
Jemand nimmt den Becher aus der Halterung.Ich bin wieder startbereit und zeige das an.
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 9
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Wo stehen wir?
Dies ist ein Automat auf Analyse-Niveau (so soll das System funktionieren) ohne informationstechnische Details.
In meinen Augen die einfachste und präziseste funktionale Spezifikation, besser als viele Seiten Text, und gleichzeitig auch eine Benutzeranleitung!Ein anderer Kunde hätte es vielleicht lieber so:
stm GesamtMitActions
Ruhe
entry / zeigHinweis(bereit)
Auswahl
entry / zeigAuswahl
Bezahlen
entry / zeigRestbetrag
Zubereiten
entry / zeigHinweis(zubereiten)do / zubereitenexit / zeigHinweis(entnehmen)
Wechselgeld ausgeben
do / wechselgeld_ausgeben
Warten
becher_entnommen[zu viel]
[passt]
muenze
muenze
taste
tasteBezahlen
entry / berechneRestbetragentry / zeigRestbetrag
stm AndereVersion
Ruhe
entry / zeigHinweis(bereit)
Auswahl
entry / zeigAuswahl
Bezahlen
entry / zeigRestbetrag
Zubereiten
entry / zeigHinweis(zubereiten)do / zubereitenexit / zeigHinweis(entnehmen)
Wechselgeld ausgeben
do / wechselgeld_ausgeben
Warten
start [zu viel]start [passt]
taste
becher_entnommenstart [zuviel]
start[passt]
muenze
muenze
taste
tasteBezahlen
entry / berechneRestbetragentry / zeigRestbetrag
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 10
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
stm GesamtMitActions
StateTrigger taste muenze becher_entnommen ce <None>
Ruhe Auswahl
Auswahl Auswahl Bezahlen
Bezahlen Bezahlen
[zu viel]
Wechselgeld ausgeb...
[passt ]
Zubereiten
Zubereiten Warten
Wechselgeld ausgeben
Zubereiten
Warten Ruhe
Initia Ruhe
Qualitätssicherung der AnforderungenAutomatische Umwandlung in State-Trigger-Matrix (macht das Tool)Systematische manuelle Überprüfung aller Leerfelder nach den Kriterien
nicht möglich
ignorieren
vergessen
Syst.-Fehler
User-Fehler
repräsentiert das Completion Event
ignorieren
User-Fehler
User-Fehler
User-Fehler
vergessen
Syst.-Fehler
Syst.-Fehler User-Fehler
ignorieren
ignorieren
User-Fehler
User-Fehler
User-Fehler
User-Fehler
Syst.-Fehler
Syst.-Fehler
ignorieren
ignorieren
Syst.-Fehlervergessen ignorieren ignorieren
es kommt kein erwartetes Event
Entwurf überprüfen!
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 11
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Weiter im Entwicklungsprozess:
Die Leistungsfähigkeit der Objektorientierung beruht auf der Arbeitsteilung zwischen selbständigen spezialisierten Objekten.
Zum Finden dieser Objekte kann ein Use Case-, ein Aktivitäts- oder ein BPMN- Prozessdiagramm beitragen.
Jedes dieser Objekte benötigt eine funktionale Spezifikation, z.B. als Endlicher Automat.
Zur Bewältigung der Gesamtaufgabe müssen diese Objekte mit einander kommunizieren.
Daraus entsteht ein System aus kommunizierenden Zustandsautomaten.Ein Event kann dann eine Nachricht von einem anderen Automaten sein, eine Action das Senden einer Nachricht an einen anderen Automaten.
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 12
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Weiter im Entwicklungsprozess:Systemarchitektur
Dazu gibt es in der UML einige Basisannahmen:6.2.1 The Basic Premises
There are two fundamental premises regarding the nature of UML semantics. The first is the assumption that all behavior in a modeled system is ultimately caused by actionsexecuted by so-called “active” objects (see “Class (from Communications)” on page 436). This includes behaviors, which are objects in UML 2, which can be active and coordinate other behaviors. The second is that UML behavioral semantics only deal with event-driven, or discrete, behaviors
13.3.8 Class (from Communications) ...A class may be designated as active (i.e., each of its instances having its own thread of control ) or passive (i.e., each of its instances executing within the context of some other object). A class may also specify which signals the instances of this class handle.
2.1 Language UnitsThe modeling concepts of UML are grouped into language units. ... For example, the State Machines language unit enables modelers to specify discrete event-driven behavior using a variant of the well-known statecharts formalism, while the Activities language unit provides for modeling behavior based on a workflow-like paradigm...
1
2
3
4
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 13
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Weiter im Entwicklungsprozess:
Also: UML-Systeme sind event driven.Sind unsere Systeme überhaupt dafür geeignet?
Automatisierungssysteme sind event driven.
Dialogsysteme sind event driven.
Die meisten kommerziellen Systeme sind event driven und eignen sich daher eigentlich gar nicht für die Modellierung als Activity Diagram oder BPMN –Prozessdiagramm!
Das Verhalten eines Systems wird ausschließlich durch kommunizierende nebenläufige aktive Objekte bestimmt.
Diese wiederum werden als State Machines modelliert.
Also: Jedes System besteht aus kommunizierenden Zustandsautomaten!Das vereinfacht auch die Architekturentwicklung und den Test.
...while the Activities language unit provides for modeling behavior based on a workflow-like paradigm...
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 14
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Ereignissteuerung im Business ProcessEreignis
Ereignis
treffpunkt.buedinger.name
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 15
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Weiter im Entwicklungsprozess: ArchitekturWie beeinflussen State Machines die Architektur?
Eine Architektur hat (mindestens) zwei Aspekte:die statische Struktur des Systems (Layers, Tiers, Komponenten / Subsysteme),die Arbeitsweise des Systems (Event Driven, Data Flow, Data Centered, MVC...).
Der Business Logic Tier besteht ausschließlich aus kommunizierenden Zustandsautomaten, also Aktiven Objekten; das System ist Event Driven. Events sind nicht geeignet, große Datenmengen zu transportieren; die Schnittstellen zwischen Subsystemen / Komponenten müssen einfach sein.
Wenn eine größere Datenmenge mehrere Bearbeitungsschritte durchlaufen soll, wird sie zentral abgelegt und nur eine Referenz / ein Schlüssel durchgereicht.
do-Aktivitäten erschweren die Nebenläufigkeit in Unterobjekte auslagern!Kommunizierende State Machines machen ein System grundsätzlich flexibel; die Architektur sollte das unterstützen.
Dazu tragen MVC, eine Service-orientierte Sicht von Subsystemen / Komponenten und deren Entkopplung durch Command Pattern und Message Passing bei.
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 16
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Weiter im Entwicklungsprozess:
Use Case-Diagramm zum Finden der Subsysteme als Services:Das funktioniert übrigens auch für andere Verkaufsvorgänge!
Auftragsverwaltung Auslieferung
Kassierer
uc UseCase
Kaffeeautomat
Kunde
Kaffee kaufen
Auftrag erstellen
Bezahlen
Produkt liefern
«include»
«include»
«include»
Handel
Produkt
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 17
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
class Architektur
Auftragsv erwaltung
- auftragscode: int
+ bezahlt(betrag) : void+ l ieferstatus(status) : void+ taste(code) : void
Kassierer
- preis: int- bezahlt: int
+ kassiere(betrag) : void+ kassiert(muenze) : void
Auslieferung
+ liefere(auftragscode) : void+ fertig(dosierer) : void+ becher_da() : void+ becher_weg() : void
Tastenfeld Anzeige
+ zeige(was, wert) : void
Becherspender
+ gibBecher() : void
Dosierer
- name: int- eichung: int
+ dosiere(rezept) : void+ stopp() : void+ fertig() : void
Münzprüfer Wechselgeldspender
+ gib_aus(betrag) : void
Getraenkekarte
- getraenkeliste: Getraenk *
+ gibName(code) : char *+ gibPreis(code) : int+ gibRezept(code) : char *
next
1
Weiter im Entwicklungsprozess: ArchitekturSystemarchitektur Kaffeeautomat als Klassendiagramm
Subsysteme
aktives Objekt
Plattform (nicht dargestellt): I/O, Timer, Scheduling, Message Passing
User Interface
Datenhaltung
Layers
MVC
Event Driven
3-Tier-Architektur
Chain Of Responsibility
Events des Zustands-automaten
Business Logic Tier
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 18
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
stm Auslieferung
Ruhe
entry / Auftragsverwaltung.l ieferstatus(bereit)
Becher_spenden
entry / Becherspender.gib_Becherentry / Anzeige.zeige(zubereiter, zubereitung)
Zubereiten
do / Dosierer_steuern
Ausgabe
entry / Anzeige.zeige(zubereiter, entnehmen)
Init
after(5 s)/Anzeige.zeige(zubereiter,entnahmefehler)
becher_weg/Dosierer.stopp
fertig
becher_dabecher_weg
liefere
Weiter im Entwicklungsprozess: VerfeinerungVerfeinerung des Automaten "Auslieferung"
Die Verfeinerung ist gut genug (für Codegenerierung), wennjede Action als einfaches C++ (Java, Cobol...) -Statement formulierbar ist,
jedes Event eine Nachricht von einem anderen Objekt oder ein HW-Event ist.
?Zubereiten
entry / rezept = Getraenkekarte.gibRezept(code)entry / Dosierer.dosiere(rezept)entry / Dosierer.fertig
fertig
stm Auslieferung
Ruhe
entry / Auftragsverwaltung.lieferstatus(bereit)
Becher_spenden
entry / Becherspender.gib_Becherexit / Anzeige.zeige(zubereiter, zubereitung)Init
l iefere
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 19
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
stm Zubereiter
State
Trigger liefere
E0
becher_weg
E1
becher_da
E2
fertig
E3
after(5 s)
E4
<None>
E5
S0Ruhe S1
S1Becher_spenden S2
S2Zubereiten S0 S3
S3Ausgabe S0 S3
S4Init S0
Weiter im Entwicklungsprozess: Qualitätssicherung Wieder: Qualitätssicherung von Zustandsautomaten
Automatische Umwandlung in State-Trigger-MatrixÜberprüfung aller Leerfelder: vergessen, ignorieren, unmöglich, Fehlerfall?
Sensorfehler Tasse des Kunden? unmöglich unmöglich
ignorieren unmöglich unmöglich
ignorieren
unmöglichignorieren
unmöglich
Sensorfehler
Sensorfehler
Sensorfehler
ignorieren
Systemfehler
Systemfehler
Systemfehler
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 20
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Ereignis
Ereignis
treffpunkt.buedinger.name
Geht das auch im Business-Sektor?Klar! Zur Erinnerung:
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 21
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Kommunizierende Automaten im Business Process
stm Ersatzteilbeschaffung
Angebotsanforerung
entry / Lieferant.biete_an(teil)
Bestellung
entry / Lieferant.auftrag(teil)Teil_defekt
Anfrage
entry / Lieferant.verfuegbar(teil)verfuegbar
wareneingang
angebot
nicht_verfuegbar
Diese Automaten stellen nicht die Arbeitsweise einer Maschine, sondern den Lebenslauf eines Geschäftsprozesses dar!
stm Auftrag
Bestandspruefung
entry / pruefeBestandentry / Kunde.verfuegbarkeit
Angebotserstellung
entry / Kunde.angebot
verfuegbarVersand
do / wareVersendenbestellunganfrage
Automat wird neu erzeugt... ...und wieder vernichtet
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 22
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
stm Auftrag
Bestandspruefung
do / pruefeBestand
Angebotserstellung
do / erstel leAngebot
biete_an ErwarteAuftrag
entry / Kunde.angebot
Versand
do / wareVersendenErledigt
auftrag
[nicht_verfügbar]/Kunde.absage
[verfügbar]
Kommunizierende Automaten im Business Process
Es könnte sein, dass
•es nicht nur einen möglichen Lieferanten gibt,
•ein Lieferant nicht liefern kann oder nicht antwortet,
• ein Angebot nicht akzeptabel ist
stm Ersatzteilbeschaffung
Angebotsanforerung
entry / Lieferant.biete_an(teil)
Angebotspruefung
do / pruefeAngebot
Bestellung
entry / Lieferant.auftrag(teil)
Lieferantenauswahl
do / sucheLieferanten(teil)Teil_defekt
Erledigt
[gefunden]
wareneingang
[unpassend]
[passend]
absageafter(T1) angebot
Etwas sinnvoller
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 23
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Endlicher Automat im Business Process ModelingWie kommt man darauf?z.B. wieder durch Rollenstudium:
Ich bin Einkäufer der Firma d&d.Jemand bittet mich, ein Maschinenteil zu beschaffen.
Ich lege einen Bestellvorgang an.Ich suche einen für diese Art von Maschinenteil geeigneten Lieferanten.Ich fordere von ihm ein Angebot an.
Der Lieferant teilt mit, dass er nicht liefern kann.Der Lieferant antwortet nicht.Der Lieferant sendet ein Angebot.
Ich prüfe das Angebot.Das Angebot ist nicht akzeptabel.Das Angebot ist in Ordnung.Ich sende dem Lieferanten einen Auftrag.
Das Maschinenteil wird geliefert.Ich schließe den Bestellvorgang.
stm Ersatzteilbeschaffung
Angebotsanforerung
entry / Lieferant.biete_an(teil)
Angebotspruefung
do / pruefeAngebot
Bestellung
entry / Lieferant.auftrag(teil)
Lieferantenauswahl
do / sucheLieferanten(teil)Teil_defekt
Erledigt
[gefunden]
wareneingang
[unpassend]
[passend]
absageafter(T1) angebot
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 24
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Endlicher Automat im Business Process ModelingIn der ganzen Angelegenheit fehlte noch der Bezahlvorgang, z.B. Lieferant:
Wir finden auch ohne Use Case Diagram leicht die Service-SubsystemeAuftragsverwaltungLagerverwaltung Einziger Unterschied zum Kaffeeautomaten!AuslieferungKassierer
stm Auftrag_Zahlung
Bestandspruefung
do / pruefeBestand
Angebotserstellung
do / erstelleAngebot
biete_an(teil) Erw arteAuftrag
entry / Kunde.angebot
Versand
do / wareVersendenexit / Kunde.rechnungErledigt
Zahlung
do / zahlung_buchenauftrag
[nicht_verfügbar]/Kunde.absage
[verfügbar]
zahlung
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 25
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
class Lieferant
Auftragsv erwaltung
+ biete_an(kunde, teil) : void+ verfuegbar(artNr) : void+ nicht_da(artNr) : void+ auftrag(kunde, teil) : void+ versandt(auftrNr) : void+ bezahlt(auftrNr) : void
Lagerv erwaltung
+ pruefe(teil) : void+ gib(artNr) : void
Auslieferung
+ liefere(auftrNr) : void+ nimm_teil(artNr) : void+ versandt(auftrNr) : void
Kassierer
+ kassiere(auftrNr) : void+ kosten(auftrNr, betrag) : void+ zahlung(ReNr, betrag) : void
Versand
+ versende(auftrNr) : void
Artikel
+ artNr: int+ preis: int+ name: char[]
Sekretariat
+ schreibAngebot(auftrNr) : void+ schreibRechnung(auftrNr) : void+ schreibAbsage() : void
Auftrag
+ auftrNr: int+ kdNr: int+ status: int
Datenbank
+ neuerArtikel(artikel) : int+ neuerKunde(kunde) : void+ neuerAuftrag(kunde, teil) : int+ gib_Preis(artNr) : int+ gib_Auftrag(auftrNr) : Auftrag+ schliess_Auftrag(auftrNr) : void
Kunde
+ kdNr: int+ name: char[]+ adresse: char[]
1..*
1..*
*
*
1..* 1
Lieferant: Architektur
Um die Ablaufsteuerung von zeitraubenden Tätigkeiten frei
zu halten
Data Centered
Event Driven
Plattform (nicht dargestellt): I/O, Timer, Scheduling, Message Passing
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 26
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Lieferant: State Machine Auftragsverwaltung
stm Auftragsv erwaltung
RuheAngebot
entry / kdNr = Datenbank.neuerKundeentry / auftrNr = Datenbank.neuerAuftragentry / Lagerverwaltung.pruefe
Auftrag
entry / Lagerverwaltung.pruefe
Absage
entry / Sekretariat.schreib_Absage
Liefern
entry / auftrNr = Datenbank.neuerAuftragentry / Auslieferung.l iefere(AuftrNr)
bezahlt(auftrNr)/Datenbank.schliessAuftrag(auftrNr)
versandt(auftrNr)/Kassierer.kassiere(auftrNr)
verfuegbar
nicht_da
nicht_da
verfuegbar/Sekretariat.schreibAngebot(auftrNr)
auftrag
biete_an
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 27
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Aber die State Machine kann noch mehr!Überwachung der Hardware
Wenn ein Gerät in Ruhe ist, dürfen keine Sensoren ansprechenBeispiel Becherspender: Kein Signal vom Bechersensor im Ruhezustand
Wenn ein Gerät arbeitet, müssen eventuell vorhandene Sensoren richtig ansprechen.
Beispiel: Wenn ein Aufzug fährt, muss ein Sensor, der die Anwesenheit des Korbs an einer Position feststellt, zeitgerecht ansprechen und wieder abfallen.
Ein Gerät benötigt eine bestimmte Zeit, um einen Auftrag auszuführen. Wird diese Zeit erheblich überschritten, liegt wahrscheinlich ein Defekt vor.
Beispiel Becherspender: Vom Befehl "gibBecher" bis zum Ansprechen des Bechersensors ("becher_da") dürfen nicht mehr als zwei Sekunden vergehen.Beispiel Dosierer: Vom Befehl "dosiere" an einen Dosierer bis zu seiner Fertigmeldung dürfen nicht mehr als zehn Sekunden vergehen.Diese Art von Überwachung ist leicht einzubringen (time event: "after(t)"); die Reaktion kann sehr aufwändig werden.
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 28
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Aber die State Machine kann noch mehr!Gegenseitige Überwachung von Objekten
Ein Objekt sendet eine Anfrage an ein anderes. Kommt innerhalb einer bestimmten Zeit keine Antwort, liegt wahrscheinlich ein Defekt vor.
Beispiel: Ein Kunde sendet an einen Lieferanten eine Anfrage. Kommt innerhalb von drei Werktagen keine Antwort, arbeitet der Lieferant nicht ordnungsgemäß.
Überwachung von UsernEin User darf ein Gerät nicht blockieren. Wartet er mit seinen Eingaben zu lange, wird er aufmerksam gemacht oder sein Vorgang abgebrochen.
Beispiel Auslieferung: Hat der Kunde nach der Aufforderung, den Becher zu entnehmen, nicht innerhalb von 5 Sekunden reagiert, bekommt er ein Blinksignal.
Beispiel Kassierer: Zwischen zwei Münzeinwürfen dürfen nicht mehr als 10 Sekunden vergehen, der gesamte Zahlvorgang darf nicht länger als 20 Sekunden dauern. Sonst erfolgt ein Abbruch.
Chaotische User-Aktionen dürfen keinen Schaden anrichten.
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 29
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Aber die State Machine kann noch mehr!Spezifikation und Überwachung von Protokollen
Ein Protokoll ist die Definition aller möglichen Folgen von Signalen, die bei korrekter Funktion auftreten können.
Ein Protokoll kann durch eine Formale Sprache oder durch eine Protocol State Machine spezifiziert werden; das ist ein Zustandsautomat ohne Aktionen.
Unsere bisherigen State Machines waren Behavior State Machines.
Dieselbe State Machine kann auch benutzt werden, um im Betrieb das richtige Verhalten eines Systems zu kontrollieren.
Ruhe
entry / Auftragsverwaltung.lieferstatus(bereit)
Becher_spenden
entry / Becherspender.gib_Becherentry / Anzeige.zeige(zubereiter, zubereitung)
Ausgabe
Init
Zubereiten
entry / rezept = Getraenkekarte.gibRezept(code)entry / Dosierer.dosiere(rezept)entry / Dosierer.fertig
after(5 s)/Anzeige.zeige(zubereiter,entnahmefehler)
becher_weg/Dosierer.stopp
becher_weg
fertig/Anzeige.zeige(zubereiter,entnehmen)
becher_da
liefere
Wie geht das?Alle Leerfelder der State-Event-Matrix werden mit "Fehler" belegt.Die Protocol State Machine wird der Behavior State Maschine vorgeschaltet, oder:Die gewünschte Behavior State Machine wird als Protocol State Machine entworfen und dann ohne Änderung der Struktur durch Aktionen ergänzt.
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 30
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Aber die State Machine kann noch mehr!Spezifikation und Überwachung von User-Eingaben
Auch die zulässigen User-Eingaben sind durch ein Protokoll beschreibbar.Beispiel Kaffee-AutomatDetaillierte Spezifikation, welche Aktionsfolgen möglich sind Quelle für Benutzerhandbuch
stm Protokoll
Ruhe Zutaten
ZahlungZubereitung
Getraenkwahltaste(code)
zutattaste(code)
muenze(wert)
muenze(wert)
[genug]
becher_weg
zutattaste(code)
wahltaste(code)
zutattaste(code)muenze(wert)abbruch
abbruch
abbruch
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 31
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Weiter im Entwicklungsprozess: Implementierung und TestAus einem Zustandsautomaten kann problemlos automatisch Code generiert werden.
Dazu benötigt man nur eine Plattform, die HW-Zugriffe, Betriebssystems- und Timerdienste anbietet.Das bedeutet: Wenn Plattform und Codegenerator vorliegen, ist das State Machine Diagram bereits das Programm!Das bedeutet auch: Ein Test des Codes ist eigentlich ein Test des Modells!Nebeneffekt: Es ist nicht sinnvoll, Testfälle für den Code aus dem selben Modell herzuleiten und/oder den Wert von "state" für den Test auszulesen.
Es ist besser, Testfälle direkt aus der Spezifikation zu erzeugen (z.B. aus User Stories) in der Form Anreiz Antwort.Daraus lässt sich wiederum ein Testautomat als State Machine entwickeln.Für den Test fehlende HW kann ebenfalls als State Machine simuliert werden.Auch das Benutzerverhalten kann als State Machine simuliert werden.Aus allen wird der Code automatisch generiert wenig Aufwand.
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 32
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Weiter im Entwicklungsprozess: Implementierung und TestBeispiel: Simulation des Becherspenders mit User (entnimmt Becher)
Reaktionszeiten von HW und User durch Zufallsgenerator erzeugt
stm Becherspender
Ruhe
exit / t = 1200 + rnd()%1000
Ausgeben
entry / becher--exit / t = 1000 + rnd()%9000
Becher_bereit
entry / Zubereiter.becher_daexit / Zubereiter.becher_weg
KeinBecher
gib_Becher[becher != 0]
after(t)gib_Becher[becher == 0]
after(t)
/becher = 100
after(3000)
100 Becher Vorrat
HW benötigt 1200 – 2200 ms, bis Becher da ist
Kunde benötigt 1000 –10000 ms, um Becher
zu entnehmen
Vorrat allekein Becher innerhalb 3 s
Simulierte Sensorsignale
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 33
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Becherspender
Becherspender
Weiter im Entwicklungsprozess: Integration und TestBeispiel: Testautomat für "Auslieferung"isolierter Test/ integriert mit Becherspender
Initialisierungsmeldung der Auslieferung
Wichtig für XP & Co.!
stm Testautomat
WarteAufInit Ruhe
entry / Auslieferung.l iefere
Spenden1 Spenden2
Zubereiten1Zubereiten2Zubereiten3
entry / Auslieferung.fertig
SpendenFertig
entry / Auslieferung.becher_da
Ausgabe
entry / Auslieferung.becher_weg
Zubereiten4
entry / Auslieferung.Becher_weg
Abbruch
l ieferstatus(bereit)
fertig [rnd()%10 == 0]
stopp
zeige(auslieferung,entnehmen)
lieferstatus(bereit)
fertig [else]
dosiere
gib_Rezept
zeige(ausl ieferung,zubereitung)
gib_Becher
zeige(auslieferung,zubereitung)
gib_Becher
lieferstatus(bereit)
In 10% der Testfälle wird der Becher
vorzeitig entnommen
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 34
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Umleitung von Nachrichten leicht gemacht Vorteile einer Message-Passing-Architektur für Integration und Test:
Alle Nachrichten laufen über den Kommunikationsdienst und können dort leicht beobachtet und aufgezeichnet werden.Komponenten sind beliebig austauschbar und Nachrichten beliebig umleitbar.
Eine solche Komponente kann dann auch ein HW-Simulator, ein Testautomat oder ein Message Tracer sein.Durch Umleitung von Nachrichten über eine Kommunikationsschnittstelle können Test- und Integrationshilfen auch auf einer anderen Hardware installiert werden.
Sim
ulat
or
Test
auto
mat
Allgemeine Dienste
Sim
ulat
or A
Test
auto
mat
Sim
ulat
orB
Mes
sage
Trac
er
Allgemeine Dienste
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 35
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Fazit:(Kommunizierende) Zustandsautomaten sind die natürliche Lösung für technische und kommerzielle Automatisierungsaufgaben aller Art. Ihr Einsatzgebiet reicht von der funktionalen Systemanalyse über die Spezifikation der Benutzeroberfläche und der einzelnen Komponenten bis zur detaillierten Objektspezifikation als Grundlage für automatische Codegenerierung.(Kommunizierende) Zustandsautomaten sind auch eine gute Alternative für Business Process Modeling anstelle von Aktivitätsdiagrammen der UML oder Prozessdiagrammen der BPMN, denn Geschäftsprozesse sind keine kontinuierliche Datenverarbeitung, sondern Ereignis gesteuert.
Auch zur Selbstüberwachung des Systems, Simulation von Hardware und Benutzern und zur Entwicklung von Testautomaten sind sie hervorragend geeignet; die Architektur sollte dies unterstützen.Damit bieten sie eine einheitliche Sicht und Denkweise durch alle Phasen der Systementwicklung.
...while the Activities language unit provides for modeling behavior based on a workflow-like paradigm...
Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der UMLjoerg.robra@t-online.de Embedded Systems www.th-nuernberg.de 12.11.2013 36
Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik
Noch Fragen?
Danke fDanke füür r IhreIhre
Aufmerksamkeit!Aufmerksamkeit!
RequirementsRequirementsArchitekturArchitekturUML / UML / SysMLSysMLMDA / MDDMDA / MDDSimulation / TestSimulation / Test