Unlike the other chapters in this book, this one does not correspond to an official diagram in UML 2. The standard discusses collaborations as part of composite structures, but the diagram is really quite different and was used in UML 1 without any link to composite structures. So I felt it best to discuss collaborations as their own chapter.
Let’s consider the notion of an auction. In any auction, we might have a seller, some buyers, a lot of goods, and some offers for the sale. We can describe these elements in terms of a class diagram (Figure 15.1) and perhaps some interaction diagrams (Figure 15.2).
Figure 15.1 is not quite a regular class diagram. For a start, it’s surrounded by the dashed ellipse, which represents the auction collaboration. Second, the so-called classes in the collaboration are not classes but roles that will be realized as the collaboration is applied—hence the fact that their names aren’t capitalized. It’s not unusual to see actual interfaces or classes that correspond to the collaboration roles, but you don’t have to have them.
In the interaction diagram, the participants are labeled slightly differently from the usual case. In a collaboration, the naming scheme is participant-name / role-name : class-name. As usual, all these elements are optional.
When you use a collaboration, you can show you’re using one by placing a collaboration occurrence on a class diagram, as in Figure 15.3, a class diagram of some of the classes in the application. The links from the collaboration to those classes indicate how the classes play the various roles defined in the collaboration.
The UML suggests that you can use the collaboration occurrence notation to show the use of patterns, but hardly any patterns author has done this. Erich Gamma developed a nice alternative notation (Figure 15.4). Elements of the diagram are labeled with either the pattern name or a combination of pattern:role.
Collaborations have been around since UML 1, but I admit I’ve hardly used them, even in my patterns writing. Collaborations do provide a way to group chunks of interaction behavior when roles are played by different classes. In practice, however, I’ve not found that they’ve been a compelling diagram type.