See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/26522746

Administración de Variabilidad en una Línea de Producto de Software basada en

Modelos.

Article · January 2007

Source: DOAJ

CITATIONS READS
6 6,691

5 authors, including:

Kelly Garcés Carlos Parra

39 PUBLICATIONS   389 CITATIONS   
National Institute for Research in Computer Science and Control
21 PUBLICATIONS   363 CITATIONS   
SEE PROFILE
SEE PROFILE

Hugo Arboleda Andrés Yie

ICESI University Los Andes University (Colombia)
68 PUBLICATIONS   264 CITATIONS    10 PUBLICATIONS   106 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Change management project in Business - IT View project

cloud architectures View project

All content following this page was uploaded by Andrés Yie on 29 May 2014.

The user has requested enhancement of the downloaded file.

 Administración de Variabilidad en una línea de producto
basada en modelos
Kelly Garcés Carlos Parra Hugo Arboleda
Universidad de los Universidad de los Universidad de los
Andes, Bogotá Andes, Bogotá Andes, Bogotá
k-garces c-parra1 hf.arboleda34
@uniandes.edu.co @uniandes.edu.co @uniandes.edu.co
RESUMEN
La administración de variabilidad en una línea de producto tiene
dos retos fundamentales: (1) la expresión de las características
comunes y variables de la línea, y (2) la construcción de
aplicaciones que incluyan las características comunes, y un
subconjunto de las características variables. En este artículo
presentamos una propuesta para administrar la variabilidad
durante el proceso de construcción de SPLs usando un enfoque de
construcción de líneas de producto basado en modelos (MD-
SPL). Para esto separamos conceptos relacionados con SPLs en
diferentes dominios y construimos como activos de la línea
modelos de rasgos, metamodelos y tres tipos de reglas de
transformación para transformar modelos de un dominio origen a
diferentes (variables) modelos en un dominio destino. Las reglas
nos permiten generar incrementalmente las aplicaciones de
acuerdo con una selección de rasgos realizada para cada dominio
destino. Así, logramos ampliar el alcance de las SPLs, separar los
dominios de manera que se disminuya la complejidad de crear
aplicaciones con características variables, y generar aplicaciones
automáticamente usando reglas de transformación. Para ilustrar la
solución construimos una MD-SPL donde los productos
corresponden a ejercicios pedagógicos para la enseñanza de
programación de computadores.
Categories and Subject Descriptors
D.2.13 [Reusable Software]. Reuse models. I.6.5 [Model
Development].
General Terms
Design, Languages.
Keywords
Model Driven Architecture, Variability, Software Product Lines,
and Model Transformation.
1. INTRODUCCION
El rápido avance tecnológico y el cambio constante en los
requerimientos del negocio hacen del desarrollo de software una
tarea compleja. Encarar esta realidad ha sido motivación de
múltiples propuestas que buscan aumentar tanto la calidad del
software, como la productividad de los equipos de desarrollo. El
principio de dichas propuestas es la reutilización del software a
partir de enfoques composicionales y/o generativos [24]. Los
enfoques composicionales pretenden la construcción sistemas a
partir de la relación de componentes que se encuentran en un
Andres Yie Rubby Casallas
Universidad de los Universidad de los
Andes, Bogotá Andes, Bogotá
a-yie rcasalla
@uniandes.edu.co @uniandes.edu.co
depósito común. Los enfoques generativos intentan la
construcción de sistemas a partir de la reutilización de procesos y
de componentes de generación.
Lograr construir aplicaciones reutilizando componentes requiere
un enfoque de desarrollo de familias de productos para un
dominio específico, en lugar de un enfoque de construcción de
aplicaciones independientes [12]. Una familia de productos de
software (SPL) se define como “un conjunto de sistemas de
software que satisfacen necesidades específicas de un segmento
del mercado” [26]. En un enfoque de desarrollo de SPLs, nuevos
productos de la línea son creados reutilizando un conjunto de
componentes llamados activos. El principal activo es la
arquitectura de los productos, y otros activos adicionales pueden
ser especificaciones de requerimientos, modelos de diseño, o
componentes de software, entre otros. La creación de activos se
realiza en el proceso de ingeniería de dominio. La creación de
aplicaciones reutilizando los activos se lleva a cabo durante el
proceso de ingeniería de aplicación [10, 22].
Aún cuando los productos de una línea satisfacen necesidades
específicas de un dominio determinado, ellos difieren entre si en
el conjunto de funcionalidades implementadas en cada uno. Así,
todos los productos de una SPL proveen un conjunto de
funcionalidades comunes, pero cada producto difiere de los demás
en el conjunto de funcionalidades opcionales (variables) que
implementa. A la diferencia funcional entre productos de una
línea se le conoce como la variabilidad de una SPL [22].
La administración de variabilidad en una SPL puede ser definida
como el conjunto de actividades y artefactos necesarios para: (1)
expresar las características comunes y variables de una SPL, y (2)
construir (componer y/o generar) aplicaciones que incluyan las
características comunes, y un subconjunto de las posibles
características variables. En una SPL, las características de los
productos se relacionan directamente con la funcionalidad que
éstos proveen.
Actualmente, los modelos de rasgos son un estándar de facto
usado como mecanismo para apoyar la administración de la
variabilidad. Los modelos de rasgos son artefactos para expresar
las características comunes y variables de una familia de
productos. En los modelos de rasgos la variabilidad se modela
como rasgos de los productos que pueden ser seleccionados de
manera particular para cada producto [18]. Así, a partir de la
selección de un conjunto de rasgos, usando los activos necesarios,
se construyen aplicaciones que incluyen las características
comunes, y un subconjunto de las posibles características
variables.
Por otro lado, un enfoque de reutilización generativa es la
arquitectura basada en modelos (MDA) [19]. MDA utiliza los
modelos como elementos de primera clase en el desarrollo de
aplicaciones, a diferencia de otros paradigmas que los utilizan
únicamente como elementos de representación, documentación y
comunicación.
La idea central de MDA es construir modelos del dominio del
problema, independientes de las características inherentes a las
plataformas tecnológicas que se puedan utilizar para implementar
aplicaciones. Un modelo del dominio del problema se transforma
de forma automática en un nuevo modelo que incluye
características de una plataforma tecnológica específica haciendo
uso de reglas de transformación que permiten la generación de
estos nuevos modelos.
Los modelos son creados usando los conceptos definidos en un
metamodelo. Un metamodelo se crea con base en los conceptos de
un dominio, sus relaciones y semántica. Por esta razón los
metamodelos son llamados también modelos de dominio [15]. La
relación entre un modelo y su metamodelo se define como una
relación de conformidad. Así, se dice que un modelo es conforme
a su metamodelo [9].
Las reglas de transformación son definidas a nivel de los
conceptos del metamodelo. Una regla de transformación típica
toma los elementos de un modelo origen, conformes a un
concepto del metamodelo origen, y los transforma en elementos
de un modelo destino, conformes a conceptos del metamodelo
destino [21].
El propósito principal de MDA no es la creación de familias de
productos. Sin embargo, la separación de dominios y la naturaleza
generativa, hacen de MDA un enfoque de gran utilidad para la
creación de SPLs. Esto se logra partiendo de un modelo inicial, y
utilizando varios mecanismos de transformación automáticos para
obtener las diferentes aplicaciones miembros de una familia de
productos.
Resultados de recientes investigaciones muestran cómo el uso de
MDA y SPLs (MD-SPL) resulta en un enfoque mixto
(composicional y generativo) que permite definir procesos de
creación de SPLs [15, 25]. Sin embargo, la administración de
variabilidad en un enfoque MD-SPL es un área actual de
investigación.
En este artículo presentamos una propuesta para administrar la
variabilidad durante el proceso de construcción de SPLs usando
un enfoque MD-SPL. Para esto, nosotros separamos conceptos
relacionados con una línea de productos en diferentes dominios.
Estos dominios son el dominio de la lógica del negocio, el
dominio de arquitectura, y el dominio de la plataforma
tecnológica. Esta separación nos permite administrar la
variabilidad de las líneas de producto de manera separada para
cada dominio.
Con el objetivo de expresar las características comunes y variables
de las SPLs creamos modelos de rasgos para cada dominio. Para
construir aplicaciones definimos metamodelos para cada uno de
los dominios presentados. Estos metamodelos son utilizados para
construir un amplio conjunto de modelos variables en cada
dominio, y de esta forma podemos expresar la variabilidad de un
dominio específico.
Siguiendo el enfoque MDA, además de los metamodelos, creamos
reglas de transformación. Las reglas de transformación típicas son
creadas a nivel de los metamodelos, lo que implica que en una
transformación aplicada al mismo modelo de origen se obtiene un
único modelo destino asociado, sin embargo para crear
aplicaciones con características variables es necesario que un
mismo modelo pueda ser transformado en modelos destino
diferentes según las características variables seleccionadas.
Para guiar la generación de modelos variables, definimos tres
tipos de reglas de transformación: (1) reglas base, (2) reglas de
control, y (3) reglas específicas. Utilizamos las reglas base para
generar las características comunes de las SPLs. Las reglas de
control se encargan de escoger qué reglas específicas se deben
ejecutar según las características esperadas en el modelo destino
de la transformación. Las reglas específicas las usamos para
generar las diferentes características variables. Por medio de las
reglas específicas generamos aplicaciones de una misma familia
con funcionalidad diferente según la selección de rasgos sobre el
modelo destino realizada por el usuario en el proceso de creación
de aplicaciones (ingeniería de aplicación) de la SPL. De esta
forma, utilizando metamodelos, reglas de transformación, y
modelos de rasgos, logramos ampliar el alcance de una SPL, y
separar los dominios de manera que se disminuya la complejidad
de crear aplicaciones con características variables en cada
dominio. Sin embargo, las aplicaciones que generamos no son del
todo completas. Ya que algunos requerimientos funcionales no se
generan como parte de los procesos automáticos de
transformación, nosotros complementamos las aplicaciones
manualmente como parte del proceso de ingeniería de aplicación.
Ilustramos esta propuesta con una SPL para el proyecto Cupi2
[11]. Para el proceso de construcción nosotros utilizamos GMF
[6] como ambiente de modelado, AMW [2] como herramienta
para hacer entrelazado de modelos, y ATL [3] como lenguaje de
transformación de modelos.
El artículo está organizado de la siguiente manera. La sección 2
presenta el contexto de aplicación que nos permitirá ilustrar la
propuesta sobre un ejemplo concreto. La sección 3 y 4 presenta el
problema de administrar variabilidad en una MD-SPL y la
solución propuesta para resolverlo, ilustrados con una línea de
producto. En la sección 5 explicamos brevemente la
implementación realizada. La sección 6 presenta una comparación
de nuestro trabajo con algunos trabajos relacionados y por último
presentamos las conclusiones y esbozamos los trabajos futuros.
2. CONTEXTO DE APLICACIÓN
Como escenario de ilustración creamos una SPL para el proyecto
Cupi2 [11]. Este es un proyecto del grupo de construcción de
software de la Universidad de los Andes, que propone una nueva
forma de enseñar la programación de computadores.
La estrategia seguida para la enseñanza de programación se basa
en que los estudiantes utilicen ejemplos y ejercicios de
aplicaciones completas, en lugar de solo construir secciones de
código. Una aplicación completa incluye la descripción del
problema, los requerimientos funcionales, los requerimientos de
interfaz usuario, el diseño, las pruebas unitarias, y el código que
implementa la solución. Las aplicaciones utilizadas como ejemplo
para los ejercicios de aprendizaje están clasificadas por niveles.
Para cada nivel se selecciona los conceptos que se quiere enseñar.
Estos conceptos están alineados con uno o varios ejes temáticos.
Por ejemplo, el nivel 7 incluye, entre otras temáticas, la enseñanza
de algoritmos para manejo de colecciones como búsquedas y
ordenamientos. Así, el objetivo de una aplicación de nivel 7 es
facilitar el aprendizaje de manejo de este tipo de estructuras de
datos. Una característica importante es que el código utilizado
para resolver un problema de un nivel sólo incluye las temáticas
de los niveles anteriores y las propias del mismo nivel.
El proyecto Cupi2 necesita la construcción semestral de varias
aplicaciones ejemplo por cada nivel. Dado que en total son 18
niveles, la complejidad de la tarea es bastante alta y, además,
durante la construcción manual de los programas, es posible
inyectar defectos que se reflejan en el código fuente que manipula
el estudiante, lo cual puede causar inconvenientes en el proyecto,
dado que se debe garantizar la más alta calidad en estas
aplicaciones.
2.1 Identificación de características comunes
de los ejemplos Cupi2
El proyecto Cupi2 abarca diferentes temáticas de cursos de
programación. Las temáticas están organizadas en niveles, y cada
nivel tiene asociados ejemplos y ejercicios para facilitar la
enseñanza/aprendizaje de dichas temáticas. En adelante
trabajaremos sobre los ejemplos de Cupi2.
Todos los ejemplos tienen en común que son aplicaciones
monousuario sin requerimientos no funcionales complejos. Todos
los ejemplos son desarrollados usando la misma plataforma
tecnológica, en este caso Java. Todos los ejemplos se estructuran
por tres componentes: el mundo, la interfaz de usuario, y las
pruebas. El componente del mundo implementa los conceptos de
la lógica del negocio, sus atributos y relaciones. El componente de
la interfaz de usuario implementa la visualización de la
información y la interacción entre el usuario y el componente del
mundo. El componente de las pruebas implementa las pruebas
unitarias de la funcionalidad ofrecida por el componente del
mundo.
En nuestra línea de producto hemos dejado de lado el componente
de pruebas unitarias y hemos limitado el posible conjunto de
aplicaciones que queremos desarrollar, con el fin de identificar un
número manejable de características comunes y variables.
2.1.1 Características comunes del componente del
mundo
Los conceptos del mundo y sus relaciones pueden ser
representados y manipulados funcionalmente por medio de
estructuras de datos de tipo agrupación. Las agrupaciones siempre
tienen un elemento principal, que agrupa los demás elementos del
mundo. Las figuras 1a y 1b presentan dos ejemplos de modelos en
el dominio de la lógica de negocio donde sus elementos están
relacionados por medio de agrupaciones.
En el primer caso se presenta un modelo para una aplicación de
una tienda de discos virtual que maneja canciones en formato
mp3. En este modelo, se tienen elementos como Discotienda y
Disco. Las relaciones de agrupación muestran que el elemento
Discotienda contiene un grupo de Discos, y cada Disco a su vez
contiene un grupo de Canciones. En el segundo caso se presenta
un modelo para una aplicación de una exposición de automóviles.
En este ejemplo, se tiene el elemento ExposicionAutomoviles que
agrupa elementos Automóvil.
Todos los elementos del mundo tienen un conjunto de atributos, y
se relacionan con otros elementos del mundo. Finalmente, de
manera común en todas las aplicaciones de la línea de producto
cada elemento del mundo es responsable de hacer persistir su
información.
Figura 1. Modelos de los ejemplos de la Tienda de Discos y la
Exposición de Automóviles.
2.1.2 Características comunes del componente de
interfaz de usuario
Las interfaces gráficas de usuario manejan la funcionalidad de
paneles, listas, listas desplegables, etiquetas, cuadros de texto,
botones, imágenes, botones de radio y cajas de chequeo. Todos
los elementos gráficos de la interfaz de usuario se agrupan en
vistas de diferente tipo, cada una con responsabilidades
claramente definidas.
Hay dos tipos de vistas que son obligatorias para cualquier
aplicación de ejemplo de Cupi2: (1) la vista principal, y (2) la
vista de extensión. La vista principal comunica el componente del
mundo con las demás vistas y agrupa todas las demás vistas de la
interfaz gráfica. La vista de extensión contiene botones que el
estudiante puede usar para acceder a nuevas funcionalidades que
se agreguen como parte de la aplicación de ejemplo.
2.2 Identificación de características variables
en los ejemplos Cupi2
De la misma forma que se identifican características comunes a
todos los ejemplos, existen otras que varían para cada ejemplo
particular. Las características variables de los ejemplos Cupi2
están relacionadas básicamente con la organización de las vistas
incluidas en las interfaces de usuario y los algoritmos utilizados
para administrar las agrupaciones.
2.2.1 Características variables del componente del
mundo
En el componente del mundo se encuentran elementos variables
relacionados con los tipos de estructuras de datos, los algoritmos
que las manipulan y los servicios utilizados para hacer persistir las
diferentes agrupaciones.
Las estructuras de datos que representan las agrupaciones pueden
ser contenedores de tamaño fijo, contenedores de tamaño
variables o estructuras lineales como listas simples o doblemente
enlazadas. Cada tipo de estructura de datos puede ser manipulada
usando diferentes algoritmos. Por ejemplo, es posible manipular
una estructura de datos con algoritmos diferentes para hacer
recorridos, inserción, búsqueda y ordenamiento, entre otros
servicios.
Por otra parte, para hacer persistir la información de los elementos
del mundo se pueden implementar diferentes funcionalidades para
administrar archivos planos, o estructuras soportadas por las
diferentes plataformas tecnológicas como las estructuras creadas
al serializar objetos de Java.
Por ejemplo, en el caso de la exposición de automóviles, se puede
crear un archivo plano donde se escriben los datos de cada uno de
los automóviles que existan en la estructura de datos agrupación
residente en memoria. También es posible serializar cada objeto
utilizando métodos propios de Java. La selección de un método o
el otro depende del nivel del ejemplo y los temas asociados que se
deseen enseñar.
2.2.2 Características variables del componente de
interfaz de usuario
No existe una forma única de representar los elementos del mundo
en términos de componentes gráficos. El usuario puede
seleccionar uno o varios tipos de vistas para representar la
información de un elemento del mundo. Con propósitos
pedagógicos, cada uno de los tipos de vistas posibles que se
utilizan en los ejemplos tiene definido un conjunto de
responsabilidades particulares que el desarrollador puede utilizar
para representar su mundo particular. Las responsabilidades de
cada tipo de vista se presentan a continuación:
2.2.2.1 Vista Principal
Este tipo de vista agrupa a las demás vistas. A través una vista
principal se realiza la comunicación entre el componente del
mundo y el componente de la interfaz de usuario.
2.2.2.2 Vista de Extensión
Este tipo de vista se utiliza para agregar funcionalidad a las
aplicaciones. Las vistas de extensión tienen un conjunto de
botones, y funcionalidades asociados a cada botón. Sin embargo,
en un principio las funcionalidades sólo son responsables de
desplegar un mensaje de notificación. Las nuevas funcionalidades
o extensiones que se hagan a las funcionalidades existentes se
realizan manualmente por el estudiante a partir de las
instrucciones del profesor como parte de los ejercicios de
enseñanza de programación.
2.2.2.3 Vista de Conjunto
Este tipo de vista se encarga de presentar un conjunto de
elementos de agrupaciones por medio del uso de componentes
como listas o tablas. Adicionalmente puede ofrecer servicios que
manipulen el orden de presentación de los elementos dentro de la
agrupación.
2.2.2.4 Vista de Búsqueda
Este tipo de vista se utiliza para ingresar parámetros a partir de los
cuales se realizan búsquedas sobre una agrupación de elementos.
Típicamente contiene un cuadro de texto para introducir el
parámetro usado para realizar la búsqueda, y un botón de
confirmación.
2.2.2.5 Vista de Información
Este tipo de vista se utiliza para mostrar la información particular
asociada a los atributos de un elemento del mundo del problema.
Además de información alfanumérica, esta vista también puede
mostrar imágenes asociadas a los elementos.
2.2.2.6 Vista de Agregación
Este tipo de vista se utiliza para ingresar información particular
asociada a los atributos de nuevos elementos del mundo del
problema. Sus componentes son similares a los de la vista de
información, pero ésta utiliza cuadros de texto y botones de
confirmación para recopilar la información ingresada por el
usuario de la aplicación.
En la Figura 2 se muestra un ejemplo de una posible interfaz de
usuario para el ejemplo de la tienda de discos. Sobre esta interfaz
se pueden ver cuatro tipos de vistas diferentes: dos vistas de
información para mostrar los datos de los discos y de las
canciones, una vista de extensión con botones para agregar nuevas
funcionalidades al ejemplo, una vista de agregación para
introducir los datos de una canción nueva y finalmente una vista
principal que agrupa a todas las vistas.
Figura 2. Ejemplo de interfaz de usuario para el ejemplo de la
tienda de discos
3. PROCESO DE INGENIERÍA DE
DOMINIO
El proceso de ingeniería de dominio es el responsable de la
creación de activos necesarios para el desarrollo de SPLs. Los
activos de una línea son los componentes que conforman la
arquitectura de la línea, especificaciones de requerimientos,
modelos de diseño ó componentes de software, entre otros [10,
22]. En esta sección presentamos el conjunto de activos
necesarios para ilustrar nuestra propuesta de administración de
variabilidad en SPLs usando MDA, en el contexto de aplicaciones
ejemplo para el proyecto Cupi2. Estos activos son: (1) modelos de
rasgos, (2) metamodelos, y (3) reglas de transformación.
Para la creación de activos de la línea, separamos conceptos
relacionados con una SPL en diferentes dominios. Estos dominios
son el dominio de la lógica del negocio, el dominio de la
arquitectura que incluye la interfaz gráfica de usuario (GUI) y el
dominio de la plataforma tecnológica. Está separación nos permite
administrar la variabilidad de las líneas de producto de manera
aislada para cada dominio. Es decir, podemos expresar las
características comunes y variables de cada dominio, para luego
construir aplicaciones con características variables en cada uno de
los dominios permitiéndonos una mayor flexibilidad y
simplicidad.
Nuestra estrategia general para la creación de diferentes
aplicaciones de la línea, de acuerdo con el enfoque MDA, se basa
en la transformación automática de modelos hasta obtener
aplicaciones. Así, partimos de un modelo origen en el dominio de
la lógica de negocio, y lo transformamos en un modelo destino en
el dominio de la arquitectura; luego, partimos del modelo
generado en el dominio de la arquitectura, y lo transformamos en
un modelo destino en el dominio de la plataforma tecnológica;
finalmente, transformamos a código fuente el modelo de
plataforma tecnológica que ya incluye las características de lógica
de negocio y de arquitectura.
Para poder desarrollar aplicaciones siguiendo esta estrategia,
definimos modelos de rasgos para expresar las características
comunes y variables de cada dominio destino. Así, creamos
modelos de rasgos para el dominio de la arquitectura, y el
dominio de la plataforma tecnológica. Cada modelo de rasgos se
concentra en expresar características propias del dominio
particular. La Figura 3 presenta de manera general el proceso de
ingeniería de dominio.
Figura 3. Proceso de Ingeniería de Dominio
Como parte de los activos de la línea, para la generación de
aplicaciones, creamos metamodelos para cada uno de los
dominios presentados, y tres tipos de reglas de transformación
para transformar modelos en cada dominio origen, a modelos en
su respectivo domino destino. Como se dijo antes, estos tipos de
reglas son: (1) reglas base, (2) reglas de control, y (3) reglas
específicas. Las primeras reglas corresponden a reglas de
transformación escritas de forma declarativa, y son utilizadas para
generar las características comunes de las SPLs. Las reglas de
control se implementan de forma mixta (declarativa e imperativa),
y se encargan de escoger qué reglas específicas se deben ejecutar.
Las reglas de transformación específicas se implementan de forma
imperativa y son las encargadas de generar los elementos
necesarios de acuerdo con las características esperadas en el
modelo destino de la transformación.
3.1 Modelos de rasgos
Un modelo de rasgos expresa características de los productos de
una línea y es utilizado para representar las similitudes y
diferencias entre ellos. Los rasgos pueden ser obligatorios,
opcionales o alternativos. Los rasgos obligatorios son
características comunes a todos los productos, y los rasgos
opcionales y alternativos varían entre uno y otro producto [16].
Un diagrama de rasgos es un árbol cuyos nodos representan
rasgos. Los nodos pueden ser de tres tipos: nodo raíz, nodo
conjunto o nodo solitario. El nodo raíz es el nodo principal del
diagrama y siempre está presente. Un nodo conjunto agrupa otros
nodos y un nodo solitario es aquel que por definición no está
agrupado. Los nodos solitarios pueden ser obligatorios u
opcionales. Un nodo solitario es obligatorio cuando representa un
rasgo común a todos los productos, mientras que un nodo solitario
es opcional cuando representa un rasgo relevante a por lo menos
un producto. Un nodo conjunto puede agrupar nodos obligatorios,
y opcionales, o nodos alternativos. Cuando los nodos son
alternativos sólo uno de ellos puede ser seleccionado.
Definimos modelos de rasgos para expresar las características
comunes y variables de las diferentes aplicaciones de las SPLs.
Sin embargo, cada modelo de rasgos se concentra en expresar
características propias de las aplicaciones en un dominio
particular. Para esto, en nuestra propuesta construimos modelos
de rasgos para representar las características comunes y variables
de los modelos destino de una transformación en un dominio
determinado. En la SPL de las aplicaciones ejemplo del proyecto
Cupi2 existen dos dominios que en el proceso de generación de
aplicaciones se convierten en dominios destino, uno es el dominio
de la arquitectura, y el otro es el dominio de la plataforma
tecnológica.
La notación que utilizamos para representar los modelos de rasgos
es la definida en [12]. La figura 4 presenta un subconjunto del
modelo de rasgos para el dominio de la arquitectura. Estos rasgos
están relacionados con las características comunes y variables de
la interfaz de usuario identificadas en la sección 2. Este modelo
contiene el nodo Interfaz, un nodo solitario obligatorio y a la vez
un nodo conjunto. Como nodo conjunto, el nodo Interfaz agrupa
el nodo obligatorio Vista Principal y los nodos opcionales Vista
Conjunto, Vista Agregación y Vista Información.
Figura 4. Modelo de rasgos para el dominio de arquitectura
Cupi2
De manera complementaria la figura 5 presenta un subconjunto
del modelo de rasgos para el dominio de la plataforma tecnológica
(Java). En las figuras 4 y 5 se puede ver el nodo raíz de los
diagrama de rasgos, que para este caso se ha nombrado como el
nombre del proyecto: Cupi2. Este modelo contiene el nodo
Contenedora, un nodo solitario obligatorio que a la vez es
conjunto. Como nodo conjunto, el nodo Contenedora agrupa los
nodos alternativos ArrayList y Vector, que al ser nodos
alternativos significa que el usuario sólo puede seleccionar uno de
ellos.

Figura 5. Modelo de rasgos para el dominio de la plataforma
tecnológica Cupi2
La figura 6 presenta la relación que existe entre los dos modelos
de rasgos. Estas relaciones implican que los nodos que el usuario
puede seleccionar en el modelo de rasgos indican características
funcionales de cada aplicación de la SPL, algunas de ellas
asociadas directamente con la selección de estructuras de datos
particulares por implementar. Este es el caso de seleccionar un
rasgo que implique el uso de un Vector o de un Arraylist.
Figura 6. Modelo de rasgos para el dominio de arquitectura y
de plataforma tecnológica para la SPL del proyecto Cupi2
Esta relación permite ver cómo de manera complementaria la
variabilidad de una SPL se puede representar por diferentes
modelos de rasgos relacionados.
3.2 Metamodelos
Un metamodelo se crea con base en los conceptos de un dominio,
sus relaciones y semántica.
Así como los modelos de rasgos permiten expresar características
comunes y variables de un conjunto de aplicaciones, los
metamodelos permiten expresar características comunes y
variables de un dominio. Esto se logra abstrayendo los conceptos
de un dominio, sus propiedades, y sus relaciones. Los modelos
creados conformes a un metamodelo representan una instancia
particular del dominio, con un conjunto de características
específicas.
Para la creación de la SPL para el proyecto Cupi2 definimos como
activos tres metamodelos: el metamodelo de la lógica del negocio,
de la arquitectura y de la plataforma tecnológica. Cada
metamodelo incluye conceptos abstractos de un dominio diferente
de la SPL. Así, el metamodelo de la lógica del negocio sólo
incluye los conceptos esenciales del mundo del problema en los
ejemplos Cupi2; el metamodelo de la arquitectura incluye los
conceptos del metamodelo de lógica del negocio transformados,
junto con los conceptos de la arquitectura incluida la interfaz de
usuario; finalmente, el metamodelo de la plataforma tecnológica
incluye los conceptos del metamodelo de arquitectura ya
transformados junto con los conceptos propios del lenguaje como
por ejemplo paquetes, clases, métodos y atributos.
De acuerdo con las características comunes y variables
identificadas en la sección precedente, en las siguientes secciones
presentamos los metamodelos de la lógica del negocio y de la
arquitectura.
3.2.1 Metamodelo de la lógica del negocio
El metamodelo de la lógica del negocio presentado en la Figura 7
incluye conceptos abstractos para los niveles 7 y 8 de los ejemplos
de Cupi2. En términos generales, estos ejemplos describen un
conjunto de elementos relacionados entre sí a través de estructuras
de agrupamiento. Por ejemplo, si se habla de un problema para
una exposición de automóviles, se dice que un elemento
Exposición agrupa a un conjunto de Automóviles. Además cada
elemento puede tener un conjunto de atributos que lo caractericen.
Por ejemplo, es posible que el elemento Automóvil tenga un
atributo que represente el año de fabricación, este atributo puede
usarse para construir un servicio de ordenamiento por año de
fabricación.
Figura 7. Metamodelo de la lógica del negocio
En la Figura 7 se presentan los conceptos Agrupador y Elemento,
y la relación de agregación entre ellos. También se presenta el
concepto AtributoCupi2 y los atributos que caracterizaran este
concepto del mundo de acuerdo con los requerimientos
particulares de las aplicaciones que se construirán. Por ejemplo,
se presenta el atributo esComparable que una vez instanciado,
indica que el AtributoCupi2 que posee la propiedad de ser
comparable tiene un tratamiento especial en el momento de
construir los algoritmos de búsqueda o de ordenamiento que sobre
él se realicen.
 presenta el concepto de Vista, una Vista a la vez puede tener un
conjunto de Componentes y un conjunto de Servicios. Los
Componentes se especializan en dos tipos, Componentes de
Interacción y de Visualización. Los Componentes de Interacción
son Componentes visuales mediante los cuales el usuario puede
invocar algún tipo de funcionalidad. Algunos ejemplos de
Componentes de Interacción pueden ser botones, listas o listas
desplegables. Por otro lado, los Componentes de Visualización se
usan para mostrar la información propia del ejemplo al usuario.
Algunos ejemplos de estos Componentes son las etiquetas, los
cuadros de texto o los cuadros de mensajes.

Figura 8. Modelo e instancia de un elemento del modelo para

el ejemplo Exposición de Automóviles
Los modelos conformes al metamodelo de la lógica del negocio,
utilizan sus conceptos para expresar las características propias de
una instancia del dominio que representan. En la figura 8a se
presenta el ejemplo de un modelo para construir la aplicación de Figura 9. Metamodelo de Interfaz
exposición de automóviles. En este modelo se utiliza el
estereotipo Agrupador, Simple, Atributo y AtributoCupi2 para La Figura 10 presenta un modelo conforme al metamodelo de
indicar la relación de conformidad entre elementos del modelo y interfaz de usuario de la arquitectura. De la misma manera que en
del metamodelo. El elemento ExposicionAutomoviles es conforme la figura 8, utilizamos estereotipos para mostrar la relación de
al elemento Agrupador que fue definido en el metamodelo. De conformidad de los elementos del modelo con el metamodelo.
acuerdo con la definición del elemento Agrupador, un concepto
de este tipo debe agrupar un conjunto de otros elementos. En el
caso del ejemplo, estos elementos son Automóvil. Cada Automóvil
a su vez contiene un conjunto de Atributo y de AtributoCupi2. En
la Figura 8b, se presentan un ejemplo de datos específicos que
puede tomar una instancia del modelo para el elemento imagen de
tipo AtributoCupi2.

3.2.2 Metamodelo de Arquitectura

El metamodelo de arquitectura esta relacionado con conceptos de
diseño de los ejemplos Cupi2, este metamodelo no incluye
decisiones de implementación sobre una plataforma tecnológica
específica. Para facilitar la representación, definimos un
metamodelo de arquitectura para los conceptos relacionados con
la lógica del negocio y otro con los conceptos de la interfaz
usuario.
El metamodelo de arquitectura de la lógica del negocio introduce
el concepto de Servicio. Los servicios son necesarios para
manipular las estructuras de datos del ejemplo. Por otro lado, la
interfaz de usuario incluye los conceptos de elementos gráficos y Figura 10. Modelo para el ejemplo Exposición de Automóviles
de interacción que serán parte de la interfaz gráfica de usuario de conforme al metamodelo de arquitectura de interfaz de
la aplicación generada. De esta manera, un modelo conforme al usuario
metamodelo de arquitectura, posee todos los elementos En este caso se tienen cuatro elementos diferentes conformes al
estructurales y gráficos a partir de los cuales se puede proceder elemento Vista del metamodelo. Cada Vista a su vez tiene un
con la especificación de la plataforma tecnológica y la generación conjunto de componentes específicos de acuerdo con sus
del código fuente. La Figura 9 presenta un subconjunto del responsabilidades específicas. El elemento PrincipalExposición es
metamodelo de interfaz de usuario. Este metamodelo busca la la Vista principal y contiene a las demás Vistas. La Vista
generalización de los conceptos encontrados en los distintos tipos ConjuntoAutomoviles se encarga de mostrar al grupo de
de vistas descritos en la sección 2. Como elemento principal se automóviles contenidos por la estructura de datos de la aplicación
ejemplo. Esta Vista tiene un componente de interacción de tipo
Lista para mostrar el conjunto de automóviles. El Botón
ordenarPorModelo está asociado con los servicios de
ordenamiento sobre la lista de automóviles. La Vista
BusquedaAutomóvil brinda al usuario la posibilidad de buscar un
automóvil en específico a partir del nombre. Por último, la Vista
InformaciónAutómovil, tiene un conjunto de Etiquetas para
visualizar cada uno de los atributos del Automóvil.
3.3 Modelos de entrelazado y reglas de
Transformación
Nuestra estrategia general, para la creación de aplicaciones de la
línea, se basa en la transformación de modelos hasta obtener
aplicaciones. Así, partimos de un modelo origen en el dominio de
la lógica de negocio, y lo transformamos hasta obtener código
fuente que incluye características de lógica de negocio, de
plataforma tecnológica y de arquitectura.
Las reglas de transformación típicas son definidas a nivel de los
conceptos de los metamodelos. Una regla de transformación toma
los elementos de un modelo origen, conformes a un concepto del
metamodelo origen, y los transforma en elementos de un modelo
destino, conformes a un concepto del metamodelo destino. Esto
implica que en una transformación todo modelo tiene un único
modelo destino asociado. Sin embargo, para crear aplicaciones
con características variables es necesario que un mismo modelo
pueda ser transformado en modelos destino diferentes.
Para la generación de aplicaciones de la SPL definimos tres tipos
de reglas de transformación, las cuales transforman modelos de
los dominios origen, en modelos del domino destino, permitiendo
generar diferentes modelos destino a partir de un mismo modelo
de origen según la funcionalidad deseada. Estos tipos de reglas
son: (1) reglas base, (2) reglas de control, y (3) reglas específicas.
Para diseñar estas reglas de transformación creamos modelos de
entrelazado que permiten relacionar elementos de varios modelos
[14].
Los modelos de entrelazado que creamos como parte del proceso
de ingeniería de dominio incluyen todas las relaciones entre los
elementos de cada metamodelo origen y su respectivo modelo de
rasgos destino. Así identificamos los elementos del metamodelo
origen que se transforman siempre en los mismos elementos del
metamodelo destino, para los cuales creamos reglas base, y los
que pueden ser transformados de forma diferente (variable), para
los que creamos reglas de control y reglas específicas. De esta
forma construimos reglas base para generar las características
comunes de la línea, y reglas de control y específicas para generar
las características variables.
La Figura 11 ilustra un modelo de entrelazado entre un
metamodelo de lógica de negocio y los rasgos de la arquitectura.
En la figura el enlace entre Agrupador y el rasgo obligatorio
VistaPrincipal indica que para un elemento de tipo Agrupador
siempre se crea una Vista Conjunto. Para este enlace creamos una
regla base. Los enlaces entre Agrupador y los rasgos alternativos
Serializacion y Archivos, indican que un elemento de tipo
Agrupador puede implementar su persistencia de las dos
diferentes formas. Para estos enlaces creamos una regla de control
y dos reglas específica. Los enlaces entre el elemento Simple y los
rasgos opcionales VistaInformacion, VistaConjunto y creada (línea 25).
VistaAgregacion, indican que un elemento de tipo Simple se
puede transformar en cualquiera de las tres vistas. Para estos
enlaces creamos otra regla de control y tres reglas específica más.
Figura 11. Modelo de entrelazado entre el metamodelo de
lógica de negocio y el modelo de rasgos de la arquitectura
Nosotros implementamos las reglas base de forma declarativa, y
las reglas específicas de forma imperativa. Las reglas imperativas
pueden ser ejecutadas muchas veces en un proceso de
transformación con parámetros diferentes.
Las reglas de control son implementadas de forma mixta, es decir,
tienen una parte declarativa y una parte imperativa. Las reglas de
control determinan qué reglas específicas deben ejecutarse según
las características variables deseadas para el modelo destino de la
transformación.
En el Listado 1 presentamos un ejemplo de reglas base, de control
y específicas. La regla vistaPrincipal es una regla base. El patrón
origen se define en las líneas (2-3) y el patrón destino en las líneas
(4-6). La regla vistaPrincipal consulta el modelo de la lógica de
negocio en busca de los elementos conformes al concepto
Agrupador (línea 3) de encontrarse alguno, se crea una Vista
Principal (línea 5). Siguiendo con nuestro ejemplo de la tienda de
discos, se crea una Vistaprincipal a partir del elemento
Discotienda. Para el ejemplo de una Exposición de vehículos, se
crea una Vista principal asociada a ExposiciónVehículo.
La regla vistaConjunto es una regla de control. En las líneas 7-14
se define la parte declarativa y en las líneas 15-18 la parte
imperativa. La regla vistaConjunto busca en el modelo de
entrelazado aquellos enlaces que tenga como rasgo Vista
Conjunto (línea 9). De acuerdo con el modelo de entrelazado
presentado en la figura 9, la regla encuentra que existe un enlace
entre Disco y VistaConjunto, entonces se recupera el elemento
Disco del modelo de la lógica de negocio (línea 11), crea una
Vista (línea 14) e invoca la regla imperativa addComponente
(16).
La regla addComponente es una regla especifica. En la línea 19 se
aprecia el nombre de la regla y sus parámetros, en las líneas 20-23
se aprecia el patrón destino y en las líneas 24-26 se aprecian
sentencias imperativas. Cuando ésta regla es invocada desde la
regla de control se crea un componente de tipo Visualizacion
(línea 21), se le asigna al componente el tipo del parámetro, en
este caso lista (línea 22), y se agrega el componente a la Vista

Listado 1. Reglas de transformación base, de control e
imperativas
4. INGENIERÍA DE APLICACIÓN
El proceso de ingeniería de aplicación es el responsable de la
creación de productos de la SPL usando los activos construidos en
el proceso de ingeniería de dominio [10, 22].
Como presentamos antes, nuestra estrategia general para la
creación de aplicaciones de la línea se basa en la transformación
de modelos hasta obtener aplicaciones. Así, nosotros partimos de
un modelo fuente en el dominio de la lógica de negocio, y lo
transformamos hasta obtener código fuente con características de
la lógica de negocio, de arquitectura, y de plataforma tecnológica.
El proceso general de ingeniería de aplicación es presentado en la
Figura 12.
Figura 12. Proceso de Ingeniería de Aplicación
4.1 Modelo de lógica de negocio
Como se puede ver en la figura 12, la primera actividad de este
proceso es la creación de un modelo conforme al metamodelo de
lógica de negocio. Los modelos conformes al metamodelo de la
lógica del negocio utilizan sus conceptos para expresar las
características propias de una instancia del dominio que
representan. Un ejemplo de este modelo es el presentado
previamente en la Figura 8a.
4.2 Modelo de entrelazado entre modelos
origen y rasgos del dominio destino
Para la generación de modelos con rasgos particulares en el
dominio destino es necesario hacer la selección de rasgos
deseados. Para esto creamos modelos de entrelazado entre los
elementos de modelos conformes a un metamodelo origen y los
elementos del modelo de rasgos destino. La selección de rasgos
sobre el modelo de entrelazado nos permite determinar el
conjunto de reglas de transformación necesarias para generar el
modelo destino deseado.
En estos modelos de entrelazado las relaciones están restringidas
por el entrelazado realizado en el proceso de ingeniería de
dominio. Por ejemplo, en el modelo de entrelazado del proceso de
ingeniería de dominio se puede ver que es posible transformar los
elementos conformes al elemento Agrupador del metamodelo
origen, en una Vista de Información o en una Vista Conjunto. Así,
en el modelo de entrelazado del proceso de ingeniería de
aplicación, cada elemento conforme al elemento Agrupador se
entrelaza con uno de los dos posibles destinos: Vista de
Información o Vista Conjunto. En la Figura 13 se presenta un
modelo de entrelazado para este ejemplo.
Figura 13. Modelo de entrelazado entre un modelo de lógica de
negocio y el modelo de rasgos de arquitectura
La figura 13 presenta enlaces que tienen como origen elementos
del modelo de la lógica de negocio y como destino rasgos de
arquitectura. En la figura se puede ver la relación entre el
elemento Discotienda y el rasgo Vista información, y el enlace
entre el elemento Disco y el rasgo Vista conjunto. Esta selección
de rasgos y asociación con elementos del modelo de la lógica de
negocio genera una interfaz de usuario con una Vista información,
la cual contiene etiquetas y cuadros de texto asociados a los
atributos de Discotienda, y una Vista Conjunto que agrupa los
nombre de los Discos en una lista. Por otro lado el enlace entre
Discotienda y el rasgo Serialización, impide que haya un enlace
entre Discotienda y Archivos, pues Serialización y Archivos son
rasgos alternativos.
Para la SPL de Cupi2 nosotros realizamos dos operaciones de
entrelazado. En la primera se entrelazan modelos de la lógica de
negocio con los rasgos de arquitectura, y en la segunda se
entrelazan modelos de arquitectura con los rasgos de plataforma
tecnológica.
4.3 Configuración y ejecución de reglas de
transformación
Cuando la selección de rasgos ha sido realizada para un proceso
de transformación entre modelos, un conjunto de reglas de
transformación son ejecutadas. Este conjunto de reglas de
transformación incluye reglas base, reglas de control, y reglas
específicas.
Cada proceso de transformación tiene como entradas un modelo
origen, el conjunto de reglas de transformación, y el modelo de
entrelazado entre modelos origen y rasgos del dominio destino; y
como salida un modelo destino.
Al ejecutarse la transformación se recorren todos los elementos
del modelo origen, aplicando las reglas base o de control
asociadas a cada uno según sea el caso. Si un elemento esta
asociado a una regla base, ésta se ejecuta generando los elementos
definidos en la regla. Si un elemento está asociado a una regla de
control, se analizan las propiedades del elemento y los rasgos que
tiene asociados en el modelo de entrelazado. Según esto se decide
qué regla especifica debe ejecutarse. Las reglas especificas reciben
como parámetro el elemento y algunos parámetros que permiten
producir los elementos deseados para cumplir con la
funcionalidad representada por el rasgo.
5. IMPLEMENTACIÓN DE LA SOLUCIÓN
En el proceso de ingeniería de dominio para desarrollar la SPL
donde creamos aplicaciones específicas de ejemplo como la de la
Tienda de Discos, la Exposición de Vehículos, y otras han
servido como validación de esta propuesta, se construyeron como
activos de la línea modelos de rasgos, metamodelos, y reglas de
transformación. Se construyeron modelos de rasgos para el
dominio de la arquitectura y de la plataforma tecnológica. Se
construyeron metamodelos de la lógica del negocio, de la
arquitectura, y de la plataforma tecnológica. Finalmente, se
construyeron reglas de transformación base, de control y
especificas. Estas reglas de transformación transforman modelos
de la lógica del negocio a modelos de arquitectura, y modelos de
arquitectura a modelos de la plataforma tecnológica.
De manera consolidada el proceso de creación de la aplicación es
el siguiente. El desarrollador crea un modelo de la lógica del
negocio. Este modelo se entrelaza con el modelo de rasgos de la
arquitectura y se aplica la transformación necesaria para obtener
un modelo de arquitectura. El modelo de arquitectura generado se
entrelaza con el modelo de rasgos de la plataforma tecnológica y
se aplica la transformación necesaria para obtener un modelo de
plataforma tecnológica. Finalmente, se aplica una transformación
basada en plantillas para generar el código fuente (ver Figura 12).
Para la implementación de nuestra solución seleccionamos una
suite de herramientas plug-ins de Eclipse [4]. Estas se describen a
continuación:
• Un manejador de metamodelos y modelos: esta herramienta
debe permitir definir metamodelos y modelos, que sean
serializados en formato XMI y seguir los estándares de MOF
propuestos por la OMG. Para esto se escogió a EMF [5].
EMF implementa EMOF (Essential MOF), el cual es el
subconjunto básico de MOF.
• Una herramienta gráfica de modelado: Debido a la
complejidad en la expresión de los metamodelos se requiere
de una herramienta que permita modelar gráficamente. Se
escogió GMF como herramienta de modelado. Esta
herramienta permite definir metamodelos gráficamente y
generar un plug-in que permite crear los modelos conformes
a dicho metamodelo [6].
• Un lenguaje de transformación de modelo a modelo: Un
lenguaje que permita definir transformaciones entre los
metamodelos de dos dominios. Se seleccionó ATL como
lenguaje de transformación por ser un lenguaje mixto
(declarativo e imperativo) compatible con modelos
expresados con EMF [3]. Aun cuando ATL no es una
implementación de QVT (Query, View, Transformations), el
estándar propuesto por la OMG para hacer consultas y
transformaciones sobre los modelos y metamodelos, tiene
una implementación consistente.
• Una herramienta de entrelazado entre modelos: Una
herramienta que permita mapear o relacionar elementos de
dos modelos diferentes, y genere un modelo con la
información de estos entrelazados para ser utilizada por las
transformaciones automáticas, y que sea compatible con
modelos expresados con EMF. Esta herramienta es AMW[2].
• Un lenguaje de transformación de modelo a código: Se
requiere un lenguaje de transformación que se especialice en
la generación de archivos de texto (código, XML,
documentación) a partir de modelos. Usamos Acceleo [1]
debido a que podemos recibir modelos expresados con EMF,
utilizar plantillas para la generación, manejar adecuadamente
código no generado.
6. TRABAJOS RELACIONADOS
Propuestas para la administración de la variabilidad en SPL
plantean principalmente estrategias que se enfocan en administrar
la funcionalidad variable de los miembros de las familias de
productos. La diferencia entre estas propuestas radica en los
activos utilizados para expresar la variabilidad, y para crear
aplicaciones (variables) de la SPL en el proceso de ingeniería de
aplicación. En esta sección se presenta un consolidado de
propuestas para administrar la variabilidad en SPLs. Sin embargo,
el objetivo de esta sección no es presentar todo el estado del arte
del tema. Algunos trabajos pueden no encontrarse aquí
referenciados.
El método FODA [16] fue introducido como una estrategia para
expresar funcionalidad variable en el proceso de ingeniería de
requerimientos a través del uso de modelos de rasgos. La
propuesta de FORM [17] complementa la propuesta de FODA
para expresar funcionalidad variable en el proceso de diseño de
aplicaciones, y prescribe cómo los modelos de rasgos pueden ser
usados como base para desarrollar arquitecturas de dominio y
componentes para reutilización. En FORM los autores proponen
categorizar los rasgos de acuerdo con requerimientos no
funcionales, y usan componentes orientados a objetos como
activos para crear aplicaciones de la SPL.
En AHEAD [8] se propone un modelo de arquitectura para
programación orientada a modelos, y una base para programación
composicional a gran escala. En AHEAD (Algebraic Hierarchical
Equations for Application Design) los modelos de rasgos son
usados para expresar variabilidad. Los activos para crear
aplicaciones de la SPL son fragmentos de clases y métodos. Los
rasgos se asocian con estos activos, y se componen por medio de
ecuaciones algebraicas para crear aplicaciones de la SPL.
En [7] se presenta una propuesta que tiene como activos clases y
aspectos. Para la expresión de la variabilidad, los autores
proponen la elaboración de modelos de rasgos. Para la creación de
aplicaciones de la SPL se propone: (1) el diseño de una
arquitectura flexible aplicando patrones, (2) el diseño de los
aspectos correspondientes a los rasgos variables, y (3) la
composición entre los aspectos y las clases de negocio.
Como se puede ver en los trabajos citados, los modelos de rasgos
son un estándar de facto para modelar la variabilidad de las SPLs.
Sin embargo, existen otras propuestas de modelos que apuntan a
la expresión de esta variabilidad. En [23] se propone un modelado
ortogonal de la variabilidad (OVM) para reducir la complejidad
de los modelos de rasgos. Los modelos de variabilidad son
construidos conformes a un metamodelo general que define los
conceptos de variabilidad. A su vez, en [20] se presenta un
proceso basado en UML para la expresión de la variabilidad y la
definición de mecanismos que permitan la implementación de
ésta, es decir, la construcción de aplicaciones de la SPL.
Recientes trabajos presentan cómo la Ingeniería Dirigida por
Modelos (MDE) es útil en el proceso de administración de la
variabilidad en SPLs. En [12] el autor presenta desde una
perspectiva global los conceptos básicos del enfoque de
Desarrollo de Software Generativo (GSD). Este enfoque apunta a
desarrollar familias de productos automatizando la creación de
miembros de la familia a partir de especificaciones escritas en
lenguajes de dominio específico. Estos lenguajes pueden ser
definidos por medio de metamodelado.
En [13] se presentan MDA como un mecanismo para expresión de
variabilidad que permite aplazar la toma de decisiones sobre el
modelo de rasgos. En [25] se utilizan los diferentes niveles de
abstracción de MDA como mecanismo para expresar la
variabilidad de manera separada para cada dominio que
corresponde a una abstracción. Las aplicaciones de la SPL son
creadas componiendo elementos de un framework común. En [15]
se plantea la reutilización de activos y la ampliación de alcance
del manejo de la variabilidad, por medio de el uso de
metamodelos en diferentes niveles de abstracción. La
composición de las aplicaciones se hace por medio de mapeos
entre los conceptos abstractos del negocio y los componentes de
bajo nivel. Estas propuestas MD-SPL no utilizan
transformaciones como mecanismo para la generación de las
diferentes aplicaciones de la SPL
En nuestra propuesta nosotros usamos como activos para
administrar la variabilidad: (1) modelos de rasgos, (2)
metamodelos, y (3) reglas de transformación. Al igual que en
algunas de las propuestas anteriores, usamos modelos de rasgos
para expresar la variabilidad de las aplicaciones que hacen parte
de la SPL. Sin embargo, de acuerdo con nuestra estrategia de
generación de aplicaciones de una SPL, nosotros creamos
diferentes modelos de rasgos para expresar de manera separada la
variabilidad de la línea en cada dominio específico. De manera
complementaria a los modelos de rasgos, usamos metamodelos
para expresar la variabilidad de los diferentes dominios,
ampliando así el alcance de una SPL.
Para la creación de aplicaciones usamos una estrategia
principalmente generativa. Nosotros generamos automáticamente
las aplicaciones con características variables de una SPL usando
reglas de transformación aplicadas sobre modelos. En cada
proceso de transformación permitimos tomar decisiones de los
rasgos seleccionados. Así, dividimos la toma de decisiones sobre
los modelo de rasgos, aplazando hasta el último momento las
decisiones referentes a plataforma tecnológica.
7. CONCLUSIONES
En este artículo hemos presentado una propuesta para administrar
la variabilidad durante el proceso de construcción de SPLs usando
un enfoque MD-SPL. Para la creación de activos de la línea,
hemos separado conceptos relacionados con una SPL en
diferentes dominios. Esta separación permite ampliar el alcance de
la SPL administrando la variabilidad a nivel de conceptos de cada
dominio de forma independiente, al tiempo que se sigue
administrando la variabilidad de las aplicaciones de la línea sobre
un conjunto bien definido de características funcionales.
La estrategia que hemos utilizado para la creación de diferentes
aplicaciones de la línea se basa en la transformación automática
de un modelo inicial de lógica de negocio en un modelo destino
de arquitectura; luego, partimos del modelo de arquitectura, y lo
transformamos en un modelo destino de plataforma tecnológica;
finalmente, transformamos a código fuente el modelo de
plataforma tecnológica que ya incluye las características de lógica
de negocio y de arquitectura. De esta forma, solo construimos
manualmente el modelo inicial de la lógica del negocio usando
conceptos con un alto nivel de abstracción. Posteriormente
generamos de forma automática otros modelos por medio de
reglas de transformación hasta obtener aplicaciones. Así
construimos y usamos reglas de trasformación más sencillas y
flexibles que las necesarias para transformar en un solo paso un
modelo de lógica de negocio en una aplicación. Dado que las
aplicaciones que generamos no son del todo completas al no
incluir todos los requerimientos funcionales, parte del trabajo
futuro incluye el modelado de todos los requerimientos
funcionales como parte de los modelos de lógica de negocio, y la
trasformación de los modelos de los requerimientos hasta
incluirlos en las aplicaciones completas generadas.
Para guiar la generación de aplicaciones con características
diferentes (variables) en cada dominio, nosotros creamos
metamodelos, modelos de rasgos, modelos de entrelazado y tres
tipos diferentes de reglas de transformación: (1) base, (2) de
control y (3) específicas. Los modelos de rasgos permiten
expresar y seleccionar las características deseadas de una
aplicación en un dominio destino específico. Los metamodelos
permiten crear un amplio conjunto de modelos (variables) en un
dominio particular ampliando el alcance de la SPL. Los modelos
de entrelazado entre metamodelos y modelos de rasgos permiten
identificar las reglas de transformación necesarias para generar
características comunes y variables de las aplicaciones de la línea.
Las reglas de transformación base permiten crear aplicaciones con
las características comunes de la línea. Las reglas de control y
específicas permiten crear aplicaciones con las características
 variables de la línea. Finalmente, los modelos de entrelazado entre
modelos origen de una transformación y modelos de rasgos del
dominio destino de la transformación permiten la ejecución
automática de reglas para generar modelos de aplicaciones
variables en cada dominio. Así, usando estos diferentes activos se
puede administrar la variabilidad de SPLs no solo a nivel de
aplicación, sino a nivel de dominio. Esto significa que podemos
generar aplicaciones que varían no solo en funcionalidades
concretas a nivel de aplicaciones de la línea, sino en conceptos de
los diferentes dominios identificados.
Actualmente nuestra propuesta se encuentra en validación
generando diferentes aplicaciones de la línea. Como futuro trabajo
se espera crear SPLs para otros niveles de Cupi2 de manera que se
pueda validar los conceptos de esta propuesta en dominios donde
la lógica de negocio maneje un número más elevado de conceptos.
La construcción de un Plug-in para eclipse que permite la
creación de los modelos de entrelazados, la selección de rasgos en
cada dominio, y la generación automática de aplicaciones hace
parte del trabajo actual como parte de la propuesta.
Aun cuando los resultados hasta ahora obtenidos como parte de la
implementación de la propuesta son motivadores, existe un
amplio número de puntos para trabajar. Algunos de ellos se
presentan a continuación. Es necesario profundizar en el tema de
separación de dominios, explorando alternativas para separar
dominios y para modelar conceptos de cada dominio particular.
Como parte del trabajo sobre la expresión conceptual de los
diferentes dominios, es necesario trabajar sobre la expresión y
transformación de conceptos relativos a requerimientos
funcionales de las aplicaciones que se construyen. También es
necesario trabajar sobre la construcción de reglas de control y
reglas específicas más modulares con base en patrones de
transformación mejor definidos. Como parte complementaria a los
procesos de transformación, y en general a los procesos de
generación de aplicaciones, en esta propuesta la administración de
la trazabilidad es un campo completo por explorar.
8. REFERENCES
[1] Acceleo. En Línea: http://www.acceleo.org, Ultima visita
2006
[2] AMW Home Page. En Línea:
http://www.eclipse.org/gmt/amw/, Ultima visita 2006
[3] ATL Home Page. En Línea: http://www.eclipse.org/gmt/atl/,
Ultima visita 2006
[4] Eclipse. En Línea: http://www.eclipse.org/, Ultima visita 2006
[5] Eclipse Modeling Framework. En Línea:
http://www.eclipse.org/emf/, Ultima visita 2006
[6] Graphical Modeling Framework En Línea:
http://www.eclipse.org/gmf/, Ultima visita 2006
[7] V. Alves, A. Dantas y P. Borba. AOP-Driven Variability in
Product Lines of Pervasive Computing Applications Second
International GenerativeProgramming and Component
Engineering Conference (GPCE'03), Erfurt, Germany,
2003.
[8] D. Batory, Feature-oriented programming and the AHEAD
tool suite. en International Conference on Software
Engineering (ICSE'04), Edinburg, Scotland, 2004.
[9] J. Bézivin On the Unification Power of Models. Software and
Systems Modeling, 4 (2). 171-188. 2005.
View publication stats
[10] P. Clements y L. Northrop Software Product Lines:
Practices and Patterns. Addison Wesley Professional,
2001.
[11] Cupi2. Proyecto CUPI2.http:cupi2.uniandes.edu.co. En
Línea, Ultima visita Diciembre 2006
[12] K. Czarnecki, Overview of Generative Software
Development. en Unconventional Programming Paradigms
(UPP'04), Mont Saint-Michel, France, 2004, LNCS 313–
328.
[13] S. Deelstra, M. Sinnema, J.v. Gurp y J. Bosch, Model Driven
Architecture as Approach to Manage Variability in Software
Product Families. en Workshop on Model Driven
Architecture: Foundations and Applications (MDAFA'03),
Enschede, The Netherlands, 2003.
[14] M. Didonet Del Fabro, J. Bézivin, F. Jouault, E. Breton y G.
Gueltas, AMW: a generic model weaver. en Journées sur
l'Ingénierie Dirigée par les Modèles (IDM'05), Paris, France,
2005.
[15] J. Estublier y G. Vega. Reuse and variability in large
software applications 13th ACM SIGSOFT ACM Press
Lisbon, Portugal 2005.
[16] K. Kang, S. Cohen, J. Hess, W. Novak y A. Peterson.
Feature-Oriented Domain Analysis (FODA) Feasibility
Study. CMU/SEI-90-TR-021, T.R. ed., Software Engineering
Institute, Carnegie Mellon University, Pittsburgh, Estados
Unidos 1990.
[17] K.C. Kang, S. Kim, J. Lee, K. Kim, E. Shin y M. Huh
FORM: A feature-oriented reuse method with domain-
specific reference architectures. Annals of Software
Engineering 5. 143 - 168. 1998.
[18] J. Lee y D. Muthig Feature-oriented variability management
in product line engineering. Communications of the ACM, 49
(12). 55 - 59. 2006.
[19] J. Mukerji y J. Miller. MDA Guide, 2003.
[20] E.A.d. Oliveira, I.M.S. Gimenes, E.H.M. Huzita y J.C.
Maldonado, A variability management process for software
product lines. en Conference of the Centre for Advanced
Studies on Collaborative research Toronto, Ontario, Canada
2005, 225 - 241
[21] O.M.G. OMG. MOF 2.0 Query/Views/Transformations RFP,
2002.
[22] K. Pohl, G. Böckle y F.J.v.d. Linden Software Product Line
Engineering: Foundations, Principles and Techniques.
Springer, 2005.
[23] K. Pohl, F. van der Linden y A. Metzger Software Product
Line Variability Management. International Software
Product Line Conference. 2006.
[24] J. Sametinger Software engineering with reusable
components. Springer, New York, 1997.
[25] A.L. Santos, A. Lopes y K. Koskimies, An MDA Approach
to Variability Management in Product-Line Engineering en
Nordic Workshop on UML and Software Modeling
(NWUML'06), Grimstad, Norway, 2006.
[26] S.E.I. SEI. Software Product Lines. En Línea:
http://www.sei.cmu.edu/productlines/, Ultima visita
Diciembre 2006