Information System Design: Interaction Diagrams

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 :

c l a

S

s s

t u

da ue nt u t m

n

a o

v e

24 August, 2006

m b

je

n

0

6

e

a

c t

r t i v a

:

n

a

m

l - d

a

s h

C

n

o

o

n

u

r: s C e Mo

y m

o

a

t t a

u

u g r rs e

s

o

b

c h

e

d

je

c t

e

e

d

l i n

e

s

Information System Design IT60105, Autumn 2006

t o

o

b

je

c t

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

o

b a

d

e n

t

je c t s t a r t s a c t i v i t y h e r e

n

a o L

i f e

t i m

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

o b je c t h e r e

a

p

p

e

a

r s

n

e

a u o

24 August, 2006

a

n

b

je

c t

e

x p

i r e

t u s

m h

e

n

0

6

:

C

r e

Information System Design IT60105, Autumn 2006

o

u

r s e M

g

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

1

r e

t u

q

u

d a e u n t ut m

e

s t E

n

r o

n

0

6

n

f i r m

E

n

r o

w b

24 August, 2006

o y

o b je c t a p a s s i n g

o

r c h

( )

u

r s e M

g

r

a

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

3

T

C

l l ( ) 2 s e

c o

:

r e m

c o m m e s s a g

u n e s

i c a

t i n

Information System Design IT60105, Autumn 2006

g

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

r e

[ v a g

q

d a e u n t ut

u

e

s t E

c c a o n n t ]f i r m e

t C

o

u

m

n

r o

n

0

6

n c o

d

E

n

r s e

( )

t h i s m n d i t i o n

C

o

r c h

( )

r o

s e a l l ( )

g

e s s a g e i f i s t r u se e n d

e

t C

t h

i s

m o

24 August, 2006

u

r : s eC M o

ug r r s e

l l ( )

*

s e

:

b

o

u

e s s a je c t s

r s e

g

e

Information System Design IT60105, Autumn 2006

( )

s

t o

a

l l

c o

u

r

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

b e g i n s e s s i o

R

e

a b d :se e r s s i o

c a r d

I n f 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

( )

n [ ! v

a l i d

A

T

M

c a r d

]

e j e c t ( ) c h e c k [ s t a t u

s . i s S

r e t a i n [ s t a t u

s t a t u l e n ]

t o

s . c l o s e A e j e c t ( )

c c o

v

u

n

<

]

t ] & I N

a l u

e P

&

a l i d P I N ] e j e c t ( ) d i s p

t r y

4

( ) P

I N

( )

I N v

24 August, 2006

( )

( )

r e a d

x

a r d

s

[ ! v a l i d P I N r e q u e s t P

[ ! v

C

l a y H

e r i f y P e l l o

( )

I N

( )

x

x

x x Information System Design IT60105, Autumn 2006

a

n

k

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

b

e b r: I n

e g

i n

t e r f a c e M c : Rg

s e s s i o

r e g

n g

i n

p

u

t T

y p

e t C

u

s t o

[ C

p

u

t S

t a f f D

d

24 August, 2006

u

t O

t h

u

e s t ( )

s t o

m

e r T

y p

g dr : S

y s t e m

M

g

r

e ( )

m

e r T

y p

e

=

r e a d

D

a t a ( )

s t o m e r T y p e = s t a f f ] e t S t a f f D a t a ( ) 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

d

p

u

e q

M

u

g

d

i n

R

n

e ( ) C

i n

n

re g

[ s t a t u s 1 i s p l a y M [ s t a t u s 2 i s p l a y M

i s p

l a y M

= s g = s g s g

i n v ( R e [ s t e x i as

a l i d g n . s t a t tt ] u s

( R

e g n [ s t a ( R c e 1 g =n . u p d

[ C u s t o m e r T y p g e t O t h e r D a t e r D a t a ( ) c d = o t h e r C u s t s [ s t a t u s 2 = e x d i s p l a y M s g ( R c d i s p l a y M s g ( R e

e = a ( )

. t u cs

S

t a f f ( c d

] f a i l ) s 1 = 2 = c h u

f a s ru e

2

v a l i d e c k E

] x

i s t ( c d

t h

o m e r D t a t u s 2 i s t ] e [ sg t n a . t uf a s 2 = c r e g n . s u c u p d a t e

)

i l )

= n o t E x i s t ] a t e C e r ( c d c c e s s u) s t o m a t e R e c o r d ( c 1 ) o

)

)

e r ]

=

a t a ( ) c h e c k

E

x

i s t ( c d

n o t E x i s t ] i2 l ) = a t e C u s t o m e r ( c d c e s s ) R e c o r d ( c 2 )

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 c r e

a

t e

( )

*

s e

t O

r d

e

I n

v

h

e

e n : t o O r yr d M e r a I n n a f

r ( ) s t a

t u

s

=

i n

v e

n

t o

r y C

c k ( )

[ s t a t u s = e n q u e u e

F O

a v a i l a b l e c h e c k S u p

r e

p

l y E

s t i m

a

c c e

p

a

r e p t e ( )

l y E

s t i m

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

a

a

c c e

p

24 August, 2006

f i r m

n

f i r m

O

r d

e r : M

t ( )

c o n

u

e

L r d

S e

E ] r ( )

= p

l y ( )

( )

t ( )

c o

c o

e

A

n

f i r m

( )

( )

Information System Design IT60105, Autumn 2006

e s s a g

e

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

S

e r

: c r e d

i t C

e q u e n c e d ia g r a m 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

a r d

o

C

h

f

)

– 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

e c k

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

o

r d

e r E

n

t r y : C

u

:

c r e

s t o

a

m

t e

e r a n

2

:

*

[ f o s e

o

r d

e r S

r

t O 3

:

e t : I t4 e : ma

a

l l

r d

i t e e

m

: C 24 August, 2006

o

n

f i r m

O

i n

s t a t u s = v aL i l i a s b t l e

O

r d

e r

e

r d

e r

r ]

v e n t o r y C h e c k ( ) c h e c k S u p p l y ( )

v

e n [ a

r d

e r : O

i n =

s ]

O

r d

r ( )

: I n [ s t a t u n e w

( )

: O

r d

t o

r y M

v a i l a n e w

e r I n

Information System Design IT60105, Autumn 2006

b

a n l e

f o

]

a g

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

the

sequence

indicated

by

• 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