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.
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 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.
An example COD is:
The symbols available in CODs are: