Re: [boost] New library in Vault: Msm (Meta State Machine)
Hi Andreas,
What do t & D stand for (they do not appear in Figure 2)? They don't seem to be necessary to implement the chart?You should also read the mini doc I included. I added them to make the problem a bit more interesting and show how to solve it with flags.
1) Is it possible to implement the transitions exactly as shown in the chart? It is not, again as explained in the mini doc. I see this as an UML goto and decided to implement superior tools instead. 2) If no, is this why you introduced two self-transitions to C, one with a guard to prevent transition from B?I didn't. They were there before, I just made them cleaner by using state flagging and a guard condition instead of crossing state boundaries. The UML diagram of the doc looks, in my opinion, cleaner now, less like spaghetti. Of course I could implement these entry and exit goto-like pseudo states if users want them. I just strongly doubt they are needed.
_________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE
What do t & D stand for (they do not appear in Figure 2)? They don't seem to be necessary to implement the chart? You should also read the mini doc I included.
Right, sorry I missed that one.
I added them to make the problem a bit more interesting and show how to solve it with flags.
Ok.
1) Is it possible to implement the transitions exactly as shown in the chart? It is not, again as explained in the mini doc. I see this as an UML goto and decided to implement superior tools instead.
So IIUC then you think that transitions crossing state boundaries are bad practice and should be avoided at all costs? In general, I agree that you should avoid them when you can, e.g. in the example chart the transition triggered by y should rather be a self-transition of C, which is semantically equivalent. OTOH, the transition triggered by x can only be made non-state-boundary-crossing by introducing a guard, which is IMO less concise than allowing for the transition as shown in the chart. Moreover, things become a bit more messy if you want to allow for multiple ways of entering a composite state. For example consider Figure 8 in <http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Statecharts.pdf> Here the "alarms-beep" outer state exists primarily because you don't want to duplicate the "any button pressed" and "30 sec in alarms-beep" transitions for all three different alarm beep states. The other diagrams in the document show more uses of state-boundary-crossing transitions. Granted, Harel sometimes uses them excessively, in places where he could simply have transitioned to the outer state instead and let the default transition take care of going to the inner initial state. But in a few places I don't see any equally concise substitute for such transitions. As an aside, I don't see much of a connection of state-boundary crossing transitions with goto. Given your code in the C() function, any transition could/would be implemented with goto?
Of course I could implement these entry and exit goto-like pseudo states if users want them.I just strongly doubt they are needed.
Given the examples in the Harel paper and the fact that the UML standard expressly allows them, I would encourage you to support them. BTW, for the same reasons I don't detect value in seeing a composite state as a fully fledged state machine (as your framework seems to do). I know that the UML has so-called submachines but they are really just simple composite states with entry and exit points thrown in. Just my 2c. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (2)
-
Andreas Huber -
christophe henry