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 [email protected] and [email protected], 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).
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.
