As well as containing classes, a package can contain collaborations. A collaboration is a name given to the interaction among two or more classes. Typically, this is an interaction, as described in an interaction diagram. Thus, the sequence diagram in Figure 7-3 describes the Make Sale collaboration.
This collaboration might show the implementation of an operation or the realization of a use case. You can model the collaboration before deciding what operation invokes it.
A collaboration can be described with more than one interaction diagram, with each one showing a different path. You can also add a class diagram to show the classes that participate in the collaboration. (See Figure 7-4.)
In addition to using collaborations within a package, you can use them to show common behavior across packages. If someone asks you about database interaction, you might need to point them to many packages and classes to see how that works, even though database interaction is only one aspect of these packages and classes. You can improve this by defining a database interaction collaboration. Within that collaboration, you show those aspects of the classes that are relevant, and interaction diagrams that show how they work.
Often you may find that the same collaboration is used by different classes in the system. Each time, the basic way the classes work is the same, but classes and operations are named differently, and there may be minor differences in the implementation. You can illustrate this by parameterizing the collaboration.
First, you draw a diagram like Figure 7-5, which shows the various roles that various objects play in the collaboration. (Note that the classes in this diagram are not actual classes in the system; instead, they are roles in the collaboration.) You would then add interaction diagrams to show how these roles interact.
Next, you show how a set of classes participate in the collaboration, by drawing a diagram like Figure 7-6.
The UML also uses the term pattern as a synonym for parameterized collaboration. Calling it a pattern is controversial, as there is more to a pattern than this, but certainly this notation can be used to show where common patterns are used in a particular system.
You can also use this kind of notation in role-based modeling, within which you first model the collaborations and roles, and then come up with classes that implement these roles. You can find out more about this style of design in Reenskaug (1996).