Modelos de Decisión Como Mecanismo de Composición de Reglas de Transformación

Transcripción

1 Modelos de Decisión Como Mecanismo de Composición de Reglas de Transformación Andres Romero y Hugo Arboleda Universidad de Los Andes, Cra. 1 N 18A 10, Bogotá, Colombia {aa.romero354,hf.arboleda34}@uniandes.edu.co Resumen El proceso de derivación de productos en las Líneas de Productos de Software Dirigidas por Modelos (MD-SPL) se basa en reglas de transformación que permiten transformar un modelo del dominio origen en un modelo del dominio destino. Para derivar un producto de la línea, se debe ejecutar un conjunto de reglas de transformación en un orden específico. Tanto las reglas de transformación como su orden de ejecución, dependen de los variantes seleccionados en la configuración del producto que se quiere derivar. La mayoría de propuestas al proceso de derivación acoplan los variantes con las reglas de transformación, lo que genera problemas de mantenibilidad y evolución. En este artículo se propone un modelo de decisión como mecanismo de composición de reglas de transformación. Este modelo relaciona variantes con reglas de transformación, especificando el conjunto y orden de reglas de transformación que deben ser ejecutadas para derivar un producto dada su configuración. El modelo de decisión propuesto es independiente de un lenguaje de transformación particular lo que permite expresar de manera general la estrategia de composición de reglas de transformación. Key words: Líneas de Productos de Software, Desarrollo Dirigido por Modelos, Modelos de Decisión, Composición de reglas de transformación. 1. Introducción Las Líneas de Productos de Software Dirigidas por Modelos (MD-SPL) son un enfoque de desarrollo de software que combina las ventajas del desarrollo dirigido por modelos y la ingeniería de líneas de productos de software. En las MD-SPL los productos son creados a partir de la reutilización de activos base [1], entre los cuales se encuentran los modelos y reglas de transformación. Las líneas de productos tienen variantes, los cuales definen las posibles características que pueden tener los productos de la línea. En consecuencia, los activos base que componen la línea son personalizados y configurados de acuerdo con variantes seleccionados de una configuración, que define un producto particular de la línea [2]. El proceso de derivación de productos en las MD-SPL se realiza de manera incremental; se parte de un modelo inicial que es transformado a cada uno de los dominios que componen el sistema; al final, un modelo representando el dominio del lenguaje de programación es transformado a texto, i.e., al lenguaje de

2 2 Romero et al. programación correspondiente. Cada uno de estos dominios es descrito por un metamodelo y representa una preocupación del sistema: arquitectura, plataforma, lenguaje, etc. La transformación entre modelos se realiza a través de reglas de transformación, que toman elementos del dominio origen y los transforman en elementos del dominio destino. Los mecanismos de composición de reglas de transformación tienen como objetivo especificar el conjunto y orden de reglas de transformación que derivan un producto para una configuración en particular. Aproximaciones a la composición de reglas de transformación (e.g. [3,4,5]) se centran en el uso de funcionalidades específicas que proveen los lenguajes de transformación. Lo anterior conlleva a problemas de portabilidad de las estrategias de composición de un lenguaje de transformación a otro; limitando la composición de reglas de transformación al conjunto de funcionalidades que puede procesar cada motor de transformación. En este artículo se propone el uso de un modelo de decisión como mecanismo de soporte para la composición de reglas de transformación. Nuestro modelo de decisión relaciona variantes con reglas de transformación, especificando el conjunto y orden de ejecución de reglas de transformación que deben ser aplicadas en la derivación de un producto, dependiendo de los variantes seleccionados en la configuración. El modelo de decisión representa a alto nivel la composición de reglas de transformación, sin incluir detalles específicos de funcionalidades que ofrecen los lenguajes de transformación. Esta representación por ser abstracta no puede ejecutarse directamente sobre un motor de transformación, en consecuencia, se debe transformar el modelo de decisión a estrategias de composición concretas sobre los lenguajes de transformación, las cuales pueden ser ejecutadas sobre un motor de transformación en particular. A modo de ejemplo presentamos el uso del modelo de decisión sobre los lenguajes de transformación Xtend [6] y ATL [7], los cuales presentan estrategias de composición diferentes. Este artículo se encuentra organizado de la siguiente manera, el capitulo 2 explica los conceptos de los modelos de decisión y las aproximaciones relacionadas con la composición de reglas de transformación. El capitulo 3 introduce un caso de estudio que servirá para explicar la estrategia de solución. En el capítulo 4 se explica la estrategia de solución propuesta, se explica el uso de los modelos de decisión y el proceso de derivación de productos mediante el uso de este mecanismo. El capítulo 5 muestra cómo el modelo de decisión puede ser transformado a estrategias concretas de composición sobre dos lenguajes de transformación diferentes: Xtend y ATL. Por último, el capítulo 6 presenta conclusiones y trabajo futuro. 2. Contexto A continuación se realizará una breve descripción de los modelos de decisión, resumiendo sus principales conceptos. Los modelos de decisión serán utilizados para componer reglas de transformación, expresando esta composición de manera independiente de la plataforma. Adicionalmente, exploraremos los conceptos y

3 Modelos de Decisión como Estrategia de Composición 3 aproximaciones a la composición de reglas de transformación, que ayudaran a ejemplificar los problemas propuestos en este artículo Modelos de decisión Los modelos de decisión son modelos que capturan la variabilidad de una línea de productos en términos de decisiones abiertas y posibles resoluciones [8]. Las decisiones son puntos que requieren de la intervención de un usuario durante el proceso de derivación, para personalizar los activos de un producto. Estas decisiones se encuentran dadas en términos de los variantes de la línea. Las resoluciones son las opciones que se tienen como solución a una decisión, estas resoluciones tienen efectos, que indican las acciones específicas que se deben realizar para configurar un activo. Los modelos de decisión reducen la brecha que existe entre la variabilidad a nivel conceptual y la variabilidad a nivel de implementación. Esto se logra a través de la relación de variantes con elementos concretos de configuración de activos, en nuestro caso reglas de transformación. Los modelos de decisión han sido ampliamente usados en las líneas de producto [9,4,10], guiando el proceso de derivación de productos Composición de reglas de transformación La composición de reglas de transformación consiste en agrupar y ordenar conjuntos de reglas de transformación permitiendo derivar un producto específico de la línea, dependiendo de los variantes que han sido seleccionados en una configuración. Diferentes enfoques para componer reglas de transformación buscan mejorar el proceso de derivación de productos mediante aportes en mantenibilidad, escalabilidad y reusabilidad de las reglas de transformación (e.g. [3,5,4]). Wagelaar [3] clasifica los métodos de composición de reglas de transformación en dos clases: métodos de composición interna y métodos de composición externa. La composición interna permite componer dos reglas de transformación en una nueva regla de transformación. La composición externa encadena una secuencia de reglas de transformación, usando los modelos de salida de una regla de transformación como modelos de entrada para otra regla de transformación. Oldevik [5] propone los diagramas de actividades de UML2 como un método de composición externa de reglas de transformación. En estos diagramas, las actividades representan las transformaciones que deben llevarse a cabo para derivar un producto. Estas actividades se encuentran anotadas mediante estereotipos, representando de este modo el tipo de transformación que se debe realizar (i.e. modelo a modelo, modelo a texto, etc.). En esta aproximación un producto es derivado mediante la ejecución de las actividades que componen el flujo, en donde cada actividad recibe un modelo de entrada y genera un modelo de salida. Esta aproximación no ofrece mecanismos de composición interna, los cuales son útiles para configurar activos de acuerdo con variantes seleccionados en una configuración.

4 4 Romero et al. Wagelaar [3] propone un método de composición interna de reglas de transformación escritas en ATL (ATLAS Transformation Language) [7] llamado superimposición de módulos. Un módulo de transformación es una agrupación de reglas de transformación que transforman un modelo de un dominio a otro. En esta aproximación las reglas de transformación de un módulo son sobre impuestas por reglas de transformación de otro módulo. El resultado de la superimposición es un nuevo módulo de transformación, que contiene la unión de reglas de transformación de los módulos sobre impuestos. En caso que existan reglas de transformación con el mismo nombre entre los módulos a sobre imponer, se realiza un proceso de sobre escritura, en donde el contenido de la regla original es cambiado por el contenido de la regla sobre impuesta. Esta propuesta de composición de reglas de transformación no ofrece mecanismos de composición externa y tampoco especifica cómo es el proceso de derivación de un producto de la línea a través de la sobre imposición de módulos, dependiendo de los variantes seleccionados en una configuración. Groher y Voelter [6] proponen el uso de aspectos en el desarrollo de las líneas de productos orientadas por modelos. De este modo los aspectos interceptan llamados a reglas de transformación y adicionan comportamiento. Estos aspectos se relacionan con variantes, condicionando el entretejido de los aspectos al estado de los variantes en la configuración a derivar. Arboleda y Colegas [4] proponen modelos de decisión como método de composición interna y externa para reglas de transformación, escritas en los lenguajes de transformación Xtend y Xpand de oaw (openarchitectureware) [11]. La composición interna se realiza usando los aspectos propuestos por Groher y Voelter. Adicionalmente, el modelo de decisión especifica la secuencia de modelos de transformación que deben ser ejecutados para derivar un producto, la salida de un modelo de transformación es pasada como entrada al siguiente modelo de transformación. La propuesta de Arboleda y Colegas a diferencia de las anteriores, permite componer reglas de transformación a nivel externo e interno, sin embargo su estrategia de composición se basa en funcionalidades específicas de los lenguajes de transformación de oaw. Lo cual implica que la estrategia de composición no pueda ser utilizada en otros lenguajes de transformación diferentes como por ejemplo ATL. Las anteriores aproximaciones a la composición de reglas de transformación presentan propuestas de composición diferentes, algunas utilizan aspectos, otras sobre escriben reglas de transformación, etc. Esto se debe a que los métodos de composición se encuentran limitados a las funcionalidades de cada uno de los lenguajes de transformación. En consecuencia es difícil migrar la estrategia de composición entre lenguajes de transformación, puesto que, las estrategias de composición están dadas en términos de funcionalidades específicas de los lenguajes de transformación. El modelo de decisión propuesto en este artículo es una generalización del trabajo realizado en [4], en el que se busca expresar de manera general un método de composición que no acople las reglas de transformación con variantes y que pueda ser utilizado sobre cualquier lenguaje de reglas de transformación.

5 3. Ejemplo Ilustrativo Modelos de Decisión como Estrategia de Composición 5 A modo de ejemplo ilustrativo introduciremos el caso de estudio del administrador de colecciones [4], el cual es una línea de productos basada en los principios de la ingeniería dirigida por modelos (MDE). Esta línea de productos permite derivar productos que manejan colecciones de entidades. Un producto (Figura 1 (a)) que se puede derivar de esta línea puede ser un colegio que administra colecciones de estudiantes, los cuales tienen un código, nombre, dirección y correo. Otro producto que se podría derivar de esta línea puede ser una tienda de discos (Figura 1 (b)) que administra colecciones de discos de música, los cuales pueden tener un nombre, artista, género y fecha de lanzamiento. Figura 1. Ejemplos de productos derivados de la línea de productos del administrador de colecciones. La línea de productos del administrador de colecciones tiene varios puntos de variación, permitiendo derivar productos con características particulares. Los puntos de variación definen características puntuales del producto que pueden variar, las posibles opciones que puede tomar un punto de variación son llamadas variantes. Por ejemplo el caso de estudio del administrador de colecciones tiene un punto de variación para el tipo de vista de información, la cual muestra la información de las entidades de la colección. Este punto de variación tiene dos variantes (Single y Grid) que definen el tipo de vista de información. Una vista de información de tipo Single (Figura 1 (a)) muestra la información de una sola

6 6 Romero et al. entidad. La vista de información de tipo Grid (Figura 1 (b)) muestra en una tabla la información de todas las entidades que tiene la colección. En esta línea de productos utilizamos tres metamodelos para representar los dominios del sistema. El metamodelo del espacio del problema (ProblemSpaceMetamodel) representa el dominio de negocio y permite especificar la entidad que va a ser administrada. El metamodelo del núcleo (KernelMetamodel) representa a bajo nivel la entidad a administrar y las operaciones que se pueden llevar a cabo sobre el administrador de colecciones. El metamodelo de interfaz gráfica de usuario (GuiMetamodel) representa las vistas con las que podrá interactuar un usuario para realizar operaciones sobre el sistema. Figura 2. Proceso de derivación en el caso de estudio del administrador de colleciones. La Figura 2 presenta de manera general el proceso de derivación en la línea de productos del administrador de colecciones. El proceso de derivación se realiza de manera incremental partiendo de un modelo del espacio del problema (ProblemSpaceModel). A este modelo se le aplican dos transformaciones de modelo a modelo. Una para convertir el modelo del espacio del problema a modelo del núcleo (KernelModel) y la otra para convertirlo a modelo de interfaz gráfica de usuario (GuiModel). A cada uno de estos modelos generados ( KernelModel, GuiModel ) se le aplica una transformación de modelo a texto, generando de este modo el código fuente del producto. La transformación del modelo del espacio del problema al modelo de interfaz gráfica se encuentra compuesto por cuatro reglas de transformación: ps2gui, createinformationview, creategridinformationview y createsingleinformationview. La regla de transformación ps2gui transforma los elementos del modelo del espacio del problema a elementos del modelo de interfaz gráfica. La regla de transformación createinformationview crea la vista de información en el modelo GUI, esta vista muestra la información de las entidades en la colección. La regla de transformación creategridinformationview

7 Modelos de Decisión como Estrategia de Composición 7 crea una vista de información, en donde la información de todas las entidades de la colección es mostrada mediante una tabla. La regla de transformación createsingleinformationview crea una vista de información en la cual se muestra la información de una entidad. La ejecución de las reglas de transformación que crean los elementos variables de la línea depende de los variantes seleccionados en la configuración por derivar. Por ejemplo, la regla de transformación createsingleinformationview será aplicada en el proceso de transformación solo si el variante Single se encuentra seleccionado en la configuración. Esto mismo sucede con la regla de transformación creategridinformationview, cuya ejecución depende de la selección del variante Grid. 4. Estrategia Global de solución Nuestro modelo de decisión permite componer reglas de transformación a nivel externo e interno, especificando el conjunto y orden de reglas de transformación que deben ser aplicadas para derivar un producto particular de la línea. Este modelo de decisión por ser una abstracción no puede ser ejecutado por un motor de transformación. Sin embargo se pueden definir transformaciones entre el modelo de decisión y estrategias concretas de composición en los lenguajes de transformación, las cuales pueden ser ejecutados por su respectivo motor de transformación. Figura 3. Composición externa por el modelo de decisión. A nivel de composición externa de reglas de transformación el modelo de decisión propuesto permite definir la secuencia de transformaciones que deben aplicarse para derivar un producto de manera incremental. Para cada una de estas transformaciones se puede especificar sus modelos de entrada y salida; los modelos de salida pueden ser utilizados como modelos de entrada para otras

8 8 Romero et al. transformaciones. La Figura 3 presenta un ejemplo de composición externa de reglas de transformación para el caso de estudio del administrador de colecciones (ejemplo ilustrado en la sección anterior). Este ejemplo muestra dos transformaciones: problemspace2gui (transformación de modelo a modelo) y gui2code (transformación de modelo a texto). La primera transformación que se aplica en este ejemplo es problemspace2gui, la cual transforma un modelo del espacio del problema a un modelo GUI, el cual representa La interfaz gráfica con la que interactúa el usuario. La siguiente transformación en ejecutarse es gui2code, la cual recibe el modelo GUI que fue generado por la transformación anterior y convierte este modelo a código fuente. Figura 4. Composición interna por el modelo de decisión. A nivel de composición interna de reglas de transformación, nuestro modelo de decisión permite especificar las reglas de transformación que deben componerse dependiendo del estado de los variantes en la configuración a derivar. La Figura 4 presenta un ejemplo de composición interna para el caso de estudio del administrador de colecciones. En este ejemplo el grupo de transformaciones TransformProblemSpace2gui se encuentra compuesto por dos reglas de transformación: ps2gui y createinformationview. La regla de transformación ps2gui se encarga de transformar un modelo del espacio del problema a un modelo de interfaz gráfica de usuario, adicionalmente, esta regla utiliza la regla de transformación createinformationview para crear la vista de información del sistema. Dado que la vista de información puede variar entre Single y Grid se deben realizar dos procesos de composición de reglas de transformación dependiendo de los variantes seleccionados en la configuración. Por ejemplo, si el variante Grid

9 Modelos de Decisión como Estrategia de Composición 9 se encuentra seleccionado, entonces se deben componer las reglas de transformación del grupo GridViewModule con las reglas de transformación del grupo TransformProblemSpace2gui. Como resultado de la composición de estos dos grupos de reglas de transformación se debe aplicar en algún punto la regla de transformación creategridinformationview, la cual crea una vista de información de tipo Grid Metamodelo de Decisión Hemos creado un metamodelo para guiar la creación de los modelos de decisión, que representa los conceptos de composición interna y externa que deben realizarse para derivar un producto de la línea. La Figura 5 presenta el metamodelo de decisión propuesto. Figura 5. Metamodelo de decisión. Un Modelo de decisión se encuentra compuestos por varios modelos de transformación, los cuales representan las transformaciones entre modelos que deben realizarse en el proceso de derivación de un producto. Los modelos de transformación pueden ser de dos tipos: transformación de modelo a modelo ó transformación de modelo a texto. Las transformaciones de modelo de modelo reciben un modelo de entrada y generan un modelo de salida. Las transformaciones de modelo a texto reciben un modelo de entrada y generan texto a partir de este modelo. El orden en que son aplicados estos modelos de transformación se encuentra definido por las relaciones first (primer modelo de transformación en aplicarse) y next (siguiente modelo de transformación en aplicarse). Para cada modelo de transformación se definen sus modelos de entrada y salida, los modelos de salida son creados por transformaciones de modelo a modelo y pueden ser utilizados como modelos de entrada para otros modelos de transformación.

10 10 Romero et al. Los conceptos descritos anteriormente son utilizados para representar los mecanismos de composición externa. En el ejemplo presentado en la Figura 3 se observan dos modelos de transformación, uno de modelo a modelo (problemspace2gui) y otro de modelo a texto (gui2code). El modelo de transformación problemspace2gui recibe como entrada un modelo llamado problemspacemodel y genera un modelo guimodel, el cual es pasado como entrada al modelo de transformación gui2code. El orden de estos modelos es definido por las relaciones first y next. Nuestros modelos de transformación se encuentran compuestos por módulos de transformación, los cuales son agrupaciones de reglas de transformación. Cada modelo de transformación tiene un módulo principal y varios módulos variables. El modulo principal siempre se aplica en la derivación de un producto y tiene la responsabilidad de crear los elementos comunes de la línea. Los módulos variables crean los elementos variables y se relacionan con el módulo principal. Los módulos variables tienen asociada una condición de ejecución expresada en términos de los estados (seleccionado, no seleccionado) de los variantes de la línea y determina si el modulo variable va a estar relacionado con su módulo principal. De este modo si la condición de ejecución se resuelve de manera verdadera, las reglas de transformación del módulo variable se relacionaran con las reglas de transformación del módulo principal. En el método de composición interno no se especifica si las reglas de transformación del módulo variable reemplazan o complementan las reglas de transformación del modulo principal. Esta decisión depende de cómo hayan sido diseñadas las reglas de transformación y de las funcionalidades específicas del lenguaje de transformación que se utilice. Los conceptos módulo de transformación y condición de ejecución son utilizados para representar el mecanismo de composición interna en el modelo de decisión. En la figura Figura 4 presentamos un ejemplo de composición interna, para este ejemplo el modelo de transformación problemspace2gui tiene un módulo principal (TransformProblemSpace2gui) y dos módulos variables (GridViewModule y singleviewmodule). Estos módulos variables se encuentran relacionados con el módulo principal. La composición interna de reglas de transformación se realizará siempre y cuando se cumpla la condición de ejecución que tiene asociada cada módulo variable, por ejemplo, en caso que el variante Grid se encuentre seleccionado en la configuración, la condición de ejecución que tiene asociada el módulo variable GridViewModule se resolverá de manera verdadera, lo cual implica que se deben componer las reglas de transformación del módulo principal TransformProblemSpace2gui con las reglas de transformación del módulo variable GridViewModule. 5. Modelo de Decisión sobre Lenguajes de transformación específicos 5.1. Modelo de decisión en OAW oaw (openarchitectureware) [11] es un framework Java para construir aplicaciones utilizando el enfoque de desarrollo de software dirigido por modelos.

11 Modelos de Decisión como Estrategia de Composición 11 Este framework expone una serie de lenguajes y herramientas que permiten: validar modelos, transformar modelos a modelos, transformar modelos a texto, entre muchas otras funcionalidades. Figura 6. Proceso de derivación en OAW La Figura 6 presenta la estrategia general de derivación en este framework usando nuestro modelo de decisión. El modelo de decisión es transformado a un Workflow de oaw el cual define la secuencia de actividades que deben llevarse a cabo para derivar un producto, por ejemplo: cargar modelos, ejecutar reglas de transformación, serializar modelos, etc. Dadas las funcionalidades que ofrecen los workflow, se pueden derivar productos especificando la configuración de estos. Los lenguajes de transformación de oaw soportan aspectos, de este modo se pueden definir reglas de transformación que interceptan otras reglas de transformación. La composición interna de reglas de transformación puede ser definida a través de estos aspectos, de esta manera las reglas de transformación crean los elementos comunes y son interceptadas por aspectos que crean los elementos variables de la línea. La ejecución de estos aspectos depende del estado de los variantes en la configuración a derivar. La estrategia de derivación concreta que se utiliza en este framework a través de modelos de decisión se describe detalladamente en [4]. La Figura 7 presenta el metamodelo de workflows de oaw, que definimos para realizar la transformación del modelo de decisión a representaciones concretas sobre este framework. El proceso de transformación se resume a continuación: Los modelos de transformación junto con sus módulos principales son transformados a componentes invokerule, encargados de invocar reglas de transformación, las cuales pueden ser de tipo modelo de a modelo (M2MTransformation) ó modelo a texto (M2TTransformation). Los módulos variables junto con sus condiciones de ejecución son transformados a componentes ExecuteAspect los cuales se encargan de especificar los aspectos que se ejecutan dependiendo de los variantes seleccionados en la configuración. El elemento Configuration del modelo de decisión se transforma a un elemento LoadConfiguration en el modelo de workflow, especificando la configuración que debe ser cargada para la derivación del producto.

12 12 Romero et al. Figura 7. Metamodelo Workflow de OAW 5.2. Modelo de decisión en ATL En ATL, el proceso de composición y derivación de productos es diferente. El modelo de decisión es transformado a un script ANT [12] dependiendo de la configuración que se desee derivar. Este script ANT tiene una serie de tareas AM3 (ATLAS MegaModel Management) [13], las cuales permiten ejecutar operaciones relacionadas con modelos, por ejemplo: cargar un modelo, invocar reglas de transformación, entre otras. El script de ANT generado contiene las operaciones que deben llevar a cabo para derivar un producto un producto específico. Este proceso de derivación puede observarse en la Figura 8. Figura 8. Proceso de derivación en ATL En ATL la composición externa se realiza a través de las actividades descritas en al archivo ANT, en donde se especifican los modelos de transformación que deben ejecutarse para derivar un producto. La composición interna se realiza mediante la superimposición de módulos, estrategia planteada por Wagelaar en [3]. De este modo las reglas de transformación de un módulo serán reemplazadas por reglas de transformación del módulo sobre impuesto. Esta estrategia de derivación de productos utilizando nuestro modelo de decisión es descrita en más detalle en [14].

13 Modelos de Decisión como Estrategia de Composición 13 Figura 9. Metamodelo ANT La Figura 9 muestra una versión simplificada del metamodelo ANT que se propone en [14]. El modelo de decisión es transformado a un modelo conforme a este metamodelo dependiendo de los variantes que se encuentren seleccionados en la configuración a derivar. Los modelos de transformación junto con su módulo principal pertenecientes al modelo de decisión, son transformados a tareas AM3ATL, las cuales permiten invocar reglas de transformación escritas en ATL. Los módulos variables que serán aplicados en el proceso de derivación son transformados a tareas AM3Superimpose, las cuales representan los módulos que serán sobre impuestos a las reglas de transformación AM3ATL. 6. Conclusiones y Trabajo Futuro En este artículo hemos presentado un modelo de decisión como mecanismo de composición de reglas de transformación. El modelo de decisión propuesto facilita la composición externa e interna de reglas de transformación, determinando el conjunto y orden de reglas de transformación que deben ser aplicadas para derivar un producto específico de la línea, de acuerdo de variantes seleccionados en configuraciones. Los modelos de decisión se expresan en términos de conceptos del dominio de composición de reglas de transformación. De este modo, no se tiene en cuenta funcionalidades específicas de los lenguajes de transformación para expresar composición de reglas de transformación. En consecuencia, Las estrategias de composición que se definan con nuestro modelo de decisión pueden ser llevadas a estrategias de composición concretas sobre cada lenguaje de transformación a través de transformaciones, tal y como se ejemplifico para oaw y ATL. Sin embargo, es necesario explorar cómo integrar los modelos de decisión sobre otros lenguajes de transformación como QVT [15], VIATRA [16], etc. Antes se debía expresar una estrategia de composición diferente por cada lenguaje de transformación, lo cual implicaba problemas de portabilidad para la estrategia de composición formulada. Ahora con el uso de los modelos de

14 14 Romero et al. decisión, la estrategia de composición de reglas de transformación se expresa de manera abstracta, y a través de transformaciones se puede obtener de manera automática la estrategia de composición concreta sobre cualquier lenguaje de transformación que se desee. De este modo, nuestro modelo de decisión facilita la portabilidad de las estrategias de composición permitiendo llevar la solución de composición de un lenguaje de transformación a otro. Para trabajo futuro exploraremos las transformaciones que deban realizarse para integrar otros lenguajes de transformación con nuestro modelo de decisión. También trabajaremos en mecanismos de composición de reglas de transformación, cuando existen restricciones entre los variantes de una línea de productos. Por ejemplo, la selección simultánea de dos variantes en una configuración podría implicar una composición de reglas de transformación diferente a la composición de reglas de transformación que se realiza si un solo variante esta seleccionado. Referencias 1. Bosch, J.: Design and use of software architectures: adopting and evolving a product-line approach. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA (2000) 2. Czarnecki, K., Antkiewicz, M.: Mapping features to models: A template approach based on superimposed variants. In Glück, R., Lowry, M.R., eds.: GPCE. Volume 3676 of Lecture Notes in Computer Science., Springer (2005) Wagelaar, D.: Composition techniques for rule-based model transformation languages. In: First International Conference on Theory and Practice of Model Transformations (ICMT). (2008) 4. Arboleda, H., Romero, A., Casallas, R., Royer, J.: Product derivation in a modeldriven software product line using decision models. In: Proceedings of the 12th Iberoamerican Conference on Requirements Engineering and Software Environments, ideas, Medellín, Colombia (April, 2009) 5. Oldevik, J.: Transformation composition modelling framework. (2005) 6. Groher, I., Voelter, M.: Aspect-oriented model-driven software product line engineering. (2008) 7. Jouault, F., Kurtev, I.: Transforming models with atl. In Bruel, J.M., ed.: MoDELS Satellite Events. Volume 3844 of Lecture Notes in Computer Science., Springer (2005) Forster, T., Muthig, D., Pech, D.: Understanding decision models visualization and complexity reduction of software variability. In Heymans, P., Kang, K.C., Metzger, A., Pohl, K., eds.: VaMoS. ICB Research Report (2008) Dhungana, D., Grünbacher, P., Rabiser, R.: Decisionking: A flexible and extensible tool for integrated variability modeling. In Pohl, K., Heymans, P., Kang, K.C., Metzger, A., eds.: VaMoS. Volume of Lero Technical Report. (2007) Atkinson, C., Bayer, J., Muthig, D.: Component-based product line development: the kobra approach. In: Proceedings of the first conference on Software product lines : experience and research directions, Norwell, MA, USA, Kluwer Academic Publishers (2000) OpenArchitectureWare: Openarchitectureware. openarchitectureware.org (2009)

15 Modelos de Decisión como Estrategia de Composición Apache: Ant. (2009) 13. Allilaire, F., Bézivin, J., Jouault, F., Kurtev, I.: Atl - eclipse support for model transformation. In: Proceedings of the Eclipse Technology exchange workshop (etx) at the ECOOP 2006 Conference, Nantes, France (2006) 14. Kling, W.: Using decision models on atl. (2009) 15. Jouault, F., Kurtev, I.: On the architectural alignment of atl and qvt. In: SAC 06: Proceedings of the 2006 ACM symposium on Applied computing, New York, NY, USA, ACM (2006) Balogh, A., Varró, D.: Advanced model transformation language constructs in the viatra2 framework. In: SAC 06: Proceedings of the 2006 ACM symposium on Applied computing, New York, NY, USA, ACM (2006)