A collaboration is a description of a named structure of classes. Instances of these classes each perform some specialized function (in other words, each serves a particular role). Taken together, these instances collectively accomplish some desired functionality that's greater than the sum of the parts .
The name of a collaboration should be a simple noun phrase that communicates the essence of what the collaboration does. The symbol for a collaboration is an ellipse with a dashed outline. Figure 1-21 shows two example collaborations.
You can also show the internal structure (in terms of instances) of a collaboration, as shown in Figure 1-22. The lines between instances represent connectors ‚ and thus communication paths.
The Proxy collaboration is actually an example of a design pattern. [6] The names before the colons are those that the pattern specifies; the names after the colons are names , defined by the modeler, for entities that are playing the specified roles.
A Customer retrieving information about his or her Order is presented with an OrderInterface in the form of an HTML page. This interface provides the Customer with an OrderProxy that stands in for the actual Order instance. This is necessary because Order instances are responsible for directing system processes (see the section "Active Classes," earlier in this chapter) and thus shouldn't be directly accessible by Customers. The OrderProxy does access the Order as necessary for information, without disrupting system operations.
Figure 1-22 is another example of a composite structure diagram.
A collaboration occurrence is the application of the pattern described by a particular collaboration to a specific situation that involves specific classes or instances playing the roles of that collaboration.
The notation for a collaboration occurrence is comparable to that of an object: the name of the occurrence, a colon , and the name of the collaboration. If the occurrence represents some behavior offered by a class, the occurrence is connected with the class using a represents dependency. Figure 1-23 shows an example of this dependency.
[6] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Boston, MA: Addison-Wesley, 1995). Note that this group of authors is often referred to as the "Gang of Four."