[boost] [msm] Choosing initial event in sub machines

Subject: [boost] [msm] Choosing initial event in sub machines
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2010-06-09 17:58:09

Hi Michael,

> I just came along another question regarding state machines and sub
> machines.
>
> With "typedef my_initial_event initial_event" it is possible to customize
> the initial event.
> This does not work for nested sub machines, because in those cases msm
> just forwards the event that triggered the state change so that we end up
> in the sub machines initial state.
> Msm does not use the specified initial event of the sub machine to trigger
> the initial state of the sub machine.

Correct. This is actually the wanted behavior to respect the Liskov
substitutability principle. It would be confusing if you replaced a
substate by a submachine and get a different entry behavior.
This means that the containing machine's initial event will get
propagated to any substate or submachine marked as the initial.

> Actually, this is exactly the behaviour what we want

I'm not sure I get. You'd want the submachine to use its own initial
event and receive this one instead of the containing machine's? It's
probably possible but I'm wondering what could be a use case for this.
Could you please elaborate?

>but is it UML conform?
> Do you have any idea?

Neither is actually ;-)
UML does not define the notion of an initial event. It was added into
msm to allow a unique interface for entry behaviors (instead of one
for "normal" entries and one for entry through an initial
pseudo-state. All what UML defines is an initial pseudo-state which
can have only one outgoing transition to a real state (making it the
initial state). This cannot even be a real transition, it can have no
event and no guard, only an action.
So, as UML has no initial event and it is purely a msm construct, we
are free to define it as we wish.
I suppose we could allow the submachine to override the default
behavior, but I would need to see at least one compelling use case
before I punish compilers with some more metaprogramming ;-)

Regards,

Christophe