generación incremental de código basada en modelos · tradicionales (p.e., c++, java). dichos...
TRANSCRIPT
181
Generación incremental de código basada en modelos
Vicente García-Diaz1, Edward Rolando Núnez-Valdéz1, Luis Joyanes Aguilar2,,
Juan Manuel Cueva Lovelle1, Oscar Sanjuán Martínez1, B. Cristina Pelayo García-
Bustelo1, Carlos Enrique Montenegro-Marin3 , Jordan Pascual Espada1
1 Departamento de Informática, Universidad de Oviedo, C/Calvo Sotelo s/n 33007, Oviedo, Asturias, España
2 Facultad de Informática, Universidad Pontificia de Salamanca, Paseo Juan XXIII N 3, 28040, Madrid, España
3 Facultad de Ingeniería, Universidad Distrital, Colombia Carrera 7 N 40-53 Bogotá, Colombia
1{garciavicente, nunezedward, cueva, osanjuan, crispelayo}@uniovi.es, [email protected], [email protected], [email protected]
Resumen. La aproximación de desarrollo de software denominada Ingeniería Dirigida por Modelos continua evolucionando a gran ritmo. Prueba de ello son los numerosos estándares que están surgiendo y la reciente aparición de herramientas (p.e., Eclipse Modeling Project) que facilitan el trabajo con este
reciente paradigma de la ingeniería del software. Al trabajar con modelos, un aspecto clave es la generación automática de artefactos de menor nivel de abstracción. Sin embargo, la forma de llevar a cabo dicha generación no tiene en cuenta la evolución de los sistemas a lo largo de su ciclo de vida, realizándose de forma poco flexible y repetitiva. En este trabajo vamos a presentar una propuesta y un prototipo para generar artefactos incrementalmente a partir de modelos, de forma que se optimicen los recursos computacionales, se minimice el impacto sobre aplicaciones que ya podrían estar en producción y se permita la realización de trazabilidad de la evolución de los sistemas.
Palabras Clave: Metamodelo, modelo, generación de artefactos, incremental.
11 Introducción
La Ingeniería Dirigida por Modelos (MDE) [1] es un paradigma relativamente
novedoso en el desarrollo de software que ha ido ganando importancia desde su
aparición, sobre todo en el desarrollo de líneas o familias de productos software [2].
Consiste en utilizar modelos [3] como elementos principales en el desarrollo. Así, se
logra un mayor nivel de abstracción que el logrado por lenguajes de programación tradicionales (p.e., C++, Java). Dichos modelos, generalmente se transforman
automáticamente, reduciendo su nivel de abstracción, a artefactos que pueden ser, por
ejemplo, código fuente Java o documentación en formato HTML, facilitando así la
generación de sistemas software [4]. La manera de proceder es la siguiente: un
desarrollador crea un modelo y el generador se encarga de crear los artefactos que se
correspondan con el modelo. Dichos artefactos podrían ser por si mismos un sistema
completo o un subsistema.
Los modelos, por tanto, están sometidos a los mismos desafíos que cualquier
sistema software podría sufrir durante su evolución [5] y están sujetos a
modificaciones a lo largo de todo su ciclo de vida debido, por ejemplo, a cambios en
el negocio del cliente. Típicamente, si el desarrollador modifica el modelo a partir del
cual se generan los artefactos, habría que volver a ejecutar el generador, volviendo a regenerar todos los artefactos, incluidos los que no han cambiado de una versión a otra
del modelo. Esto es un problema en varios sentidos: 1- no se optimizan los recursos
computacionales de los que se dispone, 2- se dificulta el mantenimiento de
aplicaciones en producción y 3- se imposibilita la realización de trazabilidad de los
artefactos generados.
La generación incremental de artefactos en MDE hace referencia a la capacidad que
pueden tener los generadores para no tener que reconstruir todos los artefactos cada
vez que se hace una modificación en un modelo, considerándose los modelos como los
elementos clave a partir de los cuales se construyen sistemas software.
182
Hay que tener en cuenta que en la generación incremental de artefactos no hay
intervención manual y nada tiene que ver con los sistemas en los que se mantienen las
modificaciones realizadas manualmente por los desarrolladores, típicamente utilizando
regiones protegidas de código.
Figura 1. Ejemplo de secuencia de generación incremental de artefactos
En la Figura 1 se muestra una secuencia de 3 pasos en la que se ilustra cómo se
comportaría un generador incremental de artefactos. Por simplicidad, vamos a suponer
que cada elemento del diagrama conducirá a la generación de una clase con su mismo
nombre en un lenguaje de programación orientado a objetos. En el caso 1 (caso
inicial) habrá que generar las 4 clases A, B, C y D. Sin embargo, en el caso 2, habría
que eliminar las clases C y D porque ya no están en el diagrama los elementos que las
representan. En el caso 3, sin embargo, habría que añadir una hipotética clase E,
puesto que se ha añadido al diagrama un elemento para representarla, junto con una
modificación producida en la clase B con B'. Pese a que, dependiendo del diseño del lenguaje, podrían existir dependencias entre los elementos que dificultarían la tarea de
generación, se puede observar que siguiendo el esquema mostrado es muy probable
que se ahorre tiempo en la generación de artefactos y que se facilite la modificación de
aplicaciones ya en producción, reduciendo el impacto de los cambios en los modelos.
Nótese que de otra forma, siempre habría que regenerar todos los artefactos con cada
cambio. Manteniendo las diferentes versiones de los modelos se podría incluso
realizar trazabilidad de los cambios realizados, permitiendo saber qué se ha cambiado
y cuándo, siendo ello una poderosa herramienta de mantenimiento y de depuración.
Pese a las ventajas que puede suponer su empleo, la generación incremental de
artefactos es un tema que aún está poco tratado por la literatura científica. Así, el
objetivo de este trabajo es ofrecer una propuesta para lograr una adecuada generación de artefactos utilizando una aproximación incremental. Con el propósito de crear un
generador con dicha característica, se ha desarrollado una herramienta prototípica
basada en tecnologías estándar a partir de la cual se mostrarán las ventajas que
proporcionarán los generadores incrementales de artefactos dirigidos por modelos.
El resto de este trabajo está estructurado de la siguiente forma: en la Sección 2, para
lograr un trabajo auto contenido, presentamos un estado del arte de la generación
incremental de artefactos utilizando el paradigma MDE. En la Sección 3, proponemos
una solución para cumplir con los objetivos de crear un generador incremental MDE.
A B
C D
A B
A B’
E
Caso 1
Caso 2
Caso 3
C D
A B
C D
-
Generación:
Generación:
Generación:
evolución
evolución
B’
E
183
En la Sección 4, describimos las características principales del prototipo creado.
Finalmente, en la Sección 5, mostramos las conclusiones y el futuro trabajo a ser
realizado.
12 Estado de arte
Existen muchas herramientas dirigidas por modelos para generar artefactos. Sin
embargo, se han encontrado carencias en lo referente a la generación incremental. En
la Tabla 1 se listan algunas de las herramientas más conocidas citadas en trabajos
como Palacios et al. [6, 7], indicándose si tienen soporte nativo para realizar
generaciones incrementales. Como se puede observar, actualmente no hay un soporte adecuado para generar artefactos incrementalmente.
Tabla 4. Herramientas de generación de artefactos
Herramienta Web Soporte
incremental
AndroMDA www.andromda.org No
ArcStyler www.arcstyler.com No
ArgoUML www.argouml.tigris.org No
BlueAge www.bluage.com No
Borland Together www.borland.com/products No
BridgePoint www.mentor.com/products No
CodeGenie www.codegenie.se No
EclipseUML www.uml2.org Limitado
EMP www.eclipse.org/modeling No
ExpertCoder www.expertcoder.sourceforge.net No
Jamda www.jamda.sourceforge.net No
Kennedy Carter iUML www.kc.com No
KMF www.cs.kent.ac.uk/projects No
MDE Environment www.mde.sourceforge.net No
Microsoft Oslo www.modelsremixed.com No
ModFact www.modfact.lip6.fr No
objectiF www.microtool.de/objectif Limitado
OlivaNova www.sosyinc.com No
OpenAmeos www.openameos.org No
OptimalJ www.compuware.com Limitado
StarUML www.staruml.sourceforge.net No
uml2php www.uml2php.com No
Visualcase www.visualcase.com No
XCoder www.xcoder.sourceforge.net No
Algunas herramientas ofrecen características de generación incremental de artefactos,
aunque todas ellas de forma limitada.
Un ejemplo es objectiF, que sólo regenera las partes que se tocan en el modelo, y
que tiene carencias como que sólo admite modificaciones en tiempo de diseño y que
no tiene en cuenta que un cambio en una parte del modelo podría afectar a otras
partes.
OptimalJ utiliza el mecanismo denominado active synchronization para asegurar
que cuando un desarrollador cambia un modelo UML, el modelo y los artefactos J2EE
previamente generados se sincronizan. EclipseUML, herramienta propietaria integrada en Eclipse que permite diseñar
sistemas software utilizando varios tipos de diagramas UML. A partir de alguno de los
elementos de los diagramas se genera código fuente Java que permanecerá
sincronizado ante cambios en la vista de código o en la vista del diagrama.
Por otra parte, nuestra propuesta ofrecerá las siguientes características que ninguna
de las herramientas citadas soporta en su totalidad:
184
Separación entre el modelado y la generación de artefactos. En muchas de las
alternativas se combina la vista del modelo con la vista de los artefactos
generados para un entorno de desarrollo específico (p.e., EclipseUML,
OptimalJ). Sin embargo, el usuario de la herramienta de modelado no tiene
por qué querer o necesitar generar artefactos cuando modela su negocio. Por
ejemplo, las herramientas de integración continua [8] hacen una clara distinción entre las fuentes (es decir, los modelos) y la generación de
artefactos, ya que dichas herramientas están situadas lógica y físicamente
entre ellos.
Utilización de metamodelos prefijados. No es conveniente restringirse al
empleo de un único metamodelo sin tener la posibilidad de incorporar otros
(p.e., EclipseUML, OptimalJ).
Generación de artefactos no ligada a ninguna plataforma. Algunas
herramientas únicamente generan artefactos incrementalmente para una
arquitectura y plataforma específica (p.e., EclipseUML, OptimalJ).
Implementación abierta no comercial. Varias herramientas utilizan
tecnologías propietarias comerciales (p.e., EclipseUML).
13 Solución propuesta
Siguiendo el principio de que el reúso del conocimiento y de la experiencia es muy
importante [9], nuestra propuesta está basada en técnicas que ya se están utilizando e investigando en otros ámbitos de MDE. Generar artefactos incrementalmente requiere,
al menos, saber qué cambios se han producido en una versión de un modelo respecto a
una versión anterior, es decir, requiere conocer la diferencia entre las versiones por las
que pasa un modelo [10]. Conocer dichas diferencias no es un proceso sencillo [11] y
comprende tres fases [12] de las que nos resultan útiles las dos primeras (es decir,
cálculo de las diferencias entre modelos y representación de dichas diferencias),
puesto que la visualización de las diferencias en un formato amigable de cara al
usuario no es estrictamente necesaria debido a que los artefactos se generan
automáticamente.
En las próximas líneas se explicará brevemente para qué se utiliza actualmente el
cálculo de la diferencia entre modelos. Posteriormente, se tratarán los algoritmos
actuales para calcular la diferencia entre modelos y las técnicas de representación de las diferencias detectadas por los algoritmos de cálculo. Como se verá, todo ello no
será suficiente para generar incrementalmente artefactos de forma satisfactoria. Por
ese motivo, la última parte de esta sección se destinará a profundizar en el trabajo
realizado para lograrlo.
13.1 Ámbitos de aplicación de la diferencia entre modelos
Dentro de la gran cantidad de investigaciones que, relacionadas con MDE, surgen
cada año, ha aparecido un número considerable de trabajos enfocados a la necesidad
de desarrollar sistemas de control de versiones específicos para modelos (MVCS)
[10]. La idea es suplir las carencias que, respecto a modelos, tienen los sistemas de
control de versiones (MVS) tradicionales [13]. Así, en trabajos como Reiter et al. [14]
o Altmanninger et al. [15] se trata la gestión de fuentes optimista utilizando modelos,
en la que múltiples usuarios trabajan sobre un mismo activo, obligando al sistema a
hacer merging con las diferentes modificaciones realizadas al mismo tiempo por
varios desarrolladores. Por ello, se hace imprescindible el empleo de algoritmos de
comparación de modelos para, posteriormente, representar sus diferencias y/o realizar
uniones y mergins entre ellos [16]. Otros trabajos como Lin et al. [17] han mostrado la
importancia de la representación de las diferencias entre modelos como vía para comprobar la corrección de la especificación de transformaciones entre modelos
realizadas por humanos. De ese modo, si no hay diferencias entre el modelo esperado
tras la transformación y el realmente obtenido, se considerará que las transformaciones
están bien definidas. Garcés et al. [18] utilizan la diferencia entre diferentes versiones
185
de un metamodelo como paso previo para adaptar los modelos que conforman con él.
Adicionalmente, otros trabajos han citado más escenarios en los que calcular la
diferencia entre modelos es útil [19]. Como ejemplos se pueden citar el análisis de la
evolución del software o la detección de inconsistencias. La creciente importancia de
esta materia se ve reflejada en la aparición de herramientas como Sidiff [20], un
framework para construir herramientas centradas en la diferencia entre modelos.
13.2 Cálculo de las diferencias entre modelos
Existen muchos algoritmos para calcular las diferencias entre distintos modelos, que
pueden ser clasificados según diferentes aproximaciones [21].
La aproximación basada en un identificador universal único estático (p.e., [22, 23]),
que perdura durante todo la vida de cada elemento, permite realizar cálculos rápidos
sin necesidad de ningún tipo de configuración. Sin embargo, no puede ser utilizada cuando dos modelos se construyen de forma independiente o cuando las tecnologías
no soportan el mantenimiento de identificadores únicos.
La aproximación basada en una función (p.e., [24]) suple la dificultad de aplicación
del identificador universal único. En su lugar, se utilizan identificadores no estáticos
basados en algún cálculo definido manualmente como el empleo de algún atributo de
los elementos del modelo. De esta forma, se pueden comparar modelos que han sido
construidos de forma independiente.
La aproximación basada en semejanzas (p.e., [25, 26, 27, 28, 29, 30, 31, 32]) trata a
los modelos como grafos en los que buscar semejanzas entre los diferentes elementos.
Típicamente requieren una configuración manual para establecer el peso de cada
elemento del modelo. Por último, la aproximación específica del lenguaje (p.e., [26, 27, 28, 31]) ofrece un
gran rendimiento porque puede tener en cuenta la semántica específica de cada
lenguaje pero tiene que pagar el precio de la dependencia y de la cantidad de código
específico generado en cada caso. Generalmente, los trabajos que están incluidos en
esta categoría también lo están en la basada en semejanzas.
13.3 Representación de las diferencias entre modelos
Para representar las diferencias entre modelos, han surgido diferentes iniciativas
durante los últimos años. Además, en Cicchetti et al. [33] se enumeran una serie de
características que, según los autores, ha de tener cualquier técnica de representación
de diferencias entre modelos. Entre ellas destacan la independencia del metamodelo y
el hecho de estar basada en modelos. Así, la representación no debería estar basada en
un metamodelo específico, permitiendo el empleo metamodelos adaptados a las
necesidades de cada problema. De hecho, una solución comúnmente aceptada es el
empleo de una arquitectura de cuatro capas en la que la capa con mayor nivel de
abstracción es un único meta-metamodelo (p.e., el espacio de modelado MOF [34]
utilizado en la especificación de MDA), a partir del cual se pueden definir diferentes
metamodelos. De hecho, David Frankel afirmó que para el éxito de MDE es
totalmente fundamental el empleo de un metamodelo común [35]. En cuanto a basarse en modelos, un principio también comúnmente aceptado es el de Everything is a
model de Bézivin [36], que junto con el empleo de metamodelos y meta-metamodelos,
permiten trabajar con las numerosísimas herramientas que existen para trabajar bajo el
paradigma MDE utilizando un mayor nivel de abstracción. Por otra parte, otras
características como la compactabilidad, la transformatividad y la componibilidad
pueden ser interesantes y ofrecen grandes posibilidades, pero no son necesarias para la
generación incremental de artefactos.
Scripts de editado
Una de las técnicas más utilizadas para representar las diferencias entre modelos son
los scripts de editado, utilizados en trabajos como Alanen and Porres [22]. Consisten en crear secuencias de operaciones primitivas que describen las modificaciones que ha
sufrido un modelo respecto a otro. Se basa en una secuencia de transformaciones que
permiten representar las diferencias como una ∆.
186
Para describir cómo es la Δ, utilizan 7 transformaciones elementales que han de
cumplir con una serie de restricciones que limitan el empleo de esta técnica. Dichas
transformaciones, que describen los cambios de un modelo respecto a otro, pueden
ser: new, del, set, insert, remove, insertAt o removeAt.
Técnicas de coloreado Otra técnica muy utilizada es la basada en colores. Esta técnica, tratada en trabajos
como Ohst et al. [37], consiste en mostrar gráficamente las diferencias mediante el
empleo de un diagrama. Dicho diagrama contiene las partes comunes del modelo
inicial y del modelo final. Con marcas como colores o símbolos se representan las
partes que han cambiado. Otro ejemplo es el EMF Compare [26], que es un proyecto
ubicado dentro del Eclipse Modeling Framework (EMF) [38] y sirve para representar
y visualizar las diferencias entre dos modelos de forma gráfica.
Figura 2. Trabajo de Cicchetti
El último salto en cuanto a las técnicas para representar la diferencia entre modelos
se da en el trabajo de Cicchetti at al. [33]. La idea es que dados dos modelos que
conforman a un mismo metamodelo, la diferencia entre ambos generará otro modelo
que conforma a otro metamodelo derivado del primero de ellos. Así, los modelos
surgidos de las diferencias serán artefactos de primera clase en el proceso de
generación. Entonces, se captarán las diferencias que hay en el segundo modelo
respecto al primero, ya que se pudieron actualizar, borrar o añadir elementos. En la
Figura 2 se puede observar el proceso descrito extraído del trabajo de Cicchetti et al.
[33].
Gracias al empleo de esta técnica se consigue que la propia diferencia entre los
modelos sea un modelo que conforma a un metamodelo, lo cual permite trabajar con cualquier herramienta o tecnología MDE, como las citadas en Beydeda et al. [39].
13.4 Cálculo basado en una función y representación basada en el modelo de la
diferencia
Los trabajos citados en este artículo, se centran en proporcionar avances en ámbitos de
la ingeniería dirigida por modelos diferentes a la generación de artefactos. Sin
embargo, estudiando las analogías, se puede observar que el procesamiento de las diferencias entre modelos también es interesante de cara a realizar generaciones
incrementales. Así, la generación incremental de artefactos se puede tratar con
técnicas análogas a las utilizadas en los trabajos citados. De hecho, al representar la
diferencia entre un modelo original y otro nuevo modelo realizado posteriormente, se
podría averiguar, en principio, qué partes del modelo han de ser tenidas en cuenta para
generar artefactos, ya que en la mayoría de las ocasiones no será necesario regenerar
todos los artefactos. Esto se debe a que habrá información en el nuevo modelo que
regeneraría exactamente los mismos artefactos que el modelo inicial, con la
consiguiente pérdida de tiempo y recursos.
Respecto al algoritmo de cálculo de las diferencias entre modelos, no tiene especial
importancia en este trabajo puesto que lo único que se requiere es que calcule correctamente las diferencias, pudiendo ser optimizado en el futuro. Además, la
elección depende fundamentalmente de cada problema concreto [21]. Para lograr que
el algoritmo de cálculo sea sencillo, genérico y que no requiera grandes esfuerzos de
Metamodelo origen
Meta-
metamodelo
Metamodelo
(MM)
Metamodelo
destino
Realidad
M3
M2
M1
M0
Metamodelo
derivado (DMM)
Modelo de la
diferencia (DM)
Diferencias
detectadas
Transformación
MM a DMM
Elemento del
modelo
(Metaclase)
Added
Deleted
Updated
187
configuración, se ha utilizado un algoritmo basado en una función que depende
únicamente de una propiedad de los elementos del modelo.
Por otra parte, para no perder la esencia y las ventajas del uso de una propuesta
basada en modelos, la Figura 3 muestra la arquitectura que hemos propuesto
basándonos en la representación de las diferencias entre modelos de Cicchetti et al.
[33]. Se muestran los artefactos utilizados como entrada del proceso, los artefactos obtenidos en la salida y las herramientas que se han desarrollado durante este trabajo
para llevarlo a la práctica en el prototipo construido. La idea, cuando se pretenden
generar artefactos, es utilizar siempre las dos últimas versiones del modelo del sistema
que se hayan introducido previamente en algún tipo de repositorio como consecuencia
de las acciones de los desarrolladores. Dicho repositorio, por su parte, podría estar
gobernado por un MVCS y hacer uso de las técnicas para conocer las diferencias entre
modelos expuestas en este y en otros trabajos. Un paso fundamental es extender el
metamodelo original, creando uno con las nuevas metaclases. Sin embargo, el modelo
de la diferencia sufre una variación con respecto a la propuesta original debido a que
si una modificación en un elemento provoca que se tengan que regenerar artefactos
derivados de otro elemento que no ha sido alterado, dicho elemento no estará en el
modelo de la diferencia y provocará inconsistencias. La solución planteada es, por lo tanto, unificar el modelo de la diferencia con las partes de la última versión del
modelo que no han sido modificadas, dando lugar a la diferencia unificada. Para
facilitar el empleo de las tecnologías actuales para generar artefactos, se puede afirmar
que trabajamos en todo momento con una diferencia independiente del modelo [40], la
cual es auto contenida, es decir, los cambios se describen sin hacer referencia a otros
modelos.
Figura 3. Arquitectura propuesta
La Tabla 2 muestra una comparación de todas las técnicas mencionadas con las
características que podría tener cualquier técnica de representación de diferencias
entre modelos [33]. A las ya comentadas, se le ha añadido la propiedad generativa,
entendiéndose como la capacidad de generar artefactos de menor nivel de abstracción
[41, 42] a partir de cada técnica. Pese a que con el modelo de la diferencia se podrían
generar artefactos en muchos casos, ya que se basa en metamodelos y modelos, con la
diferencia unificada se podrán tratar todas las posibilidades debido a que se trabaja
con todas las alternativas posibles. Dicha capacidad acarrea costes, perdiéndose varias
propiedades. No obstante, dichas propiedades no son importantes en la generación
incremental de artefactos. El empleo de tecnologías basadas en metamodelo y modelos
son suficientes para posibilitar el empleo de incontables técnicas y herramientas que
existen para trabajar bajo el paradigma MDE.
MetamodeloMetamodelo
extendido
Modelo B
Diferencia
unificada
MetamodelExt
UnifiedDiffArtefactos
generadosMotor del
generador
Lleva aArtefactos
de salida
Herramienta
creada Conforma
con
Artefactos
de entrada
Motor del
repositorio
RepositoryRepository
Modelo A
Elemento
del modelo
(Metaclase)
Added
Deleted
Changed
Unchanged
Por cada una de las metaclases que pueden ser modificadas, hemos
añadido cuatro nuevas metaclases en el metamodelo extendido
188
Tabla 5. Técnicas para representar las diferencias entre modelos
Propiedad Scripts de
editado
Coloreado Modelo de la
diferencia
Diferencia
unificada
Basada en
modelos SI SI SI
Independencia
del metamodelo SI SI SI
Generativa SI Compacta SI Capacidad de
composición SI SI
Transformativa SI
En la Figura 4 se muestra un ejemplo basado en el trabajo de Cicchetti et al. [43],
en el que se puede observar la diferencia entre dos modelos de redes de Petri [44] que
conforman a un mismo metamodelo. En la parte superior se puede ver la diferencia del
modelo planteada en el trabajo original. En la parte inferior están los elementos
añadidos para que dicha diferencia pueda ser considerada una diferencia unificada.
Así, se logra un nuevo modelo, instancia de un metamodelo derivado del inicial, en el
que se contiene toda la información necesaria para actualizar, añadir, eliminar o
mantener cualquiera de los artefactos implicados en el sistema. En este ejemplo, las diferencias ya afectan a casi todo el modelo por lo que habría que añadir pocos
elementos. Sin embargo, en casos reales con modelos mucho mayores es muy
probable que las diferencias afecten a un fragmento muy pequeño del modelo.
Figura 4. Representación de la diferencia unificada (ejemplo)
14 Prototipo
En lugar de desarrollar desde cero una herramienta dirigida por modelos de generación
incremental de artefactos, se ha decidido utilizar y adaptar las herramientas existentes,
en concreto algunas de las provistas en el Eclipse Modeling Project (EMP)52 [45], que
anteriormente estaban incluidas en openArchitectureWare (oAW) [46]. Las razones
52 http://www.eclipse.org/legal/epl-v10.html
P1
P3
P2
P4
Modelo original
15 28
29 30
P1
P3
P2
Modelo destino
1528
4035
T1
T1
T2
Name = P4
:DeletedPlace
Weight = 29
:ChangedPlaceToTransition
Weight = 40
:PlaceToTransition
Name = T2
:AddedTransition
Weight = 35
:AddedTransitionToPlace
Name = T1
:Transition
Name = P3
:Place
Name = P2
:Place
updatedElement
target source source
target
source
target
Name = P1
:Place
Weight = 15
:PlaceToTransition
Weight = 28
:TransitionToPlacesourcesource
targettarget
Weight = 30
:DeletedTransitionToPlace target
source
189
principales son, sobre todo, que se trata de las herramientas más próximas a los
estándares que hay para modelos y que cumplen con la Eclipse Public Licence . En la
Figura 5 pueden verse los cuatro pasosa principales que hemos realizado para generar
artefactos de manera incremental.
Figura 5. Pasos para desarrollar la generación de artefactos incremental
14.1 Crear el metamodelo Ecore
Dado que algunas iniciativas MDE como MDA o TALISMAN MDE (TMDE) [47]
abogan por la generación de artefactos a partir de un meta-metamodelo basado en
estándares, es decir MOF, y la implementación de MOF más comúnmente aceptada es
Ecore53, que abarca al subconjunto Essential MOF (EMOF) [48], será necesario
diseñar un metamodelo Ecore como primer paso para la generación incremental.
Dicho metamodelo dependerá del Lenguaje Específico del Dominio (DSL) [49] que se utilice para cada caso concreto de aplicación y puede ser construido directamente
mediante UML o mediante una transformación de un DSL de mayor nivel de
abstracción (p.e., DSL Tools [50]). Para lograr dicha transformación, se pueden
utilizar algunas propuestas como la de Bézivin et al. [51, 52]. Una vez que el
metamodelo está creado, ya se puede utilizar cualquier herramienta que soporte Ecore
para crear y manipular modelos que conformen con el metamodelo.
14.2 Extender el metamodelo
La extensión del metamodelo original se realiza en base al metamodelo Ecore. Dicha
extensión, se hace cuando se desarrolla el metamodelo original, no siendo parte del
proceso de generación de las aplicaciones y siendo necesario una única vez para cada
familia de productos [¡Error! No se encuentra el origen de la referencia.]. Para
extender el metamodelo y obtener el metamodelo derivado o extendido (Figura 3) se
ha creado una herramienta software que posibilita, a partir de un metamodelo Ecore,
53 Ecore es el meta-metamodelo incorporado en el EMF, núcleo del EMP.
MetamodelDiffParsear nuevo
modelo
Limpiar carpetas
de generación
Metamodelo
Ecore Extendido
Extender el
metamodelo
Calcular la diferencia
unificada
Generar artefactos en
función de la
diferencia unificada
Crear metamodelo
Ecore
FileRename
UnifiedDiff
Guardar el nuevo
modelo
Diferencia
unificada
Parsear la
diferencia
unificada
Limpiar carpetas
de generación
Artefactos finales
generados
Usar plantillas de
generación de
artefactos
Pasos principales
Software expresamente creado para
poder cumplir con los objetivos
Subpasos realizados sin desarrollar
nuevo software
Salida obtenida al finalizar paso
Metamodelo
Ecore
190
crear su metamodelo extendido, en el que para cada metaclase original se añaden 4
nuevas metaclases (añadido, borrado, cambiado y no cambiado), que heredan de la
original. Así, se permite representar la diferencia de dos modelos en base al
metamodelo extendido. El cálculo del metamodelo extendido se realiza utilizando una
herramienta que hemos denominado MetamodelExt, herramienta que forma parte de la
extensión para Modeling Workflow Engine (MWE)54 que hemos desarrollado llamada MWE.Extends, la cual es un plugin que ofrece el soporte necesario para generar
artefactos incrementalmente.
Figura 6. Extensión del metamodelo original
En la Figura 6 puede verse el archivo para MWE que se utiliza para guiar el
proceso de extensión del metamodelo original.
14.3 Calcular la diferencia unificada
Este paso, a diferencia de los anteriores, se lleva a cabo siempre que se realiza la
generación de artefactos. Ello es debido a que el objetivo es utilizar como base las
diferencias de un modelo respecto al último modelo a partir del cual se había realizado
la generación. De esa forma, se podrá ir gestionando la evolución de los modelos y, al
mismo tiempo, la evolución de los artefactos que se generan a partir de los mismos. Para calcular la diferencia unificada, MWE.Extends ofrece el siguiente soporte:
Repository. Se encarga de simular el comportamiento de un repositorio.
Permite realizar pruebas de forma fluida y podría ser sustituido por un
sistema de control de versiones para modelos que ofrezca mayores
características en cualquier momento.
UnifiedDiff. Permite calcular la diferencia entre dos modelos que conforman
a un mismo metamodelo, generando así otro modelo que conforma a otro
metamodelo derivado del primero de ellos (el metamodelo extendido se crea
con la herramienta denominada MetamodelExt). Además, incluye todos los
elementos que permanecen intactos en la última versión del modelo para
permitir generar artefactos en función de ellos si así fuera necesario. Los
modelos surgidos de las diferencias serán artefactos de primera clase en el
proceso de generación, permitiendo captar en un único archivo a todos los
elementos que se han actualizado, borrado, añadido o que permanecen
intactos. Así, se consigue tener toda la información necesaria unificada en un
único modelo, favoreciendo el empleo de las tecnologías actuales para
54 MWE es una herramienta del Eclipse Modeling Project, que originalmente era parte de oAW.
Tiene un objetivo similar a otras herramientas como Ant o MsBuild pero está especialmente
orientada a trabajar con modelos.
ENTRADA PARA MODEL WORKFLOW ENGINE
Se lee el metamodelo original
Se calcula el metamodelo extendido
Se guarda el metamodelo extendido
191
trabajar con herramientas tales como repositorios, algoritmos de
comparación, plantillas de generación, etc.
14.4 Generar artefactos en función de la diferencia unificada
Una vez se tiene la diferencia unificada, el último paso es generar los artefactos en
base al metamodelo extendido. Para ello, hemos utilizado plantillas Xpand [53], que
forman parte del EMP y tienen soporte para el empleo de interesantes características
como polimorfismo. Así, por ejemplo, se permite que una metaclase y la metaclase
añadida que hereda de ella generen los mismos artefactos sin escribir ni una sólo línea
de código extra en la plantilla.
Figura 7. Generación incremental de artefactos
En la Figura 7 puede verse el archivo MWE que se utilizará para guiar la
generación incremental de artefactos.
15 Conclusiones y trabajos futuros
En este trabajo se ha presentado una propuesta para generar artefactos de forma
incremental, de forma que se optimizan los recursos computacionales, se minimiza el
impacto sobre aplicaciones que ya podrían estar en producción y se permite la
realización de trazabilidad a lo largo del ciclo de vida de las aplicaciones. Dichas
características son beneficiosas y ofrecen un salto cualitativo en cuanto a la generación
de artefactos utilizando el paradigma de desarrollo MDE.
El futuro trabajo pasará por seguir madurando la generación incremental de
artefactos. Un aspecto interesante es la relación entre el diseño del DSL y los artefactos que se generan. Convendría buscar relaciones lo más directas posible para
evitar dependencias que provoquen que una modificación en un elemento del modelo
haga que se tengan que regenerar artefactos a partir de otro elemento del modelo que
no ha sufrido ninguna modificación. Interesante también, es la aplicación del trabajo
aquí propuesto en los entornos de desarrollo en los que se sincroniza la vista del
modelo con la vista del código. Aunque muchas herramientas ofrecen soporte de
sincronización, dicha sincronización suele estar ligada a un entorno de desarrollo, a un
metamodelo o a una arquitectura determinada, no empleándose una técnica genérica
como la expuesta en este trabajo.
Referencias
1. S. Kent, “Model driven engineering,” in IFM ’02: Proceedings of the Third International Conference on Integrated Formal Methods. London, UK: Springer-Verlag, 2002, pp. 286–298. [Online]. Available: http://156.35.98.129/MDA-Oviedo3/-doc/ifm02paper.pdf
ENTRADA PARA MODEL WORKFLOW ENGINE
Se parsea la diferencia
unificada
Se generan los artefactos
incrementalmente
Se prepara la carpeta destino
192
2. P. Clements and L. Northrop, Software Product Lines - Practice and Patterns. Addison-Wesley, 2002.
3. E. Seidewitz, “What models mean,” IEEE Software, vol. 20, no. 5, pp. 26–32, 2003. 4. M. Völter and T. Stahl, Model-Driven Software Development: Technology,
Engineering, Management. John Wiley & Sons, June 2006.
5. T. Mens, M. Wermelinger, S. Ducasse, S. Demeyer, R. Hirschfeld, and M. Jazayeri, “Challenges in software evolution,” in Proc. 8th International Workshop on Principles of Software Evolution. IEEE, September 2005, pp. 13–22. [Online]. Available: http://oro.open.ac.uk/1174
6. E. Palacios-González, H. Fernández-Fernández, V. Garcá-Dáz, B. C. P. G-Bustelo, and J. M. C. Lovelle, “A review of intelligent software development tools,” in IC-AI, H. R. Arabnia and Y. Mun, Eds. CSREA Press, 2008, pp. 585–590.
7. E. Palacios-González, H. Fernández-Fernández, V. Garcá-Dáz, B. C. P. G-Bustelo,
J. M. C. Lovelle, and O. S. Martínez, “General purpose mde tools,” International Journal of Artificial Intelligence and Interactive Multimedia, vol. 1, no. 1, pp. 72–75, 2008.
8. J. D. Herbsleb and R. E. Grinter, “Splitting the organization and integrating the code: Conway’s law revisited,” in ICSE ’99: Proceedings of the 21st international conference on Software engineering. New York, NY, USA: ACM, 1999, pp. 85–95.
9. G. Caldiera and V. R. Basili, “Identifying and qualifying reusable software components,” Computer, vol. 24, no. 2, pp. 61–70, 1991.
10. H. L. R. Oliveira, L. G. P. Murta, and C. Werner, “Odyssey-vcs: a flexible version control system for uml model elements,” in SCM. ACM, 2005, pp. 1–16.
11. R. C. Read and D. G. Cornell, “The graph isomorphism disease,” Journal of Graph Theory, vol. 1, pp. 339–363, 1977.
12. C. Brun and A. Pierantonio, “Model differences in the eclipse modeling framework,” UPGRADE, The European Journal for the Informatics Professional, vol. 9, no. 2, pp. 29–34, April 2008.
13. W. F. Tichy, “Rcs - a system for version control,” Softw., Pract. Exper., vol. 15, no. 7,
pp. 637–654, 1985. 14. T. Reiter, K. Altmanninger, A. Bergmayr, and G. Kotsis, “Models in conflict -
detection of semantic conflicts in model-based development,” in Proceedings of 3rd International Workshop on Model-Driven Enterprise Information Systems (MDEIS-2007), in conjuction with 9th International Conference on Enterprise Information Systems, 2007.
15. K. Altmanninger, G. Kappel, A. Kusel, W. Retschitzegger, M. Seidl, W. Schwinger, and M. Wimmer, “Amor - towards adaptable model versioning,” in 1st Int. Workshop on Model Co-Evolution and Consistency Management, in conjunction with
Models’08, 2008. 16. L. Bendix and P. Emanuelsson, “Diff and merge support for model based
development,” in CVSM ’08: Proceedings of the 2008 international workshop on Comparison and versioning of software models. New York, NY, USA: ACM, 2008, pp. 31–34.
17. Y. Lin, J. Zhang, and J. Gray, “Model comparison: A key challenge for transformation testing and version control in model driven software development,” in Control in Model Driven Software Development. OOPSLA/GPCE: Best Practices for Model-
Driven Software Development, 2004. 18. K. Garcés, F. Jouault, P. Cointe, and J. Bézivin, “Managing model adaptation by
precise detection of metamodel changes,” in Model Driven Architecture - Foundations and Applications, 5th European Conference, ECMDA-FA 2009, Enschede, The Netherlands, June 23-26, 2009. Proceedings, ser. Lecture Notes in Computer Science, R. F. Paige, A. Hartman, and A. Rensink, Eds., vol. 5562. Springer, 2009, pp. 34–49.
19. P. Selonen, “A review of uml model comparison approaches,” in Proceedings of Nordic Workshop on Model Driven Engineering, August 2007.
20. M. Schmidt and T. Gloetzner, “Constructing difference tools for models using the sidiff framework,” in ICSE Companion ’08: Companion of the 30th international conference on Software engineering. New York, NY, USA: ACM, 2008, pp. 947–948.
21. D. S. Kolovos, D. Di Ruscio, A. Pierantonio, and R. F. Paige, “Different models for model matching: An analysis of approaches to support model differencing,” in CVSM ’09: Proceedings of the 2009 ICSE Workshop on Comparison and Versioning of Software Models. Washington, DC, USA: IEEE Computer Society, 2009, pp. 1–6.
22. M. Alanen and I. Porres, “Difference and union of models,” in Proceedings of UML
2003, 2003, pp. 2–17. 23. F. Vernadat, C. Percebois, P. Farail, R. Vingerhoeds, A. Rossignol, J. P. Talpin, and
D. Chemouil, “The topcased project - a toolkit in open-source for critical applications and system development,” in Data Systems In Aerospace (DASIA), Berlin, Germany, 22/05/2006-25/05/2006. European Space Agency (ESA Publications), 2006.
193
24. R. Reddy and R. France, “Model composition - a signature-based approach,” in in "Aspect Oriented Modeling (AOM) Workshop, Montego, 2005.
25. Y. Lin, J. Gray, and F. Jouault, “Dsmdiff: A differentiation tool for domain-specific models,” European Journal of Information Systems,, vol. 16, pp. 349–361, 2007.
26. A. Toulmé, “Presentation of emf compare utility,” in EclipseCon, 2007.
27. D. S. Kolovos, “Establishing correspondences between models with the epsilon comparison language,” in ECMDA-FA ’09: Proceedings of the 5th European Conference on Model Driven Architecture - Foundations and Applications. Berlin, Heidelberg: Springer-Verlag, 2009, pp. 146–157.
28. S. Melnik, H. Garcia-molina, and E. Rahm, “Similarity flooding: A versatile graph matching algorithm,” in 18th International Conference on Data Engineering, 2002, pp. 117–128.
29. S. Nejati, M. Sabetzadeh, M. Chechik, S. Easterbrook, and P. Zave, “Matching and
merging of statecharts specifications,” in ICSE ’07: Proceedings of the 29th international conference on Software Engineering. Washington, DC, USA: IEEE Computer Society, 2007, pp. 54–64.
30. J. E. Rivera and A. Vallecillo, “Representing and operating with model differences,” in TOOLS EUROPE 2008, ser. LNBIP, vol. 11. Springer, 2008, pp. 141–160. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-69824-1_9
31. C. Treude, S. Berlik, S. Wenzel, and U. Kelter, “Difference computation of large models,” in ESEC-FSE ’07: Proceedings of the the 6th joint meeting of the European
software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering. New York, NY, USA: ACM, 2007, pp. 295–304.
32. Z. Xing and E. Stroulia, “Umldiff: an algorithm for object-oriented design differencing,” in ASE ’05: Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering. New York, NY, USA: ACM, 2005, pp. 54–65.
33. A. Cicchetti, D. D. Ruscio, and A. Pierantonio, “A metamodel independent approach to difference representation,” Journal of Object Technology, vol. 6, no. 9, pp. 165–
185, 2007. 34. D. Djuric, “The tao of modeling spaces,” Journal of Object Technology, vol. 5, pp.
125–147, 2006. 35. D. S. Frankel, Model Driven Architecture: Applying MDA to Enterprise Computing.
John Wiley & Sons, 2003. [Online]. Available: http://156.35.98.129/MDA-Oviedo3/-doc/Wiley - Model Driven Architecture Applying Mda To Enterprise Computing (2003).pdf
36. J. Bézivin, “On the unification power of models,” in Software and System Modeling, vol. 4, no. 2, 2005. [Online]. Available: http://www.sciences.univ-nantes.fr/lina/atl/-
www/papers/OnTheUnificationPowerOfModels.pdf 37. D. Ohst, M. Welle, and U. Kelter, “Differences between versions of uml diagrams,” in
ESEC/FSE, vol. 28, no. 5. New York, NY, USA: ACM, 2003, pp. 227–236. 38. F. Budinsky, S. A. Brodsky, and E. Merks, Eclipse Modeling Framework. Pearson
Education, 2003. 39. S. Beydeda, M. Book, and V. Gruhn, Eds., Model-Driven Software Development.
Springer, 2005. 40. P. Konemann, “Model-independent differences,” in CVSM ’09: Proceedings of the
2009 ICSE Workshop on Comparison and Versioning of Software Models. Washington, DC, USA: IEEE Computer Society, 2009, pp. 37–42.
41. M. Völter, “A catalog of patterns for program generation,” in EuroPloP2003, Eighth European Conference on Pattern Languages of Programs, 2003.
42. S. Kelly and J.-P. Tolvanen, Domain-Specific Modeling: Enabling full code generation. John Wiley & Sons, 2008.
43. A. Cicchetti, D. D. Ruscio, and A. Pierantonio, “Applying a difference representation approach to the petrinet metamodel,” Dipartimento di Informatica, Università degli
Studi dell’Aquila, Tech. Rep., 2007. 44. J. L. Peterson, Petri Net Theory and the Modeling of Systems. Upper Saddle River, NJ,
USA: Prentice Hall PTR, 1981. 45. R. C. Gronback, Eclipse Modeling Project: A Domain-specific Language Toolkit: A
Domain-Specific Language (DSL) Toolkit, 1st ed. Addison-Wesley Educational Publishers Inc, March 2009.
46. A. Haase, M. Völter, S. Efftinge, and B. Kolb, “Introduction to openarchitectureware 4.1.2,” in Proceedings of TOOLS EUROPE 2007 - Objects, Models, Components,
Patterns,, July 2007. 47. V. García-Díaz, H. Fernández-Fernández, E. Palacios-González, B. C. P. G-Bustelo,
O. Sanjuan-Martínez, and J. M. C. Lovelle, “Talisman mde. mixing mde principles,” Journal of Systems and Software, vol. 83, no. 7, pp. 1179–1191, 2010.
194
48. OMG, “Meta object facility 2.0,” OMG, Tech. Rep., 2005, http://www.omg.org/mof/. [Online]. Available: http://www.omg.org/mof/
49. A. van Deursen, P. Klint, and J. Visser, “Domain-specific languages: an annotated bibliography,” SIGPLAN Not., vol. 35, no. 6, pp. 26–36, 2000.
50. S. Cook, G. Jones, S. Kent, and A. C. Wills, Domain-Specific Development with
Visual Studio DSL Tools. Addison-Wesley, 2007. 51. J. Bézivin, G. Hillairet, F. Jouault, I. Kurtev, and W. Piers, “Bridging dsl tools and the
eclipse modeling framework,” in OOPSLA’05: Proceedings of the International Workshop on Software Factories, 2005.
52. J. Bézivin, C. Brunette, R. Chevrel, F. Jouault, and I. Kurtev, “Bridging the generic modeling environment and the eclipse modeling framework,” in OOPSLA’05: Proceedings of the International Workshop on Software Factories, 2005.
53. S. Efftinge and C. Kadura, OpenArchitectureWare 4.1 Xpand Language Reference,
openArchitectureWare, 2006. [Online]. Available: http://-www.openarchitectureware.org/