|
Pattern implementations go one step further than simply using pattern specifications as blueprints.
May 04, 2007
URL:http://www.drdobbs.com/architecture-and-design/the-value-of-pattern-implementations/199204017
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.
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:
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.
When looking at the convergence of pattern specifications, MDD, and metatooling, we note that none of these disciplines is particularly new. Each is associated with a community that has been developing and maturing its domain for a number of years. The new and interesting aspect is when we bring these three concepts together in a mainstream development environment.
Model-driven development is an approach in which models are a key development artifact. The models are used to capture and communicate design—and preferably used to generate the solutions they represent.
MDD provides a strategy for raising the productivity and quality of software development by requiring you to think about the essential variables in design; so the model lets you work at the appropriate level of abstraction for the task at hand. The standard, repetitive, and algorithmic activities of expressing these variables in a particular technology environment is delegated to tooling.
The idea of metatooling is that you have tooling that lets you build tooling. In particular, for creating pattern implementations, which are tools themselves, we are interested in two metatools:
These can be used in combination to provide a platform for pattern implementations.
The main benefits of pattern implementation use can be summarized as:
With a pattern implementation, the key idea is that we've codified and automated a best practice. When it comes time to use the pattern implementation, we're able to perform the work much faster than if we were doing it manually. The pattern implementations can be used to generate both the code (and related artifacts that comprise the solution) as well as the artifacts used to test the solution. We always have to pay some price to develop the asset initially. However, if we use the asset many times, we save each time we use the automation, versus performing the task manually.
The use of pattern implementations also lets those new to the team use the asset without necessarily having the experience or knowledge required to actually create the pattern. They just need to know how to use the resulting asset, which of course, represents the best practices. As such, they are able to operate at a much higher level than if they were forced to struggle ahead on their own.
As team sizes increase and members of the team specialize, we often find it challenging to ensure that those implementing the architecture and design stay true to the intentions of the architects and designers. An additional challenge here is that team members often may not be colocated, but distributed around the globe.
To address this issue, you can leverage pattern implementations in two ways:
Governance also involves determining and managing the relationship between requirements and the solution that is built to meet those requirements. You should be able to trace all code back to requirements. We call this concept "traceability," and it is used to manage both what code is written in the first place as well as to assist us when it comes time to determine the impact of change.
To support traceability within the model, you can add connections that show the relationship between the elements in the design and the requirements. The pattern implementations are able to mimic this behavior—so that as we apply the patterns in the solution, they automatically create traceability links between model elements that were the input to the pattern and those artifacts that end up being generated.
Because of these links, you can show how the elements of the solution map back to requirements. If those requirements change, you can answer the question, "What is the impact of the change?" If you need to change the code, you can answer the question, "Why is this coded to behave this way?"
Regardless of how fast you build your solutions, all is lost if the quality is not at an acceptable level. The first way pattern implementations can assist here is obvious—the pattern implementation is an embodiment of our best practice solution. By using the pattern, the generated output is the best that you can generate and should meet quality requirements.
There are also less obvious ways that pattern implementations can improve the quality of solutions. For instance, if an error in a pattern is found, you can update the pattern implementation and reapply the pattern. Reapplication means that you just rerun the pattern and have it regenerate output that contains the fix. If you had performed the work manually, you would have to manually fix the code in each place where the error occurred. And since you would be performing that work manually, odds are that you would introduce a new defect somewhere in the updated code.
When we codify our best practices in the pattern implementation, we are implicitly stating that we are working with experts to create a representation of the best practice. If we left this work to be done manually, it might be performed by a group of people with varying skill levels. That we are able to replicate the work of the most skilled team members leads to a higher level of quality.
Over the years of software development, we have continued to leverage abstraction and tooling to build ever more complex solutions. Pattern implementations let us take the next step in this progression. Again, pattern specifications gave us a vocabulary to use when designing and building solutions. We no longer had to discuss things at a code or module level. Patterns let us communicate in a known, shared language that carried with it best practices and proven solutions.
As we move forward with pattern implementations, we can leverage this communication mechanism and build upon it. With pattern implementations, we now have a set of widgets within our tools that we can bring to bear on our projects. We can use them to communicate, design, and generate. These widgets abstract away much of the complexity, letting us focus on the problem at hand.
In this article, we explored the benefits of using pattern implementations as a generating artifact. Other aspects worth exploring are the different types of pattern implementations, how they can be built, and the best practices supporting their creation. But that will have to wait for another article.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.