Re: [boost] New library in Vault: Msm (Meta State Machine)

Subject: Re: [boost] New library in Vault: Msm (Meta State Machine)
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2008-10-19 09:11:03

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