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
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"
>> 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
> 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
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...
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk