Product Line Engineering Defined
Systems and Software Product Line Engineering, abbreviated as Product Line Engineering (or PLE for short), refers to the engineering of a portfolio of related products using a shared set of engineering assets and an efficient means of production.
A product line is defined as a family of similar products or systems with variations in features and functions. Each product is described by giving a list of its features: “A prominent or distinctive user-visible aspect, quality, or characteristic of a software system or systems”. Features are used to express product differences in all lifecycle phase artifacts. This streamlines the engineering process and lets all stakeholders speak the same language.
In the PLE Factory paradigm, we need a way to describe what product we’re building, so the shared assets (requirements, designs, code, test cases, user manuals, etc.) can be configured appropriately. Rather than adopt a different “language” and mechanism for each artifact (for example, compiler directives for code, attributes for requirements, text variables for documents, and so forth), we uses a small and consistent set of variation mechanisms for all of the artifacts.
Application engineering shrinks to almost nothing; products are produced through the use of high-end industrial-strength automation that configures the shared assets appropriately to produce the product asset instances for that product.
As shown in the illustration, the PLE Factory configurator automatically derives products from a wide variety of shared assets. Features are used to describe the products’ variations, and to tell the configurator the germane characteristics of the product it is to derive by configuring the assets.
Concepts: Products
The products in a Product Line Engineering (PLE) portfolio are described by the properties they have in common with each other and the variations that set them apart. The descriptions are in terms of the products’ features. Products can comprise any combination of:
- software
- systems in which software runs, or
- non-software systems that have software-representable artifacts (such as engineering models or development plans) associated with them.
When we refer to a product in PLE, we usually mean not only the primary entity being built and delivered, but also all of the assets that are produced along with it.
For example, the products can be software-only (such as a financial accounting system); software-embedded (such as an automobile, aircraft, cel phone, or a smart home appliance); or a manufactured item such as a piece of furniture.
When we refer to a product in PLE, we usually mean not only the primary entity being built and delivered, but also all of the assets that are produced along with it. Some of these support the engineering process (such as requirements, project plans, design modes, and test cases), while others are delivered alongside the thing being built (such as user manuals, shipping labels, and parts lists).
Concepts: Assets
Assets are the “soft” artifacts associated with engineering lifecycle of the products, the building blocks of the products in the product line. Assets can be whatever artifacts are representable with software and either compose a product or support the engineering process to create a product. These can include, but are not limited to the following:
- requirements
- design specifications
- design models
- source code
- build files
- test plans and test cases
- user documentation
- repair manuals and installation guides
- project budgets, schedules, and work plans
- product calibration and configuration files
- data models and parts lists
Shared assets are designed to include built-in variation points, which are places in the asset that change depending on the product in which the asset is used.
As you can see, some assets are delivered with the product (for example, user documentation) while other assets remain behind in the PLE Factory.
In Product Line Engineering (PLE), assets are engineered to be shared across the product line. All the assets within the shared asset superset are designed to include built-in variation points, which are places in the asset that change depending on the product in which the asset is used.
When a product is built, a statement of the product’s distinguishing characteristics is applied to “exercise” these variation points (that is, cause the change in the asset to occur to meet the needs of the product). Products are automatically generated by the PLE Factory configurator.
Variation points use variation mechanisms to impart product line diversity. In early generation approaches, these mechanisms have been specific to each kind of asset and have included macro’s in code, substituting one variant of the artifact for another; runtime conditionals and configuration files; attributes and filters; model and text transformations; feature mappings, parameterization, and many more. Second Generation PLE emphasizes the use of a small, unified set of variation mechanisms that work for all of the assets.
Concepts: Means of Production – The Configurator
The means of production is the mechanism that exercises the assets’ variation points to produce configured versions that, together, constitute the artifact set for one of the products in the product line. Configuring the shared assets for each product in turn produces the entire set of products.
Early approaches to PLE employed many means for producing the products from the shared assets. The assets could be manually configured, or (more likely) an ad hoc collection of techniques was employed to configure the various assets separately.
These techniques might include #ifdef statements for code, attributes in tabular requirements, or variables in Word documents. Each of these techniques usually only applies to the single asset in which it is used, and is often derived from the tooling used to engineer that asset.
For product lines of any size or frequency of change, manual production is impractical; some form of automation is required.
This scheme scales poorly, and may not trace well across different kinds of artifacts. Second Generation Product Line Engineering (2GPLE) approaches use the same kind of variation across all assets.
For product lines of any size or frequency of change, manual production is impractical; some form of automation is required. In fact, the complexities of modern product lines demand industrial-strength automation. The automation is called a configurator, which takes a feature-based description of a product and configures all of the assets (using their variation points) to produce instances for that product.
Under this paradigm, the PLE Factory configurator is the manufacturing automation; the shared assets represent the factory’s supply chain.
The configurator needs to be able to support the construction and management of feature models (including feature declarations, assertions, and profiles), assets and their variation points, support hierarchical production lines, and represent the logic that maps from feature choices to asset instances. Further, it needs to either provide version control for the models and artifacts or (even better) work seamlessly on top of the user’s own choice of change management system.
A major requirement for the configurator is that it supports the specification and selection of variation in shared assets and artifacts from across the entire spectrum of the lifecycle. This means that the tool will have to support variation in, for example, DOORS requirements modules, Microsoft Word documents and Excel spreadsheets, build files for Make or Ant, Rhapsody UML models, and many more. This often involves having the configurator interface with a variety of tools and manipulate artifacts stored in proprietary formats – something that most configurators cannot do.
Concepts: Features, Feature Catalogue, Feature Models, and Feature Profiles
A feature is a distinguishing characteristic of a product, usually visible to the customer or user of that product. An example is a capability that some products have but that others do not.
The concept of “feature” allows a consistent abstraction to be employed when making choices from a whole product configuration all the way down to the deployment of software components within a low-level subsystem in the architecture. The “feature language” becomes the lingua franca – common language – used by individuals and teams across across domains and organizational functions.
A “feature catalogue” contains all the feature options available for all the products in that product line. The features chosen for each product from the feature catalogue are specified in the “Bill-of-Features” for that product.
A “feature catalogue” contains all the feature options available for all the products in that product line. The features chosen for each product from the feature catalogue are specified in the “Bill-of-Features” for that product. (The Bill-of-Features is analogous to a bill-of-materials, but defining a product in terms of its features rather than its parts.) The PLE Factory configurator applies a Bill-of-Features to all of the shared assets, and evaluates each variation point to see if that variation point’s content should be included or not.
The product line literature is rife with feature modeling languages and constructs, but experience is showing a very small and simple set of feature modeling constructs suffices for describing all of the necessary feature information for large and very complex product lines. For example, the feature modeling constructs provided by BigLever Software Gears, include:
- Feature declarations
- Feature assertions
- Feature profiles
Feature declarations
Feature declarations are parameters that express the diversity in the product line for a system or subsystem. Feature declarations are analogous to the choices that are available when you buy a new car: Two door or four door? Sport package, luxury package, or economy package? Moon roof? Feature declarations typically express the customer-visible diversity among the products in a product line.
Feature declarations have types. When a feature is chosen for inclusion in a product, it must be given a value consistent with its type. The table below shows the feature types supported by Gears.
Nodes that have children are of type enumeration, set, or record – the compound types. Leaf nodes are Booleans, integer, float, string, character, or atom – the simple types.
Continuing the car example, the feature “Moon roof” would be type Boolean, since it’s either in or out. “Luxury package, sport package, economy package” would be an enumeration type since the choice is mutually exclusive.
Features can be nested (for example, the optional feature “Moon roof” could come in two varieties, electric or manual). The complete set of feature declarations forms a tree, outlining all of the decisions that are available to made to define a product.
The following illustration shows a partial example of a feature model for a vehicle cruise control system.
Feature assertions
Feature assertions describe constraints and dependencies among the feature declarations. Feature assertions in Gears express true/false conditions, often phrased as REQUIRES or EXCLUDES relations. These express the constraint that a feature (or combination of features), if present, either requires or excludes the presence of another feature (or combination of features).
For example, if we want to make sure that certain features are not available when we’re selling our product in a certain region, we could express that constraint with an EXCLUDES assertion between the region feature and the features we want to restrict.
Feature profiles
| Feature profiles are used to select and assign values to the feature declaration parameters for the purpose of instantiating a product. A feature profile is associated with a subsystem or a product, and reflects the actual choices you make: Two door with sport package but no moon roof; or four door with luxury package and moon roof. The values assigned in feature profiles must satisfy the constraints and dependencies expressed by the assertions in the feature declarations. A feature profile cannot be used if any of its value assignments violates an assertion.Constructing a feature profile consists of “walking across” a tree of feature declarations and making the necessary choices: For each Boolean, choosing true or false; for each enumeration, choosing a value; for each set, choosing the members to include, etc. Feature profiles let us escape the deadly combinatoric complexity of huge product spaces. Of the astronomical variety available, the set of feature profiles clearly enumerates which (small) set of products are actually of interest. |
Concepts: Hierarchical Product Lines
Organizations, even small ones, often have separate divisions at work to support their product line. Large organizations almost certainly do. These divisions may be geographically or organizationally isolated from each other. In this case, it is impractical to expect everyone to work on the same feature model, the same set of shared assets, and so forth.
Certainly having one global collection of feature declarations for an entire production line is impractical when features may number in the hundreds or even thousands. Large feature sets engender intractable and incomprehensible combinatorics. Subsystem engineers have no interest or need to see all of the feature diversity in other subsystems. For example, engineers for an automotive transmission system do not need to see feature abstractions that capture the diversity in the entertainment or GPS navigation system. It makes no sense to commingle them.
It makes much more sense to modularize the feature model in a way that corresponds to the organizational structure of the enterprise. Although these structures can change over time, they make an excellent starting point and let the organization begin to adopt PLE using familiar units.
A hierarchical production line constitutes an architecture-like construct, in that there are interfaces and relationships among the nested product lines.
For example, an automotive vehicle is composed from combinations of dozens of subsystems, all the way from the engine and transmission down to the subsystems that defog the mirrors and heat the driver’s seat. Each of these subsystems has features of its own, which allow a vehicle team to pick and choose in order to define a car. In this way, an automobile (like many complex systems in product lines) is more like a system of systems, which is managed as a product-line-of-product-lines.
Each of these units represents a domain, by which we mean a body of knowledge. These pockets of deep knowledge are often part of the fabric of the company. In a PLE context, that specialized knowledge becomes knowledge about the feature variations that are possible, and the result is a number of product lines that each contribute instances to the overall product. At every level, the same small and elegant set of concepts work to capture the inherent variation. This lets engineers work largely independently within the confines of their own organizational units and domain expertise.
A hierarchical production line constitutes an architecture-like construct, in that there are interfaces and relationships among the nested product lines. There is the parent-child relationship for product lines that typically mirrors the system-subsystem decomposition in the vehicle architecture. Product line features can be partitioned, encapsulated, and scoped within the primary subsystems that realize the features. Features can also be shared among product lines by establishing an import relationship, which is crucial for establishing feature constraints and asset variation points among interrelated subsystems (e.g., a high-end flavor of cruise control that slows the car if there’s traffic ahead requires a flavor of the braking system that supports braking via software command).