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