Concepts

Feature models

A feature model represents the information of all possible products of a software product line in terms of features and relationships among them. Feature models are a special type of information model widely used in software product line engineering. A feature model is represented as a hierarchically arranged set of features composed by:

  1. relationships between a parent (or compound) feature and its child features (or subfeatures).
  2. cross-tree (or cross-hierarchy) constraints that are typically inclusion or exclusion statements in the form: if feature F is included, then features A and B must also be included (or excluded).

Figure 1 depicts a simplified feature model inspired by the mobile phone industry. The model illustrates how features are used to specify and build software for mobile phones. The software loaded in the phone is determined by the features that it supports. According to the model, all phones must include support for calls, and displaying information in either a basic, colour or high resolution screen. Furthermore, the software for mobile phones may optionally include support for GPS and multimedia devices such as camera, MP3 player or both of them.

 

 Figure 1: A sample feature model

 

 

Feature models are used in different scenarios of software production ranging from model driven development [1], feature oriented programming [2], software factories [3] or generative programming [4], all of them around software product line development. Although feature models are studied in software product line engineering, these information models can be used in different contexts ranging from requirements gathering [5] to data model structures, hence the potential importance of feature models in the information systems domain. The term feature model was coined by Kang et al. in the FODA report back in 1990 [6] and has been one of the main topics of research in software product lines since then. There are different feature model languages. We refer the reader to [7] for a detailed survey on the different feature model languages. Below, we review the most well known notations for those languages.

Basic feature models

We group as basic feature models those allowing the following relationships among features:

  • Mandatory. A child feature has a mandatory relationships with its parent when the child is included in all products in which its parent feature appears. For instance, every mobile phone system in our example must provide support for calls.
  • Optional. A child feature has an optional relationship with its parent when the child can be optionally included in all products in which its parent feature appears. In the example, software for mobile phones may optionally include support for GPS.
  • Alternative. A set of child features have an alternative relationship with their parent when only one feature of the children can be selected when its parent feature is part of the product. In the example, mobile phones may include support for a basic, colour or high resolution screen but only one of them.
  • Or. A set of child features have an or-relationship with their parent when one or more of them can be included in the products in which its parent feature appears. In Figure 1, whenever Media is selected, Camera, MP3 or both can be selected.

Notice that a child feature can only appear in a product if its parent feature does. The root feature is a part of all the products within the software product line. In addition to the parental relationships between features, a feature model can also contain cross-tree constraints between features. These are typically in the form:

  • Requires. If a feature A requires a feature B, the inclusion of A in a product implies the inclusion of B in such product. Mobile phones including a camera must include support for a high resolution screen.
  • Excludes. If a feature A excludes a feature B, both features cannot be part of the same product. GPS and basic screen are incompatible features.

More complex cross-tree relationships have been proposed later in the literature [8] allowing constraints in the form of generic propositional formulas, e.g. "A and B implies not C".


Figure 2: A sample extended feature model

 

Cardinality-based feature models

Some authors propose extending FODA feature models with UML-like multiplicities (so-called cardinalities) [9],[10]. Their main motivation was driven by practical applications [11] and "conceptual completeness". The new relationships introduced in this notation are defined as follows:

  • Feature cardinality. A feature cardinality is a sequence of intervals denoted [n..m] with n as lower bound and m as upper bound. These intervals determine the number of instances of the feature that can be part of a product. This relationship may be used as a generalization of the original mandatory ([1,1]) and optional ([0,1]) relationships defined in FODA.
  • Group cardinality. A group cardinality is an interval denoted ⟨n..m ⟩, with n as lower bound and m as upper bound limiting the number of child features that can be part of a product when its parent feature is selected. Thus, an alternative relationship is equivalent to a ⟨1..1 ⟩ group cardinality and an or-relationship is equivalent to ⟨1..N ⟩, being N the number of features in the relationship.

Extended feature models

Sometimes it is necessary to extend feature models to include more information about features. This information is added in terms of so-called feature attributes. This type of models where additional information is included are called extended, advanced or attributed feature models. FODA [6], the seminal report on feature models, already contemplated the inclusion of some additional information in feature models. For instance, relationships between features and feature attributes were introduced. Later, Kang et al. [12] make an explicit reference to what they call "non-functional" features related to feature attributes. In addition, other groups of authors have also proposed the inclusion of attributes in feature models [8][13],[14],[15],[16],[17],[18],[19]. There is no consensus on a notation to define attributes. However, most proposals agree that an attribute should consist at least of a name, a domain and a value. Figure 2 depicts a sample feature model including attributes using the notation proposed by Benavides et al. in [14]. As illustrated, attributes can be used to specify extra-functional information such as cost, speed or RAM memory required to support the feature. Extended feature models can also include complex constraints among attributes and features like: "If attribute A of feature F is lower than a value X, then feature T can not be part of the product".

Automated analysis on feature models

Section 4 of the paper

External references can be also found in the original paper.


References

  1. Citekey trujillo07-icse not found
  2. Citekey batory05-GTTSE not found
  3. Citekey Greenfield04-BOOK not found
  4. Citekey Czarnecki00-BOOK not found
  5. Citekey classen08-fase not found
  6. K. Kang, S. Cohen, J. Hess, W. Novak, S. Peterson.  1990.  Feature–Oriented Domain Analysis (FODA) Feasibility Study.
  7. Schobbens P-Y, P. Heymans, Trigaux JC, Y. Bontemps.  2007.  Generic semantics of feature diagrams. Computer Networks. 51:456–479.
  8. D. Batory.  2005.  Feature Models, Grammars, and Propositional Formulas. Software Product Lines Conference. 3714:7–20.
  9. Citekey czarnecki05b-spip not found
  10. Citekey Riebisch02-IDPT not found
  11. Citekey Czarnecki02-GPCE not found
  12. Citekey Kang98 not found
  13. D. Batory, Benavides D, Ruiz-Cortés A.  2006.  Automated Analysis of Feature Models: Challenges Ahead. Communications of the ACM. December:45–47.
  14. Benavides D, Ruiz-Cortés A, Trinidad P.  2005.  Automated Reasoning on Feature Models. Advanced Information Systems Engineering: 17th International Conference, CAiSE. 3520:491–503.
  15. Benavides D, Ruiz-Cortés A, Trinidad P.  2005.  Using Constraint Programming to Reason on Feature Models. The Seventeenth International Conference on Software Engineering and Knowledge Engineering, SEKE 2005. :677–682.
  16. Citekey czarnecki05-spip not found
  17. K. Czarnecki, P. Kim.  2005.  Cardinality-Based Feature Modeling and Constraints: A Progress Report. Proceedings of the International Workshop on Software Factories At OOPSLA 2005.
  18. Citekey Streitferdt03 not found
  19. J. White, B. Doughtery, D. Schmidt.  2009.  Selecting Highly Optimal Architectural Feature Sets with Filtered Cartesian Flattening. Journal of Systems and Software. 82:1268–1284.