Análisis automático de líneas de producto software usando distintos modelos de variabilidad Fabricia Carneiro Roos, CT819422 frfrantz@unijui.edu.br Supervisado por Prof. Dr. David Benavides Cuevas and Antonio Ruiz Cortés Trabajo de investigación presentado en el Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Sevilla como parte de los requisitos a cumplir para obtener el título de Doctor Ingeniero en Informática. (Período de investigación)
Índice general 1. Introducción 1 1.1. Motivaciones............................. 2 1.2. Contexto de la investigación..................... 2 1.2.1. Líneas de producto software (SPL)............. 3 1.2.2. Modelos de características.................. 4 1.2.3. Análisis automático de modelos de características..... 5 1.3. Hipótesis............................... 6 1.4. Objetivos............................... 7 1.5. Resumen de contribuciones..................... 8 1.6. Estructura de este documento.................... 8 2. Modelado de la variabilidad en SPL 9 2.1. Introducción.............................. 9 2.2. Conceptos básicos.......................... 9 2.3. Documentación de la variabilidad.................. 11 2.4. Variabilidad de software vs variabilidad de línea de producto.. 13 2.5. Técnicas de modelado........................ 14 2.6. Discusión............................... 15 2.7. Resumen................................ 16 3. Modelos de características 17 3.1. Introducción.............................. 17 3.2. Modelos de características básicos................. 18 3.2.1. FODA............................. 18 3.2.2. Feature-RSEB........................ 19 3.2.3. Un ejemplo.......................... 19 3.3. Otras propuestas........................... 21 3.4. Modelos de características con multiplicidad y cardinalidad... 22 3.5. Modelo de características extendido................ 23 3.6. VFD.................................. 25 3.7. Discusión............................... 27 3.8. Resumen................................ 28 i
4. Otras técnicas para el modelado de la variabilidad 29 4.1. Introducción.............................. 29 4.2. OVM.................................. 29 4.2.1. Elementos de un modelo OVM............... 30 4.2.2. Metamodelo de OVM.................... 31 4.2.3. Un ejemplo de modelo OVM................ 32 4.3. COVAMOF.............................. 34 4.3.1. Elementos de un modelo COVAMOF............ 34 4.3.2. Un ejemplo de modelo COVAMOF............. 38 4.4. K. Schimid e I. John......................... 40 4.4.1. Modelos de decisión..................... 41 4.4.2. Primitivas de evaluación de decisiones........... 43 4.4.3. Metamodelo.......................... 44 4.5. DecisionKing............................. 46 4.5.1. Elementos de un modelo en DecisionKing......... 47 4.5.2. Un ejemplo de modelo en DecisionKing.......... 49 4.6. VSL.................................. 49 4.7. Discusión............................... 52 4.8. Resumen................................ 57 5. Análisis automático 59 5.1. Introducción.............................. 59 5.2. Operaciones de análisis en los modelos de características..... 60 5.3. Soporte automático a los modelos de características........ 68 5.3.1. Propuestas basadas en lógica proposicional........ 69 5.3.2. Propuestas basadas en lógica descriptiva (DL)...... 70 5.3.3. Propuestas basadas en programación con restricciones.. 71 5.4. El framework FAMA......................... 71 5.5. Análisis automático en OVM.................... 73 5.6. Discusión............................... 77 5.7. Resumen................................ 79 6. Conclusiones y trabajo futuro 81 6.1. Conclusiones............................. 81 6.2. Trabajo futuro............................ 82 A. Curriculum vitae 85 B. Artículo enviado al ASPL08 89 ii
Índice de figuras 1.1. Mass production vs. mass customization............... 3 1.2. Actividades en en desarrollo de SPL................. 4 1.3. Modelo de características para sistemas de teléfono móvil..... 5 2.1. Definición de conceptos en el contexto de SPL........... 10 2.2. Modelo de variabilidad integrado................... 12 2.3. Modelo de variabilidad separado................... 12 2.4. Variabilidad de software vs variabilidad de línea de producto... 13 3.1. Relación jerárquica entre características en FODA......... 19 3.2. Relación no jerárquica entre características............. 19 3.3. Relación OR en Feature-RSEB.................... 20 3.4. Modelo de características básico................... 20 3.5. Relación de multiplicidad y cardinalidad.............. 23 3.6. Modelo de características con cardinalidad............. 23 3.7. Modelo de características extendido................. 24 3.8. Representación gráfica de un modelo de características VFD... 26 4.1. Notación OVM............................. 30 4.2. Tipos de requires en OVM...................... 31 4.3. Tipos de excludes en OVM...................... 32 4.4. Metamodelo OVM........................... 33 4.5. Ejemplo de la relación entre OVM y artefacto........... 34 4.6. Ejemplo de modelo OVM para un sistema de teléfono móvil... 35 4.7. Niveles de abstracción en COVAMOF................ 36 4.8. Notación COVAMOF......................... 37 4.9. COVAMOF variability view..................... 38 4.10. Ejemplo de un modelo COVAMOF para un sistema de teléfono móvil.................................. 39 4.11. Propuesta para el modelado de la variabilidad [Klaus Schmid e Isabel John].............................. 41 4.12. Metamodelo de la propuesta de Schmid y John........... 44 4.13. Un ejemplo de la variabilidad usando la notación textual..... 46 4.14. Visión general del modelo de variabilidad DOPLER........ 47 4.15. Ejemplo de un metamodelo de dominio específico en DecisionKing. 48 iii
4.16. Metamodelo para el modelado de la variabilidad en el DecisionKing. 49 4.17. Ejemplo de un parcial modelo de variabilidad en DecisionKing.. 50 4.18. Modelo general en el que se basa VSL................ 51 4.19. Ejemplo del teléfono móvil con marcadores VSL.......... 52 5.1. Proceso para el análisis de SPL.................... 60 5.2. Un escenario del análisis automático de modelos de características. 61 5.3. Parcial modelo de características de la línea de productos de teléfonos móviles............................ 61 5.4. Modelo de características inválido.................. 62 5.5. Modelos de características total equivalentes............ 63 5.6. Modelos de características parcial equivalentes........... 63 5.7. Casos típicos de características muertas............... 66 5.8. Explanación en características.................... 66 5.9. Explanación correctiva en características.............. 67 5.10. Propagación de decisiones en un modelo de características..... 68 5.11. Las cuatro capas del framework FAMA............... 72 5.12. Separación de la variabilidad..................... 74 5.13. Ejemplo de la transformación OVM para VFD +.......... 75 5.14. Proceso de análisis automático en un modelo OVM........ 76 iv
Índice de cuadros 3.1. Resumen de las propuestas de modelos de características..... 28 4.1. Ejemplo de un parcial modelo de decisión para el sistema de teléfonos móviles de acuerdo con la propuesta de Schmid y John. 42 4.2. Resumen de las técnicas para el modelado de la variabilidad... 54 4.3. Comparativa de las notaciones empleadas por las técnicas para las relaciones obligatoria, opcional y alternativa........... 55 4.4. Comparativa de las notaciones empleadas por las técnicas para las relaciones or, de grupo y cardinalidad.............. 56 5.1. Resumen de las propuestas para el tratamiento automático de modelos de variabilidad........................ 78 v
Reconocimientos A mi familia y a mis tutores. Al amigo José Joaquin Bocanegra Garcia por su paciencia y amistad al ayudarme con la corrección del español. Mis reconocimientos al coordinador del Departamento de lenguajes y sistemas informáticos, Rafael Corchuelo, por su gran colaboración en hacer viable este proyecto de doctorado. De igual forma, expreso mis reconocimientos al Evangelischer Entwicklungsdienst (EED) por la concesión de la beca de doctorado. vi
Resumen En los últimos años, los investigadores en ingeniería de software han invertido sus esfuerzos en una nueva línea de investigación, conocida como líneas de producto software. La ingeniería de líneas de producto software se refiere a una nueva forma de reutilización de software en la que se propone un conjunto de métodos y técnicas para la producción de varios productos software que poseen similitudes entre ellos pero que también tienen sus divergencias. En este nuevo paradigma de construcción de software hay una particularidad importante, la que se refiere a la necesidad de un modelo que represente todos los posibles productos de una misma línea de productos. Uno de los modelos más usados para este fin son los modelos de características (feature models) propuesto en 1990. Desde su publicación ya se ha hablado de la importancia del análisis automático de dichos modelos. Sin embargo, sólo en los últimos años este tema ha sido tratado por la comunidad investigadora. El análisis automático de líneas de producto software es la extracción de informaciones de los modelos de variabilidad asistido por ordenador. Muchas de las propuestas corrientes para el análisis automático se basan en los modelos de características. No obstante dichos modelos no son la única forma de representar líneas de producto software, existen otras propuestas en la literatura con este mismo objetivo. Una de ellas es OVM (Orthogonal Variability Model). Sus autores proponen un modelo específico para documentar la parte variable entre los productos. En sus recientes publicaciones presentan algunos trabajos que han sido desarrollados el contexto del análisis automático. En esta memoria presentamos una descripción y una comparativa de algunas de las propuestas existentes en la literatura para modelar la variabilidad. Además, presentamos el estado del arte del análisis automático de estos modelos. Por último, presentamos las conclusiones a que hemos llegado y los trabajos vamos a desarrollar en el futuro para completar nuestra investigación.
Capítulo 1 Introducción En este documento se presenta la memoria de investigación que corresponde al periodo investigador del programa de doctorado Tecnología e Ingeniería de Software de la Universidad de Sevilla. El punto de partida para la elaboración fue el trabajo de investigación Tratamiento automático de modelos de características para Fábricas BDD/SOA propuesto por el departamento de Lenguajes y Sistemas Informáticos. Este trabajo de investigación proponía en un principio el siguiente programa: Estudio de la propuesta elaborada en la tesis de D. Benavides para tratar automáticamente modelos de características. Estudio de las herramientas de software libre y/o propietario para el tratamiento automático de modelos de características. Revisión del estado actual de los sistemas BDD/SOA. Identificación de las mejoras que tanto la propuesta de D. Benavides como las herramientas de soporte admiten en el contexto de las Fábricas BDD/SOA. Presentación de los resultados. Al empezar el estudio de la propuesta elaborada en la tesis de D. Benavides, nos centramos en una particularidad importante de su trabajo: la abstracción. Esta abstracción permite el uso de otros tipos de modelos de variabilidad, además de los modelos de características, para el análisis automático de líneas de producto software. En aquel momento, empezamos la investigación con el objetivo de hacer el análisis de otro modelo de variabilidad. Al hacer el estudio de la literatura comprobamos la existencia de múltiplas técnicas para el modelado de la variabilidad. De igual forma, es amplia la variedad de conceptos a asimilar así como la numerosa cantidad de trabajos a revisar. Por ello, se optó por la modalidad de Análisis de la Bibliografía como memoria de investigación. Este capítulo de introducción se organiza así: en su primer apartado exponemos las motivaciones que han guiado la investigación; en el segundo damos una 1
visión global sobre el contexto; en el tercero presentamos la hipótesis inicial; en el cuarto los objetivos que nos hemos planteado; en el quinto la planificación que hemos seguido en el periodo de investigación y finalmente la estructura de este documento. 1.1. Motivaciones Las líneas de producto software sugieren una nueva forma de desarrollo de software, en la que ya no se desarrolla un software para cada producto diferente, sino una línea de productos. De esta forma, los productos que comparten muchas de sus características pueden ser desarrollados a partir de artefactos comunes sin la necesidad de partir desde cero. En la ingeniería de líneas de producto software es necesario que existan métodos de modelado que expresen las características comunes y las variables entre los productos de una línea. Dicha tarea se define como modelado de la variabilidad y esta es la propiedad que diferencia el desarrollo de líneas de producto del desarrollo de software tradicional. Los modelos de características son considerados como una de las contribuciones más importantes para el modelado de líneas de producto software. Sin embargo, existen también otras formas de representar líneas de producto software. Los modelos de variabilidad que se generan en el desarrollo de una línea de producto software pueden tener una gran cantidad de características y un gran número de combinaciones entre ellas. Por lo tanto, es prácticamente imposible gestionar grandes modelos sin la ayuda de herramientas. El análisis automático de los modelos de variabilidad permite extraer automáticamente informaciones importantes de los modelos, las cuales pueden ser útiles a los analistas, diseñadores, programadores y gestores de la línea de productos. El análisis automático de los modelos de variabilidad es un gran reto en este campo de investigación. En los últimos años se han presentado algunas propuestas para el análisis automático, la mayoría de ellas orientadas hacia los modelos de características. Basados en la experiencia del grupo de investigación en el análisis automático usando modelos de características, nos hemos planteado investigar el análisis de otros modelos de variabilidad. 1.2. Contexto de la investigación En esta sección, presentamos el contexto al que pertenece el análisis automático de líneas de producto software. Hacemos una breve descripción de lo que son líneas de producto software, el objeto de nuestro análisis. Luego describimos los modelos de características y el análisis automático de ellos. 2
Figura 1.1: Mass production vs. mass customization. 1.2.1. Líneas de producto software (SPL) A lo largo de la historia, ha habido un cambio significativo en la producción de bienes y servicios. De la producción artesanal de un producto para un cliente individual, se pasó a la producción de una gran cantidad del mismo producto para satisfacer las necesidades de un creciente número de clientes; a esto se llamó producción en masa [43]. Varios ramos de la industria pasaron a desarrollar sus productos de esta forma, construyendo así líneas de producto. A pesar de que se haya ganado en eficiencia con el empleo de la producción en masa, este tipo de producción redujo la posibilidad de la diversificación, puesto que no tenía en cuenta los requisitos personales de cada cliente. En el mundo globalizado, la diversidad de clientes y la competitividad de las empresas trajo la necesidad de pasar de la producción en masa a la personificación en masa. Davis definió personificación en masa como... customization and personalisation of products and services for individual customers at a mass production price. [24]. Por lo tanto la personificación en masa tiene en cuenta los requisitos de los clientes (ver Figura 1.1). Con la industria de software no fue diferente, puesto que esta juega un papel importante en en el contexto actual. Se está cambiando de la producción de software individual hacia la producción de líneas de producto software (en inglés Software Product Lines - SPL). Clements y Northrop [16] definen línea de producto como: A Software Product Line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way 3
Según esta definición, una línea de producto está compuesta por un conjunto de productos. Cada uno de estos productos está construido a partir de una base de activos del núcleo (en inglés core assets), la cual es desarrollada específicamente para un dominio determinado. Las partes comunes entre los productos se transforman en artefactos de software reusables, los cuales deben ser proyectados de forma flexible, de manera que permita añadirles las variabilidades requeridas por el cliente. Basados en esta definición se puede decir que SPL es el intento más reciente de reutilización de software. De este cambio en la industria de software, surgió el nuevo paradigma denominado Ingeniería de Líneas de Producto Software. Esta nueva ingeniería está rápidamente tomando importancia como un paradigma de desarrollo de software viable y estratégico para las organizaciones. Permite que las empresas hagan mejorías en el tiempo de entrada en el mercado (time-to-market), costes, productividad y calidad [43]. En la ingeniería de líneas de producto software, el desarrollo de software sigue dos actividades esenciales [17]: Ingeniería de Dominio e Ingeniería de Aplicación. En la primera actividad, se construyen los activos del núcleo; en la segunda, se deriva cada producto específico a partir de los activos creados previamente. Con el desarrollo de una línea de producto software es posible construir, de forma rápida y eficiente, múltiples variaciones de un mismo producto. Estos dos procesos se llevan a cabo en paralelo y se retroalimentan (ver Figura 1.2). Figura 1.2: Actividades en en desarrollo de SPL. 1.2.2. Modelos de características La manera de representar cada producto software en SPL también tuvo la influencia de otras industrias, esto conllevó a la utilización del término característica (en inglés feature) para especificar cada producto. Una característica en un sistema de software es un incremento de la funcionalidad [3]. Para describir todos los productos que una SPL es capaz de producir, es necesario disponer de un modelo que capture las características comunes (en inglés commonalities) y las diferentes (en inglés variabilities) entre los siste- 4
mas pertenecientes a la línea de productos [37]. Con este objetivo, se proponen los modelos de características (en inglés Feature Models) como una forma de describir una SPL [19]. De esta forma, un producto está representado por una configuración única de un conjunto de características. El conjunto de todas las combinaciones válidas de características representa el conjunto de miembros de una línea de productos [35]. La Figura 1.3 representa un ejemplo simplificado de un modelo de características inspirado en la industria de la telefonía móvil. En el modelo se puede ver cómo se utilizan las características para especificar y desarrollar software para teléfonos móviles. El software cargado en el teléfono está determinado por las características que posee. Por ejemplo, un sistema de esta línea puede ser especificado por el conjunto de características {Calls,Messaging,Games}. Esto significa que el producto de software ofrece apoyo a realización de llamadas, a envío de mensajes y a conexión por medio de wifi, respectivamente. Figura 1.3: Modelo de características para sistemas de teléfono móvil. En 1990 Kang et al. presentaron los modelos de características por primera vez [35]. A partir de entonces han sido muchas las extensiones y mejoras que se han propuesto sobre dicho modelo que han intentado incrementar su capacidad expresiva. Actualmente estos modelos son considerados una de las más importantes contribuciones para la ingeniería de líneas de producto software [17]. Los modelos de características son la forma mas conocida para documentar la variabilidad y pueden ser empleados en todos los procesos de la ingeniería de SPL [19, 31]. De esta forma, radica la importancia de estos modelos para las investigaciones en este área. 1.2.3. Análisis automático de modelos de características El análisis automático de modelos de características consiste en la capacidad de razonar sobre un modelo de forma automática, es decir, hacer observaciones acerca de las propiedades del modelo. Por ejemplo, podemos querer saber si un determinado modelo es válido, en otras palabras, si representa por lo menos uno de los posibles productos. 5
El razonamiento automático es una tarea importante en el contexto de líneas de producto software, puesto que es prácticamente imposible hacerla de forma manual, y además, esta manualidad se presta a equívocos humanos. Por otra parte, los modelos de características son uno de los principales artefactos de la ingeniería de dominio, por ello, su análisis en una etapa temprana del desarrollo, es una tarea esencial para el éxito de la línea de producto. A pesar de que el análisis de modelos de características haya sido considerado un reto importante cuando fueron propuestos, este no ha sido alcanzado completamente. En el survey presentado por Benavides et al. [11], se identificaron que aún no existe un consenso sobre cuales son las operaciones que deben ser incluidas en el análisis, y se hizo una síntesis de las diferentes propuestas con respecto a la identificación de operaciones de análisis. En cuanto a las plataformas de soporte al análisis automático de modelos de características, algunos investigadores han presentado algunas propuestas, las que se pueden separar en 4 grupos [11]. En el primer grupo están los trabajos que proponen el análisis basado en lógica proposicional (en inglés, Propositional Logic), en los que se transforman un modelo de características en formulas proposicionales. En el segundo grupo están los trabajos de análisis basados en lógica descriptiva (en inglés, Description Logic). Luego, en el tercer grupo, están los análisis basados en programación con restricciones (en inglés, Constraint Programming), propuesta por Benavides et al. [14]. Finalmente, en el cuarto grupo, están los trabajos que usan una base conceptual propia, es decir, una solución creada específicamente para este problema. 1.3. Hipótesis En esta sección describimos la hipótesis y las preguntas de investigación que motivan esta memoria y nuestra investigación futura en el contexto del análisis automático de modelos de variabilidad. A saber: Es posible analizar automáticamente líneas de productos software usando técnicas de modelado diferentes a los modelos de características. El análisis automático de los modelos de características es un campo de investigación activo en el área de líneas de producto software [4]. A pesar de que los mencionados modelos son los más empleados en el modelado de la variabilidad existen otras propuestas en la literatura [50]. Sin embargo, parece que poco esfuerzo ha sido dedicado al análisis automático de estas otras propuestas. En particular, esta hipótesis plantea las siguientes preguntas de investigación: Cuáles son los modelos de variabilidad existentes en la literatura? Se debe hacer un estudio de las propuestas más citadas en la literatura para modelar la variabilidad. Este estudio debe incluir la notación usada por cada aproximación para el modelado de la variabilidad y si las propuestas presentan algún tipo de soporte para las operaciones de análisis automático. 6
Qué criterios diferenciadores pueden plantearse para elegir uno de los modelos estudiados? Definir los criterios para elegir uno de los modelos propuestos, a fin de hacer el análisis automático. Basados en las comparaciones que se haga entre las propuestas estudiadas y en las publicaciones sobre el análisis de modelos de características establecer algunos criterios para orientar la elección de uno de los modelos. Qué operaciones de análisis son realizables por la técnica de modelado elegida? Identificar cuáles son las operaciones de análisis posibles de realizar. Asimismo, estudiar la posibilidad de usar las mismas operaciones de análisis aplicadas a los modelos de características [11]. Definir los propósitos de cada operación de análisis identificada. Qué tipo de representación lógica es la más adecuada para cada técnica? Estudiar en la literatura las representaciones lógicas existentes e identificar cuál es la más adecuada para representar cada técnica. Responder a estas preguntas requiere un incisivo estudio de las propuestas existentes. Esto nos debe llevar a la identificación de un modelo de variabilidad sobre el cual se puede hacer el análisis automático. Asimismo a la identificación de las operaciones de análisis que podrían ser útiles a la hora de dar el soporte automático al modelo de variabilidad en cuestión. Es posible extender el framework FAMA para soportar otros lenguajes de modelado? FAMA es un framework para el análisis automático de líneas de producto software en general y modelos de características en particular. Este framework posee una capa de abstracción que fue diseñada para ser independiente del modelo de variabilidad. En este contexto, nos preguntamos: i) si también podría utilizarse FAMA para proporcionar un eficiente soporte automático a las operaciones de análisis sobre otros modelos de variabilidad, ii) si es posible extender FAMA sin alterar la capa de abstracción. Para responder a esta pregunta sería necesario un análisis detallado del framework y una comparación de él con el resto de las propuestas existentes. 1.4. Objetivos El objetivo de esta memoria de investigación es doble: Revisar el estado del arte. Basados en la hipótesis de investigación y en las cuestiones presentadas en la sección 1.3, identificamos algunos temas de los cuales el estado del arte se debe revisar. En particular: 7
Modelos de características. La mayoría de las publicaciones existentes sobre el análisis automático están orientadas hacia los modelos de características. Propuestas para modelar líneas de producto software. Existen diferentes propuestas para modelar la variabilidad, de las cuales, elegiremos una, en la cual enfocaremos nuestra investigación. Análisis automático de líneas de producto software. Esto se refiere a las técnicas, algoritmos y herramientas propuestos para el tratamiento automático de los modelos de variabilidad. El framework FAMA. Este es el framework que pretendemos usar para el análisis automático del modelo de variabilidad elegido. Trabajo futuro. Como resultado de esta memoria de investigación hemos logrado un nuevo entendimiento de nuestra hipótesis inicial. Con esto hemos podido definir el rumbo de nuestro futuro trabajo de investigación, el que también presentamos como parte de este informe. 1.5. Resumen de contribuciones Como resultado de este trabajo de investigación hemos enviado un artículo al taller ASPL08 (First Workshop on Analyses of Software Product Lines) en la conferencia internacional de líneas de producto software (SPLC 2008). En este trabajo presentamos los primeros pasos que pretendemos dar en nuestra investigación para dar suporte automático a los modelos OVM. ASPL08. Fabricia Roos-Frantz and Sérgio Segura. Automated Analysis of Orthogonal Variability Models. A First Step. First Workshop on Analyses of Software Product Lines. Limerick, Ireland, September 12, 2008. (Pendiente de evaluación) 1.6. Estructura de este documento Los demás contenidos de este trabajo se estructuran de la siguiente forma: en el Capítulo 2 se presenta una introducción al modelado de la variabilidad en SPL; en el Capítulo 3 se presenta el estado del arte de los modelos de características; en el Capítulo 4 se describen las técnicas de modelado de SPL que han sido estudiadas, diferentes a los modelos de características y asimismo, una comparativa de dichas técnicas; en el Capítulo 5 se presenta el análisis automático delos modelos de características, el framework FAMA y el análisis automático de OVM. Por último, en el Capítulo 6 se presentan las conclusiones a que hemos llegado con este trabajo de investigación y los trabajos futuros que vamos a desarrollar para completar nuestra investigación. 8
Capítulo 2 Modelado de la variabilidad en SPL 2.1. Introducción En este capítulo haremos una introducción a cerca del modelado de la variabilidad y presentaremos algunas técnicas de modelado que han sido propuesta en los últimos años. El razonamiento sobre dichas técnicas es el objetivo central del análisis automático de líneas de producto software. Empezaremos con la definición de algunos conceptos básicos que vamos a usar a lo largo de este documento. Luego hablaremos del modelado de la variabilidad en líneas de producto software y de la diferencia que hay entre variabilidad de software y variabilidad de línea de producto. Por último, comentaremos algunas de las técnicas de modelado que se encuentran en la literatura. 2.2. Conceptos básicos En esta sección presentamos un mapa mental de algunos conceptos que vamos a usar a lo largo de esta memoria. 9
Figura 2.1: Definición de conceptos en el contexto de SPL. 10
2.3. Documentación de la variabilidad Lo que diferencia la ingeniería de líneas de producto software de la ingeniería de software tradicional es la gestión de la variabilidad [43]. El proceso de desarrollo de una línea de productos implica gestionar los puntos de variación entre los diferentes miembros de la línea. Con este fin, se identifica los aspectos comunes (commonalities) y los variables (variabilities) del dominio en cuestión [59]. Cabe destacar que las características variables y las comunes entre los productos son de igual importancia en el modelado de la línea de producto. Características comunes. Una línea de productos solamente es conveniente cuando una organización desarrolla varios sistemas que pertenecen a un mismo dominio de aplicación [42]. Esto significa que en una línea de productos los sistemas deben tener por lo menos algunas características comunes entre ellos. En este sentido, las características comunes de una familia de productos sirven para caracterizar el dominio. Cada organización limita el dominio o los dominios de la línea de producto de acuerdo con su experiencia en el desarrollo. La determinación de una característica como común o como variable es una decisión más bien estratégica do que una propriedad inherente a la línea de producto. Características variables. La características variables son aquellas que pueden variar de un sistema a otro. Conocida en la literatura como la variabilidad de la línea de producto. La variabilidad es un concepto central en del desarrollo de SPL. La variabilidad posibilita el reuso constructivo y facilita la derivación de diferentes productos, específicos para cada cliente de la línea de producto [31]. David M.Weiss and Chi Lai definen la variabilidad en el desarrollo de SPL de la siguiente manera:...an assumption about how members of a family may differ from each other [62]. La variabilidad debe ser explotada y gestionada en cada una de las fases del proceso de desarrollo de la SPL [31]. Para llevar a cabo dicha gestión se hace necesario una forma de representar todos los posibles productos, en la que se captura las similaridades y variabilidades entre ellos [37]. A lo largo de las investigaciones en líneas de producto software, se han propuesto dos formas de representar la variabilidad: incluir la variabilidad en los modelos tradicionales o incluirla en un modelo por separado. La primera forma de representación incluye la variabilidad en diagramas de desarrollo tradicionales o en modelos como los de casos de uso, modelos de características, o diagramas de clases. Inicialmente se propuso expresar la variabilidad por medio de lenguajes de modelado tradicionales, como por ejemplo UML, en los que se representa los aspectos variables por medio de elementos del modelo. Para esto varias técnicas fueron presentadas. Sin embargo los lenguajes tradicionales no fueron desarrollados para capturar todos los tipos de variabilidad de forma consistente y explícita. Entonces, algunos autores, entre ellos Kang et al. [35] y Halmans et al. [31], propusieron extensiones o anotaciones a estos modelos. Kang et al. propusieron el uso de modelos de características para 11
representar la variabilidad, mientras Halmans et al. propusieron una extensión a los diagramas de caso de uso (ver Figura 2.2). Figura 2.2: Modelo de variabilidad integrado. En la segunda forma, se ha propuesto separar la información de la variabilidad de los artefactos de desarrollo. Bachmann et al. [2] fueron unos de los primeros en proponer el uso de un modelo conceptual para la variabilidad, en el que explícitamente separa la variabilidad de los modelos tradicionales. Además de ellos, tal separación también fue propuesta por investigadores como Becker [7], Pohl et al. [43], John et al. [34], entre otros (ver Figura 2.3). Figura 2.3: Modelo de variabilidad separado. 12
2.4. Variabilidad de software vs variabilidad de línea de producto El trabajo de Metzger et al. [41] propone la separación de la variabilidad en dos tipos: la variabilidad de la línea de producto (en inglés Product line variability) y la variabilidad del software (en inglés Software variability). Pohl et al. [43] definen variabilidad de línea de producto de la siguiente manera: Product Line Variability describes the variation (differences) between the systems that belong to a product line in terms of properties and qualities (like features that are provided or requirements that are fulfilled. Y Svahnberg et al. [55] definen variabilidad de software de la siguiente manera: Software variability referes to the ability of a software system or artefact to be efficiciently extended, changed, customized or configured for use in a particular context. La variabilidad de la línea de producto es la variabilidad exigida, es decir, debe expresar las decisiones de gestión del producto, por ejemplo, como el producto debe variar. Dicha variabilidad es específica de la ingeniería de SPL. Por otro lado, la variabilidad del software es la variabilidad proporcionada en los activos del núcleo, esto es, la variabilidad realizada por los artefactos. Esta variabilidad es relevante tanto para la ingeniería de SPL como para para la ingeniería de software tradicional. La Figura 2.4 presenta un ejemplo de las dos variabilidades. Figura 2.4: Variabilidad de software vs variabilidad de línea de producto. 13
Con los modelos de características se puede expresar tanto la variabilidad del software como la variabilidad de la línea de producto, por esta razón las variabilidades se mezclan en un mismo modelo. La separación explícita de los dos tipos de variabilidad aún no se ha reflejado en la mayoría de las metodologías de modelado de SPL, sólo algunas de ellas llevan a cabo esta división. Bachmann et al. [2], Metzger et al. [41] y John et al. [34], entre otros. Bachmann et al. proponen el uso de un modelo conceptual para la variabilidad, en el que explícitamente separan la variabilidad de software de la variabilidad de línea de producto; Metzger et al. proponen el uso de modelos de características para documentar la variabilidad de software y Orthogonal Variability Model (OVM) para documentar la variabilidad de la línea de producto; John et al. proponen el concepto de variability dimension para separar la variabilidad relacionada a aspectos de software, y sugieren modelos de decisión (decision models) para la documentación de la variabilidad de línea de producto. 2.5. Técnicas de modelado Existe en la literatura un gran número de técnicas para modelar la variabilidad de SPL. Los más conocidos son los modelos de características y se basan en Feature-Oriented Domain Analysis FODA [35], por ejemplo, Feature-RSEB [30], FORM [36], y las propuestas por Czarnecki et al. [18] y Riebisch et al. [45]. Además de estas propuestas, citamos adelante otros trabajos que se encuentran en la literatura. Czarnecki et al. proponen el uso de modelos de características para documentar las posibles combinaciones de características, y relacionan estos modelos a plantillas de modelos UML o a plantillas de cualquier modelo basada en Meta-Object Facility (MOF) [23]. Sinnema et al. proponen COVAMOF, un framework para modelar líneas de producto software que ofrece una vista dedicada de la variabilidad proporcionada por los modelos tradicionales [51]. Dhungana et al. proponen el uso de un metamodelo que captura la variabilidad y las dependencias entre los artefactos de la línea de producto. Documentan los puntos de variaciones y los enlaces entre el modelo de variabilidad y los artefactos en modelos de decisión [26]. Bachmann et al. proponen el uso de un modelo conceptual para la variabilidad, en el que explícitamente separan la variabilidad de software de la variabilidad de la línea de producto [2]. Becker propone un lenguaje basado en XML llamado Variability Specification Language (VSL) [7]. 14
John et al. proponen el concepto de variability dimension para separar la variabilidad relacionada con aspectos de artefactos de software y sugieren modelos de decisión para la documentación de la variabilidad de la línea de producto [34]. Bayer et al. presentan un detallado metamodelo de conceptos de variabilidad de la línea de producto. Esta propuesta se ha consolidado a partir de diversas metodologías de proyectos de investigaciones recientes como ESAPS, CAFÉ y FAMILIES. Su objetivo ha sido crear un patrón para el modelado de la variabilidad [5]. Metzger et al. proponen el uso de modelos de características para documentar la variabilidad de software, y de Orthogonal Variability Model (OVM) para documentar la variabilidad de la línea de producto. La relación entre los dos modelos indica como la variabilidad expresada en el modelo de característica realiza la variabilidad expresada en el modelo OVM [41]. 2.6. Discusión Hoy por hoy, la comunidad investigadora está trabajando en la dirección de las técnicas de modelado que documentan la variabilidad de manera separada a la documentación de los artefactos. Con la evolución de las investigaciones los autores proponen patrones a los conceptos utilizados y la separación de tipos de variabilidad que se documenta en SPL. La variabilidad puede ser abstracta a nivel de gestión solamente, o más técnica, directamente relacionada a la implementación del artefacto. De las alternativas que se encuentran en la literatura hemos elegido estudiar más detalladamente modelos de características, OVM, COVAMOF, Decision- King, K. Schimid e I. John y VSL. Estudiar los modelos de características se hace necesario en este contexto, puesto que vamos a usar el análisis automático de dichos modelos como punto de partida de nuestra investigación. Luego OVM que está respaldada por Klaus Pohl, el que posee un gran prestigio en la comunidad investigadora. Su grupo de investigación ha publicado varias trabajos en los que proponen el uso de OVM. Poseen varios proyectos reales que se han llevado a cabo en empresas como Nokia, HP, Philips, Boing entre otras. También elegimos COVAMOF que está respaldada por Jan Bosch, el que también tiene gran prestigio en el área de líneas de producto software. Los autores de COVAMOF poseen varias publicaciones importantes (ICSM 2004, SPLC2004, Journal on Information and Software Technology). En una de sus publicaciones presentan un estudio de caso con las organizaciones Thales Nederland B.V. y Robert Bosch GmbH. Hemos elegido las dos técnicas, DecisionKing y K. Schimid e I. John, las que han sido propuesta recientemente y proponen el concepto de modelos de decisión para modelar la variabilidad. Por último, VSL es citada en muchos trabajos como una propuesta para separar la variabilidad de los modelos tradicionales. Su propuesta surgió del intento de proporcionar un estándar 15
para los conceptos empleados en líneas de producto software. 2.7. Resumen EL objetivo de este capítulo es dar una idea de como se trata el modelado de la variabilidad en SPL y por lo tanto tener una mejor comprensión de las diferentes técnicas presentes en la literatura. En este capítulo describimos aspectos relacionados al modelado de la variabilidad. Comentamos algunos conceptos a tener en cuenta en la documentación de la variabilidad, los que han sido propuestos a lo largo de las investigaciones en este área. Por último, presentamos de forma breve algunas técnicas de modelado propuestas en los últimos años. 16
Capítulo 3 Modelos de características 3.1. Introducción Representar un particular producto es una cuestión clave en la ingeniería de líneas de producto. De esta cuestión surgió el uso de características para representar propiedades de un determinado producto, dado que este concepto ya era utilizado en líneas de productos en otras industrias. El concepto de características en SPL fue un éxito debido a su forma natural e intuitiva de representar un producto, y facilitó la comunicación entre los participantes [37]. De esto, se adoptó los modelos de características para representar todos los posibles productos de una línea en un único modelo [11]. Un modelo de característica representa gráficamente una línea de producto, a través de las posibles combinaciones entre las características. El conjunto de características que componen un modelo de característica se organizan de la siguiente forma: i. una relación entre característica padre y característica hija. ii. Relaciones no jerárquicas (en inglés cross-tree constraints) que suelen ser del tipo: si la característica A aparece, entonces la característica B se debe incluir (o excluir). El primer modelo de características fue propuesto en 1990 [35] como parte del método de análisis FODA (Feature-Oriented Domain Analysis). Desde entonces muchas otras propuestas de extensiones a este modelo han sido presentadas. El objetivo de este capítulo es estudiar el estado del arte en el contexto de los modelos de características. Puesto que nuestra investigación está enfocada en el análisis, nos centramos apenas en los elementos conceptuales de los modelos sin tener en cuenta las diferentes representaciones visuales propuestas por ellos. El resto del capítulo se estructura de la siguiente forma. En la Sección 3.2 se presentan las propuestas que hemos clasificado como modelos de características básicos. En la Sección 3.4 se presentan los modelos de características con multiplicidad y cardinalidad. En la Sección 3.5 se introducen los trabajos que fueron 17
propuestos con el fin de extender los modelos de características con atributos. Una visión general y una comparación de las propuestas estudiadas se presenta en la Sección 3.7. Finalmente, resumimos los puntos principales del capítulo en la Sección 3.8. 3.2. Modelos de características básicos Clasificamos como modelos de características básicos aquellos en los que se usan relaciones simples entre las características. A continuación, detallamos los mismos: 3.2.1. FODA El primer modelo de características fue propuesto en 1990 [35] como parte del método de análisis FODA (Feature-Oriented Domain Analysis). En FODA un modelo está compuesto de dos elementos: las características y las relaciones entre ellas. Las características están organizadas en una estructura jerárquica en forma de árbol. Una de las características del árbol es la raíz y representa el sistema como un todo. En esta aproximación las relaciones entre características pueden ser de dos tipos: 1. Relación jerárquica. Esta relación es definida entre una característica padre y sus características hijas. Una característica hija solamente puede hacer parte de los productos en los que la característica padre aparece. En FODA fueron propuestas tres tipos de relaciones jerárquicas: Obligatoria (Mandatory): indica que cuando la característica padre hace parte de un producto particular, la característica hija también debe hacer parte del producto (ver Figura 3.1 (a)). Opcional (Optional): indica que cuando la característica padre hace parte de un producto particular, la característica hija, puede o no, ser incluida en el producto (ver Figura 3.1 (b)). Alternativa (Alternative): es la relación entre una característica padre y un conjunto de características hijas que indica que cuando la característica padre hace parte de un producto particular, sólo una de las características del grupo de hijas debe hacer parte del producto (ver Figura 3.1 (c)). 2. Relación no jerárquica. Excluye (Excludes): Una característica X excluye Y significa que si la característica X es incluida en el producto, la característica Y no debe ser incluida, y viceversa (ver Figura 3.2 (a)). Requiere (Requires): Una característica X requiere Y significa que si la característica X es incluida en el producto, la característica Y también debe ser incluida, pero no viceversa (ver Figura 3.2 (b)). 18
Figura 3.1: Relación jerárquica entre características en FODA. Figura 3.2: Relación no jerárquica entre características. 3.2.2. Feature-RSEB En 1998, Griss et al. [30] presentaron Feature-RSEB (Reuse-Driven Software Engineering Business), una extensión de FODA que presenta una nueva notación gráfica para el modelo, pero que no cambia su semántica. Esta extensión añade una nueva relación entre una característica padre y una característica hija, como descrita a continuación: 1. Relación jerárquica. Relación Or: indica que cuando la característica padre hace parte de un producto particular, una o más de las características del grupo de hijas debe hacer parte del producto. Las demás relaciones, obligatoria, opcional, alternativa, excluye y requiere, continúan como originalmente en FODA. La organización de las características en Feature-RSEB, a diferencia de FODA, puede ser en forma de árbol o grafo (Directed Acyclic Graph-DAG). La Figura 3.3 presenta la relación Or. 3.2.3. Un ejemplo En la figura 3.4 describimos un simplificado ejemplo de modelo de características básico, usando la notación Feature-RSEB, inspirado en la industria de teléfonos móviles. El modelo ilustra como se usan características para especificar y construir una línea de producto software para teléfonos móviles. Para más ejemplos en las diversas notaciones basadas en FODA ver la referencia [40]. 19
Figura 3.3: Relación OR en Feature-RSEB. Cada producto desarrollado a partir de la línea de producto Mobile Phone, debe tener UtilityFunctions y Settings, las cuales son features obligatorias. Todo el producto posee cuatro funciones (UtilityFunctions) obligatorias: Calls, Messaging, Alarmclock y Ringingtones. Algunos productos Mobile Phone poseen un servicio de mensaje (Messaging) del tipo SMS, o EMS, o MMS, o los tres tipos a la vez, debido a la relación or. Lo mismo se aplica a los recursos de llamadas (Calls) y tipos de conexión (Connectivity). Hay productos con el recurso de Games y otros sin este recurso. Aquellos que tienen juegos (Games) exigen Javasupport, debido a la restricción requiere. Además, todo el producto Mobile Phone debe soportar un sistema operativo (OS) que puede ser Symbian o WinCE, pero solamente uno de ellos. También, algunos productos tienen un tipo de Media y otros no. Los tipos de Media que ofrecen poden ser camera, MP3 y MP4, pero si un producto posee MP3 no posee MP4 y viceversa, debido a la restricción excluye entre las dos características. Figura 3.4: Modelo de características básico. 20
3.3. Otras propuestas Otros autores propusieron extender los modelos de características básicos: Kang et al. [36] propusieron el método Feature-Oriented Reuse Method (FORM) como una extensión del método FODA; Gurp et al. [60] propusieron una extensión a Feature-RSEB, en la que añaden informaciones extras a los modelos; Eriksson et al. propusieron el Product Line Use case modeling for System and Software engineering (PLUSS) como una extensión de Feature-RSEB [27], en la que combinan diagramas de características (en inglés Feature Diagram) y diagramas de casos de uso para representar la línea de producto en una visión de alto nivel. FORM Kang et al. [36] propusieron Feature-Oriented Reuse Method (FORM) como una extensión del método FODA. En esta propuesta sus autores consideran la importancia del uso de los modelos de características para modelar la variabilidad en otras fases del desarrollo además de la ingeniería de requisitos. Con este fin, el diagrama de características fue añadido con cuatro capas de abstracción y dos nuevas relaciones entre características. Estos son descritos a continuación: Cuatro capas de abstracción. Cada característica pertenece a una de las cuatro capas: capability layer, operating environment layer, domain technology layer o implementation technique layer. Relación generalization/specialization. Esta relación permite que las características hijas sean explícitamente anotadas como una especialización de su característica padre y de forma recíproca, las características padres pueden ser modeladas como una generalización de las características hijas. Relación implemented-by. Esta relación posibilita que las características de los niveles más altos puedan se conectar a las características que las implementan en los niveles inferiores. Gurp et al. Gurp et al. [60] definen un otro lenguaje de diagramas de características la que extiende Feature-RSEB. Este lenguaje añade dos nuevas informaciones a los modelos. La primera son los binding times indicando cuando una característica debe ser seleccionada para un determinado producto y la segunda son las external features, las que son características técnicas ofrecidas por la línea de producto. Esta propuesta hace cambios principalmente en la sintaxis concreta 21
del lenguaje, por lo tanto, no influencia la combinación de las características [49]. PLUSS Eriksson et al. propusieron el Product Line Use case modeling for System and Software engineering (PLUSS) basado en Feature-RSEB [27]. En esta propuesta los autores combinan los diagramas de características con los diagramas de casos de uso. Un conjunto de características compone un paquete de casos de uso y de esta forma es posible visualizar variantes en la especificación de casos de uso por medio de los modelos de características. 3.4. Modelos de características con multiplicidad y cardinalidad Otros autores propusieron la inclusión de otros tipos de relaciones entre las características: la multiplicidad y la cardinalidad. Esta propuesta fue motivada por estudios de casos dónde se identificó la necesidad de otro tipo de relación, además de las relaciones alternativa y or [44]. En las propuestas [18] y [45], los autores añaden a los modelos la multiplicidad para sustituir las relaciones alternativa y or. Lo que antes eran dos grupos distintos, un grupo de característica alternativas o un grupo de característica or, pasa a ser sólo un grupo con una multiplicidad, como descrito a seguir. 1. Relación entre característica padre y característica hija: Relación de grupo: indica que cuando la característica padre hace parte de un producto particular, el número de características hijas que debe hacer parte del producto depende de la multiplicidad. La multiplicidad equivalente a la relación alternativa es 1 1, lo que significa que sólo una de las hijas del grupo pueden hacer parte del producto (ver Figura 3.5(a)). La multiplicidad equivalente a la relación or es 1 n, siendo n el número de características del grupo, lo que significa que una o n de las características del grupo pueden hacer parte del producto (ver Figura 3.5(b)). Más tarde, Czarnecki et al. [20, 21] propusieron otra extensión a FODA: el cardinality-based feature models. En este trabajo ellos introducen una nueva relación que generaliza la relación obligatoria y la relación opcional. 1. Relación entre característica padre y característica hija: Relación con cardinalidad: indica que cuando la característica padre hace parte de un producto particular, la inclusión de la característica hija depende de la cardinalidad. La cardinalidad equivalente a la relación 22