State Model

It is best not to confuse the general idea of a statechart, state model or state machine (in the software industry these terms are often interchanged without clear definition or distinction) with the state modeling application prescribed by Shlaer-Mellor.

UML statecharts and state machines in general can be used for many purposes. For example, state machines (UML and otherwise) are often used in regular expression parsers. They are also used to define hardware logic. In these cases and others, the rules for creating, executing and applying these models varies.

With Shlaer-Mellor, we have two distinct purposes in mind. Primarily we want to specify the pattern of behavior followed by all instances of a Class. We also have another purpose which is to resolve competition with a single point of control in competitive Associations.

In Shlaer-Mellor, the a state model is a semantic mechanism for specifying behavior known as a Moore machine. A State Model is typically shown in diagram form as a UML statechart, but this representation is almost always incomplete (which events are ignored? unexpected? is a response defined for each Event in every State?). Furthermore, statecharts do not expose the execution semantics required to drive a State Model. So rule one in metamodeling statecharts is: ‘Don’t metamodel statecharts’. Rule two is: ‘Don’t metamodel statecharts!’

Instead, we model the Moore state table, because it best embodies the state execution rules. Understand how the state table works, and this metamodel should make some sense. See the Event Response class description for an example table.