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.
A use case is a class of interactions between actors in a UML model’s environment and the system. Each may be complex or compound and may require decomposition into 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 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 class specifications 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 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 class specification.
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 class specifications, the classes in a COD will be cross referenceable.
CODs are not hierarchical. Their connectivity is:
CODs are available in both the Essential and Implementation Domain.
Numbering of CODsEach 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 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 process specifications for object instances and actors are named and numbered from the class or actor name.
SymbolsAn example COD is:
The symbols available in CODs are:
| Symbol | Name | Description | Definition | Expansion |
|---|---|---|---|---|
 | Comment | Makes a note anywhere in the diagram. Are always surrounded by * characters. Note: If you do not want Cradle to automatically add an * go to the Graphics Settings section of Project Setup and turn off the Automatically add asterisks to diagram's comment symbols option. | None | None |
 | Actor | A part of the environment that stimulates the system or is stimulated by it. | Environment | None |
 | Object Instance | An object that is created, performs actions, and/or is destroyed during the lifeline. | Class specification | None |
 | Multi Object Instance | A set of objects. | Class specification | 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 |
 | Collaboration Synchronous Message | An instantaneous communication between objects that conveys information, with the expectation that an action will be initiated as a result. | None | None |
 | Collaboration Flow of Control Message | A message that passes the focus of control from one object to another. | None | None |
 | Collaboration 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 |
 | Item | Represents a requirement or system note in the diagram. | None | None |
 | Context Item | Represents a requirement or system note in a diagram and is a container within which other object symbols can be drawn or attached. | None | None |
 | Cross Reference Link | Represents a cross reference that exists between a pair of system notes/requirements. It can also represent a cross reference between a system note/requirement and a specification or data definition or system that describes the objects symbols that it connects. | None | None |