Skip to content

Pattern Specification vs. Pattern Implementation, which do I choose?

July 7, 2010

In the book we introduce the concept of a pattern implementation as an asset that “automates the application of a pattern in a particular environment.” In contrast, a pattern specification is the formal, written documentation that describes a pattern. With these two types of patterns available, you might wonder, should we replace all specifications by implementations? Is there still room for both? When use one or the other?

Thousands of specifications already exist, so we have a large pool that we can draw upon in solving problems. Existing specifications also provide us with samples that we can use and refer to as we create our own patterns. Most of us have already seen and worked with pattern specifications, so we have familiarity with the concept that we can leverage as we create our patterns. We generally know how a pattern specification is structured and the content that goes within. Traditionally, we’ve looked to use patterns only as specifications – but that is just part of the story.

The ability to find, create and then use pattern implementations is a key aspect of PBE. Today’s tooling is building out increasing capabilities to automate the patterns. Also, the PBE Patterns and Guidelines can help you build your own pattern implementations.  However, don’t interpret this as an endorsement that all you need is pattern implementations – there is a need to bring together the right mix of pattern specifications and pattern implementations into a successful project. That mix will be determined by you and your project, but is a consideration that must be made as you analyze and define how you will build a solution.

It is important to keep in mind that we should use these patterns as they make sense for the project and the organization, not just for the sake of using patterns. In addition, we are not looking to automate each and every pattern that we may come across – we need to be pragmatic and practical in regards to the automations that we build. Some of the questions that we refer to for guidance when thinking about pattern implementations include:

  • Is the pattern automatable?
  • How can we simplify how patterns are consumed?
  • How can we speed up and simplify how patterns are created?

Here are some considerations to help in determining if a pattern is a good candidate for automation:

Pattern computability: Is the information in the associated pattern specification precise enough so you can codify it into a pattern implementation? Would it be too complex to automate? Would the input model be too complex? Is the pattern specification too abstract to allow you to derive an automation? Are the possible pattern variants clearly mapped to a set of variability points (aspects provided to the user to adapt the pattern to his specific situation)?

Tooling availability: Do you have tooling available to automate the pattern? A pattern implementation cannot be created if the tooling or technology to automate the pattern is not available. For example, we would not create a pattern implementation if the development environment or the language we use make it more difficult to develop the pattern implementation than to develop the solution following specifications.

Reusability: Does the pattern implementation offer sufficient ROI? Whether we look to reuse the pattern many times, or just a few critical high value times, the cost of developing the implementation needs to be covered – otherwise we should stick to just a pattern specification.

In case such as the ones listed above, we will be better served by using a pattern specification.

2 Comments leave one →
  1. February 2, 2011 3:47 pm

    I am also a supporter of pattern-based software engineering approaches.

    My research on this subject has resulted on the design of ABSE (Atom-Based Software Engineering), a generative model-driven development approach. ABSE uses reusable patterns (a.k.a. “Atoms”) as the basis of its model-driven approach.

    ABSE patterns are coupled with metadata, giving them the necessary variability to deal with real-world applications. ABSE Atoms have borrowed concepts from OOP like inheritance and composition, allowing you to create pattern families, and build “patterns of patterns”. Atoms are glued together like Lego to form a model that has a tree-like structure. A code generator “executes” the model to obtain the desired generated artifacts.

    ABSE features and benefits to software engineering are explained at http://www.abse.info. A free IDE-like tool that implements ABSE is available too. It’s named AtomWeaver, and you can download and try it at http://www.atomweaver.com .

    AtomWeaver is in itself ABSE’s proof of concept: AtomWeaver is developed through an ABSE model.

    ABSE is a very simple model-driven methodology and it could be a great way for developers to introduce themselves to this new patterns-based development world with the help of the PBE book.

    My personal opinion is that a “reusable pattern” is really an overloaded concept: Reusable patterns, reusable assets, metamodels, they are all similar in nature. All these concepts promote reuse of tried-and-tested code and architectures.

Trackbacks

  1. Types of Pattern Implementations « Patterns-Based Engineering

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: