Automatic derivation of behavior of products in a software product line

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, agonzalez@dc.exa.unrc.edu.ar
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, szasz@ort.edu.uy
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