Testmatrix für Menü (State Diagram)

[sunshineh]

Hallo,

ich habe das Menü von meinem Gerät das State Diagram aufgezeichnet. Es

hat 7 Hauptmenüs und je nach State 1...5 Untermenüs.

4 Grundaktionen müssen von jedem State aus machbar sein.

1.

Damit ich von einem State in den anderen welcheln kann, kann es z.B.

sein das der Anwender "erst einen Wert auswählt und diesen dann

Bestätigt (=2 Tastendrücke hintereinander)" ODER

"erst einen Wert auswählt, diesen ändert und die Änderung bestätigt

(=Tastendrück + Drehrad + Tastendruck).

2.

Nun möchte ich eine Testmatrix für die Funktion meines Menüs aufstellen.

Dafür habe ich in der Spalte die verschiedenen Eingabemöglichkeiten für

den Anwender eingetragen und in der Reihe die aktuell möglichen

Zustände.

-als Eingabemöglichkeiten habe ich 10 Taster und 1 Drehrad

-und 26 Zustände

Dies würde ja schon eine ziemlich aufwändige Testmatrix ergeben, nur

habe ich nun noch das Problem, dass manche Änderungen wie unter 1. erst

durch 3 aufeinanderfolgende Anwendereingaben erfolgen, würde das nicht

heißen, dass ich für einen zuverlässigen Test in jedem State alles

(incl. dieser 3 aufeinanderfolgenden Anwendereingaben und der

Einzeltasten..) testen müsste?

Wie ist eine solche Aufgabe zuverlässig in den Griff zu bekommen und zu

testen????!!!!

Bin für jeden Tipp dankbar!

[flashpixx]

Das ganze ist ja, wenn ich das richtig verstehe, ein Graphenproblem.

Du kannst von Edge X zu Edge Y über eine Kante laufen. An jeder Kante steht nun eine Bedingung dran, wann Du über diese laufen kannst. Aktionen wie eingaben führen natürlich inkl Werteüberprüfung zu mehreren Knoten und Kanten.

Das ganze kann man über eine Adjazenzmatrix (die kann schon recht groß werden) repräsentieren und eben entsprechende Erreichbarkeit, Zyklen usw analysieren, wobei das gerade bei Graphen meist NP Probleme sind, die Du je nach Größe über sinnvolle Heuristiken ermitteln solltest.

Wenn Du ein vollständiges Bsp hättest, könnte man schauen, wie man es konkret machen würde

Dies würde ja schon eine ziemlich aufwändige Testmatrix ergeben, nur

habe ich nun noch das Problem, dass manche Änderungen wie unter 1. erst

durch 3 aufeinanderfolgende Anwendereingaben erfolgen, würde das nicht

heißen, dass ich für einen zuverlässigen Test in jedem State alles

(incl. dieser 3 aufeinanderfolgenden Anwendereingaben und der

Einzeltasten..) testen müsste?

Rein für diese Aussage kannst Du abstrakt überlegen, dass Du vom Zustand X1 nach Xn nur kommst wenn eben jede Kante erfüllt ist und es zu dem Zustand Xi keinen anderen Weg von den Zuständen Xp (p < i) nach Xi gibt (für alle i)

Wenn man das natürlich jetzt allgemein als Testsystem formulieren will, d.h. man füttert das Testsystem eben mit der Adjazenzmatrix und den zuständigen Kantenaktionen und lässt automatisiert ermitteln, ob eben das alles korrekt funktioniert, müssen die Algorithmen eben sehr sinnvoll erarbeitet werden

Bearbeitet 9. April 2010 von flashpixx

[sunshineh]

DANKE für deine Antwort!

OK, ich gehe mal der Reihe nach vor.

Ich möchte erst mal für das Verhalten des Menüs eine State Machine zeichnen. Diese lässt sich aufteilen in eine State Machine "Änderung der Nebenwerte" und eine State Machine "Änderung der Hautpwerte".

Wenn der Benutzer nun einen Knopf zur Änderung eines Hauptwertes drückt, so soll sofort die State Machine "Änderung der Nebenwerte verlassen werden (dabei sich der letzte State gemerkt) und die State Machine "Änderung der Hauptwerte" gesprungen werden.

Wie kann ich dieses Zusammenspiel als übergeordnete State Machine zeichnen?

Konnte diese Frage irgendwer verstehen? Ich glaub, ich hab mich ziemlich chaotisch ausgedrückt.

[flashpixx]

Ich möchte erst mal für das Verhalten des Menüs eine State Machine zeichnen. Diese lässt sich aufteilen in eine State Machine "Änderung der Nebenwerte" und eine State Machine "Änderung der Hautpwerte".

Im Grunde ist das für mich ein endlicher deterministischer Automat. Du wirst rein formal nicht drum herum kommen jeden Zustand in Dein Diagramm zu packen und eben jeden Zustand und jeden Übergang deterministisch anzugeben.

Man kann sich da "visuell" etwas "retten", wenn Du eben diesen ganzen EA in Teilautomaten zerlegst und Du eben einen ganzen Teilautomat in einen Zustand packst, sprich irgendwie passend referenzierst.

[...] (dabei sich der letzte State gemerkt) [...]

Eine Statemachine ist ein (n)EA ( [nicht]-deterministischer endlicher Automat), dieser kennt nur seinen aktuellen Zustand, d.h. eine Art Speicherung hast Du nicht. Da der EA als Chomsky-3 Sprache definiert ist, kannst Du damit eben kein State merken. Man kann formal zeigen, dass das was Du brauchst "mächtiger" ist, als die "Mächtigkeit" des (n)EA.

Sobald Du etwas zählen oder speichern musst, musst Du eine Klasse höher gehen, d.h. aus der Chomsky-3 in die 2-Ebene, wobei Du dann bei den PDA (push-down-automate / Kellerautomat) bist.

[sunshineh]

Ich habe im Anhang mal ein Beispiel-Diagramm angehängt.

Ich weiß eigentlich genau was ich "sagen" will, weiß nur nicht wie es formal richtig ist.

Also im Grunde habe ich eine Hauptstatemachine "SM Menü", die wird anhand der Benutzereingaben gesteuert und ich kann sie inhaltlich in Teilsysteme zerlegen ( sind dass dann auch StateMachines??, muss ich da das Zeichen für Statemachines oder diesen gestrichelten Kasten setzen?)

Einerseits habe ich eine Taste mit höherer Prorität, die von jedem State aus gehen MUSS (da merke ich mir über globale Variablen den letzten State in den ich nach Abarbeitung wieder wechsel).

Andererseits habe ich das Teilsystem 2, dass ich in einem neuen Blatt aufzeichnen möchte (brauche ich da auch einen Anfangs- und einen Endstate, oder zeichne ich da die Einzelstates auf mit dem Bedingungen, in welchem State ich ankomme?

Ich hoffe es ist irgendwie verständlich was ich meine!!! Ich bin grad ETWAS VERWIRRT

Ich habe im Internet nur diese einfachen UML-Regeln gefunden und weiß nicht genau, ob es sich bei meiner um eine Hierarchische StateMaschine handelt oder nicht.

Die Teilsysteme will ich ja nur der Verständlichkeit halber machen und damit ich nicht zu viele States in ein Diagramm machen muss (andererseits macht mir auch die sinnvolle Nummerierung der States Probleme).

[flashpixx]

Sorry, aber ich verstehe Dein Diagramm nicht. Ich denke Du solltest Dich an die korrekte Notation halten. Endlicher Automat ? Wikipedia

[sunshineh]

Ist es nun besser so?

Ich möchte eben nur diese Teilsystem besser graphisch kenntlich machen, dass sie zusammengehören.

Z.B. das diese "Taste höherer Priorität" für jeden State des Hauptsystems gilt usw.

Das Teilsystem 2 ist in sich noch etwas kompliziert mit vielen States, darum wollte ich es so andeuten.

Darf man das nicht machen? Was mach ich dann bei richtig großen Statemachines?

[flashpixx]

Ich sehe das Problem, dass Du vom State 1 mit eben einer bestimmten Taste in das Subsystem läufst, aber nicht klar ist wohin. Laut dem Diagramm interpretiere ich das so, dass man eben von State 1 mit dem Tastendruck in "irgendein" State des Subsystem kommt und das ist ein Indeterminismus.

Soweit wie mir die Statediagramme bekannt sind, müssen alles als Determinismus dargestellt werden, so dass klar ist, welche States durch welche Aktionen erreicht werden

[sunshineh]

Hallo,

vielen Dank für deine Antwort. Ich habe es nochmal neu aufgebaut.

Es gibt keine undefinierten Zustände und es passiert nichts aus Zufall!

Es ist jetzt vielleicht etwas ersichtlicher.

Im Teilsystem 1 gibt es 3 Modi. Und im Hauptmenü gibt es logischerweise eine bestimmte Anzahl an States.

Diese beiden Informationen möchte ich in globale Variablen abspeichern:

Globale Var MODE

Globale Var STATE

Nun kann ich jedem State des Hauptsystems eine "TasteWichtig" gedrückt werden > State höherer Priorität wird ausgeführt und anschließend wird wieder in den letzten State des Hauptsystems gewechselt.

Das Hauptsystem besteht grundsätzlich aus 3 Modi., wobei der aktuelle Modus in der globalen Variable steht und als Entscheidung dafür notwendig ist, wie das Teilsystem 2 ausgeführt wird. Ich habe um die 3 States "Modus 1-Modus3" nur ein Teilsystem 1 gezeichnet, damit man bei der Verbindung von Teilsystem 1 und Teilsystem 2 abstrakter bleiben kann und nicht jeweils 3 Pfeile für den Hin- und 3 Pfeile für den Rückweg zeichnen muss.

Wäre dass nun so möglich und richtig?

[lupo49]

Mit welcher Eingabesequenz erreicht man die Modi 1,2 oder 3 in dem Teilsystem 1?

[sunshineh]

Was meinst du mit Eingabesequenz?

Es kommt darauf an, in welchem State die Modi-Auswahl verlassen wurde (z.B. MODE=2 -> die Globale Mode-Variable ist 2) -> im Teilsystem 1 wird in den Modus 2 gewechselt.

Ich habe es nur nicht direkt reingezeichnet, das ich sonst die Fälle fürs Teilsystem auch reinzeichnen müsste, und dass war mir zu unübersichtlich.

Ich weiß nicht, ob man dass überhaupt darf?

[flashpixx]

vielen Dank für deine Antwort. Ich habe es nochmal neu aufgebaut.

Es gibt keine undefinierten Zustände und es passiert nichts aus Zufall!

Das sieht schon besser aus. Die Pfeilspitzen gehören aber an die States und nicht an das Teilsystem. Im Moment würde man das so interpretieren, dass man "irgendeine" Kante laufen kann und im Teilsystem landet, aber wo man genau landet ist nicht klar.

Dann zu Deinen "globalen" Variablen: Die globale Variable ist auch ein State, d.h. Du musst das Diagramm erweitern, dass eben ! jeder ! Zustand abgedeckt wird. D.h. wenn eben Deine globale Variable im Modus 1 ist und man Taste 2 drückt, dann bleibt sie innerhalb des aktuellen States.

Du musst innerhalb des Diagramm ! jeden ! Zustand des Systems modellieren, das ist leider extrem aufwändig und viel Arbeit. Konkret bedeutet das, dass Du eben jeden Modus als State und dazu passend die Verbindungen erzeugen musst. Ein Vorteil davon besteht aber, wenn Du das alles so aufgedröselt hast, dass Du recht gut prüfen kannst, ob Zustände nicht erreichbar, co-erreichbar oder erreichbar sind bzw. ob man Zustände im System hat, aus denen man nicht mehr weg kommt.

[sunshineh]

Kann man die StateMaschine nicht so schreiben, dass man innerhalb dieses States abfragt, um welchen Modus es sich handelt?

Es ist ja schier unmöglich, wenn ich den "State höhere Priorität" an JEDEN einzelnen State gehen lassen muss! Soviele Pfeile kann ich in mein Diagramm gar nicht reinzeichnen?!! Dies soll ja alles nur "vereinfacht" darstellen!

[flashpixx]

Kann man die StateMaschine nicht so schreiben, dass man innerhalb dieses States abfragt, um welchen Modus es sich handelt?

Nach dem Modell sollte das nicht sein.

Es ist ja schier unmöglich, wenn ich den "State höhere Priorität" an JEDEN einzelnen State gehen lassen muss! Soviele Pfeile kann ich in mein Diagramm gar nicht reinzeichnen?!!

Der Sinn des Diagramm bzw wenn man das ganze als Matrix darstellt besteht ja genau darin, dass zu jedem Zustand klar ist, wie man dahin kommt und wie man in einen anderen Zustand wechselt, d.h. rein technisch musst Du alles zeichnen.

Du kannst Dir das ganze halt so vereinfachen, dass Du eben einzelne Zustände auslagerst, d.h. wenn Du in den Zustand X läufst, dass Du diesen wieder als eigenständige State Machine auffasst.

Aber rein formal, musst Du jeden Zustand im System darstellen. Ich würde das halt so angehen, dass Du eine Master-State-Machine hast, die vielleicht mit 3-5 Zuständen auskommt. Diese 3-5 Zustände stellst Du dann wieder als eigenständige State-Machine dar

[sunshineh]

Gut, vielen Dank!

Aber weißt du vielleicht ein Beispiel mit einer Master-State-Machine und einer "Unter-State-Machine".

Ich bin da mit der Umsetzung total unsicher

z.B. braucht jede dieser State-Machine einen Anfangs- und Endzustand, oder läßt man den "Pfeil" direkt rein gehen?

Ich habe im Internet leider kein passendes Beispiel gefunden!

[flashpixx]

Ich bin da mit der Umsetzung total unsicher

z.B. braucht jede dieser State-Machine einen Anfangs- und Endzustand, oder läßt man den "Pfeil" direkt rein gehen?

Ich würde mich da an die Automatentheorie anlehnen:

Startzustände werden mit einem kleinen Dreick angegeben, Finalzustände mit einer Doppellinie.

Je nach Komplexität würde ich nicht den Zustand direkt rein schreiben, sondern durch nummerieren und die Zustände in einer eigenen Tabelle mit angeben. Natürlich sollte an jeder Kante dann stehen, was für den Zustandswechsel notwendig ist (das habe ich jetzt mal im Beispiel weg gelassen)