Professional Documents
Culture Documents
Information System Design: Interaction Diagrams
Information System Design: Interaction Diagrams
Information System Design: Interaction Diagrams
IT60105
Lecture 08
Interaction Diagrams
• Collaboration diagrams
– Collaboration diagrams
• 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
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
• 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
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
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
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
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
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 )
• 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
• 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.
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 ( )
• 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 )
– Messages shown as text and an arrow that points from a client object to
a respondent object
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
• Example ??
– 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