Object-Oriented

Analysis and
Design
5 DYNAMIC
MODELING

Source: OBJECT-ORIENTED
MODELING A N D DESIGN
James Rumbaugh, Michael
Blaha,
William Premerlani, Frederick
Eddy,
William Lorensen
✘Temporal relationship are difficult to understand. A system can best be
understood by first examining its static structure, that is, the structure of its objects
and their relationships to each other at a single moment in time. Then we examine
changes to the objects and their relationships over time. Those aspects of a system
that are concerned with time and changes are the dynamic model.

✘Control is that aspect of a system that describes the sequences of operations that
occur in response to external stimuli.

✘The major dynamic modeling concepts are events, which represent external
stimuli, and states, which represent values of objects.

✘The state diagram is a standard computer science concept (a graphical

representation of finite state machines).
 1. EVENTS A N D STATES
The attribute values and links held by an object are called its state.

An individual stimulus from one object to another is an event.

The pattern of events, states, and state transitions for a given class can be
abstracted and represented as a state diagram. A state diagram is a network of
states and events, just as an object diagram is a network of classes and
relationships. The dynamic model consists of multiple state diagrams.

Events

An event is something that happens at a point in time, with no duration.

Two events that are causally unrelated are said to be concurrent; they have no effect
on each other.

In modeling a system we do not try to establish an ordering between concurrent

events because they can occur in any order.

An event is a one-way transmission of information from one object to another.

Every event is a unique occurrence, but we group them into event classes and give
each event class a name to indicate common structure and behavior.

The time at which an event occurs is an implicit attribute of all events.

An event conveys information from one object to another. The data values conveyed
by an event are its attributes.

airplane flight departs (airline, flight number, city)

mouse button pushed (button, location)
input string entered (text)
phone receiver lifted
digit dialed (digit)
engine speed enters
danger zone
Event classes
and
attributes
Events include error conditions as well as normal
occurrences. There is nothing different about an error
event; only our interpretation makes it an "error".
 Scenarios and Event Traces

caller lifts receiver

A scenario is a sequence dial tone begins
of events that occurs caller dials digit (5)
during one particular dial tone ends
execution of a system. It caller dials digit (5)
may include all events in caller dials digit
the system, or it may (5) caller dials
include only those events digit (1) caller
impinging on or dials digit (5)
generated by certain caller dials digit (2)
objects in the system. caller dials digit
(3) caller dials
digit (4)
called phone
begins ringing
ringing tone appears in calling phone
Scenario called party answers
for phone called phone stops ringing
call
ringing tone disappears in calling phone
phones are connected
called party hangs up
phones are disconnected
 Caller Phone Callee
The next step after line caller lifts receiver
writing a scenario is to
identify the sender and dial tone begins
receiver objects of each dials (5)
event. The sequence dial tone ends parameter
of events and the
dials (5)
objects exchanging
events can both be dials (5)
shown in an dials (1)
augmented scenario
dials (2)
called an event trace
dials (3) two
diagram. concurrent
TIME
dials (4) events
ringing tone phon
e
answers phone
rings
Event tone stops ringing stops
trace for phones connected phones connected
phone call
callee hangs up
object connection broken connection broken
caller hangs up

event
 States
✘ A state is an abstraction of the attribute values and links of an object.
✘The response of an object to an event may include an action or a
change of state by the object.
✘A state corresponds to the interval between two events reveived by an
object. Events represent points in time; states represent intervals of time.
✘ A state has duration; it occupies an interval of time.
✘A state is often associated with the value of an object satisfying some
condition.
✘ In the simplest case, each enumerated value of an attribute defines a
separate state.
State: Alarm ringing
Description: alarm on watch is ringing to indicate target time
Event sequence that produces the state:
set alarm (target time)
any sequence not including clear alarm
current time = target time
Various Condition that characterizes the state:
characterizations
alarm = on, and target time ≤ current time ≤ target time + 20 seconds,
of a state
and no button has not been pushed since target time
Events accepted in the state:
event action next state
current time = target time + 20 reset alarm normal
button pushed (any button) reset normal
alarm
Can links have state? In as much as they can be considered objects, links can have
state. A s a practical matter, it is generally sufficient to associate state only with
objects. The state of an object can include the values of its links.

State Diagrams

A state diagram relates events and states.

A change of state caused by an event is called transition.

All the transitions leaving a state must correspond to different events.

The state diagram specifies the state sequence caused by an event sequence. If an
object is in a state and an event labeling one of its transitions occurs, the object
enters the state on the target end of the transition. The transition is said to fire.

A sequence of events corresponds to a path through the graph.

 on-hook on-hook
Idle

transition state off-hook

time-out
Dial tone Time-out

-out
digit(n) it me

digit(n) Recorded
Dialing
invalid number message

number valid number

Busy tone bu sy

Connecting
message
Fast usy done
busy tone trunk b routed
event
Ringing
name
called phone answers State
diagram
Connected for phone
line
Continuous
loop called phone hangs up
Disconnected
It is not necessary to distinguish between different numbers as separate states since
they all have the same behavior, but the actual number dialed must of course be
saved as an attribute.

A state diagram describes the behavior of a single class of objects. Since all
instances of a class have the same behavior (by definition), they all share the same
state diagram, as they all share the same class features.

State diagrams can represent ont-shot life cycles or continuous loops.

One-shot diagrams represent objects with finite lives. A one-shot diagram has
initial and final states. The initial state is entered on creation of an object; entering
the final state implies destruction of the object.
 initial state final state
(solid circle) (bull's eye)

White's checkmate
Start Black wins
turn
stale
mate
black white
Draw
e
mat
moves stale
moves
Black's
White wins
turn checkmate

One-shot
state diagram
for chess game
One shot

The dynamic model is a collection of state diagrams that interact with each other
via shared events. An object model represents the static structure of a system, while
dynamic model represents the control structure of a system.

A scenario is to a dynamic model as an instance diagram is to an object model.

 Conditions
A condition is a Boolean function of object values, such as "the temperature is
below freezing". A condition is valid over an interval of time. For example, "the
temperature was below freezing from November 15, 1 9 21 until March 3, 1922". It is
important to distinguish conditions from events, which have no time duration. A
state can be defined in terms of a condition; conversely being in a state is a
condition.

Conditions can be used as guards on transitions. A guarded transition fires when its
events occurs, but only if the guard condition is true.
guarded
condition
state
transition
time-out [cars in N/S left lanes]
North/south North/south
may go straight [no may turn left
c ars time
in N -ou
/S lt transition
e ft la
[no nes time-out
time-out ti ]
s in me-o
car
E /W ut
left State diagram
lan with
East/west es] East/west
may turn left may go straight guarded
transitions
time-out [cars in E/W left lanes]
 2. OPERATIONS
Controlling Operations

Operations attached to states or transitions are performed in response to the

corresponding states or events.

An activity is an operation that takes time to complete. An activity is associated with

a state. Activities include continuous operations. A state may control a continuous
activity. The notation do: A within a state box indicates that activity A starts on entry
to the state and stops on exit. A state may also control a sequential activity.

An action is an instantaneous operation. An action is associated with an event. An

action represents an operation whose duration is insignificant compared to the
resolution of the state diagram.

Actions can also represent internal control operations, such as setting attributes or
generating other events.

right button down / display popup menu Actions for

Menu popup menu
Idle
visible
right button up / erase popup menu

cursor moved / highlight menu item

transition action
Summary of Notation for State Diagrams with Operations

State1 State2
do: activity1 event1 (attribs) [condition1] / action1 ...

Summary of
notation for
unstructured
state diagrams
 on-hook on-hook
Idle

off-hook
on-hook Dial tone time-out Time-out
do: sound dial tone do: sound loop beep
-out
activity digit(n) time
Recorded
digit(n)
Dialing message
on-hook invalid number do: play message

Busy tone number valid number

busy
do: slow busy tone
on-hook Connecting
do: find connection
message
Fast
busy done
busy tone trunk routed
do: fast
busy tone on-hook Ringing
do: ring bell
called phone answers State
/ connect line diagram
on-hook / disconnected line action for phone
Connected
line
called phone hangs up
/ disconnect line
on-hook
Disconnected
 3. NESTED STATE DIAGRAMS
Problems with Flat State Diagrams

Consider an object with n independent Boolean attributes that affect control.

Representing such an object with a single flat state diagram would require 2 n states.
By partitioning the state into n indenpendent state machines, however, only 2n

states are required. n 2 transitions are needed to connect every state to every other
state. If this model can be reformulated using structure, the number of transitions
could be reduced as low as n.

Combinatorial
explosion of
transitions in flat
state diagram
 Nesting State Diagrams

An activity in a state can be expanded as a lower-level state diagram, each state

representing one step of the activity.

The lack of event label indicates that the transition fires automatically when the
activity in the state is complete.

internal
coins in(amount) / set balance action
Collecting money
Idle
coins in(amount) / add to balance
cancel / refund coins
[item select(item) [change < 0]
empty]
Vending do: test item and compute change

machine
model [change < 0] [change > 0]
lamda
transition
do: dispense item do: make change
This activity corresponds to a sequence of lower-level states
and events that are invisible in the original high-level state Dispense
diagram. item activity
of vending
Subdiagram for the machine
dispense item activity

do: move arm arm ready do: move arm to arm ready do: push item off pushed
to correct correct colomn shelf
row

Events can also be expanded into subordinate state diagrams. The label on the
bull's-eye indicates the event generated on the higher-level state diagram

select item event, which

actually involves several
low-level events digit(n)
select(item)
digit(n) select item
enter transition of
do: reset item do: append digit
vending
machine
clear
 State Generalization

✘Generalization is the or-relationship. The states in the nested diagram are all
refinements of the state in the high-level diagram.
✘States may have substates that inherit the transitions of their superstates. Any
transition or action that applies to a state applies to all its substates, unless
overridden by an equivalent transition on the substate.
✘A superstate is drawn as a large rounded box enclosing all of
its substates. Substates in turn can enclose further substates.
✘ Within state Forward, substate First is the default initial State diagram of
state. Forward is just an abstract class state; control car transmission
with
must be in a real state, such as First.
generalization

Transmission push R
Neutral push N Reverse
contour
inherited
by each
gear push N push F
superstate
default
Forward abstract state
substate

stop upshift upshift

First Second Third substate
downshift downshift
 Event Generalization Events can be organized into a
generalization hierarchy with inheritance of
attributes.event
Ultimately every actual event can be viewed as a
leaf on a generalization tree of events. An input event
triggers transitions on any ancestor event type. For
event example, typing an 'a' would trigger a transition on event
time alphanumeric as well as event
keyboard character.
Partial event
user input hierarchy
keyboard
for events Providing an event hierarchy
device
permits different levels of
abstraction to be used at different
places in a model. For example,
mouse keyboard
in some states all input
button character
location character characters might be handled the
same and would lead to the same
next state; in other states control
mouse mouse
characters would be treated
control graphic differently from printing
button
button up characters; still
down others might have
different actions on
space alphanumeric punctuation individual characters.
 4. CONCURRENCY
Aggregation Concurrency

A dynamic model describes a set of concurrent objects, each with its own state and
state diagram. The objects in a system are inhrently concurrent and can change
state independently. In many systems, the number of objects can change
dynamically as well.

A state diagram for an assembly is a collection of state diagrams, one for each
component. Aggregation implies concurrency. The aggregate state corresponds to
the combined states of all the component diagrams. Aggregation is the a n d -
relationship. The aggregate state is one state from the first diagram, and a state
from the second diagram, and a state from each other diagram. In the more
interesting cases, the component states interact. Guarded transitions for one object
can depend on another object being in a given state. This allows interaction between
the state diagrams, while preserving modularity.
 An aggregation
and its
concurrent state
diagrams
Car

Ignition Transmission Brake Accelerator

Ignition
turn key to start
[Transmission in Neutral] release key
Off Starting On

turn key off

Transmission push R
Neutral push N Reverse

push N push F

Forward

stop upshift upshift

First Second Third
downshift downshift

Accelerator Brake

depress accelerator depress brake

Off On Off On
release accelerator release brake
 Concurrency within an Object

Concurrency within the state of a single object arises

when ths object can be partitioned into subsets of
attributes or links, each of which has its own
subdiagram. The state of the object comprises one Bridge game
state from each subdiagram. The subdiagrams need with concurrent
not be independent; the same event can cause states
transitions in more than one subdiagram.

name of the overall

composite state

Playing rubber
default
state N-S vulnerability
Not N-S game N-S game N-S wins
Vulnerable
vulnerable rubber
concurrent
subdiagrams
E-W vulnerability
Not E-W game E-W game E-W wins
Vulnerable
vulnerable rubber
default
state
 5. ADVANCED DYNAMIC MODELING CONCEPTS
Entry and Exit Actions

A s an alternative to showing actions on transitions, actions can be associated with

entering or exiting a state.

depress / motor up Opening

door open / motor off

Closed depress / motor up Open

door closed / motor off depress / motor down

Closing

Actions
on
transitions
Whenever the state is entered, by any incoming transition, the entry action is
performed. An entry action is equivalent to attaching the action to every incoming
transition. If an incoming transition already has an action, its action is performed
first.

Whenever the state is exited, by any outgoing transition, the exit action is
performed first.

If multiple operations are specified on a state, they are performed in the following
order: actions on the incoming transition, entry actions, do activities, exit actions,
actions on the outgoing transition. D o activities can be interrupted by events that
cause transitions out of the state, but entry actions and exit actions are completed
regardless, since thay are considered to be instantaneous actions. If a do activity is
interrupted, the exit action is nevertheless performed.

Same model using Opening

actions on entry states depress entry / motor up door open

Closed Open
depress
Actions entry / motor off entry / motor off
on entry
to door closed Closing depress
states entry / motor down

It is possible to use actions attached to transitions as well as entry and exit actions
in a diagram.
 Internal Actions

An event can cause an action to be performed without causing a state change.

Keywords entry, exit, and do are reserved words within the state box. When such an
event occurs, its action is executed but not the entry or exit actions for the state.
There is therefore a difference between an internal action and a self-transition; the
self-transition causes the exit and entry actions for the state to be executed.

State1
do: activity1 event1 (attribs1) [condition1] / action1 State2
entry / action2
...
exit / action3
event / action4 event2 (attribs2)

Object class

Summary of
extended
notation for
state diagrams
 Automatic Transition

An arrow without an event name indicates an automatic transition that fires when
the activity associated with the source state is completed. If there is no activity, the
unlabeled transition fires as soon as the state is entered (but the entry and exit
actions are always performed). Such unlabeled transitions are sometimes called
lambda transitions.

If a state has one or more automatic transitions, but none of the guard conditions
are satisfied, then the state remains active until one of the conditions is satisfied or
until an event causes another transition to fire.

Sending Events

The dotted line from a transition to an object indicates that an event is sent to the
object when the transition fires.

If a state can accept events from more than one object, the order in which
concurrent events are received may affect the final state; this is called a race
condition.
 Synchronization of Concurrent Activities

Sometimes one object must perform two (or more) activities concurrently. The
internal steps of the activities are not synchronized, but both activities must be
completed before the object can progress to its next state.

This is an example of splitting control into concurrent activities and later merging
control.
activitiy composite
(assumes one state from each subdiagram)

Emetting
concurrent
activities cash taken
do: dispense cach

Setting ready Ready

up to reset
do: eject card card taken
subdiagram
Synchronization
of control
Splitting of control into concurrent parts is shown by an arrow that forks. The forked
arrow selects one state from each concurrent subdiagram. In the example, the
transition on event ready splits into two concurrent parts, one to each concurrent
subdiagram. When this transition fires, two concurrent substates become active and
execute independently. Each concurrent substate could be a whole state diagram.

Merging of concurrent control is shown by an arrow with a forked tail. The target
state becomes active when both events occur in any order. The events need not be
simultaneous. Each subdiagram terminates as soon as its part of the transition fires,
but all parts of the transition must fire before the entire transition fires and the
composite state is terminated.

The exit actions (if any) of all subdiagram are performed when the merge transition
fires. In the example, the transitions cash taken and card taken are part of a single
merge transition. When both parts of the merge transition fire, state Ready to
reset becomes active.