Collaboration Diagram
Purpose
Each Use Case Diagram (UCD) use case may be expanded into a Collaboration Diagram (COD) and/or a Sequence Diagram (SQD) to define its scenario. A use case with multiple scenarios will be decomposed into a lower-level UCD with a set of use cases, one for each scenario, and therefore a set of CODs. A COD provides a view of the actors and class instances that interact in a scenario, and the messages that they exchange.
Example:
Description
A use case is a class of interactions between actors in a UML model's environment and the system. Each use case may be complex or compound and may require decomposition into more elemental, simpler, use cases. A use case is, effectively, a set of events sequenced in time, termed an event flow. There may be several event flows for a use case, describing, for example, the normal or most common sequence of events, alternate sequences of events, and exceptional sequences of events that will usually correspond to error conditions. Each path through these multiple event flows is called a scenario.
Scenarios are described by either an SQD or a COD, or both. Both of the diagram styles show the details of the interaction of the environment (the external actors shown in the UCD) with the appropriate part(s) of the system (classes and their object instances), in terms of a time sequenced exchange of messages. The time sequencing is made graphically explicit by the SQD, whereas the COD focuses on clearly showing the totality of message transfers between all of the actors and classes/object instances involved in the scenario.
Except for these graphical differences, the SQD and COD convey similar information.
The COD shows the same information as the SQD, but without the time sequenced view. It therefore shows the totality of all the message flows, and explicitly shows which actors and/or classes exchange messages, and what messages they exchange. As for SQDs, the notation in the diagram is initially informal, but acquired additional rigour as the design is elaborated and constructed.
The classes and objects shown in a COD are defined by Process Specifications (PSpecs) whose name and number match the name of the class. No other symbol has a definition; the data content of a class must consist of basic data types, there will never be a set of Data Dictionary (DD) definitions defining data structure.
When naming classes and objects in the COD the naming convention is as follows:
instance-name : class-name
When viewing the definition of an object instance named in this way, Cradle ignores the instance name and the : class name separator character, and uses only the class name to identify the PSpec.
It is possible to navigate directly to a class's definition from a COD, and thereafter to the Class Diagrams (CDs) in which the class appears.
By being defined in PSpecs, the classes in a COD will be cross referenceable.
None.
Characteristics
APPEARS IN MODELS |
Essential and Implementation |
NUMBERING |
Each use case may be expanded into an SQD and/or COD to define its scenario. A use case with multiple scenarios will be decomposed into a lower-level Use Case Diagram (UCD) with a set of use cases, one for each scenario. A COD has the same name and number as its parent use case. The PSpecs for object instances and actors are named and numbered from the class or actor name. |
HIERARCHICAL |
None |
Linkage
Symbols
| Symbol |
Name |
Description |
Definition |
Expansion |
|
Comment |
Makes a note anywhere in the diagram. Are always surrounded by * characters. |
None |
None |
|
Actor |
A part of the environment that stimulates the system or is stimulated by it. |
PSpec |
None |
|
Object instance |
An object that is created, performs actions, and/or is destroyed during the lifeline. |
PSpec |
None |
|
Multi-object instance |
A set of objects. |
PSpec |
None |
|
Picture |
Allows you to choose the location of a GIF or JPEG image to be displayed as a diagram symbol or to be embedded in an existing diagram symbol. |
None |
None |
|
Interaction link |
An indication that the object instances and actors collaborate and have message exchanges. |
None |
None |
|
Synchronous message |
An instantaneous communication between objects that conveys information, with the expectation that an action will be initiated as a result. |
None |
None |
|
Flow of control message |
A message that passes the focus of control from one object to another. |
None |
None |
|
Asynchronous message |
A communication between objects, taking a measurable time, that conveys information, with the expectation that an action will be initiated as a result. |
None |
None |
|