Unified Modelling Language Interaction Diagrams

Interaction Diagrams Interaction diagrams are used to model the dynamic aspects of a software system They help you to visualize how the system runs. An interaction diagram is often built from a use case and a class diagram. The objective is to show how a set of objects accomplish the required interactions with an actor.

Elements found in interaction diagrams Instances of classes Shown as boxes with the class and object identifier underlined Actors Use the stick-person symbol as in use case diagrams Messages Shown as arrows from actor to object, or from object to object

Creating interaction diagrams You should develop a class diagram and a use case model before starting to create an interaction diagram There are two kinds of interaction diagrams: Sequence diagrams Communication diagrams

Sequence Diagrams

Sequence Diagrams Dynamic Model relating use cases and class diagrams Illustrates how objects interacts with each other Shows time ordering of interactions Generally a set of messages between collaborating objects Can model simple sequential flow, branching, iteration, recursion and concurrency

member: LibraryMember A Sequence Diagram member: LibraryMember book:Book :Book Copy borrow(book) ok = mayBorrow() [ok] borrow(member) setTaken(member)

member: LibraryMember A Sequence Diagram X-Axis (objects) member: LibraryMember book:Book :Book Copy Object borrow(book) Life Line ok = mayBorrow() Y-Axis (time) message Activation box [ok] borrow(member) setTaken(member) condition

Representing objects squares with object type, optionally preceded by object name and colon write object's name if it clarifies the diagram object's "life line" represented by dashed vert. line 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

Messages between objects A message is represented by an arrow between the life lines of two objects A message call is a request from the object sending the message to the object receiving the message. The request is for the receiver to carry out one of its (the receiver’s) operations 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

Messages between objects dashed arrow back indicates return 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()

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

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

Control information Condition Iteration syntax: ‘[‘ expression ’]’ message-label The message is sent only if the condition is true example: Iteration syntax: * [ ‘[‘ expression ‘]’ ] message-label The message is sent many times to possibly multiple receiver objects. [ok] borrow(member)

The syntax of expressions is not a standard Control Information (Cont.) Iteration examples: :CompoundShape :Shape :Driver :Bus draw() *draw() *[until full] insert() The syntax of expressions is not a standard

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

Sequence Diagram (Basics) Object : Class or Actor Lifeline name Focus of Control/ Activation message Object Destruction/ Termination X <<create>> <<destroy>>

Example 1

Example 2

Example 3

Example 4

Example 5

Collaboration (or Communication) Diagrams

Collaboration Class diagrams indicate what classes are part of our system, what they offer, how they relate, but they don’t tell us how they communicate Collaboration diagrams show how objects interact and their roles The elements of a Collaboration diagram are essentially the same as that of a Sequence diagram Actually they are considered as a cross between class and sequence diagram Sequence Diagrams are arranged according to Time Collaboration Diagrams represent the structural organization of object

Elements of a Collaboration diagram Element and its description Symbol Object: The objects interacting with each other in the system. Depicted by a rectangle with the name of the object in it, preceded by a colon and underlined.                           Relation/Association: A link connecting the associated objects. Qualifiers can be placed on either end of the association to depict cardinality.                                        Messages: An arrow pointing from the commencing object to the destination object shows the interaction between the objects. The number represents the order/sequence of this interaction.                              

Symbols used in collaboration diagrams

Example Class diagram for “Courseware Management System”

Example Sequence diagram for the"Manage course information" flow

Example Collaboration diagram for the "Manage course information" flow

When to Use Interaction Diagrams You should use interaction diagrams when you want to look at the behavior of several objects within a single use case Interaction diagrams are good at showing collaborations among the objects If you want to look at the behavior of a single object across many use cases, use a state diagram

How to choose between using a sequence or communication diagram? Sequence diagrams Make explicit the time ordering of the interaction. Use cases make time ordering explicit too So sequence diagrams are a natural choice when you build an interaction model from a use case. Make it easy to add details to messages. Communication diagrams have less space for this Communication diagrams Can be seen as a projection of the class diagram Might be preferred when you are deriving an interaction diagram from a class diagram. Are also useful for validating class diagrams.