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