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

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

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

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

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)

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)

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)

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

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

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

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

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

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

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

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