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