Information System Design

IT60105

Lecture 08

Interaction Diagrams

24 August, 2006 Information System Design IT60105, Autumn 2006

 Lecture #08
• What is a sequence diagram?

• Basic components in any sequence diagram and their

notations

• Illustration of applications in Modeling

• Collaboration diagrams

24 August, 2006 Information System Design IT60105, Autumn 2006

 Interaction Diagrams
• Interaction diagrams model how groups of objects collaborate
in some behavior

• There are two types of interaction diagrams

– Sequence diagrams

– Collaboration diagrams

24 August, 2006 Information System Design IT60105, Autumn 2006

 Sequence Diagram

24 August, 2006 Information System Design IT60105, Autumn 2006

 What is a Sequence Diagram?
• A sequence diagram shows object interactions arranged in
time sequence

• It depicts the object and classes involved in the scenario and

the sequence of messages exchanged between the objects
needed to carry out the functionality of the scenario

• Typically, a sequence diagram captures the behavior of a

single activity or a use case

24 August, 2006 Information System Design IT60105, Autumn 2006

 Basic of a Sequence Diagram
• A sequence diagram is a two dimensional chart

• The chart is read from top to bottom

• The objects participating in the interaction are shown at the top of the chart
as boxes attached to a vertical-dashed line

• Inside the box the name of the object is written with a colon separating it
form the name of the class and both the name of the class and object are
underlined

• Some times an anonymous object (only class name and underlined) is also
used

24 August, 2006 Information System Design IT60105, Autumn 2006

 Life Line in a Sequence Diagram
• A lifeline represents an individual participant in a sequence diagram. A
lifeline will usually have a rectangle containing its object name. If its name
is self then that indicates that the lifeline represents the classifier which
owns the sequence diagram

24 August, 2006 Information System Design IT60105, Autumn 2006

 Life Line in a Sequence Diagram
• Sometimes a sequence diagram will have a lifeline with an actor element
symbol at its head. This will usually be the case if the sequence diagram is
owned by a use case. Boundary, control and entity elements form
robustness diagrams can also own lifelines

24 August, 2006 Information System Design IT60105, Autumn 2006

 Example: Objects and Life Line

m i h i r : S t u da ue nt u t m n 0 6 : C o u r: s C e Mo u g r rs e

c l a s s n a m e
a n o n y m o u s o b je c t
o b je c t n a m e

v e r t i v a l - d a s h e d l i n e s a t t a c h e d t o o b je c t

24 August, 2006 Information System Design IT60105, Autumn 2006

 Objects and Life Time
• The objects appearing at the top signifying that the object already existed
when the use case execution was executed.

• However, if some object is created during the execution of the use case
and participates in the interaction, then that object should be shown at the
appropriate place on the diagram where it was created

• The vertical dashed line in the sequence diagram is called the object’s life
time. The life time indicates the existence of the object at any particular
point of time

• A rectangle is used on the life time to indicate the activation symbol and
implies that the object is active as long as the rectangle exists

24 August, 2006 Information System Design IT60105, Autumn 2006

 Example: Object’s Life Time
m i h i r : S t u d e n t

o b je c t s t a r t s a n
a c t i v i t y h e r e

a n o b je c t a p p e a r s
h e r e

o b je c t f i n i s h e s a n
a c t i v i t y h e r e
L i f e t i m e

a u t u m n 0 6 : C o u r s e M g

o b je c t e x p i r e s h e r e

24 August, 2006 Information System Design IT60105, Autumn 2006

 Start and End of Life Line
• A lifeline may be created or destroyed during the timescale represented by
a sequence diagram. In the latter case, the lifeline is terminated by a stop
symbol, represented as a cross. In the former case, the symbol at the head
of the lifeline is shown at a lower level down the page than the symbol of
the object that caused the creation. The following diagram shows an object
being created and destroyed

24 August, 2006 Information System Design IT60105, Autumn 2006

 Messages in Sequence Diagrams
• Two objects in a sequence diagram interacts with passing
messages between them

• Each message is indicated as an arrow between the lifelines of

two objects

• The order of message is very important in the sequence

diagram. They should appear in chronological order from top
to the bottom. That is, reading the diagram from the top of the
bottom would show the sequence in which the message occurs

• Each message is labeled with the message name

24 August, 2006 Information System Design IT60105, Autumn 2006
 Example: Message in a Sequence Diagram

m i h i r : S t u d a e u n t ut m n 0 6 : C o u r s e M g r

1
r e q u e s t E n r o l l ( )
2

s e a r c h ( )
c o n f i r m E n r o l l ( )
T h r e e m e s s a g e s
3 c h r o n o l g i c a l s e q u

T w o o b je c t a r e c o m m u n i c a t i n g
b y p a s s i n g m e s s a g e s

24 August, 2006 Information System Design IT60105, Autumn 2006

 More on Messages
• Messages can be synchronous or asynchronous; call or signal. In the
following diagram, the first message is a synchronous message (denoted by
the solid arrowhead) complete with an implicit return message; the second
message is asynchronous (denoted by line arrowhead) and the third is the
asynchronous return message (denoted by the dashed line)

24 August, 2006 Information System Design IT60105, Autumn 2006

 More on Messages
• Messages can be lost or found. Lost messages are those that are either sent
but do not arrive at the intended recipient, or which go to a recipient not
shown on the current diagram. Found messages are those that arrive from
an unknown sender, or from a sender not shown on the current diagram.
They are denoted going to or coming from an endpoint element

24 August, 2006 Information System Design IT60105, Autumn 2006

 Self or Recursive Messages
• A self message can represent a recursive call of an operation, or one
method calling another method belonging to the same object. It is shown as
creating a nested focus of control in the lifeline’s execution occurrence

24 August, 2006 Information System Design IT60105, Autumn 2006

 Controlled Messages

• Some control information can also be included

• Two types of control information are particularly known:

1. A condition (e.g. [vacant = true]) indicates that a message is sent, only

if the condition is true

2. An iteration marker (*) is used to indicate that the message is to be

repeated many times to multiple receiver objects (e.g. when it is
required to iterate over a collection or an array of elements)

24 August, 2006 Information System Design IT60105, Autumn 2006

 Example: Controlled Message

m i h i r : S t u d a e u n t ut m n 0 6 : C o u r : s eC M o ug r r s e

r e q u e s t E n r o l l ( )

s e a r c h ( )
[ v a c c a o n n t ]f i r m E n r o l l ( )

g e t C o u r s e ( )
* g e t C o u r s e ( )

s e n d t h i s m e s s a g e i f t h i s
c o n d i t i o n i s t r u se e n d m e s s a g e s t o a l l c o u r
o b je c t s

24 August, 2006 Information System Design IT60105, Autumn 2006

Duration and Timing Constraints
• By default, a message is shown as a horizontal line. Since the lifeline
represents the passage of time down the screen, when modeling a real-time
system, or even a time-bound business process, it can be important to
consider the length of time it takes to perform actions. By setting a
duration constraint for a message, the message will be shown as a sloping
line

24 August, 2006 Information System Design IT60105, Autumn 2006

 Combined Fragments
• A combined fragment is one or more processing sequence
enclosed in a frame and executed under specific named
circumstances. The fragments available are:

• Alternative fragment (denoted “alt”) models if…then…else constructs.

• Option fragment (denoted “opt”) models switch constructs.
• Break fragment models an alternative sequence of events that is processed
instead of the whole of the rest of the diagram.
• Parallel fragment (denoted “par”) models concurrent processing.
• Weak sequencing fragment (denoted “seq”) encloses a number of
sequences for which all the messages must be processed in a preceding
segment before the following segment can start, but which does not impose
any sequencing within a segment on messages that don’t share a lifeline.

24 August, 2006 Information System Design IT60105, Autumn 2006

 Combined Fragments
Contd…

• Strict sequencing fragment (denoted “strict”) encloses a series of messages

which must be processed in the given order.
• Negative fragment (denoted “neg”) encloses an invalid series of messages.
• Critical fragment encloses a critical section.
• Ignore fragment declares a message or message to be of no interest if it
appears in the current context.
• Consider fragment is in effect the opposite of the ignore fragment: any
message not included in the consider fragment should be ignored.
• Assertion fragment (denoted “assert”) designates that any sequence not
shown as an operand of the assertion is invalid.
• Loop fragment encloses a series of messages which are repeated.

24 August, 2006 Information System Design IT60105, Autumn 2006

 Example: Combined Fragments
• The following diagram shows a loop fragment.

24 August, 2006 Information System Design IT60105, Autumn 2006

 Applications
of
Sequence Diagrams

24 August, 2006 Information System Design IT60105, Autumn 2006

 ATM PIN Validation
a :c a r d R e a b d :se e r s s i o n M c :dg ri s p l a y M d g :k r e y R e a d e e :a r B a n k

c a r d I n f o ( )
b e g i n
s e s s i o n
[ ! v a l i d A T M c a r d ]
e j e c t ( )
c h e c k C a r d ( )

s t a t u s
[ s t a t u s . i s S t o l e n ]
r e t a i n ( )

[ s t a t u s . c l o s e A c c o u n t ]
e j e c t ( )
[ ! v a l i d P I N & & t r y < 4 ]
r e q u e s t P I N ( )

r e a d P I N ( )
v a l u e P I N

v e r i f y P I N ( )
[ ! v a l i d P I N ]
e j e c t ( ) x x
d i s p l a y H e l l o ( )

x x

x
24 August, 2006 Information System Design IT60105, Autumn 2006
 Use Case Registration of OLP
Use case: Registration

Scenario 1: Customer is a staff member

Select customer type as staff.
Get data for a customer as staff.
Check the validity of the staff customer.
Alternative 1.1: Disqualify the validity of a staff
Message “Registration fail”.
Alternative 1.2: Qualify the validity of a staff
Check for already registered customer.
Alternative 1.2.1: Registration exist
Message “Registration fail”.
Alternative 1.2.1: Registration does not exist
Message “Registration successful”.
Create a new customer c.
Update record with c.
Scenario 2: Customer is other than staff
Select customer type as other.
Get data for a customer as other.
Check for already registered customer.
Alternative 2.1: Registration exist
Message “Registration fail”.
Alternative 2.2: Registration does not exist
Message “Registration successful”.
Create a new customer c.
Update record with c.

24 August, 2006 Information System Design IT60105, Autumn 2006

 Sequence Diagram of Registration
a: C u s t o m e b r: I n t e r f a c e M c : Rg re g n M g dr : S y s t e m M g r

b e g i n s e s s i o n r e g n R e q u e s t ( )

g e t C u s t o m e r T y p e ( )
i n p u t T y p e ( )
C u s t o m e r T y p e = r e a d D a t a ( )

[ C s t o m u
e r T y p e = s t a f f ]
g
e t S t a f f D a t a ( )
i n p u t S t a f f D a t a ( )
c d = s t a f f C u s t o m e r D a t a ( )
s t a t u s 1 = c h e c k S t a f f ( c d )
[ s t a t u s 1 = i n v a l i d ]
d i s p l a y M s g ( R e g n . f a i l )
[ s t a t us 1 = v a l i d ]
[ s t a t u s 2 = e x i as
s t tt ] u s 2 = c h e c k E x i s t ( c d )
d i s p l a y M s g ( R e g n . f a i l )
[ s t a t u s = 2n o t E x i s t ]
d i s p l a y M s g ( R c e 1 g =n . cs ru e
c c e s s u) s t o m
a t e C e r ( c d )
u p d a t e R e c o r d ( c 1 )
[ C u s t o m e r T y p e = o t h e r ]
i n p u t O t h e r D g e
a t a ( ) t O t h e r D a t a ( )
c d = o t h e r C u s t o m e r D a t a ( )
s t a t u s 2 = c h e c k E x i s t ( c d )
[ s t a t u s 2 = e x i s t ]
d i s p l a y M s g ( R e [ sg t n a . t uf a s i2 l ) = n o t E x i s t ]
c 2 = c r e a t e C u s t o m e r ( c d )
d i s p l a y M s g ( R e g n . s u c c e s s )
u p d a t e R e c o r d ( c 2 )

24 August, 2006 Information System Design IT60105, Autumn 2006

 Use Case Order Item in OLP
Use case: Order Items

Scenario 1: Option is new

Prompt for “Registration”
Call “Registration”
Display registration status
Exit

Scenario 2:Option is login

Call “Check In”
Alternative 2.1: Login is valid
Prompt for “Item Details”
Call “Create Order”
Display order status
Exit
Alternative 2.2: Login is invalid
Display login fail
Exit

24 August, 2006 Information System Design IT60105, Autumn 2006

 Process Order in OLP System

• To illustrate the drawing of a sequence diagram, let us consider the use

case “Process Order ” in the OLP system

• The “Process Order” use case is proposed to have a following behavior (or
scenario)

• orderEntry: Window
– this object will get an order from a customer

• anOrder: Order
– receives an order from a customer (via orderEntry object)

• orderSet: ItemList
– an object is a list of items is to be processed

24 August, 2006 Information System Design IT60105, Autumn 2006

 Sequence Diagram in OLP System

• stockist: InventoryManage
– object responsible for checking stock, supply stock, request for
inventory etc.

• :OrderInfo
– containing the orders information in a queue

• confirmMessage: Message
– message objects for sending confirmation message

• The sequence diagram for Process Order use case can be drawn as follows.

24 August, 2006 Information System Design IT60105, Autumn 2006

 Example: Sequence Diagram of “Process
Order” use case in OLP System
o r d e r E n t r y : a C n uO s r t do em r :eo rOr d r e d r e S r e t : s I t eo mc k L i si st : t I n v e n : t o O r yr d M e r a I n n a f

c r e a t e ( ) * s e t O r d e r ( )

s t a t u s = i n v e n t o r y C h e c k ( )
[ s t a t u s = F A L S E ]
e n q u e u e O r d e r ( )

a v a i l a b l e =
c h e c k S u p p l y ( )

[ a v a i l a b l e = T R dU e E Q ] u e u e ( )
r e p l y E s t i m a t e ( )
r e p l y E s t i m a t e ( ) e s t i m a t e O r d e r ( )

a c c e p t ( )

c o n f i r m O r d e r : M e s s a g e
a c c e p t ( )

c o n f i r m ( )
c o n f i r m ( )

24 August, 2006 Information System Design IT60105, Autumn 2006

 Use of Sequence Diagram
• From the sequence diagram of “Process Order” use case, it is evident that
the diagram is easy to understand and has immediate appeal. This is the
great advantage of the sequence diagram

• However, in some situation, there may be a lot of small methods in

different classes, and at times it can be very tricky to figure out the overall
sequence of behaviors. in fact, so many details can be resolved during
coding only

• The development of sequence diagram would help a designer in

determining the responsibilities of the different classes. i.e. what methods
should be supported by each class, sequence of message passing etc.

24 August, 2006 Information System Design IT60105, Autumn 2006

 Sequence Diagram and Boundary Classes

• Boundary classes are added to sequence diagrams to show the interaction with the
user or another system. The purpose of showing boundary classes on a sequence
diagram is to capture and interface requirement

Example
: C u s t o m e r : c r e d i t C a r d C h e c k

S e q u e n c e d ia g r a m o f
P r o c e s s O r d e r
( e x t e n d e d v e r s io n )

– In the above example, customer and creditCardChecker are at the boundaries,

showing the interface of the sequence diagram with others.

24 August, 2006 Information System Design IT60105, Autumn 2006

 Collaboration Diagram

24 August, 2006 Information System Design IT60105, Autumn 2006

 What is an Object Diagram
• The second form of the interaction diagram is the
collaboration diagram

• A collaboration diagram shows both the structural and

behavioral aspects, explicitly.
– The structural aspect of a collaboration diagram consists of object and
the links existing between them

– The behavioral aspect is described by a set of messages exchanged

among the different collaborations

• In the collaboration diagram, an object is also called

collaborator
24 August, 2006 Information System Design IT60105, Autumn 2006
 Basic of Collaboration Diagram
• A collaboration diagram contains the following things:

– Objects drown as rectangles

– Links between the objects shown as lines connecting as lines

connecting the linked objects

– Messages shown as text and an arrow that points from a client object to
a respondent object

• Let us consider an example of a collaboration diagram in

Process Order use case of the OLP system

24 August, 2006 Information System Design IT60105, Autumn 2006

Example: Collaboration Diagram
1 : c r e a t e ( )
o r d e r E n t r y : C u s t o m e r

a n O r d e r : O r d e r
2 : * [ f o r a l l i t e m i n O r d e r ]

s e t O r d e r ( )
3 : s t a t u s = i n v e n t o r y C h e c k ( )
o r d e r S e t : I t4 e : ma v aL i l i a s b t l e = c h e c k S u p p l y ( )

: I n v e n t o r y M a n a g
[ s t a t u s ]
n e w [ a v a i l a b l e ]
n e w

: C o n f i r m O r d e r : O r d e r I n f o

24 August, 2006 Information System Design IT60105, Autumn 2006

 Note: Collaboration Diagram
• In collaboration diagram, the sequence indicated by
numbering the messages

• Here, we have used the simple numbering scheme. The UML

also allows decimal scheme [as in DFD] to document the
hierarchical messaging

• Example ??

24 August, 2006 Information System Design IT60105, Autumn 2006

 Sequence Diagram vs. Collaboration Diagrams

• There are two basic features by which Sequence

diagram differs from the Collaboration diagram
– Object life time
• In sequence diagram, there is a object line represent the existence
of an object over a period of time. There is no object life time in
collaboration diagram

– Focus of control
• In sequence diagram, there is the focus of control to show the
period of time during which object is performing an action. There
is no focus of control in collaboration diagram

24 August, 2006 Information System Design IT60105, Autumn 2006

 Sequence Diagram vs. Collaboration Diagrams

• Sequence diagram provides a way to look at scenario in a time

based order – what happen after what etc. Customer easily can
read and understand this type of diagram. Hence, they are very
useful in the early analysis phases as well as in coding phase

• Collaboration diagram tend to provide the big picture for a

scenario since the collaborations are organized around the
object links to one another. These diagrams seem to be used
more in the design phase of development

24 August, 2006 Information System Design IT60105, Autumn 2006

 Problems to Ponder
• Obtain sequence diagrams for the following
– Heap sort
– Binary Search
– Dinning Philosophers problem
– Tower of Hanoi problem
– “Login Verification” procedure
– All use cases in OLP

• Given a sequence diagram draw a collaboration diagram

and vice-versa

24 August, 2006 Information System Design IT60105, Autumn 2006