Re: [boost] Re: Re: FSM library question

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-02-27 13:11:28

On Sun, 27 Feb 2005 10:57:16 +0100, Andreas Huber wrote
> Jeff Garland wrote:

> When I said that what you proposed doesn't break any UML mapping I 
> meant the process of *moving* the variables from Running/Active into 
> the FSM. Accoring to UML, auxillary state variables are stored in 
> one place, which is accessibly from all states of a particular FSM 
> (usually the state machine object). So, having variables in states 
> is "un-UML" already.

Interesting.  I can see significant value in encapsulating variables in states
for large state machines.
 
> I guess you mean the increase in complexity compared to the 
> traditional ways of implementing FSMs (nested switch case, state 
> pattern, etc.). I think there's an increase only for small simple 
> machines, like StopWatch. I think there is a (sometimes dramatic)
>  reduction of complexity for bigger (and more real-world) machines.

I addressed what I meant by complexity in my response to Darryl. The thing is
since we don't have an example of bad code that can be simplified by an fsm to
compare agaisnt in the docs and we can all think of easier ways to write the
StopWatch I worry that people will be put off.  So I think the remedy is to
just say that stopwatch is too simple to bother with fsm, but with bigger
state machines there is significant advantage.
 
> Currently there's no code generation and I doubt there'll ever be 
> such a tool (I personally wouldn't use it). IMHO, a reverse 
> engineering tool would be *much* more useful.

Perhaps.  If there was an XMI (UML to fsm generator or another state
definition language) it might be easy to generate.  And I agree it would be
nice to be able to visualize from written code.  But anyway, this is all nice
to have -- none of this can be done without the fsm library to start :)
 
 
> > So the
> > other general design question is -- when is it better to but the
> > variables asoociated with the machine in a state class versus pushing
> > them up to the machine?  
>
> You usually make variables as local as you can (i.e. push them 
> towards innermost states as much as possible). There would be more 
> to say here but I'll be off soon. More on this later...

Ok, good. I think this sort of discussion would be useful in the FAQ or
somewhere in the docs.

Jeff