State Machines Teil 2 States State Invarianten

Präsentation zum Thema: "State Machines Teil 2 States State Invarianten"—  Präsentation transkript:

1 State Machines Teil 2 States State Invarianten
Bereiche und Granularität Transitions/Übergänge Alpha/Omega-States Klassen-Flattening Unerlaubte Zustände Die Response-Matrix StateMachines, Thomas Legler, ProSeminar Softwaretechnologie

2 States ein State ist ein Art Kurzbeschreibung für erlaubte Vorgänge in einem Programm das State-Modell muss beim Entwickeln ständig eine exakte Abfrage des aktuellen Status erlauben im Prinzip wird der Status gebildet aus dem sämtlichen Inhalt einer Klasse

3 Beispiel 2 Booleans in einer Klasse  4 Zustände 1 int  2^32 Zustände
bsp: Konto (Betrag, Name, Kontonummer) für den Zustand nur Betrag wichtig überzogen gesperrt Betrag ok  frei nur 2 relevante Zustände aus vielen Milliarden

4 State Invariants gültiger Status ausgedrückt durch Status-Invariante
bool state1(){ return ((x==1) &&(y==2)); } wird gebildet aus den Werten der Klasse die vorher definierten Statie und die Invarianten müssen alle möglichen Statie abdecken

5 Bereiche (Ebene der Abstraktion)
Umrandet (Statie gebildet aus den Werten der Klasse, nicht aus beerbten Klassen) Rekursiv (alle Ebenen der Klasse werden ausgebreitet, und aus allen Werten wird dann der Status gebildet) Granularität (Vereinigung der Definitionen für einen Status) Aggregate (Status bestehen aus einer willkürlichen Menge von Werten der Klasse) Primitive (Status repräsentiert durch die gesamte Menge von Werten, repräsentiert durch niederen Datentyp) Konkrete und primitive Status-Modelle können sehr schnell an Komplexität zunehmen (siehe beispiel States)

6 Bereiche und Granulatität
die Bedeutung eines Status hängt von seiner Sichtbarkeit, seinem Bereich und seiner Granularität ab instance variable domain = Menge der diskreten Statie repräsentiert durch Instanzvariablen combinational value set = Menge aller möglichen Kombinationen von Instanzariablen Sichtbarkeit (Hauptmerkmal eines State-Modells) Abstrakt (nur das Interface nach aussen) Konkret (implementiert)

7 Bereiche (Ebene der Abstraktion)
Umrandet (Statie gebildet aus den Werten der Klasse, nicht aus beerbten Klassen) Rekursiv (alle Ebenen der Klasse werden ausgebreitet, und aus allen Werten wird dann der Status gebildet) Granularität (Vereinigung der Definitionen für einen Status) Aggregate (Status bestehen aus einer willkürlichen Menge von Werten der Klasse) Primitive (Status repräsentiert durch die gesamte Menge von Werten, repräsentiert durch niederen Datentyp) Konkrete und primitive Status-Modelle können sehr schnell an Komplexität zunehmen (siehe beispiel States)

8 Transitions/Übergänge
Ist eine Kombination eines Ausgangsstatus und eines Endstatus, einem Ereigniss und eventuellen Schutzmechanismen Eine Transition wird durch ein Ereigniss ausgelöst und kann mehrere Aktionen ausführen Sie hat immer nur einen Endstatus

9 Event Schutzmechanismen Aktion Nachricht an die zu testende Klasse
Die Antwort einer anderen Klasse Ein Interrupt oder eine ähnliche Unterbrechung von aussen Schutzmechanismen Ein mit dem Ereigniss verknüpfter Ausdruck Aktion Ein Nachricht/Antwort an ein anderes Objekt

10 Alpha/Omega-States Alpha Omega
Objekt vor der Konstruktion In dem Zustand werden nur Konstruktoren wie z.B. new akzeptiert (alpha transition) Omega Objekt nach der Destruktion, Löschung oder beim Verlassen des gültigen Bereiches Erreicht durch Destruktoren (omega transitions) Sie müssen nicht explizit implementiert werden, aber sollten beim Testen nicht unbeachtet bleiben

11 Klassen-Flattening Merkmale einer gut entwickelten Klassenhierarchie
Eine Unterklasse hat mehrere Teilstatie eines Statuses der Superklasse Eine Unterklasse kann neue Statie einführen,diese müssen aber mit den Statie der Oberklasse im Einklang verlaufen Private Statusvariablen der Oberklasse müssen in der Unterklasse private bleiben

12 Arten Orthogonal Komposition Aneinanderfügen
Status-Aufteilung und Unterstatus hinzufügen Transitionumleitung Transitionaufteilung

13 Expansion des Zustandsgraphen bei Orthogonaler Komposition
Möglichst das komplette Modell sollte getestet werden In der Realität nur schwer möglich, da oft Informationen über die Oberklasse fehlen, das ganze enorm Zeitaufwendig wäre u.s.w

14 Es muss ein expilziter Exception-Handler eingebaut werden, der unerlaubte Zustände bearbeitet
Diese illegalen Ereignisse müssen genau ausgetestet werden Z.b. werden illegale Zustände erreicht, wenn mehrere Instanzen eines Programm’s nebeneinander laufen und sich ungewollt gegenseitig beeinflussen Beachte Antworten auf illegale Ereignisse und blockende Guards

15 Unerlaubte Zustände Normalerweise werden viel Zustand/Ereigniss-Paare vernachlässigt  Problem, wenn in einem Zustand ein nicht geplantes Ereigniss eintritt Einfaches Ignorieren kann problematisch werden Wenn ein illegales Ereigniss akzeptiert wird, hat das eine illegale Transition zur Folge. Das bewirkt dann einen nicht gewollten Zustandswechsel Schleichpfade = Programmbugs, die illegale Transitions erlauben und Guards umgehen