Important Definitions
The terms defined in this section, as shown in Figure 1.4, are important to PBE and will be referred to in the rest of the book. This section provides brief definitions of these terms to ensure a common understanding. Additional details on these terms and supporting definitions are provided in Appendix A, "PBE Definitions."
Figure 1.4 Overview of key concepts related to PBE
Figure 1.4 also shows that there is a relationship between these elements. We use metamodels, DSLs, and patterns to represent solutions within a model. Models that are recognized as representing a best-practice solution are exemplars. With an exemplar in hand, we are able to create a new pattern that can be used to specify future solutions. With these relationships in mind, let's take a look at the definitions for each of these terms.
Model
Key to working with patterns is the use of models. Simply put, a model is an abstraction or a simplification of reality. A good model includes elements that are relevant at a given level of abstraction, while hiding or ignoring details that are not relevant. A model may be structural, emphasizing the organization of a solution, or behavioral, emphasizing the dynamics of a solution.
Metamodel
The language used within a model can be formalized textual, formalized graphical, or natural language. A formalized language—one that has a detailed and precise description—is helpful in creating models that support communication between people as well as communication with machines. A metamodel is a key mechanism we use in building a formal language. A metamodel is a special type of model that describes and specifies a modeling language. Essentially, we use a more abstract model to define the language that is used in another, more concrete model.
Exemplar
When we want to create 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 such a reference solution an exemplar.
To identify a possible pattern, we are on the lookout for both exemplars and situations where the "Rule of Three" applies. The Rule of Three is used to judge 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 situations.
As noted at the beginning of this chapter, starting a project is full of difficulties, including concerns about available expertise. However, what if we take the idea of exemplars and the Rule of Three into consideration? Can we use these ideas to help us find patterns to use on the project? Some of the sources to which we could apply these ideas include past project designs and implementations, as well as some of the artifacts of the current project. For instance, with the current project, we could examine the architectural mechanisms, key use cases, recurring aspects of the solution, and so on.
Domain-Specific Languages
A domain-specific language (DSL) is "a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique."21 More simply put, a DSL is a language that we can use to describe a solution that allows us to use terminology from the domain in which we are working.
There are a number of reasons to use DSLs along with PBE, some of which are these:
- We are trying to simplify the lives of pattern consumers and enable them to structure the input model to the pattern in the simplest manner possible.
- Ideally we are able to automate the use of the patterns via the creation and use of pattern implementations.
- DSLs and their underlying metamodels support communication between people as well as with machines.
- A DSL enables us to both speak in terms of the problem domain and to operate at higher levels of abstraction.