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, 1jordansoy@gmail.com, 2luis.joyanes@upsam.net, 3cemontenegrom@udistrital.edu.co

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/