Rhapsody Tip #39 - Nested states, the art of state-machine design (Intermediate)

Increasingly in my IBM Rational Rhapsody training I've been getting engineers to communicate with each other by drawing UML/SysML diagrams as a group exercise. Like with any natural language there is often more than one way to say the same thing. Knowing the best way is sometimes an art. The use of nested states is one such example. If you're building a state machine and I find I have many states reacting to the same event, then this little voice pops into my head which says "should I create a superstate?". Sometimes it's obvious whether a superstate is good, sometimes less so (that's the art). The key thing is that we do need to consider the readability of diagrams. We are, after all, using them to communicate. In this example I build a Rhapsody project from scratch with a simple state-machine that builds and executes and the user can interact with. I then show how the same behavior can be modeled in a different way by introducing a super state. Of course, knowing techniques like this also comes from experience. I like to think it also comes from training and the value of training is building people's confidence in using UML or the OMG Systems Modeling Language to communicate.