Lecture11 use case sequence diagram

Use Case
Sequence Diagram

Interaction Diagrams
q Interaction diagrams model the behavior of
use cases by describing the way groups of
objects interact to complete the task of the
use case.
q There are two types of interaction diagrams
q Sequence Diagrams and Communication
Diagrams (formally known as collaboration
diagrams)

Interaction Diagrams
q Sequence diagrams
• generally show the sequence of events that occur.
q Collaboration diagrams
demonstrate how objects are statically connected.
q Both diagrams are relatively simple
to draw and contain similar elements.

Sequence Diagram
q Illustrates the objects that participate
in a use case and the messages that
pass between them over time for one
use case
q In design, used to distribute use case
behavior to classes

Sequence Diagram
member:
LibraryMember
book:Book
:Book
Copy
borrow(book)
ok = mayBorrow()
[ok] borrow(member)
setTaken(member)
X-Axis (objects)
Y-Axis(time)
ObjectLife
Line
Message
Focus of
control
Condition

Sequence Diagram Syntax
AN ACTOR
AN OBJECT
A LIFELINE
A FOCUS OF CONTROL
A MESSAGE
OBJECT DESTRUCTION
anObject:aClass
aMessage()
x

Sequence Diagram
Two major components
• Active objects
• Communications between these active
objects
• Messages sent between the active objects

Sequence Diagram
Active objects
• Any objects that play a role in the
system
• Participate by sending and/or receiving
messages
• Placed across the top of the diagram
• Can be:
• An actor (from the use case diagram)
• Object/class (from the class diagram) within the
system

Active Objects
Object
• Can be any object or class that is
valid within the system
• Object naming
• Syntax
[instanceName][:className]
1. Class name only :Classname
2. Instance name only objectName
3. Instance name and class name
together object:Class
myBirthdy
:Date

Active Objects
Actor
• A person or system that derives
benefit from and is external to the
system
• Participates in a sequence by sending
and/or receiving messages

Communications
between Active Objects
Messages
• Used to illustrate communication
between different active objects of a
sequence diagram
• Used when an object needs
• to activate a process of a different object
• to give information to another object

Messages
A message is represented by an arrow
between the life lines of two objects.
• Self calls are allowed
A message is labeled at minimum with
the message name.
• Arguments and control information
(conditions, iteration) may be included.

Types of Messages

Synchronous (flow interrupt until the message
has completed)

Asynchronous (don’t wait for response)

Flat (no distinction between sysn/async)

Return (control flow has returned to the caller)

Synchronous Messages
q The routine that handles the
message is completed before the
calling routine resumes execution.
:A :B
doYouUnderstand()
Caller
Blocked
return
(optional)yes

Asynchronous Messages

Calling routine does not wait for the
message to be handled before it
continues to execute.
 As if the call returns immediately

Examples
 Notification of somebody or something
 Messages that post progress
information

Return Values

Optionally indicated using a dashed
arrow with a label indicating the return
value.
 Don’t model a return value when it is
obvious what is being returned, e.g.
getTotal()
 Model a return value only when you need to
refer to it elsewhere (e.g. as a parameter
passed in another message)
 Prefer modeling return values as part of a
method invocation, e.g. ok = isValid()

Other Elements
of Sequence Diagram

Lifeline

Focus of control (activation box or
execution occurrence)

Control information
 Condition, repetition

Sequence Diagram

Lifeline
 Denotes the life of actors/objects over
time during a sequence
 Represented by a vertical line below
each actor and object (normally dashed
line)

For temporary object
 place X at the end of the lifeline at the
point where the object is destroyed

Sequence Diagram

Focus of control (activation box)
 Means the object is active and using
resources during that time period
 Denotes when an object is sending or
receiving messages
 Represented by a thin, long
rectangular box overlaid onto a lifeline

Control Information

Condition
 syntax: ‘[‘ expression ’]’ message-label
 The message is sent only if the
condition is true
[ok] borrow(member)

Elements of Sequence Diagram
obj1:Class
[x < 15] calculate()
obj2: Class
message()

Sequence Diagrams
obj1:Class
[x < 15] calculate()
obj2: Class
message()
obj3: Class
[x > 20] calculate()

Sequence Diagrams
q Concurrency
obj1:Class
calculate()
obj2: Class
message()
obj3: Class
calculate()

Elements of Sequence Diagram

Control information
 Iteration
 may have square brackets containing a
continuation condition (until) specifying
the condition that must be satisfied in
order to exit the iteration and continue
with the sequence
 may have an asterisk followed by square
brackets containing an iteration (while or
for) expression specifying the number of
iterations

Control Information

Iteration
 syntax: * [ ‘[‘ expression ‘]’ ]
message-label
 The message is sent many times to
possibly multiple receiver objects.
*draw()

Control Information

Iteration example
:Driver
*[until full] insert()
:Bus:CompoundShape :Shape
*draw()
draw()

Sequence Diagrams

Creation and destruction of an object in
sequence diagrams are denoted by the
stereotypes <<create>> and <<destroy>>
:Creator
<<create>>
: Created Object
message()
<<destroy>> X

getViolation(id)
Sequence Diagram
Clerk
:Violations
Dialog
:Violations
Controller
:Violations
DBProxy
lookup
viewButton()
id=getID()
v:Traffic
Violation
display(v)
<<create>>
v
Lookup
Traffic
Violation
DB is queried
and the result
is returned as
an object

Steps for Building
a Sequence Diagram
1) Set the context
2) Identify which objects and actors will participate
3) Set the lifeline for each object/actor
4) Lay out the messages from the top to the
bottom of the diagram based on the order in
which they are sent
5) Add the focus of control for each object’s or
actor’s lifeline
6) Validate the sequence diagram

1) Set the context.
a) Select a use case.
b) Decide the initiating actor.
Steps for Building a Sequence Diagram

2) Identify the objects that may
participate in the implementation of
this use case by completing the
supplied message table.
a) List candidate objects.
1) Use case controller class
2) Domain classes
3) Database table classes
4) Display screens or reports

2) Identify the objects (cont.)
b) List candidate messages. (in message analysis table)
1) Examine each step in the normal scenario of the
use case description to determine the messages
needed to implement that step.
2) For each step:
1) Identify step number.
2) Determine messages needed to complete this
step.
3) For each message, decide which class holds the
data for this action or performs this action
3) Make sure that the messages within the table are in the
same order as the normal scenario

2) Identify the objects (cont.)
c) Begin sequence diagram construction.
1) Draw and label each of the identified actors and
objects across the top of the sequence diagram.
2) The typical order from left to right across the top is
the actor, primary display screen class, primary
use case controller class, domain classes (in
order of access), and other display screen classes
(in order of access)
2) Set the lifeline for each object/actor

4) Lay out the messages from the top to the
bottom of the diagram based on the order
in which they are sent.
a) Working in sequential order of the message
table, make a message arrow with the
message name pointing to the owner class.
b) Decide which object or actor initiates the
message and complete the arrow to its lifeline.
c) Add needed return messages.
d) Add needed parameters and control
information.

5) Add the focus of control (activation
box) for each object’s or actor’s
lifeline.
6) Validate the sequence diagram.

Sequence Diagrams
:Cashier
makenewSale()
: System
enterItem(itemID, quantity)
description, total
endSale()
total
makePayment(amount)
change due, receipt

Lecture11 use case sequence diagram

In this document