1. Interaction View

2. Collaboration
Description of interacting behaviors between a collection of objects
This behavior is partly derived from the static relationships (particularly association) defined in the class diagram
Subclasses may have an interacting behavior that is different from the same behavior of a superclass
Due to redefinition of methods in subclasses
interacting behaviors objects
description of the unity of data structures, control flow and data flow in the whole system
C-S 446/546

3. Examples of collaborations
ATM system
A user object interacts with an account object
Inventory system
Inventory manager object interacts with warehouse object
Course registration system
A student object interacts with a course object
Investment Records System ?
C-S 446/546

4. Interaction
A set of messages or stimuli exchanged between objects in a collaboration
Thus, a collaboration defines one or more interactions
The goal of describing a collaboration is to accomplish a particular functionality defined in the requirements
Examples
Completion of the withdrawal process in ATM is a collaboration
As part of this collaboration, a user object sends a message to an account object and the account object sends a message back to the user object
Messages or stimuli
C-S 446/546

5. Message A one-way communication between objects
synonymous to “data flow”
A message may have parameters
A message from one object generally corresponds to requesting the service of a method in the same object or in another object
A message may be synchronous (waiting for response) or may be asynchronous (continues its execution without waiting for a response)
C-S 446/546

6. Examples for message
A user object in an ATM system sends the following message to an account object
“withdraw (amount : double)”
This is a synchronous message since the user object waits for a response back from the account object indicating the success or failure of withdrawal operation
A controller object in a Traffic Light system sends a message to a light object to change its status (ON  OFF or OFF  ON)
This is an asynchronous message since the controller object does not wait for a response back from the light object; instead, it continues its work
C-S 446/546

7. Stimulus A stimulus is a signal sent from one object to another
synonymous to “control flow”
A stimulus may have parameters
A stimulus from one object generally corresponds to initiating an action in another object
It is generally asynchronous
C-S 446/546

8. Sequence Diagram

9. Sequence diagram A two-dimensional chart that describes collaborations
Each sequence diagram describes a particular scenario
E.g., a sequence diagram can describe successful withdrawal operation
Another sequence diagram can describe failure of withdrawal operation due to insufficient funds
It is also possible to describe both scenarios in one sequence diagram
C-S 446/546

10. Sequence diagram – basic syntax
Obj1 : ClassA
: ClassB
Obj2 : ClassC
method-in-B()
message
return
stimulus
message to self
lifeline
return
[condition] method(parameters)
return
concurrent method()
concurrent method()
C-S 446/546

11. Sequence diagram - semantics
Rectangular boxes on the top indicate objects
The dotted vertical line indicates the life line of the corresponding object
Rectangular boxes on the dotted vertical line indicate the duration in which the corresponding object is active; the object is idle otherwise
A solid arrow with solid arrowhead indicates a message
A solid arrow with thin arrowhead indicates a stimulus
A dashed arrow indicates return of control
C-S 446/546

12. Sequence diagram – semantics (continued)
Messages/stimuli may be augmented with conditions
Messages/stimuli can be concurrent
start from one object and send messages or signals to more than one object at the same time
The vertical dimension indicates time axis
A message ‘Y’ placed below a message ‘X’ in a sequence diagram indicates that message ‘X’ is sent before message ‘Y’
C-S 446/546

13. Sequence diagram – semantics (continued)
Objects with dashed vertical line for the entire diagram have lifeline for the entire scenario
These objects are assumed to be already created before this scenario starts and assumed to exist even after the scenario ends
Objects with short life span within a scenario can be shown differently (see the next diagram)
There is no ordering required among the placement of objects on the horizontal line
A designer may choose the ordering for the convenience of drawing the diagram
C-S 446/546

14. Additional semantics (not shown in the diagram)
Every sequence diagram must have a name
Usually chosen to represent the scenario that the diagram describes
UML tools use the following notation for representing the name of the sequence diagram; usually appears on top left corner
Reserved word
sd Name of the sequence diagram
C-S 446/546

15. Sequence diagram – extended syntax
: ClassA
constructor of B ()
: ClassB
constructor of C ()
: ClassC
message to self
return
[condition] method(parameters)
return X
C-S 446/546

16. Sequence diagram – semantics (continued)
The creation of an object is shown by the vertical displacement of the object from the top of the diagram. The object is placed at the point of creation
See the creation of objects from class A and from class B
The termination of an object can be shown by placing an “X” at the bottom of its life line
See the destruction of the object from class C
C-S 446/546

17. Example – ATM system Scenario
A user object sends a message to the accounts database to withdraw an amount from an account. The database validates the account number. It then creates a temporary copy of the account. The account first validates the amount and then updates the balance. The successful completion of the withdrawal process is informed to the user object. The account object continues to exist waiting for further transactions
Model the successful withdrawal process
C-S 446/546

18. : User : Accounts DB : Account Withdraw (act, amount)
Validate Account (act)
: Account
Create (act, bal)
Withdraw (amount)
Validate Amount (amount)
Update (amount)
return
return
C-S 446/546

19. Exercise
Discuss the changes to be made to this diagram for the following changes in the problem
There is an ATM system object. The user object communicates only with ATM system object which in turn communicates with the database object. The ATM system object creates the account object.
Scenario 2
The user object attempts to withdraw more than the balance which is not permitted.
Scenario 3
The user object attempts to withdraw more than the balance which is now permitted but only for an account that has some privileges
C-S 446/546

20. Example – Course registration system
Scenario
A student object checks the availability of seats in a course. If available, it sends a message to register. The course object checks for the prerequisites first. Upon acceptance, the course object returns the message back to the student object and at the same time informs the account object to bill the student. The account object then communicates with the student to get the payment for the course.
The following diagram shows a successful course registration process
C-S 446/546

21. :Student :Course :Account check seat availability() return
register (id, prereqs)
check prerequisites(prereqs)
update enrollment (id)
return
initiate payment (id, course number)
request payment (course number, amount)
update student record (id, course number, amount)
payment (id, course number, amount)
return
C-S 446/546

22. Exercise
Draw the sequence diagrams for various scenarios in the Warehouse example
Draw the sequence diagrams for various scenarios in the job posting example
A company posts job openings online. Job seekers must apply for these jobs online. The company will process the applications and calls eligible job seekers for interview. Upon successful completion of an interview, a job seeker may be hired and the corresponding job opening will be deleted from the company’s web site.
C-S 446/546

23. Sequence diagram – extended syntax
:Computer
:PrinterServer
:Printer
:Queue
Print(file)
Print(file)
Reserved word
alt
[printer free]
Print(file)
Two mutually exclusive conditions
Store(file)
[printer busy]
C-S 446/546

24. Depositing the same amount into several accounts
Specifying loops
: User
: Accounts DB
Deposit (act[], amount)
Validate Account (act[i])
Loop (1..act.length)
Reserved word
: Account
Create (act[i], bal)
Deposit(amount)
Delete()
return
Depositing the same amount into several accounts
C-S 446/546

25. Concurrent and time-based messages and stimuli
Obj1 : C1
Obj2 : C2
Obj4 : C4
[x > 0] Op1(x)
[t = 0]
Obj3 : C3
[y >= 0] Op3(y)
[x <= 0] Op1(x)
[for each y] Op2(y)
return
return
return
return
[t <= 30]
Op4( ) X
Op5( )
C-S 446/546

26. Concurrent messages / stimuli - semantics
an object can send two messages / stimuli to two different objects at the same time
concurrent execution
there may be a condition on each of these messages / stimuli but they can be totally different
the tail end of these two messages / stimuli coincide at the originating object
the arrow heads may physically be on different horizontal levels but logically they are at the same time line (horizontal level)
see “Op4() and Op5()” in the diagram
C-S 446/546

27. Time-based messages / stimuli- semantics
a message can be split into two, leading to two destination objects with mutually exclusive conditions
see “Op1(x)” in the diagram
a lifeline can be split into a side track for a specific duration to indicate mutually exclusive situations
see “Obj4” in the diagram
iterations can be specified using a condition at the beginning of a message / stimulus
see “Op2(y)” in the diagram
timing constraints can be added onto the messages / stimuli or on the vertical time axis
C-S 446/546

28. P1 : Phone : Exchange P2 : Phone 1 : lift receiver 2 : dial tone
2.receiveTime – 1.sendTime < 1 sec
1 : lift receiver
2 : dial tone
3.receiveTime – 2.sendTime < 10 sec
3 : [for N digits] dial number
3.dialTime < 5 sec
4 : route the call
4.completionTime < 5 sec
ringing tone
signal to ring the bell
answer the phone
< 1 sec
stop ringing tone
stop signal to ring the bell
converse
C-S 446/546

29. Observations
timing constraints placed outside the lifeline or activation bars
conditions may be applied to specific messages or stimuli
these messages or stimuli are labeled for this purpose
see the stimuli with labels 1,2,3 and 4
concurrent messages are shown on the same time line
see stimuli “ringing tone” and “signal to ring the bell”
a slanting message / stimulus indicates that it takes some specified duration to complete the action
see the stimulus “route the call” in the diagram
C-S 446/546

30. Other extensions Reference
A sequence diagram can specify a commonly occurring scenario and then can be referenced in another (or several) sequence diagram(s)
Objects having recursive operations can be shown on the sequence diagram
See the book or UML 2.0 manual for additional syntax
C-S 446/546