View source for Hilbert metric

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. {{Citation needed|date=April 2009}}

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 models were first introduced in the [[Feature-Oriented Domain Analysis]] (FODA) method by Kang in 1990.<ref name="KangEtAl90">Kang, K.C. and Cohen, S.G. and Hess, J.A. and Novak, W.E. and Peterson, A.S., "Feature-oriented domain analysis (FODA) feasibility study", Technical Report CMU/SEI-90-TR-021, SEI,
Carnegie Mellon University, November 1990
[http://www.sei.cmu.edu/reports/90tr021.pdf download]</ref> Since then, feature modeling has been widely adopted by the software product line community and a number of extensions have been proposed.

==Background==
A "feature" is defined as a "prominent or distinctive user-visible aspect, quality, or characteristic of a [[software system]] or system".<ref name="KangEtAl90"/> 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.<ref name="KangEtAl90"/>

===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. {{Citation needed|date=April 2009}}

===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 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 subfeatures) are categorized as:
* Mandatory&nbsp;– child feature is required.
* Optional&nbsp;– child feature is optional.
* Or&nbsp;– at least one of the sub-features must be selected.
* Alternative (xor)&nbsp;– 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&nbsp;– The selection of A in a product implies the selection of B.
* A excludes B&nbsp;– A and B cannot be part of the same product.

As an example, the figure below 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.

[[Image:E-shopFM.jpg|475px|right|thumb|A feature diagram representing a configurable e-shop system.]]

<!-- Car feature model
[[Image:Car_FeatureModel_with_Legend.svg|700px|right|thumb|A feature diagram representing a configurable car.]] -->

===Cardinality-based feature models===
Some authors propose extending basic feature models with [[Unified Modeling Language|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.<ref>Czarnecki, K. and Helsen, S. and Eisenecker, U., "Staged configuration using feature models", Proceedings of the Third International Conference on Software Product Lines (SPLC '04), volume 3154 of Lecture Notes in Computer Science. Springer Berlin/Heidelberg, August 2004. [http://www.springerlink.com/content/n3wn2b2dmumke6lu/ download].</ref>

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.

===Extended feature models===
Others suggest adding extra-functional information to the features using "attributes". These are mainly composed of a name, a domain, and a value.<ref name="benavides05-caise">D. Benavides, P. Trinidad and A. Ruiz-Cortés. "Automated Reasoning on Feature Models". 17th Conference on Advanced Information Systems Engineering (CAiSE'05). Porto, Portugal. 2005 [http://dx.doi.org/10.1007/11431855_34 download]</ref>

==Semantics==
The semantics of a feature model is the set of feature configurations that the feature model permits. The most common approach is to use mathematical logic to capture the semantics of a feature diagram. Each feature corresponds to a [[boolean variable]] and the semantics is captured as a [[propositional formula]]. The satisfying valuations of this formula correspond to the feature configurations permitted by the feature diagram.
For instance, if <math>f_1</math> is a mandatory sub-feature of <math>f_2</math>, the formula will contain the constraint <math>f_1 \Leftrightarrow f_2</math>.<ref name="Schobbens">Schobbens, P.-Y.; Heymans, P.; Trigaux, J.-C., "Feature Diagrams: A Survey and a Formal Semantics," Requirements Engineering, 14th IEEE International Conference , vol., no., pp.139-148, 11-15 Sept. 2006 [http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1704057&isnumber=35962 download]
</ref>

The following table provides a translation of the basic primitives. The semantics of a diagram is a conjunct of the translations of the elements contained in the diagram. We assume that the diagram is a rooted tree.

{| class="wikitable" border="1"
|-
! Feature Diagram Primitive
! Semantics
|-
|<math>r</math> is the root feature
|<math>r</math>
|-
| <math>f_1</math> optional sub-feature of <math>f</math>
| <math>f_1 \Rightarrow f</math>
|-
| <math>f_1</math> mandatory sub-feature of <math>f</math>
| <math>f_1 \Leftrightarrow f</math>
|-
| <math>f_1,\dots,f_n</math> alternative sub-features of <math>f</math>
| <math>\left(f_1 \lor \dots \lor f_n \Leftrightarrow f\right) \land
\bigwedge_{i<j}\lnot(f_i \land f_j)
  </math>
|-
| <math>f_1,\dots,f_n</math> or sub-features of <math>f</math>
| <math>f_1 \lor \dots \lor f_n \Leftrightarrow f</math>
|-
| <math>f_1</math> excludes <math>f_2</math>
| <math>\lnot(f_1 \land f_2)</math>
|-
| <math>f_1</math> requires <math>f_2</math>
| <math> f_1 \Rightarrow f_2</math>
|}

==Configuring feature models==
A product of the SPL is declaratively specified by selecting or deselecting features according to user's preferences. Such decisions must respect the constraints imposed by the feature model. A "configurator" is a tool that assists the user during a configuration process. For instance by automatically selecting or deselecting features that must or must not, respectively, be selected for the configuration to be completed successfully. Current approaches use [[unit propagation]]<ref>Batory, D., "Feature Models, Grammars, and Propositional Formulas",  Proceedings of the 9th International Software Product Line Conference (SPLC '05) [ftp://ftp.cs.utexas.edu/p-ub/predator/splc05.pdf download]</ref>  and [[Constraint satisfaction problem|CSP solvers]].<ref name="benavides05-caise"/>

==Properties and analyses==
An analysis of a feature model targets certain properties of the model which are important for marketing strategies or technical decisions. A number of analyses are identified in the literature.<ref name="benavides06-jisbd">D. Benavides, A.Ruiz-Cortés, P. Trinidad and S. Segura.  "A Survey on the Automated Analyses of Feature Models" . Jornadas de Ingeniería del Software y Bases de Datos (JISBD'06). Sitges, Spain. 2006</ref><ref name="benavides10-is">David Benavides, Sergio Segura and Antonio Ruiz Cortés. Automated Analysis of Feature Models 20 Years Later: A Literature Review
http://dx.doi.org/10.1016/j.is.2010.01.001 Information Systems . Elsevier. 2010. 35(6). September 2010.</ref> Typical analyses determine whether a feature model is void (represents no products), whether it contains dead features (features that cannot be part of any product) or what is the number of products of the software product line represented by the model. Other analyses focus on comparing several feature models (e.g. to check whether a model is a [[Specialization (logic)|specialization]] or [[Code refactoring|refactoring]] or [[generalization]] of another).<ref name="thuem09-icse">T. Thuem, D. Batory, and C. Kaestner. "Reasoning about Edits to Feature Models". International Conference on Software Engineering (ICSE), May 2009.</ref>

==Tools==
Some tools supporting the editing and/or analyses of feature models are:
* [http://www.cs.utexas.edu/users/schwartz/ATS.html Ahead Tool suite]
* [http://www.isa.us.es/betty/ BeTTy Framework]
* [http://www.isa.us.es/betty/betty-online BeTTy Online Feature Model Generator]
* [http://www.clafer.org Clafer]
* [http://www.eclipse.org/proposals/feature-model/ Eclipse Modeling Framework Feature Model Project]
* [http://www.isa.us.es/fama/ FaMa Tool Suite]
* [http://gsd.uwaterloo.ca/projects/fmp-plugin/ Feature Model Plug-in]
* [http://giro.infor.uva.es/FeatureTool.html Feature Modeling Tool, a plug-in for Visual Studio 2008]
* [http://familiar-project.github.com/ FAMILIAR]
* [http://fosd.de/fide/ FeatureIDE]
* [http://caosd.lcc.uma.es/spl/hydra/index.htm Hydra]
* [http://www.pros.upv.es/mfm/ MOSKitt Feature Modeler]
* [http://www.pure-systems.com/Variant_Management.49.0.html Pure::Variants]
* [http://www-lufgi3.informatik.rwth-aachen.de/TOOLS/requiline/ Requiline]
* [http://download.lero.ie/spl/s2t2/ S2T2 Configurator]
* [http://www.splot-research.org/ SPLOT (Software Product Line Online Tools)]
* [http://www.rise.com.br/english/products_toolday.php ToolDAy - Tool for Domain Analysis]
* [http://www.pnp-software.com/XFeature/ XFeature]
* [http://www.zipc.com/index.html ZIPC Feature]

==See also==
* [[Domain analysis]]
* [[Domain engineering]]
* [[FOSD|Feature-oriented Programming]] - a paradigm for software product line synthesis
* [[Product Family Engineering]]
* [[software product line|Software Product Lines]]

==References==
{{reflist}}

==External links==
* [http://www.splot-research.org/ Feature Model Repository and Online Tools]
* [http://fm.gsdlab.org/ Feature Model Repository Wiki]
* [http://www.methodsandtools.com/archive/archive.php?id=49 Software Product Line Engineering with Feature Models]

{{Software engineering}}

{{DEFAULTSORT:Feature Model}}
[[Category:Software requirements]]