Skip to content

Feature Models

Jump to bottom
lucaghera edited this page Apr 18, 2013 · 2 revisions

Feature models were proposed for the first time in 1990 in the context of the Feature Oriented Domain Analysis (FODA) approach. FODA aims to identify the properties and the functionality of a software, which are commonly present in applications of a specific domain, and separate them in two groups: those that are always present (stable point) and those that are present only in some applications (variation points and their variants). For representing these properties and functionality FODA proposes a formal method: the feature models. On the base of the feature models, the FODA experts have defined a graphical representation called feature diagram. The description of the Feature Models reported below refers to following feature diagram, which describes the functional variability of a motion planning product line.

Example of a feature diagram

A feature model is a hierarchical composition of features. A feature defines a software property and represents an increment in program functionality. Compose features, or in other words select a subset of all the features contained in a feature model, corresponds to define a possible configuration of a software that belongs to the application domain described by the model. This selection is usually called instance.

Feature models are organized as a tree and the root feature, also called concept, defines the application domain. Features are represented by means of white boxes, which contain the feature names, and are connected to the children features by means of edges, which represent containment relationships. Features can be discerned in two main categories:

  • Mandatory. Mandatory features have to be present in every possible configuration of a software that belongs to the domain described by the model. They usually define the core of the software and represent functionality or properties that are fundamental in the specific domain: the commonalities. In the feature diagrams they are depicted by means of a black circle on the top. In the example the Collision Checker functionality is a mandatory feature.

  • Optional. Optional features can be present but they are not manda- tory. They represent functionality or properties that characterize a specific configuration of the software: the variabilities. In the feature diagrams they are depicted by means of a white circle on the top. In the example the 3D environment model functionality is an optional feature, which means that not all the motion planning applications provide it.

Features can be connected to their children features by means of two types of containment relationships:

  • Or containment. It is a relationship between the parent feature and a set of children features. It means that from the children features at least one has to be present in a possible configuration of the software. In the example it is represented by the containment between the Sensors feature and its children. This relationship is depicted by means of the black semi-circle that connects the edges.
  • Alternative containment (X-Or). It is a relationship between the parent feature and a set of children features. It means that from the children features only one can be present in a possible configuration of the software. In the example it is represented by the containment between the Path Planner feature and its children. This relationship is depicted by means of the white semi-circle that connects the edges.

The basic feature models also define two kinds of constraints between the features: requires and excludes. These constraints allow the definition of a subset of valid configurations. They are typically expressed in the form A kind of constraint B, where A and B can be a simple feature or a composition of features by means of logical operators (AND, OR, XOR, NOT).

  • Requires constraint. It means that if a feature A is selected to be part of a configuration, then also a feature B has to be selected. If A and/or B represent logical rules the constraint imposes that if A is true, then also B has to be true. To be noticed that for solving the logical rules the value of a feature has to be considered true if the feature is selected.
  • Excludes constraint. It means that if a feature A is selected to be part of a configuration, then a feature B cannot be selected. If A and/or B represent logical rules the constraint imposes that if A is true, then B has to be false.

Cardinality-based feature models

The cardinality-based feature models propose to replace the properties optional and mandatory and the containments or and alternative with a cardinality- based annotation. In particular these ideas are proposed in two different works:

  • Feature-cardinality. The idea consists of marking each feature with a lower bound and an upper bound. The upper bound defines the maximum number of times that the feature can be present in an instance.
  • Containment-cardinality approach. The idea consists of marking each containment with a lower bound and an upper bound. The lower bound defines the minimum number of sub-features that have to be present in an instance whereas the upper bound the maximum number. According to this approach the containment relationships “or” and “alternative” are respectively replaced by [1 . . . ∗] and [1 . . . 1].

Extended feature models

The extended models propose to attach some information to the features by means of attributes. The purpose of the attributes is to allow a more concise representation of feature models. In fact the idea is to use the attributes for representing information that are important but not so relevant to be represented as features. Attributes are defined by means of a name, a type and a value.

Clone this wiki locally