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.