Re: [boost] New library in Vault: Msm (Meta State Machine)
Hi Andreas,
Whether you'd want to work with entry & exit points in the alarm-beeps case is a matter of taste. I personally wouldn't bother simply because it seems unlikely that it can be reused anywhere.
Do you mean your example is irrelevant or that reuse is not important?
To reach a definite verdict in this particular example we'd need to define
first what coupling in a state machine actually means. To my knowledge, nobody has done that so far.
Do you need more than common sense to know that if you need to see inside of a state machine you have coupling?
Given my first 3 paragraphs above, I hope it has become clear that a state-boundary-crossing transition combined with an entry/exit-point is *not* an encapsulation breach.
Please forgive me for not agreeing.
Just to make sure we're not talking past each other: With "entry/exit states" I guess you mean "entry point pseudostate" and "exit point pseudostate" as defined in UML?
Yes, are there other possibilities?
You have read the whole paragraph, right? I quote it here for clarity:
<quote> A submachine state is semantically equivalent to a composite state. The regions of the submachine state machine are the regions of the composite state. The entry, exit, and behavior actions and internal transitions are defined as part of the state. Submachine state is a decomposition mechanism that allows factoring of common behaviors and their reuse. </quote>
Note the first sentence. What is unclear here?
Well, first why there are 2 terms. They are not equal but equivalent. So what is the difference? And what does it have to do with the subject? The important part is about reuse. Again this is a key point for Msm.
I don't follow. Isn't it a fact that the current version of Msm only supports a single entry point for a composite state/submachine, namely the
initial state?
There is the entry function of the sub state machine and the one of the initial state.
Exactly. However, IIUC, at the moment Msm only supports a single entry point and a single exit point, which IMO also makes reuse harder than necessary, see below.
Again I have to disagree. When a program runs, it calls functions, which call other functions, etc. Now if you read a book of Model Driven Development, you'll probably find inside that a UML diagram and code are two views of the same model. And now we have it. You don't mind having a single entry point in a function, right? Why is it a problem in a diagram? And there we are again, multiple entry points in a function are labels and goto.
Firstly, let's be clear that any reasonable semantics definition for FSMs (e.g. Harel, UML) absolutely requires that an entry action of a composite state/submachine is called when the composite state/submachine is entered and it doesn't matter at all how the state is entered (ordinary transition, state-boundary-crossing transition). The same goes for the exit action when the state is left.
Unfortunately I understood it the other way and had to go to great lengths in the example you gave me to avoid the entry of the composite. Maybe I'm not the only unreasonable and this brings confusion?
To cut a long story short: I would encourage you to do either of the following:
1) Allow state-boundary-crossing transitions (without entry/exit points). Once you have these, entry- and exit-points are a no-brainer: An entry point is simply a member typedef in the type that defines the submachine. An exit-point can be supported just as easily by passing the destination state(s) as template parameters to the submachine. 2) Introduce entry & exit points as first-class concepts. Implementing a state-boundary-crossing transition would then become a three step process:
a) define an entry/exit point, b) connect the point with an internal state, c) connect the point with an external state.
In my (admittedly biased) view and from a purely conceptual standpoint (ignoring e.g. performance and other real-world stuff for the moment), option 1 is clearly superior as it gives the user complete freedom how to tackle his design problems. Option 2 would be acceptable, when it is clear
that supporting 1) requires too many trade-offs.
My goal is not to reimplement Statechart but offer an alternative. It is a key point for Msm to provide an easy-to-use interface and increase reusability. And a list of destination states in the submachine definition does neither. But we already discussed this. I wrote in the documentation of Msm and repeated you that I could implement entry and exit pseudostates if users asked for it. And this only if I'm satisfied of the solution I would offer. Regards, Christophe
Christophe, We're now discussing so many different things at once that I think the main point in all this hasn't gotten the attention it deserves. In this post, I will therefore only answer where I feel that you did not understand my arguments, lost the thread or asked a question. Follow up to this thread if you must. As far as I'm concerned, we're done here. If you are still interested in discussing the main point then please answer in the following post: <http://thread.gmane.org/gmane.comp.lib.boost.devel/181515>
Whether you'd want to work with entry & exit points in the alarm-beeps case is a matter of taste. I personally wouldn't bother simply because it seems unlikely that it can be reused anywhere.
Do you mean your example is irrelevant or that reuse is not important?
Of course I meant neither, at least not in the generality you are suggesting. I meant that *in* *this* *particular* *example* reuse seems very unlikely and so it is a waste of time to work with entry and exit points as they only introduce additional complexity without offering any gain.
To reach a definite verdict in this particular example we'd need to define first what coupling in a state machine actually means. To my knowledge, nobody has done that so far.
Do you need more than common sense to know that if you need to see inside of a state machine you have coupling?
It's too bad that you've snipped the context because you seem to have lost the thread. Here's how we got here: <original-context>
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.
This is a matter of taste. I personally prefer this as it reduces the coupling of the system.
To reach a definite verdict in this particular example we'd need to define first what coupling in a state machine actually means. To my knowledge, nobody has done that so far.
Do you need more than common sense to know that if you need to see inside of a state machine you have coupling? </original-context>
Now, if you have a look at the statechart we were discussing <http://www.codeproject.com/KB/cpp/Statechart.aspx> then you see that the transition triggered by x is going from an inner state to its direct outer state. I don't see how your argument of "... that if you need to see inside of a state machine you have coupling?" applies because here nobody needs to see inside anything.
Just to make sure we're not talking past each other: With "entry/exit states" I guess you mean "entry point pseudostate" and "exit point pseudostate" as defined in UML?
Yes, are there other possibilities?
You are using undefined terminology so I had to make sure ("entry state" & "exit state" are not mentioned once in the UML standard).
You have read the whole paragraph, right? I quote it here for clarity:
<quote> A submachine state is semantically equivalent to a composite state. The regions of the submachine state machine are the regions of the composite state. The entry, exit, and behavior actions and internal transitions are defined as part of the state. Submachine state is a decomposition mechanism that allows factoring of common behaviors and their reuse. </quote>
Note the first sentence. What is unclear here?
Well, first why there are 2 terms. They are not equal but equivalent. So what is the difference?
I've mentioned it before: UML submachines are basically composite states with entry & exit points thrown in. They are *not* fully fledged state machines, as the design of Msm seems to suggest.
And what does it have to do with the subject?
See above.
Exactly. However, IIUC, at the moment Msm only supports a single entry point and a single exit point, which IMO also makes reuse harder than necessary, see below.
Again I have to disagree. When a program runs, it calls functions, which call other functions, etc. Now if you read a book of Model Driven Development, you'll probably find inside that a UML diagram and code are two views of the same model. And now we have it. You don't mind having a single entry point in a function, right? Why is it a problem in a diagram?
A composite state is not a single function. Rather, it consists of many functions (entry actions, transition actions, exit actions) that are called sequentially. Even without entry/exit points, it lies in the very nature of a composite state that the sequence in which those actions are called is not always the same. The only guarantee you have is that the entry action of the composite state is called first and the exit action is called last. Between those, the number of calls made to other actions and their sequence can vary widely depending on what events are processed. So why is it a problem when the composite state can be entered through multiple different entry points? Doing so only changes in what order the other actions are called but the entry/exit action still comes first/last.
Firstly, let's be clear that any reasonable semantics definition for FSMs (e.g. Harel, UML) absolutely requires that an entry action of a composite state/submachine is called when the composite state/submachine is entered and it doesn't matter at all how the state is entered (ordinary transition, state-boundary-crossing transition). The same goes for the exit action when the state is left.
Unfortunately I understood it the other way and had to go to great lengths in the example you gave me to avoid the entry of the composite. Maybe I'm not the only unreasonable and this brings confusion?
Not sure why you call yourself unreasonable. What/Who else is unreasonable? 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