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

(1)

Composici´on de Reglas de Transformaci´on

Andres Romero y Hugo Arboleda

Universidad de Los Andes, Cra. 1 N◦ 18A 10, Bogot´a, Colombia {aa.romero354,hf.arboleda34}@uniandes.edu.co

Resumen El proceso de derivación de productos en las L´ıneas de Pro- ductos 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´ıcu- lo 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 trans- formació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´on

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´on 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´on es transformado a texto, i.e., al lenguaje de

(2)

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 ob- jetivo 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)

aproximaciones a la composici´on de reglas de transformaci´on, que ayudaran a ejemplificar los problemas propuestos en este art´ıculo.

2.1. Modelos de decisi´on

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´on han sido ampliamente usados en las l´ıneas de producto [9,4,10], guiando el proceso de derivaci´on de productos.

2.2. Composici´on de reglas de transformaci´on

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 con- figuració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 transforma- ció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éto- do 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 es- tereotipos, 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)

Wagelaar [3] propone un método de composición interna de reglas de trans- formación escritas en ATL (ATLAS Transformation Language) [7] llamado su- perimposició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 impues- tas por reglas de transformación de otro módulo. El resultado de la superim- posició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 origi- nal 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 trans- formación con variantes y que pueda ser utilizado sobre cualquier lenguaje de reglas de transformación.

(5)

3. Ejemplo Ilustrativo

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)

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 (Prob- lemSpaceMetamodel) representa el dominio de negocio y permite especificar la entidad que va a ser administrada. El metamodelo del núcleo (KernelMetamod- el) 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´on 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 transfor- mació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)

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 trans- formación createGridInformationView, cuya ejecución depende de la selección del variante Grid.

4. Estrategia Global de soluci´on

Nuestro modelo de decisión permite componer reglas de transformación a nivel externo e interno, especificando el conjunto y orden de reglas de transfor- mació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´on externa por el modelo de decisi´on.

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)

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´on interna por el modelo de decisi´on.

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 com- ponerse 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)

se encuentra seleccionado, entonces se deben componer las reglas de transfor- mació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 infor- mación de tipo Grid.

4.1. Metamodelo de Decisi´on

Hemos creado un metamodelo para guiar la creación de los modelos de de- cisió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´on.

Un Modelo de decisión se encuentra compuestos por varios modelos de trans- formación, los cuales representan las transformaciones entre modelos que deben realizarse en el proceso de derivación de un producto. Los modelos de transfor- mación pueden ser de dos tipos: transformación de modelo a modelo ó transfor- mació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)

Los conceptos descritos anteriormente son utilizados para representar los mecanismos de composición externa. En el ejemplo presentado en la Figu- ra 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ódu- lo 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 reem- plazan 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 trans- formació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ódu- lo principal TransformProblemSpace2gui con las reglas de transformación del módulo variable GridViewModule.

5. Modelo de Decisi´on sobre Lenguajes de transformaci´on espec´ıficos

5.1. Modelo de decisi´on en OAW

oAW (openArchitectureWare) [11] es un framework Java para construir apli- caciones utilizando el enfoque de desarrollo de software dirigido por modelos.

(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´on 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 transfor- mació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 transforma- ció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)

Figura 7. Metamodelo Workflow de OAW

5.2. Modelo de decisi´on en ATL

En ATL, el proceso de composici´on y derivaci´on 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´on 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)

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 trans- formació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)

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´on con nuestro modelo de decisi´on.

También trabajaremos en mecanismos de composición de reglas de transforma- ció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¨uck, R., Lowry, M.R., eds.: GPCE. Volume 3676 of Lecture Notes in Computer Science., Springer (2005) 422–437

3. Wagelaar, D.: Composition techniques for rule-based model transformation lan- guages. In: First International Conference on Theory and Practice of Model Trans- formations (ICMT). (2008)

4. Arboleda, H., Romero, A., Casallas, R., Royer, J.: Product derivation in a model- driven software product line using decision models. In: Proceedings of the 12th Iberoamerican Conference on Requirements Engineering and Software Environ- ments, 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) 128–138

8. 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) 111–119

9. Dhungana, D., Gr¨unbacher, 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 2007-01 of Lero Technical Report. (2007) 119–

127

10. 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) 289–309

11. OpenArchitectureWare: Openarchitectureware. http://www.

openarchitectureware.org (2009)

(15)

12. Apache: Ant. http://ant.apache.org/ (2009)

13. Allilaire, F., B´ezivin, 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) 1188–1195

16. Balogh, A., Varr´o, 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) 1280–1287