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.