Section 11.3. Showing Patterns with Collaborations

11.3. Showing Patterns with Collaborations

Collaborations show objects working together, perhaps temporarily, to get something done. This may sound like object diagrams (see Chapter 6), but collaborations have a different focus: describing objects by the role they play in a scenario and providing a high-level textual description of what the objects are doing.

Collaborations are a good way to document design patterns , which are solutions to common problems in software design. Even if you've never heard of them, you've probably used some patterns without knowing it. Observer and Observable in the Java API are an implementation of the Observer design patterna way for an object to receive notification that another object changed.

For more on design patterns and how they can improve your software design, check out Design Patterns: Elements of Reusable Object Oriented Software (Addison Wesley), or Head First Design Patterns (O'Reilly).

Let's consider a problem in the CMS design that can be solved with a design pattern, which we'll then model using collaborations. Suppose the CMS requires a content approval process: the author submits content, the reviewer may reject the content or pass it on to the editor, and the editor may reject or accept the content. You decide to implement this flow with the Chain of Responsibility (COR) design pattern. The COR design pattern allows an object to send a request without worrying about which object will ultimately handle the request. In the COR pattern, the client submits the request, and each handler in the chain decides whether to handle the request or to pass the request on to the next handler. In the content approval process, the author will play the role of client, while the reviewer and editor will each play the role of handler. The sequence diagram in Figure 11-16 illustrates this flow. Refer back to Chapter 7 for a refresher on sequence diagrams.

Figure 11-16. Sequence diagram showing how the COR pattern is used in the content approval process

There are two ways to model this pattern using collaborations. The first way uses a large dashed-lined oval with the collaboration participants drawn inside the oval. You name a participant by the role it plays in the collaboration and its class or interface type, written as <role> : <type>. The participants are linked together using connectors to show how they communicate. The name of the collaboration is written inside the oval above a dashed line. Figure 11-17 shows a Chain of Responsibility collaboration using the first notation. In this COR collaboration, the participant of type Author has the role client, and the other participants have the role handler.

Figure 11-17. Collaboration showing the COR pattern in the content approval process

You can think of participants in a collaboration as placeholders for objects because at runtime, objects will fill those places (or play the roles). Connectors are temporary links; connectors mean that the runtime objects communicate during the collaboration, but the objects don't have to communicate outside the collaboration.

The second way to draw a collaboration is shown in Figure 11-18. In this notation, you show the class (or interface) rectangles of the participants, connecting each to a small collaboration oval. Write the participants' roles along the lines. This notation is useful for showing details of the class or interface, such as its operations.

Figure 11-18. Alternate representation of the COR design pattern

Collaborations may not look particularly useful, but their strength is in their ability to express patterns that may not be obvious from other diagrams, such as class or sequence diagrams. Without collaborations, you'd have to come up with your own technique to describe what's going on, such as the attached notes in Figure 11-16.

Because collaborations are only temporary relationships, they have some interesting runtime properties that are best described with an everyday example of a collaboration. Suppose a company has monthly training sessions in which the topic changes every session, and in every session the resident expert on the topic performs the training. This is modeled as a TRaining collaboration that has participants with roles trainer and trainee, as shown in Figure 11-19.

Figure 11-19. This Training collaboration shows that the objects participating in a collaboration at runtime can interact with different collaborations in different ways

Now let's turn to some objects that may play these roles at runtime. Ben is the XML expert, so during the XML training collaboration, Ben has the role of trainer, and his co-worker Paul has the role of trainee. However, Paul is the Java expert, so during the Java training collaboration, Paul has the role of trainer and Ben has the role of trainee. This training example illustrates the following points:

An object isn't bound to its role in a collaboration; it can play different roles in different collaborations. Employee Ben and employee Paul remain the same objects; they're just playing different roles in different training collaborations.

The objects in a collaboration aren't owned by the collaboration; they may exist before and after. Ben and Paul have a life outside of training.

Even though objects in a collaboration are linked, they don't necessarily communicate outside the collaboration. Ben and Paul may not talk to each other unless they absolutely have to during the training sessions.

The training collaboration also demonstrates that you can use collaborations to describe any type of object interaction that can be nicely summarized using a short phrasenot just design patterns.

This is a specialized UML notation because the oval simply draws attention to the existence of a pattern, describing it in brief, high-level terms. But collaborations are valuable for exactly that reason. Design patterns are about building a common vocabulary among developers for solving everyday problems, and collaborations help communicate that vocabulary. Collaborations don't show detailed interactions such as messages being passed between objects as sequence and communication diagrams do, but that can be a benefit when it comes to concisely expressing a well-known pattern.