The document outlines the purpose and types of interaction diagrams, specifically focusing on sequence and collaboration diagrams, which illustrate how objects interact within a use case. It details components such as object lifelines, message types, return values, and the modeling of object creation and destruction. Additionally, it highlights the advantages of using sequence diagrams over coding, their visualization capabilities, and mechanisms to represent selection, loops, and concurrency.

1. OOAD
Sequence Diagrams

2. Interaction Diagrams
 Interaction diagrams describe exemplary
how groups of objects collaborate in some
behavior.
 An interaction diagram typically captures the
behavior of a single use case.
 Interaction diagrams do not capture the
complete behavior, only typical scenarios.

3. Types of Interaction Diagrams
There are two types of interaction diagrams:
 Sequence diagrams emphasize the order or
concurrency of the interactions.
 Collaboration diagrams emphasize the
interacting objects.

4. Role of Interaction Diagrams in UML

5. Interaction Diagrams and Use Cases
Behavior of the “order” use case:
A customer orders several products.
The (sub-)orders (“order lines”) for each product are prepared
separately.
For each product check the stock.
• If the product is in stock, remove requested amount from stock.
• If the product stock falls below a predefined level, reorder it.

6. Object
 Object naming:
myBirthdy
 syntax: [instanceName][:className]
:Date
 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.
 The Life-Line represents the object’s life
during the interaction

7. Messages
 An interaction between two objects is
performed as a message sent from one
object to another (simple operation call,
Signaling, RPC)
 If object obj sends a message to another
1
object obj2 some link must exist between
those two objects (dependency, same
objects)

8. Messages (Cont.)
 A message is represented by an arrow between the
life lines of two objects.
 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.

9. 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()

10. Synchronous Messages
 Nestedflow of control, typically implemented
as an operation call.
 The routine that handles the message is
completed before the caller resumes execution.
:A :B
doYouUnderstand()
return
Caller
yes (optional)
Blocked

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

12. 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>>

13. Sequence Model (1)

14. Sequence Model (2)

15. Sequence Model (3)

16. Sequence Model (4)

17. Why not just code it?
 Sequence diagrams can be somewhat close to the code
level. So why not just code up that algorithm rather than
drawing it as a sequence diagram?
 a good sequence diagram is still a bit above the level of the real code (not
EVERY line of code is drawn on diagram)
 sequence diagrams are language-agnostic (can be implemented in many
different languages
 non-coders can do sequence diagrams
 easier to do sequence diagrams as a team
 can see many objects/classes at a time on same page (visual bandwidth)
17

18. Lifetime of objects
 creation: arrow with
'new' written above it
 notice that an object
created after the start of
the scenario appears
lower than the others
 deletion: an X at bottom
of object's lifeline
 Java doesn't explicitly
delete objects; they fall
out of scope and are
garbage-collected
18

19. 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 opt [balance 0]
items to loop over] [balance 100.00]
<> alt <
[balance 100 ]
>= .00
loop [balance 0]
<
19

20. Concurrent Processes and Activations

21. Concurrency in Sequence Diagrams (1)

22. Concurrency in Sequence Diagrams (2)

23. Concurrency in Sequence Diagrams (3)

24. A Successful Bank Transaction
Reference: Object-Oriented Analysis and Design
J.W. Schmidt, F. Matthes, TU Hamburg-Harburg

25. A Failing Bank Transaction
Reference: Object-Oriented Analysis and Design
J.W. Schmidt, F. Matthes, TU Hamburg-Harburg

26. Sequence diag. from use case
26