1120 IEEE LATIN AMERICA TRANSACTIONS, VOL. 12, NO. 6, SEPTEMBER 2014 Automatic Derivation of Behavior of Products in a Software Product Line A. González, C. Luna, F. Zorzan and N. Szasz Abstract— Models and model transformations constitute the basis of a set of software development techniques known as ModelDriven Development. In this context, UML State Machines have great potential for modeling the behavior of systems. In this work we are concerned with modeling the behavior of Product Lines, and their individual products. We present a process for deriving automatically a UML State Machine that models the behavior of a specific product from the UML model of a product line, via a model transformation based on Query/View/Transformation. The process directly involves the use of Feature Models in order to determine which elements of a (extended) State Machine describing a product family, will remain in the instantiation. Keywords— State Machines, Software Product Lines, QVT, Feature Models. E I. INTRODUCCIÓN L DESARROLLO dirigido por modelos (Model-Driven Development, MDD) [1], [2], [3] es una metodología de la ingeniería de software que idealmente eleva el desarrollo de software a un mayor nivel de abstracción, mediante la utilización de modelos y transformaciones de modelos durante todo el proceso de desarrollo. Los modelos proporcionan abstracciones de un sistema del mundo real y permiten el razonamiento acerca de ciertos aspectos de ese sistema, ignorando otros detalles no relevantes. A menudo, es necesario realizar transformaciones entre diferentes modelos de un sistema en un nivel de abstracción equivalente, por ejemplo, entre un modelo estructural y uno de comportamiento. En otros casos, una transformación convierte modelos de diferente nivel de abstracción; por lo general reduciendo el nivel de abstracción mediante la incorporación de detalles adicionales sobre un modelo base. Los lenguajes de modelado y las herramientas de transformación de modelos y de generación de código permiten disminuir la brecha existente entre el dominio de los problemas y el de las soluciones. Gran parte de las técnicas de MDD utilizan UML [4], lenguaje incorporado como estándar de facto a nivel académico e industrial, que permite la descripción de múltiples aspectos de un sistema. En particular, las Máquinas de Estados (StateCharts, SCs) [5] constituyen un mecanismo adecuado para definir el comportamiento de sistemas mediante una representación gráfica.1 A. Gonzalez, Universidad Nacional de Río Cuarto, Río Cuarto, Argentina, [email protected] F. Zorzan, Universidad Nacional de Río Cuarto, Río Cuarto, Argentina, fzorzan}@dc.exa.unrc.edu.ar C. Luna, Facultad de Ingeniería, Universidad de la República, Montevideo, Uruguay, cluna@fing.edu.uy N. Szasz, Universidad ORT Uruguay, Uruguay, [email protected] Una Línea de Productos de Software (Software Product Line - SPL) [6], [7], [8] representa un conjunto de sistemas (o productos) que comparten funcionalidades y satisfacen, en general, las necesidades de un segmento particular del mercado. Los diferentes productos de la línea se obtienen incorporando funcionalidades distintivas (variabilidad) a un conjunto de funcionalidades comunes a todos los productos de la línea, denominado núcleo. En nuestra investigación, aplicamos MDD a las SPLs con el objetivo de automatizar la obtención de un modelo UML, que representa el comportamiento de un producto determinado, a partir de un modelo de la SPL, que representa el comportamiento de una particular familia de productos. Si bien existen trabajos previos que aplican MDD a las SPLs, como por ejemplo [9], [10], [11], [12], [13], ninguno de éstos tiene por objetivo la derivación de especificaciones de comportamiento extendidas con variabilidades. El presente artículo es una continuación de los siguientes trabajos previamente publicados por los autores: [14], [15], [16], en los cuales se propone una extensión de las SCs para especificar SPLs y obtener productos concretos utilizando Modelos de Funcionalidades [17], [18]. En [14] se presenta la propuesta general y se desarrollan las primeras formalizaciones; en [15] se especifica el problema como un sistema basado en reglas, en el cual se prueban las propiedades de confluencia y terminación; y en [16] se propone una implementación parcial de dichas reglas mediante una transformación utilizando el lenguaje estándar Query/view/Transformation Relations (QVT-R) [19]. Este trabajo presenta la automatización completa del proceso de instanciación del comportamiento de productos específicos de una SPL, a partir de los resultados descriptos, previamente alcanzados. Una versión preliminar de este artículo es [20] y una versión extendida es la tesis [21], donde pueden consultarse en detalle todos los resultados producidos en esta investigación y reportados aquí. La organización del resto de este trabajo es como sigue. En la sección II se describen brevemente las SPL, las SCs y los Modelos de Funcionalidades. En la sección III se introducen las SCs con variabilidad en sus componentes esenciales, y la relación entre éstas y los Modelos de Funcionalidades, para especificar el comportamiento de una SPL. Asimismo, se detalla el proceso de transformación de una SC con variabilidad en una SC concreta que especifica el comportamiento de un producto particular de una SPL. En la sección IV se presenta un caso de estudio basado en tecnología de telefonía móvil. Finalmente, en la sección V se discuten los trabajos relacionados, las conclusiones y los trabajos futuros. GONZALEZ et al.: AUTOMATIZATION OF THE INSTANTIATION II. NOCIONES PRELIMINARES En esta sección se presentan brevemente los principales conceptos referentes a las áreas de base que dan soporte al trabajo. Estas son: las Líneas de Productos de Software, las Máquinas de Estados y los Modelos de Funcionalidades. Clements y Northrop definen las SPLs en [6] como: “un conjunto de sistemas de software (productos) que comparten un conjunto de características, las cuales satisfacen las necesidades específicas de un dominio o segmento particular de mercado, y que se desarrollan a partir de un sistema común (core) de una manera preestablecida”. Los productos de una misma SPL poseen un conjunto de características en común, pero cada producto difiere de otro en el conjunto de funcionalidades opcionales que implementa. Esta diferencia funcional entre productos de una SPL es conocida como la variabilidad en una SPL [7]. El manejo de la variabilidad juega un papel fundamental en una SPL y constituye un problema en sí mismo [22], [23]. Es necesario tener en cuenta desde el inicio del desarrollo posibles variaciones a ser incluidas en los productos finales. Además, requiere utilizar una notación adecuada para representarla y debe ser explícitamente manejada a través del proceso entero de desarrollo. El manejo de la variabilidad permite el reuso de componentes, y normalmente es representada a través de características (features). Una característica puede ser un requerimiento funcional específico, una combinación de ellos o incluso podría estar relacionada a requerimientos no funcionales. En el contexto de los sistemas reactivos, las distintas funcionalidades o características de un sistema introducen la visión de un conjunto de productos diferentes, según sea el conjunto de funcionalidades subyacentes. Un mecanismo para modelar este tipo de sistemas en una etapa prematura del desarrollo (diseño) es a través de las máquinas de estados. En [24] se pueden observar diferentes técnicas que dan soporte al manejo de la variabilidad y a la derivación de productos. El presente trabajo hace uso del concepto de variabilidad negativa, es decir, a partir de una especificación completa de la familia de productos, se eliminarán componentes de la especificación que corresponden a una funcionalidad no deseada en el producto final. Una SC es una representación visual de un autómata de estados finito con jerarquía de estados e historia. Estas máquinas fueron introducidas por Harel [5] e incorporadas a las diferentes versiones de UML con algunas variaciones. La principal característica de las SCs es que sus estados pueden refinarse, definiendo así una jerarquía de estados. La descomposición de un estado puede ser secuencial o paralela. En la primera, un estado se descompone en un autómata, mientras que en la segunda se descompone en dos o más autómatas que se ejecutan concurrentemente. Las transiciones son dirigidas. Una transición (t) está formada por su nombre, el estado origen, el evento que la “dispara” (e), la condición de disparo (c), la secuencia de acciones (α), el estado destino y el tipo de historia del estado destino, respectivamente. La notaciσn grαfica utilizada es t: e, c / α. Los Modelos de Funcionalidades o Características (Feature Models, FMs) se utilizan fundamentalmente para describir las 1121 propiedades o funcionalidades (features) obligatorias, opcionales, alternativas y disyuntivas dentro de un dominio [17], [25]. Los FMs permiten identificar las funcionalidades comunes y las variantes entre los productos de una SPL, y establecer relaciones entre las mismas. Aunque hay múltiples notaciones para describir un FM nos basamos en la propuesta por Czarnecki en [17]. La Fig. 1 describe un posible FM en el dominio de la tecnología de teléfonos móviles (TMs) usando la notación de Czarnecki. Por ejemplo, todos los TMs deben tener un directorio telefónico (relación obligatoria); un TM puede tener cámara digital o no (relación opcional); un TM puede tener búsqueda en el directorio telefónico por búsqueda directa, por strings o ambas (relación disyuntiva); si un TM dispone de cámara fotográfica, esta deberá ser de 10 o 12mpx, pero no ambas resoluciones (relación alternativa). Figura 1. FM de un Teléfono Móvil. Em [15] un FM es definido formalmente como una estructura de árbol representada como una tupla: (Funcs, f0, Obli, Opc, Alt, rel-Or). También se define una configuración (instanciación) de un FM conffm = (F, R), con F ⊂ Funcs y R el conjunto de las aristas, como un subárbol que caracteriza las funcionalidades de un producto específico. Las funcionalidades obligatorias (funcionalidades comunes a la familia de productos) deben pertenecer a cualquier configuración. III. PROCESO DE TRANSFORMACIÓN El proceso de transformación se divide en tres partes: (1) la definición de la variabilidad de una SPL; (2) la definición formal de un método para la generación de productos; y (3) la implementación del mecanismo anterior. La definición de la variabilidad se basa en una extensión de máquinas de estados que admiten componentes opcionales (máquinas de estados con variabilidad), de tal manera que, junto a los FMs, definen la familia de productos de una línea. Posteriormente, y 1122 utilizando las definiciones anteriores, se presenta un mecanismo para la obtención de productos basado en reglas y un algoritmo de aplicación de las mismas. Por último, se implementa con QVT-R el mecanismo anterior como un proceso de transformación de modelos, desde máquinas de estados con variabilidad a máquinas de estados concretas. La fig. 2 representa gráficamente el proceso. Figura 2. Proceso de Transformación. A. Variabilidad en las SPLs Existen extensiones de algunos modelos de UML para la especificación de variabilidades, por ejemplo [26], [27], [28], [29], [22]. En este trabajo utilizamos nuestra propuesta de [15], la cual está basada en la aplicación de un conjunto de reglas que especifican la semántica al eliminar los elementos opcionales de una SC. En dicho trabajo las SCs son extendidas con elementos opcionales o variantes, y luego se establece la relación que vincula a estos elementos con las funcionalidades de un FM. Llamaremos StateCharts* (SCs*) a las SCs extendidas. Los estados y las transiciones opcionales son destacados gráficamente con líneas de puntos. La vinculación entre un FM y una SC se realiza a través de una función (Imp) que representa la asociación entre los elementos variables de una SC* con las funcionalidades de un FM. Dado un FM (Funcs, Obl, Opc, Alt, Disy) y una SC*, la función Imp tiene tipo Imp : Funcs → Set(ElemVar), donde ElemVar es el conjunto de todos los elementos opcionales de la SC*. Imp(F) retorna el conjunto de elementos opcionales que implementan el comportamiento de la funcionalidad F. IEEE LATIN AMERICA TRANSACTIONS, VOL. 12, NO. 6, SEPTEMBER 2014 toma como parámetro un modelo de una SC* con los elementos que deben eliminarse, marcados previamente sin la utilización de procesos automáticos. Este método se torna impráctico cuando se trata con modelos complejos. Además, la introducción de un cambio en el conjunto de funcionalidades deseadas para un producto determinado (una nueva instancia del FM correspondiente), implica una actualización manual del modelo SC* fuente de la transformación, lo cual incrementa las posibilidades de introducir errores en la marcación. En [20] se propone una optimización con respecto a [16]. La transformación considera, además de una SC*, el conjunto de funcionalidades que deben permanecer en la SC concreta. La automatización de este paso brinda practicidad al mecanismo y reduce los errores que, en particular, pueden surgir al tener que efectuar manualmente la marcación de los elementos que deben eliminarse. En [20], la implementación en QVT-R considera, por un lado, un parámetro adicional a la transformación (Param_funcionalidades) que representa a una instancia de un FM, y por otro lado, un mecanismo para determinar la asociación entre las funcionalidades y los elementos de una SC*. Para esto último, se extendió el metamodelo de las SCs* con un atributo adicional a los estados y transiciones (features) que admita la especificación de un conjunto de nombres de funcionalidades. Se debe tener en cuenta que un estado o transición opcional puede implementar a más de una funcionalidad. Este mecanismo implementa la función Imp. Dada una SC* y un conjunto de funcionalidades (instancia de un FM), la implementación retorna una SC concreta, tal como se muestra en la Fig. 3. Se transforman, por un lado, los elementos sintácticos no opcionales (obligatorios), y por otro lado, los elementos opcionales que tengan al menos una funcionalidad asociada que pertenezca a Param_funcionalidades. B. Generación de productos Dada una SC*, una instancia de un FM permite determinar cuáles elementos opcionales deben permanecer y cuáles deberán ser eliminados para obtener el modelo del producto específico. En [15] se definen, por un lado, reglas que especifican la semántica de la eliminación de cada uno de los posibles casos, y por otro, una estrategia de aplicación de dichas reglas. El método de obtención de productos se presenta como un sistema de reescritura basado en reglas, el cual especifica cómo se instancian los prodcutos de una SPL a partir de un algoritmo que refleja la estrategia de aplicación de las reglas C. Implementación En [16] se propone una implementación parcial de dichas reglas utilizando el lenguaje QVT-R. Allí, la transformación Figura 3. Implementación de la Transformación. La instancia de un FM (Param_funcionalidades) es introducida dentro del modelo origen tal como se puede ver en la Fig. 5 de la sección [Caso de Estudio]. El metamodelo es extendido con una nueva EClass denominada Param_funcionalidades. El atributo features de los estados y las transiciones es implementado con una EReference sobre GONZALEZ et al.: AUTOMATIZATION OF THE INSTANTIATION 1123 las EClass Vertex y Transition de tal manera que las funcionalidades sean referenciadas desde features. IV. CASO DE ESTUDIO En esta sección mostramos un fragmento de un caso de estudio basado en tecnología de telefonía móvil. El ejemplo completo puede verse en [21]. Los archivos necesarios para ejecutar la transformación están disponibles en https://www.dropbox.com/sh/h8kj76snr4x3l26/TvH9UvLq2h. Considérese la SC* de la Fig. 4. Las funcionalidades involucradas en este ejemplo parcial de un teléfono móvil (TM) son las relacionadas al envío de mensajes de texto. Los mismos pueden clasificarse en mensajes de sólo texto, mensajes de voz y mensajes con contenido multimedia. A su vez, estos últimos pueden contener una imagen y/o un video y/o un sonido de tipo polifónico. Las relaciones entre estas funcionalidades se muestran en el FM de la Fig. 1. El atributo features de los estados y las transiciones opcionales debe ser configurado de acuerdo a la función Imp, como se muestra también en la Fig. 4 mediante etiquetas con los nombres de las funcionalidades involucradas. Por ejemplo, la funcionalidad se asocia tanto al estado SeleccSonPol como a la transición que va desde TipoMultimedia a SeleccSonPol. Figura 5. Modelo origen de la transformación en formato Ecore de un Teléfono Móvil. A. Ejemplo 1: Un TM sin sonido polifónico El FM de la Fig. 1 puede configurarse para caracterizar a un TM sin sonidos polifónicos, es decir, conffm = ({Adm. Mensajes, Multimedia, Imágenes, Videos}, R). Por simplicidad, sólo notamos las funcionalidades involucradas en la SC* del ejemplo. La transformación recibe como parámetros la SC* de la Fig. 4 y el conjunto Param_funcionalidades = {Adm. Mensajes, Multimedia, Imágenes, Videos}. Los únicos elementos opcionales de la SC* que no tienen al menos una funcionalidad asociada que pertenezca a Param_funcionalidades son el estado SeleccSonPol y la transición TDerTipoMultimedia-SeleccSonPol, por lo que no son transformados al modelo SC resultante. Las transiciones opcionales de entrada y salida al estado SeleccSonPol también desaparecen. El modelo resultante se muestra en la Fig. 6. Figura 4. SC* parcial de un Teléfono Móvil. En la Fig. 5 se muestra la SC* del ejemplo en formato Ecore, con la funcionalidad Adm. Mensajes asociada al estado opcional Mensaje Nuevo. B. Ejemplo 2: Un TM sin mensajes Multimediales El FM de la Fig. 1 puede configurarse también para caracterizar a un TM sin la posibilidad de enviar mensajes con contenido multimedial, donde sólo se pueden enviar mensajes de texto, es decir, conffm = ({Adm. Mensajes}, R). El único elemento opcional de la SC* que tiene al menos una funcionalidad que pertenece al conjunto de funciones que deben permanecer Param_funcionalidades = {Adm. Mensajes} es el estado Mensaje Nuevo. Este último estado y los demás elementos no opcionales son transformados por las relaciones definidas en QVT-R. En particular, la eliminación del estado opcional Multimedia produce la composición de las transiciones no opcionales TDerMensTexto- Multimedia y 1124 IEEE LATIN AMERICA TRANSACTIONS, VOL. 12, NO. 6, SEPTEMBER 2014 TIzqMultimedia-SeleccContacto en correspondencia con las reglas definidas en [15]. El modelo resultante se presenta en la Fig. 7. Figura 6. SC de un Teléfono Móvil sin sonidos polifónicos. la obtención de productos concretos empleando un desarrollo dirigido por modelos (MDD). Un enfoque alternativo puede observarse en [28] y [36]. Los autores, en un marco formal, definen funciones que asocian SCs (en lugar de estados y transiciones de SCs, como en nuestro caso) a funcionalidades de un FM y analizan formas de combinación entre distintos SCs que especifican posibles variantes de una SPL. El enfoque se orienta a un proceso de combinación de SCs para obtener la especificación del comportamiento de un producto de la línea. Sin embargo, se torna complejo el diseño cuando el comportamiento de una funcionalidad se manifiesta en distintas partes de una SC a través de los estados, transiciones y posiblemente otros elementos del modelo, como sería el manejo de multimedia de nuestro ejemplo. Otro trabajo relacionado es [37], donde se propone una transformación de modelos para derivar automáticamente un modelo UML de un producto concreto, a partir de un modelo UML de una SPL. Utilizan el perfil Modeling and Analysis of Real-Time and Embedded Systems (MARTE) sobre los elementos del Modelo UML para indicar las funcionalidades que implementan, es decir, el mapeo está explícito en los modelos UML fuentes. Para la obtención de un producto concreto definen una transformación de modelos que es implementada en el lenguaje ATL (Atlas Transformation Language). La propuesta se enfoca básicamente sobre modelos UML estáticos, como los diagramas de Casos de Uso y el Modelo de Dominio, y de comportamiento, como los Diagramas de Secuencia, pero no presenta ningún tratamiento sobre la variabilidad en las SCs. Además, restringe la asociación de un elemento con una sola funcionalidad del FM. B. Conclusiones y Trabajos Futuros Figura 7. SC de un Teléfono Móvil sin contenido Multimedia. V. DISCUSIÓN A. Trabajos Relacionados Existen múltiples trabajos que proponen la incorporación de variabilidades en sistemas de software y en particular en las SPLs. En [30], [31], [32] los autores proponen utilizar mecanismos de combinación de paquetes (“package merge”) de UML 2 basados inicialmente en [33], como herramienta de representación y configuración de la variabilidad de una SPL y reservar los mecanismos clásicos de modelado para expresar las variantes válidas en tiempo de ejecución de cada aplicación concreta. En cuanto a los modelos estructurales, o bien se utilizan directamente los mecanismos de UML como en el caso mencionado de Jacobson, o bien se anotan de forma explícita mediante estereotipos. Los trabajos [27] y [34] son ejemplos de este último enfoque. En [35] las extensiones propuestas para las SPLs son definidas sobre UML 2.0 y sólo conciernen a los diagramas de clases y de secuencias. Sin embargo, ninguno de los trabajos referidos presenta un mecanismo para La derivación de productos es una parte esencial del proceso de desarrollo de una SPL. Este artículo propone un proceso integral para derivar automáticamente una máquina de estados que representa el comportamiento de un producto específico desde una máquina de estados extendida, que representa una SPL. La propuesta permite reducir el tiempo de desarrollo de un producto, automatizando la derivación de la especificación del comportamiento de un producto, a través de una transformación de modelos en el lenguaje QVT-R. El proceso presentado en este artículo —que sintetiza y conjuga resultados de investigación de los autores de varios años constituye un avance significativo hacia el objetivo de automatizar completamente el proceso de desarrollo de una SPL para sistemas dinámicos. En particular, a partir de este trabajo se cuenta con una automatización del proceso de instanciación del comportamiento de productos específicos de una línea; un resultado que, para nuestro conocimiento, no se había alcanzado, con otras propuestas, de manera integral sobre modelos de comportamiento extendidos con variabilidades. La aplicación de la propuesta a un caso de estudio relevante muestra la factibilidad de la propuesta para abordar sistemas complejos. Como trabajo futuro se prevé la creación de una herramienta que automatice todo el proceso de desarrollo y GONZALEZ et al.: AUTOMATIZATION OF THE INSTANTIATION permita la incorporación en las relaciones QVT de todos los elementos de UML 2 involucrados en las transiciones y los estados. REFERENCIAS [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] S. J. Mellor, A. N. Clark, and T. Futagami, “Guest editors’ introduction: Model-driven development,” IEEE Software, vol. 20, no. 5, pp. 14–18, 2003. B. Selic, “The pragmatics of model-driven development,” IEEE Softw.,vol. 20, no. 5, pp. 19–25, 2003. T. Stahl, M. Voelter, and K. Czarnecki, Model-Driven Software Development: Technology, Engineering, Management. John Wiley & Sons,2006. OMG, OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.4.1, Object Management Group Std., Rev. 2.4.1, 2011. [Online]. Available: http://www.omg.org/spec/UML/2.4.1 D. Harel, “Statecharts: A visual formalism for complex systems,” Sci. Comput. Program., vol. 8, no. 3, pp. 231–274, 1987. P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, ser. SEI Series in Software Engineering. Addison-Wesley, 2001. K. Pohl, G. Böckle, and F. J. v. d. Linden, Software Product Line Engineering: Foundations, Principles and Techniques. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2005. W. B. Frakes and K. Kang, “Software reuse research: Status and future,” IEEE Trans. Softw. Eng., vol. 31, no. 7, pp. 529–536, 2005. K. Czarnecki, M. Antkiewicz, C. H. P. Kim, S. Lau, and K. Pietroszek, “Model-driven software product lines,” in Companion to the 20th Annual ACM SIGPLAN Conference on Object-oriented Programming, Systems, Languages, and Applications, ser. OOPSLA ’05. New York, NY, USA: ACM, 2005, pp. 126–127. G. Botterweck, K. Lee, and S. Thiel, “Automating product derivation in software product line engineering,” in Software Engineering, ser. LNI, P. Liggesmeyer, G. Engels, J. Münch, J. Dörr, and N. Riegel, Eds., vol. 143. GI, 2009, pp. 177–182. I. Schaefer, E. Worret, A. Poetzsch-heffter, and T. Kaiserslautern, “A model-based framework for automated product derivation,” in Modeldriven Approaches in Software Product Line Engineering, 2009. K. Schmid, R. Rabiser, and P. Grúnbacher, “A comparison of decision modeling approaches in product lines,” in Proceedings of the 5th Workshop on Variability Modeling of Software-Intensive Systems, ser. VaMoS ’11. New York, NY, USA: ACM, 2011, pp. 119–126. P. Fernandes, C. Werner, and E. Teixeira, “An approach for feature modeling of context-aware software product line,” Journal of Universal Computer Science, vol. 17, no. 5, pp. 807–829, 2011. A. Gonzalez and C. Luna, “Behavior specification of product lines via feature models and uml statecharts with variabilities,” in SCCC, 2008, pp. 32–41. ——, “Specification of products and product lines,” in WRS, ser. EPTCS, M. Fernández, Ed., vol. 15, 2009, pp. 44–55. A. Gonzalez, C. Luna, and F. Zorzan, “Transformación de máquinas de estados con variabilidad usando el lenguaje qvt,” in Proceedings of Conferencia Latinoamericana en Informática (CLEI’11), 2011, pp. 479– 494. K. Czarnecki and U. W. Eisenecker, Generative programming methods, tools and applications. Addison-Wesley, 2000. D. Benavides, S. Segura, and A. Ruiz-Cortés, “Automated analysis of feature models 20 years later: A literature review,” Inf. Syst., vol. 35, no. 6, pp. 615–636, 2010. OMG, Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification, Version 1.1, Object Management Group Std., Rev. 1.1, 2011. [Online]. Available: http://www.omg.org/spec/QVT/1.1/ A. Gonzalez, C. Luna, N. Szasz, and F. Zorzan, “Automatización del proceso de instanciación del comportamiento de productos de una línea de productos de software,” in Proceedings of 16th Ibero-American Conference on Software Engineering (CIbSE’13), 2013, pp. 103–116. A. Gonzalez, “Especificación del comportamiento de líneas de productos mediante modelos de funcionalidades y máquinas de estados con variabilidades",” Master’s thesis, PEDECIBA Informática, Uruguay, Tech. Rep., 2012. [Online]. Available: https://www.dropbox. com/s/229wrnrimybfr0b/tesisAGonzalez-Final.pdf 1125 [22] J. Bosch, “Software variability management,” in Proceedings of the 26th International Conference on Software Engineering, ser. ICSE ’04. Washington, DC, USA: IEEE Computer Society, 2004, pp. 720–721. [23] L. Chen and M. A. Babar, “Variability management in software product lines: An investigation of contemporary industrial challenges.” in SPLC, ser. Lecture Notes in Computer Science, J. Bosch and J. Lee, Eds., vol. 6287. Springer, 2010, pp. 166–180. [24] I. Groher and M. Voelter, Aspect-Oriented Model-Driven Software Product Line Engineering. Springer Berlin / Heidelberg, 2009, vol. 5560, pp. 111–152. [25] F. Heidenreich, P. Sánchez, J. a. Santos, S. Zschaler, M. Alférez, J. a. Araújo, L. Fuentes, U. Kulesza, A. Moreira, and A. Rashid, “Transactions on aspect-oriented software development vii,” S. Katz and M. Mezini, Eds. Berlin, Heidelberg: Springer-Verlag, 2010, ch. Relating Feature Models to Other Models of a Software Product Line: A Comparative Study of Featuremapper and VML, pp. 69–114. [26] M. V. Cengarle, P. Graubmann, and S. Wagner, “Semantics of uml 2.0 interactions with variabilities,” Electr. Notes Theor. Comput. Sci., vol. 160, pp. 141–155, 2006. [27] H. Gomaa, “Designing software product lines with uml 2.0: From use cases to pattern-based software architectures,” in ICSR, 2006, p. 440. [28] N. Szasz and P. Vilanova, “Statecharts and variabilities,” in VaMoS, 2008, pp. 131–140. [29] L. Chen, M. Ali Babar, and N. Ali, “Variability management in software product lines: A systematic review,” in Proceedings of the 13th International Software Product Line Conference, ser. SPLC ’09. Pittsburgh, PA, USA: Carnegie Mellon University, 2009, pp. 81–90. [30] M. A. Laguna, B. González-Baixauli, and O. López, “Gestión de la variabilidad en líneas de productos,” in Proceedings of Conferencia Latinoamericana de Informática (CLEI’07), 2007. [31] M. A. Laguna and B. González-Baixauli, “Variabilidad, trazabilidad y líneas de productos: una propuesta basada en uml y clases parciales,” in JISBD, 2007, pp. 157–166. [32] ——, “Product line requirements: Multi-paradigm variability models,” in WER, 2008. [33] A. Zito, Z. Diskin, and J. Dingel, “Package merge in uml 2: Practice vs. theory?” in MoDELS, 2006, pp. 185–199. [34] M. Clauss, “Generic Modeling using UML extensions for variability,” in Proceedings of OOPSLA Workshop on Domain-specific Visual Languages, Tampa, FL, USA, 2001, pp. 11–18. [35] T. Ziadi, L. Hélouét, and J.-M. Jézéquel, “Behaviors generation from product lines requirements,” in Proc. UML2004 workshop on Software Architecture Description, Lisbon, Portugal, 2004. [36] P. Vilanova, “On uml statecharts with variabilities,” Master’s thesis, PEDECIBA Informática, Uruguay, Tech. Rep., 2011. [37] R. Tawhid and D. C. Petriu, “Product model derivation by model transformation in software product lines,” 2012 IEEE 15th International Symposium on Object/Component/Service-Oriented RealTime Distributed Computing Workshops, vol. 0, pp. 72–79, 2011. Ariel Gonzalez recibió el título de Magíster en Informática del PEDECIBA Informática (Uruguay) y actualmente está comenzando su doctorado en Informática en dicho programa. Es profesor e investigador de la Universidad Nacional de Río Cuarto, Argentina. Sus principales áreas de interés son: Transformación de Modelos, Líneas de Productos y Sistemas de Simulación. Actualmente es representante de las universidades de Argentina miembros del Centro Latinoamericano de Estudios en Informática (CLEI). Carlos Luna es Magíster en Informática del PEDECIBA Informática (Uruguay) y actualmente está culminando su doctorado en Informática en dicho programa. Es profesor Adjunto del Instituto de Computación de la Facultad de Ingeniería de la Universidad de la República (Uruguay). Desde hace 5 años se desempeña como investigador de la Agencia Nacional de Investigación e Innovación de Uruguay, en métodos formales aplicados a ingeniería de software y seguridad de sistemas. 1126 Fabio Zorzan es Magíster en Informática del PEDECIBA Informática (Uruguay) y actualmente está comenzando su doctorado en Informática en dicho programa. Es profesor e investigador de la Universidad Nacional de Río Cuarto, Argentina. Ha recibido una beca especial de la agencia Córdoba Ciencia, y como estudiante de grado recibió una beca de ayudantía de investigación. Sus principales áreas de interés son: Transformación de Modelos, Bases de Datos y Microprocesadores. Nora Szasz es Ph.D. en Ciencias de la Computación de la Universidad Tecnológica de Chalmers, Suecia. Actualmente es Coordinadora Académica de Ingeniería en Sistemas de la Universidad ORT Uruguay e Investigadora del área Informática del PEDECIBA y del Sistema Nacional de Investigadores de Uruguay. Sus principales áreas de interés son los métodos formales, los fundamentos de la computación y los lenguajes de programación. IEEE LATIN AMERICA TRANSACTIONS, VOL. 12, NO. 6, SEPTEMBER 2014