1. Unified Modelling Language
Interaction Diagrams

2. Interaction Diagrams
Interaction diagrams are used to model the dynamic aspects of a software system
They help you to visualize how the system runs.
An interaction diagram is often built from a use case and a class diagram.
The objective is to show how a set of objects accomplish the required interactions with an actor.

3. Elements found in interaction diagrams
Instances of classes
Shown as boxes with the class and object identifier underlined
Actors
Use the stick-person symbol as in use case diagrams
Messages
Shown as arrows from actor to object, or from object to object

4. Creating interaction diagrams
You should develop a class diagram and a use case model before starting to create an interaction diagram
There are two kinds of interaction diagrams:
Sequence diagrams
Communication diagrams

5. Sequence Diagrams

6. Sequence Diagrams Dynamic Model relating use cases and class diagrams
Illustrates how objects interacts with each other
Shows time ordering of interactions
Generally a set of messages between collaborating objects
Can model simple sequential flow, branching, iteration, recursion and concurrency

7. member: LibraryMember
A Sequence Diagram
member: LibraryMember
book:Book
:Book Copy
borrow(book)
ok = mayBorrow()
[ok] borrow(member)
setTaken(member)

8. member: LibraryMember
A Sequence Diagram
X-Axis (objects)
member: LibraryMember
book:Book
:Book Copy
Object
borrow(book)
Life Line
ok = mayBorrow()
Y-Axis (time)
message
Activation box
[ok] borrow(member)
setTaken(member)
condition

9. 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
Name classes consistently with your class diagram (same classes)
Include instance names when objects are referred to in messages or when several objects of the same type exist in the diagram

10. Messages between objects
A message is represented by an arrow between the life lines of two objects
A message call is a request from the object sending the message to the object receiving the message. The request is for the receiver to carry out one of its (the receiver’s) operations
Self calls are also allowed
The time required by the receiver object to process the message is denoted by an activation-box
A message is labeled at minimum with the message name
Arguments and control information (conditions, iteration) may be included

11. Messages between objects
dashed arrow back indicates return
Return Values
Optionally indicated using a dashed arrow with a label indicating the return value.
Don’t model a return value when it is obvious what is being returned, e.g. getTotal()
Model a return value only when you need to refer to it elsewhere, e.g. as a parameter passed in another message.
Prefer modeling return values as part of a method invocation, e.g. ok = isValid()

12. Object Creation
An object may create another object via a <<create>> message. :A :B
<<create>>
Constructor
Preferred :A
<<create>> :B

13. Object Destruction
An object may destroy another object via a <<destroy>> message.
An object may destroy itself.
Avoid modeling object destruction unless memory management is critical. :A :B
<<destroy>>

14. Control information Condition Iteration
syntax: ‘[‘ expression ’]’ message-label
The message is sent only if the condition is true
example:
Iteration
syntax: * [ ‘[‘ expression ‘]’ ] message-label
The message is sent many times to possibly multiple receiver objects.
[ok] borrow(member)

15. The syntax of expressions is not a standard
Control Information (Cont.)
Iteration examples:
:CompoundShape
:Shape
:Driver
:Bus
draw()
*draw()
*[until full] insert()
The syntax of expressions is not a standard

16. Indicating selection and loops
frame: box around part of a sequence diagram to indicate selection or loop
if -> (opt) [condition]
if/else -> (alt) [condition], separated by horiz. dashed line
loop -> (loop) [condition or items to loop over] [
balance
<> ]
opt
<
100 . 00
> =
alt
loop

17. Sequence Diagram (Basics)
Object : Class or Actor
Lifeline
name
Focus of
Control/
Activation
message
Object
Destruction/
Termination X
<<create>>
<<destroy>>

18. Example 1

19. Example 2

20. Example 3

21. Example 4

22. Example 5

23. Collaboration (or Communication) Diagrams

24. Collaboration
Class diagrams indicate what classes are part of our system, what they offer, how they relate, but they don’t tell us how they communicate
Collaboration diagrams show how objects interact and their roles
The elements of a Collaboration diagram are essentially the same as that of a Sequence diagram
Actually they are considered as a cross between class and sequence diagram
Sequence Diagrams are arranged according to Time
Collaboration Diagrams represent the structural organization of object

25. Elements of a Collaboration diagram
Element and its description
Symbol
Object: The objects interacting with each other in the system. Depicted by a rectangle with the name of the object in it, preceded by a colon and underlined.
                         
Relation/Association: A link connecting the associated objects. Qualifiers can be placed on either end of the association to depict cardinality.
                                      
Messages: An arrow pointing from the commencing object to the destination object shows the interaction between the objects. The number represents the order/sequence of this interaction.
                             

26. Symbols used in collaboration diagrams

27. Example Class diagram for “Courseware Management System”

28. Example Sequence diagram for the"Manage course information" flow

29. Example Collaboration diagram for the "Manage course information" flow

30. When to Use Interaction Diagrams
You should use interaction diagrams when you want to look at the behavior of several objects within a single use case
Interaction diagrams are good at showing collaborations among the objects
If you want to look at the behavior of a single object across many use cases, use a state diagram

31. How to choose between using a sequence or communication diagram?
Sequence diagrams
Make explicit the time ordering of the interaction.
Use cases make time ordering explicit too
So sequence diagrams are a natural choice when you build an interaction model from a use case.
Make it easy to add details to messages.
Communication diagrams have less space for this
Communication diagrams
Can be seen as a projection of the class diagram
Might be preferred when you are deriving an interaction diagram from a class diagram.
Are also useful for validating class diagrams.