Appendix B. PBE and Other Development Approaches
This appendix discusses how PBE relates to other available development practices, including asset-based development, model-driven development, Model-Driven Architecture, and software factories.
Asset-Based Development
As introduced in Chapter 1, there is a strong connection between PBE and asset-based development (ABD). ABD is focused on how to leverage investments made in software artifacts in future projects. These investments cover a wide range of artifacts, from requirements, to models, code, tests, even deployment scripts. ABD includes four major areas—process, standards, tooling, and assets—all of which are focused on how you can successfully reuse and benefit from the investments that are made in your software projects.
We can say that a pattern is a type of asset, and we can see PBE as a specific type of implementation of an ABD program. The difference is that although we consider a wide range of artifacts and aspects of development in PBE, we look at these as exemplars for use in creating patterns. In PBE, the primary assets that are distributed and reused are patterns.
A key standard available in support of ABD is the Reusable Asset Specification (RAS) from the Object Management Group (OMG). RAS is used to package an asset to support the consumption of assets by tools and people. Typically the RAS-packaged asset contains a set of artifacts as well as a manifest that describes the asset.1
Model-Driven Development (MDD)
Generally when we discuss MDD, we are referring to an approach to software development whereby we leverage models at multiple levels of abstraction. The elements that exist within a model at a certain level of abstraction are in turn related to elements at the next level of abstraction. This view of MDD can be seen in the following definition for model-driven: “. . . meaning that the system developed is organized in terms of different models with specific purposes and whose elements relate (trace) to each other.”2
In recent years more focus has been placed on using automation and thereby using the elements found in one model to generate the elements of a model found at another level of abstraction. “Truly model-driven development uses automated transformations in a manner similar to the way a pure coding approach uses compilers.”3
Regardless of whether the migration between levels of abstraction is something that happens manually or through automation, we still need some guidance as to how the migration should be performed. Sometimes this transformation is very direct and quite simple. For instance, if we are moving from a detailed design document, it is quite easy to figure out how to transform the elements in the model into code elements. This transformation capability has been available in modeling tools for a number of years now. Although it enables us to generate a great deal of code, have we really added much value to the development process? Yes, the code is generated faster than a human can write it, but has the modeler ended up just drawing the code? The goal is to use models to abstract away details; however, we put so many details into the model that the generation of code is simple. As a result, the value we derive from using MDD transformations is limited (especially when compared to the potential). We are able to achieve all of our modeling-related goals, including design, communication, and generation, but we are designing at such a low level of abstraction that the model transformation provides little real value.
What if we want to simplify things for the modeler? What if we want to ensure that best practices are going into the design? To simplify things for the modeler and to truly bring value to our models we need to better leverage abstraction and best practices. Using patterns in and across models is a key step in doing so. We can take things even further with the use of DSLs (including the use of constraints, rules, and assumptions). Having patterns and DSLs enables us to simplify the solution so that we can reduce the number of levels of abstraction, and even within a level of abstraction we can reduce the amount of information that we need to capture from the modeler.
PBE provides us with an approach to find patterns and the related and supporting DSLs. We can envision the relationship between MDD and PBE as shown in Figure B.1.
Figure B.1. The relationship between MDD and PBE
Clearly, there is overlap between MDD and PBE. MDD assumes developers will create models while incorporating best practices. Thus, there is the expectation that the solution that is modeled will use patterns. However, within MDD there is little to no guidance for how to find these patterns. In addition, MDD does not help us figure out how to start to compress the number of levels of abstraction that we need.
Model-Driven Architecture (MDA)
Model-Driven Architecture is a specific implementation of MDD that is being led by the OMG. According to the OMG:
The Model-Driven Architecture starts with the well-known and long established idea of separating the specification of the operation of a system from the details of the way that system uses the capabilities of its platform.
MDA provides an approach for, and enables tools to be provided for:
• specifying a system independently of the platform that supports it,
• specifying platforms,
• choosing a particular platform for the system, and
• transforming the system specification into one for a particular platform.
The three primary goals of MDA are portability, interoperability and reusability through architectural separation of concerns.4
Like MDD, MDA recognizes that the transformations between levels of abstraction can be done either manually or in an automated fashion. However, those supporting and attempting MDA place much more focus on the idea of using automation.
As shown in Figure B.2, MDA is one possible approach to MDD.
Figure B.2. MDA is a subset of MDD.
Specific to the MDA approach to MDD is a prescribed set of viewpoints that are represented in models. These viewpoints are
• Computation-Independent Model (CIM)
• Platform-Independent Model (PIM)
• Platform-Specific Model (PSM)
Most often you will find that the solution has one or more PSMs to support the generation of the solution. Patterns play a key role in supporting the transformation from one viewpoint to another.
Figure B.3 shows that the relationship between MDA and PBE is similar to the previously discussed relationship between MDD and PBE. There is definitely overlap and a connection between PBE and MDA. However, there exist ideas, guidance, and roles in PBE that do not exist in MDA.
Figure B.3. The relationship between MDA and PBE
Here are some of the differences between MDA and PBE:
• Very little guidance is provided on how to capture and create the patterns necessary to support you in MDA.
• There is little discussion in the MDA literature regarding the other pattern use cases that are possible. Within PBE we do not restrict our thinking to just using patterns for forward-engineering a solution. Patterns can and do support many use cases when we are building a solution; forward engineering is just one of many.
• MDA has more of a top-down focus than PBE.
• PBE is more explicit in calling out the idea that the transformations that are used between levels of abstraction are themselves pattern implementations.
Software Factories
A software factory (SF) is defined by Greenfield and Short as follows:
A software factory is a software product line that configures extensible tools, processes, and content using a software factory template based on a software factory schema to automate the development and maintenance of variants of an archetypical product by adapting, assembling, and configuring framework based components.5
The terms software factory schema and software factory template in this definition merit further explanation:
A SF Schema defines, categorizes and summarizes the artifacts and assets required to build a software product line. It can be seen as a recipe listing ingredients, tools and the application process. A SF Template is based on the SF Schema and represents the implementation of the SF Schema that means that all defined assets and artifacts have to be built and made available. The implementation comprises among others developing DSLs. The SF Template can be seen as a bag of groceries containing the ingredients listed in the recipe (SF Schema).6
And related to the concept of an exemplar, we see within software factories the concept of an archetype. It is defined as follows:
archetype: An ideal example of a type after which other similar things are patterned7
It is important to note that while modeling and automation are key elements in software factories, there is also an emphasis on ensuring that the right process is built to support the factory. Figure B.4 depicts the relationship between software factories and MDD.
Figure B.4. Overview of the relationship between software factories and MDD
In this relationship there are certainly aspects of software factories that are contained within MDD. However, software factories are much broader in scope as they deal not only with how your application would be generated from your model(s) but also with all of the supporting tools that would be involved in making your development easier.
Just as with MDD, there is a strong and important role for patterns in software factories. To automate and support the production lines we need to find the correct set of patterns. However, the software factory approach and related literature provide little or no guidance on how to create and use patterns together such as is detailed in PBE. Thus, we can view the relationship between software factories and PBE as shown in Figure B.5.
Figure B.5. Overview of the relationship between software factories and PBE
As seen in the diagram, PBE is narrower in scope than both MDD and software factories. There is a great deal of overlap and synergy between these approaches. However, PBE provides content that is unique and exists outside of either of these approaches. PBE provides a set of tasks, roles, and work products that we can bring to bear in our MDD and software factory projects. For example, PBE provides guidance in terms of the roles that are needed for creating and managing a set of patterns. In addition, PBE provides guidance on when, where, and how to build the patterns you will use.
Keep in mind that PBE is not limited to just supporting software factories and MDD. PBE is a software development practice that can be applied and used within other practices and approaches.