Modelando la Variabilidad de Características Complejas en Líneas de Productos Software

Modelando la Variabilidad de Características Complejas en Líneas de Productos Software José Miguel Horcas, Mónica Pinto, and Lidia Fuentes Universidad de Málaga, CAOSD Group, Málaga, Spain {horcas,pinto,lff}@lcc.uma.es http://caosd.lcc.uma.es/ Resumen A pesar de la gran cantidad de trabajos y de herramientas existentes en el ámbito de las Líneas de Productos Software, muchos dominios de aplicación actuales como la ingeniería web no pueden verse beneficiados del uso de una Línea de Producto Software. Además, fuera del mundo académico, la empresa sigue siendo bastante reticente a usar este enfoque. En este artículo reflexionamos sobre las razones de esta falta de adopción, tanto desde el punto de vista de las características complejas que son imprescindibles en los sistemas actuales, como del soporte que las herramientas existentes proporcionan. Keywords: Líneas de Productos Software ·Modelado ·Soporte de herramientas ·Variabilidad 1. Introducción Las Líneas de Productos Software (SPL, de Software Product Line) [38] se han vuelto muy complejas debido a los exigentes requisitos de los actuales dominios de aplicación. Por ejemplo, si pensamos en aplicaciones para el Internet de las Cosas (IoT, de Internet of Things) o en sistemas ciberfísicos (CPS, de CiberPhysical System), aún sin tener en cuenta los requisitos específicos de la aplicación a desarrollar, aparecen numerosos requisitos del dominio de aplicación para los que las propuestas actuales de SPL, y en especial las herramientas que las soportan, no están preparadas [5,40]. Por un lado, al margen de la variabilidad propia de las aplicaciones, la variabilidad en muchos dominios actuales aparece en muchas otras dimensiones [30], como es en los dispositivos hardware sobre los que se desplegará la aplicación y en cómo pueden configurarse, en los despliegues alternativos que pueden llevarse a cabo tanto desde el punto de vista hardware como software y en como afectan a los atributos de calidad del sistema, o en la variabilidad del contexto de ejecución. Es necesario por tanto reflexionar sobre todas estas dimensiones de variabilidad, sobre si los modelos de variabilidad existentes son los apropiados para todas las dimensiones que es necesario modelar, sobre cuáles son las relaciones entre ellas y como se modelan [39]. Si pensamos por ejemplo en los modelos de características actuales y en las herramientas existentes, sin soporte para características clonables [19] no es posible modelar la variabilidad de un sistema IoT o CPS con múltiples dispositivos iguales (e.g., distintos sensores) [4], donde el número de sensores a desplegar variará para cada sistema y donde los parámetros de cada sensor se configurarán de forma diferente. Tampoco es posible definir y razonar sobre muchos de los parámetros de configuración de los dispositivos hardware de un CPS sin características numéricas y sin razonadores que sean capaces de manejar la complejidad añadida por estas características numéricas a la hora de resolver el modelo de variabilidad [26]. Por otro lado, la configuración de estos sistemas, tanto en tiempo de diseño como en tiempo de ejecución, debería estar dirigida mayormente por los atributos de calidad 2 Horcas et al. que el sistema debe satisfacer (e.g., rendimiento, latencia, consumo de energía) [51]. Esto exige que las configuraciones de estos sistemas deben poder generarse optimizando uno o varios de estos atributos de calidad [25]. Para conseguirlo debe ser posible razonar sobre el impacto de las distintas características del modelo de variabilidad en los atributos de calidad que se estén considerando, debe ser posible identificar un deterioro en el cumplimiento de esos atributos de calidad durante la ejecución del sistema y debe ser posible adaptar el sistema al nuevo contexto automáticamente de forma que sus atributos de calidad sigan estando en un rango aceptable. Aunque las características mencionadas anteriormente no son novedosas y hay multitud de propuestas de SPL que las tienen en cuenta [40], la realidad es que no están integradas en una sola propuesta que de respuesta a las necesidades de estos nuevos sistemas y, sobre todo, no están soportadas por las herramientas existentes. Cabe resaltar que a pesar de que existen más de un centenar de herramientas sobre SPL [5,34,37], hay aspectos sobre el modelado y resolución de la variabilidad que ninguna de ellas es capaz de cubrir correctamente. Esto hace que las empresas sean reticentes a adoptar un enfoque de SPL, al no contar con un soporte maduro de herramientas [40]. Por todos estos motivos, las SPLs no se utilizan fuera de su comunidad tanto como podría esperarse dado los beneficios que su uso proporcionaría en numerosos dominios de aplicación. El objetivo de este trabajo es reflexionar sobre la complejidad de modelar ciertas características de variabilidad que actualmente exigen las aplicaciones y que las herramientas de SPL no soportan. Para ello se identifican las características más complejas del modelado de la variabilidad que existen hoy en día en la industria y se analiza el soporte actual de las herramientas existentes de referencia en SPL exponiendo las limitaciones más importantes de ellas. Este trabajo expone las dificultades de la industria para adoptar los enfoques SPL, y sienta las bases sobre las características que debería tener una herramienta para dar soporte completo a un proceso de SPL en la industria. A partir de este trabajo, la comunidad de SPL puede comenzar el desarrollo de los artefactos adecuados (e.g., metamodelos, lenguajes, formatos) para definir una herramienta que cubra todas las necesidades exigidas por los proyectos actuales de SPL en la industria. El resto del artículo se estructura de la siguiente forma. La Sección 2 presenta el trabajo relacionado sobre modelado de la variabilidad y soporte de herramientas. La Sección 3 identifica las características de variabilidad en proyectos complejos y analiza el soporte de las herramientas actuales, discutiendo sus limitaciones y como debería ser el soporte ideal. Por último, la Sección 4 presenta las conclusiones y el trabajo futuro. 2. Trabajo Relacionado Existen una gran cantidad de trabajos que estudian el modelado de la variabilidad [8,28,39,40]. Sin embargo, el soporte de herramientas para llevarla a cabo ha sido estudiado principalmente en revisiones sistemáticas [5,34,37]. 2.1. Modelado de la variabilidad La mayoría de los trabajos sobre modelado de la variabilidad exploran diferentes dimensiones y relaciones entre los elementos de modelado [28]. La Figura 1 muestra un resumen de los trabajos más importantes sobre modelado de variabilidad y modelos de características. Hay que resaltar que no están todos los trabajos existentes, sino que se han incluido principalmente aquellos donde aparecieron por primera vez las características discutidas a lo largo del artículo. Modelando la Variabilidad de Características Complejas en SPLs 3 Kang et al. (1990) [27] Feature Models (FODA) Technical report Primera definición de los modelos de características (feature model) para modelar la variabilidad. Kang et al. (1990) [27] Feature Models (FODA) Technical report Primera definición de los modelos de características (feature model) para modelar la variabilidad. Kang et al. (1998) [29] FORM Ann. Softw. Eng. Introducción de diferentes puntos de vista (viewpoints). Kang et al. (1998) [29] FORM Ann. Softw. Eng. Introducción de diferentes puntos de vista (viewpoints). Griss et al. (1998) [22] FeatuRSEB ICSR Incorporación de binding time y notación para restricciones. Griss et al. (1998) [22] FeatuRSEB ICSR Incorporación de binding time y notación para restricciones. Czarnecki et al. (2000) [17] Generative Programming (GP) Thesis Redefinición de características alternativas a relaciones xor, y or. Czarnecki et al. (2000) [17] Generative Programming (GP) Thesis Redefinición de características alternativas a relaciones xor, y or. Czarnecki et al. (2002) [16] GP-Extended GPCE Características clonables (feature cardinality). Czarnecki et al. (2002) [16] GP-Extended GPCE Características clonables (feature cardinality). Benavides et al. (2005) [11] Extended-Feature Models CAiSE Características con atributos (feature attributes). Benavides et al. (2005) [11] Extended-Feature Models CAiSE Características con atributos (feature attributes). Lee et al. (2014) [30] Requirements Eng. Enfoque holístico (holistic approach) para el modelado de la variabilidad con múltiples puntos de vista (viewpoints). Lee et al. (2014) [30] Requirements Eng. Enfoque holístico (holistic approach) para el modelado de la variabilidad con múltiples puntos de vista (viewpoints). Grupos de multiplicidad y características clonables (cardinality features) Características con atributos (feature attributes) D. Batory et al. (2006) [7] Comm. of the ACM Automated analysis of feature models: challenges ahead D. Batory et al. (2006) [7] Comm. of the ACM Automated analysis of feature models: challenges ahead White et al. (2009) [50] SPLC Problema de la configuración en múltiples pasos (multi-step configuration problem). White et al. (2009) [50] SPLC Problema de la configuración en múltiples pasos (multi-step configuration problem). Modelos de variabilidad Bosch et al. (2001) [12] PFE Feature binding time. Bosch et al. (2001) [12] PFE Feature binding time. Variabilidad en la dimensión temporal (feature binding time)Características desde diferentes puntos de vista (feature viewpoints) Formalizaciones para el análisis de modelos de variabilidad Benavides et al. (2010) [8] Infor. Systems Análisis automático de la variabilidad: operaciones sobre modelos. Benavides et al. (2010) [8] Infor. Systems Análisis automático de la variabilidad: operaciones sobre modelos. D. Batory (2005) [6] SPLC Conexión entre gramáticas, modelos de características y lógica proposicional (SAT solver & feature models). D. Batory (2005) [6] SPLC Conexión entre gramáticas, modelos de características y lógica proposicional (SAT solver & feature models). Benavides et al. (2005) [10] SEKE Programación de restricciones (Constraint Programming) para el análisis de modelos de características. Benavides et al. (2005) [10] SEKE Programación de restricciones (Constraint Programming) para el análisis de modelos de características. Mannion (2002) [35] SPLC Lógica proposicional para el análisis de modelos de características. Mannion (2002) [35] SPLC Lógica proposicional para el análisis de modelos de características. Hallsteinsen et al. (2008) [23] J. Computer Líneas de Producto Software Dinámicas (Dynamic Software Product Lines). Hallsteinsen et al. (2008) [23] J. Computer Líneas de Producto Software Dinámicas (Dynamic Software Product Lines). Sousa et al. (2017) [45] SEAMS Restricciones temporales en Líneas de Producto Software Dinámicas. Sousa et al. (2017) [45] SEAMS Restricciones temporales en Líneas de Producto Software Dinámicas. Schmid & John (2004) [42] Decision Models Science of Comp. Progr. Análisis de la variabilidad con modelos de decisiones. Schmid & John (2004) [42] Decision Models Science of Comp. Progr. Análisis de la variabilidad con modelos de decisiones. Czarnecki et al. (2008) [20] Probabilistic Feature Models SPLC Modelos de características probabilísticos. Czarnecki et al. (2008) [20] Probabilistic Feature Models SPLC Modelos de características probabilísticos. Pohl et al. (2005) [38] OVM Book Modelos de variabilidad ortogonales (Orthogonal Variability Model) Pohl et al. (2005) [38] OVM Book Modelos de variabilidad ortogonales (Orthogonal Variability Model) Otros aspectos de modelado Thüm et al. (2009) [48] ICSE Clasificación de las posibles relaciones entre dos modelos de características. Thüm et al. (2009) [48] ICSE Clasificación de las posibles relaciones entre dos modelos de características. Schobbens et al. (2007) [43] Computer Networks Diferentes lenguajes para los modelos de características (survey). Schobbens et al. (2007) [43] Computer Networks Diferentes lenguajes para los modelos de características (survey). Leyenda: ■ Revistas ■ Conferencias ■ Libros y tesis ■ Informes técnicos Extiende, continúa, se basa, está relacionado,... Lee & Kang (2010) [32] SPLC Definición de contexto de uso (usage context) para configurar modelos de variabilidad. Lee & Kang (2010) [32] SPLC Definición de contexto de uso (usage context) para configurar modelos de variabilidad. Haugen et al. (2008) [52] CVL SPLC Intento de estandarización: Common Variability Language (CVL). Haugen et al. (2008) [52] CVL SPLC Intento de estandarización: Common Variability Language (CVL). Haugen et al. (2014) [24] BVR SPLC Extensión de CVL: Base Variability Resolution Models (BVR). Haugen et al. (2014) [24] BVR SPLC Extensión de CVL: Base Variability Resolution Models (BVR). Sinnema et al. (2004) [44] COVAMOF SPLC Framework para modelar la variabilidad y dependencias en Líneas de Producto Software. Sinnema et al. (2004) [44] COVAMOF SPLC Framework para modelar la variabilidad y dependencias en Líneas de Producto Software. Capilla & Dueñas (2001) [13] PFE Características con variables numéricas (numerical features). Capilla & Dueñas (2001) [13] PFE Características con variables numéricas (numerical features). Ferber et al. (2002) [21] SPLC Interacciones y dependencias entre características. Ferber et al. (2002) [21] SPLC Interacciones y dependencias entre características. Dependencias entre características Modelado de Atributos de calidad Zhang et al. (2014) [51] Software Qual. J. Modelado de atributos de calidad y configuración basada en ellos en Líneas de Producto Software. Zhang et al. (2014) [51] Software Qual. J. Modelado de atributos de calidad y configuración basada en ellos en Líneas de Producto Software. Horcas et al. (2018) [25] WeaFQAs Thesis Proceso de Líneas de Producto Software para modelar la variabilidad de atributos de calidad funcionales (FQAs). Horcas et al. (2018) [25] WeaFQAs Thesis Proceso de Líneas de Producto Software para modelar la variabilidad de atributos de calidad funcionales (FQAs). Lee & Kang (2003) [31] PFE Grupos de características conjuntamente enlazadas (feature binding unit) y estados (feature binding state). Lee & Kang (2003) [31] PFE Grupos de características conjuntamente enlazadas (feature binding unit) y estados (feature binding state). Czarnecki et al. (2004) [18] Cardinality-based Feature Model SPLC Características clonables grupos de características, multiplicidad, referencia entre modelos, y configuración por pasos. Czarnecki et al. (2004) [18] Cardinality-based Feature Model SPLC Características clonables grupos de características, multiplicidad, referencia entre modelos, y configuración por pasos. Czarnecki et al. (2005) [19] Soft. Process: Improv. and Pract. Formalización de modelos con características clonables y su especialización. Czarnecki et al. (2005) [19] Soft. Process: Improv. and Pract. Formalización de modelos con características clonables y su especialización. Figura 1. Resumen de los trabajos más importantes sobre modelado de variabilidad. Desde la introducción de los modelos de características por Kang et al. en 1990 [27], infinidad de extensiones y lenguajes han sido propuestos [17,43]. Por un lado, no hay un estándar para el modelado de la variabilidad, por lo que han surgido distintas propuestas para modelar conceptos similares, como los modelos de variabilidad ortogonales [38], los modelos de características probabilísticos [20], o lo modelos de decisiones [42]. Aunque hubo un intento de estandarización con la definición de CVL [52] y BVR [24], esta no finalizó satisfactoriamente. Por otro lado, se han definido múltiples versiones de modelos de características “extendidos” [16], por ejemplo, para añadir atributos a las características [7,11], para definir grupos de multiplicidad y características clonables [18,19], para definir características numéricas [13], para modelar las interacciones y dependencias entre características [21,44,48], para considerar múltiples puntos de vista [29,30], para modelar atributos de calidad [25,51] o el contexto de uso [32]. Desafortunadamente, no existe una propuesta conjunta en la que poder utilizar todas estas características. Además, el problema se complica si tenemos en cuenta la dimensión temporal [12,22,31] o la configuración del modelo en múltiples pasos [50], o cuando queremos llevar esas características a tiempo de ejecución con Líneas de Productos Software Dinámicas (DSPL, de Dynamic Software Product Lines) [23], pudiendo incluso añadir restricciones temporales [45]. 2.2. Soporte de herramientas para modelar la variabilidad Existen varias revisiones sistemáticas que estudian el soporte de herramientas para SPLs [5,34,37]. El problema de estos trabajos es que estudian las herramientas desde el punto de vista de su documentación y/o artículo de referencia. Sin embargo, la mayoría de los detalles técnicos de las herramientas suelen estar en tesis, informes técnicos y páginas webs, que no suelen ser considerados estudios primarios en las revisiones sistemáticas [5]. Además, estos estudios se quedan anticuados muy pronto debido a que no suelen testear las herramientas de forma práctica, descargarlas, instalarlas y usarlas. 4 Horcas et al. 73% 24% 3% Modelado de la variabilidad Implementación de la variabilidad y generación de productos SPL en general 12% 88% Disponibles y usables No disponibles o no funcionales Figura 2. Clasificación de herramientas de SPL. Esto implica que la mayoría de las herramientas analizadas en esos estudios no están ni siquiera disponibles [34,37]. Otro problema de las revisiones sistemáticas existentes es que su análisis se queda en un nivel muy alto, indicando solo si una determinada fase de las SPLs está cubierta o no, pero sin entrar en los detalles sobre como se proporcionan las características específicas y si es la forma apropiada [37]. La conclusión es que este tipo de estudios no son suficientes para analizar las dificultades de la industria para adoptar un enfoque SPL [5]. De estos estudios [5,34,37] se extrae que el 73 % de las herramientas de SPL (de un total de 97) se enfocan en modelar la variabilidad. A partir de estas herramientas se ha realizado un estudio empírico descargando y probando las herramientas, que ha dado como resultado que solo el 12 % están disponibles para descargar y/o son utilizables (Figura 2) — i.e., son versiones estables que funcionan correctamente sin errores. En la siguiente sección se tienen en cuenta las seis herramientas más relevantes [5]. 3. Modelado de la variabilidad en SPL complejas Esta sección presenta los aspectos de modelado de la variabilidad más complejos que aparecen en los proyectos actuales de SPL y que no están debidamente cubiertos por las herramientas existentes, lo que muchas veces impide la adoptación de la SPL en las empresas. Para cada aspecto o característica, describimos brevemente en qué consiste, damos un ejemplo de aplicación o domino en el cual se usa o requiere de dicha característica de modelado, presentamos el soporte que dan las herramientas existentes, y discutimos como debería ser el soporte ideal para dicha característica. La Tabla 1 resume el soporte actual de las herramientas existentes para cada uno de los aspectos descritos. Se han escogido esas herramientas porque son las más relevantes, están disponibles para descargar y tiene buena usabilidad [5,34,37]. 3.1. Modelado de la variabilidad El soporte más básico para modelar la variabilidad en cualquier dominio de aplicación incluye la posibilidad de definir características opcionales (optional features), obligatorias (mandatory features), grupos de multiplicidad (or yxor), y restricciones simples (del tipo requires yexcludes). Prácticamente, todas las herramientas de modelado existentes soportan estas características básicas como muestra la Tabla 1. En esta sección nos centramos en el modelado de aquellas características de variabilidad más complejas. Modelando la Variabilidad de Características Complejas en SPLs 5 Tabla 1. Soporte práctico de las herramientas de modelado de la variabilidad en SPLs. Características S.P.L.O.T.1 Glencoe2 Clafer3 FAMA4 FeatureIDE5 pure::variants6 Modelado de la variabilidad Modelado básico de la variabilidad - Características opcionales, obligatorias, grupos de características (or,xor), restricciones (requires,excludes).       Modelo de características extendidos - Características con atributos.    Características con tipo variable - Características numéricas (integer,float), cadenas de caracteres (string), etc.  Características con cardinalidad - Características clonables.     Restricciones complejas y otras extensiones - Lógica de segundo orden, lógica modal, lenguajes de restricciones (OCL), características abstractas, grupos de multiplicidad arbitrarios, etc.    Análisis de la variabilidad Análisis automático de modelos de variabilidad - Validación, estadísticas y métricas, operaciones de análisis (características muertas, anomalías,. . . ).       Generación de configuraciones y proceso de configuración - Número de configuraciones, enumeración de configuraciones, optimización de configuraciones, configuración parciales, configuración por pasos, etc.     Gestión de los modelos Composición de características y múltiples puntos de vista - Unidades de modularización (composite units), y viewpoints: objetivos, contexto, atributos de calidad, despliegue, tecnologías, funcionalidad, etc.     Formato de los modelos y compatibilidad entre herramientas - Estándarización, formato intercambiables, importación/exportación, etc.    Evolución de los modelos - Modificación de características (e.g., cambiar el tipo de variabilidad de una características, moverla a otra parte del modelo, etc.).     Trazabilidad e independencia de la variabilidad - Independencia y relación entre el modelo de variabilidad y los artefactos.       Soporte completo. Soporte parcial. Sin soporte. 1S.P.L.O.T. [36]: http://www.splot-research.org/ 2Glencoe [1]: https://glencoe.hochschule-trier.de/ 3Clafer [2]: https://www.clafer.org/ 4FAMA [9]: https://www.isa.us.es/fama/ 5FeatureIDE [33,49]: http://www.featureide.com/ 6pure::variants [46]: https://www.pure-systems.com/ Modelando propiedades no funcionales Descripción: Benavides et al. [11] introdujo los modelos de características extendidos que permiten definir atributos sobre las características del modelo de variabilidad. Estos atributos suelen usarse para modelar propiedades no funcionales del sistema como el coste de una característica, su rendimiento, latencia, consumo de memoria, etc. Dominio de aplicación: Aquellas aplicaciones que necesiten desplegar configuraciones acorde a ciertas propiedades no funcionales del sistema y optimizar configuraciones. Por ejemplo, las aplicaciones móviles pueden desplegarse con configuraciones que minimicen el consumo de batería según el contexto del dispositivo en el que se ejecuten. Soporte práctico: Ni S.P.L.O.T. ni Glencoe soportan características con atributos. Clafer permite modelar atributos como características adicionales con tipo variable (e.g., 6 Horcas et al. variables enteras o reales). Esto quiere decir que para cada característica del árbol de variabilidad debemos añadir una nueva variable que defina ese atributo (e.g., coste) y que funciona como cualquier otra característica del árbol, debiendo seleccionarse dicha variable como una características más cuando se generen configuraciones del modelo. Esta solución es muy poco práctica porque incrementa de forma innecesaria el grado de variabilidad del modelo. FeatureIDE soporte los atributos solo parcialmente, ya que requiere usar un tipo especial de extensión o composer que no es compatible con el resto de plugins para implementar la variabilidad, por lo que solo permite especificar los atributos a nivel del árbol de variabilidad, además de tener que especificarlos directamente en el XML del modelo sin poder usar el editor gráfico para ello. Por el contrario, pure::variants y FAMA ofrecen soporte completo para los atributos. Discusión: Los atributos son propiedades de las características del modelo de variabilidad por lo que tienen que ser definidas como tal y no como características propias (features) en si mismas [11] (como ocurre con Clafer). Los atributos pueden ser considerados a la hora de generar configuraciones basadas en sus valores (e.g., propiedades no funcionales) para optimizar las configuraciones. Sin embargo, valores diferentes de un atributo asociado a una característica no supone una configuración diferente del modelo porque un atributo no es un punto de variación. Por otro lado, existen enfoques específicos y más adecuados para modelar la variabilidad de propiedades no funcionales como el framework NFR [14], y que sería deseable integrar en una herramienta de SPL. Variabilidad de grano fino: parámetros variables Descripción: Una característica con tipo variable [15] define un punto de variación en el cual hay que proporcionar un valor (e.g., entero, real, cadena de caracteres, fecha) para resolver esa variabilidad. Es importante diferenciar entre características con tipo variable, que son aquellas que requieren proporcionar un valor cuando se genere una configuración del modelo, y características con atributos [11], que son usadas para modelar propiedades no funcionales de las características. Dominio de aplicación: En muchas aplicaciones es necesario modelar la variabilidad de parámetros configurables o variables del sistema (e.g., tamaño del mensaje en kB, número de píxeles en una imagen, etc). En estos casos la forma adecuada de modelarlos es usando características con tipo variable. Soporte práctico: Clafer es la herramienta con mejor soporte para características con tipo variable. Clafer permite definir variables con un tipo específico (e.g., enteros o reales), así como definir restricciones sobre los valores de dichas variables. El resto de herramientas no soportan este tipo de características, aunque en pure::variants pueden modelarse como si fueran atributos. Discusión: El soporte para características con tipo variable es confuso debido a la sutil diferencia que existe con las características con atributos. Hay que tener en cuenta que un valor diferente en una característica con tipo variable supone una configuración diferente del modelo de variabilidad, mientras que un valor diferente de un atributo asociado a una característica no supone una configuración diferente (aunque actualmente no hay consenso en la comunidad sobre esto). Por otro lado, si el rango de valores que puede tener una variable no es muy elevado, se puede discretizar y modelarse como características normales que representan cada uno de los valores. Si por el contrario el rango de valores es muy amplio, sería deseable poder definir intervalos de valores. Modelando la Variabilidad de Características Complejas en SPLs 7 Modelando múltiples instancias de una misma característica Descripción: Czarnecki et al. [19] introdujo el concepto de modelos de características con cardinalidad (clonables), donde a una característica se le puede asociar una cardinalidad (e.g., [1..*]) indicando que puede ser instanciada múltiples veces. Esto permite configurar el subárbol correspondiente de esa característica de forma independiente para cada instancia. Dominio de aplicación: En sistemas IoT [4] y CPS [26], las características clonables son esenciales para modelar la variabilidad de los diferentes dispositivos, tanto a nivel hardware como software. Por ejemplo, una aplicación multi-tenant [25] necesitará modelar la variabilidad de los tenants como una característica clonable para posteriormente configurar cada instancia (tenant) de forma diferente. De igual modo, en un sistema multi-agente de una casa automatizada [3], cada agente que controla la funcionalidad de un electrodoméstico debe modelarse como una instancia de la característica clonable. Soporte práctico: Las características clonables es uno de los aspectos más difícil de implementar, y por lo tanto ninguna herramienta proporcionar un soporte completo para ellas. Clafer permite clonar cualquier características del modelo y configurar cada instancia, pero tiene que hacerse durante la fase de configuración del modelo y no durante el modelado de la variabilidad que es donde realmente se debería definir si una característica es clonable o no. FeatureIDE y pure::variants permiten un comportamiento similar a las clonables por medio de la incorporación de subárboles en el modelo de variabilidad. Sin embargo, esto obliga a decidir el número de instancias durante el modelado, cosa que se debería decidir durante la fase de configuración. Discusión: La cardinalidad de una característica clonable debe definirse en la ingeniería del dominio de la SPL, mientras que el número de instancias clonables para una configuración del modelo debe especificarse en la ingeniería de la aplicación. A su vez, es deseable especificar restricciones entre diferentes clones y para ello se necesita un soporte de restricciones más completo, como se discute en el siguiente punto. Modelando dependencias y otros aspectos Descripción: La incorporación de características clonables y características con tipo variable conllevan la posible inclusión de restricciones complejas. Por ejemplo, el modelado de dependencias entre características que son hijas de diferentes características clonables [19], o dependencias que tengan en cuenta valores numéricos. Dominio de aplicación: Cualquier aplicación o dominio que requiera de características no básicas como las clonables o las variables numéricas necesitará definir restricciones sobre ellas. Soporte práctico: Solo Clafer (con restricciones que pueden incluir variables numéricas) y pure::variants (con Prolog o su propia variante de OCL: pvSCL [46]) permiten definir restricciones complejas. El resto de herramientas solo permiten definir restricciones con lógica de primer orden (and,or,not,implies). Discusión: Las herramientas deberían proporcionar la posibilidad de definir restricciones en lógica de mayor orden (high-order logic constraints), en lenguajes estándares de modelado de restricciones como OCL, lenguajes de programación como Prolog, o incluso definir su propio lenguaje de restricciones si fuera necesario, como ocurre con pure::variants y pvSCL [46]. Estas restricciones se deberían poder aplicar sobre cualquier característica del modelo o incluso sobre diferentes modelos de variabilidad. 8 Horcas et al. 3.2. Análisis de la variabilidad Una vez modelada la variabilidad es importante poder razonar sobre ella [6] y analizar las posibles configuraciones del modelo. Análisis automático de la variabilidad Descripción: Benavides et al. [8] presenta una revisión sistemática sobre análisis de la variabilidad y define un conjunto de operaciones sobre los modelos de variabilidad: desde la validación del modelo hasta la generación de configuraciones, pasando por la identificación de anomalías, métricas y propiedades (homogeneidad, grado de variabilidad, ortogonalidad,. . . ), estadísticas (características comunes y variables, conjunto atómicos,. . . ) y optimización de configuraciones. Para ello es necesario poder definir o transformar el modelo de variabilidad a diferentes formalizaciones como satisfacción de restricciones (SAT) [6,35], diagramas de decisión binarios (BDD, de Binary Decision Diagrams) [7], o programación con restricciones [10]. Dominio de aplicación: El análisis automático de la variabilidad es deseable en cualquier dominio de aplicación, pero su importancia se incrementa en aquellos dominios donde el número de características es elevado, como en los sistemas IoT. Soporte práctico: Casi todas las herramientas proporcionan algún tipo de soporte para analizar los modelos de variabilidad. Clafer y FeatureIDE usan resolutores de propagación de restricciones (CPS, de Constraint Propagation Solver) [10], mientras que S.P.L.O.T., Glencoe y FAMA usan varios resolutores para soportar diferentes formalizaciones (SAT, BDD) [8,10]. Discusión: Dependiendo del análisis requerido, diferentes formalizaciones del modelo de variabilidad deberían ser soportadas. Por ejemplo, para analizar el grado de variabilidad es mejor utilizar una formalización en BDD [7] que permite contar el número de configuraciones válidas del modelo de manera directa en lugar de tener que generar todas las configuraciones para contarlas como haría un resolutor CPS [10]. Trabajando con configuraciones del modelo Descripción: Generar una configuración del modelo seleccionando las características requeridas no es trivial, sobre todo si necesitamos optimizar las configuraciones en base a algún criterio (e.g., propiedades no funcionales). Para ello puede ser útil trabajar con configuraciones parciales, realizar el proceso de configuración por pasos (step-by-step configuration) o en diferentes modelos (viewpoints), o incluso generar todas las posibles configuraciones (si fuera posible) para razonar sobre ellas. Dominio de aplicación: Aplicaciones que requieren generar configuraciones en base a objetivos o criterios. Por ejemplo, encontrar la configuración que minimiza el consumo energético de la aplicación [26]. Soporte práctico: Sólo S.P.L.O.T. (con un asistente para configuración por pasos) y Clafer (con un proceso de instanciación basado en restricciones) proporcionan un soporte razonable para configuraciones parciales y configuración por pasos. FeatureIDE y pure::variants permiten generar configuraciones parciales pero no incorporan ningún proceso guiado para asistir al usuario. Por otro lado, solo Clafer y FeatureIDE permiten generar y enumerar todas las configuraciones válidas, aunque esto no es factible para modelos muy grandes. Modelando la Variabilidad de Características Complejas en SPLs 9 Discusión: Hoy en día, ninguna herramienta permite generar todas las configuraciones de forma eficiente para modelos muy grandes. Es más, aunque las herramientas permiten calcular el número de configuraciones, no se tiene en cuenta las características numéricas en ese cálculo. Por otro lado, sería deseable asistir al usuario a la hora de generar una configuración del modelo de variabilidad informando en todo momento de las diferentes posibilidades (e.g., configuraciones óptimas, configuraciones inválidas,. . . ). De hecho, no existe ninguna herramienta operativa que permita generar configuraciones óptimas, por ejemplo, basadas en propiedades no funcionales del sistema [25]. 3.3. Gestión de los modelos de variabilidad En esta sección se discute la gestión y el tratamiento de los modelos de variabilidad, como su tamaño, los formatos, la evolución de los mismos y su conexión con los artefactos que implementan la variabilidad. Trabajando con modelos de gran tamaño Descripción: Los modelos de variabilidad de gran tamaño pueden llegar a ser inmanejables y es necesario dividirlos, usando unidades de modularización como por ejemplo composición de características (composite variability models) [15], múltiples puntos de vista (viewpoints), o incluso Líneas de Productos Múltiples (MultiPLs) [41]. Por ejemplo, siguiendo un enfoque holístico [30] la variabilidad del sistema se puede dividir en varios modelos interconectados. Por ejemplo, un modelo para especificar la variabilidad de los objetivos del usuario, otro para la variabilidad del contexto, otro para la variabilidad de los atributos de calidad, otro con la variabilidad de la funcionalidad principal del sistema, otro con la variabilidad de las tecnologías disponibles (e.g., lenguajes de programación), y otro con la variabilidad de los dispositivos para el despliegue del sistema [28]. Dominio de aplicación: Los sistemas de hoy en día disponen fácilmente de más de un centenar de características. Por ejemplo, la SPL del sistema operativo Linux contiene miles de características diferentes [7]. Un modelo con 100 características puede llegar a tener más de 1030 posibles configuraciones. Además, el problema del número de configuraciones se incrementa considerablemente si consideramos dominios donde intervienen las características clonables y los parámetros variables. Soporte práctico: Por un lado, ninguna herramienta ofrece un soporte adecuado para trabajar con modelos de gran tamaño (más de 100 características). Primero, los modelos deben ser definidos a mano, normalmente mediante un editor gráfico (salvo Clafer y FAMA), lo que dificultad trabajar con modelos grandes. Y segundo, dependiendo de la operación que se realice sobre el modelo (análisis, generación de configuraciones,. . . ), la complejidad del problema puede pasar de lineal a exponencial (muchas de estas operaciones son problemas NP-completos). Por otro lado, los modelos de variabilidad no se pueden modularizar de forma fácil con el soporte de herramientas existentes. Clafer permite definir múltiples modelos de variabilidad como clases abstractas pero todos ellos en el mismo fichero. FeatureIDE soporta MultiPLs [41] pero esta característica es un prototipo a día de hoy con muchos fallos, y además, el modelo de variabilidad en sí no puede dividirse en varios ficheros reutilizables. En pure::variants, el soporte es algo mejor ya que se define una relación de composición que permite definir un enlace entre modelos para incorporar uno dentro