Sequence Diagrams
Sequence Diagrams
Related Terms:
Interaction Diagrams
Event Trace Diagram
Scenarios
Message Diagram
Scenarios
• A scenario is a sequence of events that occurs during
one particular execution of a system.
• A scenario can include all events in the system or can
only include these events that are generated by a
certain object in that system.
• A scenario can be a historical record of executing or
simulating the execution of a system or an object.
Example: Scenario for a Phone Line
• Caller lifts receiver
• dial tone begins
• caller dials digit (5)
• dial tone ends
• caller dials digit (5)
• caller dials digit (5)
• caller dials digit (1)
• caller dials digit (2)
• caller dials digit (3)
• caller dials digit (4)
• called phone begins ringing
• ringing tone appears in calling
phone
• called party answers
• called phone stop ringing
• ringing tone disappears in calling
phone
• phones are connected
• called party hangs up
• phones are disconnected
• caller hangs up
Event Trace Diagram
• Each event transmits information from one object to
another.
• Example:
– dial tone begins event transmits a signal from the
phone line to the caller.
• In Event Trace:
– Identify sender and receiver objects of each event.
• Event Trace Diagram (ETD) shows the sequence of
events and the object exchanging these events.
• ETD shows object as a vertical line and each event as a
horizontal line from the sender to the receiver.
Event Trace Diagram for a Phone Call
Caller
Callee
Phone line
caller lifts receiver
dial tone begins
dials (5)
dial tone ends
dials (5)
dials (5)
dials (1)
dials (2)
dials (3)
dials (4)
ringing tone
phone rings
answers phone
tone stop
phone connected
connection broken
ringing stops
phone connected
callee hangs up
connection broken
Sequence Diagrams
Definition:
A sequence shows a series of messages exchanged by
A selected set of objects in temporally limited situation,
With emphasis on the chronological course of events.
Objects are shown by vertical lifelines. This highlights
The chronological sequence of the message.
Time runs from top to bottom.
Scenarios
• Stories about how the business works
– Typical sequences that happen, and variations on the basics
– Usually structured with numbered steps and calls to subsequences
– Can be illustrated with sequence charts
• Scales --- level of detail of the steps:
– Daily scale --- "my pay was credited to my account yesterday, so I went to get
some cash today"
– Detail scale --- "to get money from your account, you insert your card into a
cash machine, select 'cash', …"
– Grand scale --- "A good way of making money is to run a bank. Provide
accounts with higher rates of interest in exchange for less accessibility. They
should be able to get cash from the most accessible accounts at any time of day
or night."
– Choose the level you're working at
Sequence charts for scenarios
• Helps:
– identify the different participants and their interactions
– show the sequence of events
• Each event can be expanded to more detailed sequences
– and each object to more detailed objects
Payday
ibm:Employer
lourdes:Bank jo:Employee
get cash
jo:Customer :CashMachine lourdes:Bank
insert card
req cash
pay
payslip
get cash
req details
cash
get cash
jo:Customer :Card Reader
insert card
req cash
:Dispenser
:Keyboard
Using Scenarios
• Stories illustrated by sequence diagrams
Payday
ibm:Employer lourdes:Bank jo:Employee
IBM transfers money
to Jo's account at her Bank
IBM notifies Jo that she
has been paid
Jo can now collect cash
from her Bank.
pay
payslip
get cash
Benefits of scenarios
• Enable dialogue with non-technical users
• Initial exploration of the domain
Try it …
• Write some scenarios for a Library
– No software, just the people and things
– Write a scenario (or two) to show what happens when Jo
wants to borrow “Trainspotting”, but Pat and Chris
already have the only copies. How does Jo eventually
get to read it?
– Notice that a sequence diagram’s vertical bars are
objects, not types — you can have more than one object
of the same type
Technique: Spot nouns
• Nouns –> candidate types
– Elephant, Airplane, Meeting, Flight
• Questions you could ask at any one moment –>
associations and attributes
– fred is an Elephant
– What colour is fred? What Airplane does fred own? What Meetings is fred
chairing this month? What meetings is fred attending this month?
– m42 is a Meeting
– Who is chairing m42 ? Where will m42 be held? When will m42 take place?
• Verbs –> use-cases
– But usually prefer to do them on a separate diagram
– Fred flies to Athens; m42 is held by fred & the board;
– Some of them turn into objects – fred meets jo –> meeting
Technique: Scenarios -> snapshots
• Snapshots can be used to exercise scenarios
• Scenario = a story about a series of occurrences
• For each step in the scenario, modify the snapshot
– ensure there is a way you can record all the relevant
information in the associations and attributes
– ensure that all information relevant to enquiries is
represented in the associations and attributes
• Update the type model to reflect improvements you
made while going through the scenario
Process: writing scenarios
• Ask users for typical stories about tasks in the domain
• Envision with snapshots, cartoons, screen shots, playacting
– "rich pictures"
MegaBank
Each of Jo's
cards identifies
123:DAccount
jo:Customer
an Account.
345:CAccount
Jo wants money
from her current FastBuck
account.
welcome
She inserts the
card in an ATM.
This associates the
£20: Debit
ATM to her current account.
date=17/5/99
Any further operations at the
machine are recorded against her current account.
How UML is used – software specification
•
Showing which activities the software supports
– Sometimes also useful to note those it doesn’t support
use-case diagram with system boundary
Room Management System
check in
check out
Receptionist
Person
pay bill
 uml-c-p77
Scenario with sequence diagram
• Interactions between actors:This is a form of instance diagram: it just shows one example
of what could occur
Sequence diagram
jo : Person
Person arrives at desk,
gives name.
R gets map of available
Rooms, chooses one.
rms: Room Manager System
arrive
get room map
choose room
get details
R enters Person’s details
on Room Management
system against chosen
room.
R gives key to Person.
chris: Receptionist
person details
confirm room assignment
key
• Used to work out use-case implementation at high level
– No internal details of system
time
use-case check in
Try it ...
• Make a system boundary diagram for a system to support a library
• Create two scenarios for people checking a book out of a library, and
another for returning a book
• List the operations the system is required to do
• Write the dictionary descriptions for the operations
Object oriented or component based design
• Designs consist of interacting parts
– each containing interacting parts ...
• Design is about dividing up the task between the parts
Collaborating objects
• Functions of software system are divided between objects
– Each object performs those sub-tasks most relevant to it
– Objects interact to achieve overall system goals
•‘Sending messages’ = invoking functions
• Objects have to send each other messages to ask for other
parts of the job to be done
• A good OO design partitions the tasks cleanly, so that no
object does work that should properly be done by another
– decoupling 
•flexible, easily changeable software
•separable, generic components that can be assembled in many
ways to make many end products
• Bad design results in poor decoupling  no OO benefits
Distribution of tasks: issues
• Applying for a job
0
thinks: I need a job
jo: Person
1
chris.acceptApplication
(myApplication)
10 (later)
thinks: I need a
widgetgrinder
chris: Secretary
2
: Application
intray: WorkTray
pat: Manager
Distribution of tasks: issues
• Appropriate distribution of responsibilities 
– changes have more restricted impact
– objects can be reused elsewhere
benefit of this scheme:
0
thinks: I need a job
jo: Person
10 (later)
thinks: I need a
widgetgrinder
1
chris.acceptApplication
(joApplic)
11 chris.nextApplicn()
chris: Secretary
pat: Manager
12 intray.get()
2 intray.put(joApplic)
11 intray.get()
joApplic: Application
intray: WorkTray
benefit of this scheme:
UML collaboration diagrams
• Messages shown atop instance diagrams
– associations: references stored within one object linking to another
» could be: pointers in memory, database keys, URLs, ...
– messages: invocations of a function from one object to another
» could be: function calls, database queries, http (web page) requests, …
– These diagrams don't show the precise nature of the implementation
1 needJob( )
jo: Person
2 needWidgetgrinder( )
“*” = repeated with other receiver instances
1.2 *
acceptApplication
(joApplic)
association
message
2.1 nextApplicn( )
chris: Secretary
pat: Manager
boss
1.2.1 put(joApplic)
2.1.1 get()
1.1 new
instance creation
1 intray
intray: WorkTray
joApplic: Application
2.1 intray.get()
UML Sequence diagrams
•
•
Different view of collaborations
– Tools translate directly between the two syntaxes
Good for showing assignment of responsibility
– not so good at associations
– also weak at control flow variations
jo: Person
chris: Secretary
1 needJob( )
intray: WorkTray
pat: Manager
instance creation
1.1 new
joApplic: Application
repeated
1.2 *
message
acceptApplication
(joApplic)
1.2.1 put(joApplic)
stores joApplic
2 needWidgetgrinder( )
2.1 nextApplicn( )
2.1.1 get()
optional
return joApplic