One of the advantages of applying profile to reifying design patterns is that a user of design patterns can give his/her reification of the design patterns to reflect the specific development context. While authors of many patterns originally proposed some solution, we argue many different factors can affect the reification of a design pattern and there is no standard reification to realize a pattern. For instance, the inheritance relation between an abstract Observer class and a concrete Observer class in the Observer pattern cannot be implemented as a generalization/an inheritance when an implementation language such as Java does not support the multiple inheritance. On the other hand, a design pattern can have some limitations when it is applied to some applications. For example, if an application keeps adding new element classes, then it is hard to apply the Visitor pattern because all interfaces of related visitor classes must be modified to incorporate an operation to visit the newly added element classes. So some variations of the Visitor patterns have been proposed. We argue that a user of design patterns should be allowed to reify patterns based on his/her application. The UML profile mechanism is the best method to serve this purpose. As an example, we show two different reification for the Observer Pattern and several reifications of the variations of the Visitor pattern in the following.

We have designed UML profiles for the following Gang of Four (GoF) design patterns. In the diagrams showing part of each UML profile, stereotypes with the suffix "Op" are stereotypes of Operation; those with the prefix "a" are stereotypes of Association; those with 3-5 capital letters are stereotypes of AssociationEnd; those with the suffix "Dep" are stereotypes of Dependency; those with the suffix "Var" are stereotypes of Attribute. The rest are stereotypes of Class.

There are no profiles for Facade and Template. This is because the structure of the Facade pattern is too vague; it only has a Facade class with unidirectional associations to multiple unspecified classes in a subsystem. The Template Method pattern is too common and is used in the other patterns where an abstract class contains primitive operations and also some template operations, which are (re)defined in concrete sub-classes.

Here are instructions to apply the ICER tool to using design patterns.

Creational Patterns

1. Abstract Factory
2. Builder
3. Factory Method
4. Prototype
5. Singleton

Structural Patterns

1. Adapter
2. Bridge
3. Composite
4. Decorator
5. Facade
6. Flyweight
7. Proxy

Behavioral Patterns

1. Chain of Responsibility
2. Command
3. Interpreter
4. Iterator
5. Mediator
6. Memento
7. Observer (alternate profile)
8. State
9. Strategy
10. Template
11. Visitor (variants from "A Pattern Language To Visitors" by Y. Mai & M. de Champlain, PLoP2001)
    1. Easy Operation Adder (GoF)
    2. Double Dispatch
    3. Catch-All Operation

Multiple Patterns

1. Bridge, Composite, and Iterator

Limitations of our profile:

1. Constraints in the profile are based on our interpretation of the design pattern, which may be different from others. However, the advantage of metamodel methodology is that a developer can change those constraints based on their own interpretations.
2. Operation implementations cannot be checked.
3. We only check class hierarchies up to two levels (parent and children) with OCL constraints.
4. Checking whether a sub-class inherits an operation from a parent class is rather complex, involving traversing associations with meta-class Generalization, and is omitted in the profile.
5. In some patterns an abstract base class is not necessary but our profile requires them based on the structure in the design patterns book.
6. Certain other semantics are not easily or cannot be checked with graphical and OCL constraints in a static class diagram-based profile.

Links and References:

1. Design patterns with sample code in C#
2. Huston design patterns
3. Patterns for Java and Distributed Computing
4. Hillside.net Patterns Library