Líneas de Productos de Software Dirigidas por Modelos (MD-SPL): Oportunidades y Retos

Transcripción

1 Líneas de Productos de Software Dirigidas por Modelos (MD-SPL): Oportunidades y Retos Andrés Romero y Fabián Ceballos Universidad de los Andes, Cra. 1 No 18A 10, Bogotá, Colombia {aa.romero354, fl.ceballos40}@uniandes.edu.co Abstract. En un mercado dinámico y globalizado como el actual, el cual promueve la competencia, las empresas están obligadas a llevar sus ideas y proyectos lo más rápido posible a la realidad. Por este motivo, el desarrollo de software ha venido evolucionando constantemente, reduciendo los tiempos de desarrollo, y mejorando la calidad de los productos. Las líneas de productos de software dirigidas por modelos combinan las ventajas del Desarrollo Basado en Modelos y la Ingeniería de Líneas de Producto de Software. Estos dos enfoques día a día ganan terreno, debido a los beneficios que ofrecen reduciendo los tiempos de desarrollo y mejorando la calidad, basándose en el principio básico de reusabilidad. Sin embargo estos enfoques deben afrontar grandes retos para que sean totalmente aceptados por la industria del software. Key words: Ingeniería dirigida por modelos, Líneas de productos de software, lenguajes de dominio específico, variabilidad, trazabilidad, verificación, validación 1 Introducción En el mercado actual las empresas están obligadas a ser flexibles y dinámicas, lo cual implica que deben ser capaces de desarrollar sus ideas lo más rápido posible, para poder ser competitivas y no desaparecer. Las empresas de software han tenido que buscar alternativas que optimicen sus procesos de desarrollo y aumenten la rentabilidad de cada producto desarrollado. Una alternativa se basa en la reutilización, en donde se hace uso de un mismo conjunto de artefactos de software durante la fase de desarrollo de cada producto. Esta estrategia constituye el enfoque principal de la Ingeniería de Líneas de Producto de Software (SPLE por sus siglas en inglés) la cual se basa en la creación de artefactos de alto nivel que son reutilizados durante el proceso de desarrollo de software [5]. De acuerdo con [9] una Línea de Producto de Software (SPL por sus siglas en inglés) es una familia de sistemas que comparten un conjunto de características administrables, las cuales satisfacen las necesidades específicas de un mercado o segmento particular y que son desarrolladas a partir de un conjunto común de activos base". Estas SPL permiten reducir tanto el tiempo como el costo para

2 2 Andrés Romero y Fabián Ceballos desarrollar cada producto debido a la estabilidad y confiabilidad de los activos base que se reutilizan. Por otro lado, el Desarrollo Basado en Modelos (MDD por sus siglas en inglés) es un enfoque que permite un mayor grado de abstracción tomando a los modelos como elementos de primera clase. De esta manera, en el proceso de desarrollo de software es posible enfocar los esfuerzos en la representación del problema y expresar una solución independiente de la tecnología [21]. Una SPL puede ser construida utilizando el enfoque MDD, lo cual puede ser una ventaja debido a que los productos de la línea pueden ser derivados a partir de un proceso generativo que utiliza modelos y transformaciones como sus activos base principales [4]. La conjunción de los enfoques SPLE y MDD es conocida como Líneas de Producto Basadas en Modelos (MD-SPL por sus siglas en inglés). En este artículo se explicarán las ideas más importantes de MDD y SPLE, y se dará un primer acercamiento a MD-SPL y sus principales retos. El artículo se encuentra organizado de la siguiente manera: La sección 2 describe las características principales de SPLE. La sección 3 presenta MDD como un enfoque de desarrollo de software. Estas secciones introducen a la sección 4 en la cual se presenta a MD-SPL como un enfoque que incorpora las ventajas de MDD en SPLE. Finalmente en la sección 5 se muestran los retos más importantes asociados a este nuevo enfoque y en la sección 6 se presentan las conclusiones. 2 Ingeniería de Líneas de Producto de Software (SPLE) La Ingeniería de Líneas de Productos de Software es un enfoque que sustenta sus principios en la reutilización. Este enfoque se basa inicialmente en la captura explícita de las características comunes y variables de un conjunto de productos haciendo uso de modelos de variabilidad. A partir de esta clasificación se define y construye una serie de elementos o activos base que son reutilizados durante el proceso de derivación de los productos miembros de una SPL. De acuerdo con [9] una Línea de Producto de Software es una familia de sistemas que comparten un conjunto de características administrables, las cuales satisfacen las necesidades específicas de un mercado o segmento particular y que son desarrolladas a partir de un conjunto común de activos base". Un activo base es un artefacto de software que se usa en la producción de varios productos, este puede ser un componente de software, una arquitectura, un modelo, un proceso, un documento o cualquier otro elemento útil en la construcción de un sistema. El enfoque SPLE proporciona economías de escala. Esto significa que se pueden obtener ventajas del hecho de que la mayoría de los productos son muy similares [5]. Estas ventajas se basan, esencialmente, en la reutilización de los activos base para la derivación de nuevos productos. Por lo tanto, si se decide crear una SPL se debe considerar el costo de construir los activos base y compararlo con el beneficio que se obtendrá en términos de la disminución en los costos de desarrollo y el aumento en la calidad durante el proceso de desarrollo de cada producto.

3 MD-SPL: Oportunidades y Retos 3 Un concepto importante dentro de una SPL es el alcance el cual establece el conjunto de productos que los activos base pueden producir y define las características comunes y variables entre estos. La identificación de este conjunto de características establece el punto de entrada para construir los activos base en una SPL. Las diferencias entre los posibles productos de la Línea pueden ser discutidas en términos de características. Una característica (feature) es una propiedad que se utiliza para distinguir los diferentes productos dentro de una familia [5]. Las características se organizan en grupos, formando una jerarquía de composición. De esta manera, en la fase de desarrollo es posible seleccionar una configuración específica de características para derivar cada uno de los productos. El SEI (Software Engineering Institute) 1 propone un framework para SPLE, en donde se involucran tres actividades principales ilustradas en la Figura 1: desarrollo de activos base, desarrollo de productos y la gestión respectiva de la Línea. En el desarrollo de activos base se deben definir e implementar el conjunto de activos que serán utilizados durante la generación de cada producto. En la fase de desarrollo se derivan los respectivos productos haciendo uso de los activos base. Finalmente, debe existir una actividad relacionada con la gestión integral de la Línea, en donde se administren los activos y se tomen decisiones con respecto a su evolución. Fig. 1. Actividades principales en una SPL Imagen tomada de SEI

4 4 Andrés Romero y Fabián Ceballos 3 Desarrollo de Software Dirigido por Modelos (MDD) Paralelamente a la evolución de la tecnología se han creado varias plataformas para el desarrollo de software que soportan cada vez más funcionalidades. Estas plataformas son generalmente heterogéneas, es decir, que a pesar de ofrecer interfaces similares, estas no se crean ni se utilizan de la misma manera. Esto implica que las aplicaciones se desarrollen sobre una plataforma en particular y solamente puedan ejecutarse sobre esta. MDD es una aproximación para solucionar el problema asociado a la complejidad de cada plataforma tecnológica y la inhabilidad que experimentan los lenguajes de propósito general en aliviar esta complejidad [17]. MDD propone el uso de modelos como elementos de primera clase (que pueden ser procesados por un computador o herramienta) para el desarrollo de software. De acuerdo a lo anterior, estos modelos se pueden utilizar para representar los conceptos del negocio y la solución del problema en sus diferentes niveles (arquitectura, tecnología, etc.). Un modelo es una representación abstracta de un sistema y la porción del mundo que interactúa con el" [10]. Los modelos generalmente se utilizan para documentar elementos del problema y la solución, ofreciendo un grado de abstracción alto con respecto a lo esencial del problema, puesto que responden preguntas sobre el sistema de software y la porción del mundo que es de interés para los stakeholders" [10]. La arquitectura dirigida por modelos (MDA) es una propuesta de la OMG (Object Management Group) y un enfoque MDD, para diseñar e implementar software basado en la generación y transformación de modelos. El principal objetivo de MDA es el de separar la especificación de un sistema de su detalle de implementación, proponiendo herramientas y aproximaciones para: Especificar un sistema independiente de la plataforma tecnológica que lo soporta, Especificar la plataforma y transformar la especificación de un sistema a una plataforma particular. MDA propone como primera instancia de diseño la generación de modelos independientes de la plataforma (PIM) seguido de transformaciones automáticas a modelos específicos de la plataforma (PSM) los cuales pueden ser interpretados por herramientas generadoras de código. Logrando de esta manera portabilidad, interoperabilidad y reusabilidad a través de la separación arquitectural de preocupaciones (concerns) [17]. Adicionalmente se debe notar que esta aproximación permite posponer las decisiones de implementación, puesto que siempre se está tratando el problema desde un nivel abstracto y solo se concreta el problema cuando se ha llegado a un modelo concreto de plataforma PSM. Un concern es una parte de interés en la solución del problema. Por ejemplo la vista lógica o de despliegue de una arquitectura son diferentes abstracciones del mismo problema que explican la solución de una preocupación en particular del problema global. La Figura 2 presenta el proceso de generación de una aplicación desde la perspectiva de MDA. El proceso inicia con la definición de activos base, para este caso los metamodelos. Se define un modelo inicial conforme a un metamodelo

5 MD-SPL: Oportunidades y Retos 5 Fig. 2. Modelo en Y, aproximación de MDA[17] de negocio en particular, este modelo se transforma hasta llegar a un modelo específico de la plataforma PSM (Platform Specific Metamodel por sus siglas en inglés). Antes de llegar al modelo de destino se pudo haber pasado por modelos intermedios (por ejemplo el modelo que representa la arquitectura de solución del sistema), los cuales representan los concerns y enriquecen la solución del problema. Todos estos modelos intermedios son conformes a diferentes metamodelos. 4 Líneas de Productos de Software Dirigidas por Modelos (MD-SPL) De acuerdo a las principales características y ventajas explicadas en las dos secciones anteriores relacionadas con MDD y SPLE, se explicará en esta sección la relación que tienen los dos enfoques y la manera en que pueden complementarse para crear una Línea de producto de software basada en modelos (MD-SPL). El enfoque presentado en SPLE se basa en la derivación de productos de software a través de la reutilización de activos base. Generalmente, en una SPL tradicional estos activos están representados por arquitecturas, componentes, procesos y documentos los cuales deben componerse para derivar nuevos productos [5]. Tanto la arquitectura como los componentes de una SPL tradicional se encuentran desarrollados para una plataforma específica y su enfoque de desarrollo se basa en la representación de la solución y no del problema [9]. De acuerdo al enfoque MDD, el aumento en el nivel de abstracción permite representar el modelo del problema y utilizarlo como elemento de primera clase para obtener el modelo de la solución independiente de la plataforma a través de transformaciones sucesivas. Si se incorpora el enfoque MDD dentro de una SPL se aprovechar a su carácter generativo para facilitar la derivación de los productos a través de la

6 6 Andrés Romero y Fabián Ceballos representación del problema y no de la solución. Adicionalmente, este enfoque permitir a generar soluciones que no estén basadas en una tecnología específica. De esta manera, se abre la posibilidad de representar la misma solución del problema en diferentes plataformas. La unión de estos dos enfoques es conocida como MD-SPL (Model Driven - Software Product Line). De acuerdo al enfoque MDD en donde los modelos representan elementos de primera clase y la derivación del software se realiza de manera generativa, los elementos involucrados en esta generación representarán los activos base de una Línea de producto. Una de las actividades principales descritas en el enfoque SPLE es el desarrollo de los activos base de la Línea de producto. De acuerdo al enfoque MDD, en esta fase se deben generar los metamodelos de los diferentes dominios (negocio, arquitectura, tecnología, etc.), las reglas de transformación respectivas y las plantillas de generación de código. Es importante tener en cuenta el nivel de abstracción que tienen los metamodelos de cada dominio, puesto que este nivel definirá los posibles conceptos soportados por los productos de la Línea que se esté diseñando. En la Figura 3 se muestra un proceso de desarrollo de activos base para una MD-SPL. En este proceso se crean los metamodelos en los diferentes dominios, tanto los que son independientes de la plataforma (Dominio 1, 2,..., n) como los de plataforma específica (Dominio Plataforma X y Y). Adicionalmente, se crean las transformaciones que definen la representación de los conceptos de un dominio particular en otro. Para este caso, T1 tiene la definición de las transformaciones de los conceptos del metamodelo del dominio 1 a los conceptos del metamodelo del dominio 2. Las transformaciones T3 y T4 contienen las reglas que definen la manera en que los conceptos independientes de la plataforma se representan en las plataformas específicas. Finalmente, se definen las plantillas P1 y P2 las cuales establecen la manera en que los conceptos de las plataformas se traducen a código. Partiendo de los activos base construidos, en este caso los metamodelos, reglas de transformación y plantillas, se puede ejecutar la actividad de desarrollo de producto en la cual se tendrán que desarrollar los modelos que representan el dominio del problema. Estos modelos deben ser conformes a los metamodelos definidos como activos base. Una vez definidos estos modelos, la derivación del producto final estará enmarcada con la ejecución de las transformaciones las cuales permitirán representar estos modelos iniciales en modelos de la solución independientes de la tecnología. Finalmente, como último paso del proceso de derivación, se aplican otras transformaciones para representar la solución en una plataforma específica y se ejecutan las plantillas respectivas para generar el código fuente del producto. En la Figura 4 se muestra un proceso de desarrollo de productos para una MD-SPL. En este proceso se crea un modelo independiente de la plataforma (PIM1) y se ejecutan las transformaciones T1 y T2 para obtener los modelos de solución respectivos (PIM2 y PIMn), los cuales corresponden también a modelos independientes de la plataforma. Las transformaciones T3 y T4 se ejecutan para

7 MD-SPL: Oportunidades y Retos 7 Fig. 3. Actividades de la fase de desarrollo de activos base en una MD-SPL obtener los modelos de solución específicos para las plataformas X y Y (PSM X, PSM Y). Finalmente, a través de la ejecución de P1 y P2 se obtiene el código fuente del producto para las diferentes plataformas. Es importante tener en cuenta que como cualquier SPL, se debe considerar el manejo de la variabilidad durante el proceso de derivación de cada producto. La variabilidad generalmente es representada por un modelo de rasgos (el cual se explicará en la siguiente sección). A través de un modelo de rasgos se pueden Especificar características deseadas de un producto en particular. Una vez definidas las características que tendrá el sistema a generar, se realiza el proceso de derivación, el cual incluye la ejecución de un conjunto de reglas. De esta manera, para cada posible selección de características debe existir un conjunto de reglas que se encargan de crear un producto conforme a la funcionalidad seleccionada. La ventaja que tiene una MD-SPL sobre una SPL tradicional es que permite diseñar una Línea de producto en donde es posible abstraer los conceptos principales de los diferentes dominios y plasmarlos en metamodelos que, por naturaleza, limitan las posibles características soportadas por los productos. De esta manera, un conjunto de características determinado puede ser representado por un modelo que puede ser transformado automáticamente a través de los diferentes dominios hasta obtener el código fuente. 5 Retos En el momento de crear las MD-SPL se debe tener en cuenta algunos factores que impactan de manera directa el alcance de la Línea, la optimización del proceso

8 8 Andrés Romero y Fabián Ceballos Fig. 4. Actividades de la fase de desarrollo de productos en una MD-SPL de desarrollo, la mantenibilidad de los activos base y la administración general de la línea de productos. El camino que se ha recorrido en cuanto a la evolución de buenas prácticas y herramientas para manejar estos factores hacen que estos se conviertan a su vez en retos ya que todavía existe mucho trabajo e investigación en torno a estos temas. Algunos de los retos actuales de las líneas de producto basadas en modelos son: administración de la variabilidad, administración de la trazabilidad, verificación y validación. 5.1 Administración de la Variabilidad La administración de la variabilidad es la principal preocupación en el desarrollo, mantenimiento y evolución de las SPLs. La variabilidad puede ser definida como la diferencia funcional dentro de los productos de una Línea [13]. Los retos relacionados con la variabilidad se centran en su representación, y en la derivación de un producto a partir de la selección y expresión de esta variabilidad. El principio básico para representar la variabilidad se basa en que las características de un producto que se diferencian de otros productos deben poderse representar. Diferentes aproximaciones para representar y expresar la variabilidad se basan en los modelos de rasgos [19], [11]. Un modelo de rasgos es un árbol donde la raíz representa un concepto y sus nodos descendientes representan rasgos. Un rasgo es una propiedad del sistema que es relevante para algún stakeholder [12]. Semánticamente un modelo de rasgos describe un conjunto de todos

9 MD-SPL: Oportunidades y Retos 9 las posibles configuraciones válidas [11], donde una configuración corresponde a la selección de un conjunto determinado de rasgos. Fig. 5. Ejemplo de modelo de rasgos [10] Czarnecki et al. [12], clasifica los rasgos de la siguiente manera: obligatorios, opcionales o alternativos. Los rasgos obligatorios son aquellos que siempre deben ser tenidos en cuenta, los rasgos opcionales son aquellos que pueden ir o no dependiendo de la selección del usuario, finalmente los rasgos alternativos sirven como un mecanismo de agrupación. La figura 5 muestra un modelo de rasgos para soportar uno o más métodos de pagos en un sistema de comercio electrónico. Los rasgos obligatorios están representados por Líneas con un circulo relleno de color negro por ejemplo payment y taxcalculation. Los rasgos opcionales se distinguen por las Líneas que tienen un circulo sin relleno en su parte final, por ejemplo para el rasgo shipping. En esta misma figura los rasgos alternativos están representados por un semi-circulo que corta las Líneas de los rasgos, como es el caso del rasgo creditcard, debitcard y electroniccheque. Existen otras aproximaciones diferentes a los modelos de rasgos para expresar la variabilidad de una Línea de productos. Hendrickson y van der Hoek [1] proponen change sets y relationships. Un change set consolida puntos de variación relacionados dentro de una sola variación conceptual, es decir que se agrupan puntos de variación que tienen sentido y restricciones entre ellos. Los relationships gobiernan las posibles combinaciones válidas de change sets para componer de esta manera un producto en particular. En esta aproximación los autores proponen adicionalmente el versionamiento de los change sets facilitando la evolución de la Línea. En el enfoque de Tessier et al. [19] se representa la variabilidad a través de modelos de rasgos y utilizan estereotipos en los diagramas de clases para expresar los puntos de variación. La Figura 6 muestra un ejemplo de la representación de

10 10 Andrés Romero y Fabián Ceballos los puntos de variación. En este ejemplo se puede observar que la interface WatchControl tiene dos puntos de variación setdualtime y closedualtime. Fig. 6. Representación de los puntos de variación por estereotipos [19] Tessier et al. [19] propone modelos de decisión como una solución para la verificación y derivación de productos de la Línea. Un modelo de decisión es un árbol con caminos, donde cada camino es una secuencia de posibles resoluciones para un grupo de variantes. Un grupo de variantes es un conjunto de puntos de variación que tienen alguna restricción entre ellos. Es decir, que por cada posible configuración, el modelo de decisión es el encargado de decidir una secuencia de transformaciones (resoluciones) que permiten derivar un producto conforme a la selección de variantes. Garces et al. [13] propone la creación de un modelo de rasgos por cada uno de los metamodelos destino que se tengan en la Línea, de esta manera, se logra Especificar las características de un artefacto en cada dominio. En el enfoque tradicional de transformación entre modelos un elemento de origen siempre se transformaba a un elemento de destino, con esta nueva propuesta un elemento de origen puede tener múltiples representaciones en el modelo de destino dependiendo de la selección de rasgos que se realice en el modelo de rasgos. La idea anterior se puede ver expresada en la figura Administración de la Trazabilidad Otro de los grandes retos existentes en las Líneas de productos de software dirigidas por modelos es la administración de la trazabilidad. En las SPL tradicionales es preciso conocer las relaciones lógicas entre los artefactos creados en las diferentes fases de los procesos de desarrollo de software [3]. Esto aplica tanto para el proceso de desarrollo de activos base como para el proceso de desarrollo de productos. Cada uno de los artefactos creados en una fase tiene dependencias con otros artefactos creados en fases más tempranas, por ejemplo, un artefacto creado en la fase de implementación tiene dependencias con artefactos creados durante las fases de requerimientos y diseño. La administración de las dependencias entre estos artefactos constituye una gran complejidad y más aun si se trata de una MD-SPL puesto que el enfoque MDD utiliza un conjunto de nuevos

11 MD-SPL: Oportunidades y Retos 11 Fig. 7. Variabilidad en Líneas de productos basada en modelos[13] artefactos representados en metamodelos, transformaciones, modelos y plantillas de generación de código. En las MD-SPL se deben definir técnicas para administrar las dependencias y relaciones de los metaconceptos y transformaciones especificados inicialmente. Adicionalmente, durante el proceso de derivación de productos, es preciso conocer las relaciones de cada uno de los conceptos involucrados en la generación del producto ya que estos conceptos son transformados a través de los diferentes dominios de la Línea. Es preciso conocer las dependencias de estos conceptos de manera explícita con el fin de identificar los artefactos parciales y finales que se generaron a partir de estos y las decisiones que motivaron su generación. Actualmente, existen frameworks para el manejo de trazabilidad los cuales se basan en la creación de metamodelos que soportan los conceptos involucrados en la trazabilidad [2]. Estos metamodelos permiten manejar modelos que describen las relaciones y dependencias de los artefactos generados en las Líneas de producto dirigidas por modelos [3]. 5.3 Verificación y Validación Los conceptos de verificación y validación surgen como mecanismos encaminados a garantizar la calidad de los productos de software que se desarrollan [6]. Estos mecanismos permiten validar si los componentes involucrados en un producto

12 12 Andrés Romero y Fabián Ceballos de software son correctos, cumplen con las especificaciones definidas y su comportamiento refleja la intencionalidad para los cuales fueron construidos. Las SPL tradicionales definen como activos base los procesos y herramientas para realizar la verificación y validación de los diferentes componentes que conforman un producto de software. De esta manera, una SPL puede definir un procedimiento de control de calidad y apoyarse en herramientas de pruebas para comprobar el correcto funcionamiento de los componentes derivados a partir del proceso de composición. Debido al nuevo enfoque, las MD-SPL tienen que asegurar la calidad a nivel de sus elementos de primera clase: los modelos. El aumento en el nivel de abstracción propuesto por MDD hace que ya no sea suficiente realizar la verificación y validación a nivel del código, sino que es preciso contar con estrategias y mecanismos que aseguren la calidad a nivel de los modelos y sus transformaciones. De esta manera, se crea un nuevo reto asociado a la verificación y validación dentro de las MD-SPL. La verificación y validación en las MD-SPL se puede ver desde 3 perspectivas: a nivel de los modelos, a nivel de las transformaciones y a nivel de las pruebas basadas en modelos (Model-Driven Testing). A nivel de los modelos la verificación intenta mostrar que estos representan de manera correcta el comportamiento de un sistema del mundo real (Correctitud Semántica) y que cumplen con las reglas del lenguaje sobre el cual fueron construidos (Correctitud Sintáctica) [18]. Unhelkar describe un framework para esta verificación [20]. La validación evalúa si el comportamiento observable del modelo cumple con los requerimientos exigidos por el usuario [18], esta validación se puede realizar a través de la simulación de modelos tal como lo ilustra Combemale [7] y Edwards [8]. A nivel de las transformaciones, la verificación y validación se relacionan a la ejecución correcta de la transformación, la creación de un modelo destino válido, la no pérdida de información [16] y a la terminación y confluencia durante la ejecución de las transformaciones [15]. Estas dos últimas propiedades hacen referencia a que dado un modelo de origen, la transformación siempre produzca un único modelo como resultado. A nivel de las pruebas basadas en modelos (Model-Driven Testing), la verificación y validación se relaciona con la generación automática de casos de prueba a partir de los modelos, de esta manera, de la misma forma en que se generan los componentes de software, se generan también sus escenarios de prueba. Kamoun propone una especificación que genera automáticamente escenarios de prueba a partir de requerimientos formales [14]. 6 Conclusiones La combinación de desarrollo de software basado en modelos y Líneas de productos son una forma de diseñar y desarrollar software que gana terreno día a día. Resuelven el problema de la independencia de la plataforma sobre la que se desea la aplicación, facilita la generación de la mayor parte de artefactos, reduciendo

13 MD-SPL: Oportunidades y Retos 13 considerablemente el tiempo de desarrollo, incrementando la calidad de los productos y permitiendo posponer decisiones de implementación en el proceso de desarrollo. Otra característica importante de esta nueva forma de desarrollar software se basa en el lenguaje que se utiliza para modelar la solución. Los modelos que sirven para representar lo esencial de cada problema son empleados como elementos de primera clase para el desarrollo de la aplicación. El uso de modelos permite separar preocupaciones (concerns) en diferentes vistas de la solución. Esta aproximación (MD-SPL) se encuentra actualmente en construcción. Diferentes autores proponen soluciones para cada uno de los retos que incluye este tipo de desarrollo de software. Los principales problemas se relacionan con la especificación y derivación de un producto en particular, es decir, la administración de la variabilidad. Otros retos, como trazabilidad, validación, verificación, etc. son igual de importantes, lo cual implica que existen propuestas que permiten solucionar parcial o totalmente el problema. Una vez se tengan soluciones para cada uno de los retos mencionados anteriormente, el reto consistirá en seleccionar las mejores soluciones y unificarlas para la creación de un framework que facilite el desarrollo de software explotando todas las capacidades de las Líneas de productos dirigidas por modelos. Referencias 1. Hendrickson Scott A. and Andre van der Hoek, Modeling product line architectures through change sets and relationships, ICSE '07: Proceedings of the 29th international conference on Software Engineering, IEEE Computer Society, 2007, pp Andsousa, Uirakulesza, Andreas Rummler, Nicolas Anquetil, Ralf Mitschke, A. Moreira, V. Amaral, and J. Arajo, A model-driven traceability framework to software product line development, ECMDA Traceability Workshop ECMDA-TW ( 2008 Proceedings), SINTEF ICT, N. Anquetil, B. Grammel, I. Galvñao, J. Noppen, S. Shakil, H. Arboleda, A. Rashid, and A. Garcia, Traceability for model driven, software product line engineering, Proceedings of the 4th Workshop on Traceability at the 4th European Conference on Model Driven Architecture (Berlin, Germany), June Hugo Arboleda, Rubby Casallas, and Jean claude Royer, Implementing an mda approach for managing variability in product line construction using the gmf and gme frameworks, 5th Nordic Workshop on Model Driven Software Engineering. August 27 29, 2007, pp Paul Clements and Linda Northrop, Software product lines: practices and pat- terns, vol , Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, James S. Collofello, Introduction to software verification and validation, Curriculum Module SEI-CM , Software Engineering Institute, Carnegie Mellon University, Benoit Combemale, Xavier Crgut, Jean-Patrice Giacometti, Pierre Michel, and Marc Pantel, Introducing simulation and model animation in the mde topcased toolkit, European Congress on Embedded Real-Time Software (ERTS), Toulouse, Socit des Ingnieurs de l'automobile, 2008.

14 14 Andrés Romero y Fabián Ceballos 8. George Edwards, Chiyoung Seo, and Nenad Medvidovic, Construction of analytic frameworks for component-based architectures, Proceedings of the Brazilian Symposium on Software Components, Architectures and Reuse (SBCARS), Hassan Gomaa, Designing software product lines with uml 2.0: From use cases to pattern-based software architectures, Software Product Line Conference, th International, 2006, p Czarnecki K., Overview of generative software development, LNCS 3566, 2005, pp Czarnecki K. and Antkiewicz Michal, Mapping features to models: A template approach based on superimposed variants, GPCE, LNCS 3676, 2005, pp Czarnecki K., Helsen S., and Eisenecker U., Staged configuration using feature models, Proc. of the 3th SPLC, LNCS 3154, 2004, pp Garces K., Parra C., Arboleda H., Yie A., and Casallas R., Variability management in a model-driven software product line, Avances en Sistemas e Informática 4 (2007), no. 2, Souha Kamoun and Pierre Boulet, Model-based testing of the ertms system with sysml and marte, 4th International Workshop on Model Driven Engineering, Verification, and Validation: Integrating Verification and Validation in MDE, Jochen Malte Kster, De nition and validation of model transformations, Software and System Modeling 5 (2006), no. 3, 233{ F. J. Lucas, F. Molina, and A. Toval, Una propuesta de proceso expl cito de vv en el marco de mda, IV Jornadas de Trabajo DYNAMICA, Archena, Murcia, J. Miller and J. Mukerji, Mda guide version 1.0.1, Tech. report, Object Management Group (OMG), Mohagheghi Parastoo and Aagedal Jan, Evaluating quality in model-driven engineering, MISE '07: Proceedings of the International Workshop on Modeling in Software Engineering, IEEE Computer Society, 2007, p Tessier Patrick, G erard S ebastien, FranTerrie, and Geib Jean M., Using variation propagation for model-driven management of a system family, LNCS 3714, 2005, pp Anthony J. H. Simons, Verification and validation for quality of uml 2.0 models. by bhuvan unhelkar. published by john wiley & sons, inc., hoboken, nj, u.s.a., isbn: , 271 pp: Book reviews, Softw. Test. Verif. Reliab. 16 (2006), no. 1, Markus Volter and Thomas Stahl, Model-driven software development : Technology, engineering, management, John Wiley & Sons, June 2006.