Patterns

Components

A component is a cohesive, opaque, replaceable, functional module of a larger system.

The larger system can be a hardware, software, or business system, thus a component can be a hardware component, such as a device, microchip, or circuit; a software component such as a user interface, database, or message passing subsystem; or a component can be a business unit such as payroll, provider, or shipping. (See the Wikipedia article on Systems Theory for a good overview of the full scope of the system/component concept.)

A component's functionality is specified by a set of provided interfaces (lollipops).

A component provides its services to other components. In turn, a component may require the services of other components. These requirements are specified by a set of required interfaces (sockets).

Here is an example of a UML component diagram:

Deployment

Components are realized by artifacts (files usually) which are deployed on software platforms, which are hosted by hardware platforms. Platforms (called nodes in UML) communicate using protocols and communication links. Here's a UML component diagram combined with a UML deployment diagram showing these concepts:

Collaborations

Internally, a component is implemented by a collaboration. A collaboration is a collection of classes that work together to implement the services specified in the component's provided interfaces.

UML provides some notational support for collaborations:

Inside the shipping collaboration we might find that a shipper keeps the method of shipping in a separate ShippingMethod object. When asked to ship a purchase to a customer, the shipper delegates to the shipping method object to decide if the purchase should be shipped by land, sea, or air:

Inside the billing collaboration we might find that the Billing component delegates to a tax calculator to decide how much sales tax to add to the invoice. This object determines if California, Oregon, or New York sales tax should be computed:

Parameterized Collaborations

Sometimes radically different components can be implemented by collaborations that are only superficially different. In other words, the structure and behavior of the collaboration is the same, but the names of the participants, perhaps the names of the attributes and methods are different.

For example, we might notice that both of the collaborations above are instances of the same collaboration template:

Just as we think of a generic class in Java as a class parameterized by types:

List<String> a; List<Integer> b; List<List<Char>> c;

We can think of Context, Strategy, and ConcreteStrategy as type parameters in the above strategy template. The official UML icon is:

This icon is cumbersome and useless. By using labeled dependency arrows we can show the binding of parameters to arguments.

Here it is for the Shipper example:

Here it is again for the Billing example:

Specifying Behavior

A class diagram specifies the structure of a collaboration. We can use a sequence diagram to describe the component's behavior. For example, here's the behavior of the strategy collaboration:

Design Patterns

A design pattern is a parameterized collaboration that solves a recurring design problem:

In this diagram we see that both Pattern3 (with parameters X, Y, and Z) and Pattern4 (with parameters A, B, and C) are solutions to the problem. The designer can choose. (Often a pattern will have stated disadvantages and advantages depending on the context.)

The diagram also shows that Pattern3 uses Pattern1 (with parameters U and W) and Pattern2 (with parameters J and K). Pattern4 also uses Pattern2. Pattern3 might be a composite pattern and Pattern1 and Pattern2 are its components. In other words, Pattern1 and Pattern2 work together so often that their combination is a pattern (Pattern3). In the case of Pattern4 it might be the case that its use in this particular situation created or failed to solve a secondary recurring design problem that had to be solved using Pattern2. We say that Pattern2 refines Pattern4.

Our strategy collaboration above is actually the Strategy design pattern.

Pattern Catalogs

A pattern catalog is a collection of design patterns. Each pattern in the catalog might be described using some elaboration of the Problem-Solution format:

Pattern: Strategy

Problem: The algorithm a provider object uses to implement a particular operation may need to be changed by its client at runtime.

Solution: Place the algorithm in a separate strategy object. Implement the operation in the provider object so that it delegates to the algorithm in the strategy object. By introducing a strategy interface that all strategy objects must implement, strategies objects become dynamically interchangable in the provider object.

Structure: Class diagram goes here

Behavior: Sequence diagram goes here

A pattern catalog entry might also include:

Other Names: ...
Advantages: ...
Disadvantages:
Known uses: ...
Variations: ...
Sample implementation: ...

Pattern Categories

A pattern catalog might also categorize patterns in some useful way so that they are easier to locate. Here are some examples of pattern categories:

Architectural Patterns
Structural Patterns
Behavioral Patterns
Creational Patterns
Enterprise Patterns

The Pattern Movement

The idea of using design patterns originally comes to us from architecture through the work of Christopher Alexander. The idea quickly spread to software design. In a sense data structures and coding idioms can be thought of as implementation patterns. Analysis patterns are used for building domain models during the analysis phase. There are also pattern catalogs for testing, manufacturing, and business practices (including managing programmers.)

References

This is the little book that started the patterns movement:

[ALX] Christopher Alexander. The Timeless Way of Building. Oxford University Press. New York, NY. 1979.

This is my favorite reference for enterprise patterns:

[FOW-1] Martin Fowler. Patterns of Enterprise Architecture. Addison-Wesley, Reading, MA. 2006.

An analysis pattern is a collaboration that appears in many domain models. Here's an example:

[FOW-2] Martin Fowler. Analysis Patterns: Reusable Object Models. Addison-Wesley, Reading, MA. 1997.

Here is the original pattern catalog for software engineers:

[Go4] Erich Gamma, Richard helm, Ralph Johnson, and John Vlissides. Design Patterns, Elements of Reusable Object-Oriented Software. Addison Wesley, Reading, MA. 1995.

This is my favorite catalog:

[POSA] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. Pattern Oriented Software Architecture: A System of Patterns. Wiley. New York, NY. 1998.

It's also easy to find patterns on the web.