Purpose
A statechart diagram (STD) describes the possible states
of a single class and the events that cause state transitions.
They are useful for showing the life cycle of the class.
Compared with activity diagram
Statechart and activity diagrams both describe state
transitions and share many of the same elements. An
activity diagram is most effective for describing processes
that involve more than one object.
Types of STDs
There are two kinds of STDs:
- One-shot life cycles describe objects with finite
lives. They have initial and final states:
- The initial state, in which the object is created,
is a solid circle.
- The final state, in which the object is destroyed,
is a bull's eye.
- Continuous loops describe objects that move through
a series of states. Where, how, and when the object
is created or destroyed is unimportant.
Contents
A state diagram defines:
- The external stimuli of the system: the events
- The values of objects: the states
- The changes of the object values: the transitions
- More than one transition may leave a state. The
first event to occur causes the corresponding transition
to fire. Transitions are guarded by conditions, that
is, an event can only fire a transition if the condition
of the event is true. A condition is valid over an
interval of time.
- The messages sent to classes: the event messages
Activities and actions
You use activities and actions to describe the response
of an object to an event:
| Operation |
Associated With |
Purpose |
timing |
| Activity |
State |
Relevant for control purposes |
Sequential or continuous; takes time to complete
|
| Action |
Event |
Not relevant for control purposes |
Instantaneous |
Decomposition of activities
You can define an activity further through graphical
decomposition. Opening an activity leads to another
STD that is the definition itself, or an AD.
An activity has a starting event, an ending event,
and possibly some intermediate events. A continuous
activity persists until an event terminates it by causing
a transition from the state. A sequential activity terminates
by itself after an interval of time.
Do not use super states to specify events or concurrency.
Specify these through decomposition diagrams. Use decomposition
to define activities as well. Each state in the decomposition
diagram represents one step of the activity. The decomposition
diagram is a one-shot diagram with input and output
transitions.
Example STD
A sample STD.
Control panel
The control panel for the STD.
States
State
A state represents an externally observable mode of
behavior that persists for a period of time. Activities
can run within a state. Transformations occur between
states rather than within a state. Use the
State with internal actions to add activities to
a state.
Label
state-name
Initial state
The initial state is the first state of behavior of
an object after its creation.
Label
state-name
The label is optional and usually not supplied.
Final state
The final state is the last state of behavior of an
object before it expires or is destroyed.
Label
state-name[(parameter[,parameter...])]
The label is optional and usually not supplied.
State with internal actions
Similar to a state without internal actions, but allows
you add to the lower area of the symbol the activities
initiated during this state.
Label for the upper area
state-name
Label for the lower area
one or more event condition activity send-clauses
where
- event specifies an event name and optional parameters:
- event-name(parameter, parameter, ...)
- condition specifies a guard condition in brackets:
- [ condition-text ]
- activity specifies a list of activities separated
by commas, where each activity has the syntax:
- /[name1=|name1:=]name2[(parameter[, parameter...])]
- send-clause has the syntax:
- name1.name2[(parameter[, parameter. . .])]
Note: Multiple send-clauses use the
following syntax:
^send-clause, send-clause. . .
This table shows example activities.
| Syntax |
Examples |
explanation |
| event/activity |
entry/entry-activity coins in(amount)/add to
balance exit/exit-activity |
Entering the state. Activity that takes place
inside the state. Exiting the state. |
| do/activity |
do/play dial tone |
Represents the invocation of a nested state
machine. |
| activity(parameter-list) |
XtRemoveGrab asked to remove a widget not on
the list (widget) |
An activity that may arise during the existence
of the state. The optional parameter list must
be enclosed in parentheses; separate parameters
with commas. |
Super State
A super state generalizes parts of a diagram. From
outside the diagram, you can treat the generalized part
as a single state.
States and transitions inside the super state are connected
to the outside via the super state only. Transition
arrows can be attached to the super state from the inside
and the outside. By nesting a relatively autonomous
part of a diagram in a super state, you can reduce the
number of transitions and make the diagram easier to
read.
Label
super-state
Concurrent state separators and State regions
Horizontal and vertical concurrent state separators
can be used to create concurrent state regions in a
super state.
Label
Each region has one label: name
History state
A concurrent state region can contain one history state
and one deep history state. A transition to the history
state indicates that the object resumes the state it
last had in this state region. A history state can have
multiple incoming events/actions. It can have at most
one unlabeled outgoing events/actions, which identifies
the state to "resume" if the transition occurs
before the object has been in the state identified by
the state region.
You can move a history state, but only within its concurrent
state region. You cannot resize a history state.
Label
No label.
Deep history state
A concurrent state region can contain one history state
and one deep history state. A transition to the deep
history state indicates that the object resumes the
state it last had at any depth within the state region.
A deep history state can have multiple incoming events/actions.
It can have at most one unlabeled outgoing events/actions,
which identifies the state to "resume" if
the transition occurs before the object has been in
the state identified by the state region.
You can move a history state, but only within its concurrent
state region. You cannot resize a history state.
Label
No label.
Events and Transitions
Transitions occur between two states
Transitions occur between two states:
- States (as source or target)
- States with internal actions (as source or target)
- Superstates (as source or target)
- Start states (only as source)
- Final states (only as target)
- History states (as source or target)
Transition
An event causes (or fires) a change of state: the transition.
The arrow of the transition indicates the order in which
the states appear. A complete STD specifies a state
sequence that is caused by an event sequence.
Label
event condition action send-clause
where
- event specifies an event name and optional parameters.
event-name(parameter, parameter, ...)
Alternatively, the UML suite recognizes two special
event names: when and after. In this case, the event
name is followed by a boolean expression in parentheses.
when (<boolean-expression>)
after (<boolean-expression>)
- condition specifies a guard condition in brackets.
[ condition-text ]
- action specifies a list of actions separated by
commas, where each action has this syntax:
/[name1=|name1:=]name2[(parameter[, parameter...])]
- send-clause has this syntax:
name1.name2[(parameter[, parameter...])]
Note: Multiple send-clauses use the
following syntax:
- ^send-clause, send-clause. . .
Complex transitions
You can use complex transitions to converge and
diverge transitions. Use the horizontal complex
transition to converge/diverge vertical transitions.
Use the vertical complex transition to converge/diverge
horizontal transitions.
Label
The label for a complex transition is the same as that
for a simple transition (see
Transition).
Event Messages to Classes
Class
A class in an STD represents a class receiving
an event. It is connected to a transition by an
event message.
Label
name
Classes referenced in an STD must be defined in
a class diagram.
Event message
An event message sends a message to a class. In
a complete model, every event message corresponds
to an operation in a CD.
An event message always originates from an event
and ends at a class.
Label
event-name[(parameter[,parameter. . .])] | 
