© Wolfgang Pelz 2000-04UML2 1
UMLPart Two
© Wolfgang Pelz 2000-04UML2 2
Chapters Four & TwelveInteraction Diagrams
© Wolfgang Pelz 2000-04UML2 3
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
© Wolfgang Pelz 2000-04UML2 4
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
© Wolfgang Pelz 2000-04UML2 5
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
© Wolfgang Pelz 2000-04UML2 6
Notation (UML 1)
© Wolfgang Pelz 2000-04UML2 7
Sequence Diagram Example
© Wolfgang Pelz 2000-04UML2 8
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.
© Wolfgang Pelz 2000-04UML2 9
Another Sequence Example
© Wolfgang Pelz 2000-04UML2 10
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.
© Wolfgang Pelz 2000-04UML2 11
… and Another
© Wolfgang Pelz 2000-04UML2 12
alternatives in Sequence Diagrams
© Wolfgang Pelz 2000-04UML2 13
Time Constraints
© Wolfgang Pelz 2000-04UML2 14
Some More Elaborations
• Centralized control: one participants doing all the processing (traditional sequential programming).
• Distributed control: processing is split among many participants (OOP and event-driven).
© Wolfgang Pelz 2000-04UML2 15
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 :ClassaParticipant
© Wolfgang Pelz 2000-04UML2 16
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).
© Wolfgang Pelz 2000-04UML2 17
© Wolfgang Pelz 2000-04UML2 18
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
© Wolfgang Pelz 2000-04UML2 19
Sequence Example (again)
© Wolfgang Pelz 2000-04UML2 20
Corresponding Collaboration Diagram
© Wolfgang Pelz 2000-04UML2 21
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.
© Wolfgang Pelz 2000-04UML2 22
Links and Messages
© Wolfgang Pelz 2000-04UML2 23
Parameters and Return Values
© Wolfgang Pelz 2000-04UML2 24
Iteration and messages to “this”
© Wolfgang Pelz 2000-04UML2 25
Message Sequencing
© Wolfgang Pelz 2000-04UML2 26
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.
© Wolfgang Pelz 2000-04UML2 27
Mutually Exclusive Paths
© Wolfgang Pelz 2000-04UML2 28
Sequence Diagram
© Wolfgang Pelz 2000-04UML2 29
Corresponding Collaboration Diagram
© Wolfgang Pelz 2000-04UML2 30
Another Collaboration Diagram
© Wolfgang Pelz 2000-04UML2 31
Exercise
• Draw the sequence diagram corresponding to the previous collaboration diagram
© Wolfgang Pelz 2000-04UML2 32
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
© Wolfgang Pelz 2000-04UML2 33
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
Top Related