Channels ▼


The Value of Pattern Implementations

Lee is a Senior Product Manager with the IBM Rational Learning Services & Solutions team. Celso is a World Wide Analysis, Design, and Construction Community of Practice leader in IBM Rational. They can be contacted at and, respectively.

Over the past decade or so, we've heard about using patterns when designing software solutions. Much of this discussion started with Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, et al., which showed how to use the patterns concept in software development—where a pattern is a proven solution to a known problem within a given context. The patterns in Design Patterns and books that followed let us improve designs, communicate with others, and learn about design best practices.

The patterns story becomes even more interesting when we look at pattern implementations. In this article, we explore the benefits of pattern implementations.

Pattern Specification versus Pattern Implementation

In the literature, patterns are often described in a formal manner. This description usually includes a detailed description of the pattern, the context to apply the pattern, and the forces that it addresses. This overall information is what is called the "pattern specification" and its purpose is to describe the pattern and help you determine how and when the pattern should be applied. Architects or designers can then use the pattern specification as a model to apply the pattern.

The idea of a "pattern implementation" came from the desire to go further than simply using pattern specifications as a blueprint. As architects, designers, and developers, we continuously look for ways to automate and speed up the mundane and mechanical parts of our work. The pattern implementation is an artifact that allows the codification of a pattern specification and automates its application in a particular environment.

A key point is that pattern implementations can generate many types of artifacts. They can be used to generate UML models, code, or other text-based artifacts such as JSPs, JSF pages, deployment scripts, test scripts, Eclipse project artifacts, and so on. In addition, pattern implementations can be created and used at different phases in the lifecycle as well as at different levels within an application. This means that you can use pattern implementations at high levels of abstraction, such as when you are discussing requirements or performing an initial analysis of a system. It also means that you can use pattern implementations when transitioning from analysis to design, then into an implementation—all the while moving from a more abstract representation (a series of models) to a representation that is very specific (code).

Using Rational Software Architect to illustrate, you can see that pattern implementations surface in two ways:

  • UML Patterns. A UML Pattern is applied within the scope of a model and can apply markup to a model, add model elements, or create relationships between new or existing elements (Figure 1).
  • Transformations. In contrast to UML Patterns, a Transformation usually converts elements from a source model into elements in a different target model. In the case of a Transformation, the supported input and output models go beyond UML. We use the term "model" in a broader sense to refer to a semantically rich representation of elements and their relationships. The model is usually specified using a formal language with well-defined structure and semantics. As such, UML is one choice, but you could also use other languages based on the Eclipse Modeling Framework (EMF). In addition, we can work with models that leverage Java, XML, or other languages to define the elements that they contain (Figure 2).

[Click image to view at full size]

Figure 1: The upper part shows the pattern implementation; the lower part shows the classes and relationships generated by the pattern implementation.

[Click image to view at full size]

Figure 2: Mapping transformation that generates a <<Boundary>> class in the analysis model for every Actor.

Creating pattern implementations is possible only because of the convergence of three streams with IT thinking, namely: Pattern Specifications, Model-Driven Development (MDD), and Metatooling.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.