Object Oriented

Modelling and
Design (17CSI731)
UNIT – 3

ADVANCED STATE MODELING, INTERACTION

MODELING:

State Modeling: Nested state diagrams; Nested states; Signal

Advanced generalization; Concurrency; A sample state model;
Relation of class and state models; Practical tips.
Interaction Modeling: Use case models; Sequence models;
Activity models. Use case relationships; Procedural sequence
models; Special constructs for activity models.
Features of State Diagram

□ Two major features are introduced for

controlling complexity and
combinatorial explosion in state
diagrams Nested State
◦ Nested state diagrams Diagrams
◦ Concurrent state diagrams
□ Many other features are also added
◦ propagated transitions
◦ broadcast messages
◦ actions on state entry, exit Concurrent State
◦… Diagrams
Nested State Diagram

□ Activities in states are composite items denoting other

lower-level state diagrams

□ A lower-level state diagram corresponds to a sequence

of lower-level states and events that are invisible in
the higher-level diagram.
Super/substates
□ When one state is complex, you
can include substates in it.
◦ drawn as nested rounded
rectangles within the larger
state

□ Caution: Don't over-use this

feature.
◦ easy to confuse separate states
for sub-states within one
state
Nested States
A state may be represented as nested substates.
◦ In UML, substates are shown by nesting them in a superstate box.
◦ A substate inherits the transitions of its superstate.
Nested states
Nested State Diagram
State Diagram - Nested States

event- Super-stat
A 1 B e
event-
A 1 B

event- event-
2 2
C event-
2

C
State Diagram Example including substates
get first item

*[all items checked]

[all items checked && all items available]
Checking Dispatching
do / check do / initiate
Item le] delivery
ilab
[all items checked && ava
s d
em ei ve
some items not in stock]
all it rec
[ m
Ite

Ord
erin
g
Exit/ Item received
do / order Item
Canceling Delivering
cancelled
do / Remove entry / deliver
Item Items
Superstates (nested states)
Concurrency in state diagrams
◦ concurrency is a property of systems in which
several computationsconcurrency is a property of systems in which
several computations are executing simultaneously, and potentially
interacting with each other.
◦ Dashed line indicates that an order is in two different states, e.g. Checking &
Authorizing
◦ When order leaves concurrent states, it’s in a single state: Canceled, Delivered
or Rejected
◦ Concurrent Sub states - Used when two or more state diagrams
are executing concurrently within a single object.
Concurrent State Machines
□ Complex systems usually have
concurrency
◦ “subsystems” that operate (mostly)
independently
□ Heart monitor device
◦ The power supply and the heart
monitoring application are really
concurrent subsystems
◦ They should be modeled that
way!!
◦ They are mostly independent: the
monitoring application doesn’t care
where it gets its power
Heart Monitor as Concurrent State Machine
Modeling Concurrency

Two types of concurrency

1. System concurrency
◦ State of overall system as the aggregation of state diagrams,
one for each object. Each state diagram is executing concurrently
with the others.
2. Object concurrency
◦ An object can be partitioned into subsets of states
(attributes and links) such that each of them has its own
subdiagram.
◦ The state of the object consists of a set of states: one state from
each subdiagram.
◦ State diagrams are divided into subdiagrams by dotted lines.
Interaction Models
□ The class model describes the class & objects in
a system and their relationship.

□ The state model describes the life cycles of the objects.

□ The interaction model describes how the

objects interact.

□ The interaction model starts with use cases that are then
elaborated with sequence and activity diagrams
Interaction Models
□ Use case: focuses on functionality of a system- i.e,
what a system does for users

□ Sequence diagrams: shows the object that interact and

the time sequence of their interactions

□ Activity diagrams: elaborates important

processing steps
Use Case Diagrams
 Functional vs. Non-Functional

Functional

Requirements Non-Functional

Functional requirement are user ‘visible’ features and are

typically initiated by stakeholders of the system –
generate report, login, etc.

Non-functional requirements are ‘non-visible’ features and

but required for a effective running of an application – security,
backup, etc.
Use Case Diagrams
□ Use Case diagrams show the various activities the users
can perform on the system.

◦ System is something that performs a function.

□ They model the dynamic aspects of the system.

□ Provides a user’s perspective of the system.

28
 Use-Case Diagrams
A use case is a model of the interaction between External users of a
software product (actors) and The software product itself

□ More precisely, an actor is a user playing a specific role describing a

set of user scenarios capturing user requirements contract between
end user and software developers
Using Use Case Diagrams
□ Use case diagrams are used to visualize, specify, construct,
and document the (intended) behavior of the system, during
requirements capture and analysis.

□ Provide a way for developers, domain experts and end-users to

Communicate.

□ Serve as basis for testing.

□ Use case diagrams contain use cases, actors, and their

relationships.

30
 Use-Case Diagrams
□ Actors: A role that a user plays with respect to the system, including
human users and other systems. e.g., inanimate physical objects
(e.g. robot); an external system that needs some information from
the current system.
□ Use case: A set of scenarios that describing an interaction between a
user and a system, including alternatives.

□ System boundary: rectangle diagram representing the

boundary between the actors and the system.

□ Association: Communication between an actor and a use

case; Represented by a solid line.
Actors

Could be human beings, other systems,

timers and clocks or hardware devices.

Actors Actors that stimulate the system and are the

initiators of events are called primary actors
(active)
Actors that only receive stimuli from the
system are called secondary actors (passive)
Actors

Who/what will be interested in the system?

Who/what will want to change the data in the

system?
Actors

Who/what will want to interface with the

system?

Who/what will want information from the

system?
 Use Case Diagram
– Guidelines & Caution

1. Avoid showing communication between actors.

2. Actors should be named as singular. i.e student and NOT students. NO names
should be used – i.e John, Sam, etc.
Use-Case Diagrams: Actors and Goals

1. Start by identifying the actors of the system

2. Define the goals of the system and how they can be

achieved using the systems’ actors

3. Illustrate these goals and actors actions using use-

case diagram(s)

34
Use-case Diagram: Use-case
□ A use case describes a sequence of actions a system performs to
yield an observable result or value to a particular actor
□ Naming convention = verb + noun (or) verb + noun-phrase,
◦ e.g. withdraw cash
□ A good use case should:
◦ Describe a sequence of transactions performed by a system that
produces a measurable result (goal) for a particular actor
◦ Describe the behavior expected of a system from a user's
perspective
◦ Enable the system analyst to understand and model a system from
a high-level business viewpoint
◦ Represent the interfaces that a system makes visible to the
external entities and the interrelationships between the actors and
the system

35
Use Case Diagrams – Use Cases
□ Use case is a particular activity a user can do on
the system.

□ Is represented by an ellipse.

□ Following are two use cases for a library system.

Borrow Reserv
e
38
Identifying use cases for a system

• What are the tasks of each actor?

• Will any actor create, store, change, remove, or read the
information?
• Will any actor need to inform the system about the
sudden, external changes?
• Does any actor need to informed about certain
occurrences in the system?
• What use cases will support and maintain the
system?
• Can all functional requirements be performed by
the use cases?
Summary of Notations
Construct Description Notation

Use-case A sequence of transactions

performed by a system that
produces a measurable result for
a particular actor

Actor A coherent set of roles that users

play
when interacting with these use
cases

System The boundary between the

Boundary physical system and the actors
who interact with the physical
system

41
Use cases
• Functionality provided by the system
• Consist of a series of steps which collectively add value
to the user of the system
• Examples
– Issue a book to a member
– Receive a book back from a member
– Query the current location of a book
– Maintain member’s information
– Maintain book’s information
Use case diagrams
Use-Case Diagram: Example

System name

Actor Use-case

Association System boundary

46
Use Case Diagram – Example1 (Library)
library system

borro
w
client employee
reserv
e

Order
title

Fine
payment supervisor

47
A
Use Case Diagram for Student
Assessment Management System
Grade system

Record

grades
Student
View
grades
Teacher Distribute
Report
cards

Create report
cards Printing administrator

48
 Use-Case Diagrams

Include: a dotted line labeled <<include>> beginning at base use case

and ending with an arrows pointing to the include use case. The include
relationship occurs when a chunk of behavior is similar across more
than one use case. Use “include” in stead of copying the description of
that behavior.
<<include>>

Extend: a dotted line labeled <<extend>> with an arrow toward the base
case. The extending use case may add behavior to the base use case. The
base class declares “extension points”.

<<extend>>
Include

base <<include>> included

□ The base use case explicitly incorporates the
behavior of another use case at a location specified
in the base.

□ The included use case never stands alone. It only

occurs as a part of some larger base that includes it.

‫עדימ תוכרעמ חותינ‬ 50

More about Include

□ Enables to avoid describing the same flow of events

several times by putting the common behavior in a
use case of its own.

updating
grades <<include>>
verifying
student
id
output <<include>>
generating

‫עדימ תוכרעמ חותינ‬ 51

The <<include>> Relationship
□ Include relationships are used when two or more use cases
share some common portion in a flow of events

□ This common portion is then grouped and extracted to form an

inclusion use case for sharing among two or more use cases

□ Most use cases in the ATM system example, such as Withdraw

Money, Deposit Money or Check Balance, share the inclusion
use-case Login Account

53
The <<include>> Relationship

Withdraw Money
(Base use case) Login Account
(Included use case)

54
The <<include>> Relationship: Example

55
Extend

base <<extend>> extending

□ The base use case implicitly incorporates the
behavior of another use case at certain points called
extension points.

□ The base use case may stand alone, but under certain
conditions its behavior may be extended by the
behavior of another use case.

‫עדימ תוכרעמ חותינ‬ 56

The <<extend>> Relationship
□ In UML modeling, you can use an extend
relationship to specify that one use case (extension)
extends the behavior of another use case (base)

□ This type of relationship reveals details about a

system or application that are typically hidden in a
use case

57
The <<extend>> Relationship
Withdraw Money
(Base use case) Process Excess Amount
(Extending use case)

If conditional guard is true, extending flow is executed

58
The <<extend>> Relationship

59
Example – Include and Extend

Slide 2 (of 48)

Use-Case Diagrams

Figure 16.12
Relationships between Actors
□ Generalization.

student

graduate non-graduate
student student

‫עדימ תוכרעמ חותינ‬ 64

 Summary of Notations
Construct Description Notation

Association The participation of an actor in

a use case, i.e. an instance of
an actor and instances of a use
case communicating with each
other

Generalizatio A taxonomic relationship

n between a general use case and
a more specific use case. The
arrow head points to the
general use case
Extend A relationship between an
extension use case and a base
use case, specifying how the
behavior of the extension use
case can be 65
Summary of Notations
Construct Description Notation

Include A relationship between a base use

case and an inclusion use case,
specifying how the behavior for
the inclusion use case is inserted
into the behavior defined for the
base use case. The arrow head
points to the
inclusion use case

66
Use-Case Diagrams - Clinic
□ Both Make
Appointment and
Request Medication
include Check Patient
Record as a subtask
(include)

□ The extension point is

written inside the base
case Pay bill; the
extending class Defer
payment adds the
behavior of this
extension point.
(extend)

□ Pay Bill is a parent use

case and Bill
Insurance is the child
use case.
(generalization) (TogetherSoft, Inc)
 Use Case Description
:Each use case may include all or part of the following

▪ Title or Reference Name - meaningful name of the UC

▪ Author/Date - the author and creation date
▪ Modification/Date - last modification and its date
▪ Purpose - specifies the goal to be achieved
▪ Overview - short description of the processes
▪ Cross References - requirements references
▪ Actors - agents participating
▪ Pre Conditions - must be true to allow execution
‫עדימ תוכרעמ חותינ‬

▪ Post Conditions - will be set when completes normally

▪ Normal flow of events
▪ Alternative flow of events
▪ Exceptional flow of events
▪ Implementation issues
problems
- regular flow of activities
- other flow of activities
- unusual situations
- foreseen implementation

72
Sequence Models
Sequence Models

The sequence model elaborates the themes of use cases.

Two kinds of sequences models

□ Scenarios

□ Sequence diagram
Scenarios
□ A scenario is a sequence of events that occurs during
one particular execution of a system.

For example:
John logs in, transmits a message from John to
the broker system.
SEQUENCE DIAGRAM
Sequence Diagram
□ A sequence diagram shows the participants in an interaction and the
sequence of messages among them.

□ A sequence diagram shows the interaction of a system with its actors

to perform all or part of a use case.

□ Each use case requires one or more sequence diagrams to describe

its behaviour.
Sequence Diagrams
□ Sequence diagrams, also known as event diagrams or event
scenarios, illustrate how processes interact with each other by
showing calls between different objects in a sequence.

These diagrams have two dimensions:

□ The vertical lines show the sequence of messages and calls in

chronological order
□ Horizontal elements show object instances where the messages
are relayed.
Sequence Diagram

□ Components Of A Sequence Diagram

Sequence
Diagram

Active objects Messages

Control
Activation Box Lifeline
Information
SEQUENCE DIAGRAM (important components)

Active Objects:
◦ Any objects that play a role in the system
◦ Can be any object or class that is valid within the system
◦ Can be an Actor that is external to the system and derives benefits
from the system
Messages:
◦ Used to illustrate communication between different
active objects.
◦ Used when an object needs
● to activate a process of a different object
● to give information to another object
SEQUENCE DIAGRAM (other components)

Lifeline
◦ Denotes the life of actors/objects over time during a sequence

Focus of control (activation box)

◦ Means the object is active and using resources during that time
period

Control information
◦ Shows the control flow in the system
◦ Creation and destruction of an object through <<create>> and
<<destroy>>
Representing objects
□ Squares with object type, optionally preceded by object name and
colon
◦ write object's name if it clarifies the diagram
◦ object's "life line" represented by dashed vert. line

83
 Lifeline
□Objects are displayed at the top of the
diagram
□The vertical dimension represents
time Object Name
□Each object has a dashed line –
lifeline
– extending below it – to indicate the
period of time during which objects
playing that role actually exist
 Lifetime of objects

□ Creation: arrow with

'new' written above it

□ Deletion: an X at bottom of
object's lifeline

85
 Message
□ The messages in an
interaction are drawn from top
to bottom, in the order that Object Name Object Name
they are sent.
□ Messages are shown as
arrows pointing from the message
lifeline of the role sending the
message to the lifeline of the
receiver.
□ When a message is
sent, control passes from the
sender of the message to the
receiver.
Return
Return of control is shown using dashed arrow returning
to the calling object.

Object Name Object Name

message
Messages between objects
□ Message (method call) indicated by horizontal arrow
to other object
◦ write message name and arguments above arrow

86
Indicating method calls
□ Activations - show when a method is active – either executing or
waiting for a subroutine to return

◦ Either that object is running its code, or it is on the stack waiting

for another object's method to finish

87
Activation
•Periodof time during
which an object is
processing a message, Object Name Object Name
Shown on a lifeline as a
narrow rectangle
whose top is connected message
to a message.

•When an object finishes

processing a message,
control returns to the
sender of the message
 Sequence Diagram

a : Assembly part : CatalogEntry

: Client
Lifeline
count(part)
getNumber()
Messages
return number

Activation( control returns to the

optional) sender of the message
(optional)
Sequence Diagram Syntax
Sequence Diagram(make a phone call)

Caller Phone Recipient

Picks up

Dial tone

Dial

Ring notification Ring

Picks up

Hello
Sequenc
e
Diagra
m
Example
Activity Diagrams
What Is an Activity
Diagram?
□ Activity diagrams and use cases are logical model which describe
the business domain’s activities without suggesting how they are
conduct.

□ A diagram that emphasizes the flow of control from activity to

activity in an object.

□ Similar to the traditional program flowchart.

□ Used to provide detail for complex algorithms.

□ Primary activities and the relationships among the activities in a

process.
Drawing Activity Diagrams
Purpose

◦ to model a task (for example in business modelling)

◦ to describe a function of a system represented by a use case

◦ to describe the logic of an operation

◦ to model the activities that make up the life cycle in the Unified
Process
The Activity Diagram Components

□ Initial Node
□ Control Flow
□ Action or Activity
□ Object Flow
□ Branch

□ Merge

□ Fork
□ Join

□ Final Node

* 96
Initial Node
□ This represents the start of
the flow of an activity
diagram.

□ An activity diagram contains

a single start node.

□ The name of the initial node

is entered on the node. It
takes the form of an
adjective.

* 97
 Control Flow
□ A control flow connects any combination of:
◦ activities
◦ branches
◦ merges
◦ forks
◦ joins
□ A control flow has direction, which is indicated by the arrow head
– you may only traverse the control flow in the direction of the
arrow.
□ A control flow may not enter an initial state.
□ A control flow may not exit a final node.
□ A control flow is the representation of an occurrence of an
event.
□ The name of the event is entered on the control flow. It takes the
form of something has been done, noun-verb(past-tense)
10
* 0
Activity And Action
□ The activity represents the
actions that occur as a result of an
incoming event from a control
flow.

□ The name of the activity is

entered on the activity and takes
the form of something being
done, present tense verb-noun

10
* 1
 Branch
□ The branch is used to show alternative paths in the
activity diagram.
□ Label the decision node with a question(?).
□ Do not label the merge, (unless you have a good
reason to).
□ One control flow enters the decision node and two
or more alternative control flows exit the decision
node.
□ Only one of the paths may be transitioned as the
result of an event occurring.
□ Each exiting control flow contains the condition
under which it is taken (called a guard), dependent
upon the answer to the question. These guards must
be mutually exclusive.

10
* 2
Branch
□ The guards on exiting control flows must cover all possible
outcomes of the question being asked by the branch.
◦ The simplest way to ensure all possible outcomes are covered is
to phrase the branch question such that the only possible answers
are ‘Yes’ or ‘No’. Note, this can add extra branches to the
diagram.
□ Two or more control flows enter the merge node and one
control flow exits.
 Fork
□ The fork may be represented by vertical or
horizontal bars.
□ The fork represents that the flow through the
diagram has split into 2 paths that are running
in parallel (multitasking).
□ The fork has a single control flow on entry and
several control flows exiting.
□ Use a fork when there is no requirement on the
order of activities in a flow.
◦ For example, the Dematerializer receives an
event that the door is shut. It now suspends
the cargo and creates a vacuum, but these
actions may be performed in parallel, so we
model them with a fork.

10
* 4
 Join
□ For every fork there should be a join (if not
your activity diagram is broken).
□ The join may be represented by vertical or
horizontal bars.
□ A join simply shows that when the parallel
activities have finished that they then come
back to join a single flow again.
□ The join has several control flows entering and
a single control flow on exit.
□ The exiting control flow cannot be executed
until every incoming control flow has
completed.
□ There is no need to label the fork or join.

10
* 5
 Final Node
□ The final node represents the termination of the
activity diagram.
□ There may be several termination states in a single
diagram.
□ Label the final node with an adjective.

10
* 6
Let’s review the shapes
START POINT DECISION POINT

END POINT [Condition] GUARD

STEP PARALLEL STEPS

For each X:
TRANSITION REPEATED STEPS
START

POINT
The Start Point
represents the
EVENT that
triggers the use
case.
Actor elects to Add Customer

END
POINT
Actor elects to Add Customer

Label the End Point to

EXPLICITLY confirm
that the intent of the
use case has been
achieved.
Actor elects to Add Customer

Customer added
Actor elects to Add Customer

This makes it clear to

the reader that the use
case is complete and
that nothing further is
needed in order to
fulfil the intent.

Customer added
Actor elects to Add Customer

End of process
To reach the
End Point…
… you need to
model
STEPS.
Link the steps
with
TRANSITIONS.
Transitions use arrow
heads to show the
direction of process
flow.
 I like to put a note
against any step that
achieves the goal of
the use case.

Goal
X
achieved
 Goal
X
achieved

… because it might
not be the last
step.
Often in a use case
the System has to
make a decision
based on business
rules...
The actual decision
takes place within
a STEP
 System
determines
whether X or
Y
The actual decision
takes place within
a STEP
 System
determines
whether X or
A DECISION POINT Y
is then used to
help the
reader
navigate the
diagram.
DECISION
POINT
 Decision Points
contain text which
describes the
nature of the
decision to be
made.
So was it X or Y?
 Decision points
allow the flow to
branch away from
the Primary Path.
 Transitions
[Condition 2]
coming out of
Decision Points [Condition 1]
must have a
GUARD.
 [IT WAS “Y”]

[IT WAS “X”]

A Guard needs to
explicitly describe a
condition which must
be true in order to
proceed down that
path.
 If the flow
rejoins the
Primary Path,
it is known as
an Alternate
Path.
[Condition 2]

[Condition 1]
 [Condition 1] [Condition 2]

You can show

how paths rejoin
by using a MERGE
POINT.
 [Condition 1] [Condition 2]

You can show

how paths rejoin
by using a MERGE
POINT.
I prefer to model
merging paths like
this.

[Condition 1] [Condition 2]