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.
|