State Machine Diagram ; Referatshilfe!?

Hallo Michelle,
wahrscheinlich googelst Du nach dem Falschen.
Versuchs mal mit:
Zustandsautomat, Zustandsgraph, endliche Automaten, Automatentheorie.
Da gibts auch was in germanisch.

Jürgen

@  Michelle (Gast)

>Jemand ne Idee wo ich einfache Informations-Kost bzw. verständliche
>Infos oder Hilfe finde? Oder hat jemand gar lust mir das ganze zu
>erklären!?/Zu helfen?!

Siehe Statemachine
http://de.wikipedia.org/wiki/Zustandsautomat

MfG
Falk

Das ganze ist falsch herum aufgezogen.
Du zeichnest die State Machine bevor du sie implementierst. Das ist ja 
genau das Wesen all dieser Beschreibungen: Man konzentriert sich auf die 
Aufgabe und nicht auf die Details die in einer Programmiersprache nötig 
sind.

State-Maschinen sind besonders einfach zu beschreiben. Von den 
wahrscheinlich unzähligen Möglichkeiten bevorzuge ich die hier:

Jeder State ist ein Kreis. Über dem Kreis (oder in ihm drinnen) steht 
der Name des Zustands, der natürlich so gewählt ist, dass man sofort 
erfasst, was dieser Zustand aussagt. Normalerweise sind das 
Eigenschaftswörter (wartend, lesend, Ventil geöffnet etc.). Jeder 
Zustand ist ein Kreis. Von einem Zustand zu einem anderen Zustand (aber 
auch zu sich selber) kann es einen Pfeil geben. Dieser Pfeil beschreibt 
den Übergang von einem Zustand in einen anderen Zustand. Über dem Pfeil 
steht die Bedingung, die vorliegen muss, damit dieser Pfad begangen 
werden kann, unter dem Pfeil steht die Aktion die dabei ausgeführt wird.

Und das wars dann schon. Du hast eine graphische Repräsentierung einer 
State-Maschine. Mit ihr kann man hervorragend die Logik der State 
Maschine kontrollieren und verbessern. Ist man mit der Logik zufrieden, 
so ist es ebenfalls einfach aus dieser Graphik das Programm zu erzeugen.

Im Wesentlichen kann man das Ganze auch als Tabelle darstellen :

Zustand   Ereignis   Aktion    NeuerZustand
  ..         ..        ..        ..
  ..         ..        ..        ..

Hallo !!

Oder du kannst auch die ganze Tabelle in einen Zustandsgraph packen.
-> Jeder Zustand ein Kreis mit Zustandsname und ev. einer 
Zustandscodierung.
-> und zwischen den Kreisen (Zuständen) Pfeile einzeichnen die du mit 
den Ereignissen für einen Zustandswechsel und den dabei gesetzten 
Ausgängen beschriftest.

L.g

So könnte sowas zb als Graphik aussehen (Bild)

Es zeigt den 'Weg' der State-Machine 'Michelle' mit den möglichen 
Zuständen bei der Lösung des Problems "Wie schreibe ich ein Referat zum 
Thema 'Visualisierung von State-Machines'". Weitere Verfeinerungen sind 
natürlich möglich und sollten auch gemacht werden :-)

Sicher.

Aber viel wichtiger: Alles klar, worauf es ankommt?

Es kommt nicht darauf an, alle ; an den richtigen Stellen zu haben. Es 
kommt nicht darauf an for und while richtig zu schreiben. Es kommt 
einzig und alleine darauf an nachvollziehen zu können, wie und warum und 
mit welchen Aktionen die Statemachine ihre Zustände wechselt.
Man kann sich jede 'Maschine' als Zustandsmaschine denken und die 
Maschine wechselt von einem Zusatnd in irgend einen anderen. Bei manchen 
Maschinen sieht man das gut, zb eine Ampel. Die einzelnen Lichtphasen 
sind die Zustände. Bei wieder anderen sieht man es nicht so gut, zb. 
Getränkeautomat und bei wieder anderen sind die Zustände zwar auch da, 
aber von aussen nicht so toll bemerkbar. Im letzten Fall hindert einen 
aber nichts und niemand da ein paar Zustände zu postulieren.

Uuups.
Hab gar nicht drauf geachtet. Mit Paint gezeichnet und als GIF 
gespeichert. Hätte nicht gedacht, dass MS_Paint so dermassen schwach 
ist.

Karl heinz Buchegger schrieb:
> Uuups.
> Hab gar nicht drauf geachtet. Mit Paint gezeichnet und als GIF
> gespeichert. Hätte nicht gedacht, dass MS_Paint so dermassen schwach
> ist.
Was kann Paint den dafür? :P

Läubi .. schrieb:
> Karl heinz Buchegger schrieb:
>> Uuups.
>> Hab gar nicht drauf geachtet. Mit Paint gezeichnet und als GIF
>> gespeichert. Hätte nicht gedacht, dass MS_Paint so dermassen schwach
>> ist.
> Was kann Paint den dafür? :P

Na ja.
ein 700*700 Pixel Bild in 4 Farbe solle als GIF dann schon ein wenig 
kleiner sein.

Karl heinz Buchegger schrieb:
> Läubi .. schrieb:
>> Karl heinz Buchegger schrieb:
>>> Uuups.
>>> Hab gar nicht drauf geachtet. Mit Paint gezeichnet und als GIF
>>> gespeichert. Hätte nicht gedacht, dass MS_Paint so dermassen schwach
>>> ist.
>> Was kann Paint den dafür? :P
>
> Na ja.
> ein 700*700 Pixel Bild in 4 Farbe solle als GIF dann schon ein wenig
> kleiner sein.

Asche auf mein Haupt.
Man sollte dann doch als Dateityp gif einstellen und nicht einfach nur 
eine Dateiendung .gif benutzen.

Ich erkläre feierlich, dass Paint unschuldig ist, wenn sich der Benutzer 
zu dämlich anstellt.

Hallo,

noch ein wichtiger Hinweis: bei Zustandsautomaten unterscheidet man
oft zwischen Moore- und Mealy-Automaten, siehe:

http://de.wikipedia.org/wiki/Moore-Automat
http://de.wikipedia.org/wiki/Mealy-Automat

Jedoch kann man ohne weiteres auch Automaten implementieren, die
Mischformen darstellen, was häufig auch sehr sinnvoll ist. Vor
längerer Zeit gab es einmal ein Rapid-Prototyping-Werkzeug für
GUIs namens Rapid, in dem die äußerst nützlichen Konventionen
eingeführt wurden:

Action:
  kurzzeitiger Vorgang bei Zustandsübergang

Activity:
  Tätigkeit während des Aufenthalts in einem Zustand

Die Acitivity "Lasse die Lampe leuchten, während sich der
Automat in Zustand 5 befindet", lässt sich in die Actions
"Schalte die Lampe beim Betreten in Zustand 5 ein" und "Schalte
die Lampe beim Verlassen von Zustand 5 aus" überführen.

Einen Blinkvorgang kann man entweder als zeitgesteuerten Wechsel
zwischen zwei Zuständen realisieren, was aber schnell zu aufge-
blähten Zustandstabellen und -diagrammen führen kann, oder über
ein Schleifenkonstrukt (als Activity) innerhalb eines einzelnen
Blink-Zustandes.

Gruß
Andreas Schweigstill

Hmmm, ja. Wenn die Aktionen laenger dauern wie fuer die Maschine einen 
Augenblick ist, dann bekommt man transiente oder zerfallende Zustaende, 
wie zB Led-Blink, welches mind. 50ms dauern sollte.

Gleicher Tag schrieb:
> transiente oder zerfallende Zustaende

Solche Zustände sind in der Tat ein massives Problem, wenn es darum
geht, ein Modell, das man in einer entsprechenden Beschreibungssprache
oder CASE-Tool spezifiziert hat, auf ein Zielsystem zu übertragen,
z.B. auch per Codegenerierung.

Früher(tm) hatte ich mich u.a. mit dieser Thematik befasst, und zwar
im Zusammenhang mit SDL (Specification and Description Language, Z.100).
In SDL waren alle Zustandsübergänge stets zeitlos, im generierten Code
natürlich nicht. Es gibt nun verschiedene Möglichkeiten, eine Abbildung
der SDL-Prozesse auf die Betriebsmittel des Zielsystems vorzunehmen.
Zunächst banal sieht die Variante aus, bei der man jeden SDL-Prozess
auf einen Betriebssystemprozess abbildet (sog. Maximalintegration). Es
stellt sich jedoch heraus, dass das die mit Abstand gefährlichste
Variante ist, nämlich auf Grund drohender Race Conditions, die zum einen
durch Kontextwechsel während Zustandsübergängen und zum anderen durch
den Lebenszyklus nur kurzzeitig erzeugter Prozessinstanzen entstehen.

Andere Integrationsformen nennen sich Minimalintegration (alle SDL-
Prozesse in einem Betriebssystemprozess, eigener Scheduler für SDL,
Environment in eigenen Prozessor) und bare integration (kein Betriebs-
system, eigener Scheduler, Environment als Erweiterung des Schedulers).

Über diese Thematik kann man stunden-, ach tagelang diskutieren und
Bücher schreiben (was auch getan wurde). In vielen Fällen stellt sich
auch heraus, dass der Pflegeaufwand für solche Systeme so hoch ist,
dass der eingesparte Aufwand bei der Anwendungsentwicklung mehr als
aufgezehrt wird.