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 models were first introduced in the Feature-Oriented Domain Analysis (FODA) method by Kang in 1990.[1] 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".[1] 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.[1]
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 that 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. [2]
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
Las relaciones entre una característica principal y sus características secundarias (o subcaracterísticas) se clasifican de la siguiente manera:
- Obligatorio : debe seleccionarse la función infantil.
- Opcional : la función secundaria puede seleccionarse o no seleccionarse.
- O bien , se debe seleccionar al menos una de las subcaracterísticas.
- Alternativa (xor) : se debe seleccionar exactamente una de las subcaracterísticas.
Además de las relaciones de parentesco entre las características, se permiten restricciones entre árboles. Las más comunes son:
- A requiere B : la selección de A en un producto implica la selección de B.
- A excluye a B : A y B no pueden formar parte del mismo producto.
Como ejemplo, la figura de la derecha ilustra cómo se pueden usar los modelos de características para especificar y construir sistemas de compra en línea configurables. El software de cada aplicación se define por las características que ofrece. La característica raíz (es decir, la tienda en línea) identifica el SPL. Cada sistema de compra implementa un catálogo, módulos de pago, políticas de seguridad y, opcionalmente, una herramienta de búsqueda. Las tiendas en línea deben implementar una política de seguridad alta o estándar (a elegir) y pueden ofrecer diferentes módulos de pago: transferencia bancaria, tarjeta de crédito o ambos. Además, una restricción de árbol cruzado obliga a los sistemas de compra que incluyen el módulo de pago con tarjeta de crédito a implementar una política de seguridad alta.
Modelos de características basados en la cardinalidad
Algunos autores proponen extender los modelos de características básicas con multiplicidades tipo UML de la forma [n,m], donde n es el límite inferior y m el límite superior. Estas se utilizan para limitar el número de subcaracterísticas que pueden formar parte de un producto cuando se selecciona el padre. [ 3 ]
Si el límite superior es *, la característica se puede clonar tantas veces como queramos (siempre que se respeten las demás restricciones). Esta notación es útil para productos extensibles con un número arbitrario de componentes.
Modelos con características extendidas
Otros sugieren agregar información extrafuncional a las características mediante "atributos". Estos se componen principalmente de un nombre, un dominio y un valor. [ 4 ]
Semántica
La semántica de un modelo de características es el conjunto de configuraciones de características que permite dicho modelo. El enfoque más común consiste en utilizar lógica matemática para capturar la semántica de un diagrama de características. [ 5 ] Cada característica corresponde a una variable booleana y la semántica se captura como una fórmula proposicional . Las valuaciones que satisfacen esta fórmula corresponden a las configuraciones de características permitidas por el diagrama de características. Por ejemplo, sies una subcaracterística obligatoria deLa fórmula contendrá la restricción.. [ 6 ]
La siguiente tabla proporciona una traducción de las primitivas básicas. Suponemos que el diagrama es un árbol con raíz.La semántica de un diagrama completo es una conjunción de las traducciones de los elementos que contiene. Por lo tanto, si todos los elementos están escritos en forma normal conjuntiva (FNC), los términos se pueden combinar fácilmente con la operación lógica AND y la expresión lógica resultante permanecerá en FNC.
Configuración de productos
Un producto del SPL se especifica de forma declarativa seleccionando o deseleccionando características según las preferencias del usuario. Dichas decisiones deben respetar las restricciones impuestas por el modelo de características. Un "configurador" es una herramienta que asiste al usuario durante el proceso de configuración. Por ejemplo, seleccionando o deseleccionando automáticamente las características que deben o no deben seleccionarse, respectivamente, para que la configuración se complete correctamente. Los enfoques actuales utilizan propagación de unidades [ 7 ] y solucionadores CSP [ 4 ] .
Propiedades y análisis
Un análisis de un modelo de características se centra en ciertas propiedades del modelo que son importantes para las estrategias de marketing o las decisiones técnicas. En la literatura se identifican varios análisis. [ 8 ] [ 9 ] Los análisis típicos determinan si un modelo de características está vacío (no representa ningún producto), si contiene características muertas (características que no pueden formar parte de ningún producto) o el número de productos de la línea de productos de software representada por el modelo. Otros análisis se centran en comparar varios modelos de características (por ejemplo, para comprobar si un modelo es una especialización , una refactorización o una generalización de otro). [ 10 ]
Véase también
- Análisis de dominio
- Ingeniería de dominios
- Programación orientada a características : un paradigma para la síntesis de líneas de productos de software.
- Ingeniería de Familias de Productos
- Líneas de productos de software
Referencias
- 1 2 3 Kang, KC y Cohen, SG y Hess, JA y Novak, WE y Peterson, AS, "Estudio de viabilidad del análisis de dominio orientado a características (FODA)", Informe técnico CMU/SEI-90-TR-021, SEI, Universidad Carnegie Mellon, noviembre de 1990 descargar
- ↑ "Árbol de características | BAwiki" .
- ↑ Czarnecki, K. y Helsen, S. y Eisenecker, U., "Configuración por etapas utilizando modelos de características", Actas de la Tercera Conferencia Internacional sobre Líneas de Productos de Software (SPLC '04), volumen 3154 de Lecture Notes in Computer Science. Springer Berlin/Heidelberg, agosto de 2004. Descargar .
- ↑ Schobbens, P.-Y.; Heymans, P.; Trigaux, J.-C., " Diagramas de características: una revisión y una semántica formal "," Ingeniería de Requisitos, 14.ª Conferencia Internacional IEEE, vol., n.º, págs. 139-148, 11-15 de septiembre de 2006 (descargar)
- ↑ Amador Durán, David Benavides, Sergio Segura, Pablo Trinidad y Antonio Ruiz-Cortés «FLAME: un marco formal para el análisis automatizado de líneas de productos de software validadas mediante pruebas de especificación automatizadas». Software and System Modeling. 2015. Descargar
- ↑ Batory, D., "Modelos de características, gramáticas y fórmulas proposicionales", Actas de la 9.ª Conferencia Internacional sobre Líneas de Productos de Software (SPLC '05) descargar
- ↑ T. Thuem, D. Batory y C. Kaestner. " Razonamiento sobre las modificaciones a los modelos de características "Conferencia Internacional sobre Ingeniería de Software (ICSE), mayo de 2009.
Enlaces externos
- Wiki del repositorio de modelos de características
- Ingeniería de líneas de productos de software con modelos de características
- Requisitos de software