Feature model-The Daily Ledger

In software development, a feature model is a compact representation of all the products of the Software Product Line (SPL) in terms of "features". Feature models are visually represented by means of feature diagrams. Feature models are widely used during the whole product line development process and are commonly used as input to produce other assets such as documents, architecture definition, or pieces of code.

A SPL is a family of related programs. When the units of program construction are features—increments in program functionality or development—every program in an SPL is identified by a unique and legal combination of features, and vice versa.

Feature model

Feature models were first introduced in the Feature-Oriented Domain Analysis (FODA) method by Kang in 1990. Since then, feature modeling has been widely adopted by the software product line community and a number of extensions have been proposed.

Feature model

Background

A "feature" is defined as a "prominent or distinctive user-visible aspect, quality, or characteristic of a software system or system". The focus of SPL development is on the systematic and efficient creation of similar programs. FODA is an analysis devoted to identification of features in a domain to be covered by a particular SPL.

Feature model

Model

A feature model is a model that defines features and their dependencies, typically in the form of a feature diagram + left-over (a.k.a. cross-tree) constraints. But also it could be as a table of possible combinations.

Diagram

A feature diagram is a visual notation of a feature model, which is basically an and-or tree. Other extensions exist: cardinalities, feature cloning, feature attributes, discussed below.

Configuration

A feature configuration is a set of features which describes a member of an SPL: the member contains a feature if and only if the feature is in its configuration. A feature configuration is permitted by a feature model if and only if it does not violate constraints imposed by the model...

Feature Tree

A Feature Tree (sometimes also known as a Feature Model or Feature Diagram) is a hierarchical diagram that visually depicts the features of a solution in groups of increasing levels of detail. Feature Trees are great ways to summarize the features that will be included in a solution and how they are related in a simple visual manner.

Feature modeling notations

Current feature modeling notations may be divided into three main groups, namely: Basic feature models Cardinality-based feature models Extended feature models

Basic feature models

Relationships between a parent feature and its child features (or sub-features) are categorized as: Mandatory – child feature must be selected. Optional – child feature can be selected or not selected. Or – at least one of the sub-features must be selected. Alternative (xor) – exactly one of the sub-features must be selected.

In addition to the parental relationships between features, cross-tree constraints are allowed. The most common are: A requires B – The selection of A in a product implies the selection of B. A excludes B – A and B cannot be part of the same product.

As an example, the figure to the right illustrates how feature models can be used to specify and build configurable on-line shopping systems. The software of each application is determined by the features that it provides. The root feature (i.e. E-Shop) identifies the SPL. Every shopping system implements a catalogue, payment modules, security policies and optionally a search tool. E-shops must implement a high or standard security policy (choose one), and can provide different payment modules: bank transfer, credit card or both of them. Additionally, a cross-tree constraint forces shopping systems including the credit card payment module to implement a high security policy.

Cardinality-based feature models

Some authors propose extending basic feature models with UML-like multiplicities of the form [n,m] with n being the lower bound and m the upper bound. These are used to limit the number of sub-features that can be part of a product whenever the parent is selected.

If the upper bound is m the feature can be cloned as many times as we want (as long as the other constraints are respected). This notation is useful for products extensible with an arbitrary number of components.