Applying Patterns

---

The diagram in Figure 15-1 shows you who’s involved in a collaboration, but it doesn’t provide much detail about the attributes and operations of the individual classes you must construct before you can use the pattern for yourself. To help you and others with using patterns, you need to show a specific example fitting your own classes into the pattern or template. In UML 2, the example you build to show others how you are using a pattern is known as a collaboration occurrence.

You use collaboration occurrences to show details of how you apply a pattern to your specific application. You show a collaboration occurrence by placing the name of the occurrence and a colon in front of the name of the collaboration. For example, if you use the builder pattern to build air-filter units, you would name the collaboration occurrence as AirFilterUnit:Builder.

 Tip   Instead of showing everything inside a large dashed oval, you can show a collaboration or collaboration occurrence as a small dashed oval, connected to each class via dashed lines. The role that each class plays in the collaboration appears on the dashed line, next to the name of the class playing the role. Use this form of collaboration to show details of the participating classes’ attributes and operations.

Using the Builder pattern

Figure 15-2 shows you an example of the Builder pattern for building air-filter units. You notice the AirFilterUnit: Builder name in the small dashed oval indicates this is an example—a collaboration occurrence. The example uses the alternative form of a collaboration occurrence. The classes, important attributes, and operations for this use of the Builder pattern look like this:

• The AirFilterConstructor class plays the role of Director in the Builder pattern. To follow the Builder pattern, you must provide the class that plays the role of Director with a construct operation.

• Only a class stereotyped as an interface can play the role of Builder in the pattern. (Remember a class stereotyped as an interface is a special kind of class that specifies a contract that other classes must perform if they are to realize the interface.) Any class that supports the Builder interface must have an assembly attribute, along with a reference datatype that references an instance of the Product being built.

• The Builder interface also requires the implementation of a buildPart operation.

• The AirFilterUnitBuilder class plays the role of the ConcreteBuilder, thus providing a getResult() : AirFilterUnit operation. That operation returns an instance of the AirfilterUnit class, which plays the role of the Product in this pattern.

  
  Figure 15-2: Alternative form for showing a colaboration occurence.

Showing object interaction

Whenever you document a pattern, you have to show how the objects playing various roles interact. You can use a sequence diagram or communication diagram to document the nature of the interaction between parts of a collaboration.

Figure 15-3, for example, is a sequence diagram that shows the Builder pattern interaction. Play by play, it looks like this:

Figure 15-3: Sequence diagram for the Builder design pattern.

1. the: Client creates an instance of ConcreteBuilder called aConcreteBuilder.

2. the: Client creates an instance called a of type Director, and passes it a reference to the aConcreteBuilder instance just made in Step 1.

3. The instance a: Director turns around and asks aConcreteBuilder to buildPart.

4. The sequence gets into a loop where the Director instance asks the ConcreteBuilder instance to build all the parts that are necessary until the assembly is complete.

5. After the assembly is constructed, the: Client invokes the getResult operation on aConcreteBuilder : ConcreteBuilder.

6. A constructed instance of the Product is returned to the: Client.

---