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. (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 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 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 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.