State machine: Aktionen im Zustand und Übergänge trennen?

[Michael R. (Firma: Brainit GmbH) (fisa)]

Hallo zusammen,

ich bin grad verunsichert: Ich mach für meine Micro_Telefonanlage grad 
die State Machine. in jedem Zusatnd gibt es Aktionen (Relais, Töne, ...) 
die ausgeführt werden, und natürlich Zustandsübergänge. Basis für den 
Zustandsübergang ist natürlich der aktuelle Zustand und ein äußeres 
Ereignis (z.B. Zustand "idle", ein Telefon wird abgehoben => Zustand 
"waiting")

Im Zuge eines Übergangs muss ich mir natürlich auch ein paar Sachen 
merken (z.B. welches Telefon abgehoben wurde)

Nun überlege ich, zwecks Übersichtlichkeit, das in zwei 
switch-Statements aufzuteilen: das erste Statemen kümmert sich nur und 
ausschließlich um die übergänge, während das zweite unmittelbar 
darauffolgende die nowendigen Aktionen auslöst.

Allerdings hätte ich das so noch nie gesehen...

Bin ich da grad komplett auf dem Holzweg?

[Matthias (Gast)]

Mehr Statemachine geht nicht:
http://www.state-machine.com/index.php

Dort wird der Aktuelle Zustand als Funktionspointer gespeichert. Jeder 
(Super-)State ist eine seperate Funktion. Das stellt die erste 
"switch-Stufe" dar.

Jede Funktion erhält ein Event-Struct: Einen enum, der das Event 
spezifiziert gepaart mit dazu passenden Daten (WAITING-Event mit Nummer 
des Telefons).

Vielleicht hilft dir das. Benötigt etwas Einarbeitung, aber für die 
bloße Anwendung sollte das ziemlich schnell fertig sein.

[Wusel D. (stefanfrings_de)]

Probiert es aus, und wenn es Dir besser gefällt, dann mach es so.
Letztendlich kommt es darauf an, dass der Quelltext für Dich 
übersichtlich ist, so dass Du ihn später gut pflegen kannst. Sofern Du 
vorhast, andere Entwickler mit einzubeziehen, sollte deren Meinung 
natürlich auch zählen.

[Markus M. (mark_m)]

Hast du dir eine Diagramm erstellt? Damit kannst du eigentlich alle 
Probleme lösen bevor Du anfängst zu Implementieren.

Es gibt mehrere Darstellungsarten. Eine davon wäre das UML- 
Zustandsdiaramm. (http://de.wikipedia.org/wiki/Zustandsdiagramm_(UML))

Die Zeit ein Diagramm zu Zeichnen lohnt sich auf jeden Fall.

Grüsse

[Michael R. (Firma: Brainit GmbH) (fisa)]

Danke euch, aber ich war wirklich am Holzweg, und zwar anderweitig: Der 
Trick ist, im Case-Zweig zuerst die Aktionen des aktuellen Zustands 
auszuführen, und erst dann über Transitions nachzudenken. Ich hab 
dummerweise verkehrt gedacht...

[Julius (Gast)]

hallo,

jeder übergang impliziert übrigens drei mögliche aktionen wenn die SM 
ereignisorientiert (Interrups/Eventsystem) arbeitet

1. die exit-aktion des alten zustandes
2. die aktion der trasition
3. die entry-aktion des neuen zustandes

sollte die SM mit signalen (variablen) und guards (bedingungen) arbeiten 
würde ich vier mögliche Aktionen ausmachen

1. die exit-aktion des alten zustandes
2. die aktionen der trasition
   2.1 aktion vor der bedingung immer (vorbereitung der guard)
   --> bedingung
   2.2 aktion nach der bedingung wenn true
       also nur wenn die transition traversiert wird
3. die entry-aktion des neuen zustandes

übrigens wer die SM eng an UML Klassendiagramme binden möche dem wäre 
raphsody oder sisy zu epfehlen

Gruß J.

[Reinhard Kern (Gast)]

Michael Reinelt schrieb:
> Der
> Trick ist, im Case-Zweig zuerst die Aktionen des aktuellen Zustands
> auszuführen

Die Frage ist, ob es überhaupt Aktionen des Zustands gibt, das ist oft 
auf mangelnde Diagnose zurückzuführen - wenn man z.B. meint bei 
verbundenem Modem ist die Aktion des Zustands "Daten empfangen", so 
lässt sich das elimineren dadurch dass man den Event "1 Zeichen 
angekommen" einführt. In den meisten Fällen können alle Aktionen in 
passenden Eventhandlern untergebracht werden.

Gruss Reinhard

[Julius (Gast)]

jup ... die sm ist auch eigentlich ereignisorientiert nur hat man auch 
tatsächlich echte ereignisse (int oder aktives eventsystem) oder bildet 
man diese über änderung von variablen ab ... sprich signale und guards 
:-o