Murray:

It is my experience that once one gains the skill of thinking of a problem in a state type design the coding of the implementation into C code is quite easy. There is generally no requirement for a tool of the type you describe.

One problem I have seen with the demo's of such tools that I've tried is that they get tied to a rather tight and rigid structure for the resulting code that they generate. Since, in my personal experience, every time I've ever coded up a new state machine for a problem I find that it ends up being coded in a way that closely fits the problem at hand. Sometimes this is done to make the implementation more efficient and other times it is done to make the state machine more extensible and maintainable. So from this experience I'd once again say I see little real value to such tools.

There is maybe one unique case where a tool of the sort that you mention may be of some value. If one is coding a state machine that had say greater than 30 or 40 states then there may be value to a graphical way to maintain the state machine as opposed to doing it at the C code level.

One more negative for machine auto generated code is that if you go to do an update to a state machine by inserting additional logic into the graphical tool and generating a new code set then it is necessary to fully unit test and validate every state and path through the state machine. On the other hand if you are adding a few things to an already hand built C code state machine it may be OK to just unit test the new states that were added or modified. (This is of course valid for scenarios where the code and the unit tester are the same person). If your business operation uses another validation methodology then it is most likely best to fully re-test the state machine with each change that is released.

Michael Karas