Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: Michael Caisse (boost_at_[hidden])
Date: 2009-12-05 19:03:19

David Bergman wrote:
>
> Repeating: the MSM/Statechart overlap in features and interface is quite unique to Boost. I argue that this is a bad thing. "You can never get too many goodies!" Well, I think you can. Is that situation bad enough not to be outweighed by the quite terrific design of MSM? Probably not, but I just wanted to raise the general question of duplicity (and redundancy), and also that of potentially deprecating libraries.
>
>   

Back in the mid to late 90's I worked closely with a company called ObjecTime [1]. They
were a telco spin-off that promoted a tool set and methodology called ROOM (Real-time
Object Oriented Modeling). ROOM was very successful to the point that the ObjecTime/IBM's
submission to OMG was about to be accepted as *the* real-time modeling language. Rational
was distraught and quickly purchased a controlling stake of ObjecTime and integrated ROOM
as the first release of UML for Real-time. 

What does all of this have to do with MSM/Statechart overlap? Even ObjecTime saw that 
not all FSM implementation/designs are created equal. While the "front end" modeling 
concepts provided a rich language that we could apply to various problem domains, not all 
domains have the same design/implementation requirements. A profitable, resource-conscience 
company made the choice to provide multiple FSM libraries implementing the same modeling 
concepts because it made good sense. 

I have my own graphical tool/code generator based heavily on ROOM and UML. I have considered
SC and MSM as additional backend offerings to my own FSM libraries. SC is a non-starter for
many of my (and my clients') targets with very small stack space. Constant creation/destruction
of state objects makes me seriously question the viability of that approach for those targets.
I have some small concern about the final build size of MSM; however, creating a machine
in global space that is completely initialized on start-up fits perfectly with the
requirements of those targets.

On the other hand, some of my targets running actual OS's with real amounts of memory 
create and destroy actors dynamically and perform various nifty dynamic port bindings that
are much more in-line with a design/implementation utilizing virtual functions and inheritance.
SC might be the perfect choice for these targets.

I have many other examples of why specifically different FSM's are appropriate for different
targets... but this email is already much longer than I had intended. Interface variations
make/break library adoption all the time. Design/implementation choices differentiate
libraries for specific domains constantly. There is so much more than equivalent feature
sets that make libraries "equivalent".

Best regards -
michael

[1] http://en.wikipedia.org/wiki/ObjecTime

-- 
----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com