Object Oriented Analysis and Design

Interaction Diagrams

1
Methods
 As part of object oriented design,
you need to specify the methods
which will be associated with each
class
 Method names start with a verb
 Such as: get, set, create, calculate,
display, obtain, append, delete, etc.
 And end with the noun (often the
type of data or object involved)

2
Methods Form
 [visibility] name ([parameter-list]) ':'
[return-type] [{property-string}]
 Each parameter is defined in the
same manner used to define
attributes, a name and a data type
in the format name:datatype.

3
Methods Form
 When using more than one
parameter, simply separate the
"name : datatype" pairs with
commas.
 example (new_start_date : Date,
new_duration : int).

4
Getters and Setters
 Two of the most common methods
are to read the value of a variable
(get), or assign the value of a
variable (set)
 getQuantity would read the value of
some field Quantity
 setQuantity would assign or set the

value of Quantity, ignoring its previous

value (if any)

5
Interaction Diagrams
 Interaction diagrams primarily
consist of two types
 Sequence diagrams
 Collaboration (or communication)

diagrams
 Either type describes ONE
USE CASE
 Unlike the class diagram, which
pertains to the whole system

6
Interaction Diagrams
 Interaction diagrams describe how
one or more actors interact with the
system to perform a use case
 The development of interaction
diagrams motivates the
development of methods (i.e. making
them up), which later become part of
the class diagram

7
Returns from the System
 In response to messages, the
system often provides some sort
of data in return
 This can be explicitly shown by a
dashed line
 The line is labeled with the type of data
provided by the system, such as
totalPrice or discountedValue
 Returns generally point to an interface
object, so an actor can see the data

8
Returns from the System
 Return messages often fulfill a
system response identified in the
use case description (hint!!!)
 If the use case states ‘system displays
the total amount due’, then some
return message will probably need to
contain totalAmountDue (or something
like that)

9
Method versus Message
 We often use ‘method’ and
‘message’ interchangeably
A method is code which belongs to
some object
 A message is the command to execute

a method

10
Identifying Objects
 Interaction diagrams can identify
specific objects (not just classes)
 Name objects and classes using
the format
object:Class
 For example, employee:Person means
there is an object “employee” of the
Class “Person”

11
Identifying Objects
 Notice the Class name is
capitalized, but the object name is
all lower case, and the phrase is
underlined
 If you don’t need to specify the
object name, just use the format
Class

12
Identifying Actors
 Sequence diagrams do not show
the primary actor explicitly
 EarlierUML (versions 1.x) showed the
primary actor in the form of the stick
figure we saw in the use case diagram
 Often, the first message in an
interaction diagram is a direct result
of some action by the primary actor

13
Sequence Diagram

14
Sequence Diagram
 A sequence diagram shows the
messages needed to perform a use
case, in chronological order
 Time is assumed to advance as
you move down the page (top
to bottom)
 Steps in a sequence diagram often
(not always) correspond to the steps
in a scenario for that use case

15
 Generic Sequence Diagram
:ClassA :ClassB :ClassC :ClassD

msg1()

msg2()

msg3()

msg4()

msg5()
msg6()

No returns are shown

Notice that messages may go right-left as well as left-right

16
 Notation for Sequence Diagram
 Represents an object in the
system or one of its
components.
 Each class or object is
Object2
identified in a box, with a
dashed line extending below
it
 When an object is in use, a
Activation bar narrow rectangle can be
added over the dashed line
 This rectangle is an activation
X bar; it shows the lifespan of that
object
17
Notation for Sequence Diagram
 Actor:
Represents an external person or
entity that interacts with the
system.

18
Notation for Sequence Diagram

19
Notation for Sequence Diagram
 A boundary is a class that represent,
typically a user interface screen. It is
used to illustrate screens. It is the
View in the Model-View-Controller
pattern.
 A control is a class that represents a
controlling entity or manager. A
control organizes and schedules other
activities and elements. It is the
controller of the Model-View-
Controller pattern

20
Notation for Sequence Diagram
 An entity is a store or persistence
mechanism that captures the
information or knowledge in a
system. It used to illustrate
database items .
It is the Model in the Model-View-
Controller pattern.

21
Notation for Sequence Diagram
 Lifeline:
An object and shows all
its points of interaction
with other objects in
events that are
important to it. Lifelines
start at the top of a
sequence diagram and
descend vertically to
indicate the passage of
time. Interactions
between objects are
drawn as horizontal
direction arrows
connecting lifelines.

22
Notation for Sequence Diagram
 Synchronous Message:
 The sender sends the message
 The recipient accepts the message, and

notifies the sender with a message

result.
 The sender accepts the message result.

23
Notation for Sequence Diagram
 Asynchronous Message:
 The sender sends the message.
 The sender does not wait for the return

of the message, it immediately

continues execution.
 The recipient may or may not send a

reply.

24
Notation for Sequence Diagram
 A found message is used when the
source of the message is outside
the scope of the current model, so
how and by what object the
message is generated simply don't
matter to the model. The only
relevant information is that the
message needs to be received and
handled by the modeled application
or system

25
Notation for Sequence Diagram
• Self-reference message:
Its an object calling itself, you draw
a message as you would normally,
but instead of connecting it to
another object, you connect the
message back to the object itself.

26
Object Creation and Deletion
 A special notation is used for the
creation of an object during a use
case
 The message points to the new object,
and the message is labeled ‘new’ or
‘create’
 When an object is no longer needed,
it is deleted
 Message is labeled ‘close’ or ‘delete’

27
Object Creation and Deletion

28
Decisions
 Conditional statements (If) are
shown in brackets [x<10] or before
a colon leading to the message

29
Decisions

30
Loops
 Loops (repeat activity until some
condition is met) are shown on a
sequence diagram by placing a box
around the set of repeated
messages
 The looping condition is in brackets
 [for each line item]

31
Loops

32
Sequence Diagram … Sequence
 The sequence of actors and objects
from left to right on a sequence
diagram is generally the order in
which they are used
 Typically this results in the
primary actor on the far left,
then an interface object, etc.

33
Where to begin?
 To develop an interaction diagram,
use the use case documentation to
 Identifythe primary actor
 Use the MVC (or interface, control, and

data objects) pattern to make up the

objects which will be used to follow the
main success scenario
 Label messages appropriately to read,

move, and analyze data as needed

34
Where to begin?
 Where significant, add return
messages to describe important
information obtained as a result
of the messages

35
Ex.
 Use case name
 Login

 Scenario
 Scenario 1 : User enters his details.

 Scenario 2 :System security checks user details.

 Scenario 3:System sends welcome message if he

is authorized .

36
Ex.

37
Collaboration (or
Communication) Diagram

UML v2 will call them

‘communication’ diagrams, but
‘collaboration’ is still used in Visio
and the current UML standard
38
Collaboration Diagram
 A Collaboration Diagram looks like a
class diagram, since it has boxes
(with class or object names)
connected by lines
 But here, the lines correspond to
message paths, not associations
 It shows what messages are passed
between objects

39
Collaboration Diagram
 To show the chronological order of
messages, a collaboration diagram
MUST NUMBER MESSAGES
 The first object dictates the start of
each numbering series
 Its first message is number “1.”, the
second “2.”, etc.
 Messages which follow as a result of
the first message get 0.1 added for
each message, i.e. 1.1, 1.2, 1.3, etc.

40
Collaboration Diagram
 Then the messages which follow
message “2.” do likewise, 2.1, 2.2,
2.3, etc.
 This establishes threads of messages

 Some people just number the

messages sequentially (1, 2, 3, …),
but this is not compliant with any
UML standard

41
Collaboration Diagram
 The other critical thing is to
determine where messages ‘live’
(what object is responsible for
implementing them):
 The object to which a message
points (its target) is responsible
for implementing that message
 This also applies for sequence diagrams

42
Ex.

43
Generic Collaboration Diagram
1. msg1 1.1 msg2

:ClassA :ClassB

1.

1.2 m sg5
3

sg3
m
sg

1.4 m
4
1.5 msg6

:ClassD :ClassC

This matches the sequence diagram on slide 16

44
Collaboration Diagram
 Notice that lines between classes
have no arrowheads, but each
message is labeled with an arrow
 The next slide shows the implied
class characteristics from this case
 Notice that the ability to pass messages
implies visibility
between classes

45
Class Diagram for slide 16
ClassC
ClassA

+msg3()
+msg1()
+msg4()

ClassB ClassD

+msg2() +msg6()
+msg5()

Same case shown as slide 16

46