The recent post about diagram drawing tools (Xfig and Dia, and I also tried Omni Graffle) started because I want to develop a state machine for the software I'm working on. But as I remove states, or discover new states (or realise I forgot some state), diagram drawing tools become cumbersome. Lines and boxes all over the place! To insert a state in the middle of all these, you may have to reroute existing lines. Sometimes you add the new lines and delete the old ones; and forget to delete some. Sometimes you do it the other way and forget to add some. Double check, triple check, quadruple check, ... it never ends! And when you think it's ended, there's always the nagging feeling, "did I break something?"
How nice would it be if I had some kind of state machine specification language of the form:
goto AtDinnerTable(); /* starting state */
state AtDinnerTable() {
entry:
printf("%d is at the dinner table\n", self.id);
eat_potatos_signal(n):
goto EatPotatos(n);
}
state EatPotatos(n) {
entry:
for i = 1 to n:
printf("%d: Potato number %d\n", self.id, i);
printf("%d using fork fetch a potato to plate.\n", self.id);
printf("%d eat potato.\n", self.id);
goto AtDinnerTable();
}
While it is straight forward enough to use a similar style for the actual code, what would be nice is to have something that converts that into a diagram. Much like how you markup your document using LaTeX and let the LaTeX engine handle the rest. The philosophy being authors should focus on writing the document, not what font it should be in, where to put page breaks, what the page width is, etc. Similarly, I would like to focus on adding, removing, or modifying states and transitions in the state diagram, not deciding where to put a box or how to route a transition line, and where to squeeze in the signal label for each transition.
All that sounds difficult for a machine to handle though.
Moreover there's the problem of the diagram changing too radically from one change to the next such that the author has to re-orientate to make sense of the updated diagram.How about a "red ink" concept? Take the current state of the diagram, use "red ink" to add a new state, add new transition lines (just use red ink link two states with a straight line!), delete old lines, and then update. The software can then do some animated magic to morph from the old diagram into the new one with as little restructuring as possible. Animated morphing is important so the author can be re-oriented from old to new diagrams. This would be an interactive and incremental approach to building state machines. And it could apply to other diagram drawing tools too. Hmm... it would be a really cool application for a tablet PC.
If only...
