Object Oriented

Analysis and Design

(OOAD)
M2I322952

Lecture 7
Sequence Diagrams

(UML@Classroom – chapter 6 )
1
 Contents

• Describe the purpose of Sequence Diagrams

• Know the notation
• Describe the use and notation of messages
• Develop a sequence diagram from a scenario of a
business situation –> from a Use Case

• (Reading Schaum chapter 9)

2
Process map from Sun Microsystems

3
 UML diagrams

• Class diagrams
– model the static structure of the system

• Interaction diagrams
– model the dynamic aspects of the system

4
5
 UML diagrams

We will initially look at Two kinds of diagram that are

classed as “interaction” diagrams :

• Sequence diagrams
• Communication diagrams
– (collaboration diagrams)

– We will also cover Timing Diagrams and Interaction Overview Diagrams at

a forthcoming lecture

6
 Sequence & Communication diagrams
BOTH of these diagrams show Inter-Object behaviour –
that is, interaction BETWEEN Objects within the system

• Sequence diagrams :
– show interactions and emphasise the order of the messages
over time

• Communication (collaboration) diagrams :

– Show same interaction in the context of the classes that
participate in the interaction
– Show the structural relationships of the classes to one another
7
 Interactions
• An interaction specifies how messages and data are exchanged between
Interaction Partners /Participants.

• The interaction partners are either human, such as lecturers or students, or

non-human, such as a server, a printer, or executable software.

• Alternatively, an interaction can represent the message exchange between

humans and a software system—for example, between a lecturer and the
student administration system when the lecturer publishes exam results.

• An interaction can also be a sequence of method calls in a program or

signals such as a fire alarm and the resulting communication processes.

8
 Interactions

Interaction diagrams are therefore used in various situations. For example

….

Interaction diagrams can be used to model the interaction between

system parts in order to show how a specific use case can be
implemented.

Interaction diagrams can also zoom in much further into the system to be
realized and can model communication at class level, meaning that you
can use them to model operation calls and inter-object behaviour.

9
 Sequence Diagrams
• Model the high level interaction between active objects in a
system
• They are a graphical representation of a Use Case
• Display the interactions that take place between the objects in a
Use Case
• Show the sequence of messages between objects in a use case

Sequence Diagrams can be used to describe a use case or an

operation – in either case they are used to model the interaction
between object instances by showing the sequence of messages
that are exchanged by the objects

OOAD Coursework !!!!

10
 Sequence Diagrams Notation

Includes :
– Frames
– Participants/Objects
– Lifelines
– Messages and Focus of Control
– Actors

11
 Overview
• Sequence Diagrams have a Vertical Time Axis

• Participants (Interaction partners), which usually represent object

instances, are arranged in the frame across the top of the page

• Lifelines run vertically down the page from the participants

Frame

Time

Lifelines
12
Frame
– Contains the Sequence Diagram
– Indicates the context of the Sequence Diagram
– Not always used

Heading

sd interaction name

Content area
13
 Participants (Interaction Partners)
The Participants are placed in rectangles along the top of the Sequence
Diagram

“Participants” is a term used to describe the objects or systems that

participate in the interaction.

They each have a Lifeline (vertical dashed lines)

While it will usually be objects it does not have to be.

 
The names inside the rectangles can be :
• the identifier (name) of an object (e.g. anOrder),
• a class name, which means that the participant is an unnamed object of
that class. To indicate that it is a class, a colon is placed before the class
name (e.g. :Order)
• a collection, for example an array, of objects (e.g. arrayName[i])
• it could be a combination (e.g. anOrder:Order)
• Used in StarUML 14
 Examples of participant names
(UML@Classroom – chapter 6.1 )

Syntax Explanation
o An object named o
o:C An object named o of class c
:C An anonymous object of class c
o[i] The object o that is selected by the index
value i
s ref sd3 A subsystem s whose internal interaction is
shown in sequence diagram sd3

self The connectable element that owns the

interaction shown in the sequence diagram

15
 Lifelines
• Denotes the life of a participant (Object) during a
sequence

Participant name

Lifeline notation

16
 Execution Occurrence
• A long narrow rectangle placed on top of a lifeline
• Denotes when an Object (participant) is sending or
receiving messages

Participant name

Execution Occurrence

17
 Message & Reply notation
• A Message conveys information from one Object to Another
• An Operation is labelled with the message being sent and it is a solid arrow
• Whereas the Return is labelled with the value being returned and shown as
a dashed line

Object Name Object Name

message

Reply/Response (optional) notation 18

 Reply

• Represents the explicit return of control from the

object to which the message was sent.

• Not always shown on sequence diagrams

• Not normally shown on communication diagrams

19
 Message & Reply notation
Message Syntax:
[attribute=] signal-or-operation-name [(arguments)] [:return-value]

Everything is optional APART from Message (or signal or operation)

name - Thus, must ALWAYS have a Message Name

Lifeline name Lifeline name

message

Reply (optional) notation 20

 Message & Reply notation

anOrder anOrderLine

getQuantity

quantity = getQuantity

Reply (optional) notation :

We could just have written quantity ….
OR just leave it blank in this example – since it is obvious from
message name
21
 Example
We will now look at an example of a Sequence
Diagram

To do this – we need to understand the use of

User Interaction

The concept of User Interaction is very important

22
 User Interaction
In many cases, it is this User Interaction which :
• identifies the operations
• ‘controls’ the order of these operations
-> Derived from the Use Case Form/Activity Diagram

Thus, controls the design of the Sequence

Diagram

One way to think about it is :

• what information does the user have to type in ?
• what information has to be displayed ?
• what information has to be updated ?
• what is the order (sequence) of this ?
23
 User Interaction
Another way of doing this is to design and draw a sample
screen which illustrates what information is typed in and
displayed – and in what order !!

You should consider the following :

• What data (attributes) has to be entered by the User?

• What information (attributes) have to be displayed ?
• What objects/attributes have to be checked ?
• What objects/attributes have to be updated ?
 User Interaction

• CRC Cards should also be used at this stage :

– We know which classes are being used
– We know what attributes are in each class
– So we can now start identify which operations are required for
each Use Case – i.e. Sequence Diagram – so should also refer to
Sample Screens
Example – Use case

26
 Class Diagram

( Operations will be added to the classes as

required during the design of the Screen /
Sequence Diagram)
27
Main Flow of Events :
(For the Use Case : Display Course Details )

1. Admin will enter a Course ID

2. The system will display the Course Title

3. The system will then display the Department Details

– Department Name, Head of Department (HoD)

4. Details about ALL Modules on the Course will then be

displayed
– Module ID, Module Name and Credits

28
 Sample Screen

• Will be based on :
– Main Flow Of Events
• Will match the order of events
– objects/attributes from the class diagram

29
Sample Screen

30
Sample Screen
- with operations
- matches the flow of events
1. CourseID – from user
- Use [ square brackets ]

2. DisplayCourseDetails()
- From Course Class

3. DisplayDepartmentDetails(
- From Department Class

4. DisplayModuleDetails()
- From Module Class
- Done in a loop

31
 Class Diagram
– with flow of events
1. CourseID – from Admin
Access the Course Class

2. DisplayCourseDetails
Within the Course Class

3. DisplayDepartmentDetails 4. DisplayModuleDetails
FROM the Course Class FROM the Course Class
In a LOOP

The ‘Staff’ Class is not used in this example

32
Sequence Diagram

33
 Sequence Diagram
Additional Information about the previous Sequence Diagram :

• Admin and ‘System’ ( or ‘Screen’ ) are NOT classes –

they have been added to show the User Interaction,
(which comes from the Use Case Form / Activity
Diagram) :
– information input by User ( e.g Admin )
– Information displayed on Screen (by the ‘System’)

• The use of Loops is covered later

• The ‘Staff’ Class from the Class diagram is NOT used – so is

NOT shownon the Sequence Digram

34
 Example
For another example, we will now look at a
another use case scenario

For a detailed description of this example :

(Does not have the following Order Example which is in

these slides ONLY)
- so refer to Handout AND Slides

35
 For an example, let us look at a simple use
case scenario
Use case “Calculate price”
We have an order and are going to calculate its price.
To do this the order (object) needs to :
• look at all the order lines in the order
• multiply the number of items in an order line by the product’s unit price,
• and then add up the prices of all the order lines.

Finally the order (object) has to check with the customer (object)
to see if he/she gets a discount, and use this to calculate the end
total.

(to start with we are going to make it simple by assuming that an

order has only 1 order line) 36
Use case form
Use Case Name Calculate Price (invoice with 1 order line)
Description Calculates price of order using information on order lines

Actors Primary: sales clerk

Priority High
Risk High
Assumptions
Pre-conditions
Extension Points
Extends None
Trigger An order has been made

Main Flow of
Events 1. Get the quantity, product & product price
2. Calculate order line price total
3. Find out if customer gets discount
4. Calculate final order price

Alternative flow
Of Events

Post-condition
Non-Functional
Requirements

Issues
37
 Relevant Information
We will probably have to hold the following
data :
• Order Information
– (Order Number, DateReceived )
• Customer Information
– ( name, address, discount etc)
• Order Line(s)
– Product, Quantity
– ( e.g. Camera, 2)
• Product
– Price (e.g. Camera Price = £100)
38
• Produce an initial Class Diagram
– Identify classes
– Identify attributes for each class
– Identify possible operations

• Produce sequence diagram

– Update Class Diagram :
• Update attributes
• Update operations
• Repeat this process until class diagram and sequence diagram are
finalised

39
 Order Customer

-datereceived : Date * 1 -lastName: String

-number : String -firstName : String
-discount: Double
-address : Address

1 .. *
Initial Class Diagram – with attributes
Order Line
only
-quantity : Integer
-product : String
What operations do we need ??

* Need ‘Public’ Operations to

1 access attributes/data
Product
-price : Money
40
 calcPrice
• To calculate the actual total price of a given order
– we need to identify required operations for
each relevant class
– Identify public(+) and private(-) operations
– Need public operations to access private data

What operations are required ?????

- Should use CRC Cards to identify possible
operations

41
 Order Customer

-datereceived : Date * 1 -lastName: String

-number : String -firstName : String
-discount: Double
-calcBasePrice() -address : Address
-calcDiscount()
+calcPrice() +getDiscount()
1

Here is the class diagram for the use case

1 .. *

Order Line In order to carry out the task – calculate the order price
– the objects have to communicate with each other .
-quantity : Integer They communicate using their operations. This is what
-product : String
we mean when we talk of passing messages.
+getQuantity()
+getProduct() Look at each class to see what information objects of the
* class would hold and what operations they can carry out
(use CRC Cards)
1
Product
These operations can also be added/updated
-price : Money
when producing the Sequence Diagrams
+getPrice() 42
 Order Example
will be used to explain how to produce the
Sequence Diagram
The following Customer has placed an order for a camera:
 
Customer First Name : Joe
Customer Last Name : Smith
Address : 15 Any St
Discount : £10
 
Order no : 5555 Date : 15/6/16
 
Product Price Qty
Camera 100 2

Base price (Order Line Price) = 2 * 100 = 200

Discount = 10
Order Discount Price = (200 – 10) = 190
43
 Order Customer

-datereceived : 15/6/16 -lastName: Smith

-number : 5555 -firstName : Joe
-discount: 10
-address : 9 Any St.

Order Line

-quantity : 2 Object Diagram for this example

-product : Camera
– with attributes only

Product
-price : 100

44
Main Flow of Events :

1. Get the quantity, product & product price

2. Calculate order line price total
3. Find out if customer gets discount
4. Calculate final order price

45
 Order Customer
3b
-datereceived : 15/6/16 -lastName: Smith
-number : 5555 -firstName : Joe
-discount: 10
2 -calcBasePrice()
-address : 9 Any St.
-calcDiscount()
3a +calcPrice()
+getDiscount()
1a 1b 1c
4 Need to calculate price of a specific Order …. 5555 :
calcPrice() .. Will do the following for Order 5555:
1a Get the quantity (from Order-Line) 2 -> getQuantity()
Order Line 1b Get product (from Order-Line) Camera -> getProduct()
1c & then get product-price (from Product) 100 -> getPrice()
-quantity : 2
-product : Camera
2 Calculate Order Line Price total (called the ‘Base price’)
+getQuantity()
= (quantity * product-price) = 2*100 =200
+getProduct()
-> calcBasePrice()
3a Calculate Discount : -> calcDiscount()
3b get customer discount (from Customer) 10
Product
-> getDiscount()
-price : 100

+getPrice()
4 Calculate final order price ….. using Discount
46
-> done by calcPrice … Order price = 200-10 =190
 Refer to the Module Hand-out for a full description

calcPrice

getQuantity and getProduct are both ‘obvious’ operations - it is clear what they do
In this diagram – there is no return from ‘getQuantity – but there is a return from getProduct
(i.e. aProduct() )
Both of these are correct – do not overuse ‘return’ values that are ‘obvious’ 47
 lifeline

return

activation
(method)
self-call

message

48
 Order Customer

-datereceived : Date * 1 -lastName: String

-number : String -firstName : String
-discount: Double
-calcBasePrice() -address : Address
-calcDiscount()
+calcPrice() +getDiscount()
1

1 .. *

Order Line

-quantity : Integer
-product : String

+getQuantity()
+getProduct()
*

1
Product
-price : Money
+getPrice()
 Order Customer

-datereceived : Date
* 1 -lastName: String
-number : String -firstName : String
-discount: Double
-addLinePriceToTotal(price:double) : double -address : Address
+calcPrice()
+getDiscountedTotal(total:double) : double
1
For Information ONLY :
An Alternative Class diagram – we are not going to use
these classes with their slightly different operations, so you
1 .. * can just ignore this slide. However, it demonstrates an
Order Line important point.

-quantity : Integer This class diagram has the same four classes, but the
-product : String operations (methods) are different. This is a more
decentralised approach to the problem of calculating the
+calcPrice(): double Order price.

Rather than the Order asking the other objects for

* information and doing all the calculations itself ( previous
slides and in the Sequence diagram ), here the Order asks
1 the Order Line to calculate its own price and the Order Line
Product then passes the quantity on to the Product for the Product to
do the calculation.
-price : Money
+getPrice(quantity:int): double This devolving of responsibilities is probably better OO
design.
 Additional Notation
• Message type Notation
• Common operators for interaction frames

51
 Message Type Notation
• Synchronous or Call
• Asynchronous
• Creation
• Destruction

(UML@Classroom – chapter 6.3 )

52
 Synchronous Messages

• The ‘normal’ procedural situation

• A message is sent by one object to another and the first
object waits until the resulting action has completed.
• This may include waiting for the completion of actions
invoked by the second object on other objects

53
As we have already discussed :
 If the message is a Synchronous message, when one method invokes another method
(sends a message), the focus of control is passed to the other operation (method). Control
returns to the first operation with the return arrow, or at end of execution rectangle.
 The message is shown with an arrow with filled in arrowhead, and the return has an arrow
with a dashed line. The arrowhead on the return can be drawn filled in or open (the UML
specifications are a bit ambiguous)

Lifeline name Lifeline name

message
Execution
Occurrence start
event
Message
Start event
Message
Execution
end event
occurrence
end event
54
 Asynchronous messages

• A message is sent by one object to another but the first

object does not wait until the resulting action has
completed
• It carries on with the next step in its own sequence of
actions

55
 Note that some applications are multi-threaded, which means that it’s possible
for a method to send a message and still keep focus of control (i.e. it does not
have to wait for the invoked method to finish and return control).
 In these cases both methods are running at the same time. This type of
message is called an Asynchronous message and is shown using an open
arrowhead.

Lifeline name Lifeline name

message
Execution Occurrence
running. Execution
After sending the occurrence
message. It does not running
have to wait for a
return
56
 Creation and Destruction
Creation :
• It is a dashed line
• It Represents a message that causes the creation of an
object instance to which the message is sent.
• The sender creates an Object (instance)
Destruction :
• Represents a message that causes the
deletion/destruction of an object instance
• The sender destroys the Object (instance)
• It is denoted by an ‘X’ at the end of the Lifeline
57
Notation for creation and destruction of
an object
A message to create a
Object name participant (usually an
object)

CreateObject Object name

DeleteObject

A message to destroy
a participant (usually
an object) 58
 Lost & Found Messages

Lost message

Lost messages have a send event but the receive event is

unknown. Normally because they do not reach their
destination

Found messages

Found messages have a receive event, but their origin is

unknown, possible because it is outside the scope of the
system 59
 Notation for reflexive, or self-call,
message
Lifeline name

message

• An object can send a message to itself or call one of its own

operations.
• This is shown in the focus of control region by placing a
separate rectangle over the existing one and offsetting it
slightly to the right 60
Common operators for
interaction frames

Combined Fragments :
(UML@Classroom – chapter 6.4 )

61
 Common operators for interaction frames
- we will look at some of these in the following slides

alt Alternative multiple fragments; only the one whose condition

is true will execute (if .. else)

opt Optional; the fragment executes only if the supplied

condition is true. Equivalent to an alt with only one trace. (if)

par Parallel – each fragment is run in parallel

loop Loop; the fragment may execute multiple times, and the
guard indicates the basis of the iteration

region Critical region; the fragment can only have one thread
executing at once

ref Reference; refers to an interaction defined on another

diagram. The frame is drawn to cover the lifelines involved in
the interaction. Parameters and return value can be defined

sd Sequence diagram; used to surround an entire sequence

diagram – Main use of a Frame
62
 Notation for Iteration (loops)

Lifeline name Lifeline name Lifeline name

message

Loop[condition]
message

Notation for iteration (loops)

63
 A loop for each
Order Line Item

This Loop can be used for MANY Order Lines

For example if customer orders:
2 cameras at £100 (order line = 200 … current total = 200)
1 tripod at £50 (order line = 50 … current total = 250)
3 SD Cards at £10 (order line = 30 … current total = 280) 64
Customer Discount = £10 …. So Order Discount Price = 280 – 10 = 270
 Notation for selection(if..else, or switch)

Lifeline name Lifeline name Lifeline name

alt [condition] message

[else] message

Keyword alt and two or more compartments separated by dashed lines

65
 loop [for each order line]
 
anOrder anOrderLine aProduct aCustomer

calcPrice()

getQuantity()

getProduct()

aProduct

getPrice()

calcBasePrice()

calcDiscPrice()
getDiscount()
opt [total price > aaa

aDrawTicket
createDrawTicket()
 Ref : Interaction Occurrences
• This is a way to hide details in sequence diagrams

• Interaction occurrence with ref keyword refers to next

Sequence Diagram

• The combined fragment contains the detail of the

interaction

• Interaction occurrence acts as placeholder for and

reference to an interaction shown in detail in another
Sequence diagram

• Where a reference to an interaction occurrence is shown in

a diagram, attribute assignment, parameters and a return
value can be shown 67
sd Spool File to Printer

:WordProcessor :PrintSpooler :Printer

ref
Write File to Print (“UML.doc”)

ref
Send File to Printer (“UML.doc”)

68
sd Write File to Print (String name)

:WordProcessor :PrintSpooler

open(name)
f:File

write(document)

close

print(name)

69
 User Interaction
• Clerk and OrderScreen (or ‘System’) are NOT classes – they have been
added to show the User Interaction, ( which comes from the Use Case
Form / Activity Diagram) :
– information input by User ( e.g Clerk)
– Information displayed on Screen (OrderScreen)
 May also May also
use ‘Actor’ be called
Symbol ‘System’

Previous version of Sequence Diagram 71

 Caley Cars
• Similar to design process for the coursework
• Have done the following :
– Part 1 - Use Case Diagram *
– Part 2 – Use Case Documentation *
– Part 3 - Class Diagram ( with attributes ) *

• Part 4 – will cover :

– Screen layouts
– Sequence diagrams
– Updated Class Diagram
• with attributes/operations
• CRC Cards

* review CaleyCars information on GCULearn for next week