UML
Part Two
UML2
© Wolfgang Pelz 2000-04
1
Chapters Four & Twelve
Interaction Diagrams
UML2
© Wolfgang Pelz 2000-04
2
Interaction Diagrams
• models that describe how groups of objects
interact (collaborate)
• class and use case diagrams are useful at
capturing the structural nature of a system
design in a generalized way
• interaction diagrams capture dynamic
behavior applicable to timing or sequencing
requirements
UML2
© Wolfgang Pelz 2000-04
3
Use Case & Interaction Diagrams
• scenario - a specific instance of a use case, that is,
a particular path through system functionality
• a single use case represents many related yet
distinctly different scenarios
• typically, an interaction diagram captures the
behavior of a single scenario
• Two forms of interactive diagrams: sequence and
collaboration/communication
UML2
© Wolfgang Pelz 2000-04
4
Sequence
•
•
•
•
boxes at the top are participants (objects);
vertical lines are time lines;
horizontal directed lines are messages;
unless specifically noted, only sequence (location
on the time line) is important, not exact times
• an activation rectangle in the lifeline indicates a
focus of control (activation) during which an
object is performing an action, either directly or
through another object
UML2
© Wolfgang Pelz 2000-04
5
Notation (UML 1)
UML2
© Wolfgang Pelz 2000-04
6
Sequence Diagram Example
UML2
© Wolfgang Pelz 2000-04
7
Some Elaborations
• Usually objects have concurrent life spans so they
are aligned at the diagram’s top.
• If an object is created, its lifeline starts with the
receipt of a << create >> message.
• Destruction can be explicitly noted with X.
• Sequence diagrams are good at visualization of
how objects interact, but not good at showing
details of algorithms, such as loops.
UML2
© Wolfgang Pelz 2000-04
8
Another Sequence Example
UML2
© Wolfgang Pelz 2000-04
9
Some More Elaborations
• Messages are function calls in traditional programming and events in
event-driven programming.
• Messages may carry parameters.
• A dished line indicates a return, used to carry a return message or just
indicate the end of a group of sub-actions.
• Self-call: sending messages to one self (message lines direct back to
the same life line)
• Found messages: messages not originated from any participants.
• Synchronous messages: messages return only when done, block the
flow of execution, no more messages from the same participant until a
synchronous message is done.
• Asynchronous message: messages returns immediately, do not block
the flow of execution.
• Guards are conditional expressions in square.
UML2
© Wolfgang Pelz 2000-04
10
… and Another
UML2
© Wolfgang Pelz 2000-04
11
alternatives in Sequence
Diagrams
UML2
© Wolfgang Pelz 2000-04
12
Time Constraints
UML2
© Wolfgang Pelz 2000-04
13
Some More Elaborations
• Centralized control: one participants doing
all the processing (traditional sequential
programming).
• Distributed control: processing is split
among many participants (OOP and eventdriven).
UML2
© Wolfgang Pelz 2000-04
14
Notations (UML 2)
• A participant was just an object in UML 1, but
can be more than that (e.g. a group of objects) in
UML 2.
• No more underline below the name in UML 2.
• : needs to be there with the class name in UML 2.
aParticipant:Class
UML2
aParticipant
© Wolfgang Pelz 2000-04
:Class
15
Interaction Frames
• New in UML2
• Notations for loops, conditions and other
detail algorithms.
• Common operators for Interactive Frames:
alt (alternative), opt (optional), par
(parallel), loop (loop), region (critical
region), neg (negative), ref (reference), sd
(sequence diagram).
UML2
© Wolfgang Pelz 2000-04
16
UML2
© Wolfgang Pelz 2000-04
17
Collaboration (UML 1.x)
Communication (UML 2.x)
– an interaction diagram that utilizes message
numbering instead of a time line; emphasizes
structural organization of objects that send
and receive messages
UML2
© Wolfgang Pelz 2000-04
18
Sequence Example (again)
UML2
© Wolfgang Pelz 2000-04
19
Corresponding Collaboration
Diagram
UML2
© Wolfgang Pelz 2000-04
20
Which to Use?
• Choose sequence diagram when only the sequence
of events needs to be shown and collaboration
among the objects are priority.
• Choose a collaboration/communication diagram
when the objects and their links facilitate
understanding the interactions (you don’t have to
put all objects at the top and make the lines all
vertical or horizontal).
• Collaboration diagrams have relatively fixed
notation and numbering scheme.
UML2
© Wolfgang Pelz 2000-04
21
Links and Messages
UML2
© Wolfgang Pelz 2000-04
22
Parameters and Return Values
UML2
© Wolfgang Pelz 2000-04
23
Iteration and messages to “this”
UML2
© Wolfgang Pelz 2000-04
24
Message Sequencing
UML2
© Wolfgang Pelz 2000-04
25
Threads and Mutual Exclusion
• Letters in the numbering indicate different
threads of control.
• Threads can be mutual exclusive if they are
guarded by exclusive conditions.
UML2
© Wolfgang Pelz 2000-04
26
Mutually Exclusive Paths
UML2
© Wolfgang Pelz 2000-04
27
Sequence Diagram
UML2
© Wolfgang Pelz 2000-04
28
Corresponding Collaboration
Diagram
UML2
© Wolfgang Pelz 2000-04
29
Another
Collaboration Diagram
UML2
© Wolfgang Pelz 2000-04
30
Exercise
• Draw the sequence diagram corresponding
to the previous collaboration diagram
UML2
© Wolfgang Pelz 2000-04
31
Making a Collaboration/Communication Diagram
• create a separate diagram for each system operation
under development
• if the diagram doesn’t fit on an ordinary sheet of
letter paper (A size), split into small diagrams
• Flat numbering (1,2,3..)is easy to keep track. Nested
numbering (1.1.1.2.3.1, 1.1.1.2.2.4) can be
confusing.
• use design by contract and use case descriptions to
design a system of collaborating objects
UML2
© Wolfgang Pelz 2000-04
32
Other Notations
• {tagged value} - in a class - a property
either predefined or defined by the user to
hold additional information about elements
• {constraint} - outside a class - applied to the
role of the link
• active object - executes concurrently with
its own thread of control
UML2
© Wolfgang Pelz 2000-04
33