Guideline: Applying Design Patterns
Design patterns are generalized solutions to commonly occurring problems. In this process, design is largely performed by selecting and applying design patterns.
Relationships
Main Description

Design patterns are "generalized solutions to commonly occurring design problems" and are a kind of asset that can be reused in many different specific designs. In this process, we recommend that design proceeds primarily through the application of design patterns to the PIM, resulting in the PSM. Two primary approaches are used to accomplish this - elaboration and translation.

Design Pattern Preparation

Before design patterns can be selected, let alone applied, the problem context and optimization required need to be clarified.

To understand the context of the pattern, you need to view the model to which you are planning to optimize, focusing on the aspect to optimized (e.g. structural collaboration of classes) at the level of abstraction of concern (e.g. architectural (global scope), mechanistic (collaboration scope), or detailed (class scope)). The pattern context is the collaboration of elements at the appropriate level of abstraction for the pattern, and typically includes the elements to be instantiated within the pattern (the actual parameters of the pattern) and the elements that directly connect to the actual parameters.

To clarify the design criteria:

  • Identify the optimizations to be achieved, in terms of design optimization criteria
  • Rank the criteria in order of importance or criticality

Optimization criteria are usually organized around some aspect of performance, resource usage, developer efficiency or artifact property. At the detailed level, class optimization is performed by applying "design idioms" (essentially tiny patterns). We recommend that you list the top criteria (at least 6-10) for optimization and then rank then in order of importance. The ranking can be done either in a scale of 1-10 or 1-100 in which the value represents the importance, or the ranking can be normalized so that the sum of the ranking add up to a predefine value (normally 10 or 100). In either case, the important thing it to clarify the relative importance of different optimization criteria so that good selections of design patterns can be made.

The criteria and their properties can easily represented in a spreadsheet.

Pattern Selection

Based on the optimization needs, select design patterns from the literature or from your design expertise that perform the desired optimizations at a cost you are willing to pay and those preconditions are met by the pattern context

One the pattern(s) have been selected, the patterns can be applied to the pattern context in two primary ways: elaboration and translation.

Elaboration

Elaboration is the most common approach to the application of design patterns. The analysis model - functionally correct but un-optimized - provides the starting point. The selected patterns are applied to the analysis model manually (typically in the context of a graphical modeling tool) by adding in the elements from the design pattern. The elements from the pattern are mostly either "glue" elements that are added without change or they are "formal parameters" that will be replaced (or sub-classed) by elements from your analysis model. In addition to the insertion of these elements, there is often some minor reorganization of responsibility, functionality, and class relations that takes place; this is known as "refactoring." Refactoring is common during the application of design patterns, but it is only very rarely an issue.

Translation

Translation requires a more sophisticated modeling tool to do well, and even tools that claim to be translation-based don't always succeed in their goal. The translation approach takes the same analysis model as in the Elaboration approach and applies patterns automatically. When used in this way, the designer doesn't explicitly do "design work" - instead he or she creates a translator that embodies those design decisions in a set of transformational rules. The translator then applies the design decisions to the analysis model to construct the design model. In some cases, the design model is not explicitly represented by is constructed (and discarded) "on the fly" and the result of the translation is the source code implementing the analysis model with the design decisions.  The translation itself can be "property-driven" or "rule-driven". In either case, it is necessary to identify to which elements different design transformations should be applied. This can be done with properties, tags, or stereotypes. Properties are tool-specific predefined metadata that specify which transformations should apply to the element. Tags are user-defined metadata that apply to the elements that the translator can be instructed to use. Stereotypes are "marks" given to model elements that the translator used to identify which transformational rules apply.

In Practice

In practice, some patterns are easy to add via elaboration but relatively hard via translation while for other patterns the reverse is true. We recommend a combination of both approaches.