6.5 Collaboration Diagrams
A collaboration diagram shows elements as they interact over time and how they are related. That is, it shows a collaboration or collaboration instance. While sequence diagrams are time-oriented and emphasize the overall flow of an interaction, collaboration diagrams are time- and space-oriented and emphasize the overall interaction, the elements involved, and their relationships. Sequence diagrams are especially useful for complex interactions, because you read them from top to bottom. Collaboration diagrams are especially useful for visualizing the impact of an interaction on the various elements, because you can place an element on a diagram and immediately see all the other elements with which it interacts.
6.5.1 Elements
Collaboration diagrams are made up of a number of elements, including class roles, specific objects, association roles, and specific links. All of these are described in the following subsections.
6.5.1.1 Class and association roles
In a collaboration diagram, class roles and other classes are shown using the same notation as in sequence diagrams. An association role is shown using the notation for associations as defined in Chapter 3, but the association name is preceded by a forward slash followed by the name of the role followed by a colon to which links must conform to participate within the role. Other associations may also be shown as necessary using the notation for associations as defined in Chapter 3.
Class roles, association roles, other classes, and other associations are used for specification-level collaborations communicated using collaboration diagrams. Figure 6-20 shows the class roles of Figure 6-8 with the projectReference association role, the Report and Section classes, and the Has association.
Figure 6-20. Association roles
6.5.1.2 Specific objects and links
In a collaboration diagram, specific objects conforming to class roles and other objects are shown using the same notation as in sequence diagrams. A specific link of an association conforming to an association role is shown using the notation for links as defined in Chapter 3, but the association name is preceded by a forward slash followed by the name of the role followed by a colon followed by the regular association name, all fully underlined. Recall from Chapter 3 that a link may have its association name shown near the path and is fully underlined, but that links do not have instance names. Other links may also be shown as necessary using the notation for links as defined in Chapter 3.
Specific objects conforming to class roles, specific links conforming to association roles, specific objects, and specific links are used for instance-level collaborations communicated using collaboration diagrams. Figure 6-21 shows the objects of Figure 6-9 with the projectReference link, which is an anonymous Report object with Introduction, Body, and Conclusion objects, and their three Has links.
Figure 6-21. Links conforming to association roles
6.5.2 Communication
In a collaboration diagram, a communication, message, or stimulus is shown as an arrow attached to a relationship pointing from the sender toward the receiver. A communication is labeled using the same notation as in sequence diagrams, but a sequence number is required and expressed using a special numbering scheme known as dot notation in which a dot or decimal point is used between different levels of communication. For example, between element A and B, communication 1 is followed by communication 2; between element B and C, communication 1.1 is followed by 1.2; and the overall sequence of communication is 1, 1.1, 1.2, and 2.
Figure 6-22 is similar to Figure 6-12, but uses a collaboration diagram to show the communication occurring between the GenerateProject-StatusReportHandler class (which is responsible for managing the overall generation of the report) and the projectOrganization class role.
Figure 6-22. Collaboration diagram communications
6.5.2.1 Reflexive communication
Figure 6-23, similar to Figure 6-13 but using a collaboration diagram, shows a reflexive communication for step 6 of the Generate Project-Status Report interaction and collaboration description in which the GenerateProject-StatusReportHandler class formats the organization and project information. Notice that a reflexive communication is shown using a reflexive relationship.
Figure 6-23. Collaboration diagram reflexive communications
6.5.2.2 Element creation and destruction
Figure 6-24, similar to Figure 6-14 but using a collaboration diagram, shows a communication for step 3 of the Generate Project-Status Report interaction and collaboration description in which the GenerateProject-StatusReportHandler class creates a report. This figure also shows a communication for step 8 of the Generate Project-Status Report interaction and collaboration description in which the GenerateProject-StatusReportHandler class destroys the report. Notice that a communication that creates an element and a communication that destroys an element are simply shown like any other communication.
Figure 6-24. Collaboration diagram creation and destruction communications
6.5.3 Repetition
In a collaboration diagram, repetition (which involves repeating a set of messages or stimuli) within a generic-form interaction is shown as a property. Properties are discussed in Chapter 2.
An iteration expression indicating the number of times the communications occur may be enclosed in a pair of braces ({}) and attached to the communications to which it applies using dashed lines. Figure 6-25, similar to Figure 6-15 but using a collaboration diagram, shows step 6b of the Generate Project-Status Report interaction and collaboration description. The figure uses an iteration expression that causes the GenerateProject-StatusReportHandler class to retrieve each worker's units of work and list of work products, to format this information, and to output the formatted information to the report element.
Figure 6-25. Collaboration diagram repetition using an iteration expression within a generic-form interaction
Alternatively, a guard expression indicating the condition that must be satisfied to terminate the repetition may be enclosed in a pair of braces ({}) and attached to the communications to which it applies using dashed lines. Figure 6-26, similar to Figure 6-16 but using a collaboration diagram, uses a guard expression to show the same information as in Figure 6-25.
Figure 6-26. Collaboration diagram repetition using a guard expression within a generic-form interaction
Repetition within an instance-form interaction involves showing the actual set of messages or stimuli that are repeated. Figure 6-27, similar to Figure 6-17 but using a collaboration diagram, shows the same information as in Figures Figure 6-25 and Figure 6-26 for a project that contains exactly three workers, each with two units of work and one work product.
Notice that Figure 6-27 may be more difficult to read than Figure 6-17. For more complex interactions, sequence diagrams are often preferable over collaboration diagrams, because sequence diagrams are read from top to bottom. Collaboration diagrams are often preferable over sequence diagrams when the desire is to show the relationships that allow the elements to communicate.
Figure 6-27. Collaboration diagram repetition within an instance-form interaction
6.5.4 Conditionality
In a collaboration diagram, conditionality which involves communicating one set of messages or stimuli rather than another set of messages or stimuli within a generic-form interaction is shown using the dot notation where the communication at a specific level indicates the guard expression that must be satisfied for the next level of communications to occur. For example, between elements A and B, communication 1 may be labeled with a guard expression and is followed by communication 2. Communication 1 from A to B may trigger communications 1.1 and 1.2 between B and C. Because of the guard condition on communication 1, the following two scenarios are possible:
- The guard condition is satisfied
-
Communication 1 occurs between A and B, triggering 1.1 and 1.2 between B and C. The overall sequence of communications is then 1, 1.1, 1.2, followed by 2. Communication 2 comes last, because everything associated with communication 1 must precede it.
- The guard condition is not satisfied
-
Communication 1 does not occur, and thus neither do communications 1.1 and 1.2. However, communication 2, does occur because it is not protected by the same guard condition as communication 1.
Figure 6-28, similar to Figure 6-18 but using a collaboration diagram, shows steps 5 and 6 of the Generate Project-Status Report interaction and collaboration description where the GenerateProject-StatusReportHandler class requests that the projectOrganization class role indicate that the project is empty if the project is newly created or unpopulated; and the GenerateProject-StatusReportHandler class requests that the projectOrganization class role continue generating information for the report element if the project is not a newly created or populated project. In this figure, only the first communication is shown for actually generating the report.
Figure 6-28. Collaboration diagram conditionality within a generic-form interaction
Conditionality within an instance-form interaction involves the set of messages or stimuli that are communicated for a specific condition. Figure 6-29, similar to Figure 6-19 but using a collaboration diagram, shows Figure 6-28 for a project that is populated.
Figure 6-29. Sequence diagram conditionality within an instance-form interaction
