Theme 8 - TU Dresden

State Machines
Teil 2
1.
2.
3.
4.
5.
6.
7.
8.
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
o 2 Booleans in einer Klasse  4 Zustände
o 1 int  2^32 Zustände
o 3 int  2^96 Zustände
o bsp: Konto (Betrag, Name, Kontonummer)
o für den Zustand nur Betrag wichtig
o überzogen gesperrt
o Betrag ok  frei
»nur 2 relevante Zustände aus vielen Milliarden
State Invariants
•gültiger Status ausgedrückt durch StatusInvariante
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)
o Umrandet (Statie gebildet aus den Werten der Klasse, nicht
aus beerbten Klassen)
o 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)
o Aggregate (Status bestehen aus einer willkürlichen Menge
von Werten der Klasse)
o 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)
oAbstrakt (nur das Interface nach aussen)
oKonkret (implementiert)
• Bereiche (Ebene der Abstraktion)
o Umrandet (Statie gebildet aus den Werten der Klasse, nicht aus
beerbten Klassen)
o 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)
o Aggregate (Status bestehen aus einer willkürlichen Menge von
Werten der Klasse)
o 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
o Ist eine Kombination eines Ausgangsstatus
und eines Endstatus, einem Ereigniss und
eventuellen Schutzmechanismen
o Eine Transition wird durch ein Ereigniss
ausgelöst und kann mehrere Aktionen
ausführen
o Sie hat immer nur einen Endstatus
o Event
o
o
o
Nachricht an die zu testende Klasse
Die Antwort einer anderen Klasse
Ein Interrupt oder eine ähnliche Unterbrechung
von aussen
o Schutzmechanismen
o
Ein mit dem Ereigniss verknüpfter Ausdruck
o Aktion
–
Ein Nachricht/Antwort an ein anderes Objekt
Alpha/Omega-States
o Alpha
o Objekt vor der Konstruktion
o In dem Zustand werden nur Konstruktoren wie z.B.
new akzeptiert (alpha transition)
o Omega
o Objekt nach der Destruktion, Löschung oder beim
Verlassen des gültigen Bereiches
o Erreicht durch Destruktoren (omega transitions)
o 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
1. Orthogonal Komposition
2. Aneinanderfügen
3. Status-Aufteilung und Unterstatus
hinzufügen
4. Transitionumleitung
5. 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
o Es muss ein expilziter Exception-Handler
eingebaut werden, der unerlaubte Zustände
bearbeitet
o Diese illegalen Ereignisse müssen genau
ausgetestet werden
o Z.b. werden illegale Zustände erreicht, wenn
mehrere Instanzen eines Programm’s
nebeneinander laufen und sich ungewollt
gegenseitig beeinflussen
o Beachte Antworten auf illegale Ereignisse und
blockende Guards
Unerlaubte Zustände
• Normalerweise werden viel Zustand/EreignissPaare 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