This is a summary of Feature Diagramming taken from chapter 4, pp. 82-130 of Generative Programming by Krzysztof Czarnecki and Ulrich W. Eisenecker, Addison-Wesley, 2000.
The purpose of these diagrams is to capture the variation points within a system. I like these diagrams because they succinctly capture aspects of a system that UML has trouble articulating.
Introduction
A concept is the knowledge we have about the properties of an object that allow us to categorize or classify it. A feature is an important property of a concept. A feature model represents common and variable features of concepts and dependencies between the variable features. A feature diagram is a visual representation of these concepts, features, and relationships. It articulates the variation points in a system.
A feature diagram consists of concepts, which comprise features, which also comprise sub-features. The diagram can have as many levels as are necessary to describe the variation in the domain you are modeling.
The basic elements of a feature diagram are described below:
A concept or feature may have one or more mandatory features or sub-features, meaning every instance of a system contains the feature. Mandatory features are denoted with a filled circle at the end of the line relating the feature to the concept.
A concept or feature may also have one or more optional features which may or may not be included in any instance. Optional features are denoted with an open circle at the end of the line.
A concept or feature may have one or more sets of alternative features. In any system instance, one (and only one) feature from the set is included. An open arc between the feature lines denotes alternatives.
A concept or feature may have one or more features from a set of or-features. Any system instance has at least one of the features in the set. A filled arc between the features lines denotes or-features.
Alternative and or- features can be either mandatory or optional, as well. Because of the resulting semantics, certain relationships can be normalized out:
If one or more of the alternative features are optional, then all are optional alternatives.
If one or more of the or-features are optional, then all are optional features.
There are a set of interesting types of variation points:
A dimension is a concept where all features are alternative features.
A dimension with optional features is a concept where all features are alternative optional features.
An extension point is a concept that has at least one optional feature or one set of or-features.
An extension point with optional features is a concept where all features are optional features.
An extension point with or-features is a concept where all features are or-features.
To complete a feature model, you capture other information about each feature: a semantic description which may include other models, traceability links, and categories; rationale for why the feature is included and recommending when variable features should be included; stakeholders in the feature; exemplar systems demonstrating the feature; constraints and default dependency rules such as mutual-exclusion or requires constraints between features and suggested defaults; availability sites, binding sites, and binding modes describing when, where, and to whom a variable feature is available, is bound, and whether it is bound statically (can never be rebound), changeably (can be unbound and rebound if necessary), or dynamically bound (automatically bound before use and unbound after); open/closed attribute where the feature is open if new variable subfeatures are expected, and closed if not; and priorities to capture how commonly variable features are used in the domain, how fundamental they are to the feature model, and which are more important to implement first.
_______
This article was originally serialized on the following days:
27 August 2001: Feature Diagram Overview, Part 1
28 August 2001: Feature Diagram Overview, Part 2
29 August 2001: Feature Diagram Overview, Part 3
