[boost] Re: Re: FSM library question

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-02-27 04:57:16

Jeff Garland wrote:
>> I don't think this breaks any mapping to UML. Also, I don't think
>
> Hmmm, ok.  I was thinking the mapping was 'mechanical'.
> States/Transitions map to bubbles / lines respectively, etc.

It usually is. There are a few limitations (see Limitations in the 
Rationale) that rarely prevent you from performing the mapping purely 
mechanically.

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.

>> So, the example kind of overuses the librarys' features to
>> show the functionality. It's a classical "school example" (not sure
>> whether one says this in English).
>
> Understood.  Getting an example of the right level is extremely
> difficult and I think overall you've done an excellent job in the
> tutorial.  Of course the interesting design question is, at one point
> does the obvious increase in code complexity make using the library
> 'worth using'?

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.

> For this discussion I'm presuming that there is no
> automated code generation which obviously changes things.

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.

>  And, of
> course, there's no right answer to the question -- which is why I was
> exploring my implementation options to understand how the code
> complexity / mapping would change if the state was concentrated in a
> single class instead of distributed amoungst the states.

Usually, having variables concentrated in one place increases the 
complexity, because you then have to manage access and lifetime 
manually. Plus, the class hosting the variables becomes a change hotspot 
(during development you often need to add/remove/change variables). In 
the StopWatch example, you only have the "problem" that the startTime_ 
variable is valid only when the FSM is in the Running state. In bigger 
FSMs, like e.g. Camera, you might have an awful lot such variables, most 
of which are only used in a tiny part of the machine. Even worse, you 
might have multiple people working on parts of the same FSM. Joe simply 
doesn't care what variables Bob needs for the operation of his part of 
the machine.

> 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?  Again there may be no answer here, but maybe
> someone that has implemented real code using fsm would have a design
> heuristic...

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...

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.