Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: Darryl Green (darryl.green_at_[hidden])
Date: 2009-12-07 05:40:06

On Fri, 2009-12-04 at 13:53 +0100, Andreas Huber wrote:

> 1) Scalability: An MSM statemachine must be implemented in one TU, a 
> Statechart statemachine can be spread over multiple TUs
> 2) State-local storage: In Statechart, storage only exists while a state is 
> active. In MSM storage exists for the whole duration of the statemachine 
> lifetime
> 

I agree with this. However, I have yet to come completely to terms with
how best to use msm. I am beginning to think, in trying to use it, that
it would be better to separate the state transition table definition as
much as possible from what, in an msm world, are more like semantic
actions. This is very different from the more oo modeling approach of
statechart. I'm not sure the statechart isn't better at expressing fsms
that "emerge" out of overall application/system design in an all
encompassing oo design uml world, and msm better at expressing more self
contained "islands" of fsm in an app. I'm far from an expert with
spirit, but I think there are many concepts that could be borrowed from
it to make msm better able to be used to define a fsm that can be bound
to separate objects to implement behavior and exend its use beyond these
islands.

Basically, it needs to be easier to take a 1 TU transition table
integrate it into to a bigger multi TU system. To this end, it would be
helpful if msm defined some very clear and minimal concepts for those
entities it deals with:

events - msm doesn't really care what the event is - it just needs a
type. Probably nothing to define here...

actions - the functor approach is good - though it needs a bit more
development to make it easier to bind to actions that are not explicitly
designed for use as msm state machine actions.

guards - see actions...

states - I don't really understand what an instance of a state is in msm
- it doesn't model anything meaningful to me. This is unlike statechart,
where the idea of object instantiation as state is genuinely useful -
sometimes, and where it is the state that "reacts" to an event. Should
msm drop state objects altogether and simply have some sort of context /
current state object? Arguably it already has one in the form of the fsm
object - though that is a bigger concept than context. Michael Caisse
has already pointed out that there is something slightly odd about the
current state being represented as a scalar in a model that has objects
as states. I haven't spent much time thinking about this, but I feel it
is this machine/context concept that needs work to make extending the
fsm easier.