Appendix A. PBE Definitions

The goal of this appendix is to provide additional support for understanding a number of the concepts associated with PBE.

Code Generators

A code generator is a program that writes other programs. Although code is a part of the name, the code generator can also generate other types of artifacts. For example, a code generator could also generate documentation or deployment descriptors. Many of the benefits that code generators offer, such as productivity and quality improvements, are also offered by pattern implementations.

So at this point we have to ask, “Is a pattern implementation, specifically one that focuses on generating text-based artifacts, just a code generator?” There are definitely similarities between the two concepts. However, there are differences as well, some minor and some more substantial. The largest differences are a matter of focus and scope; a pattern implementation associated with PBE has a larger scope aimed at leveraging multiple levels of abstraction. In addition, we look at a pattern implementation as a composition of patterns, whereas code generators generally are not discussed in this way. Last, but not least, with PBE we focus on capturing and working with best-practice-based solutions. The pattern implementation codifies a set of best practices; it is not just a translation of the model into code.

Domain-Specific Languages

The patterns that we build will accept a set of input elements, often captured in a model. To support the processing of the model by computers in an automated fashion we use a formal language, leveraging a metamodel, to define the elements that can appear in the model. Building on that understanding, we can start to discuss the language that we use for the model. We could use a general-purpose language such as UML as the basis for the input model to the pattern. However, with a general-purpose language we may end up with ambiguity and an associated gap between our problem space and how we will describe the solution. One way in which people have dealt with this gap is to model at a level that is very close to what they want to implement. In these cases the implementation technology dictates how the modeling should be handled.

Another approach to dealing with this issue is to use a language that is better aligned with the problem space or domain. We refer to a language that is aligned with the problem domain as a domain-specific language (DSL). More specifically, a domain-specific language is “a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique.”² As such, a DSL provides “concepts and rules within a language that represent things in the application domain, rather than concepts of a given programming language.”³ The DSL enables us to use a higher level of abstraction and thereby both speak about and focus on the problem at hand rather than the underlying implementation. This simplifies the consumption and use of the language because the users are familiar with the vocabulary of the domain, and therefore they are also familiar with the DSL.

Tools that can be used to implement a DSL include the Eclipse Modeling Framework (EMF)⁴/Graphical Modeling Framework (GMF)⁵ from the Eclipse platform, UML Profiles to extend UML, and tools from other vendors such as Microsoft or MetaEdit.

Some of the benefits of using a DSL include these:

• Support for automation. A DSL written as a formal language is suitable for automation and can be translated into other artifacts. Also, a DSL can often include assumptions and constraints that support a higher percentage of artifact generation compared to general-purpose languages.

• Support for people. A DSL can improve communication between roles, utilization of team member skills, and governance. With respect to governance, a DSL constrains and focuses the solution and hides unnecessary elements. When combined with appropriate automations, a DSL can enforce architectural approaches and best practices.

• Support for business/domain. The DSL uses terms and concepts that map directly to the problem space. It simplifies communication between business and technical project participants, hides irrelevant technical details, and provides a more precise validation of requirements to the design team.

Exemplar

When we build a new pattern (whether a specification or an implementation), we need to keep in mind that patterns are discovered rather than invented. To this end, we often look for representative reference solutions that we can analyze and use as the basis for the pattern. We call this reference solution an exemplar.

According to the American Heritage Dictionary, an exemplar is defined as follows:

1. One that is worthy of imitation; a model.
2. One that is typical or representative; an example.
3. An ideal that serves as a pattern; an archetype.
4. A copy, as of a book.⁶

So the question arises, “What exemplars do we need to consider for possible input into the pattern creation process?” When we look to identify a possible pattern, we are on the lookout for exemplars as well as for situations where the “Rule of Three” applies. The Rule of Three is used for judging where a possible pattern may exist; in this case we are looking for situations where the same problem/solution set has occurred in three unique instances/situations.

RULE OF THREE: A software pattern documents a recurring solution. The pattern solution abstracts three or more experiences. The solution is something which is regularly applied or practiced by some community(s) of sophisticated developers and architects. The logical basis for the rule of three is: the first occurrence shows the design can work, the second occurrence is interesting, and the third occurrence suggests that the design might be worthy of being a pattern because it appears to have a wider applicability. Non-normative comment: The informal concept behind the rule-of-three is: the first occurrence is an event, the second occurrence is a coincidence, and the third occurrence may be a pattern.⁷

A good exemplar has the following characteristics:

• It works. As a representation of a best-practice-based solution, it should by definition be a solution that works.

• It exhibits the necessary variability and flexibility that will be required of the resulting pattern.

• It has a Pattern Author/Subject Matter Expert (SME) who understands the exemplar and can support others in gaining an understanding of it.

Metamodel

A metamodel is a model that describes another model at one level of description higher. Another way of saying this is that a metamodel is a model that describes another modeling language. This includes describing the semantics and notation of the language. For example, the UML metamodel describes in precise detail the meaning of the elements within the language such as a class, attribute, and operation. In addition to defining the elements themselves, the metamodel describes the meaning of the relationships between these elements.

Figure A.1⁸ provides an overview of the relationships between a metamodel, model, and the real-world artifacts that need to be modeled. The upper left-hand quadrant is the quickest and easiest to understand. In this case we are looking at the real-world instances of artifacts that we want to represent in a model such as customer, account, order, and employee.

Figure A.1. Relationships among metamodel, model, and real-world artifacts

Copyright IBM developerWorks, www.ibm.com/developerworks. Reused with permission.

Moving to the upper right-hand quadrant, we can view a model as providing an abstract representation of instances. Here we can see the creation of model elements that represent those real-world instances mentioned previously. For example, we see model elements that can be used to represent customer, account, and order. Some familiar model elements from the UML realm include class, activity, and component. To that end we end up having a class named Customer.

Finishing up in the lower right-hand quadrant of the figure, we see that a metamodel exists at an abstract and meta level where we describe other abstract things. At this level we define the model elements that will be available to us when we create our model. If we relate this back to UML, it is at this level that we define the modeling elements such as class, activity, and component as well as their relationships. We will find a class named Class.

By using a metamodel to describe and define the model language, we support two key communication needs:

• Communication between people. As there is a well-defined basis for the language, we can use our understanding of the language as the basis for interpreting models that use it. Referring again to UML, we can see that once someone understands UML, he or she can interpret models based on this language regardless of who created the model or when it was created.

• Communication with machines. If we want to use a model as an input into automation, we need to make sure that the model can be read and interpreted by a machine. A metamodel provides us with the level of precision needed by a computer to understand a model unambiguously and accurately. In turn, a computer can use associated rules, constraints, and assumptions to generate output artifacts based on the provided model.

Tools and frameworks are available to support the creation and use of both metamodels and models. The more difficult part of the work is the thought that goes into determining what concepts need to be represented and the relationships between them. The more mechanical aspects of creating and supporting the metamodel(s) are handled by tooling.

Model

Key to working with patterns is the use of models. A very general, high-level definition of a model is that it is an abstraction or a simplification of reality. A good model includes those elements that are relevant to the given level of abstraction, while hiding or ignoring those details/elements that are not relevant. A model may be structural, emphasizing the organization of the system, or behavioral, emphasizing the dynamics of the system.

The language used within the model can vary among formalized textual, formalized graphical, or natural language. A formal language exists when time and effort are taken to document the syntax and semantics of the language, typically accomplished via the use of a metamodel. UML is a formal language that can be used to capture a model. However, a model can also be captured in an informal language, such as when we draw a diagram with boxes, lines, and arrows but without explanations or definitions for those elements.

Pattern Catalog

“A Pattern Catalog is a collection of (possibly) related patterns. Patterns in a pattern catalog do not form a Pattern Language; that is, their contexts do not weave them together.”⁹ A pattern catalog can include details on the relationships between patterns. However, the depth of any details provided about the relationships is not to the same level found in a pattern language.

Pattern Categories

As we look at the set of available patterns, we can see that they vary in terms of the scope of solution impact and the level of abstraction in which they operate. If we compare the Façade pattern to the Layers pattern, it is quite clear that they are significantly different in terms of scope and abstraction. The Layers pattern impacts the overall architecture of the system, whereas we would see the Façade pattern have an impact at the design level of the solution. When determining which patterns to use, it is helpful to categorize the available patterns, using their scope and abstraction characteristics to classify them.

In categorizing patterns, as shown in Figure A.2, three common categories are used: architectural patterns, design patterns, and idioms. Let’s take a look at a definition for each of these categories:

• “An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their relationships, and includes rules and guidelines for organizing the relationships between them.”¹⁰

• “A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.”¹¹

• “An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.”¹²

Figure A.2. A common set of pattern categories

Pattern Language

We’ve discussed how patterns are used in combination, and we expect that a solution will use numerous patterns. However, how do we know what patterns to use together? How do we know in what order we should use the patterns? One way in which we can gain some of this insight is through the use of a pattern language. A pattern language is “a network of interrelated patterns that define a process for resolving software development problems systematically.”¹³ There will be cases where we believe that we’ve found a pattern but upon further investigation determine that there are a number of “paths” through the pattern or that the pattern has a large number of steps. In such cases it may make sense to refactor the pattern into a set of patterns and distribute them as a pattern language.

Pattern languages can be used to solve many types of problems, just like a pattern. As a matter of fact, we can even use pattern languages to help us in building our own patterns. For example, a key aspect of PBE is that we should both produce and consume patterns. Since we will create our own patterns, including specifications and implementations, it makes sense to use patterns to help create patterns. We can think of these as metapatterns or pattern patterns. A pattern language for creating patterns is illustrated in Figure A.3.

Figure A.3. A set of metapatterns or pattern patterns

This figure is a reproduction of Figure 29-1 from page 531 of Martin, R. C., D. Riehle, and F. Buschmann. 1998. “Context-Setting Patterns.” In Pattern Languages of Program Design 3. Boston: Addison-Wesley. Reproduced by permission of Pearson Education.

In this pattern language there exists a set of patterns that provide guidance for building patterns and pattern languages. Trying to fit all of these best practices and guidance into a single pattern would result in a pattern that would be unusable. We can even relate the construction of the language to what we see when we develop our software solutions. We don’t just build a single monolithic class, component, or service. Instead we break the solution into smaller, meaningful pieces, leveraging encapsulation, separation of concerns, and abstraction.

Reusable Asset

An asset is “. . . a collection of artifacts that provides a solution to a problem. The asset has instructions on how it should be used and is reusable in one or more contexts, such as a development or a runtime context. The asset may also be extended and customized through variability points.”¹⁴