[boost] Re: FSM library question

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-02-27 06:40:52

Jeff Garland <jeff <at> crystalclearsoftware.com> writes:
> 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'?

When the obvious increase in code complexity is smaller than the obvious
decrease in code complexity?

I really need to ask - an obvious increase in complexity over what? I have
seen some truly complex code arise from *not* using an fsm framework in some
form or another.

My attempt at a heuristic is that one should consider using the fsm
libary when:

1) There are more than a handful of transitions per state

2) There are more than a handful of states

3) The state space is naturally hierarchical

4) There is substantial context associated with (groups of) states

If you have only (1) or (2), it is likely that the problem doesn't warrant
using boost fsm.
If you have (1) and (2) it is worth at least thinking about using boost fsm,
with substantial size or the presence of either of the other 2 features being
enough to make it pretty much an immediate choice.
  
> 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?

Innermost (leaf) states are usually empty, outer states are really a sort of
sub-machine and it is just a scoping issue - if the variable scope is clearly
tied to the lifetime of the outer state/sub-machine, put it there. Transition
functions then naturally are placed in the same state/context as the variables
they manipulate.

> Again there
> may be no answer here, but maybe someone that has implemented real code using
> fsm would have a design heuristic...

I have seen substantial reductions in code complexity arise out of using the
fsm libary in a refactoring of some existing code. The result is also much
easier to modify/maintain. This last point is particularly important if the
fsm is not well specified to start with and/or may need to be modified in
reaction to changes in requirements. Using boost fsm an iterative/exploratory
design approach works fine. In many ways this is less painful than if there
were a code generator. I'd actually prefer a diagram/documentation generator.

I'd be interested to hear other views on heuristics too. I haven't applied
my suggestion above to a sufficient variety of problems to be able to
state it with any authority. Anotehr heuristic that I see emerging is that
it where an number of little fsms turn up in a program it is worth at least
considering if more of the program cant be described as an fsm at a
design/modeling level. With the right tools this can result in something
that can be far more easily coded/validated/tested than by taking a more
fragmented approach.

Regards
Darryl Green.