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?
Gast
#3221567
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.
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.
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
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...
Gast
#3226515
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.
Gast
#3226670
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
Gast
#3226672
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
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.