In the UML state machines internal transitions are different from self-transitions. Line (4) of Figure 2.12 demonstrates the difference. The state machine is in state "s11" when event A is injected. As in the case of the internal transition, the active state "s11" does not prescribe how to handle event A, so the event is passed on to the superstate "s1." The superstate has a self-transition triggered by A and so it executes actions associated with the transition (printout "s1-A;" in line (4)). This time, however, a regular transition is taken, which requires exiting the source state configuration and entering the target state configuration.

UML statecharts are extended state machines, meaning that in general, the actions executed by the state machine can depend also on the value of the extended state variables. Consider for example event D injected in line (5). The active state "s11" has transition D, but this transition has a guard [me->foo]. The variable me->foo is an extended state variable of the state machine from Figure 2.11. You can see that me->foo is initialized to 0 on the topmost initial transition.

Therefore the guard [me->foo], which is a test of me->foo against 0, evaluates to FALSE. The guard condition temporarily disables the transition D in state "s11," which is handled as though state "s11" did not define the transition in the first place. Therefore, the event D is passed on to the next higher level, that is, to state "s1." State "s1" has transition D with a complementary guard [!me->foo]. This time, the guard evaluates to TRUE and the transition D in state "s1" is taken.

As indicated in the diagram, the transition action changes the value of the extended state variable me->foo to 1. Therefore when another event D is injected again in line (6), the guard condition [me->foo] on transition D in state "s11" evaluates to TRUE and this transition is taken, as indicated in line (6) of Figure 2.12.

Line (7) of Figure 2.12 demonstrates that all exit and entry actions are always executed, regardless of the exit and entry path. The main target of transition C from "s1" is "s2." The initial transition in the main target state goes "over" the substate "s21" all the way to the substate "s211." However, the entry actions don't skip the entry to "s21." This example demonstrates the powerful concept of guaranteed cleanup of the source state configuration and guaranteed initialization of the target state configuration, regardless of the complexity of the exit or entry path.

Interestingly, in hierarchical state machines, the same transition can cause different sequences of exit actions, depending on which state inherits the transition. For example, in lines (8) and (9) of Figure 2.12, event E triggers the exact same state transition defined in the superstate "s." However, the responses in lines (8) and (9) are different because transition E fires from different state configurations--once when "s211" is active (line (8)) and next when "s11" is active (line (9)).

Finally, lines (11) and (12) of Figure 2.12 demonstrate that guard conditions can also be used on internal transitions. States "s2" and d both define internal transition I with complementary guard conditions. In line (11), the guard [!me->foo] enables internal transition instate "s2." In line (12) the same guard disables the internal transition in "s2," and therefore the internal transition defined in the superstate d is executed.

You can learn much more about the semantics of UML state machines by injecting various events to the QHSMTST.EXE application and studying its output. Because the state machine from Figure 2.11 has been specifically designed to contain all possible state transition configurations up to level 4 of nesting, this example can "answer" virtually all your questions regarding the semantics of statecharts. Moreover, you can use the source code that actually implements the state machine (located in <qp>\qpc\examples\80x86\dos\tcpp101\l\qhsmtst\qhsmtst.c) as a template for implementing your own statecharts. Simply look up applicable fragments in the diagram from Figure 2.11 and check how they have been implemented in qhsmtst.c.

Next in Part 3: Designing a UML State Machine

To read Part 1, go to "The over simplification of the event-action paradigm"

To read Part 3, go to "Designing a UML state machine"

Miro Samek, Ph.D., is president of Quantum Leaps, LLC. He can be contacted at miro@quantum-leaps.com. With Michael Barr, he is teaching the course "Event Driven Programmin (ESC-447) at the Embedded Systems Conference, Silicon Valley, March30 – April 2, 2009 in San Jose, Ca.

ESC course ESC-477.

Endnotes:
1. Harel, David, "Statecharts: A Visual Formalism for Complex Systems", Science of Computer Programming, 8, 1987, pp. 231-274, www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Statecharts.pdf

2. Object Management Group, "Unified Modeling Language: Superstate version 2.1.2", formal/07-11-02, see also www.omg.org/docs/formal/07-11-02.pdf

3. Selic, Bran, Garth Gulleckson, and Paul T. Ward, Real-Time Object-Oriented Modeling, John Wiley & Sons, 1994.

4. Petzold, Charles, Programming Windows: The Definite Developer's Guide to Programming Windows, Microsoft Press, 1996.

5. Booch, Grady, Object-Oriented Analysis and Design with Applications, Addison-Wesley, 1994.

6. Mellor, Stephen, "UML Point/Counterpoint: Modeling Complex Behavior Simply," Embedded Systems Programming, March 2000, www.embedded.com/2000/0003/0003feat1.htm

7. Douglass, Bruce Powel, Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns, Addison-Wesley, 1999.

8. Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.

9. Harel, David, and Michal Politi, Modeling Reactive Systems with Statecharts: The STATEMATE Approach, McGraw-Hill, 1998. Book no longer in print but it can be downloaded here: www.wisdom.weizmann.ac.il/~dharel/reactive_systems.html

10. Douglass, Bruce Powel, "UML Statecharts," Embedded Systems Programming, January 1999, pp. 22–42, www.embedded.com/1999/9901/9901feat1.htm

Editor's Note: This series of articles is based on material used with permission from Practical UML State Charts In C/C++, Second Edition, by Miro Samek, which was published by Elsevier/Newnes Publishing, which holds all copyrights. It can be purchased online at www.elsevier.com