Chapter 5 Building Dynamic Diagrams

Collaboration Diagram Basics

The collaboration diagram is a UML interaction diagram. It describes a particular goal (a functionality of the system) by representing a set of chronological interactions between objects. It may be used to illustrate a possible scenario of a use case, the execution of an operation, or simply an interaction scenario between classes of the system.

You can use one or more collaboration diagrams to enact a use case or to identify all the possibilities of a complex behavior.

A collaboration diagram conveys the same kind of information as a sequence diagram, except that it concentrates on the object structure in place of the chronology of messages passing between them.

A collaboration diagram shows actors, objects (instances of classes) and their communication links (called instance links), as well as messages sent between them. The messages are defined on instance links that correspond to a communication link between two interacting objects. The order in which messages are exchanged is represented by sequence numbers.

Analyzing a use case

A collaboration diagram can be used to refine a use case behavior or description. This approach is useful during requirement analysis because it may help identify classes and associations that did not emerge at the beginning.

You can formalize the association between the use case and the collaboration diagram by adding the diagram to the related diagrams list of the use case. For more information, see the "Defining related diagrams" section, in the "Working with Object-Oriented models" chapter.

It is often necessary to create several diagrams to describe all the possible scenarios of a use case. In this situation, it can be helpful to use the collaboration diagrams to discover all the pertinent objects before trying to identify the classes that will instantiate them. After having identified the classes, you can then deduce the associations between them from the instance links between the objects.

The major difficulty with this approach consists in identifying the correct objects to transcribe the action steps of the use case. An extension to UML, "Robustness Analysis" can make this process easier. This method recommends separating objects into three types:

Boundary objects are used by actors when communicating with the system; they can be windows, screens, dialog boxes or menus
Entity objects represent stored data like a database, database tables, or any kind of transient object such as a search result
Control objects are used to control boundary and entity objects, and represent the transfer of information

PowerDesigner supports the Robustness Analysis extension through an extended model definition. For more information, see the "Using profiles: a case study" in the "Managing Profiles" chapter of the PowerDesigner Advanced User Documentation.

Analyzing a class diagram

Building a collaboration diagram can also be the opportunity to test a static model at the conception level; it may represent a scenario in which classes from the class diagram are instantiated to create the objects necessary to run the scenario.

It complements the class diagram that represents the static structure of the system by specifying the behavior of classes, interfaces, and the possible use of their operations.

You can create the necessary objects and instance links automatically by selecting the relevant classes and associations in a class diagram, and then pressing CTRL+SHIFT while dragging and dropping them into a an empty collaboration diagram. Then you have simply to add the necessary messages.