https://www.omg.org/spec/UML/2.5.1/PDF
PDF PAGE 350
The semantics of individual types of Vertices are described below.
14.2.3.4 States
A State models a situation in the execution of a StateMachine Behavior during which some invariant condition holds. In
most cases this condition is not explicitly defined, but is implied, usually through the name associated with the State. 
For example, in Figure 14.36, which models the behavior of a telephone unit, the states “Idle” and “Active” represent 
situations where the telephone is and is not being used, respectively. This example also illustrates the fact that a State 
need not necessarily represent a fully static situation, as there is clearly some detailed activity occurring in the context 
of the “Active” state. However, throughout all that activity the telephone remains in use (i.e., “active”).
14.2.3.4.1 Kinds of States
The following kinds of States are distinguished:
 simple State (isSimple = true)
 composite State (isComposite = true)
 submachine State (isSubmachineState = true)
A simple State has no internal Vertices or Transitions. A composite State contains at least one Region, whereas a 
submachine State refers to an entire StateMachine, which is, conceptually, deemed to be “nested” within the State. A 
composite State can be either a simple composite State with exactly one Region or an orthogonal State with multiple 
Regions (isOrthogonal = true). For example, in Figure 14.9, State “CourseAttempt” is an example of a composite State 
with a single Region, whereas State “Studying” is a composite State that contains three Regions.
Any State enclosed within a Region of a composite State is called a substate of that composite State. It is called a direct
substate when it is not contained in any other State; otherwise, it is referred to as an indirect substate.
14.2.3.4.2 State configurations
In general, a StateMachine can have multiple Regions, each of which may contain States of its own, some of which may
be composites with their own multiple Regions, etc. Consequently, a particular “state” of an executing StateMachine 
instance is represented by one or more hierarchies of States, starting with the topmost Regions of the StateMachine and 
down through the composition hierarchy to the simple, or leaf, States. Similarly, we can talk about such a hierarchy of 
substates within a composite State. This complex hierarchy of States is referred to as a state configuration (of a State or 
a StateMachine). For example, one valid state configuration for an execution of the StateMachine depicted in Figure 
14.9 is: <CourseAttempt - Studying – (Studying::Lab2, Studying::TermProject, Studying::FinalTest)>. An executing StateMachine 
instance can only be in exactly one state configuration at a time, which is referred to as its active state configuration. 
StateMachine execution is represented by transitions from one active state configuration to another in response to Event
occurrences that match the Triggers of the StateMachine.
A State is said to be active if it is part of the active state configuration.
A state configuration is said to be stable when:
 no further Transitions from that state configuration are enabled and
 all the entry Behaviors of that configuration, if present, have completed (but not necessarily the doActivity 
Behaviors of that configuration, which, if defined, may continue executing).
After it has been created and completed its initial Transition, a StateMachine is always “in” some state configuration. 
However, because States can be hierarchical and because there can be Behaviors associated with both Transitions and 
States, “entering” a hierarchical state configuration involves a dynamic process that terminates only after a stable state 
configuration (as defined above) is reached. This creates some potential ambiguity as to precisely when a StateMachine 
is “in” a particular state within a state configuration. The rules for when a StateMachine is deemed to be “in” a State 
and when it is deemed to have “left” a State are described below in the sections “Entering a State” and “Exiting a State 
respectively.
308 Unified Modeling Language 2.5.1
PDF PAGE 351
A configuration is deemed stable even if there are deferred, completion, or any other types of Event occurrences 
pending in the event pool of that StateMachine
14.2.3.4.3 State entry, exit, and doActivity Behaviors
A State may have an associated entry Behavior. This Behavior, if defined, is executed whenever the State is entered 
through an external Transition. In addition, a State may also have an associated exit Behavior, which, if defined, is 
executed whenever the State is exited.
A State may also have an associated doActivity Behavior. This Behavior commences execution when the State is entered 
(but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be 
associated with the State, until:
 it completes (in which case a completion event is generated) or
 the State is exited, in which case execution of the doActivity Behavior is aborted.
The execution of a doActivity Behavior of a State is not affected by the firing of an internal Transition of that State.
14.2.3.4.4 State history
The concept of State history was introduced by David Harel in the original statechart formalism. It is a convenience 
concept associated with Regions of composite States whereby a Region keeps track of the state configuration it was in 
when it was last exited. This allows easy return to that same state configuration, if desired, the next time the Region 
becomes active (e.g., after returning from handling an interrupt), or if there is a local Transition that returns to its 
history. This is achieved simply by terminating a Transition on the desired type of history Pseudostate inside the Region.
The advantage provided by this facility is that it eliminates the need for users to explicitly keep track of history in cases 
where this type of behavior is desired, which can result in significantly simpler state machine models.
Two types of history Pseudostates are provided. Deep history (deepHistory) represents the full state configuration of the 
most recent visit to the containing Region. The effect is the same as if the Transition terminating on the deepHistory 
Pseudostate had, instead, terminated on the innermost State of the preserved state configuration, including execution of 
all entry Behaviors encountered along the way. Shallow history (shallowHistory) represents a return to only the topmost 
substate of the most recent state configuration, which is entered using the default entry rule.
In cases where a Transition terminates on a history Pseudostate when the State has not been entered before (i.e., no prior
history) or it had reached its FinalState, there is an option to force a transition to a specific substate, using the default 
history mechanism. This is a Transition that originates in the history Pseudostate and terminates on a specific Vertex (the
default history state) of the Region containing the history Pseudostate. This Transition is only taken if execution leads to
the history Pseudostate and the State had never been active before. Otherwise, the appropriate history entry into the 
Region is executed (see above). If no default history Transition is defined, then standard default entry of the Region is 
performed as explained below.
Deferred Events 
A State may specify a set of Event types that may be deferred in that State. This means that Event occurrences of those 
types will not be dispatched as long as that State remains active. Instead, these Event occurrences remain in the event 
pool until:
 a state configuration is reached where these Event types are no longer deferred or,
 if a deferred Event type is used explicitly in a Trigger of a Transition whose source is the deferring State (i.e., a
kind of override option).
An Event may be deferred by a composite State or submachine States, in which case it remains deferred as long as the 
composite State remains in the active configuration.
14.2.3.4.5 Entering a State
The semantics of entering a State depend on the type of State and the manner in which it is entered. However, in all 
cases, the entry Behavior of the State is executed (if defined) upon entry, but only after any effect Behavior associated 
Unified Modeling Language 2.5.1 309
PDF PAGE 352
with the incoming Transition is completed. Also, if a doActivity Behavior is defined for the State, this Behavior 
commences execution immediately after the entry Behavior is executed. It executes concurrently with any subsequent 
Behaviors associated with entering the State, such as the entry Behaviors of substates entered as part of the same 
compound transition.
The above description fully covers the case of simple States. For composite States with a single Region the following 
alternatives exist:
 Default entry: This situation occurs when the composite State is the direct target of a Transition (graphically, 
this is indicated by an incoming Transition that terminates on the outside edge of the composite State). After 
executing the entry Behavior and forking a possible doActivity Behavior execution, if an initial Pseudostate is 
defined, State entry continues from that Vertex via its outgoing Transition (known as the default Transition of 
the State). If no initial Pseudostate is defined, there is no single approach defined. One alternative is to treat 
such a model as ill formed. A second alternative is to treat the composite State as a simple State, terminating 
the traversal on that State despite its internal parts.
 Explicit entry: If the incoming Transition or its continuations terminate on a directly contained substate of the 
composite State, then that substate becomes active and its entry Behavior is executed after the execution of the 
entry Behavior of the containing composite State. This rule applies recursively if the Transition terminates on 
an indirect (deeply nested) substate.
 Shallow history entry: If the incoming Transition terminates on a shallowHistory Pseudostate of a Region of the 
composite State, the active substate becomes the substate that was most recently active prior to this entry, 
unless:
o the most recently active substate is the FinalState, or
o  this is the first entry into this State.
o In the latter two cases, if a default shallow history Transition is defined originating from the 
shallowHistory Pseudostate, it will be taken. Otherwise, default State entry is applied.
 Deep history entry: The rule for this case is the same as for shallow history except that the target Pseudostate is 
of type deepHistory and the rule is applied recursively to all levels in the active state configuration below this 
one.
 Entry point entry: If a Transition enters a composite State through an entryPoint Pseudostate, then the effect 
Behavior associated with the outgoing Transition originating from the entry point and penetrating into the State
(but after the entry Behavior of the composite State has been executed).
If the composite State is also an orthogonal State with multiple Regions, each of its Regions is also entered, either by 
default or explicitly. If the Transition terminates on the edge of the composite State (i.e., without entering the State), 
then all the Regions are entered using the default entry rule above. If the Transition explicitly enters one or more 
Regions (in case of a fork), these Regions are entered explicitly and the others by default.
Regardless of how a State is entered, the StateMachine is deemed to be “in” that State even before any entry Behavior or
effect Behavior (if defined) of that State start executing.
14.2.3.4.6 Exiting a State
When exiting a State, regardless of whether it is simple or composite, the final step involved in the exit, after all other 
Behaviors associated with the exit are completed, is the execution of the exit Behavior of that State. If the State has a 
doActivity Behavior that is still executing when the State is exited, that Behavior is aborted before the exit Behavior 
commences execution.
When exiting from a composite State, exit commences with the innermost State in the active state configuration. This 
means that exit Behaviors are executed in sequence starting with the innermost active State. If the exit occurs through an
exitPoint Pseudostate, then the exit Behavior of the State is executed after the effect Behavior of the Transition 
terminating on the exit point.
310 Unified Modeling Language 2.5.1
PDF PAGE 353
When exiting from an orthogonal State, each of its Regions is exited. After that, the exit Behavior of the State is 
executed.
Regardless of how a State is exited, the StateMachine is deemed to have “left” that State only after the exit Behavior (if 
defined) of that State has completed execution.
Encapsulated composite States
In some modeling situations, it is useful to encapsulate a composite State, by not allowing Transitions to penetrate 
directly into the State to terminate on one of its internal Vertices. (One common use case for this is when the internals of
a State in an abstract Classifier are intended to be specified differently in different subtype refinements of the abstract 
Classifier.) Despite the encapsulation, it is often necessary to bind the internal elements of the composite State with 
incoming and outgoing Transitions. This is done by means of entry and exit points, which are realized via the entryPoint 
and exitPoint Pseudostates.
Entry points represent termination points (sources) for incoming Transitions and origination points (targets) for 
Transitions that terminate on some internal Vertex of the composite State. In effect, the latter is a continuation of the 
external incoming Transition, with the proviso that the execution of the entry Behavior of the composite State (if 
defined) occurs between the effect Behavior of the incoming Transition and the effect Behavior of the outgoing 
Transition. If there is no outgoing Transition inside the composite State, then the incoming Transition simply performs a
default State entry.
Exit points are the inverse of entry points. That is, Transitions originating from a Vertex within the composite State can 
terminate on the exit point. In a well-formed model, such a Transition should have a corresponding external Transition 
outgoing from the same exit point, representing a continuation of the terminating Transition. If the composite State has 
an exit Behavior defined, it is executed after any effect Behavior of the incoming inside Transition and before any effect 
Behavior of the outgoing external Transition.
14.2.3.4.7 Submachine States and submachines
Submachines are a means by which a single StateMachine specification can be reused multiple times. They are similar 
to encapsulated composite States in that they need to bind incoming and outgoing Transitions to their internal Vertices. 
However, whereas encapsulated composite States and their internals are contained within the StateMachine in which 
they are defined, submachines are, like programming language macros, distinct Behavior specifications, which may be 
defined in a different context than the one where they are used (invoked). Consequently, they require a more complex 
binding. This is achieved through the concept of submachine State (i.e., States with isSubmachineState = true), which 
represent references to corresponding submachine StateMachines. The concept of ConnectionPointReference is 
provided to support binding between the submachine State and the referenced StateMachine. A 
ConnectionPointReference represents a point on the submachine State at which a Transition either terminates or 
originates. That is, they serve as targets for incoming Transitions to submachine States, as well as sources for outgoing 
Transitions from submachine States. Each ConnectionPointReference is matched by a corresponding entry or exit point 
in the referenced submachine StateMachine. This provides the necessary binding mechanism between the submachine 
invocation and its specification.
A submachine State implies a macro-like insertion of the specification of the corresponding submachine StateMachine. 
It is, therefore, semantically equivalent to a composite State. The Regions of the submachine StateMachine are the 
Regions of the composite State. The entry, exit, and effect Behaviors and internal Transitions are defined as contained in 
the submachine State.
NOTE. Each submachine State represents a distinct instantiation of a submachine, even when two or more submachine 
States reference the same submachine.
A submachine StateMachine can be entered via its default (initial) Pseudostate or via any of its entry points (i.e., it may 
imply entering a non-orthogonal or an orthogonal composite State with Regions). Entering via the initial Pseudostate has
the same meaning as for ordinary composite States. An entry point is equivalent to a junction Pseudostate (fork in cases 
where the composite State is orthogonal): Entering via an entry point implies that the entry Behavior of the composite 
state is executed, followed by the Transition from the entry point to the target Vertex within the composite State. Any 
guards associated with these entry point Transitions must evaluate to true in order for the specification to be well 
formed.
Unified Modeling Language 2.5.1 311
PDF PAGE 358
14.2.3.8.5 Transition ownership
The owner of a Transition is not explicitly constrained, though the Region in which it is contained must be owned 
directly or indirectly by the owning StateMachine. A suggested owner of a Transition is the innermost Region that 
contains both its source and target Vertices.
14.2.3.9 Event Processing for StateMachines
14.2.3.9.1 The run-to-completion paradigm
The processing of Event occurrences by a StateMachine execution conforms to the general semantics defined in Clause 
13. Upon creation, a StateMachine will perform its initialization during which it executes an initial compound transition
prompted by the creation, after which it enters a wait point. In case of StateMachine Behaviors, a wait point is 
represented by a stable state configuration. It remains thus until an Event stored in its event pool is dispatched. This 
Event is evaluated and, if it matches a valid Trigger of the StateMachine and there is at least one enabled Transition that 
can be triggered by that Event occurrence, a single StateMachine step is executed. A step involves executing a 
compound transition and terminating on a stable state configuration (i.e., the next wait point). This cycle then repeats 
until either the StateMachine completes its Behavior or until it is asynchronously terminated by some external agent.
StateMachines can respond to any of the Event types described in Clause 13 as well as to completion events (see 
above).
NOTE. As explained above, completion events have priority and will be dispatched ahead of any pending Event 
occurrences in the event pool.
Event occurrences are detected, dispatched, and processed by the StateMachine execution, one at a time.
NOTE. The order of event dispatching is left undefined, allowing for varied scheduling algorithms.
This cycle is referred to as the run-to-completion paradigm, and the corresponding StateMachine step is called a run-to-
completion step. Run-to-completion means that, in the absence of exceptions or asynchronous destruction of the context
Classifier object or the StateMachine execution, a pending Event occurrence is dispatched only after the processing of 
the previous occurrence is completed and a stable state configuration has been reached. That is, an Event occurrence 
will never be dispatched while the StateMachine execution is busy processing the previous one. This behavioral 
paradigm was chosen to avoid complications arising from concurrency conflicts that may arise when a StateMachine 
tries to respond to multiple concurrent or overlapping events.
When an Event occurrence is detected and dispatched, it may result in one or more Transitions being enabled for firing. 
If no Transition is enabled and the corresponding Event type is not in any of the deferrableTriggers lists of the active state 
configuration, the dispatched Event occurrence is discarded and the run-to-completion step is completed trivially.
Due to the presence of orthogonal Regions, it is possible that multiple Transitions (in different Regions) can be 
triggered by the same Event occurrence. The order in which these Transitions are executed is left undefined. Each 
orthogonal Region in the active state configuration that does not contain nested orthogonal Regions (i.e., a “bottom-
level” Region) can fire at most one Transition as a result of the current Event occurrence. When all orthogonal Regions 
have finished executing the Transition, the current Event occurrence is fully consumed, and the run-to-completion step 
is completed.
As mentioned above, it is possible for multiple mutually exclusive Transitions in a given Region to be enabled for firing
by the same Event occurrence. In those cases, only one is selected and executed. Which of the enabled Transitions is 
chosen is determined by the Transition selection algorithm described below.
During a Transition, a number of actions Behaviors may be executed. If such a Behavior includes a synchronous 
invocation call on another object executing a StateMachine, then the Transition step is not completed until the invoked 
object method completes its run-to-completion step.
Run-to-completion may be implemented in various ways. For active Classes, it may be realized by an event-loop 
running in its own thread, and that reads event occurrences from a pool. For passive Classes it may be implemented 
using a monitor.
316 Unified Modeling Language 2.5.1
PDF PAGE 359
IMPLEMENTATION NOTE. Run-to-completion is often mistakenly interpreted as implying that an executing 
StateMachine cannot be interrupted, which, of course would lead to priority inversion issues in some time-sensitive 
systems. However, this is not the case; in a given implementation a thread executing a StateMachine step can be 
suspended, allowing higher-priority threads to run, and, once it is allocated processor time again by the underlying 
thread scheduler, it can safely resume its execution and complete its event processing.
14.2.3.9.2 Enabled Transitions
A Transition is enabled if and only if:
• All of its source States are in the active state configuration.
• At least one of the triggers of the Transition has an Event that is matched by the Event type of the dispatched 
Event occurrence. In case of Signal Events, any occurrence of the same or compatible type as specified in the 
Trigger will match. If one of the Triggers is for an AnyReceiveEvent, then either a Signal or CallEvent satisfies
this Trigger, provided that there is no other Signal or CallEvent Trigger for the same Transition or any other 
Transition having the same source Vertex as the Transition with the AnyReceiveEvent trigger (see also 13.3.1).
• If there exists at least one full path from the source state configuration to either the target state configuration or
to a dynamic choice Pseudostate in which all guard conditions are true (Transitions without guards are treated as
if their guards are always true).
As more than one Transition may be enabled by the same Event occurrence, being enabled is a necessary but not 
sufficient condition for the firing of a Transition.
14.2.3.9.3 Conflicting Transitions
It is possible for more than one Transition to be enabled within a StateMachine. If that happens, then such Transitions 
may be in conflict with each other. For example, consider the case of two Transitions originating from the same State, 
triggered by the same event, but with different guards. If that event occurs and both guard conditions are true, then at 
most one of those Transitions can fire in a given run-to-completion step.
Two Transitions are said to conflict if they both exit the same State, or, more precisely, that the intersection of the set of 
States they exit is non-empty. Only Transitions that occur in mutually orthogonal Regions may be fired simultaneously. 
This constraint guarantees that the new active state configuration resulting from executing the set of Transitions is well 
formed.
An internal Transition in a State conflicts only with Transitions that cause an exit from that State.
14.2.3.9.4 Firing priorities
In situations where there are conflicting Transitions, the selection of which Transitions will fire is based in part on an 
implicit priority. These priorities resolve some but not all Transition conflicts, as they only define a partial ordering. The
priorities of conflicting Transitions are based on their relative position in the state hierarchy. By definition, a Transition 
originating from a substate has higher priority than a conflicting Transition originating from any of its containing States.
The priority of a Transition is defined based on its source State. The priority of Transitions chained in a compound 
transition is based on the priority of the Transition with the most deeply nested source State.
In general, if t1 is a Transition whose source State is s1, and t2 has source s2, then:
• If s1 is a direct or indirectly nested substate of s2, then t1 has higher priority than t2.
• If s1 and s2 are not in the same state configuration, then there is no priority difference between t1 and t2.
14.2.3.9.5 Transition selection algorithm
The set of Transitions that will fire are the Transitions in the Regions of the current state configuration that satisfy the 
following conditions:
• All Transitions in the set are enabled.
Unified Modeling Language 2.5.1 317
PDF PAGE 360
• There are no conflicting Transitions within the set.
• There is no Transition outside the set that has higher priority than a Transition in the set (that is, enabled 
Transitions with highest priorities are in the set while conflicting Transitions with lower priorities are left out).
This can be implemented by a greedy selection algorithm, with a straightforward traversal of the active state 
configuration. States in the active state configuration are traversed starting with the innermost nested simple States and 
working outwards. For each State at a given level, all originating Transitions are evaluated to determine if they are 
enabled. This traversal guarantees that the priority principle is not violated. The only non-trivial issue is resolving 
Transition conflicts across orthogonal States on all levels. This is resolved by terminating the search in each orthogonal 
State once a Transition inside any one of its components is fired.
14.2.3.9.6 Transition execution sequence
Every Transition, except for internal and local Transitions, causes exiting of a source State, and entering of the target 
State. These two States, which may be composite, are designated as the main source and the main target of a Transition 
respectively.
The main source is a direct substate of the Region that contains the source States, and the main target is the substate of 
the Region that contains the target States.
NOTE. A Transition from one Region to another in the same immediate enclosing composite State is not allowed.
Once a Transition is enabled and is selected to fire, the following steps are carried out in order:
1 Starting with the main source State, the States that contain the main source State are exited according to the 
rules of State exit (or, composite State exit if the main source State is nested) as described earlier.
2 The series of State exits continues until the first Region that contains, directly or indirectly, both the main 
source and main target states is reached. The Region that contains both the main source and main target states 
is called their least common ancestor. At that point, the effect Behavior of the Transition that connects the sub-
configuration of source States to the sub-configuration of target States is executed. (A “sub-configuration” here
refers to that subset of a full state configuration contained within the least common ancestor Region.)
3 The configuration of States containing the main target State is entered, starting with the outermost State in the 
least common ancestor Region that contains the main target State. The execution of Behaviors follows the rules
of State entry (or composite State entry) described earlier.
This transition execution algorithm is illustrated by the StateMachine example in Figure 14.2. In this case, when event 
“sig” is dispatched while the StateMachine is in State “S11” (the main source), the following sequence of actions will 
be executed:
        xS11; t1; xS1; t2; eT1; eT11; t3; eT111
S
exit/xS1
S1
exit/xS11
S11
entry/eT1
T1
entry/eT11
T11
entry/eT111
T111/t2 /t3
The Region of State S is 
the least common 
ancestor of S11 and T111
sig/t1
Figure 14.2  Compound transition example
318 Unified Modeling Language 2.5.1