die state machine – zaubertrank der uml - mid.de · pdf filefor modeling behavior based...

Fakultät efiElektrotechnik Feinwerktechnik Informationstechnik

Prof. (i.R.) Dr.-Ing. Jörg Robra Software Engineering Technische Hochschule Nürnberg Die State Machine – Zaubertrank der [email protected] 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 [email protected] Embedded Systems www.th-nuernberg.de 12.11.2013 2


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



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?



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))



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



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"



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.



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)


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.



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:


Ruhe


Auswahl

entry / zeigAuswahl

Bezahlen

entry / zeigRestbetrag

Zubereiten




Warten

becher_entnommen[zu viel]

[passt]

muenze

muenze

taste

tasteBezahlen


stm AndereVersion

Ruhe


Auswahl

entry / zeigAuswahl

Bezahlen

entry / zeigRestbetrag

Zubereiten




Warten

start [zu viel]start [passt]

taste

becher_entnommenstart [zuviel]

start[passt]

muenze

muenze

taste

tasteBezahlen





StateTrigger taste muenze becher_entnommen ce <None>

Ruhe Auswahl

Auswahl Auswahl Bezahlen

Bezahlen Bezahlen

[zu viel]

Wechselgeld ausgeb...

[passt ]

Zubereiten

Zubereiten Warten


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!



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.



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




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



Ereignissteuerung im Business ProcessEreignis

Ereignis

treffpunkt.buedinger.name



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.




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



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



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



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



Ereignis

Ereignis

treffpunkt.buedinger.name

Geht das auch im Business-Sektor?Klar! Zur Erinnerung:



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



stm Auftrag

Bestandspruefung

do / pruefeBestand

Angebotserstellung

do / erstel leAngebot

biete_an ErwarteAuftrag


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


Angebotsanforerung


Angebotspruefung

do / pruefeAngebot

Bestellung

entry / Lieferant.auftrag(teil)

Lieferantenauswahl

do / sucheLieferanten(teil)Teil_defekt

Erledigt

[gefunden]

wareneingang

[unpassend]

[passend]

absageafter(T1) angebot

Etwas sinnvoller



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.


Angebotsanforerung


Angebotspruefung

do / pruefeAngebot

Bestellung

entry / Lieferant.auftrag(teil)

Lieferantenauswahl

do / sucheLieferanten(teil)Teil_defekt

Erledigt

[gefunden]

wareneingang

[unpassend]

[passend]

absageafter(T1) angebot



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


Versand

do / wareVersendenexit / Kunde.rechnungErledigt

Zahlung

do / zahlung_buchenauftrag

[nicht_verfügbar]/Kunde.absage

[verfügbar]

zahlung



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



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



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.



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.



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.



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



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.



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



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



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



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



Noch Fragen?

Danke fDanke füür r IhreIhre

Aufmerksamkeit!Aufmerksamkeit!

RequirementsRequirementsArchitekturArchitekturUML / UML / SysMLSysMLMDA / MDDMDA / MDDSimulation / TestSimulation / Test

die state machine – zaubertrank der uml - mid.de · pdf filefor modeling behavior based...

Documents