Re: [boost] [MSM] Comparison with ad-hoc FSM implementation

Subject: Re: [boost] [MSM] Comparison with ad-hoc FSM implementation
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-12-09 11:47:07

An interesting post, make sure this information is included in the 
tutorial/introduction
in the documentation.

Robert Ramey

Christophe Henry wrote:
> Hi Phil,
>
>> switch ((state<<8) | event) {
>>  case (Stopped<<8)|play:       start_playback(); state=Playing;
>>  break; case (Stopped<<8)|open_close: open_drawer();    state=Open;
>> break; etc. etc.
>
>
>> The greatest advantage of this ad-hoc style is that it is readable
>> by anyone who has even the most basic understanding of C++ without
>> the need to learn a new library, and its exact behaviour is
>> immediately evident.  It is also likely to compile and run quickly.
>>
>> I have no doubt that MSM has many benefits compared to this.  Perhaps
>> it would be useful to spell them out?
>
> The question is of course slighty provocative but still valid. The
> answer will be quite long, sorry about that.
>
> I won't say that your solution is not good. Actually if someone is
> happy with such a solution, great for him. If you check the review
> from Franz Alt, you'll see the source code generated by Rhapsody,
> which is not very different from this one, the O(1) double-dispatch
> excluded.
> And it's at least way better than non-formal state machines which I
> happen to see in production code again and again.
> A state machine library, including MSM, is made for people who are not
> happy with such an approach. I wrote MSM out of sheer frustration with
> Statechart's inability to provide me with what I was looking for, and
> out of admiration for the solution presented in the MPL book. I only
> hoped that others felt like me and would like an alternative.
> Concretely, what I was looking for:
> - a descriptive, expressive and declarative state machine syntax.
> - most of UML features which are hard to code with a switch/case
> dispatch.
> - a library with the explicit goal of supporting a
> Model-Driven-Development process
> - enough speed so that it'd be hard to reject a state machine simply
> on speed grounds (usual excuse).
>
> Next, you wil ask me what UML features I deem so important that it
> justifies a library.
> My personal favorites (order by what I use most):
> - events containing data. In your case, you are more or less forced to
> choose between the O(1) (which you did) and forgo event data or the
> O(n) (chosen by Rhapsody) at a speed cost. Metaprogramming techniques
> allow us a O(1) with event data.
> - actions/guards. Luckily, they are easy to implement in a
> switch/case.
> - orthogonal regions. I often use them for error handling and they
> greatly make the machine more readable by reducing the number of
> transitions. Also hard to get with a switch/case.
> - submachines (makes the code cleaner). Implementing them inside a
> switch case is simply horrible. Soon, you need to hide them in
> subclasses so we are already going in the direction of a library.
> - flags. Will make the calling code easier
> - exit points. Not my favorite, but always needed. Will quickly make
> your switch/case implementation hard to follow.
> - anonymous events. Hard to write with a switch/case dispatch. Luckily
> for your case, not everybody likes them.
> - history. Easy to implement in a switch/case (as long as you don't
> need them event-dependent) but doesn't make your code any more
> readable
>
> Of course, like always, developers use only 20% of all UML features.
> But it's never the same 20%, so what you need depends on your "coding"
> style.
> And if you want to implement all these features in a switch/case, your
> code will quickly become terrible. You'll have to issue guidelines on
> how to implement them, each developper will have to redo the same
> again and again with the corresponding flow of bugs (what if I forget
> a "break"? Uh oh) and low productivity (not even talking about
> documentation).
>
> Do we agree that this proves the need of a library?
>
> The next valid question would be, why MSM?
> It doesn't have to. If you're happy with Statechart or another library
> and don't need the speed, it's really ok for me, I promise ;-)
> MSM is for people who, like me, want a declarative syntax. People who
> want to have a look at the transition table and see the whole
> structure of a machine. Not as clearly as on a diagram but better than
> just code. That's why there is a transition table, and that's why
> there is eUML, to make it even clearer.
> This will greatly help us developers communicate with domain experts
> who will not understand code, but quite fast understand a state
> machine (I tried an it works).
>
> The second reason is the descriptive syntax of MSM. I wanted a library
> which would help a Model-Driven-Development. I wanted a library
> allowing us to switch from a graphical model to code and code to
> model. And I wanted the mapping to be complete. The goal would be to,
> at some point, never have to edit the code. I don't know how far I'll
> push it but you can be sure that I will push it as far as I can. This
> is where the functors added in eUML and the reusable states will help.
>
> I hope I managed to answer your question.
>
> Christophe
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost