First Generation: Software Product Lines

Product Line Engineering (PLE) traces its roots as a field of study to software product line engineering. Software product lines, and the efforts to characterize their successes, gave us early and long-standing approaches to product line engineering that we characterize as first generation approaches. These include the following:

  • Parnas's seminal paper on product families in 1976 instilled the idea that similar programs could be treated as a family rather than as a separate and unrelated set. Parnas characterized software evolution as a tree of decision possibilities. Every design decision leads down a different path of the tree. The family of possible programs occupy the leaves of the tree. Making a change involves backtracking up the tree and choosing a different path downward, ending at a different leaf. Obviously, the less backtracking required, the easier the change. Parnas argued that, to accomplish this, we should make the most stable design decisions early, corresponding to nodes closer to the tree's root, and the most volatile ones late.
  • Domain analysis, exemplified by the Feature Oriented Domain Analysis (FODA) method, provided a way to express the commonality and variations found in a set of systems or products. FODA provided a useful definition of a feature, which is "A prominent or distinctive user-visible aspect, quality, or characteristic of a software system or systems," and this definition still serves well in the PLE world. FODA led the way to a wide variety of feature modeling languages, which allow domain modelers to express features and their allowable combinations.
  • The software reuse movement that came to fruition in the early 1990s emphasized code repositories. By and large this movement exemplified opportunistic reuse (i.e., searching to see if a unit of software exists to fill a need as it arises), as opposed to planned reuse. Its primary contribution to PLE was to instill the notion that software systems might not (or should not) be built from scratch.

  • The U.S. Department of Defense's Advanced Research Projects Agency's STARS project ("Software Technology for Adaptable, Reliable Systems") turned its attention to software product line development in the early to mid 1990s. STARS instilled the dichotomy between domain engineering (the construction of reusable core assets) and application engineering (the selection, application, and augmentation of those assets to build products). Application engineering is often said to include creating any assets used in a single product, and promoting them to core assets only if subsequently used in more.

  • Generative programming involves the use of domain-specific languages in which to specify a product, and a generator to process a product description written in that language to turn out a product. In 1999, Weiss and Lai adopted this approach for a product line methodology called FAST (Family-Oriented Abstraction, Specification, and Translation).

  • Case studies of successful software product lines began to emerge in the mid-1990s. These included STARS demonstration projects, but also commercial successes, which revealed that successful product lines required more than a technical approach, but also strong management and business acumen as well. Movements began to coalesce to explore product lines from this more holistic approach, first in Europe as a series of Program Families workshops, and then in the United States with the creation of the Product Line Practice research program at the Software Engineering Institute and its creation of the Software Product Line Conference (SPLC) series of international conferences.

A distillation of first generation approaches includes:

  1. A strong dichotomy between domain engineering and application engineering, or core asset development and product development. Application engineering is often said to include creating any assets used only in a single product, and promoting them to core asset status only if subsequently used in more. Application engineering includes the obligation to choose a production strategy – that is, a way to turn the shared assets into products.

  2. Explicit inclusion of non-software artifacts in the collection of core assets, but an unmistakable emphasis on software (under the umbrella of an all-encompassing software architecture) as the principal kind of core asset.

  3. Focus on features as the language to describe a product line's domain and a way to discriminate products from each other in that domain.

  4. Acknowledgment of configuration management as an essential practice under PLE, but without a strong distinction between core asset CM and product CM.

  5. No strong emphasis on unifying the variation mechanisms employed in different assets, nor on a centralized configurator to automate the product-derivation process.

These approaches form the foundation on which Second Generation Product Line Engineering, the current state of the art and the main subject of this website, has been built.