Sequence Diagrams

Lecture 8

In this lecture

Tools used during the analysis & Design

phases
Sequence diagrams
Class diagram

1
 Inputs and outputs of systems analysis

Use case Prototypes

models

Systems
Analysis & Design

Sequence State
diagrams diagrams

Collaboration Class
diagrams diagrams

Dynamic Models Add Details to the

Object Model

Dynamic
Models:
Collaboration diagrams
Sequence Diagrams

Use Object
Case
Model
Model

2
 Dynamic Modelling: Sequence Diagrams

Sequence Diagrams are about deciding HOW our

system will achieve what we described in the Use
Case model.

Examples
How entering a new sales order into the system will work
How changing a customer's address will be handled

Sequence Diagrams:
How do the they look like?
Objects
O1 O2 O3 O4 O5 indicates
that the
E1 event
E2 effects the
Events object
E3

E4

Tracks a sequence of events in a scenario

Identifies all objects involved

3
 Sequence diagrams & Software Life
Cycle
Sequence diagrams are used in both the
analysis and the design phases:

In the analysis stage you are trying to think

about how the users needs will be fulfilled.

In the design all details should be included.

Sequence Diagrams
:CheckOutController :StudentDB

getStudentINFO(StudentID)

Sequence diagrams are part of interaction

diagrams just as collaboration diagrams.
They both show relationships between instances
of classes.
Messages exchanged correspond to methods in
class diagrams.
The emphasis is on the sequence.

4
 Return Values
:CheckOutController :StudentDB :Student

getstudentINFO(studentID)

balance := getstudentBal(studentID)

The dotted arrow between the student object and

controller illustrates a return from the method call.
Not always necessary to add them

Message Conditions
:CheckOutController :StudentDB :Student :PayOverDueFineController

getStudentINFO(studentID)

balance := getStudent(studentID)

[balance>0]payFine()

5
 Deletion
:CheckOutController :StudentDB :Student :PayOverDueFineController

getStudentINFO(studentID)

balance := getstudentBal(studentID)

[balance>0]payFine()

Deletion indicates the death of an object

After the fine is paid the PayOverdueFineController
deletes itself

Deletion

Objects may delete themselves or be deleted by

other objects.

A message arrow from one objects lifeline to a

deletion on another object indicates that the
deletion is caused by another object.

6
 Other notations

Multiplicity
Some messages may be sent multiple times
Ex: a patron may check multiple assets
simultaneously.
* before a message indicates that a message may
be sent several times.

Example

7
 Example: Invoice use case

Assume that printing an invoice involves the

following sequence:

1. Get customer details from the customer file.

2. Print customer details (name, address)
3. Get invoice items
4. Print the total required values
5. Print any other terms or conditions that apply to that
purchase

.
.
.

Sequence diagram for print invoice

use case
: Print Invoice

It is usual to have a controller class for each use

case, that drives the processing.

Now, add the controller object to the object model

8
 Print Invoice - class diagram

Print Invoice And now, from our sequence

diagram, we find our first object!

Find the interaction of the controller

with other objects
: Print Invoice : Customer
Record
Now we implement the
Get Customer Name
first step of the scenario
by getting the Print
Invoice control class to
send a message.

And then we need a

recipient of the message.

So we have found another

object

9
 Print Invoice - class diagram

Print Invoice Customer Record

Now we have another object for our class diagram

Add another object to the SD

: Print Invoice : Customer : Invoice
Record

Get Customer Name

Print Customer Name

And so we
move on to the
next step of the
scenario

And now we
have a third
object!

10
 Add another object to the class
diagram

Print Invoice Customer Record

Now we add in our third object

Invoice
And because the message comes
from Print Invoice to Invoice, they
need to be related

And we continue
: Print Invoice : Customer : Sales Items : Invoice
Record

Get Customer Name

Print Customer Name

Get Customer Address

Print Customer Address

Get Unbilled Invoice Items

Print Invoice Lines

Print Total

Print Terms and Conditions

11
 Add another object to the class diagram

Print Invoice Customer Record

Sales Items
Invoice

And we can see that we need one more object

Which is related to Print Invoice

So what did we do?

Introduced a controller object to drive things

Worked through a use case step by step
Sent messages from one object to another
Found objects to deal with the messages
Put the objects and necessary relationships
on a class diagram

12
 Put the methods for each object
: Print Invoice : Customer : Sales Items : Invoice
Record

GetName( )

PrintCustName( )

GetAddress( )

PrintCustAddress( )

GetUnbilledItems( )

PrintLines( )
PrintTotal( )

PrintTermsConditions( )

Methods for each object

Transfer the details to the

class diagram
Add operations to the related classes in the class diagram

Customer Record
Print Invoice

GetName()
Print()
GetAddress()

Invoice
Sales Items
PrintCustName()
GetItems() PrintCustAddress()
GetUnbilledItems() PrintLines()
PrintTotal()
PrintTermsConditions()

13
 Summary
Complicated sequence diagrams (SD) are hard for
users to discuss and they will be used by the
designers in the subsequent design phase.

At first, SD will be missing details, as the work

proceeds to the design, more and more details will
be added to them.

From the sequence of a use case we identify

objects
relationships
operations

14