Object Oriented Analysis and

Design
Lecture 6 – Sequence Diagrams
Muhammad Zeeshan Sabir
Sequence Diagram
• An SSD shows, for a particular course of events within a use case
• Describe flow of messages, events, actions between objects
• Show concurrent processes and activations
• Show time sequences that are not easily depicted in other diagrams
• Typically used during analysis and design to document and
understand logical flow of your system
 Cont…
• Two-dimensional diagram
• Horizontal axis: involved interaction partners
• Vertical axis: chronological/ sequential order of the
interaction
• Interaction = sequence of event specifications
 Interaction Partners
• Interaction partners are depicted as lifelines
• Head of the lifeline
• Rectangle that contains the expression
• Body of the lifeline
• Vertical, usually dashed line
• Represents lifetime of the object associated with it
Head of lifeline

Body of Lifeline
Representing Objects
• Squares with object type, optionally preceded by object name and
colon
• write object's name if it clarifies the diagram
• object's "life line" represented by dashed vert. line
 Exchanging Messages
• Interaction: sequence of events
• Message is defined via send event and receive event
• Execution specification
• Continuous bar
• Used to visualize when an interaction partner executes some
behavior

Send event Receive event

Execution specification
Messages
• Synchronous message
• Sender waits until it has received a response message
before continuing
• Syntax of message name: msg(par1,par2)
• msg: the name of message
• par: parameters separated by commas
• Asynchronous message
• Sender continues without waiting for a response
message
• Syntax of message name: msg(par1,par2)
Messages
• Response message
• May be omitted if content and location are obvious
• Syntax: att=msg(par1,par2):val
• att: return value can optionally be assigned to a variable
• msg: the name of message
• par: parameters separated by commas
• val: return value
 Cont…
• Object creation
• Dashed arrow
• Arrowhead points to head of lifeline of
object to be created
• Keyword new
• An object created after the start of scenario appears lower
than the others
• Object destruction
• Object is deleted
• Large cross (×) at the end of lifeline
 Cont…
• Found message
• Sender of a message is unknown or not relevant
• Lost message
• Receiver of a message is unknown or not relevant

• Time-consuming message Time=A

• "Message with duration" Time=B

• Usually messages are assumed to be transmitted

without any loss of time
• Express that time elapses between sending and
receipt of a message
 Cont…
• activation: thick box over object's life line
• either that object is running its code, or it is on stack waiting for another
object's method to finish
Example
 Combined Fragments
• 12 predefined types of operators
Combined Fragment

Operator
Operand

Operand
Operand
Types of Combined Fragments
 Cont…
• if -> (opt) [condition]
• if/else -> (alt) [condition], separated by horizontal dashed line
• loop -> (loop) [condition or items to loop over]
 opt Fragment

• To model an optional
sequence
• Actual execution at runtime is
dependent on guard
• Exactly one operand
• Similar to if statement
without else branch
 alt Fragment

• To model alternative sequences

• Similar to if else statement
• Guards are used to select one
path to be executed
• Guards
• Modeled in square brackets
• default: true
• predefined: [else]
loop Fragment
• To express that a sequence is to be executed
repeatedly
• Exactly one operand
• Keyword loop followed by minimal/maximal number of
iterations (min..max) or (min,max)
• default: (*) .. no upper limit
• Guard
• Evaluated as soon as the minimum number of iterations has
taken place
• Checked for each iteration within (min,max) limits
• If guard evaluates to false, execution of loop is terminated
 break Fragment
• Simple form of exception handling
• Exactly one operand with a guard
• If the guard is true:
• Interactions within this operand are
executed
• Remaining operations of surrounding
fragment are omitted

Not executed if break is

executed
loop and break Fragment - Example
System Sequence Diagram vs
Sequence Diagram (SSD vs SD)
• A System Sequence Diagram:
• is an artifact that illustrates input and output events related to system under
discussion.
• Typically associated with use-case realization
• System behaves as “Black Box”
• Interior/inner objects are not shown, as they would be on a Sequence Diagram.
• Sequence Diagrams:
• Display object interactions arranged in time sequence.
• Depict objects and classes involved in the scenario, sequence of messages
exchanged between objects needed to carry out the functionality of system.
SSD
• A system sequence diagram (SSD) is a picture that shows for a
particular scenario of a use case, events that external actors generate,
their order, and inter-system events.
• Suggestion: One SSD – one Use Case
• In other words,
• Operations of system in response to the events generated.
• Depict the sequential order of events.
• Should be done for the main success scenario of the use-case, and
frequent and alternative scenarios.
Explanation
• System sequence diagrams, also known as SSD, are actually a sub-type of
sequence diagrams, whose style and notation is dictated by UML.
• Sequence diagrams show progression of events over a certain amount of
time, while system sequence diagrams go a step further and present
sequences for specific use cases.
• Use case diagrams are simply another diagram type which represents a
user's interaction with system. Most elements we cover in use case
diagrams remain in use throughout a system sequence diagram,
including:
• Objects: this box shape with an underlined title represents a class, or
object, in UML. Within a SSD, this shape models system as a black box (a
system with inner workings that are not immediately visible).
• Actors: shown by stick figures, actors are entities that interact with
system, and yet are external to it.
• Events: system events that actors generate in sequence. A dashed line,
known as a lifeline, represents events in an SSD. Lifelines may begin with a
Example (SSD)
• Following example shows the success scenario of the Process Sale use
case.
• Events generated by cashier (actor)-
• makeNewSale
• enterItem
• endSale and
• makePayment
SSD for Process Sale scenario
System Sequence Diagrams and
Use Cases
• System Sequence Diagram is generated from inspection of a use case.
• Constructing a systems sequence diagram from a use case:
1. Draw a line representing system as a black box.
2. Identify each actor that directly operates on system. Draw a line for each
such actor.
3. From use case, identify system (external) events that each actor generates.
They will correspond to an entry in right hand side of typical use case.
Illustrate them on the diagram.
SSDs: Derived from use cases
 Class Exercises
• Draw a sequence diagram for:
• Getting on a flight. Start at home, check in at the counter, go through security, and
end up at the gate. (If you have time during the exercise, get yourself to your seat.)
• You may get searched in security
• Draw a sequence diagram for:
• Getting money from an ATM machine
• Treat each part of the ATM as a class
• Keypad
• Bank computer etc.
Class Exercises

• Draw a sequence diagram for:

• Getting money from an ATM machine
• Treat each part of the ATM as a class
• Keypad
• Bank computer etc.