3

3.73 Statechart Diagram

3.73.1 Semantics


Statechart diagrams repre sent the be havior of entities cap able of dy namic behavior by


specifying its r esponse to the rec eipt of event in stances. Typically, it is us ed for


describing the behavior of classes, but statecharts may also describe the behavior of


other model entities such as us e-cases, acto rs, su bsystems, operations, or methods.

3.73.2 Notation
A statechart diag ram is a gr aph that re presents a state m achine. States and various


other types of vertices (p seudostates) in the state mac hine graph are rendered by


appropriate state and pseudostate symbols, wh ile tra nsitions are generally rend ered by


directed arcs that inter-connect them. States may also contain subdiagrams by physical


containment or tiling. Note that every state machine has a top state, wh ich contains all
the other elements of the entire state m achine. The graphical rendering of this top state

is optional.

The assoc iation between a state mac hine and its co ntext does not have a sp ecial


notation.

An example statechart diagram for a simple telephone object is depicted in Figure 3-59


on page 3-127.

3-126 OMG-UML V1.3 March 2000

 3

Active
Timeout


do/ play message 

dial digit(n)


after (15 sec.) [incomplete]

after (15 sec.)


DialTone


dial digit(n)


Dialing
do/ play dial tone
lift


dial digit(n)[invalid]

receiver 

dial digit(n)[valid]
/get dial tone 

/connect
Invalid


do/ play message 

Connecting
Idle

busy
Pinned connected


Busy
callee


do/ play busy



tone


callee hangs up


caller


answers



hangs up
/disconnect Ringing
Talking 

callee answers do/ play ringing



/enable speech tone



Figure 3-59 State Diagram

3.73.3 Mapping
A statechart diagram maps into a StateMachine. That StateMachine may be owned by


a model elem ent c apable o f dynamic behavior, such as classifier o r a b ehavioral

feature, which provides the context for that state m achine. Different contexts may


apply different sema ntic constraints o n the state m achine.

3.74 State

3.74.1 Semantics
A state is a condition during the life of an object or an interaction during which it


satisfies so me con dition, perf orms some action , or waits for some event. A composite 

state is a state that, in co ntrast to a simple state, has a g raphical decomposition.



(Composite states and their notation are described in m ore detail in S ection 3.75,
“Composite States,” on page 3-130.) Conceptually, an object remains in a state for an
interval of time. However, the semantics allow for modeling “flow-through” states that


are ins tantaneous, as well as t ransitions that are not in stantaneous.

OMG-UML V1.3 State March 2000 3-127


3
A state may be used to m odel an ongoing activity. Such an activity is specified eith er


by a ne sted state m achine or by a co mputational expression.

3.74.2 Notation
A state is shown as a rectangle with rounded corners (Figure 3-60 on page 3-129).
Optionally, it m ay have an attached nam e tab. The nam e tab is a r ectangle, usually


resting on the outside of the top side of a state and it contains the name of that state. It
is normally used to keep the name of a composite state that has concurrent regions, but


may be used in o ther cases as well (the Process state in Figu re 3-65 on page 3-137
illustrates the use of the name tab).

A state may be optionally subdivided into multiple compartments separated from each


other by a horizontal line. They are a s follows:

• 

Name compartment

This compartment ho lds the ( optional) name of the state, as a string . States without


names are anonymous and are all distinct. It is undesirable to show the same named


state twice in th e same diag ram, as co nfusion may ensue. Name compartments


should not be used if a name tab is used and vice versa.

• Internal transitions compartment

This compartment holds a list of internal actions or activities that are performed


while the elem ent is in the state . The n otation for each o f these list item s has th e


following gen eral f ormat:



action-label ‘/’ action-expression



The ac tion lab el id entifies the circ umstances un der which th e action sp ecified by the


action expression will b e invoked. The action expression may use an y attributes and
links that are in the sco pe of the o wning entity. For list item s where th e action


expression is em pty, the backslash separa tor is optional.

A number of action labels are reserved for various special purposes and cannot be used


as event n ames. The following are th e reserved actio n labels an d their m eaning:
• 

entry

This label identifies an action, specified by the corresponding action expression,



which is perf ormed upon entry to the state ( entry action).

• 

exit

This label identifies an action, specified by the corresponding action expression,

that is performed upon exit from the state ( exit action ).

• 

do

This label identifies an on going activity (“do activity”) that i s performed as long as


the modeled ele ment is in the state or un til the com putation sp ecified by the ac tion

expression is com pleted (the latter m ay result in a com pletion event bein g
generated).

3-128 OMG-UML V1.3 March 2000

 3
•

include

This lab el is used to iden tify a sub machine invocation. The action expression


contains the name of the submachine th at is to be in voked. Submachine states and

the co rresponding notation are des cribed in Section 3.81, “Submachine States,” o n

page 3-142.

In all oth er cases, the action lab el id entifies the e vent that trigg ers the corresponding
"

action expression. These e vents are called in ternal trans itions and are sem antically


equ ivalent to self t ransitions except tha t the state is n ot exited o r re-entered. This
#

means th at th e cor responding exit and entry actions are not per formed. The general
format for the list item of an internal transition is:
#

event-name ‘(’ comma-separated-parameter-list ‘)’ ‘[’ guard-condition‘]’ ‘/’

 $

action-expression

Each event name may appear more than once per state if the guard conditions are


different. The e vent param eters and th e guard con ditions are optional. I f the e vent has
!

parameters, they can be us ed in th e action expression through th e current event

%

variable.

3.74.3 Example

Typing Password

entry / set echo invisible

'

exit / set echo normal

'

character / handle character



help / display help

Figure 3-60 State

&

3.74.4 Mapping
A state symbol maps into a State. See Section 3.75, “Composite States,” on page 3-130


for further details on which kind of state.

The name string in the symbol maps to the name of the state. Two symbols with the


same name map into th e same state . However, each state sy mbol with no name (or an


empty name strin g) maps into a distin ct an onymous State.

A list item in the in ternal transitio n com partment maps into a corr esponding Action


asso ciated with a s tate. An “entry” list item (i.e., an item with the “entry” label) maps
to th e “entry” role, an “e xit” list item maps to the “e xit” role, and a “do” item maps to

the “do Activity” role. ( The m apping of “in clude” item s is dis cussed in Section 3.81,

“Submachine States,” on page 3-142.)

OMG-UML V1.3 State March 2000 3-129


3
A list item with an event name maps to a Transition associated with the “internal” role


relative to the state. The action expression maps into the ActionSequence and Guard
for the Transition. The event name and arguments map into an Event corresponding to
the event nam e and arguments. The T ransition has a trigger Association to the Ev ent.


3.75 Composite States

3.75.1 Semantics
A composite state is decom posed in to two or m ore concurrent substates (c alled


regions) or into mutually exclusive disjo int s ubstates. A g iven state may only be
refined in one of these two ways. Naturally, any substate of a composite state c an also


be a co mposite state o f either type.

A newly-created ob ject ta kes its to pmost d efault transition, originating from the


topmost in itial pseudostate. An o bject that tra nsitions to its ou termost final state is

terminated.

Each region of a state m ay have initial ps eudostates and final states. A tr ansition to the


enclos ing state represents a transitio n to the initial p seudostate. A trans ition to a f inal


state represents the completion of activity in th e enclosing region. Completion of



activity in all co ncurrent regions represents co mpletion of activity by the enclosing



state and triggers a completion event on the enclosing state. Completion of the top state


of an o bject c orresponds to its ter mination.

3.75.2 Notation
An expansion of a state shows its internal state machine structure. In addition to the
(optional) name and internal tr ansition compartments, the state may have an add itional


compartment that co ntains a r egion holding a nested diagram. For convenience a nd



appearance, the te xt compartments may be sh runk horizontally with in th e graphic

*

region.

An expansion of a state in to concurrent substates is shown by tiling the g raphic region



of the state us ing dash ed lines to divide it into regions. Each region is a con current


substate. Each region may have an optional name and must contain a nested state


diagram with disjoint state s. The text compartments of the entir e state ar e sepa rated
from the concurrent substates by a solid line. It is also possible to use a tab notation to
!

place th e name of a c oncurrent state. The tab n otation is more spac e efficient.

An expansion of a state into disjoint substates is shown by showing a nested state



diagram within th e graph ic region.

An in itial pseudostate is s hown as a sm all so lid filled circle . In a top -level state


machine, the transition from an in itial pseudostate may be lab eled with th e event th at


creates the o bject; oth erwise, it m ust be u nlabeled. If it is u nlabeled, it represents an y

transition to th e enclosing state. T he initial tra nsition may have an actio n.

3-130 OMG-UML V1.3 March 2000

 3
A final state is sho wn as a circle surrou nding a sm all solid filled circle (a bull’s eye). It


represents the com pletion of activity in the enclo sing state and it trigg ers a transitio n


on the enclo sing state la beled by the implicit a ctivity com pletion event (usually


displayed as an unlabeled transitio n), if su ch a tr ansition is def ined.

In some cases, it i s convenient to hid e the decom position of a com posite state. For
"

example, the state ma chine insid e a com posite state may be very large and may simply
not fit in the graphical space available for the diagram. In that case, the composite state


may be represented by a simple state g raphic with a special “c omposite” icon, usually
in the lower right-hand corner. This icon, consisting of two horizontally placed and


connected states, is an optional visual cue that the state has a decomposition that is not
+

shown in this particular s tatechart diagram (F igure 3-62 on page 3-131). Instead, the


contents of the composite state are shown in a separate diagram. Note that the “hiding”
here is purely a matter of graphical convenience and has no semantic significance in
terms of acce ss restrictions.

3.75.3 Examples

Dialing

Start digit(n) Partial Dial [number.isValid()]

entry/ start dial tone entry/number.append(n)
' '

exit/ stop dial tone

'

digit(n)

Figure 3-61 Sequential Substates

&

HiddenComposite
entry/ start dial tone
'

exit/ stop dial tone

'

Figure 3-62 Composite State with hidden decomp osition indicator icon

OMG-UML V1.3 Composite States March 2000 3-131


3

Taking Class

Incomplete
lab
lab done done
Lab1 Lab2

Passed
3

project done
2

Term
Project

pass
2

Final
Test

fail
Failed

Figure 3-63 Concurrent Substates

&

3.75.4 Mapping
A state symbol maps into a State. If the sy mbol has n o subdiagrams in it, it m aps into


a Sim pleState. If it is tiled by dashed lin es into regions, th en it m aps into a

/

CompositeState with th e isConcurrent value true; oth erwise, it m aps into a

0

CompositeState with th e isConcurrent value false. A region maps into a

/

CompositeState with th e isRegion value true an d the isConcurrent value false.

0 0

An initial pseudostate symbol map into a Pseudostate of kind initial. A final state
0

symbol maps to a final state.

1

 

3.76 Events

3.76.1 Semantics
An event is a noteworthy occurrence. For practical purposes in state diagrams, it is an


occurrence that may trigger a s tate transition. Events m ay be o f several kinds (not
necessarily m utually exclusive).

3-132 OMG-UML V1.3 March 2000

 3
• 

A designated condition beco ming true (described by a Boolean expression) resu lts
in a ch ange event in stance. The event occurs whe never th e value of the e xpression


changes from false to true. Note that th is is dif ferent from a gu ard cond ition. A
guard condition is e valuated once whenever its event fires. If it is false, then the
+

transition does no t occur and the e vent is los t.

The receipt of an explicit signal from one object to another results in a signal event
instance. It i s denoted by the sig nature of the e vent as a tr igger on a tr ansition.
• The receipt of a call for an operation implemented as a transition by an object
represents a call event instance.
• 

The passage of a designated period of time af ter a d esignated event (often the entry


of the current state) or the occurr ence of a gi ven date/time is a T imeEvent.

The event declaration has scope within the package it appears in and may be used in


state diagrams for classes that h ave visibility inside the p ackage. An event is not local 5

to a sing le class.

3.76.2 Notation
A signal or call event can be defined using the following format:
#

event-name ‘(‘ comma-separated-parameter-list ‘)



A parameter has the format:

parameter-name ‘:’ type-expression

(

A signal can be declared using the «signal» keyword on a class symbol in a class


diagram. The par ameters ar e spec ified as attributes. A sig nal can be specified as a


subclass o f ano ther sign al. This ind icates th at an occurre nce of the su bevent triggers


any transitio n th at depends on the event o r any of its ancestors.

An elapsed-time event can be specified with the keyword after followed by an

7

expression that e valuates (a t modeling time) to an am ount o f tim e, such as “ after (5



7


seconds)” o r after (10 seconds sin ce exit from state A).” If no starting point is


7


indicated, then it is the time since the entry to th e current state. Other time events can
be sp ecified as co nditions, such as when (date = J an. 1, 2000).



A condition becoming true is shown with the keyword when followed by a Boolean
8

expression. This may be regarded as a con tinuous test for the con dition until it is tr ue,


although in practice it w ould only be checked on a change of values.



Signals can be declared on a cla ss diagram with the keyword «sig nal» on a re ctangle


symbol. These def ine sig nal n ames that m ay be used to trigger tr ansitions. Their
!

para meters are shown in th e attr ibute com partment. They have no operations. They
may appear in a generalization hierarchy.

OMG-UML V1.3 Events March 2000 3-133


3

3.76.3 Example

«signal»
InputEvent

time
:

«signal»
UserInput
device

«signal» «signal»
Mouse Keyboard
Button
9

Character
location character

«signal» «signal» «signal» «signal»

Mouse Mouse Control Graphic
Button Button Character Character
Down Up

«signal»
;
«signal» «signal»
Space Alphanumeric Punctuation

Figure 3-64 Signal Declaration

3.76.4 Mapping
A class box with stereotype «signal» maps into a Signal. The name and parameters are
given by the n ame string and th e attribute list of th e box. Gen eralization arrows


between sig nal class b oxes map in to Generaliz ation relationships betwee n the Sig nal.

The usage of an event strin g expression in a co ntext req uiring an e vent map s into an


implicit reference of the Event with the given name. It is an error if various uses of the


same name (includ ing any explicit d eclarations) do not match.

3-134 OMG-UML V1.3 March 2000

 3

3.77 Simple Transitions

3.77.1 Semantics
A simple transition is a relationship between two states indicating that an object in the


first state will enter the secon d state and perform specific actions when a sp ecified


event occurs p rovided that cer tain specif ied conditions are satisfied. On su ch a chan ge


of state , the tra nsition is said to “f ire.” The trigg er for a tr ansition is the occurr ence of
the event labeling the transition. The event may have parameters, which are accessible

by the action s specified on the transition as well a s in the c orresponding exit and entry


actions associated with th e sou rce and target states re spectively. Events are processed


one at a tim e. If an event does not trigger any transition, it is discarded. If it can trigger
more than one transition within the sam e sequential region (i.e., not in different


con current re gions), only one will f ire. If these conflicting trans itions are of the sam e
!

priority, an arbitra ry one is s elected an d trigg ered.

3.77.2 Notation
A transition is shown as a solid line originating from the source state and terminated


by an a rrow on the target state. It may be labeled by a transition string that has the
( (

following gen eral f ormat:

#

event-signature ‘[’ guard-condition ‘]’ ‘/’ action-expression



The event-signature describes an e vent with its arguments:



event-name ‘(’ comma-separated-parameter-list ‘)’



The guard-condition is a Boolean expression written in terms of parameters of the



triggering event an d attributes and links of the object tha t owns the state ma chine. The

guard condition may also involve tests o f con current state s of the curr ent machine, or
<

explicitly designated s tates of so me reachable object (for example, “ in State1” or “not



=


in State2”). State names may be fully qualified by the ne sted states that co ntain them,


>

yielding pathnames of the form “Stat e1::State2::State3.” T his m ay be u sed in case



same state name occurs in d ifferent c omposite state regions of the overall m achine.

The action-expression is executed if and when the transition fires. It may be written in


terms of operations, attributes, and links of the owning object and the parameters of the

triggering event, or any other features visib le in its scope. The corresponding action

must be executed entir ely before any other actions are c onsidered. This mo del of


execution is ref erred to as run-to-completion semantics. The action expression may be



an actio n seq uence comprising a number of distinct acti ons including actions that


explicitly g enerate events, su ch as send ing sig nals or in voking operations. The d etails


of this expression are dep endent on the ac tion lan guage cho sen for the m odel.

3.77.2.1 Transition times

Names may be placed on transitions to d esignate the tim es at wh ich they fire. See


Section 3.62, “Transition Times,” on pag e 3-104.

OMG-UML V1.3 Simple Transitions March 2000 3-135


3

3.77.3 Example
right-mouse-down (location) [location in window] / object := pick-object (location);
object.highlight ()
?

The event may be any of the standard event types. Selecting the type depends on the


syntax of the n ame (for time e vents, f or example); however, SignalEvents an d

/

CallEvents a re not distinguishable by syntax and must be disc riminated by their



declaration elsewhere.

3.77.4 Mapping
A transition string and th e transitio n arrow that it labels togeth er map into a Transition


and its atta chments. The arrow connects two state sy mbols. The T ransition has th e


corresponding States as its sou rce (the state a t the tail) and destination (the state at the
@

head) States in association to th e Transition.

The event n ame and parameters m ap into an Event elem ent, whic h may be a


SignalEvent, a C allEvent, a TimeExpression (if it ha s the proper syntax), o r a

/

ChangeEvent (if it is expressed as a B oolean expression). The event is atta ched as a

“trigger” role in the asso ciation to the tr ansition.
*

The g uard co ndition maps into a Guard elem ent attached to the Transition. Note th at a


guard condition is distinguished graphically from a change event specification by being



enclosed in brackets.

An action expression maps into an Action attached as an “effect” role relative to the
Transition.


3.78 Transitions to and from Concurrent States

A concurrent transition may have multiple source states and target states. It represents


a synchronization and /or a splittin g of control in to con current threads witho ut



concurrent substates.

3.78.1 Semantics
A concurrent transition is enabled when all the source states are occupied. After a


compound transition fires, all its d estination states ar e occu pied.

3.78.2 Notation
A concurrent transition includes a short heavy bar (a synchronization bar, which can


represent synchronization, forking, or both). The bar may have one or more arrows


from states to th e bar (these a re the sou rce sta tes). The bar may have one or more
)

arrows from the b ar to states ( these ar e the destination states ). A transitio n string may
A

be shown near the bar. Individual arr ows d o not have their own transition string s.

3-136 OMG-UML V1.3 March 2000

 3

3.78.3 Example
Process

A1 A2
-

Setup 

Cleanup

B1 B2

Figure 3-65 Concurrent Transitions

3.78.4 Mapping
A bar with multiple transition arrows leaving it maps into a fork pseudostate. A bar


with multiple tr ansition arrows entering it maps into a join pseudostate. The transitions


corr esponding to the inco ming and outgoing arrows attac h to th e pseu dostate as if it


were a regular state. If a bar has multiple incoming and multiple outgoing arrows, then

it m aps into a join connected to a fork p seudostate b y a sin gle transition with no


atta chments.

3.79 Transitions to and from Composite States

3.79.1 Semantics
A transition drawn to the boundary of a composite state is equivalent to a transition to
its initial point (or to a complex transition to the initial point of each of its concurrent
*

regions, if it is co ncurrent). The entry action is always performed when a state is



entered from outside.

A transition from a composite state indicates a transition that applies to each of the


states within th e state r egion (at a ny depth). It is “in herited” by the nested states.
Inherited tr ansitions can be masked by the presence of nested transitions with the sam e
"

trigger.

3.79.2 Notation
A transition drawn to a composite state boundary indicates a transition to the


composite state. This is equ ivalent to a tr ansition to th e initial pseu dostate with in th e


com posite state r egion. The initial pseu dostate m ust be p resent. If the state is a


con current co mposite state, then th e transition ind icates a tra nsition to th e initial
!

pseudostate of each of its c oncurrent su bstates.

OMG-UML V1.3 Transitions to and from Composite States March 2000 3-137

3
Transitions may be drawn directly to states with in a com posite state r egion at an y


nesting depth. All entry actions are performed for any states that are entered on any
transition. On a tr ansition within a concurrent com posite state, transitio n arrows from

the synchronization bar may be drawn to on e or more concurrent states. Any other

concurrent re gions star t with their def ault initial p seudostate.

A transition drawn from a c omposite state boundary ind icates a tra nsition of th e


com posite state . If such a tr ansition fires, any nested states are forcibly terminated an d
!

perf orm their e xit actions, then the tra nsition action s occur and the ne w state is


established.

Transitions may be drawn directly from states within a c omposite state region at a ny
nesting depth to outside states. All exit actions are performed for any states th at are


exited on any transitio n. On a tra nsition from with in a con current composite state,
transition arrows m ay be s pecified from one or m ore con current state s to a

synchronization bar; therefore, sp ecific states in th e oth er regions are ir relevant to

triggering the tr ansition.

A state region may contain a history state indicator shown as a small circle containing

B

an ‘H.’ The histor y indicator applies to the state region that dir ectly contains it. A
history indicator may have any number of incoming transitions from outside states. It


may have at m ost o ne ou tgoing unlabeled tra nsition. This id entifies the def ault
“previous state” if the region has never been entered. If a transition to the history
indicator fires, it indicates that the object resumes the state it last had within the


composite regio n. Any necessary entry actions are performed. The histo ry ind icator
may also be ‘H*’ for deep histo ry. This ind icates th at the o bject re sumes th e state it
A

last had at any depth within the composite region, rather than being restricted to the


state at the sam e level as the history indicator. A re gion may have both shallo w and


deep history indicators.

3.79.3 Presentation Options

3.79.3.1 Stubbed transitions

Nested states may be su ppressed. Transitions to nested states a re subsumed to th e most


specific visib le enclosing state of the suppressed s tate. Sub sumed trans itions that do
not com e from an un labeled f inal state or go to an unlabeled in itial pseudostate may


(but need not) be shown as coming from or going to stubs. A stub is shown as a small
 

vertical lin e (bar) drawn inside the boundary of the en closing state. It indicates a
transition connected to a sup pressed in ternal state. Stubs are not used for tr ansitions to

initial o r from final states.

Note that events should be shown on transitions leadin g into a state, either to the state


boundary or to an internal su bstate, including a tr ansition to a stubbed state. Normally



events sh ould no t be sh own on trans itions leading from a stub bed state to an e xternal


state. Thin k of a transitio n as b elonging to its sou rce state. If the so urce state is


suppressed, then so are the d etails o f the transition. Note also that a transitio n from a
final state is su mmarized b y an u nlabeled transitio n from the com posite state c ontour


(denoting the im plicit event “action com plete” f or the corresponding state) .

3-138 OMG-UML V1.3 March 2000

 3

3.79.4 Example
See F igure 3-64 on page 3-134 and Figure 3-65 on page 3-137 for examples of


composite tr ansitions. The following are examples of stub bed transitions and the
history indicator.

W E

s
p E

s
E
D

A C
u
t


r F
B
D

may be abstracted as

s
E

p W D

C
C

A
r
B
D

Figure 3-66 Stubbed Transitions

&

C
interrupt
A A1 D

resume
H
A2

Figure 3-67 History Indicator

OMG-UML V1.3 Transitions to and from Composite States March 2000 3-139

3

3.79.5 Mapping
An arrow to any state bo undary, nested or no t, maps in to a T ransition between the


corr esponding States and sim ilarly for transitio ns d irectly to his tory states.

A history indicator maps into a Pseudostate of kind shallowHistory or deepHistory.

A

A stubbed transition does not map into anything in the model. It is a notational elision
that indicates the presence of tra nsitions to additional states in the m odel th at are no t

visible in the diagram.

3.80 Factored Transition Paths

3.80.1 Semantics
By definition, a tr ansition connects exactly two vertices in the state m achine graph .
F

However, since some of these vertices may be pseudostates (which are transient in
nature) there is a need for describing chains of transitions that may be executed in the


context of a sin gle run -to-completion s tep. Such a transitio n is known as a compound


transition.
(

As a prac tical measure, it is o ften useful to share segments of a c ompound transition.

For example, two or more distinct compound transitions may come together and


continue via a common path , sharing its action, and p ossibly terminating on the sam e
target state. In other cases, it may be useful to split a transition into separate mutually

exclusive (i.e., non-concurrent) paths.

Both of these examples of graphical factoring in which some transitions are shared
*

result in s implified diagram s. However, factoring is also useful for modeling



dynamically ad aptive behavior. An example o f this occu rs wh en a single event may

lead to any of a set of possible target states, but where the final target state is only


determined as the result of an action (calculation) performed after the tr iggering of the


compound transition.

Note th at the splittin g and join ing of path s du e to f actoring is d ifferent from the


splitting and joining of concurrent transitio ns described in Section 3.78, “Transitions to



and from Concurrent States,” on page 3-136. The sources an d targets of these f actored
transitions are not con current.

3.80.2 Notation
Two or more transitions emanating from different non-concurrent states or
!

pseudostates ca n ter minate o n a co mmon junction point. Th is allo ws their resp ective


compound transitions to share the path that em anates from that jun ction point. A
G

jun ction point is re presented by a small b lack circle. Alternati vely, it m ay be

*

represented by a di amond shape (see S ection 3.86, “Decisions,” on page 3-150).

Two or m ore guarded transitio ns em anating from the same jun ction point re present a


static branch point. Normally, the guards are mutually exclusive. This is equivalent to


a set of individual tran sitions, one for each path through the tr ee, whose guard

3-140 OMG-UML V1.3 March 2000

 3


condition is th e “an d” of all of the con ditions alo ng the path . Note that the sem antics
of static b ranches is that all th e outgoing guards are evaluated before any transition is
H

taken.

Two or more guarded transitio ns emanating from a common dynamic choic e point are
A

used to model dynamic choices. In this case, the g uards of the o utgoing transitio ns are


evaluated at the time the choice point has been reached. The value of these guards may


be a function of some calculation s performed in th e action s of the incoming

transition(s). A dy namic choice po int is represented by a sm all wh ite circle

(reminiscent o f a sm all state ico n).

3.80.3 Examples
In Figure 3-68 a single junction point is used to merge and split transitions. Regardless


of whether the jun ction point was reac hed from state State0 or from state Sta te1, the


outgoing paths are the sam e for both cases.

If the state machine in this example is in state State1 and b is less than 0 when event


e1 occurs, th e outgoing transitio n will b e taken o nly if on e of the th ree downstream

guards is true. T hus, if a is equal to 6 at that p oint, no transitio n will b e trigg ered.

- -

State0 State1

e2[b < 0] e1[b < 0]

'

'

[a < 0] [a > 7]

[a = 5]

- - -

State2 State3 State4

Figure 3-68 Junction points

J

In the dy namic ch oice point example in Figure 3-69 on page 3-142, the decision on
"

which branch to take is on ly m ade after the tra nsition from State1 is tak en an d th e


choice point is r eached. Note that th e actio n associated with that in coming tran sition


computes a new value for a. This new value can then be used to determine the outgoing
transition to b e taken. The us e of the predef ined co ndition[else] is recommended to

avoid run-time er rors.

OMG-UML V1.3 Factored Transition Paths March 2000 3-141


3

State1
e1[b < 0]/a := f(m)
'

[a < 0] [else]

[a = 5]

- - -

State2 State3 State4

Figure 3-69 Dynamic choice points

K

3.81 Submachine States

3.81.1 Semantics
A submachine state r epresents th e invocation of a state ma chine defined elsewhere. It


is similar to a macro call in the sense that it represents a (graphical) shorthand that
implies embedding of a complex specification within another specification. The


submachine must be c ontained in the sam e context as th e invoking state mac hine.

In the general case, an in voked state mac hine can be e ntered at an y of its sub states or
"

through its def ault (initial) pseudostate. Similarly, it can be e xited from any substate or

as a result o f the invoked state mach ine reac hing its f inal state o r by an “in herited” or
“group” transition that applies to all substates in the submachine.

The non-default en try and exits are specified th rough special stu b states.


3.81.2 Notation
The submachine state is depicted as a normal state with the appropriate “include”


declaration within its in ternal transitio ns co mpartment (see Se ction 3.74, “State,” on
!

page 3-127). The expression following the incl ude reser ved word is the n ame of the
invoked submachine.


Optionally, the submachine state may contain one or more entry stub states and one or
more exit stub states. The notation for these is similar to that used for stub ends of


stubbed transitions, except th at the en ds are labeled. The lab els represent the n ames of
the corresponding su bstates within the in voked su bmachine. A pathname may be used

if the substate is no t defined at the top level of the invoked submachine. Naturally, this
L

name must be a v alid name of a state in the invoked state ma chine.

3-142 OMG-UML V1.3 March 2000

 3
If the s ubmachine is entere d through its d efault pseu dostate or if it is exited as a r esult
"

of the com pletion of the sub machine, it is not necessary to u se the stu b state no tation
for these ca ses. Sim ilarly, a stu b state is n ot requ ired if the exit o ccurs throu gh an


explicit “grou p” transition that em anates f rom the boundary of the su bmachine state


(implying that it app lies to all th e substates of the su bmachine).



Sub machine states in voking the same submachine m ay occur multiple tim es in the


same state diagram with d ifferent en try and exit con figurations and with d ifferent

internal tr ansitions and exit and entry action specifications in each case.

3.81.3 Example
The following diagram shows a fragment from a statechart diagram in which a


submachine (the F ailureSubmachine) is in voked in a p articular w ay. The actu al



submachine is presumably defined el sewhere an d is not shown in this diagram. Note

that the same sub machine could be in voked elsewhere in th e same state chart dia gram

with different entry an d exit con figurations.

Handle Failure

include / FailureSubmachine

error1/ error2/
'

'

sub1 sub1::sub12
E

subEnd
E

error3/
'

fixed1/

Figure 3-70 Submachine State

In the abo ve example, the transition triggered by event “er ror1” will term inate on state
"

“sub1” of the FailureSubmachine state machine. Since the entry point does not contain


a path name, this m eans th at “sub1” is d efined at the top level of that submachine. In


con trast, the tr ansition triggered by “error2” will ter minate on the “sub12” substate o f
the “su b1”substate (as ind icated by the path n ame), while the “e rror3” tr ansition

implies takin g of the default transition of the F ailureSubmachine.

The transition triggered by the event “fixed1” emanates from the “subEnd” substate of
the su bmachine. Fin ally, the transition emanating from the edge o f the submachine

state is tak en as a result o f the completion event generate d when the

FailureSubmachine reaches its f inal state.

OMG-UML V1.3 Submachine States March 2000 3-143


3

3.81.4 Mapping
A submachine state in a statechart diagram maps directly to a SubmachineState in the


metamodel. The name following the “include” reserved action label represents the state
machine indicated by the “submachine” attribute. Stub states map to the Stub State


concept in th e metamodel. T he label on the diag ram corresponds to the p athname

represented by the “referenceState” attribute of the stub state.

3.82 Synch States

3.82.1 Semantics
A synch state is for synchronizing concurrent regions of a state machine. It is used in


conjunction with forks and join s to in sure that o ne region leaves a particular state or


states before another region can enter a particular state or states. Th e firing of outgoing
transitions from a sy nch state can b e limited by specifying a b ound on the dif ference

between the number of tim es outg oing an d in coming trans itions have fired.

3.82.2 Notation
A synch state is s hown as a small cir cle with th e up per bound ins ide it. The bound is


either a p ositive integer or a star ('*') for un limited. Synch states ar e drawn on the


boundary between two regio ns when possible.

3-144 OMG-UML V1.3 March 2000

 3

3.82.3 Example

Build House

Build Put On Install

Frame Roof Walls

Install
Foundation Inspect
* *

Install Install Install

Electricity Electricity Electricity
O

In Foundation In Frame Outside

Figure 3-71 Synch s tates

3.82.4 Mapping
A synch state circle maps into a SynchState, contained by the least common containing


state of the regions it is syn chronizing. The n umber insid e it maps onto th e bound


attribute of the synch state. A star ('* ') inside the syn ch state circle maps to a value of
Unlimited for the bo und attrib ute.
N

Part 10 - Activity Diagrams

3.83 Activity Diagram

3.83.1 Semantics
An activity graph is a variation of a state machine in which the states represent the
!

performance of ac tions or sub activities and th e transitions are trigg ered by the


com pletion of the actions or sub activities. It re presents a state m achine of a p rocedure
itself.

OMG-UML V1.3 Activity Diagram March 2000 3-145


3

3.83.2 Notation
An activity diag ram is a specia l case o f a state d iagram in wh ich a ll (o r at lea st most)


of the states are actio n or subactivity states and in wh ich all (o r at least mo st) of the
transitions are trigg ered by com pletion of the action s or subactivities in the so urce

states. The entire activity diag ram is attach ed (through the model) to a class, such as a
I

use case, o r to a package, or to the implementation of an operation. The purpose of this



diagram is to focu s on flows driven by internal processing (as opposed to e xternal



events). Use acti vity d iagrams in situatio ns wh ere all or m ost o f the events represent
the com pletion of internally-generated actions (that is, proced ural flow of control). Use

ordinary state diag rams in situa tions where asyn chronous events occ ur.

3-146 OMG-UML V1.3 March 2000

 3

3.83.3 Example
Person::Prepare Beverage

Find [no coffee] [no cola]

Beverage

[found coffee] [found cola]

Put Coffee P

in Filter Add Water Q

Get
to Reservoir Cups
R

Put Filter P

in Machine Get cans

S

of cola

Turn on
Machine

/coffeePot.turnOn
U

Brew coffee

light goes out

Pour Coffee

Drink

Figure 3-72 Activity Diagram

OMG-UML V1.3 Activity Diagram March 2000 3-147


3

3.83.4 Mapping
An activity d iagram maps in to an ActivityGraph.


3.84 Action State

3.84.1 Semantics
An action s tate is shorthand for a state with an entry action and at least one outgoing


transition involving th e implicit e vent of com pleting th e entry action (there may be

several such transitions if the y have guard con ditions). Ac tion states s hould n ot have

internal tr ansitions or outgoing transitions b ased o n explicit e vents, use n ormal states
for this situatio n. The normal use of an action state is to m odel a step in the execution


of an algorithm (a procedure) or a workflow process.

3.84.2 Notation
An actio n state is sho wn as a shape with straig ht top and bottom and with convex arcs


on the tw o sides. The action-expression is placed in the symbol. The action expression


need not be unique within the diagram.

Transitions leaving an action state should not include an event signature. Such
transitions are im plicitly triggered by the completion of the action in the state. T he

transitions may inclu de gu ard con ditions and actions .

3.84.3 Presentation options

The action may be described by natural language, pseudocode, or programming
V

language code. It may use only attributes and link s of the owning object.

Note that action state no tation may be used within o rdinary state d iagrams; however,


they are more commonly used with activity diagrams, which are spe cial ca ses of state

diagrams.

3.84.4 Example

matrix.invert (tolerance:Real) drive to work

Figure 3-73 Action States

3-148 OMG-UML V1.3 March 2000

 3

3.84.5 Mapping
An action state sym bol maps into an Action State with the action-expression mapped to


the entry actio n of the State. T here is no exit nor any internal transitions. The State i s


normally anonymous.

3.85 Subactivity State

3.85.1 Semantics
A subactivity sta te invokes an activity graph. When a subactivity state is entered, the


activity graph “nested” in it is executed as an y activity graph would be. The subactivity


state is no t exited until the f inal state of the n ested graph is re ached, or when trigg er


events occur on transitions com ing out of the su bactivity state . Sin ce states in activity
graph s do not normally have trigger events, subactivity states are no rmally exited when
their n ested graph is f inished. A sing le acti vity graph may be invoked by many

subactivity states.

3.85.2 Notation
A subactivity state is sh own in th e same way as an action state with the add ition of an


icon in the lower right corner depicting a nested activity diagram. The name of the


subactivity is p laced in th e symbol. The subactivity need n ot be unique with in th e



diagram.

This notation is a pplicable to any UML construct that sup ports “nested” str ucture. The


icon must suggest the type of nested structure.

3.85.3 Example

Build Product Fill Order

Figure 3-74 Subactivity States

3.85.4 Mapping
A subactivity state symbol maps into a SubactivityState. The name of the subactivity
maps to a submachine link between the SubactivityState and a StateMachine of that
L

name. The SubactivityState is normally anonymous.

OMG-UML V1.3 Subactivity State March 2000 3-149


3

3.86 Decisions

3.86.1 Semantics
A state diagram (and by derivation an activity diagram) expresses a decision when
guard conditions are used to ind icate different po ssible transitions that d epend on
Boolean co nditions of the o wning o bject. UML provides a sh orthand for sho wing


decisions an d merging their separa te p aths back tog ether.

3.86.2 Notation
A decision may be sh own by labelin g multiple output transitio ns of an action with


different gu ard conditions.

The icon provided for a decision is the traditional diamond shape, with one incoming


arrow and with tw o or m ore outgoing arrows, ea ch labeled b y a distinct guard



condition with n o event trigg er. All pos sible o utcomes sh ould ap pear on one of the


outgoing transitions. A predefined g uard den oted “else” m ay be d efined for at m ost


one ou tgoing transitio n. This trans ition is enabled if all the g uards labelin g th e other
transitions are false.

The same icon can be used to merge decision branches back together, in which case it


is called a merge. A merge has two or more incoming arrows and one outgoing arrow.

Note that a chain of decision s may be part of a com plex transitio n, but only th e first


segment in s uch a chain may contain an event trigger la bel. All se gments m ay have
guard expressions. The transition coming from a merge may not have a trigger label or
guard expressions.

3.86.3 Example

[cost < $50] Charge

Calculate Y

customer’s
total cost Z

account
[cost ≥ $50]
[

Get
authorization

Figure 3-75 Decision and merge

3-150 OMG-UML V1.3 March 2000

 3

3.86.4 Mapping
A decision symbol maps into a Pseudostate of kind junction. Each label on an outgoing

]

arrow maps into a Guard o n the co rresponding Transition leaving th e Pseud ostate. A
merge symbol also maps into a Pseudostate of kind junction.
\

3.87 Swimlanes

3.87.1 Semantics
Actions and subactivities may be organized into swimlanes. Swim lanes are used to


organize re sponsibility for actions and subactivities acco rding to class. They often


correspond to organization al un its in a b usiness model.

3.87.2 Notation
An activity diagram may be divided visually into “swimlanes,” each separated from
L

neighboring swimlanes by vertical solid lines on both sides. Eac h swimlane represents
responsibility for par t of the overall activity, and may eventually be im plemented by


one or m ore objects. T he relative ordering of the swimlanes has no sem antic


sig nificance, but might indicate some affinity. Each action is assigned to one swimlane.
Transitions may cross lanes. There is no significance to the routing of a transition path.

OMG-UML V1.3 Swimlanes March 2000 3-151


3

3.87.3 Example

Customer _

Sales _

Stockroom

Request service

Take order

Pay

Fill order

Deliver order

Collect order

Figure 3-76 Swimlanes in Activity Diagram

&

3.87.4 Mapping
A swimlane maps into a Partition of th e States in the ActivityGraph. A state s ymbol in


a swim lane causes the corre sponding S tate to belon g to the corre sponding Partition.

3-152 OMG-UML V1.3 March 2000

 3

3.88 Action-Object Flow Relationships

3.88.1 Semantics
Actions operate by and on objects. These objects either have primary responsibility for

initiating an action , or are used or deter mined by the action. Actions usu ally sp ecify


calls sent between the object owning the activity graph, which initiates action s, and the


objects that are the targets of the actions.

3.88.2 Notation

3.88.2.1 Object responsible for an action

In sequence diagrams, the o bject resp onsible f or performing an ac tion is sh own by
"

drawing a life line and placing action s on lifelines. See Sectio n 3.58, “Seq uence
Diagram,” on page 3-94. Activity diagrams do not show the lifeline, but each action


specifies wh ich object performs its operation. These objects may also be related to the


swim lane in s ome way. The actions within a s wimlane can all be handled by the s ame


object or by multiple o bjects.

3.88.2.2 Object flow



Objects that ar e input to or output from an actio n may be sho wn as object symbols. A


dashed arrow is dr awn from an ac tion state to a n output object, an d a dashed ar row is


drawn from an input object to an actio n state. The same object may be (and usually is)
the output of one action and the input of one or more subsequent actions.

The control flow (solid) arrows must be omitted when the object flow (dashed) arrows


supply a r edundant con straint. In other words, when a state p roduces an output that is

input to a subsequent state, that ob ject flow rela tionship im plies a control con straint.

3.88.2.3 Object in state

Frequently the same object is manipulated by a number of successive actions or


subactivities. It is p ossible to s how one ob ject with arrows to and from all o f the
*

relevant action s and sub activities, but fo r greate r clarity, the object m ay be d isplayed
multiple tim es on a diagram. Ea ch app earance deno tes a different po int d uring the


object’s life. To distinguish the various appearances of the same ob ject, the state of the


object at each point may be placed in brackets and appended to the name of the object
(for example, PurchaseOrder[approved]). This notation may also b e used in


collaboration and seq uence diagrams.

OMG-UML V1.3 Action-Object Flow Relationships March 2000 3-153


3

3.88.3 Example

Customer _

Sales _

Stockroom

Request service

Order
[placed]
Take order


Order
[entered]
Pay
a

Order Fill order

[filled]

Deliver order
b

Order
[delivered]

Collect order
/

Figure 3-77 Actions and O bject Flow

&

3.88.4 Mapping
An object f low symbol maps in to an Obje ctFlowState who se inc oming and outgoing


Transitions correspond to the incoming and outgoing arrows. The Transitions have no


attachments. Th e class name and (optional) state name of the object flow symbol map

into a C lass or a C lassifierInState corresponding to the name (s). Solid and dashed


arrows b oth map to transitions.

3-154 OMG-UML V1.3 March 2000

 3

3.89 Control Icons

The following icons provide explicit symbols for certain kinds of information that can


be specified o n transitio ns. These ico ns are not necessary for constructin g activity


diagrams, but many users p refer th e added impact th at th ey provide.

3.89.1 Notation

3.89.1.1 Signal receipt

The receipt of a signal may be shown as a concave pentagon that looks like a rectangle


with a triangular notch in its sid e (either side). The signature of the sign al is sho wn

ins ide the sy mbol. An u nlabeled transition arrow is dra wn from the previous action


state to th e pentagon and ano ther un labeled tra nsition arrow is d rawn from the
!

pentagon to the next action state. A dashed arrow may be drawn from an object symbol
to the notch on the pen tagon to s how the sender of the sig nal; th is is op tional.

3.89.1.2 Signal sending

The sending of a signal may be shown as a convex pentagon that looks like a rectangle


with a triangular point on one s ide (either sid e). The sign ature of the sig nal is sh own
inside the symbol. A unlabeled transition arrow is drawn from the previous action state
to the pentag on and an other un labeled transitio n arrow is d rawn from the pen tagon to

the next action state. A dashed arrow may be drawn from the point on the pentagon to

an object sym bol to s how the receiver of the sig nal, this is o ptional.

OMG-UML V1.3 Control Icons March 2000 3-155


3

d
Turn on
Machine

turnOn

coffeePot


Brew coffee

light goes out

Pour Coffee

Figure 3-78 Symbols for Si gnal Recei pt and Sending

&

3.89.1.3 Deferred events

A frequent situation is when an event that occurs must be “deferred” for later use while


some oth er action or su bactivity is u nderway. (Norm ally an event that is n ot handled
immediately is lost.) This may be thought of as having an internal transition that
handles the event and places it on an internal queue until it is needed or until it is


discarded. Each state specifies a set of events th at are deferred if they occur during the


state and are no t used to trigger a tr ansition. If an event is not includ ed in the set of


defe rrable events for a state, and it d oes n ot trigg er a tra nsition, then it is discar ded


from the queue even if it has already occurr ed. If a transition depends on an event, the
transition fires im mediately if the event is already on th e internal qu eue. I f several

transitions are possible, the lea ding event in th e queue takes prece dence.

A defe rrable event is shown by listing it within th e state f ollowed by a slash and the
special op eration defer. If the event occurs, it is sa ved and it recurs wh en th e object
A "

transitions to another state, where it may be deferred again. When the o bject rea ches a

state in which the event is not deferred, it must be accepted or lost. The indication may


be placed on a composite state o r its equivalents, submachine and subactivity state s, in



which case it remains deferrable throughout the com posite state. A contained transitio n
may still be trigg ered by a deferrable event, whereup on it is removed from the queue.

3-156 OMG-UML V1.3 March 2000

 3
It is not necessary to defer events on actio n states, b ecause the se states are n ot
"

interruptible for event processing. In this case, both deferred and undeferred events that


occur during the state are deferred until the state is com pleted. This means th at the
tim ing of the transition will be the sam e regardless of the re lative order of the e vent

and the state c ompletion, and regardless of wheth er events are d eferred.

Turn on
Machine

turnOn

Brew coffee
light goes out / defer

f
Get Cups
light goes out / defer

light goes out

Pour Coffee

Figure 3-79 Deferred Event

&

3.89.2 Mapping
A signal receipt symb ol maps into a state with n o actions or inter nal tran sitions. Its


specified event m aps to a trigg er event o n the o utgoing transition between it an d th e

following state.

A signal send symbol maps into a SendAction on the incoming transition between it


and the previous state.

A d eferred event a ttached to a state ma ps into a deferredEvent association from the


A

State to the Event.

OMG-UML V1.3 Control Icons March 2000 3-157


3

3.90 Synch States

The SynchState notation may be omitted in Activity Diagrams when a SynchState has


one incoming and one outgoing transition, and an un limited bound. The sem antics and


mapping are the sam e as if th e syn ch state circ les were in cluded, as d efined for state
machine notation.

Build House
h

Build Put On Install

Frame Roof Walls

Install i

Inspect
Foundation

Install Install Install

Electricity Electricity Electricity
In Foundation In Frame Outside

Figure 3-80 Synchronizing parallel activities

&

3.91 Dynamic Invocation

3.91.1 Semantics
The actions of an action state or the activity graph of a subactivity state may be


executed m ore than once concurrently. The number of concurrent invocations is



determined at r untime b y a co ncurrency expression, whi ch evaluates to a set o f



argument lis ts, one argument list for e ach invocation.

3.91.2 Notation
If the dynamic concurrency of an actio n or subactivity state is not always exactly one,
"

its multiplicity is shown in the upper right corner of the state. Otherwise, nothing is


shown.

3-158 OMG-UML V1.3 March 2000

 3

3.91.3 Mapping
A multiplicity string in the up per right corner of an action or subactivity state m aps to


the sam e value in th e dyn amicMultiplicity attrib ute of the state. The p resence of a

multiplicity string also maps to a value of true for the isDynamic attribute of the state.
If no multiplicity is present, the v alue of the isDyn amic attr ibute is false.
"

3.92 Conditional Forks

In Activity Diagrams, transitions outgoing from forks may have guards. This means the
*

region initiated by a fork tra nsition might no t star t, and therefore is no t required to


com plete at the corresponding join. The usual notation and mapping for guards may be
I

used on the tra nsition outgoing from a f ork.

Part 11 - Implementation Diagrams

Implementation diagrams show aspects of implementation, including source code


structure and run-time imp lementation str ucture. They come in two forms:

1. component diag rams show the str ucture of the co de its elf and

2. deployment diagrams show the str ucture of the run-time system.

They can also be applied in a broader sense to business modeling in which the “code”


components are the business procedures and documents and the “run-time stru cture” is
the organization units and res ources (human and other) of the business.

3.93 Component Diagram

3.93.1 Semantics
A component diagram shows the dependencies among software components, including


source code co mponents, binary code components, and executable c omponents. F or a



business, “software” co mponents are taken in th e broad sen se to in clude business

!

procedures and documents. A s oftware module may be represented as a co mponent



stereotype. Some components exist at com pile time, some exist at link time, some exist


at run time, and som e exist at mo re than one time . A co mpile-only component is o ne
that is only meaningful at compile time. The run-time component in this c ase would be

an executable program.

A component diagram has only a type form, not an instance form. To show component

instances, use a deployment diagram (possibly a degenerate one without nod es).

3.93.2 Notation
A component diagram is a graph of components connected by dependency
relationships. Components may also be connected to components by physical


containment representing co mposition relation ships.

OMG-UML V1.3 Conditional Forks March 2000 3-159