SE3102

Software Design &

Architecture
Lecture: 5
Finite State Machines & Statecharts
And Dynamic Modelling
Overview

Steps in Using COMET/UML:

1 Develop Software Requirements Model

2 Develop Software Analysis Model

– Develop static model of problem domain (Chapter 7)

– Structure system into objects (Chapter 8)

– Develop statecharts for state dependent objects (Chapter 10)

– Develop Dynamic Interaction Modelling (Chapter 9, 11)

3 Develop Software Design Model

Finite State Machines &
Statecharts
Finite State Machines and Statecharts

• In the UMLnotation, a state transition diagram is referred to as a state machine diagram.

• The UML state machine diagram notation is based on Harel’s statechart notation (Harel 1988;
Harel and Politi 1998).
• The terms statechart and state machine diagram are used interchangeably.
• We refer to a traditional state transition diagram, which is not hierarchical, as a flat statechart
• The term hierarchical statechart to refer to the concept of hierarchical state decomposition.
• A finite state machine (also referred to as state machine) is a conceptual machine with a finite
number of states.
• The state machine can be in only one state at any one time. A state transition is a change in state
that is caused by an input event.
Finite State Machines and Statecharts

• Many information and real-time systems are state - dependent

– Action depends not only on input event
– Also depends on state of system
• Finite State Machine
– Finite number of states
– Only in one state at a time
• Statechart
– Graphical representation of finite state machine
– States are rounded boxes
– Transitions are arcs
• Statechart relates events and states
UML notation for statechart: composite state with sequential
substates
States and Events

• State
– A recognizable situation
– Exists over an interval of time
– Represents an interval between successive events

• Event
– A discrete signal that happens at a point in time
– Also known as a stimulus
– Has no duration
– Causes change of state

• Referred to as state transition

Example of Events and States
Events and Conditions

• State transition label – Event [Condition]

• Condition is a Boolean function

– Conditions are optional on statecharts

– Condition is true for finite period of time

• When event occurs, condition must be true for state transition to occur.

• If condition is false, state transition does not occur

Example of Events and Conditions
Actions

• State transition label

– Event / action(s)
– Event [condition] / action(s)

• Action

– Executed as a result of state transition

– Executes instantaneously at state transition – Terminates itself
– Is optional
Example of actions
Entry and Exit Actions

• Entry action
– Action executed on entry into state
• Entry / action
– E.g., Start Cooking
• Exit action
– Action executed on exit from state

• Exit / action
– E.g, Stop Cooking
Example of entry action
Example of exit action
Hierarchical Statecharts

• Disadvantages of State Transition Diagrams and Flat Statecharts

– Complex State Transition Diagrams get very cluttered
– Limited capability for managing complexity

• Hierarchical Statecharts
– Based on Harel Statecharts
– Notation for hierarchical decomposition of state transition diagrams

• Composite state decomposed into substates

• Default entry states

• Transition out of composite state corresponds to transition out of every substate

Example of hierarchical statechart showing composite state
and substates
Hierarchical Statecharts

•Sequential decomposition
– When object is in composite state

• It is in one and only one of substates

– Transition into composite state

• Valid PIN / Display Menu

• Waiting for Customer Choice

• Must be to one and only one of substates Aggregation of state transitions

– If same event causes transition out of every substate
– Then aggregate into transition out of composite state
Example of hierarchical statechart showing composite state
without substates
Aggregation of State Transitions in Statecharts

The customer to press the Cancel button on the

ATM machine in any of the three states:
• Waiting for PIN

• Validating PIN

• Waiting for Customer Choice.

• The Cancel event transitions the ATM to Ejecting state.

• This is depicted by a Cancel arc leaving each of these

states and entering the Ejecting state.
Guidelines on Statecharts

• State name must be passive not active

– Represents time period when something
- ishappenING, e.g., WaitingforPIN (a gerund form)
• Identifiable situation, e.g. Idle, Initial
• State names must be unique
• Must be able to exit from every state
• Flat statechart
– Statechart is only in one state at a time
• Hierarchical statechart
– sequential decomposition
• Statechart is only in one substate at a time
Guidelines on Statecharts

• Event is the cause of the state transition

– Event happens at a moment in time

– Event name indicates something has just happened

e.g. Card Inserted, Door Closed

• Action is the result of the state transition

– Action is a command, e.g., Dispense Cash, Start Cooking

– Action executes instantaneously

– Activity executes throughout a given state

Guidelines on Statecharts

• More than one action possible with a state transition

– No sequential dependency between actions

• Condition is a Boolean value

– Event [Condition]

– State transition only occurs if

• Event happens & Condition is True

– Condition is True over some interval of time

• Actions, Activities and Conditions are optional

Developing Statechart from Use Case

• Develop state dependent use case

• Start with scenario (one path through use case)

– Consider sequence of interactions between actor and system

• Consider sequence of external events

– Input event from external environment

– Causes state transition to new state

– Action may result from state transition

• Initially develop flat statechart

Banking System use case model
Statechart for ATM Control - Validate PIN use case
Developing Statechart from Use Case (continued)

• Consider alternative external events

– Could result in additional states
– Could result in additional state transitions

• Develop hierarchical statechart

– States that can be aggregated to form composite state

– Event causing transition from several states

• Create composite state with one transition out of composite state

• Instead of many transitions out of substates

Example of integrated statechart
Example of integrated statechart
Dynamic Interaction
Modelling
Dynamic Interaction Modelling
• Dynamic modelling provides a view of a system in which control and sequencing are considered, either
within an object (by means of a finite state machine) or between objects (by analysis of object interactions).
• Use cases realized in Dynamic Model
– Show objects participating in each use case
• Determine how objects participate in use case
– Use object structuring criteria to determine objects
• Stereotype for each object structuring criterion
– Shows sequence of object interactions in use case
• Depict on – Communication diagram or – Sequence diagram
• State-dependent control objects
– Modelled using statecharts
• Dynamic Modelling
– Approach to determine how objects interact with each other to support use case
 Dynamic Modeling

• Determine how objects interact with each other to support use case

– Start with external event from actor

– Determine objects needed to support use case

– Determine sequence of internal events following external event

– Depict on communication diagram or sequence diagram

• Stateless (non-state-dependent) Dynamic Modeling

• State - dependent Dynamic Modeling

 Communication Diagram
• A communication diagram is a UML
interaction diagram that depicts a dynamic
view of a group of objects interacting with
each other by showing the sequence of
messages passed among them.
• Graphically depicts objects interacting with
each other

– Show objects as boxes

– Show their message interactions as arrows
– Number sequence of messages Communication diagram for View Alarms use case
 Sequence Diagram

• Sequence diagram shows object interactions arranged in

time sequence.
• A sequence diagram shows the objects participating in the
interaction and the sequence in which messages are sent.
• Sequence diagrams can also depict loops and iterations.
• Shows sequence of object interactions in use case
• Emphasis on messages passed between objects
– Objects represented by vertical lines

– Messages represented by labeled horizontal arrows Sequence diagram for View Alarms use case
 Stateless Dynamic Modelling
1. Start with use case
2. Determine boundary objects
– Receives external events from actor
3. Determine internal objects
– Receive messages from boundary objects
4. Determine object interactions
– Sequence of messages passed
5. Develop main interaction sequence (scenario)
6. Develop alternative sequences
– For alternative branches of use case
Example of Stateless Dynamic Modeling
– E.g, for error handling or less frequently Communication diagram for View Alarms use case
occurring conditions
 Message Sequence Description

• Describes sequence of object interactions

– Narrative description

– Corresponds to Communication Diagram or Sequence Diagram

• Description corresponds to message sequence numbering on diagrams

– Describe what object does on receiving message

– E.g., every time an object interacts with an entity object

• Describe the object being accessed

• Identify attributes referenced

 Message Sequence Description - View Alarms

A1: The operator requests to view one or more alarms—for

example, to view the status of a factory workstation.

A1.1: Operator Interaction object sends an alarm

request to the Alarm Service.

A1.2: Alarm Service responds—for example, with

information about the requested alarm: name, description,
location, severity.

A1.3: Operator Interaction object formats and

displays the alarm information to the operator.
Sequence diagram for View Alarms use case
 Use case description

Make Order Request Example

1. Develop Use Case Model

Make Order Request Example

2. Determine Objects Needed to Realize Use Case

3. Determine Message Communication Sequence
Make Order Request Example
Make Order Request Example

4. Determine Alternative Sequences

Make Order Request Example

4. Determine Alternative Sequences

Make Order Request Example
Make Order
Request Example
 State-Dependent
Dynamic Interaction
Modelling
 State Dependent Dynamic Modelling
State Dependent Dynamic Modelling help determine how objects interact with each other in dynamic interactions
involving at least one state-dependent control object.
• Object interaction controlled by statechart(s)
• State-dependent interactions involve at least one state-dependent Control object that
• Executes statechart
• Activates/deactivates other objects
• For each use case
– Determine objects participating in use case
– Determine sequence of object communication
– Develop statechart for control object
• For each event that arrives at control object
– Determine state transition from current state to next state
– Determine actions and activities to be executed
– Determine objects required to perform actions and activities
 State Dependent Dynamic Modelling
The main steps in the state-dependent dynamic interaction modelling strategy are presented in the following list.
The sequence of interactions needs to reflect the main sequence of interactions described in the use case.
• 1. Determine the boundary object(s). Consider the objects that receive the inputs sent by the external objects in
the external environment.
• 2. Determine the state-dependent control object. There is at least one control object, which executes the
statechart. Others might also be required.
• 3. Determine the other software objects. These are software objects that interact with the control object or
boundary objects.
• 4. Determine object interactions in the main sequence scenario. Carry out this step in conjunction with step 5
because the interaction between the state dependent control object and the statechart it executes needs to be
determined in detail.
• 5. Determine the execution of the statechart.
• 6. Consider alternative sequence scenarios. Perform the state-dependent dynamic analysis on scenarios described
by the alternative sequences of the use case.
 Example of Dynamic Modeling Banking System -
Validate PIN Use Case
ATM Client Objects
– Boundary Objects
• Card Reader Interface
• Customer Interaction
– Entity Objects
• ATM Card
• ATM Transaction
– State Dependent Control Object
• ATM Control
Communication diagram:
ATM Client – Validate PIN use case – Valid Pin
Sequence Diagram for
Validate PIN use case – Valid Pin
Validate PIN Statechart – Valid Pin
 Validate PIN
Main and Alternative Scenarios
• Valid card and PIN entered
2.6 [Valid]: Valid PIN
• Incorrect PIN
2.6A* [Invalid]: Invalid PIN
Iteration of messages: 2.6A.1 through 2.6A.8.
• Incorrect PIN entered three times
2.6B [Third Invalid]: Third Invalid PIN
• Card stolen or expiration date expired.
2.6C [Stolen OR expired]: Card stolen, Card expired
• Card not recognized:
1.1A [card not recognized] Eject Card
• Cancel
2A.2 Eject
Sequence diagram for validate PIN- Invalid PIN
Sequence Diagram for Validate PIN use case – Stolen
or Expired Card
Communication diagram:
ATM client-Validate PIN use case- Generic form
showing alternatives
Validate PIN statecharts-Valid PIN use case
showing alternative
 Example of Dynamic Modeling Banking System -
Validate PIN Use Case
Banking Service Objects

– Entity Objects

• Debit Card

• Card Account

• Transaction Log

– Business Logic Objects

• PIN Validation Transaction Manager

Example of Dynamic Modeling Banking System -
Validate PIN Use Case
 Example of Dynamic Modeling Banking System -
Withdraw Funds Use Case
ATM Client Objects
– Boundary Objects
• Card Reader Interface
• Receipt Printer Interface
• Cash Dispenser Interface
• Customer Interaction
– Entity Objects
• ATM Transaction
• ATM Cash
– State Dependent Control Object
• ATM Control
Example of Dynamic Modeling Banking System -
Withdraw Funds Use Case

Communication diagram: ATM Client – Withdraw Funds use case

Example of Dynamic Modeling Banking System -
Withdraw Funds Use Case
 Example of Dynamic Modeling Banking System -
Withdraw Funds Use Case
Banking Service objects

– Entity Objects

• Account
• Debit Card
• Bank Transaction

– Business Logic Objects

• Withdrawal Transaction Manager

Example of Dynamic Modelling Banking System -
Withdraw Funds Use Case
‫ﺷﻜﺮا ﻟﻜﻢ‬