This document discusses interaction diagrams and design decisions when modeling object interactions. It covers sequence diagrams, collaboration diagrams, design by contract, starting dynamic modeling, working with interaction diagrams, and making design decisions. Key points include that sequence diagrams show message flow over time while collaboration diagrams show object links, interaction diagrams help model class behavior, CASE tools may convert between the diagram types, and the document provides examples and best practices for modeling object interactions and relationships.

1. Arab Open University
2nd
Semester, 2006-2007
M301
Unit 4.4
Interactions
reem.attas@arabou.org.sa

2. Reem AlAttas © 2
Topic Road Map
 Design by Contract
Starting Dynamic Modeling
Working with Interaction Diagrams
Design Decisions

3. Reem AlAttas © 3
Design by Contract
The process of developing software based
on the notion of a contract between
objects.
Assertions:
 Pre-conditions.
 Post-conditions.
 Invariants.

4. Reem AlAttas © 4
Example

5. Reem AlAttas © 5
Topic Road Map
Design by Contract
 Starting Dynamic Modeling
Working with Interaction Diagrams
Design Decisions

6. Reem AlAttas © 6
Interaction Diagrams
Sequence diagrams and collaboration
diagrams (known collectively as
interaction diagrams) are notations to help
make and record decisions relating to the
behavior defined for each class.

7. Reem AlAttas © 7
… Interaction Diagrams
A sequence diagram shows the flow of
messages from object to object as time
passes by.
A collaboration diagram shows the objects
and their links (the structure).

8. Reem AlAttas © 8
Sequence Diagram (Check In)

9. Reem AlAttas © 9
Main Elements
Objects  rectangles.
Messages  arrows.
Object’s lifeline  dashed line.
Indication that a particular object is ‘active’
for a given period of time  long rectangle
overlaid on that object’s lifeline.

10. Reem AlAttas © 10
Notes
The return of flow of control from the
receiver is not normally shown.
If one object sends a message to another,
there should be an association between
the classes and that association requires
managing.

11. Reem AlAttas © 11
Topic Road Map
Design by Contract
Starting Dynamic Modeling
 Working with Interaction Diagrams
Design Decisions

12. Reem AlAttas © 12
CASE Tools
Some CASE tools can generate a
collaboration diagram from a sequence
diagram and vice versa  Find out if
StarUML can do this?

13. Reem AlAttas © 13
Collaboration Diagrams

14. Reem AlAttas © 14
Numbering System
Why not use a simple numbering system
1, 2, 3 ?

15. Reem AlAttas © 15
1st
Message Sequence

16. Reem AlAttas © 16
2nd
Message Sequence

17. Reem AlAttas © 17
… Numbering System
A message number always contains as its
prefix the number of the message that
gave rise to it.

18. Reem AlAttas © 18
Comparison
 A collaboration diagram shows the links between
objects (the local structure), whereas a
sequence diagram does not. In a sequence
diagram, the message arrow implies a link
between two objects.
 The time ordering of messages is clear in a
sequence diagram. Some form of numbering is
needed in a collaboration diagram to show which
message comes before or after another.

19. Reem AlAttas © 19
Parameterized Interactions

20. Reem AlAttas © 20
Creation and Deletion in Sequence
Diagram

21. Reem AlAttas © 21
Creation and Deletion in Collaboration
Diagram
 {new} and {destroyed}.
 If you want to show an object’s complete lifecycle in one
interaction, you can use the {transient} constraint.
Otherwise you should treat creation and destruction as
two separate interactions and show them on two
separate collaboration diagrams.

22. Reem AlAttas © 22
Topic Road Map
Design by Contract
Starting Dynamic Modeling
Working with Interaction Diagrams
 Design Decisions

23. Reem AlAttas © 23
Naming the Link Manipulation Methods

24. Reem AlAttas © 24
Indirect Messages
 Suppose that the company needs to collect
information about the ages of all its employees.

25. Reem AlAttas © 25
Fork

26. Reem AlAttas © 26
Cascade

27. Reem AlAttas © 27
Law of Demeter
The Law of Demeter states that a method,
say m, in a class A should not refer to
another class, say B, unless B is the class
of:
 An instance variable used in the method m.
 A parameter to the method m.
 An object created in the method m.
 A global variable used in the method m.

28. TMA4 – Q4

29. Thank You!