UML22 — Starting a state machine

Description:
The State Machines chapter (Section 2.12) does not provide a clear description of what it means to "start" a state machine.

Syntactically, we have the following:

o Well-formedness rule [1] for Pseudostate (p. 2-157) says "An initial vertex [i.e., a initial pseudostate] can have at most one outgoing transition and no incoming transitions". Presumably, it is the single transition from the initial pseudostate at the top level that is taken when the state machine starts.

o Well-formedness rule [6] for Transition (p. 2-160) says "An initial transition at the topmost level either has no trigger [i.e., event] or it has a trigger with the stereotype 'create'." Thus, the ONLY kind of event allowed on an initial transition is a "creation event".

o The definition of the stereotype <<create>> is (p. 2-149):

"Create is a stereotyped call event denoting that the instance receiving
that event has just been created. For state machines, it triggers the
initial transition at the topmost level of the state machine (and is the
only kind of trigger that may be applied to an initial transition)."

Thus, a "creation event" MUST be a call event.

o However, well-formedness rule [5] for Transition (p. 2-160) states without qualification, that "Transitions outgoing pseudostates may not have a trigger"! This prohibits all together the "creation events" allowed by rule [6].

Semantically, there is no specific discussion of how a state machine "starts". Section 2.12.4.3 describes "Entering a non-concurrent composite state" on p. 2-162 and "Entering a concurrent composite state" on p. 2-163. Since the top state of a state machine must be a composite state, one could assume that "starting" a state machine has the semantics of entering the composite top state. However, this does not provide an explanation of the "creation events" allowed (or at least seem intended to be allowed) in the special case of the initial transition at the top level.

Now, well-formedness rule [5] of StateMachine says "If a StateMachine describes a behavioral feature, it contains no triggers of type CallEvent, apart from the trigger on the initial transition (see OCL for Transition [8])" (this is probably intended to refer to Transition rule [6]). Presumably, then, the call event on the initial transition is suppose to be the call event for the behavioral feature described by the state machine, at least in this case, but this is not described in the semantics (and it doesn't make sense for this event to be a "creation" event, anyway).

This issue came out during the finalization of the Action Semantics. In the Action Semantics, when an object is created, any state machine associated with the object (via its classifiers) are NOT started automatically. Instead, there is an explicit "StartStateMachineAction" which is supposed to "start the execution of the state machines." However, it is not clear from the current state machine semantics what it really means to do this.

Recommendation:

1. Describe the "start" of the execution of a state machine as an RTC step from an implicit "not started" state (that is, not explicitly modeled in the state machine) to the target of the initial transition of the state machine (that is, the single transition with the top-level initial pseudo-state as its source). This RTC step includes the execution of any relevant transition actions and entry actions, per the usual state machine semantics.

2. Define that, if no other explicit specification is given in a model, a state machine associated with a classifier is assumed to start when an instance of the classifier is created and a state machine associated with a behavioral feature is assumed to start when that feature is invoked. (When the action semantics is included, a formal specification of the start of a state machine can be given with the StartStateMachineAction.)

3. Change well-formedness rule [5] to exclude the top initial pseudo-state.

4. Change well-formedness rule [6] to allow, if the state machine describes a behavioral feature, a trigger (call event or signal event) on the initial transition that corresponds to that behavioral feature.

5. If the state machine describes a classifier, then, in the absence of the action semantics, it is unclear whether a "creation event" is really useful at all (particularly since it would only allow for a single creation operation). With the action semantics, such an event is probably unnecessary, since the procedure for a creation operation will then be able to explicitly create an instance (using CreateObjectAction), start the state machine of that instance (using a StartStateMachineAction), which will get the state machine into a "real" state, and then send the instance a message (using an ExplicitInvocationAction), which can be handled by an event on the state machine, with any additional data required for initialization.

Disposition: Deferred to UML 2.4 RTF