State Machine

Diagram

Week 14

Lecture Outline
State machine Diagrams
State machine syntax/Notation
State
Event
Transition
Initial/Final State

Learning Objective

To determine states from problem

statement
To understand UML notations for state
machine diagram
To elaborate and identify elements in
state machine diagram
To draw state machine diagram

State machine Diagram

State machine diagram or behavioral state machine is a

dynamic model that shows the different states that a
single object passes through during its life in
response to events, along with its responses and
actions. (Dennis, 2005)
A diagram that captures the behavior of an object by
specifying the sequence of states it goes through during
its lifetime in response to events, together with the
responses to those events (Hoffer, 2004)
State machine diagram is used to represent a single
object and how its behavior causes it to change
state.
State machine diagram describes the dynamic
behavior of objects over time by modeling the
lifecycles of objects of each class. (The UML Ref
Manual, 1999)

When to use State machine

Diagram?

State machine diagram need to be drawn only for

objects that exhibit a number of states or dynamic
objects.
The diagram is not used for all objects, but just to
further define complex objects to help simplify the
design of algo for their methods. (Dennis, 2005).The
more CRUD process an object has, it is possibly a
candidate for state machine diagram.
Fowler and Scott(1997) recommended using state
machines for:
1. Describing the behavior of an object across several
use cases
2. Describing behavior that involves in an object, not
for collaboration of objects

State machine Diagram (SCD)

vs Interaction Diagram
SCD

should be used if you are interested in

understanding the dynamic aspects of a single
class and how it evolves over time.
Interaction diagram should be used if you are
interested in understanding how a particular use case
scenario is executed over a set of classes.

Example: State Machine

Diagram of Patient
Admission

Example: State machine

Diagram of a Stack
pushl[ not full ]

create stack
push

Empty

pop/error

Loaded

pop[ empty ]
pop
pop[ not empty ]

push[full ]

Full

push / error

State machine Diagram

Syntax
A STATE

aState

AN INITIAL STATE
A FINAL STATE

AN EVENT
A TRANSITION

anEvent

Elements in State machine

1. States
2. Events
3. Transitions

States

State a stable condition during the lifetime of the object, where

it is:

Continuously performing activity,

Waiting on an event, or

Complying with some condition.

The state of an object is defined by the value of its attributes
and its relationships with other objects at a particular point in
time.

Eg: Patient new, current, former.

However, some attributes might not affect states of an object. Eg:
patient address. (Dennis, p.250)
All objects in a given state execute the same action when they
receive the same event
Objects in different states, may react differently to the same
event, by performing different actions.
Eg: ATM machine reacts to cancel button differently when it is
processing a transaction compared when it is idle.

States> Notation

State name

State represented by rectangle with

rounded corners

States> Eg :
after(5 seconds)

Idle

do action()

Active

Simple states for ATMScreen

ATMScreen object may be idle if it is inactive

or no transaction in 5 seconds. The screen
will be active if there is any transaction done.

States
State has several parts:
1.
Name
Textual string that distinguishes the state from other states
2.
Entry/exit actions
Actions when entering and leaving the state
Syntax: entry/action, exit/action
3.
Internal transitions
When events are processed internally, without leaving a state.
The entry/exit actions are not executed.
Syntax: event/action,
4.
Activity
When in a state, an object is not necessarily idle it may be
continuously performing some operation.
Syntax: do/activity,
5.
Substates
Nested state/composite states (sequential/concurrent
substates)

States
State has several parts:
Internal
transition
compartment

Name
compartment
State Name

entry / action
expression
exit/ action expression
do / activity
include / submachine

A state may include

a sub-statemachine

Initial/Final States
final state

Initial state

after(5 seconds)

Idle

do action()

Active

Simple states for ATMScreen

Initial state

1.

Indicates the initial starting state for the

state machine or a substate.

Final state

2.

Indicates the state machines has

completed.

Events

External stimuli, such as signal, calls to operations by external

bodies or the passing of time, change in a condition and creation
and deletion.
Events represent the kind of changes that an object can detect.
Is a triggers that cause an object move from one state to the next
state.
Something that happens and that may cause some actions.
Anything that can affect an object can be characterized as an event.
Usually indicated directly on the path of a transition from a state to
another state.
Events may be internal or external
1.
External events : those that pass between system and its actor.
Eg : pushing a button
2.
Internal events: those that pass among the objects that live inside
the system. Eg: overflow message

Types of Event
No
.
1.

Description of Events
A change event occurs when some condition is
satisfied (a Boolean condition becomes true).
Change event vs Guard Condition (GC)

2.

Syntax
When
(exp)

GC is evaluated once when the trigger event on the

transition occurs and the receiver handles the event.
If it is false, the transition does not fire and the
condition is not reevaluated
Change event is evaluated continuously until it
becomes true, then the transition fires

An time event is caused by the passage of a

designated period of time after a specified event
(frequently the entry to the current state)

after
(time)

Example : Change & Time

events
change event

When(11:50pm)/selfTest()

Time event

after(5 seconds)
/displayMain()

Idle

do action()

Active

Types of Event
No.
3.

Description of Events

Syntax

A call event occurs when an object receives a call to

one of its operations either from another object or from
itself (synchronous).
After execution, returns to the calling object.
The receiver of a call event may continue its own
execution in parallel with the caller.
call event

Idle

op(a:T)

parameter

pressButton(withdraw)

Active

Types of Event
No.
4.

Description of Events

Syntax

A signal event occurs when an object receives a

signal (an asynchronous communication).The
sending object does not wait for the receiver to deal
with the signal but continues with its own
independently.The sender can the receiver can be
the same object.

sname
(a:T)

Wait for
Fax

incoming call

Receive
Fax

Transition

A transition is a change of an object from one state (the

source state) to another (the target state).
A transition is triggered when an event of interest of the given
object occurs.
Transition is a relationship that represent the movement of
an object from one state to another state. (Dennis, 2005)
To show flow from one state to another.
Alternatively, a transition may be executed unconditionally
when the activity associated with the source state is complete
(triggerless transition) .
Transition is modeled by open arrow from one state to
another.
It is a relationship between 2 states indicating that:
1. an object in the first state will perform certain actions and
2. enter second state when a specified event occurs and
3. specified conditions are satisfied.

Transition
There may be an action associated with a triggered

transition. This action executes before the object

enters the target state.
A self-transition is a transition whose source state
and target state are the same.
Note that entry and exit actions are executed at a selftransition.

Transition
Transition has 5 parts:
1.
Source state

Current state, in which the transition originated.

The object receives a trigger event in this state.

2.
Event trigger

Eligible to fire a transition

3.
Guard Condition

Boolean expression that is evaluated when the transition

triggers.Truefire

Notation of event with guard:

eventName[guard condition]

eventName[guard condition]/action

[guard condition]
4.
Action

Piece of functionality to be executed during transition (operation

contained within object).

Atomic computation (non decomposable process that cannot be

interrupted) done by object [Activity is non-atomic]
5.
Target state

State that is active after completion of the transition

Transition
after(2 secs)/send o.isAlive

Idle

noise

Searching

targetAt(p)
[isThreat]/t.a
ddTarget(p)

Engaging
contact

Tracking

Transition
Send signal

Time event

Initial state after(2 secs)/send o.isAlive

Self transition

Idle

noise

Event trigger

Triggerless
transition

Searching

Engaging

GC

targetAt(p)
[isThreat]/t.a
ddTarget(p)

action

final state

contact

Tracking

Preparing State machines

Set the context

Identify the initial final, and stable states of
the object
Determine the order in which the object will
pass through stable states
Identify the events, actions, and guard
conditions associated with the transitions
Validate the statemachine diagram

Example: Digital Watch

inc/hours : >= hours + 1

Display
Do/display
current time

mode_button

Set hours
Do/display
hours

mode_button

inc/minutes : >= minutes + 1

mode_button

Set minutes
Do/display
minutes

Example: CourseOffering
(CO)
Initially, a CO must be initialized with a lecturer assigned

to the CO.
A CO object may be open(able to add student) or closed
(when achieve maximum number of students already
assigned to the CO object). Assume that the max no. of
students that can be assigned to a CO is 10 students.
Whenever there are students register to a CO, ask
CourseRegister object(external object) to create the CO
into the list.
The CO object must count the no. of student added to the
CO.
A CO may also be cancelled at any time during the
semester.

Initialization

State machine
diagram for
CourseOffering
object.

add student / set count = 0 ^CourseResgiter.create

add student[ count<10 ]
Open

cancel

Canceled

[ count = 10 ]

cancel

Closed

Exercise 1
Create a state machine diagram to show the state

transitions of a class called Article as it moves

through the publishing process. When an authors
submits an article to be published, the article is
categorized as new submission. The article is
categorized as being evaluated when a referee is
assigned to that article. If the article is suitable for
publication, it becomes accepted article, but if the
article is not suitable for publication, it becomes
rejected article.

Clue
Create a state machine diagram to show the state

transitions of a class called Article as it moves through

the publishing process. When an authors submits an
article to be published, the article is categorized as new
submission. The article is categorized as being
evaluated when a referee is assigned to that article. If
the article is suitable for publication, it becomes
accepted article, but if the article is not suitable for
publication, it becomes rejected article.

Exercise 2
Develop a State machine for the following specification of a CD

player.
The CD Player contains a CD drawer with three functional
buttons: Load, Play and Stop.
Load Button shall open the CD drawer if currently the CD
drawer is closed and vice versa.
Stop Button will stop the CD player being played. If this
button is pressed without any CD being played, it shouldnt
give any response.
Play Button will play the CD. If this button is being pressed
with the drawer is still open, the drawer shall close it first
before playing the CD.
Additional information:
The user can press the Off button at anytime to stop the
operation.
It is assumed that the CD drawer is closed in the initial state.

Answer #1
Start

author submits an article( articleNo )

New
submission

ass ign referee( articleNo, refereeNo )

being
evaluated

When[ s uitable = Yes ]

When[ suitable = No ]

accepted

rejected

End

Answer #2
Start
When[ button=On ]
When[ button=stop ]

When[ button=stop ]
When[ button=load ]

Closed

When[ button=load ]

When[ button=play ]

When[ button=stop ]

Open

When[ button=play ] / close drawer

Playing

When[ button=Off ]

When[ button=Off ]
When[ button=Off ]

End