Universidad Rey Juan Carlos

Escuela Tcnica Superior de Ingeniera Informtica Departamento de Lenguajes y Sistemas Informticos II

Incorporando la Gestin de la Trazabilidad en un entorno de Desarrollo de Transformaciones de Modelos Dirigido por Modelos

Autor: lvaro Jimnez Rielo Director de Tesis: Juan Manuel Vara Mesa Co-Directora de Tesis: Vernica Andrea Bollati

Mstoles, Marzo 2012

El Dr. D. Juan Manuel Vara Mesa, Profesor de Universidad del Departamento de Lenguajes y Sistemas Informticos II de la Universidad Rey Juan Carlos de Madrid y la Dra. D Vernica Andrea Bollati, Profesora de Universidad del Departamento de Lenguajes y Sistemas Informticos II de la Universidad Rey Juan Carlos de Madrid, director y codirectora, respectivamente, de la Tesis Doctoral: Incorporando la Gestin de la Trazabilidad en un entorno de Desarrollo de Transformaciones de Modelos Dirigido por Modelos realizada por el doctorando D. lvaro Jimnez Rielo, HACEN CONSTAR QUE: Esta tesis doctoral rene los requisitos para su defensa y aprobacin En Madrid, a 5 de Marzo de 2012

Fdo.: Juan Manuel Vara Mesa

Fdo: Vernica Andrea Bollati

Dadme un punto de apoyo y mover el mundo.

Arqumedes

Si todo lo que tiene es un martillo, todo lo que vea le parecer un clavo.

Observacin de Baruch (Leyes de Murphy)

Resumen
La IEEE define la trazabilidad como: "El grado de relacin que puede establecerse entre dos o ms productos de un proceso de desarrollo, especialmente productos que tienen relaciones predecesor-sucesor o maestro-subordinado con otro producto." Una correcta gestin de la trazabilidad permitira conocer cmo evolucionan los elementos del sistema a lo largo del proceso de desarrollo y cmo se relacionan los diferentes elementos entre s. Este tipo de informacin puede utilizarse en diferentes actividades, como el anlisis del impacto, la toma de decisiones de diseo y en general, cualquier actividad relacionada con el mantenimiento del sistema. As, sera deseable que cualquier metodologa de desarrollo software proporcionara un soporte adecuado para la gestin de la trazabilidad. Sin embargo, aunque esta necesidad ha sido reconocida histricamente, lo cierto es que hasta la fecha, son pocas las propuestas metodolgicas y tecnolgicas que la soportan. Por otro lado, la Ingeniera Dirigida por Modelos (MDE, Model-Driven Engineering) es el ltimo paso en la tendencia a elevar el nivel de abstraccin al que se disea y construye el software: del ensamblador pasamos a los lenguajes estructurados, que dieron lugar a la orientacin a objetos, etc. Los principios fundamentales de MDE son potenciar el rol de los modelos a lo largo de todo el ciclo de vida y potenciar el nivel de automatizacin en el proceso de desarrollo. La pieza que une estos dos principios son las transformaciones de modelos. En general, las transformaciones se utilizan para ir refinando la especificacin del sistema, recogida en un conjunto de modelos de alto nivel, hasta obtener un nivel de detalle suficiente para abordar la generacin automtica del cdigo que implementa el sistema. No obstante, tambin pueden utilizarse para cualquier otra tarea relacionada con el procesamiento de modelos, como la validacin, o el merging. As, el papel clave que juegan las transformaciones a lo largo del proceso de desarrollo proporciona un nuevo escenario en el que abordar la gestin de la trazabilidad de una forma mucho ms eficiente y completa. La idea de fondo es simple e intuitiva: el conjunto de reglas que componen una transformacin representan las relaciones que deben darse entre los elementos de los modelos origen y los elementos de los modelos destino implicados en dicha transformacin. Por tanto, se pueden utilizar esas relaciones para identificar y crear las trazas entre los diferentes elementos del sistema, que habrn sido
VII

producidos como resultado de ejecutar diferentes transformaciones a lo largo del proceso de desarrollo. Por otro lado, dado que las transformaciones son otro artefacto software, parece lgico aplicar los principios de MDE a su desarrollo, es decir, concebirlas como un producto que podemos obtener a partir de refinamientos sucesivos desde una especificacin de alto nivel. En este caso, dicha especificacin no ser ms que el conjunto de relaciones que deberan darse entre los elementos de los modelos origen y destino. Combinando estas ideas, la presente tesis doctoral aborda la construccin de un entorno de desarrollo de transformaciones de modelos dirigido por modelos que incorporan generacin de trazas. Dicho entorno parte de una especificacin de alto nivel de las relaciones entre los elementos de los modelos origen y de los modelos destino, que es refinada automticamente hasta llegar a un modelo de transformacin que puede ser serializado en el cdigo que implementa la transformacin. La ejecucin de la transformacin generada producir, adems del modelo/s destino, el modelo de trazas que recoge las relaciones entre los artefactos origen y los artefactos destino.

VIII

Agradecimientos
En primer lugar quiero agradecer a mis directores de tesis, Juancho y Vero, toda la confianza que habis depositado en m desde los primeros momentos, mucho antes del comienzo de esta tesis. Desde que comenc a trabajar con vosotros, siempre habis apostado por m y me he sentido muy valorado tanto personal como profesionalmente. Si no hubiera sido por eso, creo que en algn momento hubiera tirado la toalla. Este agradecimiento tambin quiero extenderlo a Esperanza, que de la misma forma, siempre me ha mostrado su confianza en m. Y gracias a los tres por la presin y apretarme las tuercas en ciertos momentos, sino no s cundo hubiera acabado esto. Tambin quiero dar las gracias al resto de mis compaeros del Grupo Kybele. De todos ellos, quisiera mencionar de forma especial a varias personas: Valeria, t fuiste quin me contrat por primera vez como becario cuando todava estaba en 3 y sin aquel adelante, dudo que hoy estuviera pensando en acabar esta tesis. Tambin quiero agradecerte que estuvieras presente en mis tribunales de PFC y TFM y los sabios comentarios que me diste en ambas ocasiones. A Jenifer, por toda la ayuda prestada a lo largo de toda la realizacin de esta tesis y sus maravillosos diseos para los iconos de la herramienta. A Ivn, Feliu y David, todos futuros doctores, animo chicos! Cuando os queris dar cuenta, estaris como yo: escribiendo el final de vuestras tesis e intentando no olvidaros de nadie en los agradecimientos. Ivn, gracias por todas esas charlas sobre trazabilidad que tanto me han ayudado a levantar la cabeza del papel y ver la realidad. A mis amigos de toda la vida, esos chicos del Amigos del Grano de Caf: Ral, Diego, Samu, Juez, Tena, Rubn, Hctor, Alex, Adrin (para m siempre sers Adri) y los jeques: Jess y Fran (para ti tendra que escribir una tesis entera, hermano! Que desde los 6 aos, fjate si hay cosas que agradecer). La mayora siempre hemos estado en momentos importantes de la vida del resto: desde los primeros pelos de la barba y las primeras noches de fiesta hasta prepararnos selectividad y entrar en la universidad o conducir por primera vez; y ahora algunos hasta con casa propia; as que por supuesto, no podais faltarme en este momento importante en mi vida. A mis padrespor todo. Por ensearme todas esas cosas de la vida que no se ensean en los colegios o en las universidades: gracias por ensearme a valorar lo gratificante que es conseguir las cosas por uno mismo o que mis xitos y fracasos en la vida, los disfrutar o sufrir yo mismo. Toda la educacin que he recibido de vosotros ha hecho de m la persona que soy hoy. De forma individual,
IX

a mi padre, Antonio, quiero agradecerle todo el esfuerzo que ha hecho a lo largo de estos aos para intentar darme TODO lo que he necesitado e incluso, a veces cosas que ni siquiera necesitaba pero venan muy bien (aunque no lo creas, lo valoro mucho ms de lo que piensas) as como su papel de poli malo que no me dejaba salirme del camino correcto. A mi madre, Carmen, por ser mi Pepito Grillo, la voz de mi conciencia. Siempre has sabido estar en tu sitio, darme los consejos adecuados y convencerme como nadie de lo equivocado que poda llegar a estar en algunos momentos. Definitivamente, solo puedo decir cosas buenas de ti. A mi hermana, M Carmen, por ser en muchos momentos mi segunda madre y en otros muchos, mi mejor consejera y mi mejor amiga (recuerdas los sbados por la maana haciendo el idiota por casa? Que grandes momentos!). De forma especial quiero dedicarle esta tesis a mi sobrina Andrea, que aunque quizs todava no sepa valorar el esfuerzo que esto supone, si ha sabido entender que su to tena que trabajar y que no le poda dedicar todo el tiempo que hubiera querido. A mi cuado, Cristbal, quiero agradecerle que siempre est ah para lo que haga falta y por ser un to tan autntico. Y tirando de tpicos se dice que detrs de cada hombre, hay una gran mujer. Yo adems quiero aadir que: detrs de cada doctorando, hay una gran sufridora. GRACIAS, Helena. A pesar (te lo promet) de que nunca te hizo ilusin que me embarcara en esta aventura y siendo la persona que ms ha sufrido mis agobios o faltas de tiempo, desde el primer momento me has apoyado en mis decisiones y has sabido darme nimos para conseguirlo, sobre todo en estos ltimos momentos. Adems, tengo que reconocer, como ya te he dicho en muchas ocasiones, que si no te hubiera conocido no s qu hubiera sido de m ;-) . Quizs, a estas alturas en lugar de pensar en terminar la tesis, estara pensando en acabar la carrera. En los ltimos aos has sido mi apoyo, mi referencia y una de mis mayores motivaciones para conseguir todos los retos a los que me he enfrentado. No quiero entrar en terreno personal, pero espero poder tener, a partir de ahora, ms tiempo para ti. Por ltimo, quiero agradecerte a ti, lector, que ests empleando tu tiempo en leer estas lneas. Gracias a todos1, lvaro
1

La foto de la portada se encuentra publicada en http://juanluisvera.blogspot.com/2011/11/el-camino-

tambien-deja-huella.html bajo licencia CC (http://creativecommons.org/licenses/by-nc/3.0/).

ndice
1. INTRODUCCIN ......................................................................................... 25 1.1 1.2 1.3 Planteamiento del Problema .............................................................. 25 Hiptesis y Objetivos......................................................................... 30 Marco de Investigacin ..................................................................... 32 Proyectos de Investigacin ........................................................ 34

1.3.1 1.4 2.

Estructura de la Tesis ......................................................................... 36

MTODO DE TRABAJO .............................................................................. 41 2.1 Mtodo de Investigacin ................................................................... 41 Etapa de Resolucin y Validacin ............................................. 43

2.1.1 2.2

Mtodo de Identificacin del Cuerpo de Conocimiento .................... 45 Proceso para guiar la Revisin Sistemtica .............................. 46

2.2.1 2.3 2.4 3.

Mtodo de Desarrollo ........................................................................ 48 Mtodo de Validacin ....................................................................... 51

ESTADO DEL ARTE .................................................................................... 57 3.1 Conceptos Previos ............................................................................. 58 Modelado ................................................................................... 58 Transformaciones de Modelos ................................................... 59 Ingeniera Dirigida por Modelos ............................................... 61 Desarrollo de Software Dirigido por Modelos .......................... 62 Arquitectura Dirigida por Modelos ........................................... 63 Trazabilidad ............................................................................... 64 para el Desarrollo Dirigido por Modelos de

3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.2

Propuestas

Transformaciones de Modelos ........................................................... 66 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 Cuestiones de Investigacin ....................................................... 67 Criterios de Evaluacin ............................................................. 68 Extraccin de Datos ................................................................... 70 Anlisis de las propuestas .......................................................... 71 Discusin .................................................................................... 86
XI

3.3

Propuestas para la Gestin de la Trazabilidad a partir de Transformaciones de Modelos ........................................................... 93

3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 4.

Cuestiones de Investigacin ....................................................... 93 Criterios de Evaluacin ............................................................. 95 Extraccin de Datos ................................................................... 96 Anlisis de las propuestas .......................................................... 97 Discusin .................................................................................. 117

PROPUESTA METODOLGICA ................................................................. 129 4.1 Un Proceso de Desarrollo de Transformaciones que soportan la Generacin de Trazas ...................................................................... 131 4.2 Especificacin de Metamodelos ...................................................... 134 Metamodelo de Trazabilidad ................................................... 135 Metamodelo MeTAGeM (nivel PIM) ........................................ 138 Metamodelo Especfico de Plataforma (nivel PSM) ................ 140 Metamodelos Dependientes de Plataforma (nivel PDM) ......... 142

4.2.1 4.2.2 4.2.3 4.2.4 4.3

Especificacin de Transformaciones ............................................... 149 Transformacin de modelos PIM a modelos PSM ................... 149 Transformacin de modelos PSM a modelos PDM ................. 152 Transformacin de modelo PDM a cdigo .............................. 156

4.3.1 4.3.2 4.3.3 4.4

Especificacin de reglas de validacin de modelos ......................... 158 Validacin del metamodelo PIM .............................................. 158 Validacin del metamodelo PSM ............................................. 159

4.4.1 4.4.2 5.

SOLUCIN TECNOLGICA ...................................................................... 165 5.1 5.2 5.3 Arquitectura Conceptual de MeTAGeM-Trace ............................... 166 Diseo tcnico de MeTAGeM-Trace .............................................. 167 Implementacin ............................................................................... 169 Implementacin de Metamodelos ............................................. 169 Implementacin de Editores y Visualizadores de modelos ...... 178 Implementacin de Asistentes de Creacin de modelos ........... 196 Implementacin de Transformaciones de modelos .................. 202 Implementacin de la Generacin de Cdigo .......................... 219

5.3.1 5.3.2 5.3.3 5.3.4 5.3.5

XII

5.3.6 5.3.7 6.

Validacin automtica de modelos .......................................... 224 Desarrollo de controles de usuario e Integracin ................... 226

VALIDACIN ............................................................................................ 241 6.1 Protocolo de Validacin .................................................................. 241 Definicin de los Casos de Estudio .......................................... 241 Protocolo para la Recogida de Datos ...................................... 242

6.1.1 6.1.2 6.2

Diseo y Ejecucin del Meta-Caso de Estudio ................................ 245 Especificacin de las Relaciones de Transformacin .............. 246 Definicin del Modelo PIM ...................................................... 248 Definicin del Modelo PSM ..................................................... 250 Definicin del Modelo PDM .................................................... 252 Generacin de Cdigo ............................................................. 253

6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.3 6.4 7.

Diseo y Ejecucin del Caso de Estudio ......................................... 255 Conclusiones de la Validacin......................................................... 260

CONCLUSIONES ....................................................................................... 267 7.1 7.2 7.3 7.4 Anlisis de la Consecucin de Objetivos ......................................... 267 Principales Contribuciones .............................................................. 273 Resultados Cientficos ..................................................................... 275 Trabajos Futuros .............................................................................. 277 Generacin y Gestin de Trazas en MDE ................................ 277 Mejoras en el Desarrollo de Transformaciones de Modelos ... 279 Aplicacin de los principios de MDE a la construccin de otros

7.4.1 7.4.2 7.4.3

artefactos MDE ...................................................................................... 281 7.4.4 APNDICE A. A.1 Mejoras en el contexto de la herramienta MeTAGeM-Trace... 282 DETALLES DEL PROCESO DE REVISIN SISTEMTICA ....... 287

Planificacin .................................................................................... 287 Cuestiones de Investigacin ..................................................... 287 Fuentes de Informacin y cadenas de bsqueda ...................... 289 Criterios de Inclusin y Exclusin ........................................... 290 Criterios de Evaluacin ........................................................... 291 Extraccin de Datos y Anlisis ................................................ 293
XIII

A.1.1 A.1.2 A.1.3 A.1.4 A.1.5

A.2

Ejecucin ......................................................................................... 294 Bsqueda de Estudios Primarios ............................................. 294 Estudios Primarios seleccionados ........................................... 296

A.2.1 A.2.2 A.3

Limitaciones .................................................................................... 297 MANUAL DE USUARIO DE METAGEM-TRACE ................... 301

APNDICE B. B.1 B.2 B.3 B.4 B.5 B.6 B.7

Introduccin ..................................................................................... 301 Instalacin........................................................................................ 302 Modelado de la Transformacin Independiente de Plataforma ....... 303 Modelado de la Transformacin Especfica de Plataforma ............. 307 Modelado de la Transformacin Dependiente de Plataforma .......... 311 Generacin de Cdigo ..................................................................... 312 Generacin del Modelo de Trazas ................................................... 314

REFERENCIAS ................................................................................................... 315 ACRNIMOS ...................................................................................................... 327

XIV

Lista de Figuras
Figura 1-1. Ejemplo de trazas obtenidas en un escenario MDE ............................ 28 Figura 1-2. Arquitectura de MIDAS ...................................................................... 33 Figura 1-3. Proyectos de Investigacin de la Tesis Doctoral................................. 34 Figura 2-1. Mtodo de Investigacin propuesto por Marcos y Marcos [141] ....... 42 Figura 2-2. Etapa de Resolucin y Validacin del Mtodo de Investigacin ........ 44 Figura 2-3. Proceso de Revisin Sistemtica propuesto por Biolchini et al. [27] . 46 Figura 2-4. Proceso para guiar la RS: (a) proceso de bsqueda, (b) seleccin de estudios primarios y (c) extraccin de datos. ................................................ 48 Figura 2-5. Mtodo de Desarrollo ......................................................................... 49 Figura 2-6. Proceso de Validacin mediante Casos de Estudio ............................. 51 Figura 3-1. a) Definicin de Modelo (Kleppe et al.), b) Jerarqua de Modelado y c) Relacin entre los conceptos Modelo y Metamodelo .............................. 59 Figura 3-2. Proceso de Transformacin de Modelos ............................................. 60 Figura 3-3. Disciplinas MDE................................................................................. 61 Figura 3-4. Simplificacin de un proceso de DSDM ............................................. 62 Figura 3-5. Niveles de abstraccin MDA .............................................................. 64 Figura 3-6. relacin de trazabilidad vs enlace de traza ..................................... 66 Figura 4-1. Generacin de Modelos de Trazas a partir del DDM de Transformaciones de Modelos .................................................................... 131 Figura 4-2. Diagrama SPEM del Proceso de Desarrollo soportado por MeTAGeMTrace ........................................................................................................... 133 Figura 4-3. Jerarqua de modelado de MeTAGeM-Trace ................................... 135 Figura 4-4. Metamodelo de Trazabilidad de MeTAGeM-Trace.......................... 137 Figura 4-5. Metamodelo MeTAGeM (nivel PIM) ............................................... 139 Figura 4-6. Metamodelo de Transformaciones para la aproximacin Hbrida (nivel PSM) ........................................................................................................... 141 Figura 4-7. Metamodelo de ATL ......................................................................... 146 Figura 4-8. Metamodelo de ETL ......................................................................... 148 Figura 5-1. Arquitectura Conceptual de MeTAGeM-Trace ................................ 166 Figura 5-2. Diseo tcnico de MeTAGeM-Trace ................................................ 168
XV

Figura 5-3. Metamodelo MeTAGeM (Modelo Ecore) ........................................ 171 Figura 5-4. Metamodelo de Aproximacin Hbrida (Modelo Ecore) .................. 173 Figura 5-5. Metamodelo de ETL (Modelo Ecore)............................................... 175 Figura 5-6. Metamodelo de Trazabilidad (Modelo Ecore) .................................. 177 Figura 5-7. Relacin entre los modelos GenModel y Ecore ................................ 178 Figura 5-8. Vista general de la Generacin de Editores EMF ............................. 179 Figura 5-9. Ejemplo editor en forma del rbol (EMF)......................................... 180 Figura 5-10. Organizacin de modelos en el editor AMW .................................. 181 Figura 5-11. Esbozo de la estructura de los editores/visualizadores multipanel .. 182 Figura 5-12. Creando extensiones tipo editor...................................................... 183 Figura 5-13. Mtodo getChildrenFeatures modificado ....................................... 184 Figura 5-14. Mtodo collectNewChildDescriptors modificado........................... 185 Figura 5-15. Atributos aadidos a la clase TraceabilityEditorTrace ................... 186 Figura 5-16. Estableciendo la forma del contenedor y cargando los modelos origen y destino en el editor multipanel ................................................................. 186 Figura 5-17. Cdigo que implementa el visor de los modelos origen ................. 187 Figura 5-18. Cdigo que implementa el visor del modelo de Trazas .................. 188 Figura 5-19. Lneas a suprimir en el mtodo createContextMenuFor ................. 188 Figura 5-20. Mtodo handleContentOutlineSelection ......................................... 189 Figura 5-21. Estableciendo el visor en el que se resalta la seleccin ................... 189 Figura 5-22. Instanciando la clase TraceabilityDragDrop .................................. 191 Figura 5-23. Editor multipanel de Trazabilidad................................................... 191 Figura 5-24. Modelo ETL: (a) iconos genricos; (b) iconos personalizados ....... 192 Figura 5-25. Modelo MeTAGeM: (a) todas las instancias disponibles; (b) valores actualizados en tiempo de ejecucin ........................................................... 193 Figura 5-26. Cdigo Java para actualizacin automtica de los mens desplegables de las referencias ........................................................................................ 194 Figura 5-27. Cdigo que implementa la actualizacin automtica de los elementos de las relaciones de trazabilidad ................................................................. 195 Figura 5-28. Asistente de creacin de modelos de Trazas ................................... 196 Figura 5-29. Extensin org.eclipse.ui.newWizards ............................................. 197 Figura 5-30. Categora MeTAGeM para agrupar a los asistentes de creacin .... 198
XVI

Figura 5-31. Inicializando los atributos sourceModels y targetModels............... 199 Figura 5-32. Mtodo createInitialModel modificado .......................................... 199 Figura 5-33. Mtodo addPages() modificado...................................................... 200 Figura 5-34. Pantalla de seleccin de modelos (Asistente de creacin de modelos de Trazas) ................................................................................................... 200 Figura 5-35. Atributos de TraceabilityModelWizardModelsCreationPage......... 201 Figura 5-36. Ventana de definicin de modelos participantes ............................. 202 Figura 5-37. Cabecera Transformacin MeTAGeM2Hybrid .............................. 204 Figura 5-38. Regla ModelRoot2Module (Transformacin MeTAGeM2Hybrid) 204 Figura 5-39. Reglas de transformacin de los modelos origen y destino (Transformacin MeTAGeM2Hybrid) ....................................................... 205 Figura 5-40. Regla abstracta Relations2Rule (Transformacin MeTAGeM2Hybrid) ................................................................................... 206 Figura 5-41. Ejemplo grfico de regla Relations2Rule (Transformacin MeTAGeM2Hybrid) ................................................................................... 207 Figura 5-42. Regla OneToOne2Rule (Transformacin MeTAGeM2Hybrid) ..... 207 Figura 5-43. Regla abstracta Relations2Binding (Transformacin MeTAGeM2Hybrid) ................................................................................... 208 Figura 5-44. Fragmento regla Module: creando el modelo de Trazas (Transformacin Hybrid2ATL) .................................................................. 210 Figura 5-45. Fragmento regla Module: creando un entrypoint (Transformacin Hybrid2ATL) .............................................................................................. 211 Figura 5-46. Fragmento de regla createRule2MatchedRule (Transformacin Hybrid2ATL) .............................................................................................. 212 Figura 5-47. Generando trazas como elementos destino de una regla ................. 212 Figura 5-48. Fragmento regla InPatternElement_withTrace (Transformacin Hybrid2ATL) .............................................................................................. 213 Figura 5-49. Helper getPre y regla Module: creando bloque pre (Transformacin Hybrid2ETL) .............................................................................................. 215 Figura 5-50. (a): Regla createSourceModel; (b) bloque pre de la transformacin generada (Transformacin Hybrid2ETL) ................................................... 216 Figura 5-51. Regla createRule (Transformacin Hybrid2ETL) .......................... 217 Figura 5-52. Regla TraceRule2CreateTraceLink (Transformacin Hybrid2ETL) .................................................................................................................... 218

XVII

Figura 5-53. Cabecera y Generacin de cdigo de la metaclase EtlModule ....... 221 Figura 5-54. Generacin de cdigo de la metaclase T ransformationRule ........... 222 Figura 5-55. Generacin de cdigo de la metaclase Operation ........................... 223 Figura 5-56. Operacin ETL generada ................................................................ 223 Figura 5-57. Regla de validacin notEmptyModelRootName (MeTAGeM) ....... 225 Figura 5-58. Regla de validacin validModuleName (Hybrid) ........................... 225 Figura 5-59. Regla de validacin manySources (Hybrid_to_ETL) ..................... 226 Figura 5-60. Dependencias del Mdulo de Integracin de MeTAGeM-Trace .... 227 Figura 5-61. Definiendo la extensin para la validacin EVL ............................ 228 Figura 5-62. Lanzando una validacin de modelos en MeTAGeM-Trace .......... 229 Figura 5-63. Configurando la ejecucin de una transformacin ATL ................. 230 Figura 5-64. Definicin de extensiones para los lanzadores de las transformaciones de modelos .................................................................................................. 231 Figura 5-65. Posibles comportamientos del lanzador de transformaciones: a) seleccin de configuracin ya establecida; b) creacin de una nueva configuracin .............................................................................................. 232 Figura 5-66. Mensaje de error en la ventana de configuracin ............................ 233 Figura 5-67. Mensaje de error de validacin ....................................................... 233 Figura 5-68. Proceso de ejecucin de la transformacin MeTAGeM2Hybrid .... 234 Figura 5-69. Mtodos para la ejecucin programtica de la transformacin Metagem2hybrid ......................................................................................... 235 Figura 5-70. Entradas del men contextual para generar el cdigo de la transformacin ............................................................................................ 236 Figura 5-71. Extensiones para la definicin de entradas de men contextual ..... 237 Figura 6-1. Proceso de Desarrollo de Bases de Datos soportado por M2DAT-DB .................................................................................................................... 243 Figura 6-2. Proceso de Desarrollo de la Transformacin UML2XMLSchema_Trace con MeTAGeM-Trace .................................... 246 Figura 6-3. Modelo de Transformacin a nivel PIM (UML2XMLSchema_Trace) .................................................................................................................... 249 Figura 6-4. Modelo de Transformacin a nivel PSM (UML2XMLSchema_Trace) .................................................................................................................... 251 Figura 6-5. Modelo de Transformacin a nivel PDM: ATL (UML2XMLSchema_Trace) ...................................................................... 252
XVIII

Figura 6-6. Cdigo ATL de la regla model2schema generada con MeTAGeMTrace (UML2XMLSchema_Trace) ............................................................ 254 Figura 6-7. Cdigo ATL de la regla model2schema implementada manualmente para M2DAT-DB (UML2XMLSchema_Trace) ......................................... 255 Figura 6-8. Modelo Conceptual de Datos (Caso de Estudio OMDB) ................. 256 Figura 6-9. Proceso de Desarrollo del Caso de Estudio....................................... 257 Figura 6-10. Modelo OMDB.schemaxml: (a) obtenido a partir de la transformacin generada con MeTAGeM-Trace; (b) obtenido a partir de la transformacin manual embebida en M2DAT-DB ..................................... 258 Figura 6-11. Modelo de Trazas generado (Caso de Estudio OMDB) .................. 259 Figura B-1. Seleccin del Asistente de Creacin para modelos MeTAGeM ...... 303 Figura B-2. Creando el modelo de la Transformacin Independiente de Plataforma .................................................................................................................... 304 Figura B-3. Nuevo modelo de la Transformacin Independiente de Plataforma. 304 Figura B-4. Tipos de Relaciones ......................................................................... 305 Figura B-5. Especificando el elemento destino en una relacin OneToOne........ 306 Figura B-6. Creando una relacin incluida en un elemento destino .................... 306 Figura B-7. Generando un modelo Hybrid a partir de un modelo MeTAGeM ... 307 Figura B-8. Creando un elemento Operation ...................................................... 308 Figura B-9. Definiendo el atributo Operation de un elemento RightPattern ...... 309 Figura B-10. Definiendo los atributos BelongsTo ............................................... 310 Figura B-11. Creando un elemento Trace Rule ................................................... 311 Figura B-12. Creando un elemento Trace Binding .............................................. 311 Figura B-13. Transformacin de PSM a PDM .................................................... 312 Figura B-14. Generando el cdigo de la transformacin en ATL ....................... 313 Figura B-15. Generando el cdigo de la transformacin en ETL ........................ 313 Figura B-16. Ejemplo de Modelo de Trazas ........................................................ 314

XIX

Lista de Tablas
Tabla 3-1. Resumen de los Criterios de Evaluacin en cada propuesta................. 86 Tabla 3-2. Resumen de los Criterios de Evaluacin en cada propuesta............... 118 Tabla 4-1. Transformacin PIM a PSM .............................................................. 150 Tabla 4-2. Transformacin PSM a ATL (PDM).................................................. 153 Tabla 4-3. Transformacin PSM a ETL (PDM) .................................................. 155 Tabla 4-4. Transformacin ETL (PDM) a ETL (Cdigo) ................................... 157 Tabla 4-5. Validacin del metamodelo PIM ........................................................ 159 Tabla 4-6. Validacin del metamodelo PSM ....................................................... 160 Tabla 4-7. Validacin del metamodelo PSM para transformaciones a ATL ....... 161 Tabla 4-8. Validacin del metamodelo PSM para transformaciones a ETL ........ 162 Tabla 5-1. Reglas de Transformacin implementadas para elementos origen y destino (Transformacin Hybrid2ETL) ...................................................... 219 Tabla 6-1. Relaciones de Transformacin en UML2XMLSchema_Trace .......... 246 Tabla 6-2. Comparativa de tiempos de ejecucin (Transformacin MeTAGeMTrace vs. Transformacin manual) ............................................................. 263 Tabla A-1. Cadenas de Bsqueda adaptadas y mbito de bsqueda ................... 294 Tabla A-2. Resultados de las bsquedas.............................................................. 295 Tabla A-3. Filtrado de estudios duplicados ......................................................... 296 Tabla A-4. Lista de Estudios Primarios ............................................................... 296

XXI

Introduccin

1. Introduccin
En la presente tesis, se propone la definicin de un marco metodolgico para la generacin (semi-)automtica de enlaces de traza en un entorno de desarrollo de transformaciones de modelos dirigido por modelos y la construccin de un entorno tecnolgico que d soporte a dicho marco metodolgico. En la primera seccin de este captulo (seccin 1.1) se presenta el contexto y el problema a abordar este trabajo as como las principales contribuciones del mismo. A continuacin, en la seccin 1.2 se establece la hiptesis principal y los objetivos que derivan directamente de la misma. En la seccin 1.3 se describe el contexto en el que se desarrolla este trabajo, haciendo referencia a los proyectos de investigacin en los que se ha tomado parte. Y finalmente, en la seccin 1.4 se proporciona una visin general del resto de este documento.

1.1

Planteamiento del Problema

A lo largo de la historia de la Ingeniera del Software, los desarrolladores e investigadores han realizado grandes esfuerzos con el objetivo de simplificar el proceso de desarrollo de software a partir del aumento gradual del nivel de abstraccin al que se disea y se desarrolla. As, por ejemplo, la programacin en lenguaje ensamblador dio paso al empleo de lenguajes de programacin como C o Fortran, que elevaban el nivel de abstraccin al que se programaba y diseaba. Esta tendencia ha continuado hasta nuestros das y as han surgido otros paradigmas como la orientacin a objetos o la orientacin a aspectos [182, 221]. El ltimo paso natural en esta tendencia de aumentar el nivel de abstraccin al que se construye el software es la Ingeniera Dirigida por Modelos (MDE, Model-Driven Engineering) [22]. Con la llegada de MDE, el escenario en el que se construye el software ha cambiado drsticamente: los desarrolladores han pasado de centrarse en la codificacin de la solucin, a centrarse en el modelado del problema. Sin embargo, conviene mencionar que la idea de usar modelos a lo largo del proceso de desarrollo no es en absoluto nueva. Con anterioridad a la llegada de MDE, los modelos ya estaban presentes en tareas como la documentacin o el diseo del sistema e incluso en algunos casos, a partir de estos modelos era posible generar la estructura o esqueleto del sistema. Un ejemplo de este escenario podra ser Rational Rose [94], que a partir de modelos UML es capaz de generar la especificacin de las clases recogidas en dichos modelos, lo que podra utilizarse

26

lvaro Jimnez Rielo

como punto de partida para implementar el resto del sistema. Sin embargo una vez que cumplan su funcin, tradicionalmente limitada a las fases de anlisis y diseo (de alto nivel), estos modelos eran descartados en fases sucesivas del proceso de desarrollo y en la mayora de los casos no eran actualizados para reflejar cambios posteriores. Los principales cambios o novedades que aporta MDE son: el rol principal que juegan los modelos en el proceso de desarrollo y el aumento del nivel de automatizacin del proceso en s mismo. De hecho, una de las mejores formas de aprovechar al mximo las ventajas que ofrece MDE, en trminos de desarrollos ms rpidos y baratos, pasa por automatizar al mximo posible el proceso de desarrollo [14, 71]. El impacto de MDE puede verse reflejado en nuevas metodologas de Desarrollo de Software Dirigido por Modelos (DSDM o en ingls: MDSD, Model-Driven Software Development) [192, 220]. Estas metodologas se centran en potenciar el nivel de automatizacin en la construccin de software, proponiendo el modelado del sistema a diferentes niveles de abstraccin, de forma que se construyan modelos cada vez ms detallados hasta que estos puedan ser utilizados como planos de menor nivel para la generacin de cdigo o en algunos casos, constituyan el sistema ejecutable en s mismo [1, 51, 65, 135, 229]. En este contexto, uno de los puntos clave para aumentar el nivel de automatizacin es el empleo de transformaciones de modelo a modelo (M2M, model-to-model) y de transformaciones de modelo a cdigo (M2T, model-to-text) que actan como eslabones, uniendo cada paso del proceso [22, 78, 185, 199]. As, las primeras se utilizan para convertir uno (o varios) modelos del sistema en otro modelo (u otros), mientras que las segundas se utilizan para la serializacin de los modelos en el cdigo que implementa el sistema. Una de las interpretaciones ms adoptadas de los principios de MDE es la realizada por el consorcio internacional Object Management Group2 (OMG): Arquitectura Dirigida por Modelos (MDA, Model-Driven Architecture) [71, 74, 90, 112, 144, 157, 186, 226]. MDA define una arquitectura basada en tres niveles conceptuales o niveles de abstraccin: CIM (Computation Independent Model), PIM (Platform Independent Model) y PSM (Platform Specific Model). Los detalles del dominio de la aplicacin se modelan mediante Modelos Independientes de Computacin (nivel CIM) que sirven de conexin entre los expertos del negocio y los desarrolladores del sistema. La funcionalidad y
2

http://www.omg.org

Introduccin 27

estructura del sistema, abstrayndose de los detalles tecnolgicos de la plataforma que soportar al sistema se modelan mediante Modelos Independientes de Plataforma (nivel PIM). Estos modelos podrn ser refinados tantas veces como sea necesario, con el fin de obtener una descripcin del sistema con el nivel de claridad y abstraccin ptimo. Para combinar estas especificaciones independientes de plataforma con los detalles especficos de la plataforma en la que se implementar el sistema final, se utilizan Modelos Especficos de Plataforma (nivel PSM). Partiendo de diferentes modelos PSM se puede obtener distintas implementaciones de un mismo sistema. Este nivel PSM, a su vez puede contener diferentes modelos que representan distintos grados de abstraccin, pudindose agrupar en modelos que representan elementos generales a todas las plataformas y en modelos que representan elementos dependientes de una plataforma especfica. Esta distincin da lugar a la consideracin de otro nivel de abstraccin, denominado PDM (Platform Dependent Models) [79, 157, 170]. Adicionalmente, el cdigo que implementa el sistema puede ser considerado otro modelo de ms bajo nivel de abstraccin [157]. Por otro lado, una de las tareas ms importantes de la Ingeniera del Software [12, 172] es la identificacin, creacin y mantenimiento de las relaciones de trazabilidad. La IEEE [95] (pp. 78) define la trazabilidad como: el grado de relacin que puede establecerse entre dos o ms productos de un proceso de desarrollo, especialmente productos que tienen un relacin predecesor-sucesor o maestro-subordinado con otro producto. Una correcta identificacin de las trazas permite conocer cmo evolucionan los elementos de un sistema y cmo se relacionan entre s, a lo largo de todo su ciclo de vida [11]. Adems, la adecuada gestin de la informacin de trazabilidad facilita el desempeo de otras actividades relacionadas con el desarrollo software tales como el anlisis del impacto del cambio, pruebas de regresin, validacin de requisitos, anlisis de coberturas, toma de decisiones, gestin de la configuracin y en general, todas las tareas de mantenimiento del software [5, 9, 39, 40, 44, 113, 147, 164, 183, 188, 200, 225]. Por todo ello, sera deseable que cualquier propuesta para el desarrollo de software diera soporte para la gestin de la trazabilidad [191]. Desafortunadamente, hasta el momento, la identificacin y la gestin de las relaciones de traza ha sido casi exclusivamente una tarea manual, lo que la ha convertido en una tarea difcil y costosa en tiempo y esfuerzo, y en consecuencia, propensa a generar errores [61, 66, 92, 138, 152, 228].

28

lvaro Jimnez Rielo

Dado que las tecnologas que dan soporte a MDE han alcanzado cierto grado de madurez [142, 221], es el momento de afrontar nuevos retos en el desarrollo de software dirigido por modelos. En particular, esta tesis se centra en aplicar los principios de MDE a la identificacin, creacin y mantenimiento de las relaciones de trazabilidad. Estas tareas son, si cabe, an ms importantes en desarrollos dirigidos por modelos, donde la construccin de los sistemas tiende a automatizarse y por tanto, se requiere un mayor control acerca de cmo se han creado los artefactos. Esta tendencia hacia la automatizacin surge como una oportunidad para mejorar la creacin y gestin de las relaciones de trazabilidad presentes en cualquier proyecto de desarrollo dirigido por modelos [5, 82]. Segn los principios de MDE [108, 182, 185] y del DSDM [78], la mayor parte de los modelos empleados en las distintas fases del desarrollo estn conectados por transformaciones de modelos. Por tanto, sera posible emplear las relaciones que componen cualquier transformacin para generar de forma automtica los enlaces de traza entre los distintos elementos de dichos modelos. Este escenario es representado en la Figura 1-1: dos modelos (Ma y Mb) se conectan mediante una transformacin (MMa2MMb), definida a nivel de metamodelo. En MMa2MMb se ha definido una relacin de transformacin entre las clases p y p y una relacin de transformacin entre las clases q y q. A partir de estas relaciones de transformacin, es posible identificar las relaciones de trazabilidad existentes entre dichas clases (a nivel de metamodelo). As, como muestra la Figura 1-1, es posible transformar las instancias (a nivel de modelo) de la clase p (p1 y p2) en instancias de la clase p (p1 y p2) y adems, generar automticamente las trazas existentes entre los elementos transformados (MTrace).
MTrace
q1->q1

p1->p1 p2->p2

Ma

p1 p2

q1

Mb MMa2MMb q1

p1

p2

Figura 1-1. Ejemplo de trazas obtenidas en un escenario MDE

Introduccin 29

Ahora bien, mediante esta idea se estara trasladando el problema de la creacin y gestin manual de las relaciones de trazabilidad por el de codificar o desarrollar una transformacin. Este paso se considera un avance ya que, como se han mencionado anteriormente, los sistemas son construidos a partir de modelos y transformaciones entre dichos modelos, por tanto, la tarea de desarrollar transformaciones se lleva a cabo en cualquier caso. No obstante, dado que las transformaciones de modelos son cada vez ms complejas, debido al mayor nmero de artefactos implicados en las mismas, resulta recomendable aplicar los principios de MDE para su desarrollo [23, 24, 58, 88, 103, 128, 153]. En este contexto, sera an mejor si pudisemos reemplazar la codificacin de las transformaciones por su especificacin a alto nivel, de forma que dicha especificacin sera tambin una definicin implcita de las relaciones de trazabilidad a nivel de metamodelo. En otras palabras, resultara conveniente poder modelar las transformaciones a alto nivel y refinar automticamente dichas especificaciones en especificaciones (o modelos) de ms bajo nivel. Adems, el hecho de especificar las transformaciones (e implcitamente las relaciones de trazabilidad) en forma de modelo resulta en una serie de ventajas adicionales: en tanto en cuanto las transformaciones sean un modelo ms, podremos generarlas, transformarlas, validarlas, compararlas, refactorizarlas, etc. utilizando tcnicas propias de MDE [21]. Por todo ello, en esta tesis doctoral se plantea incorporar mecanismos de generacin semi-automtica de trazabilidad en un entorno de desarrollo de transformaciones de modelos dirigido por modelos como el que se presenta en [31]. As, la propuesta que se presenta en esta tesis, MeTAGeM-Trace, permitir generar modelos de trazas a partir del modelado de transformaciones de modelos a diferentes niveles de abstraccin, de forma semi-automtica e independiente del lenguaje en el que finalmente se implemente la transformacin. Las principales contribuciones que incluir el entorno para el desarrollo de transformaciones de modelos dirigido por modelos con soporte para la generacin de modelos de trazas, denominado MeTAGeM-Trace sern: Gestin de la trazabilidad en el desarrollo dirigido por modelos de transformaciones de modelos: Definicin de un metamodelo de trazabilidad lo suficientemente genrico para cubrir las necesidades de cualquier escenario que se pueda dar en cualquier entorno dirigido por modelos.

30

lvaro Jimnez Rielo

Soporte para el modelado y generacin de modelos de transformacin a diferentes niveles de abstraccin que integren informacin de trazabilidad para la generacin de modelos de trazas conformes al metamodelo anterior. Mecanismos de visualizacin ad-hoc para modelos de trazas conformes al metamodelo anterior. Estos mecanismos de visualizacin, tendrn en cuenta la naturaleza de los modelos de traza para resultar usables e intuitivos en ese contexto. Incorporacin de construcciones para el modelado de relaciones de trazabilidad en los DSLs que fueron definidos en [31] para el modelado de transformaciones a distintos niveles de abstraccin. Incorporacin de mecanismos de visualizacin ad-hoc para las relaciones entre los elementos de los metamodelos implicados en la transformacin que se desea modelar.

Generacin de enlaces de traza a partir de la ejecucin de las transformaciones de modelos generadas.

1.2

Hiptesis y Objetivos

La hiptesis planteada en esta Tesis Doctoral es: Dado que a partir de la especificacin de alto nivel de las relaciones que deben satisfacerse entre los elementos de los modelos implicados en una transformacin es posible generar, no solo la propia transformacin, sino tambin las trazas que se derivan de esas relaciones, es factible proporcionar un entorno de desarrollo de transformaciones de modelos dirigido por modelos que incorpore gestin de la trazabilidad. El objetivo principal de este trabajo de investigacin, derivado directamente de la hiptesis, es: la definicin y construccin de un entorno de desarrollo de transformaciones de modelos dirigido por modelos que incorpore gestin de la trazabilidad. Para la consecucin de este objetivo se han planteado los siguientes objetivos parciales: O1. Estudio de trabajos previos: O1.1. Anlisis y evaluacin de trabajos relacionados con la generacin de informacin de trazabilidad en el desarrollo de transformaciones, incluyendo propuestas metodolgicas y herramientas.

Introduccin 31

O1.2. Anlisis y evaluacin de propuestas para el desarrollo dirigido por modelos de transformaciones de modelos. O2. Especificacin de un metamodelo de trazabilidad genrico. O3. Estudio y mejora (si procede) de la propuesta MeTAGeM para el desarrollo transformaciones de modelos [31]: O3.1. Estudio y mejora (si procede) del metamodelo para la definicin de modelos de transformaciones a nivel PIM. O3.2. Estudio y mejora (si procede) de los metamodelos para la definicin de modelos de transformacin a nivel PSM. Este nivel se corresponde con la aproximacin seleccionada por el desarrollador, esto es, imperativa, declarativa, hbrida, grafos, etc. En esta tesis se selecciona la aproximacin hbrida (combinacin de las aproximaciones imperativa y declarativa). O3.3. Estudio y mejora (si procede) de los metamodelos para la definicin de modelos de transformacin a nivel PDM. MeTAGeM propone ATL y RubyTL como lenguajes hbridos a nivel PDM. En esta tesis nos centraremos en ATL. O4. Especificacin de un metamodelo de transformacin a nivel PDM de acuerdo a las caractersticas del lenguaje hbrido ETL. O5. Identificacin de construcciones que, incorporadas a los metamodelos de transformacin definidos a nivel PIM, PSM y PDM, permitirn generar modelos de traza conformes al metamodelo definido en O2. O5.1. Incorporacin de dichas construcciones a los metamodelos de transformacin definidos a nivel PIM, PSM y PDM. O6. Especificacin de transformaciones de modelos: O6.1. Especificacin de las transformaciones de modelos transformaciones de nivel PIM a modelos de nivel PSM. de

O6.2. Especificacin de las transformaciones de modelos de transformacin de nivel PSM a modelos de nivel PDM, es decir, modelos dependientes de un lenguaje de transformacin determinado. En concreto, en esta tesis se propone ATL y ETL a nivel PDM. O7. Construccin de la herramienta de soporte: O7.1. Especificacin de la arquitectura de la herramienta de soporte. O7.2. Desarrollo del DSL para el modelado de enlaces de traza.

32

lvaro Jimnez Rielo

O7.3. Implementacin de los DSLs para el transformaciones a nivel PIM, PSM y PDM. O7.4. Implementacin de transformaciones de modelos:

modelado

de

Transformacin de modelos definidos a nivel PIM a modelos definidos a nivel PSM. Transformacin de modelos definidos a nivel PSM a modelos definidos a nivel PDM. Transformacin de modelo a texto, que permitirn obtener el cdigo para un lenguaje concreto (ATL y ETL). O7.5. Integracin de la funcionalidad proporcionada como resultado de las tareas anteriores. Para ello, se desarrollarn mdulos que proporcionen una interfaz visual que facilite la ejecucin de las transformaciones. O8. Validacin de la propuesta. O8.1. Para ello se desarrollar un meta-caso de estudio que permitir validar, tanto la propuesta metodolgica, como el correcto funcionamiento de la herramienta. O8.2. Adems, se desarrollar un caso de estudio que consistir en probar las transformaciones de modelos generadas en el meta-caso de estudio.

1.3

Marco de Investigacin

En los ltimos aos, el grupo de investigacin Kybele, del cual forma parte el doctorando, ha estado trabajando en la definicin de MIDAS [53, 54, 137, 211, 216], una metodologa centrada en la arquitectura para el desarrollo dirigido por modelos de Sistemas de Informacin (SI). En el marco de MIDAS, se han definido distintas propuestas destinadas a dar solucin a problemas concretos en el contexto del desarrollo de SIs: SOD-M [52] una aproximacin metodolgica basada en MDA para el desarrollo orientado a servicios de SIs; PISA [4] una arquitectura de integracin de portales Web basados en servicios web semnticos; MIDAS MDA Tool (M2DAT) [206] la herramienta MDA que soporta cada uno de los mtodos propuestos en MIDAS; y MeTAGeM [31], una meta-herramienta para semi-automatizar el desarrollo de transformaciones de modelos para M2DAT.

Introduccin 33

En la Figura 1-2 se presenta la arquitectura de MIDAS. Esta arquitectura est basada en los principios de MDA [157] y se define sobre una base multidimensional que se propaga a travs de varios niveles de abstraccin y diferentes aspectos del desarrollo del sistema. En cada una de las dimensiones o aspectos se definen una serie de modelos y reglas de transformacin entre dichos modelos, adems se establecen las relaciones existentes entre los mismos.

PSM

PIM

CIM

Figura 1-2. Arquitectura de MIDAS

Dimensin vertical. Esta dimensin tiene una relacin directa con los tres niveles de abstraccin definidos por MDA: CIM, PIM y PSM. De acuerdo a esta clasificacin: los conceptos relacionados con el dominio del problema son especificados en los modelos CIM; la estructura y funcionalidad del sistema, omitiendo los detalles tecnolgicos de la plataforma sobre la que se desarrolla, son definidas en modelos a PIM; y la representacin del sistema, teniendo en cuenta las caractersticas propias de la plataforma sobre la que se desarrolla, se especifica en modelos a nivel PSM. Para establecer relaciones entre dichos modelos, se definen transformaciones de modelos.

34

lvaro Jimnez Rielo

Ncleo de la arquitectura de modelos. En MIDAS la arquitectura gua el proceso de desarrollo [140], por lo que sus modelos forman parte del ncleo de MIDAS. De hecho, la arquitectura especifica las caractersticas que afectan a todos los aspectos del sistema. Capa interior concntrica. En esta capa, los modelos se organizan de acuerdo a los tres principales aspectos involucrados en el desarrollo de un SI: contenido, hipertexto y comportamiento. Capa externas. En el desarrollo software existen otros aspectos importantes, tales como la semntica, la seguridad o la calidad, que tambin son definidos por MIDAS. Estos aspectos son ortogonales a los anteriormente mencionados (contenido, hipertexto y comportamiento). Por esta razn, son incluidos en otra capa concntrica del cilindro. Herramientas de soporte (M2DAT y MeTAGeM-Trace). Finalmente, las dos capas ms externas hacen referencia a la herramienta que soporta MIDAS (M2DAT [206]) y a la herramienta MeTAGeM-Trace (objetivo de esta tesis doctoral), respectivamente. MeTAGeM-Trace se utiliza para desarrollar las transformaciones embebidas en los diferentes mdulos de M2DAT. Para ello, MeTAGeM-Trace soporta el desarrollo semi-automtico de transformaciones incluyendo, adems, la generacin de enlaces de traza.

1.3.1

Proyectos de Investigacin

La investigacin realizada en esta tesis doctoral se ha llevado a cabo en el Grupo de Investigacin Kybele de la Universidad Rey Juan Carlos (URJC). Este trabajo, como muestra la Figura 1-3, se enmarca fundamentalmente en el contexto del proyecto de investigacin MODEL-CAOS y su continuacin, MASAI y ha sido co-financiado por el programa I+D de Personal Tcnico de Apoyo.

Figura 1-3. Proyectos de Investigacin de la Tesis Doctoral

El proyecto MODEL-CAOS [TIN2008-03582], financiado por el Ministerio de Educacin y Ciencia, comenz en el ao 2009 y ha tenido una

Introduccin 35

duracin de tres aos (hasta 2011). El objetivo principal de MODEL-CAOS ha sido la especificacin de un marco para el desarrollo (semi-)automtico de SI, centrndose en la utilizacin del paradigma de Orientacin a Servicios. En el marco de dicho proyecto se propone el desarrollo de una meta-herramienta que permita automatizar las tareas del DSDM. Este proyecto toma como base los trabajos realizados en proyectos anteriores, actualizndolos mediante la inclusin de las ltimas tendencias en el desarrollo de SI: desarrollo dirigido por modelos, orientacin a servicios, etc., poniendo especial nfasis en el aspecto arquitectnico como elemento central que gua el proceso metodolgico. En el contexto del proyecto MODEL-CAOS es donde se ha desarrollado la mayor parte de esta Tesis Doctoral. En particular, el doctorando ha trabajado en el desarrollo de una propuesta metodolgica y tecnolgica para el desarrollo (semi-)automtico de transformaciones de modelos que incluyen generacin de enlaces de traza. La continuacin del proyecto MODEL-CAOS es el proyecto MASAI [TIN TIN-2011-22617] cuyo objetivo principal es aplicar tcnicas de MDE para proporcionar soluciones a algunos de los problemas que encontramos en la Ingeniera de Servicios (IS), aprovechando los conocimientos y experiencia adquiridos en el marco de los proyectos anteriores desarrollados por el grupo Kybele. En particular, el doctorando contina refinando la propuesta presentada en esta Tesis Doctoral con el objetivo de producir una meta-herramienta completa que se utilizar para la construccin del entorno de desarrollo que soporta las propuestas metodolgicas de MASAI para la evolucin de servicios y el Gap Analysis. El Subprograma de Personal Tcnico de Apoyo [MICINN-PTA 2009] pertenece al Programa Nacional De Contratacin e Incorporacin de RRHH (Ministerio de Ciencia e Innovacin). El principal objetivo de este subprograma es la cofinanciacin de la contratacin laboral de personal tcnico en los centros de I+D para, de este modo, incrementar y mejorar las prestaciones y rendimiento de estos centros. La duracin de la ayuda, en el caso de la contratacin del doctorando, ha tenido una duracin de dos aos (febrero de 2010 a febrero de 2012). Igualmente conviene mencionar que durante el desarrollo de esta Tesis Doctoral, el doctorando ha formado parte como investigador de las dos ediciones de la Red de Desarrollo de Software Dirigido por Modelos (Red DSDM) [TIN2005-25886-E y TIN2008-00889-E] (2006-2010). El objetivo de esta red ha sido facilitar el intercambio y la transferencia de conocimientos y experiencias entre los distintos grupos de la comunidad de DSDM, as como fomentar su cooperacin, tratando de aunar y articular los esfuerzos nacionales para consolidar

36

lvaro Jimnez Rielo

la posicin espaola y mejorar el reconocimiento internacional en el rea de DSDM. Adems de los proyectos anteriores, el doctorando particip en el proyecto M-DOS [URJC-CM-2007-CET-1607], cofinanciado por la Universidad Rey Juan Carlos y la Comunidad de Madrid. En este proyecto se implement un conjunto de metamodelos, correspondientes al aspecto de comportamiento de la arquitectura de MIDAS.

1.4

Estructura de la Tesis
El resto de los captulos de esta tesis, se organizan de la siguiente manera:

El Captulo 2 presenta el mtodo de trabajo seguido en el desarrollo de esta tesis doctoral. En particular, la seccin 2.1 detalla el mtodo de investigacin. la seccin 2.2 el mtodo seguido para la identificacin del cuerpo de conocimiento y la seccin 2.3, el mtodo de construccin o desarrollo. Por ltimo, la seccin 2.4 presenta el mtodo seguido para llevar a cabo la validacin de esta tesis doctoral. El Captulo 3 proporciona una visin completa sobre el estado del arte. En primer lugar, la seccin 3.1 proporciona una vista general de algunos conceptos previos relacionados con este trabajo. A continuacin se realizan dos revisiones de la literatura para identificar y analizar respectivamente: propuestas para el desarrollo de transformaciones de modelos aplicando los principios del desarrollo dirigido por modelos (seccin 3.2) y propuestas para la gestin de la trazabilidad en el contexto del desarrollo de transformaciones de modelos (seccin 3.3). El Captulo 4 presenta la solucin metodolgica propuesta en esta tesis: MeTAGeM-Trace, un entorno para el desarrollo de transformaciones de modelos dirigido por modelos que incluye un meta-generador de trazas. En primer lugar, la seccin 4.1 presenta un proceso de desarrollo dirigido por modelos para la construccin de transformaciones de modelos, que considera cuatro niveles de abstraccin (incluyendo el cdigo final). Para concretar este proceso, la seccin 4.2 presenta los metamodelos que se utilizan para el modelado de transformaciones a diferentes niveles de abstraccin; la seccin 4.3 presenta la especificacin de las reglas de transformacin que permiten conectar dichos modelos y finalmente la seccin 4.4 recoge las reglas de validacin o restricciones que deben cumplir los modelos terminales conformes a dichos metamodelos.

Introduccin 37

El Captulo 5 presenta la solucin tecnolgica que da soporte a la propuesta metodolgca presentada en el captulo 4. Para ello, en la seccin 5.1 se presenta la arquitectura conceptual de la herramienta, que se plasma en el diseo tcnico presentado en la seccin 5.2, siguiendo el proceso de desarrollo presentado en la seccin 5.3. El Captulo 6 presenta la validacin del trabajo de investigacin de esta tesis doctoral, de acuerdo al mtodo de validacin presentado en el Captulo 2. En la seccin 6.1 se define el protocolo de validacin, en el que se establece el desarrollo de un meta-caso de estudio y de un caso de estudio, mientas que el diseo y la ejecucin de cada uno se detallan en las secciones 6.2 y 6.3, respectivamente. Finalmente, la seccin 6.4 resume las principales conclusiones extradas del proceso de validacin. Finalmente, el Captulo 7 concluye con un resumen de las principales contribuciones de esta tesis. Para ello, se analizan los resultados obtenidos y las publicaciones en las que se han materializado estos resultados. Adems, se plantean una serie de lneas de investigacin futuras que se plantean a raz de este trabajo de tesis doctoral. Adicionalmente, el Apndice A recoge los detalles del proceso de revisin sistemtica de la literatura que se ha llevado a cabo para la identificacin y anlisis de las propuestas centradas en la gestin de la trazabilidad a partir de transformaciones de modelos, mientras que el Apndice B presenta el manual de usuario de la herramienta MeTAGeM-Trace.

Mtodo de Trabajo

2. Mtodo de Trabajo
En este segundo captulo se presentan los diferentes mtodos de trabajo que se han seguido para llevar a cabo esta tesis doctoral. En primer lugar, en la seccin 2.1 se presenta el mtodo de investigacin que define todo el proceso. Dicho mtodo de investigacin, a su vez, engloba otros mtodos que son detallados en este captulo: el mtodo de identificacin del cuerpo de conocimiento (seccin 2.2), el mtodo de desarrollo o construccin (seccin 2.3) y el mtodo de validacin (seccin 2.4).

2.1

Mtodo de Investigacin

Las diferencias que radican en la naturaleza de las Ingenieras, incluida la Ingeniera del Software, respecto de otras disciplinas empricas y formales, dificultan la aplicacin directa de los mtodos de investigacin tradicionales. Teniendo en cuenta esta problemtica, el mtodo de investigacin que se ha seguido en esta tesis se basa en el mtodo propuesto en [141] para la investigacin en Ingeniera del Software. Dicho mtodo se basa en el hipottico-deductivo propuesto por Bunge [43] y se compone de un conjunto de pasos genricos, mostrados en la Figura 2-1, de forma que pueda aplicarse a la investigacin en cualquier disciplina. De acuerdo con este mtodo, el primer paso consiste en identificar un cuerpo del conocimiento y una serie de problemas o puntos de mejora en el estado actual de dicho cuerpo del conocimiento. Esta informacin es identificada mediante el seguimiento de un mtodo de identificacin del cuerpo del conocimiento, que es detallado en la seccin 2.2. Como resultado se obtiene un estado del arte (captulo 3) que servir de base terica sobre la que se desarrolla la investigacin. A partir del anlisis exhaustivo del cuerpo del conocimiento y de sus problemas sin resolver o puntos de mejora, se determina el problema al cual se quiere dar respuesta. Una vez que se ha definido el problema, se formula la hiptesis y se define un conjunto de objetivos que se deben cumplir para alcanzar la solucin que verifique la hiptesis planteada en la Seccin 1.2. El siguiente paso, como se puede ver en la Figura 2-1, consiste en la definicin del mtodo de investigacin (mtodo de trabajo) para la resolucin y validacin del problema. Los autores Marcos y Marcos [141], a diferencia de lo propuesto por Bunge [43], recomiendan definirlo de esta manera, ya que la naturaleza de cada investigacin tiene sus propias caractersticas y por lo tanto, no

42

lvaro Jimnez Rielo

sera conveniente aplicar un nico mtodo universal. En el proceso de investigacin de esta tesis se ha empleado una adaptacin del mtodo de trabajo propuesto en [206] y [31]. Este mtodo se compone de dos etapas principales: resolucin y validacin, que son descritas en detalle en la siguiente sub-seccin.

Cuerpo del Conocimiento Problemas Determinacin del Problema

D O C U M E N T A C I N

Hiptesis

Definicin del Mtodo de Trabajo

Resolucin
Validacin
Anlisis de Resultados y Conclusiones

Redaccin del Informe Final Nuevo Cuerpo del Conocimiento Nuevos Problemas

Figura 2-1. Mtodo de Investigacin propuesto por Marcos y Marcos [141]

Una vez que se han realizado las etapas de resolucin y validacin, la hiptesis y los objetivos planteados deben ser contrastados con los resultados obtenidos, especificando la forma y el grado en que han sido cumplidos. Del mismo modo, es recomendable especificar aquellos aspectos que no se han podido resolver y los nuevos problemas que han podido surgir a partir de la investigacin realizada, ya que esta informacin puede servir como punto de partida para futuras investigaciones [141]. En el captulo 7 de esta tesis doctoral se presenta el anlisis

Mtodo de Trabajo 43

de los resultados, la identificacin de nuevos problemas y las conclusiones obtenidas del proceso de investigacin.

2.1.1

Etapa de Resolucin y Validacin

Como se ha indicado anteriormente, en la etapa de resolucin y validacin se ha seguido una adaptacin del proceso propuesto y validado en [206] y [31]. Se trata de una adaptacin de dos procesos ampliamente conocidos y empleados en el campo de la Ingeniera del Software: el desarrollo en cascada [28, 176] y el Proceso Unificado de Rational (RUP) [98, 122], tomando como base la definicin de etapas consecutivas del primero y el proceso iterativo del segundo. La eleccin de un proceso basado en los dos anteriores para abordar esta tesis doctoral se fundamenta en la similitud que existe entre la naturaleza del problema a resolver y los problemas que surgen en el desarrollo de software. En efecto, existen ciertos problemas de investigacin en Ingeniera del Software (como el que se presenta en esta tesis) que tienen en s mismo una naturaleza ingenieril, ya que se trata de la construccin de nuevos artefactos [139]; en el caso de este trabajo, se trata de construir un entorno para el desarrollo de transformaciones dirigido por modelos, con capacidad para generar modelos de trazas. Dicho entorno estar compuesto por una propuesta metodolgica y una herramienta que proporcione soporte tecnolgico. La Figura 2-2 muestra, de forma simplificada, el proceso de resolucin y validacin empleado en esta tesis doctoral. Este proceso consta de tres iteraciones: 1 Iteracin: Desarrollo del mdulo para el modelado de enlaces de traza. 2 Iteracin: Desarrollo de los mdulos para el modelado de transformaciones de modelos con soporte para la generacin de relaciones de traza. 3 Iteracin: Desarrollo de un meta-caso de estudio. En primer lugar se lleva a cabo la especificacin del proceso a partir del estudio del estado del arte o cuerpo del conocimiento (captulo 3), la hiptesis planteada (seccin 1.2) y la experiencia previa del grupo de investigacin en el que se ha realizado esta tesis doctoral [3, 31, 32, 55, 56, 57, 100, 206, 209, 210].

44

lvaro Jimnez Rielo

Especificacin del Proceso

Entorno MeTAGeM

Resolucin

1 Iteracin Especificacin
(Propuesta Metodolgica)

2 Iteracin

Especificacin (Propuesta Metodolgica)

Especificacin Metamodelo PIM Especificacin Metamodelo PSM Especificacin Metamodelo PDM

Especificacin del Metamodelo de Trazabilidad Especificacin Transformacin PIM - PSM Especificacin Transformacin PSM - PDM Especificacin Transformacin PDM - Cdigo

Especificacin Mtodo de uso

Propuesta Metodolgica MeTAGeM-Trace

Construccin
(Soporte Tecnolgico)

Construccin

(Soporte Tecnolgico) Implementacin Metamodelos PIM, PSM y PDM

Implementacin del Metamodelo de Trazabilidad

Soporte Tecnolgico MeTAGeM-Trace

Implementacin del Editor de Trazas

Implementacin de Editores PIM y PSM

Implementacin de Transformaciones

3 Iteracin
Pruebas
Desarrollo de Pruebas Unitarias
Ejecucin de Pruebas Unitarias

Pruebas
Desarrollo de Pruebas Unitarias Ejecucin de Pruebas Unitarias

Pruebas
Desarrollo de Meta-caso de estudio

Ejecucin de Meta-caso de estudio

Validacin

Figura 2-2. Etapa de Resolucin y Validacin del Mtodo de Investigacin

Una vez realizada esta especificacin, comienza la primera iteracin (desarrollo del mdulo de trazabilidad). Esta iteracin se compone de las fases de especificacin, construccin (resolucin) y pruebas (validacin). La fase de construccin y la fase de validacin se realizan de acuerdo a los mtodos de desarrollo y validacin que se detallan en las secciones 2.3 y 2.4, respectivamente. Los resultados obtenidos en la fase de especificacin y construccin de la primera iteracin, junto con el entorno MeTAGeM [31], sirven como entrada a la segunda iteracin del proceso (desarrollo de los mdulos para el modelado de transformaciones de modelos con soporte para la generacin de enlaces de traza). Esta iteracin tambin se compone de las fases de especificacin, construccin y pruebas. Como resultado, se obtiene la propuesta metodolgica y la herramienta de soporte que se presentan en esta tesis doctoral, que se detallan en los captulos 4 y 5, respectivamente. Por ltimo, la tercera iteracin se compone de una fase de pruebas en la que se desarrolla y ejecuta un meta-caso de estudio que permite llevar a cabo la validacin de la investigacin realizada (Captulo 6).

Mtodo de Trabajo 45

Conviene recordar que la Figura 2-2 muestra una simplificacin del proceso completo. Para mejorar la visualizacin de la misma se han omitido los flujos de retroalimentacin existentes entre los distintos pasos del proceso. A modo de ejemplo, se puede mencionar que el desarrollo de las pruebas unitarias permite refinar la fase de especificacin de la iteracin correspondiente; o que la ejecucin de dichas pruebas unitarias facilita datos para la mejora de la fase de construccin.

2.2

Mtodo de Identificacin del Cuerpo de Conocimiento

Como se ha indicado en la seccin anterior, el punto de partida del mtodo de investigacin consiste en la identificacin de un cuerpo de conocimiento o estado del arte. Para identificar el cuerpo del conocimiento que sirve de base para la investigacin de esta tesis doctoral, se ha empleado un proceso de revisin sistemtica de la literatura (tambin conocido como revisin sistemtica o RS), basado en las guas propuestas por Kitchenham [110, 111] y Biolchini et al. [27]. Una revisin sistemtica es un proceso riguroso desarrollado para identificar, evaluar e interpretar toda la informacin relativa a un tema de investigacin [27, 41, 111]. Una de las principales motivaciones para llevar a cabo un proceso de revisin sistemtica es la gran cantidad de informacin a la que se tiene acceso en la actualidad, gracias a la evolucin de las tecnologas de la informacin en los ltimos aos y especialmente Internet. Disponer de tanta informacin facilita la recopilacin de datos, sin embargo, no todo son ventajas. Ante tal cantidad de datos es muy fcil pasar por alto aquella informacin que a priori parece poco relevante para el objetivo de la investigacin. Adems, es habitual que esta informacin se gestione de forma dinmica [13, 30] de forma que, por ejemplo, el nmero de resultados arrojados por una bsqueda puede aumentar considerablemente despus un cierto periodo de tiempo. A diferencia de una revisin literaria tradicional, una RS sigue una secuencia estricta y bien definida de pasos metodolgicos que garantiza el alto valor cientfico de los resultados obtenidos [27]. Adems, cada uno de los pasos del proceso, las estrategias para recuperar informacin y el enfoque con el que se aborda el tema de investigacin se definen explcitamente, de manera que otros puedan reproducir el protocolo [27]. El proceso de revisin sistemtica seguido en esta tesis doctoral es el mostrado en la Figura 2-3.

46

lvaro Jimnez Rielo

Este proceso se compone de tres fases consecutivas: planificacin (Planning), ejecucin (Execution), anlisis de resultados (Result Analisys); y una cuarta fase de empaquetado (Packaging) que se ejecuta a lo largo de todo el proceso. Adems, se definen dos puntos de control en los cuales se evala que el proceso de revisin sistemtica se est realizando correctamente [27].

Figura 2-3. Proceso de Revisin Sistemtica propuesto por Biolchini et al. [27]

La fase de planificacin consiste en la definicin del objetivo de la investigacin y del protocolo para llevar a cabo la revisin [27]. En dicho protocolo se debe especificar informacin como: preguntas de investigacin a las que se intentar responder con la informacin obtenida en la revisin; estrategias de bsqueda, definiendo las fuentes de informacin y los trminos clave para realizar las bsquedas; criterios de inclusin y exclusin de los estudios que contribuirn a la revisin; y los datos que se extraern de cada estudio [111]. Adems, se debe definir el proceso a seguir durante la fase de ejecucin. En la fase de ejecucin, se ejecuta el protocolo definido previamente, por tanto, se identifican, analizan y evalan los estudios primarios de la revisin sistemtica. Finalmente, en la fase de anlisis de resultados se sintetizan los datos obtenidos en la fase de ejecucin para dar respuesta a las cuestiones de investigacin definidas y al objetivo principal de la revisin sistemtica. De forma paralela a las fases anteriores se lleva a cabo la fase de empaquetado que se encarga de almacenar los resultados de cada una de las fases anteriores.

2.2.1

Proceso para guiar la Revisin Sistemtica

En la etapa de planificacin se debe definir el proceso que guiar la ejecucin de la revisin sistemtica. Para definir dicho proceso, en esta tesis doctoral se ha seguido una adaptacin del proceso presentado por Pino et al. en [169]. Dicho proceso est pensado principalmente para realizar bsquedas en fuentes digitales. El proceso adaptado consiste bsicamente en las tres etapas

Mtodo de Trabajo 47

mostradas en la Figura 2-4: proceso de bsqueda (Figura 2-4a), seleccin de estudios primarios (Figura 2-4b) y extraccin de datos (Figura 2-4c). A continuacin se explica cada una de estas etapas. 2.2.1.1 Proceso de bsqueda El primer paso del proceso de bsqueda consiste en enumerar las fuentes digitales de las cuales se extraern los datos y las cadenas de bsqueda que se usarn en cada fuente. Una vez que se ha identificado esta informacin, se procede a analizar de forma independiente cada motor de bsqueda (DSi) con el objetivo de adaptar las cadenas de bsqueda a las caractersticas de la sintaxis del motor. A continuacin, se comienza a buscar estudios a partir de la ejecucin de cada una de las cadenas adaptadas (QSi) en la fuente digital correspondiente (DSi). Una vez que se ha ejecutado la bsqueda correspondiente, se enumeran y almacenan los estudios obtenidos (SDi). En este paso, para facilitar su posterior identificacin se comienza a extraer algunos datos de los estudios como el ttulo y los autores. A continuacin, los estudios identificados, como resultado de ejecutar QSi en DSi, pasan a la etapa de seleccin de estudios primarios. 2.2.1.2 Seleccin de Estudios Primarios En esta segunda etapa, se analiza cada uno de los estudios identificados en la etapa anterior con el objetivo de saber si cumple con los criterios de inclusin definidos anteriormente. Aquellos estudios que satisfacen los criterios de inclusin se convierten en estudios relevantes de la revisin sistemtica. Este proceso se repite para todas los estudios identificados tras ejecutar la bsqueda de todas las cadenas adaptadas a todas las fuentes de datos seleccionadas. Una vez que se han identificado todos los estudios relevantes, comienza la segunda parte de la etapa de seleccin de estudios primarios (parte derecha de la Figura 2-4b). Esta fase consiste bsicamente en: enumerar los estudios relevantes (RS1RSN); eliminar la duplicidad en dichos estudios, esto es, mantener solo una copia de cada estudio aunque se haya encontrado en varias fuentes; y por ltimo analizar cada uno de los estudios relevantes, de acuerdo a los criterios de exclusin definidos. Esta ltima tarea permitir conocer qu trabajos deben ser excluidos del conjunto de estudios primarios de la revisin sistemtica. Tras analizar todos los estudios relevantes y descartar aquellos que cumplen con los criterios de exclusin, los estudios primarios pasan a la ltima etapa.

48

lvaro Jimnez Rielo

2.2.1.3

Extraccin de datos En la ltima etapa se enumeran los estudios primarios que contribuyen a la revisin sistemtica (PS1PSN). A continuacin, se analiza cada uno de ellos en detalle para extraer la informacin definida anteriormente y que nos permitir dar respuesta al objetivo de la revisin sistemtica.
START

(a)
Enumerate data source: DS1DSN; Select search query strings

(b)
No
More studies?

Enumerate relevant studies RS1RSN; remove SR repeated

More sources?
Yes

No

Yes Select new SDi

More SR? Yes Select new RSi

No

For each DSi, to analyze search engine, adapt query strings to search engine; enumerate search string adapted: QS1QSN

No

More query strings? Yes

Does SDi fulfil the inclusion criterion?

No
Yes

Does RSi fulfil the exclusion criterion? No RSi is a primary study

Yes SDi is a relevant study

Execute a search with QSi on the source DSi; save studies found; enumerate studies discovered SD1..SDN SEARCH PROCESS

PRIMARY STUDIES SELECTION

(c)
Enumerate primary studies PS1PSN More primary studies?
No FINISH

Yes

Select new primary study PSi . Extract information from PSi and save it. Synthesis of that information
DATA EXTRACTION

Figura 2-4. Proceso para guiar la RS: (a) proceso de bsqueda, (b) seleccin de estudios primarios y (c) extraccin de datos.

El resultado de este proceso se presenta en el Captulo 3, donde se presenta el estado del arte que sirve como base terica a la investigacin realizada en esta tesis doctoral.

2.3

Mtodo de Desarrollo

Como se ha indicado en la seccin 2.1.1, la etapa de resolucin de esta tesis doctoral implica la especificacin y construccin de varios lenguajes de modelado que constituyen el ncleo de la propuesta. Por lo tanto, una de las primeras decisiones que debe tomarse es cmo abordar la especificacin e implementacin (o construccin) de dichos lenguajes de modelado. En otras palabras, se debe definir el mtodo de desarrollo de dichos lenguajes de modelado.

Mtodo de Trabajo 49

Un paso previo a la definicin de dicho mtodo es seleccionar la aproximacin a seguir: utilizar perfiles UML o DSLs [226]. En esta tesis doctoral, se ha optado por el empleo de DSLs [73, 145], siguiendo la aproximacin adoptada en MIDAS, el marco metodolgico en el que se enmarca el desarrollo de esta tesis doctoral (seccin 1.3). MIDAS, al igual que otras propuestas como UWE [114], abandon el uso de perfiles UML en favor del empleo de DSLs [206]. El uso de DSLs ofrece una serie de ventajas frente al empleo de perfiles UML [206], algunas de las cuales se hacen an ms evidentes a la hora de desarrollar transformaciones de modelos. Por todo ello, en esta tesis doctoral se ha seguido una adaptacin del mtodo de desarrollo de DSLs propuesto por Vara como resultado de un anlisis exhaustivo del estado del arte sobre soluciones tecnolgicas para soportar las distintas tareas relacionadas con el desarrollo dirigido por modelos [206]. La adaptacin del mtodo de desarrollo que se ha seguido en esta tesis doctoral es mostrado en la Figura 2-5.
Improved EMF Tree-like Editor

CONCRETE SYNTAX DEFINITION

EMF Tree-like Editor

GRAPHICAL 3 EDITORS IMPROVEMENT

ABSTRACT SYNTAX DEFINITION

Ecore Metamodel

ATL

4 MODEL ATL TRANSFORMATIONS Transformations DEVELOPMENT

MOFScript

CODE GENERATION 5 DEVELOPMENT

MOFScript Scripts

AUTOMATIC MODEL VALIDATION

EVL Files

STEP

LEGEND

PRODUCT

INTEGRATION

Integration Plug-ins

Figura 2-5. Mtodo de Desarrollo

Como muestra la Figura 2-5, el mtodo de desarrollo se compone de siete pasos relacionados entre s. A continuacin, se describe cada uno de ellos. 1. El primer paso consiste en la definicin de la sintaxis abstracta del DSL. Para llevar a cabo esta tarea, el metamodelo que define el DSL es

50

lvaro Jimnez Rielo

construido en trminos del lenguaje de metamodelado Ecore, mediante el empleo de Eclipse Modeling Framework (EMF) [42, 85, 194]. 2. El segundo paso consiste en la definicin de la sintaxis concreta del DSL. Para ello, el framework EMF proporciona los medios adecuados para generar editores en forma de rbol que permiten interactuar con modelos terminales conformes al metamodelo definido. Dado que el editor proporcionado por EMF puede resultar demasiado genrico, el tercer paso del proceso consiste en mejorar dicho editor para adaptarlo a las necesidades de la naturaleza del DSL. Una vez que se ha definido el DSL y los medios para crear modelos e interactuar con ellos (editores), es momento de definir las relaciones con otros DSLs ya existentes. As, este paso consiste en el desarrollo de las transformaciones de modelos que permitirn conectar el nuevo DSL con los ya existentes. El desarrollo de estas transformaciones se lleva a cabo mediante los siguientes pasos: Definicin en lenguaje natural de un conjunto de reglas estructuradas. Convertirlas en reglas ejecutables mediante su implementacin con alguno de los lenguajes de transformaciones de modelos existentes [49]. En particular, se propone el uso de ATL ( ATLAS Transformation Language) [104, 105, 107], que ese considerado el estndar de-facto para transformaciones de modelos

3.

4.

5.

Si el DSL se define a nivel PSM o PDM, es posible que se requiera generar cdigo a partir de los modelos elaborados con dicho DSL. En tal caso, el sexto paso consistira en el desarrollo de transformaciones de modelo a texto para la generacin de cdigo. Para llevar a cabo esta tarea, se propone el uso del lenguaje MOFScript [149, 151]. Una vez que se han desarrollado todas las transformaciones (M2M y M2T) en las que se encuentra implicado el DSL, hay que recoger todas aquellas restricciones que no han podido contemplarse en la definicin del metamodelo del DSL o que no han podido ser controladas mediante las transformaciones. Para implementar estas reglas de validacin, se propone utilizar EVL (Epsilon Validation Language, [121]). Finalmente, dado que los pasos anteriores proporcionan como resultado un conjunto de plug-ins, el ltimo paso consiste en realizar la integracin de estos plug-ins entre s y con otros mdulos ya existentes, si fuera necesario.

6.

7.

Mtodo de Trabajo 51

La puesta en prctica de este proceso se presenta en el Captulo 5, donde se explica en detalle los pasos seguidos para la especificacin y construccin de la propuesta metodolgica MeTAGeM-Trace y la herramienta que da soporte a dicha propuesta.

2.4

Mtodo de Validacin

La naturaleza cientfica de la Ingeniera del Software, al igual que otras disciplinas como la fsica, la medicina u otras ingenieras, hace necesaria un componente experimental que permita comprobar y validar las teoras propuestas. As mismo, resulta recomendable experimentar con las tcnicas software para conocer en qu escenarios funcionan correctamente, conocer sus limitaciones y descubrir sus posibles puntos de mejora [18, 189]. Para tal fin, Kish [109] defini tres tipos de investigaciones empricas: encuestas, experimentos e investigaciones simples (o casos de estudio). Las encuestas son investigaciones empricas en las que los sujetos de estudio son una muestra representativa de la poblacin a la que pertenecen [168]; los experimentos son las investigaciones en las que las posibles variables perturbadoras han sido aleatorizadas pero pueden controlarse [19]; y los casos de estudio son aquellos en los que no hay aleatoriedad de las variables perturbadoras, que no pueden controlarse, ni representatividad de los sujetos que componen la muestra del estudio [230]. Dado que los casos de estudios nos permiten analizar el comportamiento de una propuesta dentro de su contexto real [230], en esta tesis doctoral empleamos casos de estudio de laboratorio para la validacin de la propuesta planteada. De acuerdo con las ideas expuestas en [20, 67, 230], la Figura 2-6 muestra el proceso que se ha seguido en esta tesis doctoral para llevar a cabo la validacin del trabajo de investigacin presentado mediante el empleo de casos de estudio. Obviamente, el proceso parte de una propuesta de la que se desea analizar diferentes aspectos de su comportamiento en un contexto real.

Propuesta

Seleccionar Caso de Estudio

Protocolo de Recogida de Datos

Diseo y Ejecucin del caso de estudio

Elaboracin del inform e y conclusiones

Contexto
Figura 2-6. Proceso de Validacin mediante Casos de Estudio

52

lvaro Jimnez Rielo

El primer paso del proceso consiste en la definicin de uno o varios casos de estudio. Para ello, es necesario conocer en profundidad la propuesta a validar, el contexto de la misma y los aspectos que se desean analizar [20]. Dado que, en la mayora de los casos, mediante uno o varios casos de estudio no es posible generalizar el comportamiento de la propuesta bajo todas las circunstancias posibles, resulta recomendable seleccionar aquellos casos de estudio que sean suficientemente representativos, completos y que proporcionen el mayor aprendizaje posible como resultado de su desarrollo y ejecucin [193]. A continuacin, se debe definir el protocolo para la recogida de datos. Esta fase consiste en la elaboracin de un protocolo que proporcione una visin global del caso de estudio, procedimientos de campo (credenciales, lugares en los que se ejecutar el caso de estudio, etc.), cuestiones del caso de estudio y una gua para documentar el caso de estudio [230]. As mismo, en cuanto a la recoleccin de datos en s misma, los datos correspondientes al desarrollo de un caso de estudio pueden encontrarse, segn Yin [230], en varios tipos de fuentes distintas: documentacin, registro de archivos, entrevistas, observaciones directas, observaciones participantes y artefactos fsicos, aunque no solo se limita a ellas [20, 67]. Para maximizar el beneficio que proporcionan estas fuentes de datos, Yin [230] propone seguir tres principios en la recoleccin de datos: 1. Uso de mltiples fuentes de informacin para corroborar la misma evidencia o fenmeno. 2. Crear una base de datos del caso de estudio. 3. Mantener una cadena de evidencias de forma que un observador externo pueda ser capaz de seguir el camino entre las evidencias identificadas en el caso de estudio. El tercer paso consiste en el diseo y ejecucin del caso de estudio seleccionado. En cuanto al diseo del caso de estudio, Yin [230] propone definir secuencialmente: 1. Las preguntas a las que se quiere responder. 2. Las proposiciones que se analizarn. 3. Las unidades de anlisis que se derivan de las preguntas y las proposiciones. 4. La relacin existente entre las preguntas y las proposiciones definidas. 5. Los criterios para interpretar los resultados. Adems de proponer los pasos anteriores, Yin [230] establece que para evaluar la calidad de diseo de cualquier caso de estudio se pueden realizar test

Mtodo de Trabajo 53

que garanticen la validez de construccin, la validez interna, la validez externa y la fiabilidad. En cuanto a la ejecucin del caso de estudio, como su nombre indica, consiste en poner en prctica el caso de estudio diseado y recopilar aquellos datos definidos en la fase anterior, que son necesarios para llevar a cabo la siguiente. Por ltimo, se elabora el informe correspondiente al desarrollo y ejecucin del caso de estudio, de acuerdo a la gua establecida en la fase de definicin del protocolo de recogida de datos. Para llevar a cabo el informe del caso de estudio se deben tener en cuenta aspectos tales como la audiencia a la que se dirige, si forma parte de un estudio ms amplio o constituye un estudio en s mismo y el tipo de caso de estudio realizado [20, 67, 193, 230]. Yin propone seis tipos de estructuras diferentes para llevar a cabo el informe: analtica-lineal, comparativa, cronolgica, construccin de teora, suspenso y no secuencial [230]. A partir del informe, se analizan los resultados obtenidos en el desarrollo y ejecucin del caso de estudio y se extrae un conjunto de conclusiones que permiten analizar la validez de la propuesta inicial. En caso necesario, con la informacin obtenida se podrn corregir y mejorar las debilidades detectadas en la propuesta [230]. La puesta en prctica de este proceso se presenta en el Captulo 6, donde se detalla el desarrollo de la transformacin UML2XMLSchema, correspondiente a uno de los mdulos de la herramienta M2DAT. Esta transformacin ya ha sido desarrollada y probada anteriormente [206, 208, 215], por lo que se dispone de informacin suficiente para medir y analizar los resultados obtenidos en la ejecucin del caso de estudio.

Estado del Arte

3. Estado del Arte

En el contexto de MDE, los modelos y las transformaciones entre dichos modelos son los artefactos clave en cualquier proceso de desarrollo [14, 23, 108, 182]. De hecho, el Desarrollo de Software Dirigido por Modelos (DSDM) [192], que es la aplicacin de los principios de MDE a la construccin de software, propone definir el sistema mediante modelos con un alto nivel de abstraccin y refinarlos (semi-)automticamente por medio de transformaciones de modelos hasta que su nivel de abstraccin permita utilizarlos como entrada para la generacin de cdigo (o para ser directamente ejecutados) [22, 108, 185]. Este escenario, en el que se construye software (semi-)automticamente a partir de la ejecucin de transformaciones de modelos, proporciona las bases para abordar la automatizacin de otras actividades, como la gestin de la trazabilidad. En concreto, dado que una transformacin es una forma de definir las relaciones que deben satisfacerse entre los elementos de los modelos implicados en la transformacin, sera posible aprovechar dichas relaciones para derivar la creacin de las trazas que las hacen explcitas. Sin embargo, poner en prctica esta idea implica aumentar la complejidad de las transformaciones, ya que se debe aadir el cdigo que se encargue de la creacin de las trazas. Una forma de paliar este aumento de la complejidad pasa por aplicar los principios de MDE para (semi)automatizar el desarrollo de transformaciones [23, 24, 58, 128]. Por todo ello, esta tesis doctoral se centra en aprovechar las ventajas que proporciona la aplicacin de MDE al desarrollo de transformaciones con el objetivo de aumentar el nivel de automatizacin en la gestin de la trazabilidad. As, en este captulo se ofrece una visin global del estado del arte de las reas relacionadas con la cuestin de investigacin que se aborda. En primer lugar, con el fin de contextualizar la presente tesis doctoral y proporcionar un vocabulario comn, se definen en detalle los conceptos bsicos relacionados (seccin 3.1); a continuacin se presenta una revisin de la literatura que analiza las propuestas existentes para el desarrollo dirigido por modelos de transformaciones de modelos (seccin 3.2) y finalmente se presenta otra revisin de la literatura que estudia las propuestas centradas en la gestin de la trazabilidad a partir del desarrollo de transformaciones de modelos (seccin 3.3).

58

lvaro Jimnez Rielo

3.1

Conceptos Previos

A lo largo de la historia de la Ingeniera del Software, ha sido necesario realizar grandes esfuerzos con el objetivo de alcanzar un acuerdo en cuanto al uso de una terminologa comn [2, 37]. Este problema se hace mayor cuando se trata de una disciplina como la Ingeniera Dirigida por Modelos que se encuentra en proceso de expansin y madurez [187, 201, 221]. Por ello, en las siguientes secciones se exponen algunas definiciones y conceptos previos, necesarios para entender el cuerpo del conocimiento en el que se basa la propuesta que se presenta en esta tesis doctoral.

3.1.1

Modelado

Como ya se ha podido comprobar en captulos anteriores, los modelos son uno de los conceptos clave en el contexto de la Ingeniera Dirigida por Modelos. Sin embargo, tambin es clave en un gran nmero de disciplinas cientficas, por lo que existen numerosas definiciones acerca de qu es un modelo [125, 180]. Por ello, en esta seccin se especifica qu se entiende por modelo y metamodelo en el contexto de esta tesis doctoral. En particular, un modelo es entendido como una simplificacin de un sistema, construido con un objetivo en mente. En este sentido, los modelos deben ser capaces de responder a preguntas sobre el dominio del sistema del mismo modo que respondera el propio sistema [26]. La definicin anterior est muy relacionada con la forma en la que las ingenieras tradicionales hacen uso de los modelos. En dichas disciplinas los modelos son definidos como paso previo a la construccin de los sistemas, actuando como planos o mapas que proporcionan una especificacin que describe el comportamiento y la estructura del sistema. Siguiendo esta lnea, la Ingeniera del Software ha adoptado el modelado como una de sus prcticas ms comunes con el objetivo de definir el sistema a construir, especificando su estructura y comportamiento [171, 190]. En este sentido, en el contexto de MDE es ampliamente aceptada la definicin de modelo software propuesta por Kleppe et al. en [112]: un modelo es una descripcin (o parte) de un sistema en un lenguaje bien-formado (Figura 3-1 (a)). Un lenguaje de modelado bien-formado es aquel que define los elementos que pueden formar parte de un modelo as como las relaciones que pueden darse entre estos elementos. Generalmente, esta informacin es recogida por el metamodelo del lenguaje. As pues, un metamodelo no es ms que un modelo que

Estado del Arte 59

permite establecer las condiciones para que los modelos expresados en un determinado lenguaje se consideren vlidos [14, 45, 184]. En algunos casos, un metamodelo es creado conforme al lenguaje que l mismo define. Y en tal caso, se denomina metametamodelo. En la Figura 3-1 (b) se representa la jerarqua de modelado que muestra la relacin existente entre los metametamodelos, los metamodelos y los modelos [26]. De acuerdo a esta jerarqua, un modelo terminal se define de acuerdo a las reglas definidas en otro modelo (metamodelo), que a su vez es definido conforme a otro modelo (metametamodelo), el cual se define de acuerdo a s mismo. La Figura 3-1 (c) ilustra la idea de que un metamodelo es bsicamente un modelo que se describe de acuerdo a otro metamodelo [112].

Lenguaje de Modelado

(a)
c2
Metametamodelo

(b)

(c)

expresado en

Modelo

c2
Modelo Metamodelo
describe

describe

c2
Modelo Terminal Sistema

Metamodelo

*c2: Conforme a

Figura 3-1. a) Definicin de Modelo (Kleppe et al.), b) Jerarqua de Modelado y c) Relacin entre los conceptos Modelo y Metamodelo

3.1.2

Transformaciones de Modelos

En la seccin anterior se ha indicado qu se entiende por modelo y cul es su finalidad en el contexto de esta tesis doctoral. En esta seccin se describe cmo se relacionan los modelos entre s. Trabajar con modelos interrelacionados implica invertir grandes esfuerzos a la hora de realizar ciertas tareas relacionadas con la gestin de dichos modelos como por ejemplo el mantenimiento, el refinamiento o la refactorizacin. Es habitual que dichas tareas se lleven a cabo mediante transformaciones de modelos. Una transformacin de modelos es un proceso automatizado que toma uno o varios modelos origen y produce uno o varios modelos destino, a partir de la ejecucin de un conjunto de reglas [188].

60

lvaro Jimnez Rielo

En el contexto de MDE, hay distintas definiciones de qu es una transformacin de modelos [206]. A modo de ejemplo, en la gua de MDA (Model-Driven Architecture [157], pg. 17) se dice que: una transformacin de modelos es el proceso de convertir un modelo en otro modelo del mismo sistema. En particular, en el contexto de esta tesis doctoral, se adopta la definicin basada en el concepto de metamodelo propuesta por Bzivin [22] y esbozada anteriormente por Lemesle [133] (Figura 3-2).

MetaMetaModelo (MMM)

Conf orme a Usa

Metamodelo A (MMa)

Metamodelo de Transf ormaciones de Modelos (MtMM)

Metamodelo B (MMb)

Transf ormacin de Modelos (MMa2MMb)

Modelo A (Ma)

origen

destino

Modelo B (Mb)

Motor de Transformacin de Modelos

Figura 3-2. Proceso de Transformacin de Modelos

El principal elemento en este proceso es el metametamodelo (MMM), que proporciona un conjunto de abstracciones que permiten la definicin de nuevos metamodelos. As, en la Figura 3-2 se puede ver que se han definido los metamodelos origen (MMa) y destino (MMb) de la transformacin como instancias de dicho metametamodelo, es decir, MMa y MMb son conformes a MMM. Para realizar la transformacin entre cualquier modelo origen conforme a MMa (Ma) y cualquier modelo destino conforme a MMb (Mb) es necesario definir un conjunto de reglas que relacionen los elementos de dichos metamodelos. Estas reglas son recogidas en una transformacin de modelos (MMa2MMb). Dicha transformacin ser ejecutada por el motor de transformacin, permitiendo generar modelos destino a partir de cualquier modelo conforme al metamodelo origen. Adems, si el conjunto de reglas y restricciones que guan la construccin de la transformacin es recogida en un metamodelo (MtMM), cualquier

Estado del Arte 61

transformacin de modelos puede ser tratada como un modelo, es decir podremos generarla, transformarla o validarla como cualquier otro modelo del sistema [21, 24]. Esta concepcin de las transformaciones como modelos ofrece una serie de ventajas. En particular, las transformaciones cuya origen y/o destino son modelos de transformaciones reciben el nombre de transformaciones HOT (Higher Order Transformation) [197] y como se ver ms adelante, juegan un papel clave en esta tesis doctoral.

3.1.3

Ingeniera Dirigida por Modelos

Del mismo modo que los primeros lenguajes de programacin (por ejemplo, el lenguaje ensamblador) alejaban a los programadores de los complejos desarrollos en cdigo mquina y estos a su vez, dejaron paso a otros lenguajes de mayor nivel de abstraccin como C o Fortran [182, 221], la Ingeniera Dirigida por Modelos o MDE surge como un paso natural en esta tendencia histrica de elevar el nivel de abstraccin al que se disea y construye el software. En particular, MDE propone centrarse en el espacio del problema en lugar de centrarse en la codificacin (espacio de la solucin). Para ello, los modelos y las transformaciones entre dichos modelos juegan un papel central en los procesos de desarrollo, convirtindose en la base de este paradigma [22, 69, 108, 182, 185, 221]. De acuerdo a su objetivo final, es posible identificar distintas disciplinas que ponen en prctica los principios de MDE (Figura 3-3).

MDE

MDSD

MDRE

MDA

ADM

Figura 3-3. Disciplinas MDE

62

lvaro Jimnez Rielo

En la rama izquierda de la Figura 3-3 se encuentran aquellas disciplinas que aplican los principios de MDE a la Ingeniera del Software Directa: el Desarrollo de Software Dirigido por Modelos (MDSD, Model-Driven Software Development) [192] y la Arquitectura Dirigida por Modelos (MDA) [157]. En la rama de la derecha se encuentran las disciplinas que aplican los principios de MDE a la Ingeniera del Software Inversa: la Ingeniera Inversa Dirigida por Modelos (MDRE) [177] y la Modernizacin Dirigida por la Arquitectura ( ADM) [154]. Esta tesis doctoral se enmarca en el contexto de las dos primeras (MDSD y MDA), que se describen en detalle en las siguientes secciones.

3.1.4

Desarrollo de Software Dirigido por Modelos

El Desarrollo de Software Dirigido por Modelos (DSDM) es la aplicacin de los principios de MDE al desarrollo de software [91, 185, 192]. Esta disciplina no solo tiene por objetivo incrementar el nivel de abstraccin, sino que adems propone aumentar el nivel de automatizacin en el desarrollo de software. Para ello, propone especificar los sistemas mediante modelos a diferentes niveles de abstraccin, de forma que los modelos de ms alto nivel se convierten en otros de menor nivel hasta alcanzar modelos ejecutables mediante la generacin de cdigo [72] o la interpretacin de modelos [1, 51, 65, 135, 229]. En este escenario, la clave para aumentar el nivel de automatizacin es el empleo de transformaciones de modelos que permiten el paso de un modelo a otro de menor nivel de abstraccin. La Figura 3-4 sirve para ilustrar esa idea: cada paso de un proceso de DSDM consiste en aplicar un conjunto de reglas de transformacin sobre uno o varios modelos origen para producir uno o varios modelos destino con menor nivel de abstraccin. Estos modelos destino a su vez, sern modelos origen del siguiente paso del proceso.
Nivel de Abstraccin N+1 Nivel de Abstraccin N
FinancialTransactionBase CreationData +creationData 1 FinancialTransactionConsum erData 1 +displayStatus 1 DisplayStatus

Nivel de Abstraccin N-1

FinancialTransactionData 1

+processingData 1

ProcessingData 0..1

<<enumeration>> FinancialTransactionTypeCode PAYMENT FUNDS_TRANSFER 1 +transactionType

+status FinancialTransaction 0..1 1 +specification FinancialTransactionExtended 0..1 * +note 0..1 * {ordered}

ProcessingStatus +status +previousStep 0..1 ProcessingStep 1

CurrencyAmount

+amount 1 0..1

FinancialTransactionSpecification

Note

Transformacin de Modelos N+1 N

Transformacin de Modelos N N-1

Figura 3-4. Simplificacin de un proceso de DSDM

Estado del Arte 63

3.1.5

Arquitectura Dirigida por Modelos

Una de las interpretaciones ms fieles de los principios de MDE es la Arquitectura Dirigida por Modelos (MDA, Model-Driven Architecture) [71, 74, 90, 112, 144, 157, 186, 226], de hecho Favre en [69] considera que MDA es la encarnacin de MDE. MDA, presentado en el ao 2001 por el consorcio OMG (Object Management Group), es un marco de desarrollo software alineado con los principios de MDE (rol de los modelos y automatizacin). El principal objetivo de MDA es separar la especificacin de un sistema concreto de los detalles relacionados con el uso de la plataforma por parte de dicho sistema. Para alcanzar este objetivo se centra en la definicin de modelos formales como elementos de primera clase para el diseo e implementacin de sistemas y la definicin de transformaciones (semi-)automticas entre los modelos [157]. Uno de los rasgos distintivos de MDA es que define tres grandes grupos de modelos de acuerdo a su nivel de abstraccin. Los requisitos del sistema se modelan mediante modelos independientes de computacin (CIM, Computation Independent Model). Los modelos independientes de plataforma (PIM, Platform Independent Model) sirven para representar la funcionalidad y estructura del sistema, omitiendo los detalles tecnolgicos asociados a las caractersticas especficas de la plataforma que soportar al sistema. Finalmente, las especificaciones descritas a nivel PIM son adaptadas a los detalles de plataformas concretas por medio de los modelos especficos de plataforma (PSM, Platform Specific Model), a partir de los cuales se genera el cdigo del sistema. En el nivel PSM es posible definir modelos que representan distintos grados de abstraccin, pudindose agrupar en modelos que describen elementos comunes y en modelos que contienen elementos especficos de una plataforma concreta. Estos modelos intermedios, se denominan modelos dependientes de plataforma (PDM, Platform Dependent Models) [79, 157, 170]. La Figura 3-5 ilustra una simplificacin de las relaciones entre las capas de abstraccin definidas por MDA as como las interacciones existentes entre modelos de los diferentes niveles. Con esta categorizacin de modelos, un proceso de desarrollo basado en MDA comienza con la definicin de los modelos correspondientes a la capa de abstraccin CIM (en la prctica, esta actividad se omite en cierto escenarios). Ntese que mientras que estos modelos definen el dominio del negocio, los niveles inferiores especifican el dominio del sistema. Por ello, no siempre es posible establecer una transformacin directa entre los requisitos del sistema,

64

lvaro Jimnez Rielo

especificados en la capa CIM, y los artefactos representados en las capas inferiores. En cambio, MDA s define transformaciones concretas PIM-PSM y PSM-PDM entre los artefactos de dichas capas.

CIM

PIM

<<transformation>>

PSM

<<transformation>>

PDM

<<transformation>>

Code

Figura 3-5. Niveles de abstraccin MDA

Otro rasgo distintivo de MDA es que potencia el uso de los estndares definidos por la OMG. Entre estos estndares se encuentran: UML [160], MOF [158], OCL [159], XMI [161] y QVT [155].

3.1.6

Trazabilidad

En el contexto de la Ingeniera del Software el trmino trazabilidad ha sido asociado tradicionalmente a las tareas de gestin de requisitos [5, 172]. De

Estado del Arte 65

hecho, Gotel y Finkelstein [81] definen la trazabilidad como: la capacidad para describir y seguir la vida de un requisito, tanto hacia delante como hacia atrs. En este contexto, el principal objetivo de la gestin de la trazabilidad es asegurar que el software desarrollado cumple con las expectativas del usuario (o cliente), de forma que permita comprobar si cada requisito ha sido satisfecho o si cada componente del sistema satisface al menos un requisito [11, 172]. Sin embargo, este concepto ha evolucionado a lo largo del tiempo y actualmente la trazabilidad se identifica con las relaciones existentes entre los artefactos implicados en el ciclo de vida del software [5]. En este sentido, una de las definiciones ms aceptadas es la propuesta por la IEEE [95], que define la trazabilidad como: el grado de relacin que puede establecerse entre dos o ms productos de un proceso de desarrollo, especialmente productos que tienen relaciones predecesor-sucesor o maestro-subordinado con otro producto. La informacin obtenida a partir de la gestin de la trazabilidad puede facilitar el desempeo de otras actividades que forman parte del ciclo de vida del software. As, por ejemplo, puede utilizarse para la toma de decisiones, el anlisis del impacto del cambio, el mantenimiento del sistema o la validacin y verificacin de los requisitos [5, 39, 96, 113, 143, 147, 172, 228]. Adems, algunos estndares, centrados en la mejora de los procesos software como el ISO12207 consideran la gestin de la trazabilidad como una medida de calidad [96]. En cualquier desarrollo dirigido por modelos, la gestin de la trazabilidad cobra an ms importancia debido a la naturaleza de estos desarrollos. Como se ha mencionado anteriormente, el sistema se desarrolla a partir de la especificacin de modelos de alto nivel que se transforman (semi-)automticamente en otros modelos de menor nivel de abstraccin. Dado que los desarrolladores de los modelos iniciales y de las transformaciones no tienen por qu ser los mismos e incluso pueden ser diferentes de los que ejecutan dichas transformaciones, la trazabilidad es un concepto crucial ya que proporciona informacin acerca de cmo y porqu son creados los artefactos del sistema [117, 153]. Aprovechando las caractersticas mencionadas del DSDM, esta tesis doctoral se centra en identificar relaciones de trazabilidad a partir de las relaciones existentes en las transformaciones que guan el proceso de desarrollo y en generar enlaces de traza entre las instancias de los elementos implicados en dichas transformaciones. En este punto, es necesario establecer la diferencia que se establece, en el contexto de esta tesis doctoral, entre relacin de trazabilidad y enlace de traza:

66

lvaro Jimnez Rielo

mientras que las relaciones de trazabilidad son aquellas que se definen entre tipos de elementos (por ejemplo, clases o elementos de un metamodelo), los enlaces de traza (o simplemente trazas) son las instancias de dichas relaciones (por ejemplo, entre objetos o elementos de un modelo). A modo de ejemplo, en la Figura 3-6, se puede observar que se ha definido una relacin de trazabilidad entre las clases Alumno y AlumnoUI. En la prctica, esta relacin se traduce en un conjunto de enlaces de traza entre cada par de objetos que instancien dichas clases (cada objeto Alumno tiene asociado un objeto AlumnoUI que define su interfaz). As, se han creado dos enlaces de traza: uno entre los objetos alumno1 (instancia de la clase Alumno) y alumnoUI1 (instancia de la clase AlumnoUI) y otro entre los objetos alumno2 y alumnoUI2.

Alumno

Relacin de Trazabilidad

AlumnoUI

Enlace de Traza
:alumno1 :alumnoUI1

Enlace de Traza

:alumno2
<<instancia de>>

:alumnoUI2

Figura 3-6. relacin de trazabilidad vs enlace de traza

3.2

Propuestas para el Desarrollo Dirigido por Modelos de Transformaciones de Modelos

Una vez que las tecnologas que dan soporte a las tareas propias de MDE han alcanzado ciertos niveles de madurez [221], los investigadores han comenzado a abordar proyectos cada vez ms extensos y complejos. Como consecuencia, las transformaciones de modelos que se desarrollan en estos proyectos son tambin ms extensas y complejas, de forma que resulta recomendable seguir un proceso de desarrollo propio, que permita asegurar y validar su construccin [68, 80]. Adems, dado que estas transformaciones son construidas en el contexto de un proceso dirigido por modelos, parece lgico y deseable aplicar los principios del

Estado del Arte 67

DSDM a su desarrollo [23, 24, 58, 88, 103, 128, 153]. As, las transformaciones de modelos deberan especificarse como modelos de alto nivel y ser refinadas (semi-)automticamente en modelos ms detallados (de menor nivel de abstraccin), hasta obtener el cdigo de la transformacin o modelos ejecutables. Por todo ello, en esta seccin se realiza un estudio de la literatura para identificar y analizar aquellas propuestas que ponen en prctica este planteamiento. Es necesario apuntar que el estudio de la literatura que se hace en esta seccin no corresponde a un proceso de revisin sistemtica completo, sino que se trata de una evolucin y mejora del estado del arte presentado en [31]. En las siguientes sub-secciones se presentan los objetivos o cuestiones de investigacin a las que se quiere dar respuesta con este estudio de la literatura (seccin 3.2.1), los criterios que se emplean para evaluar y comparar cada una de las propuestas identificadas en la literatura (seccin 3.2.2), los datos que se extraen de cada propuesta (seccin 3.2.3), el anlisis detallado de cada una de ellas (seccin 3.2.4) y por ltimo, se presentan las conclusiones obtenidas del estudio de la literatura (seccin 3.2.5).

3.2.1

Cuestiones de Investigacin

El principal objetivo de este estudio de la literatura es identificar y analizar las propuestas centradas en aplicar los principios del desarrollo dirigido por modelos a la construccin de transformaciones de modelos. Para dar respuesta a este objetivo se proponen las siguientes cuestiones de investigacin (CI), a las que se responde en la seccin 3.2.5, una vez que se han identificado y analizado las propuestas: CI-1. A qu niveles de abstraccin se propone especificar las transformaciones de modelos? Las propuestas a analizar estn centradas en el Desarrollo Dirigido por Modelos (DDM) de transformaciones de modelos y uno de los pilares del DDM es especificar el sistema (en este caso, una transformacin) mediante modelos a diferentes niveles de abstraccin. Por tanto, es relevante conocer a qu niveles de abstraccin es factible modelar las transformaciones. CI-2. Qu ideas se proponen para automatizar el proceso de desarrollo de las transformaciones? Otro de los principios bsicos del DDM es la automatizacin del paso entre los diferentes niveles de abstraccin a los que se especifica el sistema, por ejemplo a travs de transformaciones de modelos. As, en esta segunda

68

lvaro Jimnez Rielo

pregunta se analiza cmo se propone automatizar el paso entre los modelos de los distintos niveles de abstraccin y la generacin del cdigo que implementa la transformacin (si aplica). CI-3. Existen propuestas metodolgicas centradas en el DDM de transformaciones de modelos que propongan o sugieran ideas para la gestin de la trazabilidad a partir del modelado de dichas transformaciones? El principal objetivo de esta tesis doctoral es dar soporte a la generacin de enlaces de traza a partir del modelado de transformaciones. Por ello, esta cuestin de investigacin analiza si las propuestas para el DDM de transformaciones de modelos ofrecen ideas o mtodos para la gestin de la trazabilidad a partir del modelado de dichas transformaciones. CI-4. Existen herramientas que soporten el DDM de transformaciones de modelos? En esta cuarta pregunta se analiza si las propuestas metodolgicas han sido puestas en prctica, es decir, si existen herramientas que soporten el DDM de transformaciones de modelos. En caso afirmativo, se analiza dicho soporte. CI-5. Cules son las limitaciones del estado del arte en el DDM de transformaciones de modelos? Finalmente, en la ltima cuestin se combinarn las respuestas a las preguntas anteriores (CI-1, CI-2, CI-3 y CI-4) para identificar problemas o limitaciones en el estado del arte actual.

3.2.2

Criterios de Evaluacin

Una vez que se han seleccionado los estudios que ayudarn a dar respuesta a las preguntas anteriores, sera deseable disponer de mecanismos para evaluar y comparar dichos estudios. Por tanto, de acuerdo a la gua para realizar una revisin sistemtica propuesta por Kitchenham y Charters [111], en esta seccin se define un conjunto de criterios de evaluacin (CE) y los valores que puede adoptar cada criterio para evaluar la calidad de cada una de las propuestas identificadas y proporcionar una comparativa cuantitativa. Para facilitar la comparativa, los valores que se pueden asignar para cada uno de los criterios de evaluacin son: S (S) = 1; Parcial (P) = 0.5; y No (N) = 0. Los criterios de evaluacin para propuestas centradas en el DDM de transformaciones de modelos son:

Estado del Arte 69

CE-1. La propuesta metodolgica propone especificar la transformacin en los niveles PIM y PSM definidos por MDA [157] antes de ser serializada en cdigo? Valores: (S), la propuesta define explcitamente que las transformaciones de modelos deben ser especificada al menos en estos dos niveles o equivalentes; (P)arcial, la propuesta contempla que las transformaciones sea definida, al menos, a nivel PIM o PSM (o equivalentes); (N)o, la propuesta no contempla el modelado de las transformaciones a ninguno de estos niveles.

CE-2. La propuesta metodolgica sugiere cmo automatizar el paso entre los diferentes niveles de abstraccin a los que se especifican las transformaciones? Valores: (S), proporciona mtodos para automatizar o semi-automatizar la conversin de modelos a distintos niveles de abstraccin, por ejemplo, mediante transformaciones entre dichos modelos; (P)arcial, no indica cmo automatizar el proceso, sin embargo, considera que es una caracterstica deseable; (N)o, el paso entre los niveles es totalmente manual.

CE-3. La propuesta metodolgica especifica cmo generar el cdigo que implementa las transformaciones desarrolladas? Valores: (S), indica cmo llevar a cabo la serializacin de los modelos de bajo nivel que describen las transformaciones; (P)arcial, no especifica cmo ponerlo en prctica, pero identifica la generacin de cdigo como una caracterstica deseable; (N)o, no considera la generacin del cdigo que implementa las transformaciones.

CE-4. Propone algn mecanismo para visualizar los modelos de transformacin? Valores: (S), propone el desarrollo de un editor o visualizador ad-hoc, que considere la naturaleza de los modelos de transformacin; (P)arcial, propone la representacin de los modelos a travs de mtodos genricos para cualquier tipo de modelo como por ejemplo el editor en forma de rbol que ofrece EMF [194], por tanto no es una representacin ptima; (N)o, la propuesta no considera la visualizacin de modelos o no sugiere ninguna forma de representacin.

CE-5. La propuesta metodolgica proporciona o sugiere mecanismos de validacin de los modelos de transformacin, de forma que los errores no se propaguen a los modelos de menor nivel de abstraccin?

70

lvaro Jimnez Rielo

Valores: (S), indica cmo deberan validarse los modelos de transformacin para asegurar que son correctos; (P)arcial, no indica cmo deben validarse los modelos, pero considera que es una caracterstica deseable; (N)o, no considera en absoluto la validacin de modelos. CE-6. La especificacin a alto nivel de las transformaciones es independiente de cualquier lenguaje de transformacin concreto? Valores: (S), la definicin de las transformaciones a alto nivel es independiente de cualquier lenguaje de transformacin; (P)arcial, la especificacin de las transformaciones no es completamente independiente, o es dependiente de un lenguaje concreto pero consideran deseable que fuera independiente; (N)o, la especificacin de las transformaciones es totalmente dependiente de un lenguaje concreto. CE-7. La propuesta metodolgica considera la gestin de la trazabilidad a partir del DDM de transformaciones de modelos? Valores: (S), propone cmo gestionar la trazabilidad a partir del desarrollo de transformaciones; (P)arcial, no indica cmo, pero considera que sera posible gestionar trazabilidad a partir de las transformaciones; (N)o, no considera en absoluto la gestin de la trazabilidad en el DDM de transformaciones. CE-8. Proporciona alguna implementacin, herramienta, o soporte tecnolgico? Valores: (S), proporciona una herramienta o marco de trabajo completo para dar soporte a la propuesta metodolgica; (P)arcial, proporciona una implementacin parcial de la propuesta; (N)o, se trata de una propuesta puramente terica que no se ha implementado.

3.2.3

Extraccin de Datos

Para facilitar el anlisis y evaluacin de las propuestas que forman el estado del arte y dar respuesta a las preguntas anteriores, es necesario recopilar cierta informacin de dichas propuestas. As, para las propuestas centradas en el DDM de transformaciones de modelos se ha decidido extraer la siguiente informacin: Ttulo, autores, resumen y ao de publicacin de cada estudio identificado (perteneciente a la propuesta). El ttulo, los autores y ao de cada publicacin puede consultarse en las referencias de esta memoria de tesis doctoral.

Estado del Arte 71

Niveles de abstraccin que considera para el modelado de la transformacin. Si automatiza el DDM de transformaciones de modelos. Si proporciona o sugiere cmo sera posible generar el cdigo que serializa los modelos de la transformacin. Si sugiere cmo deberan visualizarse los modelos que especifican la transformacin. Si considera o recomienda la validacin de los modelos que especifican la transformacin. Si considera la gestin de la trazabilidad a partir del DDM de transformaciones de modelos. Si ofrece soporte tecnolgico y cmo lo hace (si aplica).

La extraccin de estos datos se presenta en la siguiente sub-seccin, donde se analiza en detalle cada una de las propuestas por separado.

3.2.4

Anlisis de las propuestas

Una vez que se ha definido la informacin que se va a extraer y evaluar de cada propuesta, en esta seccin se analizan de forma individual las propuestas identificadas y se comparan dichas propuestas de acuerdo a los criterios de evaluacin definidos en la seccin 3.2.2. Cada una de las propuestas (o grupos de estudios primarios) est formada por aquellos estudios que tienen uno o ms autores en comn y las ideas que se defienden en dichos trabajos corresponden a una misma lnea de investigacin. 3.2.4.1 Bzivin et al. Segn los autores de la propuesta presentada en [25], en los desarrollos MDA, la mayor parte de las transformaciones son codificadas en un lenguaje propietario e inestable. Frente a esta tendencia, los autores defienden que las transformaciones deberan ser tratadas como cualquier otro artefacto software y por tanto, deberan analizarse, disearse, implementarse, probarse y mantenerse de forma independiente a cualquier plataforma. Por todo ello, Bzivin et al. proponen aplicar los principios de MDA al desarrollo de las transformaciones de modelos [25]. En particular, proponen especificar dichas transformaciones a dos niveles de abstraccin, que se corresponden con los niveles PIM y PSM definidos por MDA: p latformindependent transformations (PIT) y platform-specific transformations (PST). En

72

lvaro Jimnez Rielo

este contexto se entiende plataforma como la herramienta que permite realizar la especificacin, diseo y ejecucin de las transformaciones. A partir de la identificacin de estos niveles de abstraccin, los autores proponen que el desarrollo de transformaciones debera consistir en: definir la transformacin de forma independiente a la plataforma y trasladar dicha definicin independiente a una dependiente de plataforma. Este proceso de desarrollo de transformaciones puede utilizarse al tiempo que cualquier proceso MDA, es decir, mientras se especifican o definen modelos a niveles PIM y PSM, es posible definir modelos de transformacin a niveles PIT y PST. Esta lnea de investigacin, abierta en [25], es continuada en [24] donde los autores Bzivin, Bttner, Gogolla, Jouault, Kurtev y Lindow comparan el desarrollo de las transformaciones por medio de la codificacin y del modelado a nivel PIT. A partir de estos modelos de transformacin PIT, se podran obtener diferentes transformaciones de modelos, dependiendo de la plataforma de implementacin utilizada. Adems, en este trabajo los autores presentan algunas de las ventajas derivadas del modelado de las transformaciones de modelos como: especificar las transformaciones a alto nivel, transformar los modelos que sirven para especificar las transformaciones o validar las transformaciones. A continuacin, se presentan los datos extrados del anlisis de la propuesta que permitirn asignar un valor a los criterios de evaluacin definidos en la seccin 3.2.2: Niveles de abstraccin a los que se especifica la transformacin. Los autores definen dos niveles de abstraccin (PIT y PST) que se corresponden con los niveles PIM y PSM definidos por MDA. Se trata de definir la transformacin de forma independiente y dependiente de la plataforma, que en este caso es entendida como la herramienta que permite realizar la especificacin, diseo y ejecucin de las transformaciones. Para implementar los modelos de transformacin a nivel PIT, los autores proponen el uso de UML. Para el modelado de las transformaciones a nivel PST, proponen el uso de la sintaxis definida por las plataformas en las que se desee llevar a cabo la ejecucin de la transformacin. Nivel de automatizacin. El proceso de desarrollo propuesto consiste en el modelado de la transformacin a nivel PIT y el refinamiento de este modelo en otro a nivel PST. Los autores asumen que este paso se llevar a cabo mediante transformaciones de modelos. Generacin de cdigo. La propuesta contempla la necesidad de obtener el cdigo que implementa la transformacin en el lenguaje seleccionado por el

Estado del Arte 73

desarrollador, aunque no se especifica cmo se obtendr este cdigo ni cmo se debera realizar la implementacin de la misma. Visualizacin de modelos. La propuesta no aborda cmo se deberan visualizar los modelos que especifican las transformaciones. Validacin de modelos. Los autores indican que los modelos, como cualquier otro modelo, pueden ser validados. Para ello, dado que defienden el uso de UML para modelar la transformacin, proponen utilizar OCL para definir mecanismos de validacin. Sin embargo, no se detalla cmo llevar a cabo dicha validacin. Gestin de la trazabilidad. La propuesta no considera la gestin de la trazabilidad en el modelado de las transformaciones. Soporte tecnolgico. En las conclusiones de [25], los autores indican que, en el marco del programa de investigacin CARROLL, estn trabajando en el desarrollo de un conjunto de herramientas de cdigo abierto para dar soporte a la propuesta metodolgica presentada. Sin embargo, no se ha podido acceder a dichas herramientas y el programa CARROLL parece haber terminado, ya que la ltima actualizacin de su sitio web (http://www.carroll-research.org) fue en el ao 2005. 3.2.4.2 Didonet del Fabro En su tesis doctoral [58], Didonet del Fabro propone una solucin genrica para la gestin de las relaciones existentes entre los elementos de diferentes modelos, basada en el uso de modelos de weaving [21]. En este trabajo se presenta un marco tecnolgico para trabajar con modelos de weaving y se muestra su utilizacin en diferentes escenarios. Una de las principales aportaciones del trabajo de Didonet al estado del arte es la definicin semi-automtica de transformaciones de modelos a partir de modelos de weaving. En dichos modelos se establecen las relaciones existentes entre los elementos del metamodelo origen y los elementos del metamodelo destino de la transformacin. Para validar la aproximacin propuesta, el autor presenta una herramienta genrica y adaptable denominada ATLAS Model Weaver (AMW). AMW es una herramienta, implementada sobre Eclipse, que proporciona un editor grfico de modelos de weaving que permite definir y visualizar las relaciones existentes entre los elementos de uno o varios modelos origen y uno o varios modelos destino. Adems, AMW incorpora la implementacin de una transformacin HOT (seccin 3.1.2) denominada TransfGen que, a partir de un modelo de weaving, genera un

74

lvaro Jimnez Rielo

modelo de transformacin conforme al metamodelo del lenguaje de transformacin ATL [104]. Para serializar estos modelos en cdigo ATL, la herramienta dispone de un extractor de cdigo desarrollado con la herramienta TCS (Textual Concrete Syntax, [106]). En cuanto a los datos extrados del anlisis de la propuesta respecto a los criterios de evaluacin definidos: Niveles de abstraccin a los que se especifica la transformacin. El autor no indica explcitamente que el nivel de abstraccin al que se especifica la transformacin se corresponda con ninguno de los niveles definidos por MDA. Sin embargo, propone recoger las relaciones que darn lugar a la transformacin en un modelo independiente del lenguaje que implementar la transformacin. Por tanto, se puede considerar equivalente al nivel PIM definido por MDA. Dicho modelo, es convertido en un modelo conforme al metamodelo del lenguaje que implementa la transformacin. Es decir, este modelo describe cmo ser la transformacin en trminos de la sintaxis concreta de un lenguaje, por ello no sera equivalente al nivel PSM de MDA, sino al nivel PDM. Nivel de automatizacin. El autor propone el empleo de una transformacin HOT para convertir un modelo de weaving en un modelo conforme al metamodelo de un lenguaje de transformacin concreto. De esta forma, las relaciones definidas en el modelo de weaving entre los elementos de los metamodelos de entrada y salida sern transformadas de forma automtica a reglas de transformacin. En cuanto a la implementacin de dicha transformacin HOT, es necesario destacar que la herramienta presentada solo da soporte para la generacin de modelos de transformacin conformes al lenguaje ATL. Generacin de cdigo. La generacin de cdigo es soportada mediante un extractor implementado con TCS que permite obtener cdigo ATL a partir de un modelo conforme al metamodelo definido por ATL. Visualizacin de modelos. AMW, la herramienta que da soporte a la propuesta presentada, permite la definicin y visualizacin grfica de las relaciones que componen la transformacin a alto nivel. El editor propuesto, compuesto por varios paneles de visualizacin, permite identificar las relaciones existentes entre los elementos de los metamodelos de entrada y salida. Validacin de modelos. No aborda la validacin de modelos de transformacin.

Estado del Arte 75

Gestin de la trazabilidad. Aunque no en el contexto del desarrollo de transformaciones, el autor muestra que otro de los posibles usos de los modelos de weaving es visualizar y almacenar trazas que se generan a partir de la ejecucin de una transformacin de modelos. Soporte tecnolgico. Como ya se ha mencionado, esta propuesta ofrece soporte tecnolgico mediante la herramienta AMW, desarrollada sobre Eclipse. Dicha herramienta permite la definicin de modelos de weaving para establecer las relaciones a alto nivel. A partir de dichos modelos, mediante la ejecucin de una transformacin HOT, se genera un modelo de la transformacin conforme al metamodelo del lenguaje de transformacin ATL que posteriormente, usando un extractor implementado con TCS, permite la generacin del cdigo de la transformacin en trminos de la sintaxis del lenguaje ATL. 3.2.4.3 Guerra et al. En los trabajos [88] y [89], los autores Guerra, De Lara, Kolovos, Paige y Dos Santos presentan una familia de lenguajes de modelado, denominada transML, que abarca el ciclo de vida completo del desarrollo de transformaciones: desde la definicin de los requisitos hasta las pruebas, siguiendo enfoque basado en MDE. Los autores defienden que el proceso de desarrollo de transformaciones debera incluir las siguientes fases (siempre que la complejidad de la transformacin lo requiera): requisitos, anlisis, diseo de la arquitectura, diseo a alto nivel, diseo detallado, codificacin y pruebas. Para cada una de estas fases, la notacin empleada debe tener en cuenta las especificaciones del desarrollo que se est llevando a cabo. Para la fase de requisitos, aunque los autores indican que es posible emplear cualquier tcnica propia de la Ingeniera de Requisitos, proponen una representacin de los requisitos en forma de diagramas, similares a los diagramas de SysML (http://www.omg.org/spec/SysML/1.1/). Para ello, definen un metamodelo ad-hoc para la captura de requisitos. Para la fase de anlisis, proponen una adaptacin de las tcnicas clsicas de Ingeniera del Software, de forma que para cada requisito aprobado se definan ejemplos de transformacin, denominados casos de transformacin (similares a los casos de uso de UML).

76

lvaro Jimnez Rielo

Para la definicin de la arquitectura de la transformacin, transML propone un lenguaje de modelado que permite descomponer las transformaciones en unidades funcionales o mdulos. En cuanto al diseo, definen dos niveles: alto nivel y bajo nivel. El diseo a alto nivel se recoge en un diagrama de mapeo (mapping diagram), en el que se especifican las relaciones entre los elementos de los modelos que participan en la transformacin, omitiendo los detalles de dicha transformacin. El diseo a bajo nivel consiste en definir cmo debe implementarse la transformacin, separando su estructura y comportamiento. Para soportar el modelado de la transformacin a ambos niveles de diseo, transML proporciona dos DSLs. Para la fase de implementacin, transML ofrece mecanismos para utilizar lenguajes de transformacin existentes (QVT, ATL, ETL, etc.). As, siguiendo la filosofa MDE, se puede generar el cdigo para diferentes plataformas o lenguajes de transformacin a partir de los modelos elaborados en los niveles anteriores. Por ltimo, para la fase de pruebas proporciona un lenguaje propio para la definicin de casos de prueba. Para dar soporte a esta propuesta, los autores han implementado lenguajes de modelado definidos en forma de DSLs, basados en EMF. Adems, han definido una serie de transformaciones de modelos y generadores de cdigo que soportan la transformacin entre los modelos de las diferentes etapas. Estas transformaciones se han implementado con el lenguaje ETL [118], mientras que para la generacin de cdigo se utiliza EGL [173]. En cuanto a los datos extrados del anlisis de la propuesta respecto a los criterios de evaluacin definidos: Niveles de abstraccin a los que se especifica la transformacin. En la etapa de diseo, la propuesta identifica dos niveles a los que se debera describir el diseo de la transformacin: diseo a alto nivel y diseo a bajo nivel. En el primero se deben definir las relaciones entre los elementos de los metamodelos implicados en la transformacin, sin tener en cuenta los detalles de implementacin, del mismo modo que se hace en un modelo a nivel PIM. En el diseo a bajo nivel se redefinen y completan los diagramas de diseo a alto nivel, incluyendo detalles de implementacin, de forma similar a los modelos PSM. Nivel de automatizacin. Para automatizar el proceso descrito, la propuesta define, aunque no detalla, un conjunto de transformaciones entre los modelos correspondientes a cada una de las fases del desarrollo de la transformacin.

Estado del Arte 77

Generacin de cdigo. Los autores utilizan EGL para la generacin de transformaciones ETL. Visualizacin de modelos. Se establece la necesidad de que los modelos de las diferentes etapas puedan ser visualizados mediante diagramas genricos (por ejemplo, diagramas SysML) que no consideran la naturaleza especfica de los modelos de transformacin (por ejemplo, no muestran relaciones de tipo origen-destino). Validacin de modelos. Para llevar a cabo la validacin de los modelos, se propone el empleo del lenguaje de validacin EVL que permite definir restricciones de forma similar al lenguaje OCL. Gestin de la trazabilidad. Aunque los autores consideran de gran importancia la trazabilidad, se limitan al mbito interno del desarrollo de la transformacin, es decir, entre los modelos de las distintas etapas del desarrollo de las transformaciones. En cambio, no abordan la gestin de la trazabilidad derivada de la ejecucin de transformacin que se desarrolla, aunque sealan que transML puede adaptarse tanto a lenguajes de transformacin que ofrezcan soporte implcito para la trazabilidad como a los que lo ofrezcan de forma explcita. Soporte tecnolgico. Aunque los autores han implementado metamodelos, transformaciones de modelos y generadores de cdigo, no han abordado la integracin de estos componentes en una herramienta que facilite su uso. 3.2.4.4 Kusel Kusel en [128] presenta un framework llamado TROPIC (Transformations on Petri Nets in Color) para el desarrollo de transformaciones de modelos. TROPIC permite definir transformaciones a diferentes niveles de abstraccin, proporcionando una visin abstracta del mapeo de los elementos y una visin concreta de la transformacin. Adems, para la reutilizacin de transformaciones, proporciona una biblioteca de componentes reutilizables. Para modelar las transformaciones, TROPIC ofrece dos puntos de vista: una vista de mapeo y una vista de transformacin. En la vista de mapeo se establecen las relaciones existentes entre los elementos origen y los elementos destino de los metamodelos que intervienen en la transformacin. Para ello, proponen el uso de UML2. A partir de la informacin definida en la vista de mapeo, se obtiene la vista de transformacin ejecutable que se representa mediante Redes de Petri coloreadas, denominadas redes de transformacin. Dichas redes

78

lvaro Jimnez Rielo

son ejecutables y de hecho, Kusel junto a otros autores presentan, en [227], un depurador para mejorar su desarrollo y ejecucin. Para dar soporte a parte de esta propuesta, se ha desarrollado una primera versin del prototipo TROPIC que permite editar, ejecutar y depurar las redes de transformacin. La implementacin de TROPIC est basada en las herramientas EMF y GMF e incluye dos editores: uno para la especificacin de la transformacin y otro que muestra la representacin grfica de dicha especificacin en trminos de redes de transformacin. Adems soporta la depuracin paso a paso y otras funcionalidades de edicin. A partir de TROPIC, para facilitar el mapeo entre los elementos de los metamodelos implicados en la transformacin, se ha desarrollado una serie de patrones de transformacin reutilizables, llamados operadores de mapeo (Mapping Operators, MOP). Como primer prototipo para probar el funcionamiento de los MOPs, se utiliza la herramienta AMW. En cuanto a los datos extrados del anlisis de la propuesta respecto a los criterios de evaluacin definidos: Niveles de abstraccin a los que se especifica la transformacin. La propuesta establece dos puntos de vista o niveles de abstraccin para el modelado de las transformaciones. En la vista de mapeo se establecen las relaciones entre los elementos y la semntica de la transformacin y en la vista de transformacin se obtienen redes de transformacin que contienen la lgica de ejecucin de la transformacin. As, al igual que en propuestas anteriores, se considera que los niveles definidos en la propuesta son equivalentes a los niveles PIM y PSM definidos por MDA. Nivel de automatizacin. Aunque se establece que la vista de transformacin debera ser generada de forma directa a partir de la vista de mapeo, no especifica cmo llevar a cabo dicha generacin. Generacin de cdigo. La vista de transformacin se representa mediante redes de transformacin ejecutables, por tanto, no surge la necesidad de generar cdigo. Sin embargo, en el prototipo que da soporte a la propuesta s se contempla la generacin de la transformacin ATL a partir de los operadores de mapeo. Visualizacin de modelos. Para definir y representar la vista de mapeo se propone el empleo de UML y para la vista de transformacin se emplean Redes de Petri coloreadas. Ambas se consideran visualizaciones genricas que no han sido especficamente diseadas para visualizar modelos de transformacin.

Estado del Arte 79

Validacin de modelos. La propuesta no considera la validacin de las especificaciones de la transformacin. Gestin de la trazabilidad. No se contempla la gestin de la trazabilidad en el desarrollo de transformaciones de modelos. Soporte tecnolgico. Parte de la propuesta es soportada por el prototipo TROPIC que ofrece dos editores para crear y manipular redes de transformacin. TROPIC ha sido construido sobre EMF, GMF y AMW. 3.2.4.5 Kster et al. Los autores Kster, Ryndina y Hauser presentan en [131] un mtodo iterativo para el desarrollo de transformaciones de modelos centrado en asegurar la calidad de las mismas. Identifican tres fases diferentes en el desarrollo: el diseo a alto nivel, el diseo a bajo nivel y la validacin del diseo. El mtodo consiste en definir (semi-)formalmente las reglas de la transformacin, abstrayndose de sus detalles ms especficos. Estas reglas de transformacin de alto nivel son refinadas y completadas, siguiendo unas guas, hasta obtener el diseo de las reglas de transformacin a bajo nivel, de forma que sirva como base para la implementacin (o para la generacin del cdigo que implementa la transformacin). La propuesta se ilustra mediante un caso de estudio basado en modelos de proceso de negocio. Sin embargo, no existe herramienta para dar soporte tecnolgico, por tanto se trata de una propuesta puramente metodolgica que se limita a mostrar los pasos a seguir para el desarrollo de transformaciones de modelos. Esta idea tambin se ve reflejada en otros trabajos de Kster juntos a otros autores, como [129] y [130], donde utilizan dicho mtodo para el diseo e implementacin de transformaciones. En cuanto a los datos extrados del anlisis de la propuesta respecto a los criterios de evaluacin definidos: Niveles de abstraccin a los que se especifica la transformacin. Los autores proponen disear la transformacin a dos niveles de abstraccin. En primer lugar, se disean parcialmente las reglas de la transformacin a alto nivel, omitiendo algunos de sus detalles. Por tanto, se considera que este nivel es similar al nivel PIM propuesto por MDA. Posteriormente, las reglas definidas a alto nivel son refinadas y completadas en un diseo de bajo nivel, de manera similar a como se hace en los modelos PSM de MDA. Nivel de automatizacin. La propuesta establece un proceso iterativo compuesto por cinco pasos para refinar sistemticamente las reglas de

80

lvaro Jimnez Rielo

transformacin definidas a alto nivel en reglas a bajo nivel. Sin embargo, no se detalla cmo automatizar este proceso, tan solo se describen los pasos. Generacin de cdigo. Los autores indican que las reglas de transformacin validadas pueden ser implementadas manualmente o convertidas a cdigo de forma automtica. Sin embargo, no especifican cmo debera llevarse a cabo dicha generacin de cdigo. Visualizacin de modelos. Los autores reconocen la necesidad de soportar el modelado grfico de las transformaciones. A nivel PIM proponen una descripcin (semi-)formal de la transformacin y a nivel PSM proponen el uso de diagramas de objetos UML. Validacin de modelos. Para los autores, la validacin del diseo es uno de los aspectos ms importantes en el desarrollo de transformaciones de modelos. Por ello, proponen validar sintctica y semnticamente los modelos antes de su implementacin. Sin embargo, no especifican cmo llevar a cabo dicha validacin. Gestin de la trazabilidad. En la propuesta presentada, los autores no contemplan la gestin de la trazabilidad a partir del desarrollo de transformaciones de modelos. Soporte tecnolgico. Los autores no presentan ninguna herramienta para dar soporte a la propuesta metodolgica presentada, aunque en las conclusiones de [131] indican que uno de los trabajos futuros es la construccin de una herramienta para este propsito. 3.2.4.6 Lano y Kolahdouz-Rahimi La propuesta presentada en [132] consiste en la definicin de un proceso de desarrollo de transformaciones de modelos con el objetivo de mitigar los problemas de migracin y reusabilidad derivados del gran nmero de lenguajes de transformacin existentes. Los autores proponen una aproximacin genrica para el desarrollo dirigido por modelos de transformaciones de modelos, basada en notaciones MOF y UML. El proceso propuesto consta de las siguientes cuatro etapas: requisitos, especificacin abstracta, diseo y especificacin explcita e implementacin. En la primera etapa se detallan los requisitos de la transformacin en trminos de los metamodelos origen y destino, incluyendo aquellas restricciones que sean necesarias. En esta primera etapa es posible emplear diagramas de casos de uso para describir la funcionalidad del sistema y los requisitos no funcionales.

Estado del Arte 81

En la etapa de especificacin abstracta se formalizan los requisitos como restricciones en un lenguaje tipo OCL. Dichas restricciones se emplean para definir de forma global las relaciones existentes entre los metamodelos para cada caso de uso. En la etapa de diseo y especificacin explcita, las transformaciones se pueden desarrollar en diferentes fases. As, en cada una de las fases se definen las reglas de transformacin en trminos de operaciones especificadas por pre-condiciones y post-condiciones y se detalla el orden de ejecucin de dichas reglas. En este punto, se puede verificar que las reglas satisfacen la especificacin y son deterministas y bien definidas. Segn los autores, dado que estas reglas y fases se definen de forma independiente, existe la posibilidad de reutilizarlas en otras transformaciones. Por ltimo, se codifica la transformacin usando uno de los lenguajes de transformacin existentes. En cuanto a los datos extrados del anlisis de la propuesta respecto a los criterios de evaluacin definidos: Niveles de abstraccin a los que se especifica la transformacin. En este trabajo, los autores proponen un proceso de desarrollo de transformaciones de modelos dirigido por modelos, que se compone de varias etapas en las que se describen las transformaciones a diferentes niveles de abstraccin. Dichos niveles se corresponden con los pasos requeridos para desarrollar una transformacin: definicin de los requisitos, especificacin abstracta como restricciones que definen las relaciones entre los modelos implicados en la transformacin, diseo y especificacin explcita de las reglas de la transformacin y el orden de las mismas, y por ltimo, codificacin de las reglas de transformacin. Los autores no establecen ninguna relacin de estos niveles con los definidos por MDA, sin embargo la especificacin abstracta y la especificacin explcita de la transformacin pueden considerarse equivalentes a los niveles PIM y PSM. Nivel de automatizacin. El proceso propuesto para el desarrollo de transformaciones de modelos dirigido por modelos no ndica cmo llevar a cabo el paso entre los artefactos que se definen en las distintas etapas del proceso, por tanto se asume que no considera la automatizacin de esta tarea. Generacin de cdigo. A pesar de definir una fase de implementacin, los autores no especifican si el cdigo de la transformacin se puede obtener

82

lvaro Jimnez Rielo

mediante un proceso de generacin de cdigo o si debe ser creado manualmente. Visualizacin de modelos. Los autores proponen que los modelos que describen las diferentes etapas del proceso de desarrollo de las transformaciones sean definidos en trminos de MOF y UML. Por tanto, se podran usar los editores/visualizadores genricos que existen para estos tipos de modelos. Validacin de modelos. La propuesta no define explcitamente cmo llevar a cabo la validacin de las especificaciones de la transformacin. Sin embargo, en la etapa de diseo y especificacin explcita s se considera que es posible verificar que las reglas de la transformacin satisfacen la especificacin abstracta de la transformacin y si las reglas se encuentran bien definidas y son deterministas. Gestin de la trazabilidad. En la propuesta presentada, los autores no contemplan la gestin de la trazabilidad a partir del desarrollo transformaciones de modelos. Soporte tecnolgico. Los autores no presentan ninguna implementacin de la propuesta metodolgica presentada, por tanto, se asume que se trata de una propuesta puramente terica. 3.2.4.7 Varr y Pataricza Segn Varr y Pataricza [214], las aproximaciones existentes para el desarrollo de transformaciones de modelos se centran en asegurar que la ejecucin de las transformaciones sea correcta y no dan importancia a otras caractersticas como la reusabilidad, el mantenimiento o el rendimiento. Para abordar este problema, en [214] presentan una propuesta que, siguiendo los principios definidos por MDA [157], define las transformaciones como modelos en s mismos. En concreto, se centran el uso de transformaciones genricas y meta-transformaciones. En primer lugar se centran en las transformaciones genricas, que definen reglas de transformacin independientes de plataforma, donde los tipos de algunos componentes son variables y se resuelven en tiempo de ejecucin. As, una regla genrica puede ser aplicada a distintos escenarios en los que el patrn de entrada sea el mismo para elementos de distinto tipo. Esta caracterstica ofrece transformaciones ms compactas y reutilizables, pero por el contrario, reduce el rendimiento respecto de las transformaciones tradicionales. Para dotar de fundamentos tericos a esta idea, los autores proponen VPM (Visual and Precise

Estado del Arte 83

Metamodeling), un marco de trabajo terico, presentado en [213], donde las transformaciones de modelos se definen y representan mediante grafos. Posteriormente, definen las meta-transformaciones como aquellas transformaciones que utilizan otras transformaciones como salida o entrada similar a las transformaciones HOT (seccin 3.1.2). Un requisito indispensable de estas transformaciones es almacenar las reglas de la transformacin como modelos. Segn los autores, los principales beneficios derivados del uso de meta-transformaciones son el incremento de rendimiento respecto de las transformaciones genricas y la mejora en la mantenibilidad de las transformaciones. Para poner en prctica las ideas propuestas y dar soporte a VPM, los autores presentan una actualizacin de la herramienta VIATRA (http://www.eclipse.org/gmt/VIATRA2/). Concretamente, esta actualizacin permite llevar a cabo el modelado de transformaciones independientes de plataforma (PIT) y de transformaciones dependientes de plataforma (PST). En cuanto a los datos extrados del anlisis de la propuesta respecto a los criterios de evaluacin definidos: Niveles de abstraccin a los que se especifica la transformacin. La propuesta presentada hace uso de VPM, un marco de trabajo multinivel. En la propuesta metodolgica no se indican los niveles a los que se deberan definir las transformaciones. Sin embargo, en la herramienta que da soporte a la propuesta se permite el modelado de las transformaciones de forma independiente de plataforma (modelos PIT) y dependiente de plataforma (modelos PST). Estos niveles coinciden con los propuestos por Bzivin en [25], descritos en la seccin 3.2.4.1. Al igual que en ese caso, se considera que los niveles propuestos se corresponden con los niveles PIM y PSM descritos por MDA. Nivel de automatizacin. Los autores de este trabajo no sugieren tcnicas para llevar a cabo la conversin (semi-)automtica de un modelo de un nivel de abstraccin en un modelo de otro nivel distinto. Generacin de cdigo. Aunque la definicin de la propuesta metodolgica no contemple cmo se debera llevar a cabo la generacin del cdigo que implementa la transformacin, al presentar la herramienta que da soporte a la propuesta s describen la generacin de cdigo como una de las caractersticas de dicha herramienta. Sin embargo, no describen claramente cmo se lleva a cabo.

84

lvaro Jimnez Rielo

Visualizacin de modelos. Los autores proponen que la descripcin de las definiciones de la transformacin se lleve a cabo mediante grafos. Validacin de modelos. Los autores de esta propuesta no consideran la validacin de los modelos de la transformacin que se est desarrollando. Gestin de la trazabilidad. En la propuesta presentada, no se contempla la gestin de la trazabilidad. Soporte tecnolgico. Para dar soporte a la propuesta presentada, se presenta una actualizacin de VIATRA, una herramienta para el desarrollo de transformaciones de modelos, desarrollada por los mismos autores de esta propuesta. Esta nueva versin, construida sobre Eclipse, ofrece soporte tecnolgico para los niveles de modelado propuestos en [213] y el desarrollo de las transformaciones genricas y meta-transformaciones presentadas en [214]. La principal caracterstica es el modelado de las transformaciones independientes de plataforma (PIT) y de las transformaciones dependientes de plataforma (PST). 3.2.4.8 Vignaga La propuesta presentada por Vignaga en [218] consiste en la definicin de una metodologa genrica para aplicar tcnicas MDE al desarrollo y evolucin de transformaciones de modelos. Dicha metodologa, se centra en las actividades de diseo e implementacin, aunque debera contemplar todo el ciclo de vida. El autor identifica dos problemas asociados al cuerpo del conocimiento: la ausencia de un paradigma de programacin dominante o consensuado para la implementacin de transformaciones de modelos; y la falta de una clasificacin o categorizacin unificada de las transformaciones de modelos. Segn el autor, la metodologa est definida como un proceso completo expresada mediante un modelo SPEM y propone un ciclo de vida basado en un modelo iterativo e incremental, estructurado en etapas, una para la construccin y una para la evolucin. Sin embargo, en [218] no se detallan dichos procesos. Continuando esta lnea de investigacin, Vignaga junto a Perovich y Bastarrica proponen en [219] realizar la especificacin de las transformaciones de modelos siguiendo una estructura de cuatro niveles de abstraccin. El primer nivel, el ms bajo, debera contener el cdigo que implementa la transformacin y los elementos implicados en dicha transformacin, en trminos de constructores especficos de plataforma. El segundo nivel debera ofrecer una capa de abstraccin de los constructores especificados en el nivel anterior, suprimiendo los constructores especficos de plataforma. En el tercer nivel, se deberan especificar

Estado del Arte 85

las relaciones entre los diferentes elementos que participan en la transformacin. Y por ltimo, en el cuarto nivel se deberan incluir mecanismos de modularizacin, especificando lo qu debera hacer la transformacin, pero con menor detalle que en las etapas anteriores. En [219], los autores identifican como tarea futura la construccin de una herramienta para dar soporte a la propuesta presentada. Sin embargo, en la actualidad esta lnea de investigacin parece que ha sido abandonada ya que no se ha encontrado dicha implementacin ni nuevos trabajos relacionados. En cuanto a los datos extrados del anlisis de la propuesta respecto a los criterios de evaluacin definidos: Niveles de abstraccin a los que se especifica la transformacin. La propuesta define cuatro niveles de abstraccin que van desde el cdigo que implementa la transformacin (nivel ms bajo) hasta el nivel en el que se definen los mecanismos de modularizacin (nivel ms alto). Los dos niveles superiores son independientes de plataforma, por tanto existe una equivalencia con el nivel PIM; y los dos niveles inferiores contienen informacin relativa a la plataforma, por lo que se corresponden con el nivel PSM de MDA. Nivel de automatizacin. Aunque los autores reconocen la necesidad de establecer mecanismos de automatizacin en el paso de unos niveles de abstraccin a otros, no especifican cules ni cmo deberan ser. Generacin de cdigo. Una de las capas de abstraccin establecidas es el cdigo de la transformacin en el lenguaje que corresponda, sin embargo no establecen cmo crear o generar dicho cdigo. Visualizacin de modelos. Los autores consideran la necesidad de disponer mecanismos de visualizacin, de hecho cuando identifican como trabajo futuro el desarrollo de su herramienta de soporte, mencionan la herramienta AMW como ejemplo para la representacin/visualizacin grfica de informacin. Validacin de modelos. Los autores no especifican cmo se debera llevar a cabo la validacin, sin embargo la identifican como una tarea deseable. Gestin de la trazabilidad. En la propuesta presentada, los autores no contemplan la gestin de la trazabilidad. Soporte tecnolgico. En [219], identifican la construccin de una herramienta como trabajo futuro, sin embargo no se ha encontrado dicha aplicacin.

86

lvaro Jimnez Rielo

3.2.5

Discusin

Tras analizar todas las propuestas identificadas en la literatura para el desarrollo dirigido por modelos de transformaciones de modelos, en esta seccin se le asigna a cada propuesta los valores correspondientes a los criterios de evaluacin propuestos en la seccin 3.2.2 y posteriormente, se analizan los valores obtenidos con el objetivo de dar respuesta a las cuestiones de investigacin propuestas en la seccin 3.2.1. En la Tabla 3-1 se presentan los valores asignados a cada propuesta para cada uno de los criterios de evaluacin. Se recuerda que la puntuacin de cada uno de los posibles valores es: (S)=1; (P)arcial=0.5; y (N)o=0. Por tanto, dado que se han definido ocho criterios de evaluacin (CE), cada una de las propuestas podra obtener, como mximo, 8 puntos. La penltima columna de la tabla (Total) muestra la puntuacin obtenida por cada una de las propuestas y la ltima columna (% mximo posible) indica el porcentaje de puntos que ha obtenido cada propuesta respecto de 8, es decir del total de puntos posibles.
Tabla 3-1. Resumen de los Criterios de Evaluacin en cada propuesta
Niveles PIM y PSM o equivalentes Paso entre niveles (Automtico) Independencia de lenguaje de transformacin Herramienta de Soporte Generacin de cdigo Visualizacin Gestin de la Trazabilidad

Validacin

Propuesta Bzivin et al. Didonet del Fabro Guerra et al. Kusel Kster et al. Lano y KolahdouzRahimi Varr y Pataricza Vignaga

CE-1 S P S S S S S S

CE-2 S S S P N N N P

CE-3 P S S P P N P P

CE-4 N P P P P P P N

CE-5 P N S N S P N P

CE-6 S S S S S S S S

CE-7 CE-8 N P P N N N N N N S P P N N S N

T o tal

% m xim o po s ible 5 0 ,0 0 % 6 8 ,7 5 % 8 1,2 5 % 5 0 ,0 0 % 5 0 ,0 0 % 3 7 ,5 0 % 5 0 ,0 0 % 4 3 ,7 5 %

4 ,0 0 5 ,5 0 6 ,5 0 4 ,0 0 4 ,0 0 3 ,0 0 4 ,0 0 3 ,5 0

T o tal C E

7 ,5 0

4 ,0 0

4 ,5 0

3 ,0 0

3 ,5 0

8 ,0 0

1,0 0

3 ,0 0

3 4 ,5 0

% m xim o po s ible C E 9 3 ,7 5 % 5 0 ,0 0 % 5 6 ,2 5 % 3 7 ,5 0 % 4 3 ,7 5 % 10 0 ,0 0 % 12 ,5 0 % 3 7 ,5 0 % 5 3 ,9 1%

Como se puede observar en la Tabla 3-1, todas las propuestas han obtenido una puntuacin entre 3 y 6.5 puntos (columna Total), o lo que es lo mismo entre

Estado del Arte 87

el 37.50% y el 81.25% de la puntuacin total (columna % mximo posible). En concreto, 2 propuestas (25%) han obtenido menos de 4 puntos (la mitad de los puntos posibles), 4 propuestas (50%) han obtenido 4 puntos y 2 propuestas (25%) han obtenido ms de 4 puntos. Por otra parte, en las ltimas dos filas de la tabla (Total CE y % mximo posible CE) se presenta la puntuacin alcanzada por cada uno de los criterios de evaluacin (CE), sumando los puntos asignados a cada propuesta para dicho criterio; y el porcentaje de puntos que supone respecto del total de puntos posibles. Se recuerda que, en esta revisin de la literatura, se han analizado 8 propuestas y que el mximo valor que puede asignar por cada CE es 1, por tanto la puntuacin mxima a la que aspira cada CE es de 8 puntos. Esta puntuacin mxima tan solo ha sido alcanzada por uno de los criterios de evaluacin (CE-6: independencia del lenguaje de transformacin), aunque CE-1 (definicin de las transformaciones a nivel PIM y PSM) con 7.5 puntos se acerca bastante a dicha puntuacin. Otro dato a tener en cuenta es que la mitad de los criterios de evaluacin (CE-4, CE-5, CE-7 y CE-8) han obtenido una puntuacin por debajo del 50% del mximo de puntos posibles, es decir menos de 4 puntos. De estos criterios, es destacable que la gestin de la trazabilidad solo haya obtenido 1 punto. A partir de estos datos se puede afirmar que, dado que todas las propuestas analizadas han obtenido una puntuacin entre el 37.50% y el 81.25% de los puntos posibles, todas ellas se encuentran relacionadas en mayor o menor medida con el objetivo de investigacin planteado. Adems, se puede afirmar que existe un consenso en la literatura en cuanto a ciertas caractersticas que debe cumplir toda propuesta centrada en el desarrollo dirigido por modelos de transformaciones de modelos, como son la independencia respecto del lenguaje con el que finalmente se codifique la transformacin o la especificacin de la transformacin a diferentes niveles de abstraccin. Sin embargo, existen otras caractersticas como puede ser la validacin o la visualizacin de las especificaciones de la transformacin que no son abordadas por todas las propuestas o no lo hacen de forma completa. Dado que la mitad de los CE ha obtenido una puntuacin por debajo del 50% de los puntos posibles, se puede considerar que las caractersticas evaluadas por dichos CE son posibles puntos de mejora en el estado del arte en el desarrollo de transformaciones de modelos dirigidas por modelos. Una vez que se dispone de los valores asignados a cada propuesta, se procede a analizarlos para dar respuesta a cada una de las cuestiones de investigacin (CI) planteadas en la seccin 3.2.1:

88

lvaro Jimnez Rielo

CI-1. A qu niveles de transformaciones de modelos?

abstraccin

se

propone

especificar

las

Una de las principales caractersticas del desarrollo de software dirigido por modelos es la definicin del sistema a diferentes niveles de abstraccin [91, 192, 220]. El caso de la construccin de transformaciones de modelos no puede ser diferente y por tanto, para seguir una aproximacin dirigida por modelos, es necesario definir una jerarqua de niveles de abstraccin en los que se describa y especifique la transformacin. Una de las aproximaciones ms adoptadas en este sentido es MDA, que define tres niveles de abstraccin: CIM, PIM y PSM [112, 157, 186]. Para evaluar cmo se cumple este requisito en la literatura analizada se ha empleado el criterio de evaluacin CE-1 que evala si las propuestas proponen el uso de los niveles PIM y PSM definidos por MDA o niveles anlogos. Este criterio de evaluacin ha obtenido un 93.75% de los puntos posibles, lo que significa que la especificacin de las transformaciones a diferentes niveles de abstraccin es una cuestin bastante abordada por las propuestas analizadas. Todas las propuestas analizadas, a excepcin de la presentada por Didonet del Fabro, proponen el uso de al menos dos niveles de abstraccin equivalentes a los niveles PIM y PSM definidos por MDA, es decir, uno independiente de plataforma y uno dependiente de plataforma. Se puede concluir que para llevar a cabo el desarrollo de una propuesta para el DDM de transformaciones de modelos se deben especificar a qu niveles de abstraccin se modelan las transformaciones. En este sentido, es habitual la definicin de, al menos, un nivel independiente de plataforma que omita los detalles especficos del lenguaje o motor de transformacin que se utilice para implementar y ejecutar la transformacin y un nivel menos abstracto que s considere los detalles o caractersticas propias del lenguaje que implementar la transformacin. CI-2. Qu ideas se proponen para automatizar el proceso de desarrollo de las transformaciones?

En la cuestin anterior se analiza uno de los principios del DSDM (la distincin de niveles de abstraccin). En esta, se estudia el comportamiento de las propuestas analizadas respecto a otro de los principios fundamentales del DSDM: la automatizacin del proceso de desarrollo [91, 185, 188, 192, 220]. Para dar respuesta a esta cuestin, se hace uso de los valores asignados a los criterios CE-2 y CE-3, que estudian si las propuestas definen tcnicas o mtodos para automatizar el paso entre modelos de diferentes niveles de abstraccin y para la generacin de cdigo, respectivamente. Ambos han obtenido

Estado del Arte 89

aproximadamente el 50% de la puntuacin mxima, 4 puntos en el caso de CE-2 y 4.5 puntos en el de CE-3. Conviene destacar que, a pesar de haber obtenido una puntuacin relativamente baja, todas las propuestas, excepto la presentada por Lano y Kolahdouz-Rahimi, afrontan al menos una de estas dos cuestiones. En cuanto a la automatizacin del paso entre modelos de diferentes niveles de abstraccin, solo tres propuestas (Bzivin et al., Didonet del Fabro y Guerra et al.) proponen tcnicas para llevar a cabo esta tarea. Todas coinciden en la conveniencia de usar transformaciones de modelos. Adems, los autores Kusel y Vignaga tambin consideran que automatizar el paso entre niveles de abstraccin es una tarea deseable aunque no indican cmo se debera hacer. En cuanto a la generacin del cdigo que implementa la transformacin, todas las propuestas, excepto la presentada por Lano y Kolahdouz-Rahimi, consideran que es una caracterstica deseable en un entorno de desarrollo de transformaciones de modelos, sin embargo, solo las propuestas de Didonet del Fabro y Guerra et al. definen cmo afrontarla. En el caso de Didonet del Fabro se propone el uso de la herramienta TCS para crear un extractor de cdigo que serialice los modelos definidos en cdigo ATL, mientras que la propuesta presentada por Guerra et al. recomienda usar el lenguaje EGL. No obstante, la ausencia de propuestas para la generacin de cdigo puede deberse a que, como muestra el estudio de CE-6, todas las propuestas presentan mtodos orientados al desarrollo de transformaciones independientes de los lenguajes de transformacin existentes. CI-3. Existen propuestas metodolgicas centradas en el DDM de transformaciones de modelos que propongan o sugieran ideas para la gestin de la trazabilidad a partir del modelado de dichas transformaciones?

Uno de los objetivos principales de esta tesis doctoral es combinar las tcnicas de generacin y gestin de la trazabilidad con las tcnicas para el DDM de transformaciones de modelos. Por ello, esta cuestin de investigacin tiene por objetivo analizar si las propuestas para el DDM de transformaciones de modelos ofrecen mtodos o ideas para obtener informacin de trazabilidad a partir de las transformaciones de modelos generadas. Para dar respuesta a esta pregunta se analiza el criterio de evaluacin CE-7, que se centra directamente en esta cuestin. Dicho criterio ha obtenido la puntuacin ms baja (1 punto) de todos los CE definidos. Ninguna de las propuestas analizadas ofrece tcnicas para la gestin de la trazabilidad y tan solo 2 de ellas (Didonet del Fabro y Guerra et al.) establecen cierta relacin entre la gestin de la trazabilidad y el DDM de transformaciones de modelos. En concreto,

90

lvaro Jimnez Rielo

Didonet del Fabro muestra cmo los modelos de weaving pueden ser empleados para visualizar y almacenar informacin de trazabilidad; mientras que Guerra et al. consideran la gestin de la trazabilidad como una tarea importante pero en el mbito interno del desarrollo de las transformaciones, es decir, entre los modelos que definen la transformacin y no entre los artefactos que conectarn las transformaciones desarrolladas. En vista de los datos obtenidos se pone de manifiesto que existe mucho espacio para la mejora en lo que se refiere a la gestin de la trazabilidad en el DDM de transformaciones de modelos. CI-4. Existen herramientas que soporten el DDM de transformaciones de modelos?

En Ingeniera del Software suele existir cierta distancia entre la teora y la prctica. As, es habitual encontrar propuestas tericas ambiciosas que, por unos motivos u otros (aproximaciones poco realistas, tecnologa insuficiente, falta de financiacin, etc.), resultan complicadas de poner en prctica [136, 148, 167]. Por este motivo, esta cuestin de investigacin tiene por objetivo comprobar si en el estado del arte actual, adems de la existencia de propuestas metodolgicas para el DDM de transformaciones de modelos, es posible encontrar implementaciones o herramientas completas que soporten dichas propuestas. El criterio CE-8, que proporciona la informacin necesaria para dar respuesta a esta cuestin, ha obtenido uno de los peores resultados (3 puntos) y se ha comprobado que el 50% de las propuestas no ponen en prctica sus ideas tericas. As pues, parece que la distancia entre teora y prctica se vuelve a hacer patente en el DDM de transformaciones. De las cuatro propuestas metodolgicas que s proporcionan soporte tecnolgico, dos de ellas (Guerra et al. y Kusel) ofrecen slo implementaciones parciales y necesitan las funcionalidades proporcionadas por otras herramientas, como editores o lanzadores de transformaciones. Las dos propuestas que s proporcionan una implementacin completa son las presentadas por Didonet del Fabro y Varr y Pataricza. Por un lado, Didonet del Fabro presenta AMW, una herramienta construida sobre Eclipse que permite definir modelos de weaving para establecer relaciones a alto nivel entre elementos de diferentes modelos. En uno de los casos de uso de AMW que se presentan, se propone utilizar uno de estos modelos de weaving para recoger las relaciones que deben satisfacerse entre los elementos de los metamodelos implicados en una transformacin. Dicha transformacin es consumida por una transformacin HOT, que produce un modelo de

Estado del Arte 91

transformacin para el lenguaje de transformacin ATL. Finalmente, dicho modelo puede serializarse en el cdigo ATL que implementa la transformacin. Por otro lado, Varr y Pataricza, presentan una actualizacin de su herramienta para el desarrollo de transformaciones de modelos (VIATRA). A diferencia de la anterior la nueva versin ha sido construida sobre Eclipse y su principal caracterstica es soportar el modelado de transformaciones a nivel PIT y PST. En general, para construir o desarrollar la mayor parte de las implementaciones analizadas, los autores han empleado herramientas enmarcadas en el proyecto Eclipse Modeling Project (EMP, http://eclipse.org/modeling), que engloba herramientas e implementaciones de referencia que facilitan la construccin del soporte tecnolgico para propuestas basadas en MDE. De hecho, de todas las propuestas analizadas, las cuatro que incluyen algn tipo de implementacin utilizan EMP como base tecnolgica. Por lo tanto, se podra concluir que, aunque el soporte tecnolgico es una cuestin an inmadura en el estado del arte actual, el problema no est relacionado con la falta de medios para construirlo. CI-5. Cules son las limitaciones del estado del arte en el DDM de transformaciones de modelos?

Por ltimo, analizando las respuestas a las preguntas anteriores y los datos obtenidos del anlisis de las propuestas, se da respuesta a esta cuestin que tiene por objetivo resumir las limitaciones o puntos de mejora que se han identificado en el estado del arte actual en el DDM de transformaciones de modelos. En el apartado de discusin de CI-1 se han analizado los niveles de abstraccin que, segn las propuestas, deberan emplearse para el desarrollo de transformaciones de modelos dirigido por modelos. En este punto, se ha identificado que todas las propuestas, a excepcin de una, coinciden en la necesidad de definir, al menos, un modelo independiente de plataforma y un modelo dependiente de plataforma. En este sentido, el nico punto de mejora identificado es la falta de consenso acerca del tipo de modelos empleados dentro de dichos niveles. Una posible solucin a esta diferencia de criterios es el uso de un estndar como MDA, que define explcitamente los niveles de abstraccin que se deberan emplear en la construccin de artefactos software. En la discusin de CI-2, se analiza la automatizacin del proceso de desarrollo de las transformaciones de modelos. Para dar respuesta a dicha cuestin se ha estudiado la automatizacin del paso entre los modelos de diferentes niveles de abstraccin y la automatizacin de la generacin del cdigo que implementa la

92

lvaro Jimnez Rielo

transformacin. Como es de esperar en un contexto dirigido por modelos, los autores consideran que la automatizacin del proceso es un aspecto importante que se debe tener en cuenta. Sin embargo, solo tres de las ocho propuestas analizadas sugieren ideas o tcnicas para automatizar el paso entre modelos de los distintos niveles de abstraccin. En concreto, proponen el empleo de transformaciones de modelos. Y tan solo dos de ellas proporcionan ideas o tcnicas concretas para automatizar ambas tareas (paso entre modelos de distintos niveles y generacin de cdigo). Con estos datos, se pone de manifiesto que una de las debilidades del estado del arte en el DDM de transformaciones de modelos es la automatizacin del proceso de desarrollo. Obviamente, la solucin pasa por potenciar el uso de transformaciones de modelos y generadores o extractores de cdigo. En la CI-3 se analiza si existen propuestas que consideren la gestin de la trazabilidad a partir de las transformaciones de modelos, concluyendo que ninguna de las propuestas analizadas afronta esta cuestin. Como se defiende en esta tesis doctoral, es factible obtener las trazas del sistema a partir de las transformaciones de modelos. Una posible forma de adaptar esta idea al DDM de transformaciones de modelos es incluir constructores especficos para trazabilidad en los modelos que describen la transformacin. En la discusin acerca de las herramientas que proporcionan soporte tecnolgico a las propuestas metodolgicas (CI-4), se ha observado que la mitad de las propuestas analizadas no ofrecen implementaciones para poner en prctica sus ideas tericas. En este sentido, ya que la tecnologa actual proporciona los medios necesarios para construir dichas herramientas para tareas MDE, sera deseable que las propuestas para el DDM de transformaciones de modelos proporcionaran el soporte tecnolgico adecuado. Finalmente, otra limitacin que se ha identificado en el anlisis del estado del arte es la ausencia de tcnicas de visualizacin ad-hoc para modelos de transformaciones, que se ajusten a las caractersticas de estos modelos. Como se puede comprobar en la Tabla 3-1, todas las propuestas que consideran la visualizacin de modelos que representan las transformaciones, proponen el uso de editores de modelos genricos. Tan solo el editor propuesto por Didonet del Fabro se adapta a las caractersticas de un modelo de transformacin, ya que permite visualizar las relaciones entre los elementos de dos modelos. Otra lnea de mejora en el estado del arte es el empleo de tcnicas, como la validacin, que mejoren las transformaciones desarrolladas. Dado que se plantea modelar las transformaciones, sera deseable aprovechar las ventajas que ofrecen las operaciones para la gestin de los modelos en este sentido [21].

Estado del Arte 93

3.3

Propuestas para la Gestin de la Trazabilidad a partir de Transformaciones de Modelos

Como se ha comprobado en la seccin anterior, las propuestas para el desarrollo dirigido por modelos de transformaciones de modelos no consideran la gestin de la trazabilidad. Por ello, dado que en esta tesis doctoral uno de los principales objetivos es la gestin de la informacin de trazabilidad, para complementar el cuerpo de conocimiento, en esta seccin se realiza un nuevo estudio de la literatura cuyo principal objetivo es identificar y analizar diferentes propuestas centradas en la gestin de la trazabilidad a partir del desarrollo de transformaciones de modelos. Mientras que en la seccin anterior el objeto de estudio era la aplicacin de los principios de MDE (uso de modelos y automatizacin del proceso) al desarrollo de transformaciones de modelos, en esta lo es la gestin de la informacin de trazabilidad que se deriva de la ejecucin de las transformaciones de modelos, sin tener en cuenta si se aplican los principios de MDE para desarrollar dichas transformaciones. Para llevar a cabo esta revisin de la literatura se ha seguido un proceso completo de revisin sistemtica basado en las guas propuestas por Kitchenham y Charters [111] y Biolchini [27]. El mtodo concreto se present en la seccin 2.2. Los detalles de este proceso de revisin sistemtica son descritos en el Apndice A de este documento, mientras que en las siguientes sub-secciones se presentan los objetivos o cuestiones de investigacin a las que se quiere dar respuesta con este estudio de la literatura (seccin 3.3.1), los criterios que se emplean para evaluar y comparar cada una de las propuestas identificadas en la literatura (seccin 3.3.2), los datos que se extraen de cada propuesta (seccin 3.3.3), el anlisis detallado de cada una de ellas (seccin 3.3.4) y por ltimo, las principales conclusiones obtenidas (seccin 3.3.5).

3.3.1

Cuestiones de Investigacin

El principal objetivo de esta revisin de la literatura es identificar y analizar las propuestas existentes centradas en generar y gestionar informacin de trazabilidad a partir del desarrollo de transformaciones de modelos. Para dar respuesta a este objetivo principal, se propone el siguiente conjunto de cuestiones de investigacin (CI), a las que se darn respuesta en la seccin 3.3.5: CI-1. Qu nivel de automatizacin ofrecen o sugieren las propuestas metodolgicas para generar informacin de trazabilidad?

94

lvaro Jimnez Rielo

Aunque en este estudio de la literatura el objetivo principal no es analizar si las propuestas aplican los principios de MDE al desarrollo de transformaciones, s que resulta interesante conocer qu tareas es posible automatizar y hasta qu nivel. As ser posible conocer si, en el estado del arte actual, la generacin de la trazabilidad se considera una tarea manual o si por el contrario, se proporcionan mtodos que la automaticen (completa o parcialmente). CI-2. Segn las propuestas metodolgicas identificadas, cmo se deberan almacenar, visualizar y analizar las trazas generadas? Como se ha indicado en la introduccin de esta memoria de tesis doctoral, la informacin de trazabilidad puede ser muy til para llevar a cabo otras actividades del ciclo de vida software como por ejemplo el anlisis de impacto del cambio, la toma de decisiones o el mantenimiento general del sistema [5, 39, 40, 113, 147]. Por tanto, resulta interesante conocer cmo, segn las propuestas metodolgicas, deberan llevarse a cabo ciertas tareas relacionadas con la gestin de las trazas, como el almacenamiento (en modelos de trazas, en repositorios de trazas, embebidas en los modelos terminales, etc.), la visualizacin (de forma grfica o textual) y las tcnicas para facilitar su anlisis (informes tcnicos, estudios estadsticos, clasificaciones, etc.). CI-3. Existen herramientas o marcos de trabajo que ofrezcan soporte tecnolgico para la gestin de la trazabilidad en el contexto del desarrollo de transformaciones de modelos? Una de las principales metas de este estudio de la literatura es identificar si las propuestas para la generacin y gestin de la trazabilidad a partir del desarrollo de transformaciones de modelos han sido puestas en prctica por medio de herramientas MDE. Por tanto, el objetivo de esta cuestin de investigacin es analizar si las propuestas existentes ofrecen algn tipo de soporte tecnolgico. CI-4. Cules son las limitaciones encontradas en las propuestas para la gestin de informacin de trazabilidad a partir de transformaciones de modelos? Finalmente, en la ltima cuestin se combinarn las respuestas a las preguntas anteriores (CI-1, CI-2 y CI-3) para identificar problemas o limitaciones en el estado del arte actual de la gestin de la trazabilidad a partir de transformaciones de modelos.

Estado del Arte 95

3.3.2

Criterios de Evaluacin

Al igual que en la revisin de la literatura anterior y de acuerdo a la gua para realizar revisiones sistemticas, propuesta por Kitchenham y Charters [111], para dar respuesta a las preguntas anteriores es recomendable disponer de mecanismos que permitan evaluar y comparar las propuestas seleccionadas. Por ello, en esta seccin se define un conjunto de criterios de evaluacin (CE) y un conjunto de posibles valores para dichos criterios. Para facilitar la comparativa entre las propuestas, los valores que se les pueden asignar para cada uno de los criterios de evaluacin son: (S) = 1; (P)arcial = 0.5; y (N)o = 0. Los criterios de evaluacin para las propuestas centradas en la gestin de la trazabilidad a partir de transformaciones de modelos son: CE-1. La propuesta metodolgica sugiere o indica cmo se debera automatizar la identificacin de las relaciones de trazabilidad? (Recurdese que las relaciones de trazabilidad son aquellas que se definen entre tipos de elementos, por ejemplo clases o elementos de un metamodelo) Valores: (S), proporciona o especfica algn mtodo para mejorar el nivel de automatizacin de esta tarea; (P)arcial, no indica cmo debera automatizarse, pero lo considera deseable; (N)o, la propuesta no considera la automatizacin de la identificacin de las relaciones de trazabilidad, por tanto la asume como una tarea manual. CE-2. La propuesta metodolgica sugiere o indica cmo se debera automatizar la generacin de las trazas? (Recurdese que los enlaces de trazas, o simplemente trazas, son las instancias de las relaciones de trazabilidad, por ejemplo, entre objetos o elementos de un modelo). Valores: (S), la propuesta define cmo sera posible automatizar la generacin de las trazas; (P)arcial, la propuesta no especifica cmo automatizar esta tarea, aunque considera que sera deseable automatizarla; (N)o, no considera la automatizacin de la generacin de trazas. Es decir, se considera una actividad manual. CE-3. La propuesta para la gestin de la informacin de trazabilidad es independiente de cualquier lenguaje de transformacin concreto? Valores: (S), la propuesta es independiente de cualquier lenguaje de transformacin; (P)arcial, no es completamente independiente, o es dependiente de un lenguaje concreto pero consideran deseable que fuera independiente; (N)o, la propuesta se define para un lenguaje concreto. CE-4. Propone alguna tcnica para el almacenamiento de las trazas?

96

lvaro Jimnez Rielo

Valores: (S), la propuesta sugiere cmo almacenar las trazas generadas, en general, existen dos aproximaciones: almacenamiento interno (en los modelos terminales que describen el sistema) y almacenamiento externo (en otras estructuras de datos ad-hoc); (P)arcial, considera que el almacenamiento de las trazas es una caracterstica a tener en cuenta, pero no sugiere ningn mtodo de almacenamiento; (N)o, no considera el almacenamiento de las trazas. CE-5. Propone alguna tcnica para la visualizacin o representacin de las trazas? Valores: (S), sugiere el desarrollo de una herramienta ad-hoc para la visualizacin de trazas o sugiere el empleo de mecanismo existente para este propsito; (P)arcial, sugiere el empleo de visualizaciones no especficas para la representacin de trazas, es decir son representaciones genricas y por tanto, el resultado no es ptimo. Por ejemplo, si las trazas son almacenadas en modelos y emplea un editor de modelos genrico como el que ofrece EMF; (N)o, la propuesta no sugiere ningn tipo de mecanismo para la visualizacin de trazas. CE-6. Sugiere o propone tcnicas para llevar a cabo el anlisis de la informacin de trazabilidad generada? Valores: (S), la propuesta centra parte de sus objetivos en proporcionar tcnicas de anlisis de la informacin de trazabilidad; (P)arcial, la propuesta considera interesante clasificar o analizar la informacin obtenida a partir de las trazas, pero no especfica cmo hacerlo; (N)o, la propuesta no considera el anlisis de las trazas. CE-7. Proporciona alguna implementacin, herramienta, o soporte tecnolgico? Valores: (S), proporciona una herramienta o marco de trabajo completo para dar soporte a la propuesta metodolgica; (P)arcial, proporciona una implementacin parcial de la propuesta; (N)o, se trata de una propuesta puramente terica que no ofrece implementacin para ponerla en prctica.

3.3.3

Extraccin de Datos

Para facilitar el anlisis y evaluacin de las propuestas que forman el estado del arte y dar respuesta a las preguntas anteriores es necesario recopilar cierta informacin de dichas propuestas. En esta revisin de la literatura se ha decidido extraer la siguiente informacin de cada una de las propuestas:

Estado del Arte 97

Ttulo, autores, resumen y ao de publicacin de cada estudio identificado (perteneciente a la propuesta). Los ttulos y los autores pueden consultarse en la Tabla A-4. Si las relaciones de trazabilidad se identifican de forma (semi-)automtica o si el usuario debe especificarlas manualmente. Nivel de abstraccin de la transformacin en el que se identifican las relaciones de trazabilidad (en el cdigo de la transformacin o en algn modelo de la transformacin a alto nivel). Si la informacin de trazabilidad puede ser generada a partir de una transformacin independiente de cualquier lenguaje de transformacin o, si por el contrario, depende de un lenguaje o motor de transformacin especfico. Si las trazas se generan (semi-)automticamente o si por el contrario, debe crearlas el usuario. La forma de almacenar los enlaces de traza (en modelos de trazas, repositorios, modelos del sistema, etc.). Tipo de metamodelo de trazabilidad propuesto (especfico o genrico), si aplica. Esto es, una propuesta puede proporcionar un metamodelo de trazabilidad genrico para todos los escenarios o puede permitir la definicin de un metamodelo especfico para cada escenario de trazabilidad concreto. La forma en que se visualizan/representan las trazas. Las tcnicas que proporciona para el anlisis de las trazas. Si ofrece soporte tecnolgico y cmo lo hace (si aplica).

Estos datos se extraen en la siguiente sub-seccin, donde se analiza en detalle cada una de las propuestas por separado.

3.3.4

Anlisis de las propuestas

Una vez que se ha definido la informacin que se va a extraer y evaluar de cada propuesta, en esta seccin se analizan de forma individual las propuestas identificadas y se comparan de acuerdo a los criterios de evaluacin definidos en la seccin 3.3.2. Conviene mencionara que cada una de las propuestas (o grupos de estudios primarios) est formada por aquellos estudios que tienen uno o ms autores en comn y las ideas que se defienden en dichos trabajos corresponden a una misma lnea de investigacin.

98

lvaro Jimnez Rielo

3.3.4.1

Bond et al. El trabajo presentado en [33] est centrado en el mbito del desarrollo de sistemas embebidos. Los autores defienden que aplicar MDA puede ser muy beneficioso para el desarrollo de estos sistemas. Sin embargo, plantean que cuando un modelo es transformado en otros modelos de menor nivel de abstraccin, se debera asegurar la interoperabilidad entre estos modelos de menor nivel, entendindola como la posibilidad de intercambiar informacin entre los modelos. Esto es, por ejemplo, si un modelo X de alto nivel incluye un elemento a y un elemento b conectados entre s, cuando a partir del modelo X se generen otros modelos a bajo nivel, se debera poder conectar el elemento a de uno de los modelos generados con el elemento b de otro de los modelos generados. Para dar respuesta a este planteamiento, proponen una aproximacin basada en el empleo de modelos de trazas que son generados automticamente a partir de las relaciones definidas en las transformaciones de los modelos. Para llevar a cabo la transformacin, los autores proponen el uso del motor de transformacin ModTransf (http://www.lifl.fr/~dumoulin/mdaTransf/), basado en reglas XML. As la transformacin, adems de proporcionar el modelo destino, genera un modelo de trazas. Posteriormente, dicho modelo de trazas es analizado para saber qu ajustes hay que realizar para permitir el intercambio de informacin entre los modelos generados. A partir de esta informacin se genera un puente (bridge) que solventa los problemas encontrados y permite la interconexin entre dichos modelos. Los modelos de trazas generados son conformes a un metamodelo de trazabilidad de propsito general que incluye elementos presentes en una transformacin de modelos: elementos de los modelos y relaciones entre los elementos. Adems, permite definir qu operaciones (creacin, enlace, copia, conversin y transformacin) se establecen entre los elementos. A continuacin, se presentan los datos extrados del anlisis de la propuesta que permitirn asignar un valor a los criterios de evaluacin definidos en la seccin 3.3.2: Identificacin de las relaciones de trazabilidad. Las relaciones de trazabilidad se identifican automticamente a partir de las relaciones implcitas en las reglas de transformacin. Nivel de abstraccin al que se identifican las relaciones de trazabilidad. Como se indica en el punto anterior, las relaciones se extraen a partir de las

Estado del Arte 99

propias reglas de la transformacin que se ejecutan, por tanto, se considera que son identificadas a bajo nivel. Generacin de enlaces de traza. Los autores proponen que, haciendo uso de las relaciones de trazabilidad identificadas, al ejecutar la transformacin se obtenga la salida de la transformacin y un modelo que contenga las trazas entre los elementos implicados en dicha transformacin. Las transformaciones son ejecutadas en el motor de transformacin ModTransf que est basado en reglas de tipo XML. Almacenamiento. La propuesta sugiere que las trazas obtenidas sean almacenadas en un modelo de trazas creado para este propsito, es decir, proponen almacenamiento externo. Metamodelo de trazabilidad. La propuesta presenta un metamodelo de trazabilidad genrico. Dado que las relaciones de trazabilidad se identifican a partir de las relaciones existentes en las transformaciones, dicho metamodelo se compone de los elementos bsicos que definen una transformacin de modelos: los elementos de los propios modelos y las relaciones entre dichos elementos. Adems de esta informacin, permite modelar qu operaciones (creacin, enlace, copia, conversin y transformacin) se establecen entre los elementos. Visualizacin. Los autores no indican ni sugieren cmo visualizar las trazas generadas. Sin embargo, en [33] muestran un modelo de trazas en trminos de XML. Por tanto se puede interpretar que, aunque no aborden la visualizacin de las trazas, consideran que es una tarea a tener en cuenta en el contexto de la propuesta. Anlisis de las trazas. La propuesta no considera el anlisis de la informacin de trazabilidad generada. Soporte tecnolgico. Los autores no proporcionan ninguna herramienta o implementacin para dar soporte a la propuesta metodolgica presentada. 3.3.4.2 Boronat et al. Boronat, Cars y Ramos proponen en [36] un marco de trabajo para la gestin de modelos genricos basado en la definicin de operadores algebraicos. Esta propuesta se apoya en la idea de que en todo proceso MDA, los modelos son refinados continuamente y para ello, deben existir operadores que permitan especificar la forma de realizar dichos refinamientos. Esta propuesta no est orientada a la gestin de la trazabilidad en el desarrollo de transformaciones de modelos. Sin embargo, ha sido incluida en este estado del arte porque su

100

lvaro Jimnez Rielo

principal contribucin es proporcionar un mtodo para la generacin de trazas independiente del lenguaje de transformacin empleado. El mtodo propuesto es el siguiente: para generar el modelo de trazas, el usuario puede emplear el metamodelo de trazabilidad genrico que proporciona MOMENT, o bien extender dicho metamodelo para construir uno especfico. A continuacin, a partir de los operadores algebraicos definidos sobre los modelos, se extrae el modelo de trazas de forma automtica. Adems, tambin se permite que el usuario defina las trazas manualmente en un modelo de trazas conforme al metamodelo seleccionado. Para dar soporte tecnolgico a esta propuesta, los autores emplean la herramienta MOMENT (MOdel manageMENT, http://moment.dsic.upv.es/) que ha sido implementada como una extensin de Eclipse. Concretamente, utiliza Maude [46] para la implementacin de las especificaciones algebraicas y EMF para llevar a cabo el modelado. En cuanto a los datos extrados del anlisis de la propuesta: Identificacin de las relaciones de trazabilidad. Los autores proponen el empleo de operadores algebraicos para especificar operaciones de gestin de modelos. A partir de dichos operadores se identifican automticamente las relaciones de trazabilidad existentes entre los elementos de los modelos. Nivel de abstraccin al que se identifican las relaciones de trazabilidad. Esta propuesta no est orientada a la generacin de la trazabilidad a partir de transformaciones de modelos. Por tanto, este criterio no aplica en esta propuesta. Generacin de enlaces de traza. Los autores proponen que las trazas se generen automticamente cada vez que se ejecuta un operador algebraico que realiza una operacin que relaciona dos modelos cualesquiera. Almacenamiento. Las trazas generadas se almacenan automticamente en modelos de trazas conformes al metamodelo de trazabilidad definido por el usuario o al metamodelo de trazabilidad genrico ofrecido. Metamodelo de trazabilidad. Los autores presentan un metamodelo de trazabilidad genrico descrito en trminos de UML e implementado con EMF. Dicho metamodelo permite establecer las relaciones entre los elementos de varios modelos, independientemente de cmo sean sus correspondientes metamodelos. Visualizacin. En las conclusiones de este trabajo, los autores indican que estn analizando el editor propuesto por la herramienta AMW para editar y

Estado del Arte 101

visualizar los modelos de trazas. En [35], Boronat presenta un editor ad-hoc para modelos de trazas, basado en el editor de AMW. Anlisis de las trazas. La propuesta presentada no considera el anlisis de la informacin de trazabilidad generada. Soporte tecnolgico. MOMENT es la herramienta que da soporte a esta propuesta metodolgica. Se trata de una herramienta desarrollada sobre Eclipse que proporciona un conjunto de operadores genricos para interactuar con modelos EMF. 3.3.4.3 Grammel y Kastenholz En [82], Grammel y Kastenholz realizan un estudio acerca de los retos, problemas y limitaciones a los que se enfrenta el Desarrollo de Software Dirigido por Modelos (DSDM) en cuanto a la gestin de la trazabilidad. Destacan la gran cantidad de metamodelos de trazabilidad existentes y las diferentes aproximaciones empleadas por los motores de transformacin para la gestin de la trazabilidad (gestin implcita y gestin explcita). La gestin implcita de la trazabilidad consiste en obtener automticamente las trazas a partir de las relaciones definidas en la transformacin. Esta aproximacin implica algunas desventajas derivadas de su automatizacin como por ejemplo que el desarrollador no participa directamente en la definicin y creacin de las trazas, por tanto no puede adaptarlas a sus necesidades. Adems, en estos casos cada motor de transformacin define su propio metamodelo de trazabilidad, por lo que surge un problema de interoperabilidad a la hora de manejar trazas generadas por distintos motores de transformacin. En cambio, la gestin explcita implica un mayor esfuerzo para los desarrolladores ya que es necesario que incluyan, explcitamente, las relaciones de trazabilidad en las reglas de transformacin. Dado que ambas aproximaciones tienen ventajas e inconvenientes, los autores presentan una propuesta que permite unificar los metamodelos de trazabilidad para favorecer la interoperabilidad entre los modelos de trazas, adecuar el metamodelo a las necesidades concretas de los escenarios de trazabilidad y minimizar los esfuerzos de los desarrolladores para la generacin de trazas. El objetivo principal es el desarrollo de un framework de trazabilidad genrico que extienda las funcionalidades proporcionadas por los actuales motores de transformaciones de modelos, de forma que se aprovechen las ventajas que ofrecen estos motores, independientemente de si gestionan la trazabilidad implcita o explcitamente.

102

lvaro Jimnez Rielo

La propuesta presentada consiste en una interfaz genrica llamada GTI (Generic Traceability Interface) que sirve para establecer un punto de conexin con los diferentes mecanismos de transformaciones de modelos. GTI permite obtener, de forma automtica, las relaciones de trazabilidad que son generadas en la transformacin, ya sea de forma implcita o explcita, y almacenarlas en un repositorio. Para el tratamiento de la informacin de la trazabilidad, de forma genrica e independiente de los conectores empleados, presentan un lenguaje de dominio especfico para trazabilidad: Trace-DSL, compuesto por un metamodelo de trazabilidad genrico que permite definir relaciones de creacin, actualizacin, consulta y borrado entre diferentes artefactos. Adems, dicho metamodelo puede ser extendido mediante el empleo de facetas para cada artefacto y relacin. En cuanto a los datos extrados del anlisis de la propuesta: Identificacin de las relaciones de trazabilidad. El trabajo presentado propone que las relaciones de trazabilidad se identifiquen automtica o manualmente, dependiendo del motor de transformacin que se extienda. Nivel de abstraccin al que se identifican las relaciones de trazabilidad. La propuesta no establece ningn nivel de abstraccin para especificar la transformacin, solo propone el uso de una interfaz genrica para extender motores de transformacin ya existentes. Por tanto, se asume que el nivel de abstraccin en el que se identifican las relaciones de trazabilidad es el ms bajo, es decir la transformacin que se ejecuta. Generacin de enlaces de traza. Las trazas se generan automticamente a partir de la ejecucin de la transformacin, sea cual sea el motor de transformacin empleado. Almacenamiento. Los autores proponen que las trazas generadas sean almacenadas en un repositorio creado para cumplir con este objetivo. Dichas trazas debern ser almacenadas en un formato conforme al metamodelo del lenguaje Trace-DSL. Metamodelo de trazabilidad. En esta propuesta se presenta Trace-DSL, un lenguaje definido por un metamodelo de trazabilidad genrico que puede extenderse a travs de facetas para cada artefacto y relacin. Visualizacin. Los autores no especifican cmo se debera visualizar o representar la informacin de trazabilidad obtenida de la transformacin. Anlisis de las trazas. La propuesta no considera el anlisis de la informacin de trazabilidad generada.

Estado del Arte 103

Soporte tecnolgico. Los autores no especifican que hayan implementado la propuesta y dado que no se ha encontrado ninguna herramienta que ofrezca soporte, se asume que no dispone de soporte tecnolgico. 3.3.4.4 Guerra et al. En [87], los autores Guerra, De Lara, Kolovos y Paige presentan una aproximacin basada en el empleo de patrones declarativos para definir especificaciones inter-modelado. Esta propuesta no tiene por objetivo dar soporte a la gestin de la trazabilidad en el desarrollo de transformaciones, sin embargo, ha sido incluida en este estado del arte porque el empleo de especificaciones declarativas que se presenta, puede trasladarse a los desarrollos de transformaciones de modelos con lenguajes de transformacin declarativos o hbridos. En este contexto, el concepto inter-modelado se entiende como la construccin de modelos que describen cmo deben relacionarse los lenguajes de modelado. Esta definicin incluye diferentes tareas, propias de la Ingeniera Dirigida por Modelos, como por ejemplo las transformaciones de modelos o la gestin de la trazabilidad. Los autores defienden que a partir de una especificacin inter-modelado que defina las relaciones entre dos lenguajes de modelado sera posible llevar a cabo diferentes tareas como transformaciones o generacin de trazas entre modelos elaborados con dichos lenguajes. Para validar la propuesta, los autores presentan un caso de estudio centrado en dos escenarios concretos de inter-modelado: comparativa de modelos bajo condiciones especficas (model matching) y generacin de trazas. Adems, para dar soporte tecnolgico a la propuesta presentan PAMOMO (http://astreo.ii.uam.es/~eguerra/tools/pamomo/main.htm), una herramienta que permite llevar a cabo la definicin de especificaciones inter-modelado y a partir de ellas, realizar operaciones como la construccin o verificacin de modelos de trazas. Para traducir y ejecutar las especificaciones, esta herramienta emplea el lenguaje EOL (Epsilon Object Language [115]) y proporciona dos modos de ejecucin: off-line y on-line. En el primero de ellos, la especificacin se compila una vez y puede usarse para cualquier modelo origen. En el modo on-line, el desarrollador elige los modelos origen y destino y la especificacin es aplicada directamente sobre ellos. Como resultado de la ejecucin de estas especificaciones, se obtiene un modelo de trazas que puede ser visualizado en ModeLink (http://www.eclipse.org/epsilon/doc/modelink/), un editor desarrollado como parte de la familia Epsilon, que permite visualizar al mismo tiempo los

104

lvaro Jimnez Rielo

modelos origen y destino y el modelo que contiene las relaciones entre los elementos de ambos modelos. En cuanto a los datos extrados del anlisis de la propuesta: Identificacin de las relaciones de trazabilidad. Las relaciones de trazabilidad se identifican manualmente a partir de la definicin de patrones declarativos que especifican operaciones entre modelos. Nivel de abstraccin al que se identifican las relaciones de trazabilidad. La propuesta no est orientada a la generacin de trazas a partir del desarrollo y ejecucin de transformaciones de modelos, por ello, las relaciones de trazabilidad no se relacionan con la definicin de transformaciones. Por tanto, este dato no aplica en esta propuesta. Generacin de enlaces de traza. Los autores presentan en este trabajo una propuesta para la definicin de patrones declarativos que permitan llevar a cabo operaciones inter-modelado. En este trabajo presentan un caso de estudio centrado en dos escenarios, uno de ellos consiste en la creacin automtica de modelos de trazas a partir de la definicin de especificaciones inter-modelado. Almacenamiento. La propuesta metodolgica no especifica cmo se deberan almacenar las trazas generadas. Sin embargo, en la seccin donde se presenta la herramienta que da soporte a dicha propuesta, los autores especifican claramente que las trazas son almacenadas en un modelo externo, en trminos de Ecore. Metamodelo de trazabilidad. Los autores no presentan ningn metamodelo de trazabilidad. En cambio, s presentan un metamodelo genrico para el modelado de patrones declarativos que relacionan dos lenguajes de modelado. Visualizacin. Los autores no especifican en la propuesta cmo deberan visualizarse los modelos de trazas. Sin embargo, en la herramienta que da soporte tecnolgico a la propuesta (PAMOMO) emplean el editor ModeLink para visualizar los modelos de trazas obtenidos. Anlisis de las trazas. La propuesta presentada no considera el anlisis de la informacin de trazabilidad generada. Soporte tecnolgico. La propuesta metodolgica presentada en este trabajo es soportada por PAMOMO, una herramienta construida sobre Eclipse que permite la definicin de especificaciones inter-modelado y a partir de ellas, la ejecucin de operaciones sobre modelos de EMF, como la construccin de modelos de trazas.

Estado del Arte 105

3.3.4.5

Jouault et al. En [103], Jouault presenta una aproximacin para la gestin de la trazabilidad en el desarrollo de transformaciones de modelos implementadas con ATL. Jouault propone definir explcitamente las relaciones de trazabilidad en las reglas que implementan la transformacin. El autor propone almacenar las trazas generadas en un modelo ms del proceso de desarrollo y para ello, propone un metamodelo de trazabilidad genrico. Para aplicar esta idea a transformaciones ya existentes y facilitar la construccin de nuevas transformaciones se presenta TraceAdder, una herramienta implementada como una transformacin HOT con ATL. Dado que ATL permite extraer el modelo de una transformacin a partir del cdigo que la implementa, TraceAdder consume un modelo de transformacin ATL para producir un nuevo modelo de dicha transformacin al que aade la informacin necesaria para generar el modelo de trazas. Las principales contribuciones de este trabajo son: el uso de las transformaciones de modelos como un modelo ms del proceso de desarrollo e incorporar explcitamente las relaciones de trazabilidad en las reglas de la transformacin. La principal ventaja de esta propuesta es el dbil acoplamiento que existe entre la generacin de la trazabilidad y el motor de la transformacin, ya que el usuario tiene la posibilidad de definir explcitamente qu relaciones existen y cmo modelarlas. As, la generacin de las trazas depende de las decisiones del desarrollador y no de cmo el motor de transformacin gestiona la trazabilidad. Las ideas propuestas por Jouault en [103] han servido como gua para un gran nmero de trabajos posteriores. As, en [127] se presenta un estudio acerca de cmo modularizar el desarrollo de transformaciones implementadas en lenguajes basados en reglas. Los autores presentan varios escenarios implementados en ATL, uno de ellos es la gestin de la trazabilidad en el desarrollo de transformaciones de modelos y para ello, incluyen la informacin de la trazabilidad en las reglas de transformacin, tal como propone Jouault. En [17], Barbero, Didonet del Fabro y Bzivin presentan una clasificacin que divide la gestin de la trazabilidad en dos niveles: nivel microscpico y nivel macroscpico. El nivel microscpico se corresponde con relaciones de trazabilidad entre elementos de diferentes modelos y el nivel macroscpico establece relaciones de trazabilidad entre los propios modelos. Para llevar a cabo

106

lvaro Jimnez Rielo

la gestin de la trazabilidad a nivel microscpico, emplean la propuesta que presenta Jouault. Freddy Allilaire presenta en [6] un pequeo estudio centrado en el empleo de ATL en la herramienta Obeo Traceability. Esta herramienta proporciona un mecanismo para la gestin de la trazabilidad basado en la gestin interna de la trazabilidad que realiza el motor de transformacin de ATL. Tambin soporta la gestin explcita de la trazabilidad basndose en la idea presentada por Jouault. Finalmente, en [68], los autores Falleri, Huchard y Nebut presentan la implementacin de un framework para la gestin de la trazabilidad implementado en Kermeta (http://www.kermeta.org). Este framework utiliza un metamodelo de trazabilidad genrico que, como indican los propios autores, se inspira en el trabajo de Jouault. Para generar los modelos de trazabilidad, tambin emplean la idea de Jouault, ya que la generacin de trazas se basa en incluir informacin en las transformaciones de modelos. En cuanto a los datos extrados del anlisis de la propuesta: Identificacin de las relaciones de trazabilidad. Aunque inicialmente propone la identificacin manual de las relaciones de trazabilidad por parte del desarrollador de la transformacin, la herramienta TraceAdder permite identificar las relaciones de trazabilidad automticamente a partir de las relaciones existentes en las reglas de la transformacin. Nivel de abstraccin al que se identifican las relaciones de trazabilidad. Sugiere que las relaciones de trazabilidad sean identificadas a nivel del cdigo que implementa la transformacin. Sin embargo, la herramienta que da soporte a la propuesta metodolgica identifica las relaciones de trazabilidad en un modelo conforme al metamodelo del lenguaje ATL, es decir, identifica las relaciones de trazabilidad a nivel PDM. Generacin de enlaces de traza. El autor propone aprovechar la ejecucin de las transformaciones de modelos ATL para generar al mismo tiempo y de forma automtica, las trazas entre los elementos implicados en la transformacin. Almacenamiento. Defiende que las trazas deberan almacenarse y tratarse como un modelo ms del sistema. Por ello, propone que las trazas generadas a partir de las transformaciones sean almacenadas en un modelo de trazas, es decir plantea un tipo de almacenamiento externo.

Estado del Arte 107

Metamodelo de trazabilidad. Para almacenar y modelar las trazas del sistema, propone un metamodelo de trazabilidad genrico y bsico que permite describir elementos de los modelos y las relaciones entre dichos elementos. Visualizacin. Aunque, en [103], el autor no especifica cmo se deberan visualizar o representar los modelos de trazas, en trabajos posteriores se presentan propuestas para visualizar este tipo de modelos usando los editores proporcionados por AMW y EMF. Anlisis de las trazas. Esta propuesta no considera el anlisis de las trazas generadas. Soporte tecnolgico. En [103] se presenta TraceAdder, una transformacin tipo HOT, implementada en ATL, que recibe como entrada un modelo que describe una transformacin ATL (nivel PDM) y genera automticamente otro modelo de la transformacin. El modelo ATL resultante ser el mismo pero aadiendo, a cada una de las reglas de transformacin, la informacin necesaria para que al ejecutar el cdigo que implementa la transformacin se obtenga, adems del modelo destino, un modelo con las trazas existentes entre los elementos de los modelos implicados en la transformacin. 3.3.4.6 Kolovos et al. Los autores Kolovos, Paige y Polack presentan en [117] un trabajo centrado en analizar las diferentes formas de almacenar la informacin de trazabilidad entre modelos. Esta propuesta no est centrada en la gestin de la trazabilidad en el desarrollo de transformaciones de modelos sino en la gestin de los modelos de trazabilidad. Sin embargo, sus aportaciones en cuanto a la especificacin de los metamodelos resultan de gran inters para el objetivo de esta revisin de la literatura. Los autores analizan dos aproximaciones: almacenar las trazas en los propios modelos que describen el sistema y crear modelos de trazas ad-hoc. La primera aproximacin facilita la visualizacin y el anlisis por parte de observadores humanos debido a que toda la informacin se almacena en un mismo modelo. Sin embargo, contamina el modelo, ya que incluye informacin que no es propia de la especificacin del sistema. La segunda aproximacin defiende el empleo de un modelo de trazas ad-hoc, encargado de almacenar toda esta informacin. Estos modelos de trazas ad-hoc deben ser conformes a un metamodelo de trazabilidad. La principal desventaja de esta aproximacin es que a la hora de analizar los modelos y las relaciones de trazabilidad, la informacin se

108

lvaro Jimnez Rielo

encuentra dispersa en varios modelos (los modelos trazados y los modelos de trazas). Dado que ambas aproximaciones tienen ventajas e inconvenientes, en [117], los autores proponen combinar ambas ideas. As, proponen generar modelos externos que recojan los enlaces de traza y posteriormente, fusionarlos (merging) con los modelos del sistema, utilizando EML (Epsilon Merging Language [116]), de forma que se consiguen modelos a la carta. Continuando el estudio de las diferentes alternativas para el almacenamiento de la trazabilidad, Drivalos, Paige, Fernandes y Kolovos presentan, en [62], un estudio centrado en evaluar la conveniencia de usar metamodelos de trazabilidad genricos o especficos para cada escenario concreto. Los primeros permiten modelar todos los escenarios de trazabilidad y favorecen la interoperabilidad, ya que un modelo de trazas generado mediante una herramienta puede ser manejado por otra, a partir de la ejecucin de una transformacin entre los metamodelos de trazabilidad. Su principal inconveniente es que no siempre se ajusta fielmente a todas las posibles relaciones de trazabilidad. En cambio, el uso de un metamodelo especfico s permite ajustarse a las caractersticas del contexto, ya que se disea teniendo en cuenta dichas caractersticas. Sin embargo, plantea dos inconvenientes: mayor esfuerzo de construccin para los desarrolladores y reduce la interoperabilidad ya que no permite definir una transformacin general que proporcione interoperabilidad entre los escenarios. En [62], se defiende el empleo de metamodelos de trazabilidad especficos porque permiten ajustarse a la naturaleza de cada escenario concreto. Adems indican que, los avances en herramientas para la gestin de modelos, reducirn estas desventajas. En esta lnea, en [60], presentan TML (Traceability Metamodelling Language), un lenguaje para reducir el esfuerzo que supone la construccin de metamodelos de trazabilidad. Para solucionar el problema de la interoperabilidad entre modelos de trazas, proponen el desarrollo de transformaciones HOT entre metamodelos conformes al metamodelo de TML. En [61] se presenta una mejora de la propuesta que permite mantener y evolucionar automticamente la trazabilidad modelada con TML, mediante el empleo de scripts. Las ideas anteriores pueden verse aplicadas en [163], donde se plantean de forma unificada las conclusiones obtenidas en los estudios anteriores para, por un lado demostrar cmo identificar los tipos de enlaces de traza y por otro, describir una aproximacin para definir la semntica de las trazas.

Estado del Arte 109

En cuanto a los datos extrados del anlisis de la propuesta: Identificacin de las relaciones de trazabilidad. La propuesta no proporciona informacin acerca de cmo identificar las relaciones de trazabilidad. Nivel de abstraccin al que se identifican las relaciones de trazabilidad. Al no indicar cmo se identifican las relaciones de trazabilidad, esta informacin no aplica. Generacin de enlaces de traza. La propuesta no tiene por objetivo generar enlaces de traza. Sin embargo, sera posible crear manualmente modelos de trazas conformes a dichos metamodelos definidos con TML. Almacenamiento. Esta propuesta realiza un estudio detallado acerca de cmo se deberan almacenar las trazas. Analiza las ventajas y los inconvenientes de almacenar las trazas en los mismos modelos que describen el sistema y crear modelos de trazas ad-hoc para almacenamiento de esta informacin. En [117], proponen combinar ambas aproximaciones. Sin embargo, a partir de [62], los autores comienzan a defender el almacenamiento en modelos de trazas, es decir abogan por el almacenamiento externo. Metamodelo de trazabilidad. Para almacenar las trazas en modelos de trazas, los autores estudian la conveniencia de emplear metamodelos de trazabilidad genricos o crear metamodelos especficos para cada escenario. Finalmente, optan por emplear metamodelos de trazabilidad especficos. As, para facilitar la construccin de estos metamodelos presentan el lenguaje TML. Visualizacin. No consideran la visualizacin de la informacin de trazabilidad. Anlisis de las trazas. En [163] realizan un estudio centrado en mostrar cmo identificar los tipos de enlace de traza implicados en un proceso MDE. Se trata de un proceso denominado TEAP ( Traceability Elicitation and Analysis Process) para guiar la construccin de clasificaciones de trazas. Soporte tecnolgico. No dispone de herramienta que soporte la propuesta. Sin embargo, en [163] indican que estn trabajando en su desarrollo. 3.3.4.7 Levendovszky et al. Los autores Levendovszky, Balasubramanian, Smith, Shi y Karsai presentan en [134], una propuesta para la gestin de la trazabilidad en el desarrollo dirigido por modelos de sistemas areos, donde la gestin de la trazabilidad se considera un aspecto obligatorio durante el desarrollo.

110

lvaro Jimnez Rielo

Segn los principios del desarrollo dirigido por modelos, todas las modificaciones o evoluciones del sistema deben ser consecuencia de la ejecucin de una transformacin. Por este motivo, los autores presentan una aproximacin para la gestin de la trazabilidad a partir del desarrollo y ejecucin de transformaciones, ya sean de tipo M2M o M2T. El mtodo propuesto se basa en la idea propuesta por Jouault en [103]: definir las relaciones de trazabilidad en la especificacin de la transformacin y a partir de dichas relaciones, obtener automticamente las trazas como resultado de la ejecucin de la transformacin. Para llevar a cabo las transformaciones M2M, proponen el uso de GReAT, una aproximacin basada en reescritura de grafos [16]. Por otro lado, para las transformaciones M2T proponen el uso de lenguajes imperativos. Como resultado de ambos tipos de transformaciones se obtiene, por un lado el modelo o cdigo destino y por otro lado, las trazas. Los autores proponen que las trazas generadas sean representadas de distintas formas, dependiendo del tipo de transformacin ejecutada. As, si es una transformacin M2M, las trazas debern ser representadas en forma de grafos y si se trata de una transformacin M2T, las trazas sern representadas en forma textual. Para gestionar y establecer la estructura de las trazas generadas entre los modelos presentan un metamodelo de trazabilidad genrico. Este metamodelo permite representar los elementos que forman parte de las reglas de la transformacin y las trazas que existen entre ellos. Aunque en [134], los autores indican que han construido una herramienta que muestra las trazas entre los elementos de los modelos y el cdigo del sistema, no proporcionan informacin acerca de dicha herramienta y no ha sido posible acceder a ella. Como trabajo futuro, los autores plantean la posibilidad de incluir las relaciones de trazabilidad de forma automtica en la transformacin, aunque no indican cmo hacerlo. En cuanto a los datos extrados del anlisis de la propuesta: Identificacin de las relaciones de trazabilidad. La propuesta sigue una aproximacin similar a la presentada por Jouault en [103] para la creacin de la informacin de trazabilidad: las relaciones de trazabilidad son incluidas directamente en la transformacin. En esta propuesta no se proporcionan medios para automatizar la identificacin de estas relaciones, por tanto, se considera una tarea manual que debe realizar el desarrollador de la transformacin. Sin embargo, en las conclusiones de [134] plantean como principal lnea de investigacin futura analizar la posibilidad de automatizarla. Nivel de abstraccin al que se identifican las relaciones de trazabilidad. Esta propuesta no establece ningn nivel de abstraccin para el desarrollo y

Estado del Arte 111

especificacin de las transformaciones. Por ello, el nivel al que se identifican las relaciones de trazabilidad es el nivel de menor abstraccin posible, es decir el cdigo de la propia transformacin. Generacin de enlaces de traza. Como ya se ha dicho anteriormente, esta propuesta sigue una aproximacin similar a la presentada por Jouault. Por tanto, al igual que dicho autor, proponen que los enlaces de traza sean generados automticamente a partir de la ejecucin de transformaciones de modelos. Almacenamiento. En cuanto al almacenamiento de las trazas generadas, los autores proponen el empleo de dos estructuras: una para almacenar las trazas generadas a partir de transformaciones M2M y otra para las trazas generadas a partir de transformaciones M2T. En la primera, las trazas son representadas en forma de grafos y en la segunda, de forma textual. Conviene mencionar que no se han encontrado ejemplos que muestren estos tipos de almacenamiento. Metamodelo de trazabilidad. Los autores presentan un metamodelo de trazabilidad genrico para establecer la estructura de las trazas generadas a partir de la ejecucin de las transformaciones de modelos. Este metamodelo permite describir los elementos que forman parte de las reglas de la transformacin y las trazas existentes entre ellos. Visualizacin. Como ya se ha mencionado, proponen que las trazas generadas se representen de diferente forma, dependiendo del tipo de transformacin ejecutada. As, en el caso de transformaciones entre modelos, las trazas son obtenidas en forma de grafos y en el caso de transformaciones de modelo a texto, de forma textual. Anlisis de las trazas. La propuesta no considera el anlisis de las trazas generadas. Soporte tecnolgico. En las conclusiones del trabajo, los autores indican que han implementado una herramienta para representar las trazas generadas entre los elementos de los modelos que especifican y el cdigo del sistema, sin embargo no especifican las caractersticas de dicha herramienta ni los medios para acceder a ella. 3.3.4.8 Oldevik et al. En los trabajos [150] y [153], los autores presentan una aproximacin para la gestin de la trazabilidad en el desarrollo de transformaciones M2T. Dado que el cdigo que implementa el sistema es generado mediante estas transformaciones, los autores defienden que, a travs de ellas, es posible generar las trazas que

112

lvaro Jimnez Rielo

relacionan los elementos de los modelos con los bloques de cdigo que los implementan. En estos trabajos, los autores analizan dos lenguajes de generacin de cdigo para la gestin de la trazabilidad en el desarrollo de transformaciones M2T: MOF Model to Text Transformation [162] y MOFScript [149]. La principal diferencia que existe entre ambas aproximaciones es que MOF Model to Text Transformation gestiona la trazabilidad de forma explcita y MOFScript lo hace de forma implcita. A pesar de esta diferencia, segn los autores, ambas aproximaciones pueden ser igualmente vlidas. Sin embargo, finalmente deciden presentar su propuesta usando MOFScript y de hecho, ya en [153] se centran totalmente en el desarrollo de la propuesta para este lenguaje. El lenguaje MOFScript dispone de su propio metamodelo de trazabilidad que permite definir referencias a elementos de los modelos y/o bloques de cdigo de los ficheros fuente y las trazas existentes entre ellos. A partir de este metamodelo, es posible crear un modelo de trazas cada vez que se invoca la generacin de cdigo. Para poner en prctica esta propuesta, emplean la herramienta que da soporte al lenguaje MOFScript. Adems, en [153] presentan un prototipo denominado Traceability Model Analysis para visualizar las trazas generadas, conocer qu partes del sistema no tienen trazas asociadas, identificar trazas obsoletas y realizar un anlisis de impacto del cambio. En [153] tambin plantean como trabajo futuro el desarrollo de una aproximacin intermedia que permita generar trazas de forma automtica y definirlas manualmente, as como definir un metamodelo ms genrico que no solo sea vlido en el contexto de las transformaciones M2T. Continuando esta lnea, en [143], Melby presenta su tesis de mster, dirigida por Olsen y Berre. Esta tesis proporciona una visin global de la trazabilidad en el contexto de MDE y sus principales aportaciones son un metamodelo de trazabilidad genrico y un editor grfico para modelos de trazas implementado con GMF (http://www.eclipse.org/modeling/gmf/). El metamodelo de trazabilidad propuesto no est orientado slo a la gestin de la trazabilidad en la generacin de cdigo, sino que permite modelar trazabilidad a lo largo de todo el ciclo de desarrollo. En cuanto a los datos extrados del anlisis de la propuesta: Identificacin de las relaciones de trazabilidad. Esta propuesta se basa en aprovechar las ventajas que ofrece el motor de generacin de cdigo MOFScript. Dicho motor proporciona un mecanismo de gestin implcita de la

Estado del Arte 113

trazabilidad que es empleado para la identificacin automtica de las relaciones de trazabilidad. Nivel de abstraccin al que se identifican las relaciones de trazabilidad. Al igual que otras propuestas anteriores, tampoco define niveles de abstraccin para especificar las transformaciones. Adems, en este caso las relaciones de trazabilidad son gestionadas de forma implcita por el motor que ejecuta la transformacin. Por todo ello, se asume que las relaciones de transformacin son identificadas a nivel de la transformacin que se ejecuta. Generacin de enlaces de traza. A pesar de que en [143] Melby proporcione un editor grfico que permita crear manualmente modelos de trazas, el ncleo de la propuesta aboga por crear los enlaces de traza de forma automtica a partir de la ejecucin de transformaciones de modelo a texto. Almacenamiento. Los autores no describen explcitamente cmo se deberan almacenar las trazas generadas, sin embargo en todo momento asumen que las trazas sern recogidas y almacenadas en un modelo de trazas creado especficamente para dicho objetivo. Metamodelo de trazabilidad. Debido a la evolucin constante de la propuesta, en cada uno de los trabajos analizados se propone un nuevo metamodelo de trazabilidad genrico. Los metamodelos presentados en [150] y [153] permiten definir trazas entre elementos de modelos y bloques de cdigo susceptibles de ser trazados, mientras el metamodelo presentado en [143] est diseado no solo para modelar trazas obtenidas a partir de transformaciones M2T, por tanto, permite definir trazas entre dos artefactos cualesquiera del sistema. Visualizacin. Debido a la evolucin de la propuesta se incluyen diferentes tipos de representaciones. As, mientras en [150] los modelos de trazas se representan en formato UML, en [153] se presenta un prototipo denominado TAP que proporciona un visor que muestra las trazas de forma jerrquica. Finalmente, en [143] se presenta un editor grfico desarrollado con GMF que permite editar y visualizar grficamente las trazas del sistema. Anlisis de las trazas. En [153] presentan TAP (Traceability Analysis Prototype), un prototipo que permite realizar varios anlisis sobre las trazas generadas, como anlisis de hurfanos, anlisis de cobertura y anlisis del impacto del cambio. Soporte tecnolgico. Una vez ms, se debe considerar la evolucin de la propuesta. Mientras en [150] no se presenta ninguna herramienta, en [153]

114

lvaro Jimnez Rielo

presentan un TAP que permite visualizar y analizar las trazas generadas; y en [143] presentan un editor grfico basado en GMF para el modelado de trazas. 3.3.4.9 Snchez et al. Los autores Snchez, Alonso, Rosique, lvarez y Pastor presentan en [181] una propuesta para la gestin de la trazabilidad de los requisitos de seguridad en el desarrollo dirigido por modelos de aplicaciones robticas para misiones de alto riesgo como por ejemplo tareas nucleares. No obstante, aunque esta propuesta se enmarca en un contexto concreto, puede ser extendida a otros tipos de sistemas. Los autores defienden que la aplicacin de tcnicas de trazabilidad puede resultar muy beneficiosa para el desarrollo de sistemas que requieran un alto grado de seguridad, ya que las trazas permiten analizar el desarrollo del sistema. Para poner en prctica esta idea, proponen un mtodo para gestionar la trazabilidad de los requisitos de seguridad, donde el usuario debe modelar los requisitos y desarrollar una arquitectura de la solucin de acuerdo a ellos. A continuacin, el usuario debe definir un primer modelo de trazas conforme a un metamodelo de trazabilidad genrico basado en el propuesto por Kolovos et al. en [117]. A partir de este modelo, en las sucesivas transformaciones que son implementadas mediante ATL (M2M) o JET (M2T), el framework se encarga de generar de forma automtica los diferentes modelos de trazas. Una de las principales aportaciones que realiza esta propuesta es la posibilidad de obtener un informe detallado, una vez que se han generado los modelos de trazas. Para proporcionar esta funcionalidad, los autores presentan la herramienta Safety-Requirements-Trace-Tool (SRTT). Esta herramienta genera, mediante una transformacin de modelo a texto implementada con JET, un informe de trazabilidad en formato HTML. Estos informes ofrecen la posibilidad de conocer qu requisitos se han tenido en cuenta durante el desarrollo, qu elementos del sistema los soportan y qu relacin existe entre ellos, as como realizar anlisis de impacto del cambio. En cuanto a los datos extrados del anlisis de la propuesta: Identificacin de las relaciones de trazabilidad. Las relaciones de trazabilidad son especificadas manualmente por el usuario en un primer modelo de trazas que servir para construir los sucesivos modelos de trazas. Nivel de abstraccin al que se identifican las relaciones de trazabilidad. Las relaciones de trazabilidad se identifican en un modelo que no se encuentra relacionado con las transformaciones que generan el sistema, por tanto, este dato no es aplicable a esta propuesta.

Estado del Arte 115

Generacin de enlaces de traza. Los autores proponen que el usuario defina manualmente el primer modelo de trazas y a partir de l, se generan automticamente otros dos modelos de trazas a lo largo del desarrollo del sistema. El primero de ellos es generado a partir de la ejecucin de una transformacin ATL (M2M) y el segundo es creado, en el momento de generar el cdigo que implementa el sistema, como resultado de ejecutar una transformacin JET (M2T). Almacenamiento. La propuesta, que sigue los principios de MDE, asume en todo momento que las trazas generadas durante el desarrollo de los sistemas deben ser almacenadas en modelos de trazas. Estos modelos de trazas son conformes al metamodelo de trazabilidad definido. Metamodelo de trazabilidad. Los autores presentan un metamodelo de trazabilidad genrico inspirado en el propuesto por Kolovos et al. en [117]. Este metamodelo es tan genrico que podra emplearse para definir cualquier tipo de relacin entre elementos de modelos, no solo trazas. Visualizacin. Esta propuesta no especifica cmo mostrar o representar los modelos de trazas obtenidos. Anlisis de las trazas. En este trabajo, los autores presentan SRTT ( SafetyRequirements-Trace-Tool), una herramienta implementada sobre JET que permite generar informes en formato HTML a partir de las trazas generadas. Segn los autores, este tipo de informes permiten conocer qu requisitos se han tenido en cuenta durante el desarrollo del sistema, qu elementos del sistema los soportan y qu relacin existe entre ellos, y llevar a cabo anlisis de impacto del cambio. Soporte tecnolgico. La propuesta metodolgica ha sido puesta en prctica mediante el uso de algunas herramientas basadas en Eclipse (ATL, JET, UML, EMF). Adems, en este trabajo los autores presentan SRTT, una herramienta implementada ad-hoc para generar informes a partir de los modelos de trazas obtenidos. 3.3.4.10 Valderas y Pelechano La propuesta presentada en [200] se enmarca en el contexto de la gestin de la trazabilidad de los requisitos en el desarrollo dirigido por modelos de aplicaciones web. Valderas y Pelechano proponen un mtodo basado en transformaciones de grafos, definidas en trminos de la herramienta AGG (Attributed Graph Grammars tool, http://tfs.cs.tu-berlin.de/agg/) que parte de un modelo de

116

lvaro Jimnez Rielo

requisitos basado en tareas para aplicaciones web. Posteriormente es convertido, mediante una transformacin XSL, a un formato XML conocido por AGG. A continuacin, el usuario define una transformacin AGG, detallando las relaciones de trazabilidad existentes entre los modelos. Esta transformacin consume el modelo de requisitos y genera un nuevo grafo que representa el modelo de navegacin del sistema web, incluyendo las trazas generadas a partir de la transformacin. En este trabajo, adems del mtodo anterior, los autores presentan TaskTracer, una herramienta que permite analizar modelos de navegacin que contienen informacin de trazabilidad en formato AGG. Mediante este anlisis, la herramienta detecta y almacena cada una de las trazas existentes en un repositorio de trazas, de acuerdo a un metamodelo genrico inspirado en los trabajos de Jouault [103] y Kolovos et al. [117]. Este metamodelo permite modelar las relaciones existentes entre los elementos del modelo de navegacin y los elementos del modelo de requisitos. Una vez que se han identificado y almacenado las trazas existentes, la herramienta genera un informe de trazabilidad en formato HTML que permite validar si la transformacin contempla todos los requisitos definidos y si lo hace de forma correcta. Adems, determina el impacto de los cambios en los requisitos. En cuanto a los datos extrados del anlisis de la propuesta: Identificacin de las relaciones de trazabilidad. La propuesta presenta un mtodo basado en transformaciones de grafos en el que los usuarios deben definir una transformacin en formato AGG. El mtodo requiere que los usuarios incluyan manualmente las relaciones de trazabilidad en dicha transformacin. Nivel de abstraccin al que se identifican las relaciones de trazabilidad. Como se ha indicado en el punto anterior, los desarrolladores deben incluir manualmente las relaciones de trazabilidad en la transformacin que se va a ejecutar, por tanto, se considera que la identificacin de las relaciones se lleva a cabo en el nivel de abstraccin ms bajo (el cdigo de la transformacin). Generacin de enlaces de traza. A partir de la informacin proporcionada por el usuario (modelo de requisitos y transformacin AGG), se ejecuta la transformacin y se obtiene automticamente un nuevo grafo que describe el modelo de navegacin del sistema web, incluyendo las trazas generadas. Almacenamiento. Los autores proponen que, en primer lugar, las trazas sean almacenadas en los modelos de navegacin. Posteriormente, mediante el uso de la herramienta TaskTracer, cada una de las trazas encontradas en el modelo

Estado del Arte 117

navegacional son almacenadas en un repositorio de trazas que es definido de acuerdo a un metamodelo de trazabilidad. Metamodelo de trazabilidad. En este trabajo, los autores presentan un metamodelo de trazabilidad genrico basado en los metamodelos propuestos por Jouault [103] y Kolovos et al. [117]. Dicho metamodelo, que es empleado para describir el repositorio de trazas, permite establecer relaciones entre los elementos del modelo de navegacin y los elementos del modelo de requisitos. Visualizacin. En este trabajo, los autores no especifican ninguna forma particular de visualizar la informacin de trazabilidad obtenida. En este sentido, solo consideran que el modelo de navegacin que incluye las trazas se representa en forma de grafo y que a partir de dichas trazas se pueden generar informes en formato HTML. Anlisis de las trazas. TaskTracer, el prototipo que se presenta en este trabajo es construido con el objetivo de generar informes de trazabilidad para facilitar el estudio acerca de cmo los requisitos del sistema son soportados por los modelos de navegacin. Segn los autores, este tipo de informes permiten: validar la completitud y la correccin de las transformaciones, es decir si se han tenido en cuenta todos los requisitos y se ha hecho de forma correcta; y establecer el impacto de los cambios en los requisitos. Soporte tecnolgico. Las transformaciones que proponen en esta propuesta son implementadas con la herramienta AGG, por lo que se basa en una herramienta ya existente. Por otro lado, los autores presentan TaskTracer, un prototipo que permite analizar modelos de navegacin en formato AGG para identificar las trazas, almacenarlas en un repositorio y posteriormente, generar informes de trazabilidad en formato HTML

3.3.5

Discusin

Una vez que se han analizado todas las propuestas identificadas en la literatura, en esta seccin se procede a asignar un valor a cada propuesta para los criterios de evaluacin propuestos en la seccin 3.3.2; y a continuacin, analizar los valores obtenidos, para dar respuesta a las cuestiones de investigacin propuestas en la seccin 3.3.1. En la Tabla 3-2 se presentan los valores asignados a cada propuesta para cada uno de los criterios de evaluacin. Se recuerda que la puntuacin de cada valor es: (S)=1; (P)arcial=0.5; y (N)o=0. Por tanto, dado que se han definido siete criterios de evaluacin (CE), cada una de las propuestas puede obtener como

118

lvaro Jimnez Rielo

mximo 7 puntos. La penltima columna de la tabla (Total) muestra la puntuacin obtenida por cada una de las propuestas y la ltima columna (% mximo posible) indica el porcentaje de puntos que ha obtenido cada propuesta respecto de 7, es decir del total de puntos posibles.
Tabla 3-2. Resumen de los Criterios de Evaluacin en cada propuesta
Generacin de Trazas (Automticas) Almacenamiento de las Trazas Visualizacin de las Trazas Independiente del lenguaje de transformacin

Relaciones de Trazabilidad (Automticas)

Herramienta de Soporte

Anlisis de Trazabilidad

Propuesta Bond et al. Boronat et al. Grammel y Kastenholz Guerra et al. Jouault et al. Kolovos et al. Levendovszky et al. Oldevik et al. Snchez et al. Valderas y Pelechano

CE-1 S S S N S N P S N N

CE-2 S S S S S N S S S S

CE-3 N S S S N S N N N N

CE-4 S S S P S S P S S S

CE-5 P S N P P N P S N N

CE-6 N N N N N S N S S S

CE-7 N S N P S N P P P P

T o tal 3 ,5 0 6 ,0 0 4 ,0 0 3 ,5 0 4 ,5 0 3 ,0 0 3 ,0 0 5 ,5 0 3 ,5 0 3 ,5 0

% m xim o po s ible 5 0 ,0 0 % 8 5 ,7 1% 5 7 ,14 % 5 0 ,0 0 % 6 4 ,2 9 % 4 2 ,8 6 % 4 2 ,8 6 % 7 8 ,5 7 % 5 0 ,0 0 % 5 0 ,0 0 %

T o tal C E % m a xim o po s ible C E

5 ,5 0 5 5 ,0 0 %

9 ,0 0 9 0 ,0 0 %

4 ,0 0 4 0 ,0 0 %

9 ,0 0 9 0 ,0 0 %

4 ,0 0 4 0 ,0 0 %

4 ,0 0 4 0 ,0 0 %

4 ,5 0 4 5 ,0 0 %

4 0 ,0 0 5 7 ,14 %

Como se puede comprobar en la Tabla 3-2, todas las propuestas han obtenido puntos. De hecho, el 80% de las propuestas han obtenido una puntuacin igual o superior a 3.5 puntos (50% de los puntos posibles), aunque ninguna de ellas ha alcanzado la puntacin mxima posible (7 puntos). En las ltimas dos filas de la tabla (Total CE y % mximo posible CE) se presenta la puntuacin alcanzada para cada uno de los criterios de evaluacin, sumando los puntos asignados a cada propuesta para dicho criterio; y el porcentaje de puntos que supone respecto del total de puntos posibles. Se recuerda que se han analizado 10 propuestas y que el mximo valor que puede recibir por cada CE es 1, por tanto la puntuacin mxima que puede alcanzar cada CE son 10 puntos. En este caso se puede observar que mientras dos CE se acercan al mximo posible

Estado del Arte 119

(CE-2 y CE-4), cuatro CE no alcanzan el 50% de los puntos posibles (CE-3, CE-5, CE-6, y CE-7). En consecuencia, se puede afirmar que las propuestas analizadas cumplen en parte con los objetivos planteados en esta revisin de la literatura, aunque ninguna los satisface al 100%. As mismo, se observa que los criterios de evaluacin definidos tampoco son cubiertos por completo. Por todo ello, se deduce que es posible encontrar puntos de mejora en el estado del arte actual sobre la gestin de la trazabilidad a partir de transformaciones de modelos. A continuacin, se utilizan los valores asignados a cada propuesta para dar respuesta a cada una de las cuestiones de investigacin (CI) planteadas en la seccin 3.3.1: CI-1. Qu nivel de automatizacin ofrecen o sugieren las propuestas metodolgicas para generar informacin de trazabilidad?

En el contexto de esta tesis resulta interesante conocer cmo se pueden aprovechar tcnicas propias de MDE para la gestin de la trazabilidad. As, dado que uno de estos principios es incrementar el nivel de automatizacin [14], esta CI se centra en analizar cmo y hasta que punto se automatiza la generacin de trazas. En este sentido, probablemente la mejor forma de automatizar la generacin de las trazas sea obtenerlas de forma automtica a partir de relaciones de trazabilidad, identificadas a nivel de metamodelo. Adems, idealmente, tambin sera deseable automatizar la identificacin de las relaciones de trazabilidad por ejemplo, a partir de transformaciones. As, el anlisis de los resultados obtenidos en los criterios de evaluacin CE-1 (automatizacin de la identificacin de relaciones de trazabilidad) y CE-2 (automatizacin de la generacin de trazas) permite conocer qu formas de automatizacin sugieren las propuestas analizadas para la gestin de las trazas a partir del desarrollo de transformaciones de modelos. Dichos criterios han obtenido 5.5 (55% de la mxima puntuacin posible) y 9 puntos (90%), respectivamente, lo que sugiere que automatizar la generacin de trazas es una tarea ampliamente abordada, pero la identificacin automtica de relaciones de trazabilidad an es poco afrontada por los trabajos existentes. De las propuestas estudiadas, tan solo una de ellas (Kolovos et al.) no considera ninguno de los dos tipos de automatizacin mencionados, aunque conviene sealar que dicha propuesta se centra en otros aspectos como el almacenamiento de trazas. Las nueve propuestas restantes s proponen tcnicas para automatizar al menos una de las dos tareas. Concretamente, las nueve ofrecen

120

lvaro Jimnez Rielo

mecanismos para generar automticamente las trazas, pero solo cinco de ellas (Bond et al., Boronat et al., Grammel y Kastenholz, Jouault et al. y Oldevik et al.), adems proponen tcnicas para identificar automticamente las relaciones de trazabilidad. Un caso particular es la propuesta de Levendovzsky et al. que considera recomendable automatizar la identificacin de las relaciones de trazabilidad, pero no indica cmo hacerlo. Por todo ello, a priori parece ms sencillo automatizar la generacin de las trazas que automatizar la identificacin de las relaciones de trazabilidad. En particular, 7 de las 9 propuestas que soportan la generacin automtica de trazas, lo hacen a partir de la ejecucin de transformaciones. Solo las propuestas de Boronat et al. y Guerra et al. emplean otros mtodos basados en tareas de gestin de modelos. En cuanto a la independencia de las propuestas respecto de los lenguajes de transformacin, observando los datos obtenidos para CE-3 se comprueba que 6 de las 10 propuestas analizadas (60%) estn definidas para un lenguaje o motor de transformacin concreto. Trasladar estas propuestas a escenarios donde se usen otros lenguajes o motores de transformacin puede resultar una tarea demasiado compleja, e incluso imposible en algunos casos. Por tanto, sera deseable disponer de mtodos o tcnicas que aliviasen este problema. De las otras 4 propuestas (el 40% restante), la presentada por Kolovos et al. no sugiere mtodos para automatizar esta tarea; las de Boronat et al. y Guerra et al. son justamente aquellas que no proponen utilizar transformaciones para generar las trazas; y finalmente la propuesta de Grammel y Kastenholz es la nica que presenta un mtodo para la generacin de trazas a partir de la ejecucin de transformaciones que puede emplearse para distintos lenguajes de transformacin. En cuanto a cmo se automatiza la identificacin de las relaciones de trazabilidad a nivel de metamodelo, solo el 50% de las propuestas analizadas abordan esta actividad, el resto propone que el usuario identifique las relaciones de forma manual. Para automatizar la identificacin de las relaciones de trazabilidad, los trabajos de Bond et al. y los de Oldevik et al. proponen aprovechar la gestin implcita de la trazabilidad que proporcionan algunos motores de transformacin; Boronat et al. proponen definir operadores algebraicos para realizar operaciones entre modelos y obtener las relaciones de trazabilidad a partir de esa informacin; y, Grammel y Kastenholz presentan un mtodo basado en una interfaz que extiende los motores de transformacin de los que extrae las relaciones de trazabilidad independientemente de cmo las gestionen (implcita o explcita). Por su parte, Jouault presenta una propuesta hbrida: defiende que los desarrolladores

Estado del Arte 121

incluyan las relaciones de trazabilidad en las reglas de la transformacin, pero al mismo tiempo presenta una transformacin que automatiza esta tarea. Como conclusin, para automatizar la generacin de informacin de trazabilidad sera deseable automatizar por un lado, la identificacin de las relaciones de trazabilidad a nivel de metamodelo y por otro, automatizar la generacin de trazas a partir de las relaciones anteriores. En este sentido, la generacin automtica de trazas es una tarea ms madura y la mayora de las propuestas coinciden en el uso de transformaciones. Sin embargo, la mayora de estas aproximaciones son dependientes de un lenguaje o motor de transformacin concreto. En cuanto a la identificacin automtica de las relaciones de trazabilidad, resulta una tarea mucho ms inmadura y no existe an un consenso en cuanto a cmo se debera abordar. CI-2. Segn las propuestas metodolgicas identificadas, cmo se deberan almacenar, visualizar y analizar las trazas generadas?

Mientras la pregunta anterior ha dado respuesta a cmo se genera la informacin de trazabilidad, en esta cuestin se estudia cmo se trata una vez obtenida. Para dar respuesta a esta cuestin de investigacin, los criterios CE-4, CE-5 y CE-6 evalan cmo las distintas propuestas abordan el almacenamiento, visualizacin y anlisis de las trazas. En cuanto al almacenamiento de las trazas, de la observacin del estado del arte se puede afirmar que es un aspecto bastante maduro ya que alcanza un 90% de la puntuacin total (9 puntos de 10 posibles). Las diferentes propuestas coinciden en la definicin de modelos de trazas ad-hoc como forma de almacenar las trazas. Aunque este es el escenario esperado en el contexto de MDE, ya que potencia el uso de los modelos, plantea un problema de interoperabilidad debido a la existencia de diferentes metamodelos de trazabilidad. No obstante, dado que en general dichos metamodelos no distan mucho estructuralmente (la mayora definen netaclases para soportar el modelado de los enlaces de traza y los elementos trazados), probablemente la solucin ms inmediata para este problema de interoperabilidad sera definir transformaciones entre dichos metamodelos. A pesar de no ser una cuestin menor, la visualizacin de las trazas ha obtenido una de las puntuaciones ms bajas de los criterios evaluados (4 sobre 10). De hecho, el 60% de las propuestas analizadas incluye alguna aportacin en este sentido, aunque la mayora propone visualizaciones genricas para representar las trazas obtenidas (calificadas con valor P en la Tabla 3-2), tan solo las propuestas de Boronat et al. y Oldevik et al. proponen tcnicas especficas para representar este tipo de informacin. Mientras los primeros proponen un editor basado en el

122

lvaro Jimnez Rielo

de la herramienta AMW, que permite visualizar al mismo tiempo varios modelos y las trazas entre ellos; la visualizacin propuesta por Oldevik et al. es un editor grfico de tipo diagramador. Entre las propuestas que sugieren representaciones genricas, cabe destacar que varias coinciden a la hora de proponer representaciones basadas en editores que permiten visualizar al mismo tiempo varios modelos y un modelo que muestra las relaciones entre los elementos de dichos modelos. Ejemplos de estas representaciones son los que soportan las herramientas AMW, ModeLink o el editor propuesto por Boronat et al. en [35]. Por ltimo, otro de los criterios que han obtenido peor puntuacin (4 puntos sobre 10 posibles) es el anlisis de la informacin de trazabilidad. De las diez propuestas analizadas solo cuatro incluyen tcnicas para el anlisis de las trazas generadas. Por tanto, es un tema que actualmente se encuentra bastante inmaduro. En cuanto a las propuestas a las que se les ha asignado un S para este criterio, los trabajos de Snchez et al. y los trabajos de Valderas y Pelechano coinciden en proponer la generacin de informes de trazabilidad en formato HTML. Por su parte, la propuesta de Oldevik et al. presenta un prototipo que soporta un conjunto de anlisis bien identificados, como el anlisis del impacto del cambio, el anlisis de cobertura y el anlisis de hurfanos. Por ltimo, la propuesta presentada por Kolovos et al. ofrece una gua para clasificar los tipos de enlaces de traza que se generan a lo largo de un proceso MDE. A la vista de los datos obtenidos, se puede afirmar que el almacenamiento de las trazas es un tema ampliamente abordado por la mayor parte de los autores, que coinciden en el uso de modelos de trazas creados ad-hoc. En cambio, la visualizacin y el anlisis de dichas trazas son tareas actualmente poco abordadas y por tanto, inmaduras en el contexto de este estado del arte. CI-3. Existen herramientas o marcos de trabajo que ofrezcan soporte tecnolgico para la gestin de la trazabilidad en el contexto del desarrollo de transformaciones de modelos?

Como ya se ha comentado en varias ocasiones a lo largo de esta tesis doctoral, MDE ofrece un nuevo escenario que permite mejorar la gestin de la trazabilidad en el desarrollo de software. No obstante, cabe la posibilidad de que estas mejoras se hayan planteado desde un punto de vista meramente terico. As, la respuesta a este CI permitir despejar esta incgnita y comprobar si el tradicional gap que existe entre las ideas y la implementacin de las mismas [136, 148, 167] se pone de manifiesto una vez ms. A priori, con los datos que proporciona la Tabla 3-2 parece cumplirse de nuevo ya que el CE-7, que evala si

Estado del Arte 123

las propuestas metodolgicas son llevadas a la prctica por medio de una herramienta, ha obtenido un 45% de la puntuacin mxima que podra obtener. Sin embargo, esta baja puntuacin no se debe a que sea un tema poco abordado sino a que en la mayora de los casos, la implementacin que se proporciona es parcial y no constituye una herramienta completa. En realidad, 7 de las 10 propuestas analizadas realiza alguna aportacin en cuanto a la implementacin de la propuesta, pero solo 2 de ellas (Boronat et al. y Jouault et al.) proporcionan una herramienta que de soporte completo a la propuesta metodolgica. Esto puede deberse a que algunos autores se centran en implementar aquellas partes de su propuesta que resultan ms novedosas, mientras que para poner en prctica el resto de la propuesta emplean herramientas ya existentes. Por tanto, se puede afirmar que existen conjuntos de herramientas que combinadas adecuadamente ofrecen soporte para la gestin de la trazabilidad en el mbito del desarrollo de transformaciones de modelos, pero que existen pocas implementaciones que, por si solas, constituyan una propuesta completa. En cuanto a cmo se han construido estas herramientas, cabe destacar que la mayora han sido construidas sobre Eclipse y en particular, utilizando las tecnologas proporcionadas en el contexto del proyecto EMP (Eclipse Modeling Project, http://eclipse.org/modeling). CI-4. Cules son las limitaciones encontradas en las propuestas para la gestin de informacin de trazabilidad a partir de transformaciones de modelos?

Dando respuesta a las cuestiones anteriores, se han identificado algunas limitaciones o puntos de mejora en el estado del arte actual en cuanto a la gestin de la trazabilidad a partir del desarrollo de transformaciones de modelos. En primer lugar, en la discusin de la CI-1, se han identificado dos limitaciones o puntos de mejora: la automatizacin de la identificacin de relaciones de trazabilidad a nivel de metamodelo es una tarea an inmadura y adems la generacin de trazas a partir de la ejecucin de transformaciones suele ser muy dependiente del motor que ejecute dichas transformaciones. Esta dependencia imposibilita aplicar una misma propuesta a varios lenguajes de transformacin y/o utilizarla para soportar nuevos lenguajes o aproximaciones. Sera deseable disponer de una propuesta para la generacin de informacin de trazabilidad a partir de la ejecucin de transformaciones que fuera independiente del motor de transformacin utilizado. De esta forma, se podra utilizar dicha propuesta por ejemplo para cualquier nuevo lenguaje de transformacin. En este sentido conviene recordar que en los ltimos aos se ha producido un flujo

124

lvaro Jimnez Rielo

continuo de nuevas herramientas y lenguajes para e desarrollo de transformaciones [49, 188]. Adems, dado que las transformaciones son un artefacto ms del sistema y que cada vez resultan ms complejas de desarrollar (ms todava si adems deben incluir el cdgo necesario para generar las trazas entre los elementos de los modelos implicados en la transformacin), sera deseable aplicar las tcnicas de MDE a su construccin. Es decir, seguir un proceso dirigido por modelos para el desarrollo de transformaciones de modelos. Esta aproximacin pasara por especificar la transformacin a alto nivel, es decir, independientemente del lenguaje con el que finalmente se implemente. Si este nivel de abstraccin de esta especificacin es lo suficientemente alto, limitndose a definir las relaciones que deberan satisfacerse a nivel de metamodelo, ser posible utilizar dicha especificacin para identificar las relaciones de trazabilidad que se daban controlar entre los elementos implicados en la transformacin. Por otro lado, la CI-2 analiza cmo se gestiona la informacin de trazabilidad una vez que ha sido generada, en particular cmo se aborda el almacenamiento, visualizacin y anlisis de las trazas generadas. En cuanto al almacenamiento, se ha detectado que la mayor parte de los autores coinciden en el empleo de modelos de trazas como la forma de almacenamiento ms adecuada. Como consecuencia, existe un gran nmero de metamodelos de trazabilidad, lo que implica un problema de interoperabilidad. No obstante, estos metamodelos contienen bastantes similitudes por lo que sera posible definir transformaciones que minimizasen el problema. Respecto a la visualizacin, algunos de los marcos de metamodelado ms empleadas actualmente, como EMF, proporcionan editores y visualizadores genricos que permiten visualizar cualquier modelo conforme a un metamodelo previamente definido. Por ello, muchas de las propuestas analizadas han optado por utilizar este tipo de visualizadores genricos y no proporcionan mtodos especficos para visualizar o representar los modelos de trazas. Desafortunadamente, el carcter genrico de estos editores no se ajusta a la naturaleza de los modelos de trazas. Por ejemplo, se limitan a mostrar los objetos del modelo de trazas y no soportan la navegacin hasta los elementos trazados, ubicados en su correspondiente modelo. En este sentido, algunas de las propuestas analizadas coinciden a la hora de identificar la necesidad de disponer de editores que permitan visualizar al mismo tiempo el modelo de trazas y los modelos trazados, e incluso soportar la interaccin entre ellos, como los que proporcionan las herramientas AMW y ModeLink.

Estado del Arte 125

El ltimo de los puntos que se discute en la CI-2 ha identificado una limitacin relacionada con el anlisis de las trazas generadas: aunque existen evidencias acerca de la importancia de analizar la informacin de trazabilidad para llevar a cabo otras actividades software [9, 147, 152, 183, 200], de entre las propuestas analizadas solo un 40% incluyen tcnicas o mtodos para facilitar el anlisis de la informacin de trazabilidad. Por ltimo, respondiendo a la CI-3 sobre la existencia de implementaciones que den soporte a las propuestas metodolgicas, se ha detectado que, a pesar de que existen marcos como Eclipse y el proyecto EMP, que facilitan el desarrollo de herramientas para dar soporte a propuestas relacionadas con MDE, la mayora de las propuestas analizadas solo incluyen implementaciones parciales. Esta limitacin obliga a recurrir a un conjunto de implementaciones parciales para poner en prctica la gestin de las trazas. Aunque a priori la necesidad de integrar varias implementaciones parciales puediera parecer poco relevante, es probable que en algn momento aparezcan incompatibilidades entre dichas implementaciones o que alguna de ellas sea abandonada por sus desarrolladores. Por ello, sera recomendable disponer de herramientas completas que ofrezcan soporte a toda la propuesta metodolgica [29, 86].

Propuesta Metodolgica

4. Propuesta Metodolgica
Una de las principales conclusiones extradas del estado del arte presentado en el captulo anterior es la ausencia de propuestas que combinen el desarrollo dirigido por modelos de transformaciones de modelos y la gestin de las trazas a partir de dichas transformaciones. Tal como se describe en el Captulo 1, para abordar esta limitacin del estado del arte, esta tesis doctoral tiene por objetivo proporcionar un entorno para el desarrollo dirigido por modelos de transformaciones de modelos que incluyan la generacin (semi-)automtica de modelos de trazas. Este entorno, denominado MeTAGeM-Trace, engloba una propuesta metodolgica que se presenta en este captulo y el correspondiente soporte tecnolgico que se presenta en el Captulo 5. La propuesta metodolgica se compone principalmente de: Un proceso de desarrollo dirigido por modelos de transformaciones de modelos. Un conjunto de metamodelos que permiten modelar transformaciones y relaciones de trazabilidad a distintos niveles de abstraccin. Reglas de transformacin que, partiendo de un modelo que describe la transformacin a un nivel de abstraccin concreto, permiten obtener (semi-)automticamente un modelo que la describa a un nivel de abstraccin menor. Reglas de transformacin que permiten (semi-)automatizar la serializacin de los modelos que describen la transformacin a bajo nivel en el cdigo que las implementa. Reglas de validacin para asegurar la correccin sintctica y semntica de los distintos modelos de transformacin. Un metamodelo de trazabilidad de carcter general que permite modelar las trazas que se derivan de la ejecucin de una transformacin de modelos generada con el proceso de desarrollo propuesto.

Como ya se ha mencionado en varias ocasiones a lo largo de esta tesis, el nuevo escenario que surge con la llegada de MDE ofrece una serie de ventajas. En particular, centrando la atencin en el Desarrollo de Software Dirigido por Modelos (DSDM), el sistema es especificado con uno o varios modelos de alto nivel que son refinados mediante la ejecucin de transformaciones hasta que se obtiene un modelo ejecutable o el cdigo que implementa el sistema [14, 78, 185, 188]. Generalmente, dichas transformaciones se componen de reglas que contienen informacin del tipo a partir del elemento X, se genera el elemento Y. Es posible utilizar esta informacin para abordar la automatizacin de otras tareas

130

lvaro Jimnez Rielo

relacionadas con el desarrollo del software, como la gestin de la trazabilidad, considerada tradicionalmente una tarea costosa y propensa a errores cuando se lleva a cabo manualmente [61, 66, 92, 138, 152, 228]. Por tanto, sera conveniente automatizarla, reduciendo el esfuerzo que supone generar y mantener las trazas. Para ello, dado que en cualquier proceso de DSDM se construyen y ejecutan transformaciones de modelos, una forma de abordar la automatizacin de la gestin de la trazabilidad es incluirla en las propias transformaciones. Sin embargo, esto complicara la codificacin de dichas transformaciones, ya que, adems de soportar la generacin de los correspondientes elementos destino, debera soportar la generacin de las trazas. No obstante, dado que las transformaciones son otro artefacto software ms, una forma de reducir esta complejidad pasa por aplicar los principios de MDE a su desarrollo. En trabajos anteriores, en el contexto de esta tesis doctoral el Grupo de Investigacin Kybele present MeTAGeM [31, 99], una primera aproximacin para soportar el desarrollo dirigido por modelos de transformaciones de modelos. A partir de la experiencia adquirida en el desarrollo de MeTAGeM y la identificacin del cuerpo del conocimiento presentado en el captulo anterior, en esta tesis doctoral se propone incorporar un meta-generador de trazabilidad en un entorno para el desarrollo dirigido por modelos de transformaciones de modelos. El objetivo es que las transformaciones generadas incorporen las construcciones que permitan generar, adems de los correspondientes modelos destino, los modelos de trazas que relacionan los modelos implicados en la transformacin. Ntese que se utiliza el trmino meta-generador para constatar que no se acta sobre la transformacin para incorporar en ella los mecanismos necesarios para la generacin de trazas. Al contrario, se acta sobre el entorno de desarrollo de transformaciones de manera que el desarrollador slo tenga que utilizar el entorno para modelar la transformacin y la incorporacin de los mecanismos de generacin de trazas sea transparente. Por todo ello, MeTAGeM-Trace, el entorno que se presenta en esta tesis doctoral, se centra en mejorar, ampliar y evolucionar MeTAGeM, de acuerdo al planteamiento presentado. En las siguientes secciones se presentan cada uno de los componentes de la propuesta metodolgica que se presenta en esta tesis, mientras que la implementacin de dichos componentes se presenta en el Captulo 5.

Propuesta Metodolgica 131

4.1

Un Proceso de Desarrollo de Transformaciones que soportan la Generacin de Trazas

MeTAGeM propona el modelado de transformaciones a diferentes niveles de abstraccin, de acuerdo a la propuesta de MDA [157], e incluyendo el nivel PDM, muchas veces omitido. El proceso de desarrollo de MeTAGeM-Trace, que se ilustra en la Figura 4-1, tambin considera el modelado de transformaciones en los niveles PIM, PSM, PDM y Cdigo, pero incorporando (automticamente) en los modelos de los niveles intermedios, las construcciones necesarias para soportar la gestin de la trazabilidad. As, el proceso propuesto es una adaptacin del presentado en [31] para el desarrollo dirigido por modelos de transformaciones de modelos.

Nivel PIM

Relaciones de Transformacin
Transformacin PIM a PSM

Nivel PSM Reglas de Transf ormacin

Relaciones de Trazabilidad
Transformacin PSM a PDM

Nivel PDM Transf . dependiente de lenguaje

Generador de Trazas
Generacin de Cdigo

Cdigo Cdigo de la Transf ormacin

Generador de Trazas

Modelos Destino

Source

Modelos Origen

Modelo Trazas (Origen-Destino)

Figura 4-1. Generacin de Modelos de Trazas a partir del DDM de Transformaciones de Modelos

132

lvaro Jimnez Rielo

A nivel PIM, se especifican las relaciones entre los elementos de uno o varios metamodelos origen y los elementos de uno o varios metamodelos destino, sin tener en cuenta la plataforma final en la que se implementar la transformacin. A partir del modelo PIM se obtiene un modelo PSM que especifica las reglas de la transformacin de acuerdo al paradigma de transformacin seleccionado (imperativo, declarativo, hbrido, basado en grafos, etc.). Este modelo, adems, incluye un conjunto de objetos que explicitan las relaciones de trazabilidad que estaban implcitas en el modelo PIM de la transformacin. El siguiente paso consiste en la generacin de un modelo PDM que describe la transformacin y contiene las construcciones necesarias para la generacin de las trazas para un lenguaje de transformacin concreto. Dicho modelo es conforme al metamodelo del lenguaje con el que quiere implementar la transformacin. Por tanto, dicho modelo es consumido por una transformacin modelo a texto que genera el cdigo que implementa la transformacin. La ejecucin de esta transformacin produce no slo los modelos destino correspondientes, sino tambin el modelo de trazas que explicita las relaciones de trazabilidad definidas implcitamente a nivel PIM. Para soportar las diferentes actividades de modelado y como herencia directa de la propuesta MeTAGeM, MeTAGeM-Trace define un conjunto de metamodelos que permiten modelar las transformaciones y las relaciones de trazabilidad a diferentes niveles de abstraccin. Dichos metamodelos se han definido conforme a MOF [158], con el objetivo de facilitar la interoperabilidad con otras herramientas MDE basadas en MOF. As, cualquiera de los modelos elaborados o generados con MeTAGeM-Trace podr ser utilizado y/o gestionado desde cualquier otra herramienta basada en MOF, sin ms que desarrollar una transformacin que permita conectar los metamodelos de ambas herramientas. Adems, el hecho de modelar las transformaciones (e implcitamente las relaciones de trazabilidad) proporciona una serie de ventajas adicionales: en tanto que las transformaciones y las relaciones de trazabilidad sean un modelo ms, podremos generarlas, transformarlas, validarlas, compararlas, refactorizarlas, etc. utilizando tcnicas MDE [21]. Finalmente, para proporcionar una representacin estndar del proceso de desarrollo propuesto, la Figura 4-2 lo describe mediante un diagrama de actividad SPEM [156].

Propuesta Metodolgica 133

Figura 4-2. Diagrama SPEM del Proceso de Desarrollo soportado por MeTAGeM-Trace

Ntese que, como muestra la Figura 4-2, todos los modelos generados con MeTAGeM-Trace pueden ser refinados de forma manual por el usuario. Obviamente, el cdigo generado tambin puede ser refinado y ejecutado usando el IDE proporcionado por el lenguaje de transformacin de modelos escogido como plataforma destino.

134

lvaro Jimnez Rielo

4.2

Especificacin de Metamodelos

Para soportar el modelado de transformaciones de modelos a diferentes niveles de abstraccin, MeTAGeM define un conjunto de metamodelos que se corresponden con cada uno de los niveles de abstraccin propuestos [31]. Como evolucin de dicho entorno, MeTAGeM-Trace define nuevas versiones de estos metamodelos, adaptndolos a las necesidades de la gestin de la trazabilidad. En esta seccin se presenta la arquitectura de modelado, que es ilustrada en la Figura 4-3, as como cada uno de los metamodelos que la componen. En primer lugar, a nivel PIM, se define un metamodelo que permite modelar las relaciones de transformacin a alto nivel. Concretamente, estos modelos contendrn las relaciones existentes entre los elementos de uno o varios metamodelos origen y uno o varios metamodelos destino. A nivel PSM, se encuentran los metamodelos que se corresponden con cada una de las diferentes aproximaciones para el desarrollo de transformacin de modelos. Dichos metamodelos debern contener los constructores necesarios para permitir el modelado de las relaciones de trazabilidad. En particular, en esta tesis doctoral se define el metamodelo correspondiente a la aproximacin hbrida. En el nivel PDM se definen los metamodelos que permiten modelar la transformacin para una plataforma concreta, es decir para un lenguaje de transformacin en particular. En esta tesis doctoral, dado que a nivel PSM se ha propuesto seguir la aproximacin hbrida, a nivel PDM se consideran los metamodelos de dos lenguajes de transformacin que siguen la aproximacin hbrida: ATL [107] y ETL [118]. El primero es proporcionado por la herramienta que da soporte al lenguaje ATL y el metamodelo de ETL ha sido especificado e implementado en el desarrollo de esta tesis doctoral Estos metamodelos no incluyen constructores especficos para el modelado de relaciones de trazabilidad. Por ello, este tipo de informacin se debe definir en trminos de estructuras definidas por el lenguaje de transformacin que se quiera emplear por ejemplo, mediante constructores que representen reglas de transformacin o elementos de dichas reglas.

Propuesta Metodolgica 135

PIM

Metamodelo-Entrada Metamodelos-Origen

Metamodelo MeTAGeM

Metamodelo-Entrada Metamodelos-Destino

Modelo MeTAGeM

PSM

Metamodelo Aproximacin Declarativa

Metamodelo Aproximacin Hbrida

Metamodelo Aproximacin

Modelo de Transformacin Aproximacin Declarativa + Relaciones de Trazabilidad

Modelo de Transformacin Aproximacin Hbrida + Relaciones de Trazabilidad

Modelo de Transformacin Aproximacin + Relaciones de Trazabilidad

MM ATL

MM ETL

PDM

MM N

MM ATL Modelo-Transformacin ATL

Modelo-Transformacin ETL

Modelo-Transformacin

CDIGO

Cdigo Reglas ATL + Generador de Trazas

Cdigo Reglas ETL + Generador de Trazas

Cdigo Reglas + Generador de Trazas

Conforme a

Usa

Figura 4-3. Jerarqua de modelado de MeTAGeM-Trace

Finalmente, en el nivel ms bajo de la arquitectura, se encuentra el cdigo de la transformacin que serializa los modelos PDM. La ejecucin de dicho cdigo generar uno o varios modelos de salida conformes a los metamodelos destino y un modelo que contenga las trazas derivadas de la ejecucin de la transformacin. En las siguientes secciones se describen cada uno de los metamodelos mencionados. Antes de presentar los metamodelos para el modelado de las transformaciones, se presenta el metamodelo de trazabilidad que define cmo deben ser los modelos de trazas, creados por el generador de trazas que est embebido en las transformaciones modeladas.

4.2.1

Metamodelo de Trazabilidad

Dado que el objetivo del meta-generador de trazabilidad es incluir, en la transformacin, la informacin necesaria para construir modelos de trazas, es

136

lvaro Jimnez Rielo

necesario definir un metamodelo de trazabilidad que defina la sintaxis abstracta de los modelos de trazas. Del anlisis de las propuestas para la gestin de la trazabilidad (seccin 3.3), se ha concluido que la mayor parte coinciden en el uso de metamodelos genricos que permitan modelar las trazas para cualquier dominio de aplicacin. Esta necesidad tambin se pone de manifiesto en MeTAGeM-Trace, ya que el entorno que se propone es independiente de los metamodelos origen y destino de las transformaciones que se modelan y en consecuencia, es imposible conocer cmo sern las trazas derivadas de la ejecucin de dichas transformaciones. Por esta razn, se propone un metamodelo de trazabilidad genrico, que es vlido para cualquier escenario de trazabilidad. Para especificar dicho metamodelo, en el proceso de estudio del estado del arte presentado en el Captulo 3, se han analizado diversos metamodelos de trazabilidad [36, 103, 117, 134, 143, 181, 224]. As, a partir del anlisis de dichos metamodelos y mediante un proceso iterativo, se ha definido el metamodelo de trazabilidad que se muestra en la Figura 4-4. El elemento principal del metamodelo es la metaclase TraceModel que representa al modelo de trazas. Los elementos TraceModel se componen de uno o varios modelos origen (SourceModel), uno o varios modelos destino (TargetModel) y un conjunto de trazas (TraceLink). Dichas trazas pueden contener elementos origen, elementos destino y otras trazas de menor entidad (para representar las trazas entre los atributos de los elementos). Adems, cada una de las trazas podr ser consecuencia de una operacin de transformacin, creacin o borrado (Operations). Ntese que del mismo modo que se registra esta informacin, podran almacenarse otros datos como la fecha de creacin, el usuario que ha ejecutado la transformacin, la ubicacin, etc., que podran ser tiles de cara a realizar otras actividades software como por ejemplo la gestin de la configuracin.

Propuesta Metodolgica 137

1 TraceModel
targetModels

Operations -Transform -Create -Delete 0..1

traceLinks

1 1..*
sourceModels

1..*

TargetModel

SourceModel

parentLink

1..* TraceLink Element -name : string

0..1

-operation : Operations

0..*
childLinks

Model -path : string -metamodel : string

model

0..*

1
source

SourceElement 1

0..*

TraceElement -ref : string 0..* TargetElement

belongsTo target

0..1

Figura 4-4. Metamodelo de Trazabilidad de MeTAGeM-Trace

138

lvaro Jimnez Rielo

4.2.2

Metamodelo MeTAGeM (nivel PIM)

Este metamodelo fue propuesto en [31] con el objetivo de soportar el modelado de las transformaciones de forma independiente al lenguaje de transformacin que implementa finalmente la transformacin y suficientemente genrico como para poder emplearse en cualquier tipo de transformacin de modelos y en cualquier dominio de aplicacin. Para alcanzar esta genericidad e independencia, este metamodelo permite definir las relaciones existentes entre los elementos de los metamodelos origen y destino de una transformacin, pudiendo indicar el tipo de relacin. El tipo de relacin se establece de acuerdo a varias caractersticas: el rol de la relacin en la transformacin (principal, secundaria o abstracta), su cardinalidad (uno-a-uno, uno-a-cero, uno-a-muchos, cero-a-uno, muchos-a-uno o muchos-a-muchos) y su comportamiento (copia, concatenacin u otros). Conviene mencionar que, debido a la genericidad y a alto nivel de abstraccin del metamodelo definido en [31], la incorporacin del meta-generador de trazabilidad en el entorno de desarrollo dirigido por modelos de transformaciones no requiere llevar a cabo grandes cambios en este metamodelo. As, el metamodelo a nivel PIM de MeTAGeM-Trace solo incluye cambios de nomenclatura (por ejemplo, la metaclase NtoN ha pasado a denominarse ManyToMany), redefinicin de los tipos enumerados y la incorporacin nuevas metaclases abstractas (TransformationElement y RelationElement) con el objetivo de mejorar dicho metamodelo. En la Figura 4-5 se muestra el metamodelo MeTAGeM resultante.

Propuesta Metodolgica 139

TRole -IsMain -IsSecondary -IsAbstract TRelation -Copy -Concatenation -Other TElement -EClassifier -EAttribute -EReference ModelRoot -name : string 1..* 1 1
isExtend targetModels sourceModels

SourceModelTransf ModelTransf -path : string

TargetModelTransf 1

0..*

1 1..*

relations

1..*

Relations 0..1
Extends isInvoked

-typeRelation : TRelation -typeElement : TElement -role : TRole -guardCondition : string

TransformationElement -name : string

model

OneToOne

OneToZero

ZeroToOne

OneToMany

ManyToOne

ManyToMany

zeroToOne

1
oneToOne

1 1 0..*
source

0..*

0..*
manyToOne

1
source

SourceElement
source

1 1..* 1..*

target

target

1..*

target

1 TargetElement 1..* 1 1 1
target

source source invokes

target

0..1

RelationElement -ref : string 1

Figura 4-5. Metamodelo MeTAGeM (nivel PIM)

140

lvaro Jimnez Rielo

4.2.3

Metamodelo Especfico de Plataforma (nivel PSM)

La propuesta que se presenta en esta tesis doctoral pasa por incluir mecanismos para la gestin de la trazabilidad en un entorno de desarrollo dirigido por modelos de transformaciones de modelos. Para ello, el entorno que se ha empleado como punto de partida es MeTAGeM, que a nivel PSM, propone el modelado de transformaciones que siguen la aproximacin hbrida. La aproximacin hbrida para el desarrollo de transformaciones de modelos es una combinacin de los enfoques declarativo e imperativo, donde en general prevalecen las construcciones declarativas [49] porque se consideran ms adecuado para el desarrollo de transformaciones. En el fondo, el desarrollo de una transformacin puede verse como la construccin de un programa basado en reglas, para los que tradicionalmente se ha aceptado que los lenguajes declarativos, tipo Prolog, resultan ms adecuados. No obstante, si no se quiere complicar demasiado el cdigo que implementa la transformacin, en muchas ocasiones es necesario de disponer de construcciones imperativas dada la mayor expresividad de los lenguajes imperativos [49]. De hecho, la aproximacin hbrida que combina ambos enfoques, es probablemente la aproximacin ms aceptada por los lenguajes de transformacin existentes [50]. As pues, a la hora de demostrar que la propuesta de MeTAGeM-Trace es factible, proporcionando una prueba de concepto, se ha optado por hacerlo para la aproximacin hbrida. Como trabajo futuro se propondr aplicar la propuesta a otras aproximaciones para el desarrollo de transformaciones. El metamodelo que se propone a nivel PSM en [31], fue definido a partir de un anlisis de los lenguajes de transformacin de modelos ms representativos que siguen la aproximacin hbrida, con el objetivo de determinar los elementos comunes a dichos lenguajes. As, los principales elementos de este metamodelo son la definicin de los metamodelos origen y destino de la transformacin, las reglas de la transformacin y las operaciones (o funciones) que se definen en el contexto de la transformacin. Dado que en este caso los elementos que relacionan los elementos de los metamodelos origen y los metamodelos destino tienen una semntica propia del mundo de las transformaciones (rule y binding), es recomendable e incluso necesario definir nuevos elementos que describan las relaciones de trazabilidad entre los elementos de dichos metamodelos. Por ello, en la Figura 4-6, se propone un nuevo metamodelo para el modelado de transformaciones de acuerdo a la aproximacin hbrida, incluyendo los constructores apropiados para el modelado de las relaciones de trazabilidad.

Propuesta Metodolgica 141

HybridElement -name : string

Datatype
sourceModels rightPattern

SourceModel Model

0..* Operation -body : string

operations

1 Module 1 1 1 0..*
arguments

1..*
targetModels

0..1 0..*

TargetModel

-path : string -type_mm : string

-null -Boolean -Integer -String

0..1 0..*
context

1..*
guard

TypeElement -EClassifier -EAttribute -EReference

0..*
return

0..*
rules

1
rule

Guard -value : string TraceRule

OpDefinition -datatype : Datatype

OpArgument -name : string -datatype : Datatype

0..1 Rule -isAbstract : bool -isMain : bool -isUnique : bool -typeRelation : TypeRelation -typeElement : TypeElement -comment : string 0..* 0..1 Target
isExtended

0..* 0..1
extend

TypeRelation
trace

0..1 0..1

0..1 0..1
component

0..1 0..1
component

rightPattern

-Copy -Concatenation -Other

0..1
belongsTo

0..* 0..1
targets target

0..1

traceLink

TraceLink

TransformationElement

0..* LeftPattern 0..*

traceLink

owns

0..1 0..1 0..*

0..* 0..*
source

Source

sources

target

source

0..1 0..* 0..*

rule

0..* 0..*
reference

1 0..* 0..*
bindings

left

1
trace

TraceBinding

0..*
traceBindings

RightPattern -concreteValue : string

Binding 1 0..1
right

-typeRelation : TypeRelation -typeElement : TypeElement

binding

operation

1 0..1

0..1

Figura 4-6. Metamodelo de Transformaciones para la aproximacin Hbrida (nivel PSM)

142

lvaro Jimnez Rielo

Este metamodelo incluye constructores para el modelado de los aspectos comunes a los lenguajes que siguen esta aproximacin: mdulo (Module), reglas (Rule), elementos origen (Source) y destino de las reglas (Target), asignaciones tipo binding (Binding), operaciones (Operation) y metamodelos origen (SourceModel) y destino (TargetModel). Adems para soportar el modelado de las relaciones de trazabilidad, se incluye la metaclase TraceLink (abstracta). Cada relacin de trazabilidad puede tener entre 0 y N elementos origen y destino. Estas cardinalidades se derivan de las relaciones que se pueden establecer a nivel PIM (uno-a-uno, uno-a-cero, uno-amuchos, cero-a-uno, muchos-a-uno o muchos-a-muchos). Finalmente, estas relaciones de trazabilidad pueden ser de los dos tipos que definen las metaclases TraceRule y TraceBinding. La primera permite el modelado de las relaciones de trazabilidad que se derivan directamente de reglas de transformacin, estableciendo un vnculo entre los elementos del patrn origen y el patrn destino de la regla. La segunda (TraceBinding) permite modelar las relaciones entre los elementos implicados en los bindings de la regla, generalmente atributos y referencias.

4.2.4

Metamodelos Dependientes de Plataforma (nivel PDM)

En el nivel PSM se propona un metamodelo para el modelado de transformaciones de acuerdo a la aproximacin hbrida. Por tanto, a la hora de refinar los modelos de transformacin conformes a dicho metamodelo en modelos de menor nivel de abstraccin, se deben seleccionar lenguajes de transformacin que sigan la aproximacin hbrida. En MeTAGeM se consideraban los lenguajes ATL [107] y RubyTL [179]. El primero fue escogido por ser probablemente el lenguaje de transformacin ms maduro y estndar de-facto para el desarrollo de transformaciones de modelos. Adems, dado que en el desarrollo del lenguaje se aplicaron los principios de MDE, exista una implementacin del metamodelo de ATL, lo que resultaba muy conveniente para poner en prctica la propuesta de MeTAGeM. Por su parte, RubyTL, un lenguaje de transformaciones embebido en Ruby, se seleccion porque, despus de ATL, se consider uno de los lenguajes hbridos ms maduros cuando se abordo la implementacin de MeTAGeM. Adems, aunque en aquel momento no se dispona de una especificacin completa del metamodelo subyacente, la cantidad de documentacin disponible y la posibilidad de contactar con los desarrolladores del lenguaje, facilitaban la tarea de definir dicho metamodelo [31].

Propuesta Metodolgica 143

A la hora de seleccionar los lenguajes de transformacin para los que MeTAGeM-Trace debera ser capaz de soportar el modelado y generacin de transformaciones se ha optado por ATL y ETL [118]. En cuanto a los motivos para escoger ATL, los que guiaron su seleccin en MeTAGeM siguen siendo vlidos a da de hoy. A pesar de la aparicin de algunas implementaciones del estndar QVT [32, 105, 126, 155, 178, 196], ATL sigue siendo considerado el estndar de-facto para el desarrollo de transformaciones. Adems, sigue siendo el que proporciona mayor cantidad de documentacin y existen distintas implementaciones que permiten generar el cdigo ATL que implementa la transformacin a partir del modelo correspondiente [7, 15, 104, 105, 107]. Por todo ello, se consideraba conveniente probar que la propuesta de MeTAGeM-Trace se puede utilizar para desarrollar transformaciones ATL que incluyen generacin de trazas. Por otro lado, si en MeTAGeM la seleccin de ATL responda a la intencin de mostar que la propuesta era vlida para el lenguaje ms utilizado, es decir, para el escenario ms habitual, la seleccin de RubyTL iba ms orientada a mostrar que la propuesta era igualmente aplicable para otros lenguajes. Dado que con la implementacin para ATL se demuestra que es factible implementar la propuesta de MeTAGeM-Trace en un lenguaje que ya era soportado en MeTAGeM, se deduce que sera igualmente factible hacerlo tambin para RubyTL3 por lo que se ha optado por considerar un nuevo lenguaje, en este caso ETL. Por su parte, ETL es un lenguaje para el desarrollo de transformaciones de modelos que sigue la aproximacin hbrida. Pertenece a la familia de lenguajes de Epsilon (Extensible Platform for Specification of Integrated Languages for mOdel Management,[119, 120]) que proporciona un conjunto de lenguajes para las diferentes operaciones relacionadas con la gestin de modelos. Existe gran cantidad de informacin disponible en forma de ejemplos de uso y un foro de discusin frecuentemente actualizado por la amplia comunidad de desarrolladores que utiliza el lenguaje. Finalmente, aunque en [118] se presenta una especificacin parcial del metamodelo, no se ha encontrado ninguna implementacin del mismo, por lo que ha sido necesario completar e implementar dicha especificacin. Para concluir esta seccin conviene hacer notar de nuevo que, aunque en esta tesis doctoral se han elegido los lenguajes de transformacin ATL y ETL para

Conviene mencionar que en trabajos anteriores ([31], [99]) se comprob las dificultades asociadas a

implementar una propuesta para el DDM de transformaciones para un lenguaje embebido en un lenguaje no orientado a trabajar con modelos (Ruby).

144

lvaro Jimnez Rielo

mostrar la aplicabilidad de la propuesta y desarrollar un primer prototipo, la propuesta sera igualmente aplicable para cualquier otro lenguaje de transformacin. La complejidad de hacerlo estribara sobre todo en la facilidad para definir el metamodelo subyacente del lenguaje en cuestin. A continuacin se muestran los metamodelos utilizados para los lenguajes ATL y ETL. 4.2.4.1 ATL En la Figura 4-7, se presenta el metamodelo simplificado de ATL [15, 104, 107]. Aunque se trata de un metamodelo bastante complejo, es posible identificar claramente los elementos comunes a los lenguajes que siguen una aproximacin hbrida que se han definido en el metamodelo PSM. El elemento raz es la metaclase Module que contiene Helpers y Rules. Un Helper se corresponde con las operaciones auxiliares que define el desarrollador en el mbito del mdulo de la transformacin. En cuanto a las reglas, ATL define tres tipos de reglas que se corresponden con los diferentes modos de programacin soportados: CalledRule (regla imperativa), MatchedRule (regla declarativa) y LazyMatchedRule, que es una especializacin de la regla de tipo MatchedRule. La funcionalidad de cada tipo de reglas es: Called Rule: permite introducir construcciones imperativas en las reglas ATL. Este tipo de reglas pueden recibir parmetros de entrada y deben ser invocadas de forma explcita para ser ejecutadas desde la seccin de cdigo imperativo de una regla tipo MatchedRule u otra regla de tipo CalledRule. Adems, un objeto CalledRule tiene dos propiedades de tipo booleano que permiten especificar el momento de ejecucin de la regla: al inicio de la transformacin (isEntrypoint) o al finalizar la transformacin (isEndpoint). Matched Rule: son las reglas principales de una transformacin ATL. Permiten especificar: 1) qu elemento o elementos del modelo destino se deben generar a partir de uno o varios elementos del modelo origen, y 2) la manera en que se deben dichos elementos en el modelo destino. En el momento de la ejecucin, el motor de ATL comprueba si en el conjunto de reglas existe alguna cuyo patrn de origen se corresponda con los elementos de modelo origen; si hubiese alguna coincidencia se generan en el modelo destino los elementos especificados en el patrn destino de la regla. Este tipo de reglas pueden ser abstractas (atributo isAbstract) y en consecuencia, extendidas por otras reglas. LazyMatched Rule: es una especializacin del tipo de regla MatchedRule. Su principal caracterstica es que para ser ejecutada, debe ser invocada de forma

Propuesta Metodolgica 145

explcita por otra regla. Si la propiedad booleana isUnique toma valor verdadero, sucesivas invocaciones de la regla devolvern la referencia al elemento generado la primera vez que se invoc.

146

lvaro Jimnez Rielo

LocatedElement -location : string -commentsBefore : string -commentsAfter : string

* LibraryRef -name : string

libraries unit elements

1 ifStat 1

0..*

Unit -name : string

ModuleElement

PatternElement

Binding -propertyName : string 0..*

Statement

thenStatements

statements

elseStatements statements

0..*
actionBlock module

ActionBlock 1 OutPatternElement 1..1

Helper Module

1 0..1 Rule -name : string

rule rule rule outPattern

0..* ExpressionStat

BindingStat -propertyName : string

-isRefining : bool
helpers

elements outPattern

0..1
mapsTo

OutPattern 10..1 1 1..*

sourceElement inPattern InPatternElement elements

0..1 0..*
library

0..1

helpers

0..*
query

* Query

0..1 SimpleOutPatternElement

ForStat

variables

0..1 InPattern
inPattern

Library

RuleVariableDeclaration

1..* 1

0..1
rule

MatchedRule CalledRule -isEntrypoint : bool -isEndpoint : bool -isAbstract : bool -isRefining : bool -isNoDefault : bool LazyMatchedRule 1 -isUnique : bool

SimpleInPatternElement

ForEachOutPatternElement

0..1
superRule children

0..*

Figura 4-7. Metamodelo de ATL

Propuesta Metodolgica 147

4.2.4.2

ETL ETL (Epsilon Transformation Language, [118]) es un lenguaje hbrido para el desarrollo de transformaciones de modelos que pertenece a la familia de lenguajes de Epsilon. La sintaxis abstracta de ETL define componentes comunes a cualquier lenguaje de transformacin de modelos como el mdulo o las reglas de transformacin. Sin embargo, para soportar otras funcionalidades, como operaciones o declaracin de variables, se apoya en el lenguaje EOL (Epsilon Object Language, [115]). A diferencia de ATL, ETL no proporciona una especificacin completa de su metamodelo. Por este motivo, para soportar el modelado de las transformaciones en trminos de ETL, ha sido necesario especificar e implementar el metamodelo del lenguaje. Para llevar a cabo esta tarea se ha analizado en profundidad la sintaxis del lenguaje [118, 119] as como ciertos aspectos del lenguaje EOL y los ejemplos disponibles en el sitio web de la herramienta Epsilon. El resultado de este proceso es el metamodelo para ETL que muestra la Figura 4-8. Al igual que en los metamodelos anteriores, la metaclase raz es el mdulo de la transformacin (EtlModule). Este mdulo puede contener bloques de cdigo EOL que definan las pre-condiciones y post-condiciones de la transformacin (EolBlock), las reglas de la transformacin (TransformationRule) y operaciones que se pueden invocar a lo largo de la ejecucin de la transformacin ( Operation). ETL permite la definicin de distintos tipos de reglas: reglas matched, reglas lazy, reglas abstractas, reglas greedy y reglas primarias. En el metamodelo de ETL presentado, la informacin sobre el tipo de regla se recoge en un conjunto de atributos booleanos en la metaclase TransformationRule: isAbstract, lazy, primary y greedy. En caso de que el atributo lazy sea falso, se asume que se trata de una regla tipo matched. Las funcionalidades de cada tipo de regla ETL son las siguientes: Matched Rule: tienen la misma funcionalidad que en ATL, es decir son las reglas principales de la transformacin. Permiten definir qu elemento o elementos se deben generar en el modelo destino a partir de la existencia uno o varios elementos en el modelo origen. Lazy Rule: como en ATL, son reglas que deben ser invocadas explcitamente por otras reglas. Abstract Rule: reglas abstractas que pueden ser extendidas por otras reglas.

148

lvaro Jimnez Rielo

EtlElement -name : string OperationParameter

Guard
guard

Block 1 0..1 0..1

target_rule rule

0..*
parameters

-body : string 0..1 1

rules module

1
operations

TransformationRule -isAbstract : bool -lazy : bool -primary : bool -greedy : bool

rule

EtlModule 1
preModule

Operation -annotation : string

0..1
source_rule

1..*
isExtended

0..* 0..1
pre

0..1

EolBlock

pre

preOperation

0..* 1..*
targets

0..1
post

0..1

0..1
postOperation

1
source

extends

postModule

0..1
post

0..*

0..1

0..1

Element -className : string -metamodel : string 0..*

bindings

1
source

Binding 0..1
elementChild

Statement

OperationStatement -operator : string

1 0..1
elementRef target

1 0..1 SimpleStatement -property : string 0..1

parameter1 parameter2

Figura 4-8. Metamodelo de ETL

Propuesta Metodolgica 149

Greedy Rule: a diferencia de otras reglas, los elementos que las invocan no tienen porqu ser exactamente del mismo tipo definido, sino que tambin pueden ser de un subtipo de dicho tipo (Type-of vs. Kind-of). Por ejemplo, si se tiene un elemento X del que heredan los elementos Y y Z, las reglas greedy definidas para X tambin se ejecutarn para los elementos Y y Z. Primary Rule: para devolver los elementos generados a partir de un elemento concreto, una de las operaciones que proporciona ETL es equivalents(). Por defecto, la operacin equivalents() devuelve una lista de elementos, ordenada segn el orden en el que se han definido las reglas que los han creado. Sin embargo, cuando una regla es definida como primary sus resultados preceden, en dichas listas, a los del resto de tipos de reglas.

4.3

Especificacin de Transformaciones

Para automatizar el paso entre los distintos niveles de abstraccin presentados en MeTAGeM-Trace (Figura 4-3) se propone el uso de transformaciones de modelos (PIM-PSM y PSM-PDM) y transformaciones de modelo a texto (PDM-Cdigo). En cuanto a la forma de definir estas transformaciones, como se indica en el mtodo de construccin detallado en la seccin 2.3, primero se definen en lenguaje natural y posteriormente se implementan mediante un lenguaje de transformaciones. Aunque lo recomendable sera seguir un proceso completo como el que se propone en [88] (elicitacin de requisitos, anlisis, diseo, implementacin, pruebas, etc.), definir las reglas de transformacin en lenguaje natural antes de su implementacin puede considerarse, en cierto modo, como la realizacin de una fase de anlisis previa al diseo. Dado que el proceso de desarrollo propuesto por MeTAGeM-Trace es guiado por el conjunto de transformaciones que se describen en esta seccin, toda aproximacin que ayude a mejorar, en algn grado, la calidad de dichas transformaciones, como puede ser su definicin en lenguaje natural, resulta en modelos mejor construidos y por tanto, favorece la mejora del proceso en general. En las siguientes sub-secciones se describen estas transformaciones en lenguaje natural.

4.3.1

Transformacin de modelos PIM a modelos PSM

Para realizar la especificacin de las reglas de transformacin y determinar las relaciones existentes es necesario analizar los metamodelos que intervienen en

150

lvaro Jimnez Rielo

la transformacin, en este caso los metamodelos definidos a nivel PIM y PSM (metamodelo MeTAGeM y metamodelo de transformaciones de aproximacin hbrida, respectivamente). Una vez que se ha realizado dicho anlisis, la Tabla 4-1 muestra las reglas de transformacin, definidas a nivel de metamodelo, para crear modelos PSM a partir de modelos PIM. Se han definido cinco tipos de relaciones principales: 1. La transformacin del elemento raz del modelo de la transformacin (ModelRoot -> Module). 2. La transformacin de los elementos que representan a los metamodelos origen y destino de la transformacin que se est desarrollando. 3. La transformacin de las relaciones a nivel PIM en reglas de transformacin y relaciones de trazabilidad, a nivel PSM. (Los elementos que describen las relaciones de trazabilidad aparecen en negrita). 4. La transformacin de las relaciones a nivel PIM en asignaciones tipo binding y relaciones de trazabilidad, a nivel PSM. (Los elementos que describen las relaciones de trazabilidad aparecen en negrita). 5. La transformacin de los elementos origen y destino implicados en la transformacin. Los puntos 3 y 4 se corresponden con conjuntos de reglas compuestos por una regla abstracta (Relations -> Rule y Relations -> Binding, respectivamente) y las reglas que la extienden, que en este caso, se corresponden con los tipos de relaciones que se pueden establecer a nivel PIM. En la Tabla 4-1, las reglas abstractas aparecen sombreadas.
Tabla 4-1. Transformacin PIM a PSM

Metamodelo MeTAGeM (PIM)

ModelRoot SourceModelTransf TargetModelTransf Relations (no incluida en otra Relations)

Metamodelo Hbrido (PSM)

Module SourceModel TargetModel Rule TraceRule Rule Source: 1 elemento Target: 1 elemento

OneToOne (no incluida en otra Relations) TraceRule Source: 1 elemento Target: 1 elemento

Propuesta Metodolgica 151

Metamodelo MeTAGeM (PIM)

Rule OneToZero (no incluida en otra Relations) Rule ZeroToOne (no incluida en otra Relations) Rule OneToMany (no incluida en otra Relations) Rule ManyToOne (no incluida en otra Relations) Rule ManyToMany (no incluida en otra Relations) Relations (Incluida en otra Relations)

Metamodelo Hbrido (PSM)

Source: 1 elemento Target: Sin elementos

TraceRule Source: 1 elemento Target: Sin elementos

Source: Sin elementos Target: 1 elemento

TraceRule Source: Sin elementos Target: 1 elemento Source: 1 elemento Target: N elementos

TraceRule Source: 1 elemento Target: N elementos Source: N elementos Target: 1 elemento

TraceRule Source: N elementos Target: 1 elemento Source: N elementos Target: N elementos

TraceRule Source: N elementos Target: N elementos

Binding TraceBinding Binding OneToOne (Incluida en otra Relations) RightPattern Source: 1 elemento

152

lvaro Jimnez Rielo

Metamodelo MeTAGeM (PIM)

Metamodelo Hbrido (PSM)

LeftPattern Target: 1 elemento

TraceBinding Source: 1 elemento Target: 1 elemento

Binding RightPattern ManyToOne (Incluida en otra Relations) Source: N elementos

LeftPattern Target: 1 elemento

TraceBinding Source: N elementos Target: 1 elemento

Binding RightPattern ZeroToOne (Incluida en otra Relations) SourceElement TargetElement Source: Sin elementos

LeftPattern Target: 1 elemento

TraceBinding Source: Sin elementos Target: 1 elemento

Source Target

4.3.2

Transformacin de modelos PSM a modelos PDM

De forma similar a la seccin anterior, a continuacin se definen las reglas de transformacin entre el metamodelo PSM y los metamodelos especificados a nivel PDM (metamodelo de ATL y ETL). Es necesario destacar que estas transformaciones son las ms complejas de todo el proceso propuesto por MeTAGeM-Trace ya que deben, por un lado, refinar el modelo de transformacin PSM y por otro, crear, en el modelo de la transformacin resultante, las estructuras necesarias que componen el generador de trazas embebido en la transformacin. Dichos elementos se generan a partir de las relaciones de trazabilidad definidas a nivel PSM y de acuerdo a las

Propuesta Metodolgica 153

caractersticas propias del lenguaje al que se modela la transformacin a nivel PDM. 4.3.2.1 Transformacin PSM a ATL (PDM) En la Tabla 4-2 se muestra una simplificacin de las reglas de transformacin entre los elementos del metamodelo de nivel PSM (aproximacin hbrida) y los elementos del metamodelo ATL (nivel PDM), usando lenguaje natural. Con el objetivo de facilitar la comprensin al lector, solo se muestran los principales elementos generados. Sirva un ejemplo para ilustrar la complejidad de esta transformacin: para generar correctamente el elemento de salida CalledRule (CreateTraceModelRoot), recuadrado en la siguiente tabla, es necesario generar, adems de dicho elemento, otros diez que no son mostrados en la tabla: OutPattern, SimpleOutPattern, OclModelElement, ActionBlock, BindingStat, NavigationOrAttributeCallExp, VariableExp y VariableDeclaration (de estos dos ltimos tipos se generan dos elementos de cada uno). Al igual que en la tabla anterior, los elementos de salida que se corresponden con el generador de trazas son mostrados en negrita.
Tabla 4-2. Transformacin PSM a ATL (PDM)

Metamodelo Hbrido (PSM)

Module Module

Metamodelo ATL (PDM)

OclModel (TraceModel) CalledRule (CreateTraceModelRoot) Helper (getTraceModelRoot) Helper (getName) OclModel (SourceModel)

SourceModel

CalledRule(createSourceModel_TraceModel) Helper (getSourceModel_TraceModel) OclModel (TargetModel)

TargetModel

CalledRule(createTargetModel_TraceModel) Helper (getTargetModel_TraceModel) MatchedRule InPattern OutPattern

Rule (isMain==true and sources>0)

Rule (isMain==false and sources>0 and isUnique==false)

LazyMatchedRule InPattern OutPattern

154

lvaro Jimnez Rielo

Metamodelo Hbrido (PSM)

Rule (isMain==false and sources>0 and isUnique==true)

Metamodelo ATL (PDM)

UniqueLazyMatchedRule InPattern OutPattern CalledRule OutPattern SimpleInPatternElement SimpleInPatternElement SimpleOutPatternElement (TraceElement:Source) SimpleOutPatternElement (TraceElement:Source) SimpleOutPatternElement SimpleOutPatternElement SimpleOutPatternElement (TraceElement:Target) SimpleOutPatternElement (TraceElement:Target) Binding Helper Parameter SimpleOutPatternElement (TraceLink)

Rule (sources==0) Source (entrada de una regla and traceLink==0) Source (entrada de una regla and traceLink>0) Source (entrada de una RightPattern and traceLink>0) Target (entrada de una regla and traceLink==0) Target (entrada de una regla and traceLink>0) Target (entrada de una RightPattern and traceLink>0) Binding Operation Argument

TraceRule

source: rule.sources target: rule.targets childLinks: traceRule.traceBindings

SimpleOutPatternElement (TraceLink) TraceBinding Datatype Boolean Datatype Integer Datatype String TransformationElement source: binding.sources target: binding.targets

BooleanType IntegerType StringType OclModelElement

Propuesta Metodolgica 155

4.3.2.2

Transformacin PSM a ETL (PDM) Al igual que se hizo para el lenguaje ATL, la Tabla 4-3 muestra una simplificacin de las relaciones de transformacin definidas entre los elementos del metamodelo PSM y los elementos del metamodelo de ETL (nivel PDM).
Tabla 4-3. Transformacin PSM a ETL (PDM)

Metamodelo Hbrido (PSM)

Module SourceModel TargetModel

Metamodelo ETL (PDM)

EtlModule Aade informacin al bloque Pre Aade informacin al bloque Pre TransformationRule

Rule (sources==1 and targets>0)

source: rule.sources target: rule.targets +r.trace+ r.trace.traceBindings

Binding LeftPattern TransformationElement (incluido en un OpDefinition or en un OpArgument) Source (incluido en una Rule and traceLink==0) Source (incluido en una Rule and traceLink>0) Source (incluido en un RightPattern and traceLink==0) Source (incluido en un RightPattern and traceLink>0) Target(incluido en una Rule and traceLink==0) Target (incluido en una Rule and traceLink>0) Target (incluido en un LeftPattern and traceLink==0) Target (incluido en un LeftPattern and traceLink>0)

Binding SimpleStatement Element Element Element Element (TraceElement:Source) Element Element Element (TraceElement:Source) belongsTo: source.rule

Element Element Element (TraceElement:Target) Element Element Element (TraceElement:Target) belongsTo: target.rule

156

lvaro Jimnez Rielo

Metamodelo Hbrido (PSM)

TraceRule Guard Operation OpDefinition (return==Boolean or return==Integer or return==String ) OpArgument (return==Boolean or return==Integer or return==String )

Metamodelo ETL (PDM)

Element (TraceLink) source: traceRule.sources target: traceRule.targets

Element (TraceLink) TraceBinding source: traceBinding.sources target: traceBinding.targets

Guard Operation SimpleStatement OperationParameter

Adems de las reglas de transformacin anteriores, es necesario definir tres operaciones imperativas para crear los bloques pre y post (EolBlock) y para crear una operacin (getName) que proporcione en tiempo de ejecucin los nombres de los elementos que participan en la transformacin.

4.3.3

Transformacin de modelo PDM a cdigo

En el proceso descrito por MeTAGeM-Trace, la ltima transformacin se refiere a la serializacin de los modelos PDM en el cdigo que implementa la transformacin en el lenguaje correspondiente. En el caso de lenguaje ATL no ha sido necesario definir esta transformacin de modelo a texto, ya que como se ha indicado anteriormente, el plug-in de ATL para Eclipse proporciona un extractor de cdigo ATL a partir de modelos conformes al metamodelo del lenguaje. En el caso de ETL, al no disponer de estos extractores o generadores de cdigo, s ha sido necesario definir cmo se genera el cdigo de la transformacin. Para llevar a cabo esta tarea, se ha seguido el mismo procedimiento que en las transformaciones M2M definidas anteriormente. As, en la Tabla 4-4 se describe en lenguaje natural, la transformacin entre los modelos ETL y el cdigo ETL.

Propuesta Metodolgica 157

Tabla 4-4. Transformacin ETL (PDM) a ETL (Cdigo)

Metamodelo ETL (PDM)

Cdigo ETL
pre pre.name { pre.body } module.transformationRules module.operations post pre.name { post.body } [(@greedy, @abstract, @lazy, @primary)] rule name transform source to targets [extends extends] { [guard: guard.body] bindings }

EtlModule

TransformationRule

Binding SimpleStatement (Binding) SimpleStatement (Operation) OperationStatement Element

target := source ; [ref .] property [child.metamodel ! className] [ref .] property [parameter1] operator [parameter2] name : metamodel ! class [ @ annotation] [@ pre] [@ post]

Operation

operation context [ ( parameters ) ] : return return { body } name : [ref.metamodel ! ref.className] [. property]

OperationParameter

158

lvaro Jimnez Rielo

4.4

Especificacin de reglas de validacin de modelos

Una de las principales ventajas de aplicar los principios de MDE al desarrollo de transformaciones es que estas pueden ser tratadas como cualquier otro modelo del proceso de desarrollo, es decir, pueden transformarse, mezclarse (merging), soportar distintas sintaxis concretas, etc. [21]. Una de las tareas ms habituales y ms soportadas por las herramientas MDE es la validacin de modelos. Dado que los sistemas se construyen a partir de la especificacin de un conjunto de modelos, cualquier error en un modelo puede ser transmitido a los modelos posteriores hasta reproducirse en la implementacin final del sistema. Por ello, el uso de mecanismos de validacin de modelos resulta clave para detectar errores e inconsistencias en las etapas tempranas del desarrollo, de cara a mejorar la calidad de dichos modelos y en consecuencia, del sistema final [146]. En este caso, validar los modelos de la transformacin ayuda a mejorar la calidad de la transformacin generada y en consecuencia, la de los modelos generados a partir de la ejecucin de dicha transformacin. As mismo, los metamodelos de los DSLs no siempre son suficientes para especificar la sintaxis abstracta de forma rigurosa y precisa. En algunos casos es necesario definir un conjunto de reglas que aseguren que los modelos cumplen ciertas condiciones que no pueden ser especificados en el metamodelo. Por todo ello, en esta seccin se presentan las reglas de validacin definidas para los metamodelos de los niveles de abstraccin PIM y PSM que se definen en MeTAGeM-Trace. Al igual que en el caso de las transformaciones, las reglas de validacin se describen en lenguaje natural.

4.4.1

Validacin del metamodelo PIM

En la Tabla 4-5 se muestran, en lenguaje natural, las reglas de validacin que debe cumplir todo modelo conforme al metamodelo definido a nivel PIM. Estas reglas se basan, principalmente, en asegurar que el nombre de los elementos est bien formado (debe comenzar por vocal y solo puede contener letras, nmeros y caracteres - o _) y que se cumpla la cardinalidad de las relaciones entre los elementos. Las reglas de validacin para las metaclases abstractas ( ModelTransf y Relations) aparecen sombreadas.

Propuesta Metodolgica 159

Tabla 4-5. Validacin del metamodelo PIM

Metaclase

Reglas de Validacin
- El atributo name debe estar definido. - El atributo name debe ser vlido (debe comenzar por una letra y solo puede contener letras, nmeros y caracteres - o _) - Debe contener como mnimo un modelo origen - Debe contener como mnimo un modelo destino - Debe contener como mnimo una relacin

ModelRoot

ModelTransf

- El atributo name debe estar definido. - El atributo name debe ser vlido.

SourceModelTransf TargetModelTransf

- Las mismas que ModelTransf (herencia). - Las mismas que ModelTransf (herencia). - El atributo role debe estar definido. - El atributo typeElement debe estar definido. - El atributo typeRelation debe estar definido. - Solo puede extender a relaciones abstractas. - Las mismas que Relations (herencia). - Debe tener un elemento origen. - Debe tener un elemento destino. - Las mismas que Relations (herencia). - Debe tener un elemento origen. - Las mismas que Relations (herencia). - Debe tener un elemento destino. - Las mismas que Relations (herencia).

Relations

OneToOne

OneToZero

ZeroToOne

OneToMany

- Debe tener un elemento origen. - Debe tener uno o ms elementos destino. - Las mismas que Relations (herencia). - Debe tener uno o ms elementos origen. - Debe tener uno o ms elementos destino.

ManyToMany

4.4.2

Validacin del metamodelo PSM

Al igual que en el caso anterior, la Tabla 4-6 muestra las reglas de validacin que deben cumplir los modelos conformes al metamodelo definido a nivel PSM (metamodelo de aproximacin hbrida). Las reglas de validacin para las metaclases abstractas ( Model y TransformationElement) aparecen sombreadas.

160

lvaro Jimnez Rielo

Tabla 4-6. Validacin del metamodelo PSM

Metaclase

Reglas de Validacin
- El atributo name debe estar definido. - El atributo name debe ser vlido (debe comenzar por una letra y solo puede contener letras, nmeros y caracteres - o _) - Debe contener como mnimo un modelo origen - Debe contener como mnimo un modelo destino - Debe contener como mnimo una relacin - El atributo name debe estar definido.

Module

Model

- El atributo name debe ser vlido. - El atributo type_mm debe estar definido. - El atributo path debe estar definido

SourceModel TargetModel

- Las mismas que Model (herencia). - Las mismas que Model (herencia). - El atributo name debe estar definido. - El atributo isAbstract debe estar definido. - El atributo isMain debe estar definido. - El atributo typeElement debe estar definido. - El atributo typeRelation debe estar definido. - Solo puede extender a reglas abstractas.

Rule

Operation OpDefinition

- El atributo name debe estar definido. - El atributo body debe estar definido. - Debe devolver (return) un tipo de dato (datatype) o un elemento (element), tan solo uno de los dos. - El atributo name debe estar definido.

OpArgument Guard TransformationElement Source Target

- Debe devolver (return) un tipo de dato (datatype) o un elemento (element), tan solo uno de los dos. - El atributo value debe estar definido. - El atributo name debe estar definido. - Las mismas que TransformationElement (herencia). - Las mismas que TransformationElement (herencia). - El atributo typeElement debe estar definido.

Binding

- El atributo typeRelation debe estar definido. - El atributo left debe estar definido. - El atributo right debe estar definido.

Propuesta Metodolgica 161

Metaclase

Reglas de Validacin
- Debe definir por lo menos uno de los siguientes atributos: concreteValue, source, operation, reference o rule. - Si define un valor concreto (concreteValue) no puede definir los atributos source, operation, reference y rule. - No puede definir al mismo tiempo los atributos rule y operation. - No puede definir al mismo tiempo los atributos rule y reference. - No puede definir al mismo tiempo los atributos reference y operation. - No puede definir al mismo tiempo los atributos reference y source.

RightPattern

LeftPattern

- El atributo target debe estar definido.

Las reglas de validacin descritas en la tabla anterior son generales para cualquier modelo conforme al metamodelo PSM definido. Sin embargo, dado que los modelos PSM sern transformados en modelos conformes a los metamodelos de ATL o ETL (nivel PDM), resulta recomendable establecer reglas de validacin adicionales para los modelos que sean transformados a uno u otro lenguaje. A continuacin se presentan dichas reglas de validacin, que se aaden a las ya presentadas. 4.4.2.1 ATL En la Tabla 4-7 se muestran las reglas de validacin que debe cumplir todo modelo PSM para su correcta transformacin a un modelo ATL. Estas reglas de validacin se establecen de acuerdo a las caractersticas particulares del lenguaje de transformacin ATL. A modo de ejemplo, ATL obliga a definir el tipo de dato que devuelve un helper. Por ello, para comprobar que todas las operaciones definidas a nivel PSM especifican el tipo de retorno, se aade una regla de validacin para la metaclase Operation.
Tabla 4-7. Validacin del metamodelo PSM para transformaciones a ATL

Metaclase
Rule Operation

Reglas de Validacin
- Una regla con ms de un elemento origen debe establecer el atributo typeRelation a valor Concatenation. - El atributo return debe estar definido.

162

lvaro Jimnez Rielo

Metaclase
Binding

Reglas de Validacin
- Un binding con ms de un elemento origen debe establecer el atributo typeRelation a valor Concatenation. - Si pertenece a una regla que no tiene elementos origen, no puede definir los siguientes atributos: source, operation y rule.

RightPattern

4.4.2.2

ETL Del mismo modo que en la seccin anterior, la Tabla 4-8 presenta las reglas de validacin adicionales que debe cumplir todo modelo PSM para ser transformado en un modelo conforme a las caractersticas del lenguaje de transformacin ETL.
Tabla 4-8. Validacin del metamodelo PSM para transformaciones a ETL

Metaclase
Rule Binding

Reglas de Validacin
- Solo puede tener un elemento origen. - Un binding con ms de un elemento origen debe establecer el atributo typeRelation a valor Concatenation.

Solucin Tecnolgica

5. Solucin Tecnolgica
Este captulo presenta el entorno de desarrollo MeTAGeM-Trace, construido para dar soporte a la propuesta metodolgica descrita en el captulo anterior y demostrar su factibilidad. Para estructurar la presentacin del entorno, se describen las diferentes actividades que han implicado su construccin: Definicin de la arquitectura conceptual y el diseo tcnico del entorno, de acuerdo al proceso para la construccin de herramientas descrito en [206]. El diseo tcnico especifica qu tecnologas se utilizan para implementar los diferentes componentes de la arquitectura conceptual. Implementacin de los metamodelos que soportan el modelado de transformaciones y relaciones de trazabilidad a distintos niveles de abstraccin. Implementacin del metamodelo de trazabilidad que soporta el modelado de las trazas generadas por la ejecucin de una transformacin de modelos desarrollada con MeTAGeM-Trace. Desarrollo de editores para la edicin y visualizacin de los modelos de transformacin y los modelos de trazas, de acuerdo a los metamodelos implementados. Implementacin de restricciones para recoger las reglas de validacin que deben satisfacer los modelos de transformacin y los modelos de trazas. Implementacin de las transformaciones que permiten automatizar el proceso de desarrollo de transformaciones (dirigido por modelos) propuesto por MeTAGeM-Trace.

Para la construccin o implementacin de la herramienta se propone un proceso iterativo e incremental que produce un conjunto mdulos interconectados y cada uno de estos mdulos se construye de acuerdo al mtodo de desarrollo que se detalla en la seccin 2.3. As, en las prximas secciones se presenta la arquitectura conceptual de MeTAGeM-Trace, omitiendo los detalles tcnicos (seccin 5.1); el diseo tcnico que establece las tecnologas a utilizar en su construccion (seccin 5.2); y finalmente, la implementacin de los distintos componentes que integran la herramienta (seccin 5.3).

166

lvaro Jimnez Rielo

5.1

Arquitectura Conceptual de MeTAGeM-Trace

La arquitectura de MeTAGeM-Trace, mostrada en la Figura 5-1, se basa en la arquitectura en capas de MeTAGeM [31]. Esta arquitectura mantiene un alto grado de modularizacin, de forma que MeTAGeM-Trace puede verse como un conjunto de mdulos independientes que interactan entre s. Estos mdulos se consideran independientes porque cada uno de ellos implementa un DSL para soportar uno de los modelos incluidos en la propuesta metodolgica. Esto es, cada mdulo incluye la implementacin de un metamodelo y el soporte necesario, en forma de editores, restricciones, transformaciones, etc. para definir y gestionar modelos terminales conformes a dicho metamodelo. Concretamente, como muestra la Figura 5-1, la arquitectura de MeTAGeM-Trace se compone de cinco mdulos diferentes que soportan: el modelado de las relaciones de transformacin a nivel PIM (DSL-MeTAGeM); el modelado de reglas de transformacin y relaciones de trazabilidad a nivel PSM (DSL-Aproximacin Hbrida); el modelado de transformaciones ATL (DSLATL); el modelado de transformaciones ETL (DSL-ETL); y el modelado de las trazas generadas a partir de la ejecucin de transformaciones (DSL-Trace). Una de las principales ventajas de esta modularizacin es la posibilidad de incluir nuevos DSLs para dar soporte a otros lenguajes (nivel PDM) o paradigmas de transformacin (PSM). Los mdulos que implementaran dichos DSLs sern directamente compatibles con los mdulos existentes (sin necesidad de desarrollar puentes tecnolgicos), ya que se utilizara la misma tecnologa y el mismo proceso de desarrollo para construirlos.
Presentacin

<<Interfaz de Usuario>>

<<Interfaz de Usuario>>

<<Interfaz de Usuario>>

<<Interfaz de Usuario>>

<<Interfaz de Usuario>>

MeTAGeM

Aprox. Hbrida

ATL

ETL

Trazas

Metamodelo Aprox. Hbrida

Modelo Aprox. Hbrida

Metamodelo MeTAGeM

Metamodelo Trazabilidad

Metamodelo ATL

Metamodelo ETL

Modelo MeTAGeM

Modelo ATL

Modelo ETL

Lgica

Figura 5-1. Arquitectura Conceptual de MeTAGeM-Trace

Modelo Trazas

Solucin Tecnolgica 167

Cada uno de los mdulos que componen la arquitectura conceptual de MeTAGeM-Trace sigue una aproximacin basada en capas [123, 124, 165], donde cada una de las capas representa una vista en particular de la arquitectura: presentacin y lgica. La capa de presentacin contiene la interfaz de usuario para crear manipular y visualizar los modelos elaborados con los DSLs que componen la herramienta. La lgica se divide en otras dos capas o niveles. El primero se corresponde con el manejador lgico de modelos, es decir, proporciona a la capa de presentacin las acciones (creacin, modificacin, borrado, etc.) que el usuario puede realizar sobre el contenido de los modelos a travs de la interfaz de la herramienta. El segundo nivel, denominado procesador de modelos [222], consiste en un mdulo donde se alojan tareas adicionales, propias de la gestin de modelos [21, 23, 58, 192], que permiten la integracin de los DSLs.

5.2

Diseo tcnico de MeTAGeM-Trace

Despus de definir la arquitectura conceptual de MeTAGeM-Trace, el siguiente paso consiste en la seleccin de las tecnologas que se utilizarn para implementar dicha arquitectura. Como se ha indicado en varias ocasiones a lo largo de esta tesis doctoral y se ha detallado en la seccin 2.3, para la construccin MeTAGeM-Trace se ha seguido una adaptacin del mtodo de desarrollo presentado por Vara en [206]. De acuerdo a dicho mtodo, el marco de metamodelado escogido para la construccin de MeTAGeM-Trace es EMF (Eclipse Modeling Framework, [42, 194]). Adems, todas las herramientas empleadas para la construccin del entorno (ATL, EVL y MOFScript) son asimismo extensiones o plug-ins de Eclipse construidos sobre EMF y el propio entorno MeTAGeM-Trace tambin ser un plug-in que extiende las capacidades de dicha plataforma. La Figura 5-2 muestra la relacin entre la arquitectura conceptual de MeTAGeM-Trace y las tecnologas empleadas para su construccin.

168

lvaro Jimnez Rielo

SINTAXIS CONCRETA
<<Interfaz de Usuario>>

Editores de Modelos

myDSL

+
SINTAXIS ABSTRACTA
Modelos Ecore

Metamodelo myDSL

PROCESADOR DE MODELOS
Procesador de modelos
Transformacin de modelos Validacin de modelos Generacin de Cdigo MOFScript

ATL

EVL

Figura 5-2. Diseo tcnico de MeTAGeM-Trace

Para definir la sintaxis concreta de cada DSL, se emplean las facilidades que proporciona EMF para la generacin semi-automtica de editores de modelos en forma de rbol. Sin embargo, el carcter genrico de estos editores no se ajusta a la naturaleza de los modelos de MeTAGeM-Trace. Por este motivo, tal como se detalla en la seccin 5.3.2, se han creado editores ad-hoc utilizando la API Java que EMF genera a partir de un metamodelo dado para soportar la gestin programtica de modelos conformes a dicho metamodelo. La sintaxis abstracta de cada (meta)modelo es gestionada directamente por EMF y es utilizada como entrada o salida de las tareas de modelado que soporta el procesador de modelos. Concretamente, estas tareas para las que MeTAGeM-Trace ofrece soporte son: la transformacin de modelos a los diferentes niveles de abstraccin; validacin de modelos PIM y PSM; y generacin del cdigo que implementa la modelada en ATL y ETL. De acuerdo a las tecnologas propuestas en [206], para dar soporte a estas tareas se ha empleado: ATL para las transformaciones de modelos, EVL (Epsilon Validation Language, [121]) para implementacin de restricciones y MOFScript [149] para la generacin de cdigo.

Solucin Tecnolgica 169

5.3

Implementacin

En las secciones anteriores se han introducido los principales componentes que conforman la arquitectura de MeTAGeM-Trace y las tecnologas que se usan para implementarlos. En esta seccin, se detalla dicha implementacin. As, siguiendo el orden de construccin definido en el mtodo de desarrollo (seccin 2.3), en primer lugar se muestra la implementacin de los metamodelos. Posteriormente, se detalla la construccin de los editores que permiten interactuar con modelos terminales conformes a los metamodelos anteriores y la construccin de los asistentes para la creacin de dichos modelos. A continuacin, se presenta la implementacin de las tareas de procesamiento de modelos: transformaciones de modelos, generadores de cdigo y validacin de modelos. Y finalmente, se describe cmo se ha llevado a cabo la integracin de todos los mdulos que componen la herramienta.

5.3.1

Implementacin de Metamodelos

En la seccin 4.2 se ha detallado la especificacin de los metamodelos que forman parte de MeTAGeM-Trace. En esta seccin se presenta la implementacin de dichos metamodelos que, como ya se ha mencionado, se ha realizado usando EMF. 5.3.1.1 Metamodelo MeTAGeM (nivel PIM) Para soportar el modelado de las relaciones de transformacin entre varios metamodelos origen y destino a alto nivel, en la seccin 4.2.2 se present la especificacin del metamodelo MeTAGeM, levemente mejorado respecto del presentado para el mismo propsito en [31]. En cambio, como se muestra a continuacin, en cuanto a la implementacin existe una evolucin fundamental que ha requerido la implementacin completa del metamodelo. El entorno de desarrollo dirigido por modelos de transformaciones de modelos MeTAGeM [31], antecesor del entorno MeTAGeM-Trace que se presenta en esta tesis doctoral, emplea la funcionalidad ofrecida por la herramienta AMW (Atlas Model Weaver, [58]) para la implementacin de los elementos del DSL a nivel PIM. La herramienta AMW permite representar relaciones entre modelos, mediante modelos de weaving. Sin embargo, AMW no est siendo actualizada al mismo ritmo que la plataforma Eclipse y el resto de tecnologas necesarias para la construccin de la herramienta MeTAGeM-Trace, dando lugar a algunos problemas de compatibilidad. De hecho para la construccin del entorno MeTAGeM se contact con el desarrollador de AMW (Didonet del Fabro), para obtener una versin actualizada de la herramienta [31]. Desde entonces

170

lvaro Jimnez Rielo

(noviembre de 2010), no se han publicado nuevas actualizaciones de AMW. Por este motivo, se ha decidido prescindir de AMW para el desarrollo de MeTAGeM-Trace y para reemplazar su funcionalidad, se ha optado por implementar una funcionalidad similar, directamente sobre EMF de acuerdo a las necesidades del DSL MeTAGeM. En cuanto a la implementacin del metamodelo que describe la especificacin presentada en la seccin 4.2.2, se ha definido el modelo Ecore, que se muestra en la Figura 5-3. Ecore, el lenguaje de modelado de EMF, es una implementacin simplificada de EMOF (Essential MOF, [158]). Es importante mencionar, que debido a la naturaleza XML subyacente del formato de almacenamiento de Ecore, cualquier modelo definido en trminos de Ecore, debe incluir un elemento raz. En el caso de este metamodelo, la metaclase raz es ModelRoot. Como parte de la desvinculacin de AMW ha sido necesario incluir, directamente en el metamodelo, cierta informacin que anteriormente era heredada de los metamodelos base de AMW. As por ejemplo, para conocer la ubicacin fsica de los metamodelos que intervienen en la transformacin, se ha definido un atributo path en la metaclase abstracta ModelTransf. Conviene sealar que para identificar los elementos implicados en la transformacin con los objetos reales de los metamodelos es posible emplear dos opciones: definir una referencia a un tipo EObject (el elemento del cual heredan todos los elementos de los modelos Ecore) y de esta forma, enlazar los elementos; o registrar el identificador XMI que poseen los elementos de los modelos Ecore, para posteriormente buscar la coincidencia de este dato. En este caso, se ha optado por la segunda opcin, dado que la primera implica cargar los metamodelos que participan en la transformacin, en el editor de modelos MeTAGeM.

Solucin Tecnolgica 171

Figura 5-3. Metamodelo MeTAGeM (Modelo Ecore)

172

lvaro Jimnez Rielo

5.3.1.2

Metamodelo de Aproximacin Hbrida (nivel PSM) De la misma forma que en el caso anterior, para la implementacin del metamodelo de transformacin especfico de plataforma, que describe las transformaciones que siguen una aproximacin hbrida (seccin 4.2.3), se ha creado el modelo Ecore que se muestra en la Figura 5-4. En este caso, el elemento raz del modelo Ecore es la metaclase Module, que contiene la representacin de los metamodelos participantes en la transformacin, las reglas de dicha transformacin y las operaciones definidas por el usuario en el mbito de la transformacin. Como se detallar ms adelante, tambin se desea que a este nivel se visualicen al mismo tiempo los metamodelos origen y destino de la transformacin y las relaciones existentes entre los elementos de dichos metamodelos (reglas de transformacin y relaciones de trazabilidad). Para ello, ha sido necesario incluir en este metamodelo a nivel PSM un conjunto de conceptos que ya aparecan en el metamodelo a nivel PIM. Concretamente, se ha incluido el atributo path en las metaclases que describen los metamodelos para registrar la ubicacin fsica de los metamodelos y el atributo ref en la metaclase TransformationElement para identificar los elementos mediante referencias XMI. Conviene mencionar que para facilitar el desarrollo de las transformaciones en las que interviene como origen o destino el metamodelo PSM, las referencias entre las metaclases del metamodelo se han implementado de forma bidireccional, es decir, la relacin se puede navegar en ambos sentidos.

Solucin Tecnolgica 173

Figura 5-4. Metamodelo de Aproximacin Hbrida (Modelo Ecore)

174

lvaro Jimnez Rielo

5.3.1.3

Metamodelos Dependientes de Plataforma (nivel PDM) Como ya se adelant en la seccin 4.2.4, para el modelado de las transformaciones a nivel PDM se propone el uso de los lenguajes ATL y ETL que siguen la aproximacin hbrida. Para el modelado de transformaciones ATL se utiliza el plug-in existente de ATL para Eclipse, por lo que no es necesario implementar el DSL correspondiente. En el caso del modelado de transformaciones ETL, s es necesario implementar un DSL para este lenguaje de transformacin dado que no se dispone de ninguna implementacin para este propsito, Al igual que en la implementacin de los metamodelos anteriores, la construccin del metamodelo de ETL se realiza en trminos de un modelo Ecore (Figura 5-5). El elemento principal o raz de este metamodelo es la metaclase EtlModule que representa la transformacin en s misma. Dicho mdulo se compone de operaciones (Operation), reglas de transformacin (TransformationRule) y bloques de cdigo EOL (EolBlock). Estos bloques de cdigo EOL no pertenecen explcitamente a la sintaxis abstracta del lenguaje, sin embargo para ofrecer algunas funcionalidades, ETL utiliza algunos conceptos del lenguaje EOL. Por este motivo, se ha definido la metaclase abstracta Block que contiene un atributo de tipo string que permite incluir cdigo EOL en la transformacin. En cuanto a las reglas de transformacin, como ya se present en la seccin 4.2.4.2, es posible definir reglas tipo matched, reglas abstractas, reglas lazy, reglas greedy y reglas primary. Para determinar de qu tipo de regla se trata, la metaclase TransformationRule incluye un conjunto de atributos booleanos (isAbstract, lazy, primary y greedy). Cada regla se compone de un elemento origen (source), uno o ms elementos destino (target) y un conjunto de asignaciones de variables (bindings). Adems, es posible establecer una pre-condicin que debe cumplirse antes de ejecutar la regla (guard).

Solucin Tecnolgica 175

Figura 5-5. Metamodelo de ETL (Modelo Ecore)

176

lvaro Jimnez Rielo

5.3.1.4

Metamodelo de Trazabilidad En esta seccin, se presenta la implementacin del metamodelo de trazabilidad genrico que define la sintaxis abstracta de los modelos de trazas que sern creados por el generador de trazas embebido en las transformaciones generadas con MeTAGeM-Trace. La Figura 5-6 muestra dicha implementacin, en trminos de un modelo Ecore. Los aspectos ms reseables de este metamodelo son: el elemento raz es la metaclase TraceModel; al igual que suceda con la implementacin de los metamodelos PIM y PSM, para conocer la ubicacin fsica de los modelos origen y destino, se incluye un atributo path (en la metaclase Model) que almacena esta informacin; finalmente, para poder acceder a los elementos trazados, se ha incluido un atributo ref (metaclase TraceElement) que almacena el identificador XMI de cada elemento trazado.

Solucin Tecnolgica 177

Figura 5-6. Metamodelo de Trazabilidad (Modelo Ecore)

178

lvaro Jimnez Rielo

5.3.2

Implementacin de Editores y Visualizadores de modelos

A partir de la sintaxis abstracta de un DSL, recogida en su metamodelo, EMF permite generar un editor genrico de tipo rbol con funcionalidades bsicas, para interactuar con modelos conformes a dicho metamodelo. Para obtener este editor en forma de rbol, el primer paso consiste en la creacin del modelo generador (GenModel) a partir del modelo base (Ecore). La mayor parte de la informacin necesaria para generar el editor tree-like se encuentra almacenada en el modelo Ecore (clases, atributos, referencias, cardinalidades, etc.). Sin embargo, algunos datos necesarios para alimentar a las plantillas JETs (Java Emitter Templates) que generan el cdigo fuente del editor, como por ejemplo la ubicacin del cdigo o la forma de generarlo, es necesario definirlos de forma externa al modelo Ecore. As, el modelo generador (GenModel) contiene referencias a los elementos del modelo Ecore para conocer la sintaxis abstracta del DSL (como muestra la Figura 5-7) y toda la informacin requerida por las plantillas JETs para generar el editor en forma de rbol [42, 85, 194].
Modelo GenModel Modelo Ecore

GenClass

EClass

GenFeature

GenFeature

EAttribute

EAttribute

Figura 5-7. Relacin entre los modelos GenModel y Ecore

La principal ventaja de la separacin entre los modelos Ecore y GenModel es que el modelo Ecore permanece independiente de cualquier informacin que slo es relevante para la generacin de cdigo. En cambio, la desventaja principal es que el modelo generador puede desincronizarse si las referencias al modelo cambian. Para evitar este problema, las clases del modelo generador incluyen mtodos que propagan los cambios desde el modelo base (Ecore) al modelo

Solucin Tecnolgica 179

generador (GenModel). El uso de estos mtodos asegura que los dos archivos se mantengan sincronizados. A partir del modelo Genmodel, EMF genera cdigo Java que se estructura en tres proyectos: el cdigo del modelo (model), el cdigo de edicin (edit) y el cdigo del editor (editor). Adems, se puede generar cdigo para los casos de pruebas (test).
GenModel
Traceability.ecore

Ecore Ecore Model Model

EMF Generation
(JET Templates)

conformsTo

Java Model

Java Edit

Java Editor

uses
MyModel.mtrace

Figura 5-8. Vista general de la Generacin de Editores EMF

Como muestra la Figura 5-8, estos proyectos de cdigo Java se encuentran relacionados entre s. Concretamente, el paquete model (contenido en el proyecto que contiene el metamodelo del DSL) permite acceder programticamente al metamodelo, crear modelos conformes a dicho metamodelo y llevar a cabo la serializacin de los mismos. Dicho paquete es usado por los proyectos edit y editor que implementan la funcionalidad relacionada con la interfaz de usuario. En otras palabras, el paquete model proporciona la lgica del DSL y los proyectos edit y editor contienen el cdigo Java que implementa el editor en forma de rbol que proporciona EMF. En la Figura 5-9 se muestra, a modo de ejemplo, el editor en forma de rbol generado con EMF a partir del modelo Ecore de trazabilidad (seccin 5.3.1.4). Se trata de un editor completo, sencillo y funcional. Sin embargo como se puede observar, no ofrece una visualizacin ptima para los modelos de trazas ya que no proporciona una representacin adaptada a la naturaleza relacional de estos modelos, es decir, los elementos de las trazas son mostrados como hijos y no

180

lvaro Jimnez Rielo

como origen o destino de las mismas. Este inconveniente se produce no solo en el DSL de trazabilidad sino en todos los DSL que componen MeTAGeM-Trace.

Figura 5-9. Ejemplo editor en forma del rbol (EMF)

En este punto conviene destacar que entre las limitaciones encontradas en el estado del arte presentado en el Captulo 3, se identific la necesidad de disponer de visualizadores especficos para representar los modelos de transformacin y los modelos de trazas, teniendo en cuenta las caractersticas propias de estos tipos de modelos. Entre las propuestas analizadas en el estado del arte, en diversos estudios ([17, 36, 58, 87, 128, 219]) se sugera o propona el empleo de editores multipanel como los proporcionados por las herramientas AMW y ModeLink. Este tipo de editores permite mostrar al mismo tiempo varios modelos y un modelo que contiene las relaciones entre los anteriores. Sin embargo, ambos editores tambin presentan algunas limitaciones. El editor ModeLink, que pertenece al proyecto Epsilon, tan solo permite la definicin de dos o tres paneles, es decir solo es posible visualizar el modelo de relaciones y como mximo dos modelos relacionados (un modelo origen y un modelo destino).

Solucin Tecnolgica 181

En cuanto al editor proporcionado por la herramienta AMW, destacan dos inconvenientes para su uso en el contexto de MeTAGeM-Trace. El primero de ellos ya se ha mencionado anteriormente y es que por motivos de compatibilidad, se ha decidido no emplear AMW en la construccin de la herramienta MeTAGeM-Trace y el segundo se corresponde con el editor en s mismo. Dado que se trata de un editor genrico, no establece la diferencia entre modelos origen y destino y por ello, los modelos relacionados no se organizan de forma adecuada en el editor. En particular, la organizacin de los modelos en el editor AMW es la siguiente: primer modelo relacionado, modelo de relaciones, resto de modelos relacionados. As, como muestra la Figura 5-10, si se tienen tres modelos origen y dos destino, es posible que la apariencia visual haga pensar al usuario que se trata de un modelo origen y cuatro destino (organizacin de los modelos en el editor: origen1, relaciones, origen2, origen3, destino1 y destino2).

Weaving Model

Source Models

Target Models

Figura 5-10. Organizacin de modelos en el editor AMW

Por ello, una de las contribuciones de esta tesis doctoral es el desarrollo de editores/visualizadores especficos para los modelos de transformacin y modelos de trazas. Por lo que, a partir del estudio y observacin de los editores multipanel proporcionados por las herramientas anteriores, MeTAGeM-Trace propone el uso de editores/visualizadores que tengan una estructura similar a la mostrada en la Figura 5-11 y las siguientes caractersticas: Tres paneles para mostrar de forma separada los modelos origen, el modelo de relaciones y los modelos destino. Si coexisten varios modelos origen o varios modelos destino, estos se organizarn verticalmente en el panel correspondiente. El usuario tiene la posibilidad de arrastrar objetos desde los modelos origen y destino al modelo de relaciones para facilitar la construccin del mismo. Si el usuario selecciona una relacin, automticamente se muestran los elementos implicados en dicha relacin en sus modelos correspondientes.

182

lvaro Jimnez Rielo

Si el usuario selecciona un elemento de los modelos origen o destino, el editor muestra automticamente las relaciones en las que participa el elemento seleccionado.

Modelos Origen
Modelo O1: -Elemento1 -Elemento2 -ElementoN Modelo O2: -Elemento1 -Elemento2 -ElementoN Modelo O3: -Elemento1 -Elemento2 -ElementoN

Modelo de Relaciones
Modelo de Relaciones: - Relacin_e1-e1 -FROM: e1:O1 -TO: e1:D1 - Relacin_e2,e2-e2 -FROM: e2:O2 -FROM: e2:O3 -TO: e2:D2

Modelos Destino
Modelo D1: -Elemento1 -Elemento2 -ElementoN Modelo D2: -Elemento1 -Elemento2 -ElementoN

- RelacinN

Figura 5-11. Esbozo de la estructura de los editores/visualizadores multipanel

La siguiente sub-seccin, detalla el proceso de implementacin de los editores incluidos en la herramienta MeTAGeM-Trace. Dado que este tipo de editores se emplean para la visualizacin de los modelos a nivel PIM y PSM y para la visualizacin de los modelos de trazas, se detalla tan solo la implementacin de uno de ellos. En concreto, se describen los pasos seguidos para la implementacin del editor multipanel para la representacin de los modelos de trazas. 5.3.2.1 Editor multipanel para modelos de trazabilidad El primer paso en la construccin de un editor multipanel es llevar a cabo el desarrollo del editor en forma de rbol que proporciona EMF y que sirve como base para la implementacin de este nuevo editor. Para la construccin del editor en forma de rbol es necesario generar el modelo GenModel a partir del modelo Ecore y posteriormente, mediante el men contextual del elemento raz del modelo generador, seleccionar la opcin Generate All (para generar al mismo tiempo los paquetes de cdigo model, edit, editor y test). Dado que el editor en forma de rbol se genera como parte del proceso, se ha decidido no prescindir de l, sino ofrecerlo como otra alternativa al editor

Solucin Tecnolgica 183

multipanel. En otras palabras, MeTAGeM-Trace ofrece dos editores para el manejo y visualizacin de modelos terminales conformes a los DSLs construidos: un editor en forma de rbol y un editor multipanel . Para ofrecer esta doble funcionalidad, en el fichero plugin.xml del proyecto editor se crea un nuevo editor en la pestaa extensions, como muestra la Figura 5-12. El editor EMF Model Editor es el editor por defecto que proporciona EMF al generar el editor en forma de rbol. El atributo class define la clase que implementa el editor. En este caso, se trata de la clase TraceabilityEditor. Para crear el nuevo editor de trazas se duplica dicha clase, que se encuentra en el proyecto de cdigo editor, y se renombra como TraceabilityEditorTrace.
(a)

(b)

Figura 5-12. Creando extensiones tipo editor

En este punto, es posible definir el editor que se desea establecer por defecto. En este caso, se ha decidido que el editor por defecto de los modelos de trazas sea el editor multipanel. Para ello, en el editor EMF Model Editor, el atributo default tomar valor false y en el editor Traceability Model Editor tomar valor true. En este momento de la implementacin se dispone de dos editores con distinto nombre pero exactamente la misma funcionalidad. Para dotar al editor multipanel de la funcionalidad deseada, se modifica el cdigo Java que lo implementa.

184

lvaro Jimnez Rielo

5.3.2.1.1

Modificando la informacin a mostrar en el editor

Dado que los modelos origen y destino originales se mostrarn en los paneles izquierdo y derecho, se ha decidido que este editor no muestre en el modelo de relaciones los elementos que representan a los modelos origen y destino (SourceModel y TargetModel) ni que permita definir nuevos modelos origen o destino. Para ello, en el proyecto edit se duplica la clase que representa al nodo raz del metamodelo, TraceModelItemProvider, y se renombra (TraceModelItemProviderTrace). Estas clases se corresponden con los editores en forma de rbol y multipanel, respectivamente. En la clase correspondiente al editor multipanel, se modifica el mtodo getChildrenFeatures() con el objetivo de eliminar o comentar las lneas de cdigo que permiten la visualizacin de los elementos de tipo SourceModel y TargetModel (Figura 5-13). Es necesario destacar que todos los mtodos modificados manualmente deben incluir la etiqueta @NOT generated para evitar que sean reescritos en posteriores generaciones de cdigo a partir del modelo GenModel.
/** * This specifies how to implement {@link #getChildren} and is used to deduce an appropriate feature for an * {@link org.eclipse.emf.edit.command.AddCommand}, {@link org.eclipse.emf.edit.command.RemoveCommand} or * {@link org.eclipse.emf.edit.command.MoveCommand} in {@link #createCommand}. * <!-- begin-user-doc --> * <!-- end-user-doc --> * @NOT generated */ @Override public Collection<? extends EStructuralFeature> getChildrenFeatures(Object object) { if (childrenFeatures == null) { super.getChildrenFeatures(object); childrenFeatures.add(TraceabilityPackage.Literals.TRACE_MODEL__TRACE_LINKS); // To avoid showing models in traceability editor //childrenFeatures.add(TraceabilityPackage.Literals.TRACE_MODEL__SOURCE_MODELS); //childrenFeatures.add(TraceabilityPackage.Literals.TRACE_MODEL__TARGET_MODELS); } return childrenFeatures; }

Figura 5-13. Mtodo getChildrenFeatures modificado

Dado que en el modelo de trazas no se representarn los modelos origen y destino, no parece tener sentido permitir la creacin de estos elementos en el contexto de esta representacin. Por ello, para eliminar esta funcionalidad se modifica el mtodo collectNewChildDescriptors(). Al igual que en el caso anterior, como muestra la Figura 5-14, se procede a eliminar o comentar las lneas de cdigo correspondientes a la creacin de los modelos origen y destino. Una vez que se han modificado estos mtodos, dado que anteriormente se ha duplicado la clase en la que se implementan, es necesario duplicar la clase que

Solucin Tecnolgica 185

invoca a dichos mtodos. Por ello, en el mismo proyecto edit se duplica la clase TraceabilityItemProviderAdapterFactory y esta se renombra a TraceabilityItemProviderAdapterFactoryTrace. Adems, en esta nueva clase se modifican las llamadas a TraceModelItemProvider por TraceModelItemProviderTrace. A continuacin, en la clase TraceabilityEditorTrace del proyecto editor, se modifica el mtodo initializeEditingDomain(), sustituyendo new TraceabilityItemProviderAdapterFactory() por new TraceabilityItemProviderAdapterFactoryTrace().
protected void collectNewChildDescriptors(Collection<Object> newChildDescriptors, Object object) { super.collectNewChildDescriptors(newChildDescriptors, object); newChildDescriptors.add(createChildParameter (TraceabilityPackage.Literals.TRACE_MODEL__TRACE_LINKS, TraceabilityFactory.eINSTANCE.createTraceLink())); //To hide model creation in traceability editor: //newChildDescriptors.add(createChildParameter //(TraceabilityPackage.Literals.TRACE_MODEL__SOURCE_MODELS, //TraceabilityFactory.eINSTANCE.createInModel())); //newChildDescriptors.add(createChildParameter //(TraceabilityPackage.Literals.TRACE_MODEL__TARGET_MODELS, //TraceabilityFactory.eINSTANCE.createOutModel())); } }

Figura 5-14. Mtodo collectNewChildDescriptors modificado

En este punto, se dispone de dos editores que muestran diferente informacin pero que mantienen la estructura del editor en forma de rbol. 5.3.2.1.2 Estructura de los paneles

El siguiente paso consiste en modificar el cdigo que implementa el nuevo editor (proyecto editor) para que tenga una apariencia similar a la estructura mostrada anteriormente en la Figura 5-11. En primer lugar, se ha creado una clase Actions que contiene un conjunto de mtodos estticos para llevar a cabo tareas comunes como obtener el nombre del modelo de trazas, obtener los modelos origen y los modelos destino, registrar un metamodelo cualquiera, etc. El cdigo de dichos mtodos se encuentra en el CD que acompaa a esta tesis doctoral.

186

lvaro Jimnez Rielo

A continuacin, se modifica la clase TraceabilityEditorTrace que implementa la apariencia y funcionalidad del editor multipanel de trazas. En primer lugar, se aaden a dicha clase los atributos mostrados en la Figura 5-15:
protected protected protected protected protected ResourceSet sourceRs; ResourceSet targetRs; TreeViewer sourceViewer; TreeViewer traceabilityViewer; TreeViewer targetViewer;

Figura 5-15. Atributos aadidos a la clase TraceabilityEditorTrace

Posteriormente, se modifican (o crean) los siguientes mtodos de la clase: createPages() createContextMenuFor() handleContentOutlineSelection() handleContentTraceabilitySelection() handleContentSourceSelection() handleContentTargetSelection ()

El mtodo createPages() contiene el cdigo que implementa la apariencia del editor. Sobre este mtodo se llevan a cabo las siguientes tareas: 1. En primer lugar, tras la llamada que invoca al mtodo createModel(), se aaden las lneas de cdigo que establecen la forma del contenedor y cargan los modelos origen y destino como recursos:
createModel(); Composite container = getContainer(); final SashForm topSashForm = new SashForm(container,SWT.HORIZONTAL);

// Only creates the other pages if there is something that can be edited if (!getEditingDomain().getResourceSet().getResources().isEmpty()) { ArrayList<SourceModelImpl> sources = Actions.getSourceModels(getEditingDomain().getResourceSet()); ArrayList<TargetModelImpl> targets = Actions.getTargetModels(getEditingDomain().getResourceSet());

Figura 5-16. Estableciendo la forma del contenedor y cargando los modelos origen y destino en el editor multipanel

2. El siguiente paso consiste en eliminar los visores (viewers) existentes en el mtodo y crear visores para los modelos origen y destino. La Figura 5-17

Solucin Tecnolgica 187

muestra el cdigo que implementa el visor para los modelos origen. La implementacin del visor destino es muy similar.
// Create view for sources models. ViewerPane viewerPane = new ViewerPane(getSite().getPage(),TraceabilityEditorTrace2.this) { @Override public Viewer createViewer(Composite composite) { Tree tree = new Tree(composite, SWT.MULTI); TreeViewer newTreeViewer = new TreeViewer(tree); return newTreeViewer; } @Override public void requestActivation() { super.requestActivation(); setCurrentViewerPane(this); } }; viewerPane.createControl(topSashForm); sourceViewer=(TreeViewer)viewerPane.getViewer(); sourceViewer.setContentProvider(new AdapterFactoryContentProvider(adapterFactory)); sourceViewer.setLabelProvider(new AdapterFactoryLabelProvider(adapterFactory)); Transfer[] transfers = new Transfer[] { LocalTransfer.getInstance() }; sourceViewer.addDragSupport(DND.DROP_LINK , transfers, new ViewerDragAdapter(sourceViewer)); for(int i=0;i<sources.size();i++){ if (sources.get(i).getMetamodel() != null) { //If metamodel attribute is not null if (!sources.get(i).getMetamodel().equals("")) { //If metamodel is not empty String metamodelRegistered = Actions.registerMetamodel( sources.get(i).getMetamodel(), sources.get(i).getName()); sources.get(i).setMetamodel(metamodelRegistered); } } } sourceRs= Actions.createResourceSet_Sources(sources); Actions.setSourceModels(getEditingDomain().getResourceSet(),sources); sourceViewer.setInput(sourceRs); sourceViewer.setSelection(new StructuredSelection(sourceRs.getResources().get(0)), true); viewerPane.setTitle("Source Models"); sourceViewer.addSelectionChangedListener (new ISelectionChangedListener() { // This ensures that we handle selections correctly. public void selectionChanged(SelectionChangedEvent event) { handleContentSourceSelection(event.getSelection()); } }); new AdapterFactoryTreeEditor(sourceViewer.getTree(), adapterFactory); //To show the contextual menu (disabled for input and output models) //createContextMenuFor(inputViewer.get(i));

Figura 5-17. Cdigo que implementa el visor de los modelos origen

3. Por ltimo, se crea el visor para el modelo de trazas. Su implementacin, que se muestra en la Figura 5-18, es similar a los visores para los modelos origen y destino, pero contiene modificaciones relevantes. Por ejemplo, a diferencia de los otros visores, no requiere registrar ningn metamodelo.

188

lvaro Jimnez Rielo

viewerPane2.createControl(topSashForm); traceabilityViewer = (TreeViewer) viewerPane2.getViewer(); traceabilityViewer.addDragSupport(DND.DROP_COPY | DND.DROP_LINK, transfers, new ViewerDragAdapter(traceabilityViewer)); traceabilityViewer.setContentProvider( new AdapterFactoryContentProvider(adapterFactory)); traceabilityViewer.setLabelProvider( new AdapterFactoryLabelProvider(adapterFactory)); traceabilityViewer.setInput(editingDomain.getResourceSet()); traceabilityViewer.setSelection( new StructuredSelection(editingDomain.getResourceSet().getResources().get(0)), true); viewerPane2.setTitle("Traceability Model",Actions.getImage("TraceModel")); traceabilityViewer.addSelectionChangedListener( new ISelectionChangedListener() { public void selectionChanged(SelectionChangedEvent event) { handleContentTraceabilitySelection(event.getSelection()); } }); new AdapterFactoryTreeEditor(traceabilityViewer.getTree(),adapterFactory); createContextMenuFor(traceabilityViewer);

Figura 5-18. Cdigo que implementa el visor del modelo de Trazas

El mtodo createContextMenuFor() es el encargado de crear el men contextual de los visores y de registrar las operaciones permitidas en dicho visor. Dado que en la implementacin de cada visor, se han definido las acciones permitidas, en este mtodo se suprimen las lneas de cdigo mostradas en la Figura 5-19.
int dndOperations = DND.DROP_COPY | DND.DROP_MOVE | DND.DROP_LINK; Transfer[] transfers = new Transfer[] { LocalTransfer.getInstance() }; viewer.addDragSupport(dndOperations, transfers, new ViewerDragAdapter(viewer)); viewer.addDropSupport(dndOperations, transfers, new EditingDomainViewerDropAdapter(editingDomain, viewer));

Figura 5-19. Lneas a suprimir en el mtodo createContextMenuFor

En este punto, el editor multipanel ya tiene la estructura deseada, es decir, tres paneles: modelos origen, modelo de trazas y modelos destino. El siguiente paso es interconectar dichos paneles para permitir que el usuario seleccione una traza y automticamente se identifiquen los elementos trazados en los modelos origen y destino y viceversa: que al seleccionar un elemento de los modelos, se resalten todas las trazas en las que participa dicho elemento. 5.3.2.1.3 Identificacin automtica de los elementos seleccionados

El mtodo handleContentOutlineSelection() se encarga de mostrar en el panel del modelo de trazas el elemento seleccionado en la ventana Outline del entorno Eclipse. Para que este mtodo solo afecte al panel del modelo de trazas, es necesario eliminar o comentar las lneas de cdigo que aparecen en negrita en la Figura 5-20.

Solucin Tecnolgica 189

public void handleContentOutlineSelection(ISelection selection) { if (currentViewerPane != null && !selection.isEmpty() && selection instanceof IStructuredSelection) { Iterator<?> selectedElements = ((IStructuredSelection)selection).iterator(); if (selectedElements.hasNext()) { // Get the first selected element. Object selectedElement = selectedElements.next(); // If it's the selection viewer, then we want it to select the same selection as this selection. //if (currentViewerPane.getViewer() == selectionViewer) { ArrayList<Object> selectionList = new ArrayList<Object>(); selectionList.add(selectedElement); while (selectedElements.hasNext()) { selectionList.add(selectedElements.next()); } // Set the selection to the widget. selectionViewer.setSelection(new StructuredSelection(selectionList)); //} //else { // Set the input to the widget. // // if (currentViewerPane.getViewer().getInput() != selectedElement) { // currentViewerPane.getViewer().setInput(selectedElement); // currentViewerPane.setTitle(selectedElement); // } //} } } }

Figura 5-20. Mtodo handleContentOutlineSelection

Y adems, modificar la siguiente lnea de cdigo:

// Set the selection to the widget. selectionViewer.setSelection(new StructuredSelection(selectionList));

// Set the selection to the widget. traceabilityViewer.setSelection(new StructuredSelection(selectionList));

Figura 5-21. Estableciendo el visor en el que se resalta la seleccin

De forma similar al mtodo handleContentOutlineSelection(), se implementan los mtodos que se encargan de mostrar las relaciones entre las trazas y los elementos que forman parte de ellas. As, se crea handleContentTraceabilitySelection(), el mtodo que se invoca cuando el usuario selecciona una traza (TraceLink) o un elemento implicado en una traza (SourceElement o TargetElement). Cuando se selecciona un elemento de tipo SourceElement, el mtodo busca su identificador (almacenado en el atributo ref) en los elementos de los modelos origen y si es encontrado, se resalta el elemento coincidente. Para los elementos de tipo TargetElement, realiza la misma funcin pero buscando entre los modelos destino. Y en el caso de seleccionar un elemento de tipo TraceLink, combina las funcionalidades anteriores, buscando las referencias de los elementos participantes en la traza entre todos los modelos origen y destino del modelo de trazas.

190

lvaro Jimnez Rielo

Cuando el usuario selecciona un elemento de un modelo origen o destino, se invocan los mtodos handleContentSourceSelection() y handleContentTargetSelection(), respectivamente. Estos mtodos se encargan de obtener el identificador del elemento seleccionado para buscar coincidencias entre los elementos de las trazas y de este modo, identificar las trazas en las que participa dicho elemento. En este punto, el editor multipanel de trazabilidad ya muestra el modelo de trazabilidad, a su izquierda los modelos origen y a su derecha los modelos destino. Adems, seleccionando un elemento (origen o destino) nos muestra todas las trazas en las que se encuentra implicado. En el caso de seleccionar una traza se muestran todos los elementos que forman parte de ella. 5.3.2.1.4 Funcionalidad Drag&Drop

En ltimo lugar, solo queda implementar la funcionalidad conocida como drag&drop [63], que permite al usuario arrastrar un elemento de los modelos origen y destino sobre una traza del modelo de trazas para establecer dicho elemento como elemento origen o destino (segn corresponda) de la traza sobre la que es arrastrado. Para soportar esta funcionalidad se crea una nueva clase (TraceabilityDragDrop) en el proyecto editor. Esta nueva clase debe extender la clase EditingDomainViewerDropAdapter. Su constructor recibe el dominio, el visor, el conjunto de recursos origen (modelos origen) y el conjunto de recursos destino (modelos destino). Esta clase contiene los siguientes mtodos: Helper(): recibe el evento drag&drop e identifica el elemento arrastrado (source) y el elemento sobre el cual ha sido arrastrado (target). A partir del source, determina si el evento se corresponde con un elemento de un modelo origen o de un modelo destino (atributo selectionType). drop(): recibe el evento drop y a partir del atributo selectionType (mtodo helper()), evala si la accin se debe ejecutar(si el elemento selectionType es de tipo SOURCE_ELEMENT o TARGET_ELEMENT) o si por el contrario, se debe descartar. createTraceElement(): recibe el elemento arrastrado, la traza que lo recibe y el tipo de elemento arrastrado (Source o Target). Comprueba si el elemento arrastrado sobre la traza es de tipo source o target y dependiendo de esta informacin realiza una llamada al mtodo

Solucin Tecnolgica 191

handleSetSourceElement() respectivamente.

handleSetTargetElement(),

handleSetSourceElement(): aade el elemento arrastrado a la traza como elemento origen. handleSetTargetElement(): igual que el mtodo anterior, pero en este caso para elementos de tipo destino. Una vez que se ha creado la clase TraceabilityDragDrop es necesario instanciarla desde el mtodo createPages() de la clase TraceabilityEditorTrace del proyecto editor, justo despus del cdigo que implementa el visor del panel de trazabilidad. La instanciacin de esta clase se muestra en la Figura 5-22.
TraceabilityDragDrop dragdrop=new TraceabilityDragDrop( getEditingDomain(),traceabilityViewer, this.sourceRs, this.targetRs); traceabilityViewer.addDropSupport( DND.DROP_COPY | DND.DROP_LINK, transfers, dragdrop);

Figura 5-22. Instanciando la clase TraceabilityDragDrop

Tras seguir los pasos anteriores, el editor multipanel para el DSL de trazabilidad ya tiene la estructura y funcionalidad requerida. En la Figura 5-23 se muestra el editor, incluyendo la personalizacin de iconos que se muestra en la siguiente seccin.

Figura 5-23. Editor multipanel de Trazabilidad

192

lvaro Jimnez Rielo

5.3.2.2

Personalizacin de los editores Con el objetivo de mejorar la experiencia del usuario a la hora de usar estos editores, se ha llevado a cabo un conjunto de modificaciones. En esta seccin se presentan dichas mejoras. 5.3.2.2.1 Personalizacin de Iconos

Los editores creados con EMF (editor en forma de rbol y editor multipanel) representan cada elemento de un modelo con iconos genricos. As, una de las primeras mejoras realizadas para los editores de MeTAGeM-Trace es personalizar dichos iconos con imgenes representativas de cada elemento. Para ello, en primer lugar se ha seleccionado una imagen adecuada para cada elemento y luego se ha procedido a cambiar la imagen original por la seleccionada. A modo de ejemplo, la Figura 5-24(a) presenta un modelo conforme al metamodelo ETL antes de incluir los iconos personalizados y la Figura 5-24(b) muestra el mismo modelo, una vez que se han incluido.

(a)

(b)

Figura 5-24. Modelo ETL: (a) iconos genricos; (b) iconos personalizados

5.3.2.2.2

Actualizacin de mens despegables en tiempo de ejecucin

En los metamodelos de los DSLs que componen la herramienta MeTAGeM-Trace, existen algunas referencias con cardinalidad 0..1. En tiempo de ejecucin, dichas referencias resultan, en mens despegables en los que el usuario puede elegir una opcin entre todos los objetos que se encuentren en el modelo y sean del tipo que indica la referencia. Sin embargo, en muchas ocasiones, no es

Solucin Tecnolgica 193

correcto permitir asociaciones con cualquier instancia de ese tipo, sino que solo tiene sentido con algunas de ellas. A modo de ejemplo, la metaclase RelationElement del metamodelo MeTAGeM (nivel PIM) contiene una referencia (belongsTo), cuyo destino es la propia metaclase. Esta referencia sirve para representar que un elemento de una relacin de transformacin (generalmente, un atributo) pertenece a otro. En la Figura 5-25, se muestra una relacin de transformacin entre un elemento padre (Father) y un elemento hombre (male) que adems contiene una subrelacin en la que se crea el nombre (fullname) del elemento destino. En tal caso, no tiene sentido poder indicar que el atributo fullname destino pertenece a cualquier elemento (Figura 5-25 (a)) sino que, como muestra la Figura 5-25(b), solo tiene cabida la relacin con el elemento destino Male.

(a)

(b)

Figura 5-25. Modelo MeTAGeM: (a) todas las instancias disponibles; (b) valores actualizados en tiempo de ejecucin

Para ofrecer esta funcionalidad en tiempo de ejecucin, se debe modificar la clase XXXItemProvider del proyecto edit, siendo XXX el nombre de la metaclase que contiene la relacin (en este caso, RelationElement). En dicha clase, se debe modificar el mtodo addYYYPropertyDescriptor(), siendo YYY el nombre de la referencia (en este caso, belongsTo). Por defecto, dicho mtodo incluir en los posibles valores del men desplegable todas aquellas instancias del tipo destino de la referencia. Para mostrar los valores deseados, dicho mtodo debe implementar el cdigo mostrado en la Figura 5-26, donde el mtodo getChoiceOfValues()debe devolver la coleccin de los elementos que aparecern en la lista de opciones del men.

194

lvaro Jimnez Rielo

/** * This adds a property descriptor for the Belongs To feature. * <!-- begin-user-doc --> * <!-- end-user-doc --> * @NOT generated */ protected void addBelongsToPropertyDescriptor(Object object) { itemPropertyDescriptors.add (new ItemPropertyDescriptor( ((ComposeableAdapterFactory)adapterFactory).getRootAdapterFactory(), getResourceLocator(), getString("_UI_RelationElement_belongsTo_feature"), getString("_UI_PropertyDescriptor_description", "_UI_RelationElement_belongsTo_feature", "_UI_RelationElement_type"), MetagemPackage.Literals.RELATION_ELEMENT__BELONGS_TO, true, false, true, null, null, null) { @Override public Collection<?> getChoiceOfValues(Object object) { Collection<Object> result = new ArrayList<Object>(); result.add(null); //Se seleccionan los elementos adecuados y se insertan en la //collection result [...] return result; } @Override public void resetPropertyValue(Object object) { setPropertyValue(object, null); } }); }

Figura 5-26. Cdigo Java para actualizacin automtica de los mens desplegables de las referencias

Esta funcionalidad de actualizacin automtica en tiempo de ejecucin de los valores de los mens desplegables ha sido implementada en todas aquellas referencias de todos los DSLs de MeTAGeM-Trace cuyas caractersticas coinciden con las mencionadas en esta seccin. 5.3.2.2.3 Establecimiento automtico de relaciones

En el modelado de la transformacin y de las relaciones de trazabilidad a nivel PSM (modelo de aproximacin hbrida), el usuario tiene la posibilidad de crear o modificar las reglas de transformacin y las relaciones de trazabilidad. Como se muestra en la seccin 4.2.3, ambos tipos de elementos se encuentran muy relacionados, ya que una regla de transformacin puede contener a una relacin de

Solucin Tecnolgica 195

trazabilidad (TraceRule). En consecuencia, los elementos origen y destino de dicha relacin de trazabilidad se corresponden con los elementos origen y destino de la regla de transformacin. Lo mismo sucede con los elementos Binding y las relaciones de trazabilidad de tipo TraceBinding. Para facilitar al usuario la construccin del modelo PSM, cada vez que se crea o aade una relacin de trazabilidad dentro de una regla de transformacin, los elementos origen y destino de la regla se asocian automticamente a la relacin de trazabilidad. Para implementar esta funcionalidad, se han modificado las clases Java que implementan los elementos Rule y Binding del paquete hybrid.impl (BindingImpl y RuleImpl, respectivamente), del proyecto Hybrid. En dichas clases se han modificado los mtodos getLeft() y getRight() en el caso de la clase BindingImpl y getSources() y getTargets() en la clase RuleImpl, de forma que, como muestra la Figura 5-27, cada vez que se invoquen estos mtodos se actualicen los elementos origen y destino de las relaciones de trazabilidad contenidas en la regla o relacionadas con el binding.
/** * <!-- begin-user-doc --> * <!-- end-user-doc --> * @NOT generated */ public EList<Source> getSources() { if (sources == null) { sources = new EObjectContainmentWithInverseEList<Source>( Source.class, this, HybridPackage.RULE__SOURCES, HybridPackage.SOURCE__RULE); } //Update TraceRule Sources TraceRule traceRule = this.getTrace(); if(traceRule!=null){ for(int i=0;i<sources.size();i++){ if(!traceRule.getSource().contains(sources.get(i))){ traceRule.getSource().add(sources.get(i)); } } } }

Figura 5-27. Cdigo que implementa la actualizacin automtica de los elementos de las relaciones de trazabilidad

Conviene destacar que dichos mtodos se invocan cada vez que se carga el modelo o se selecciona un elemento de este tipo, por tanto los elementos de la relacin de trazabilidad se actualizan continuamente.

196

lvaro Jimnez Rielo

5.3.3

Implementacin de Asistentes de Creacin de modelos

EMF proporciona un asistente de creacin por defecto para la creacin de nuevos modelos. En dicho asistente, el usuario debe elegir la ubicacin fsica y el nombre del fichero que contendr el modelo y cul ser el elemento raz de dicho modelo (generalmente debe coincidir con el elemento raz del metamodelo al que es conforme el nuevo modelo). Sin embargo, estos asistentes de creacin son demasiado bsicos y genricos. Adems, dado que en la implementacin de los editores multipanel se ha eliminado la visualizacin y creacin de los elementos que representan a los modelos origen y destino, es deseable especificar: en el caso de los modelos de transformacin, qu metamodelos intervienen como origen o destino de la transformacin; y en el caso de los modelos de trazas, qu modelos y metamodelos participan en el modelo de trazas. Por todo ello, MeTAGeM-Trace incluye varios asistentes de creacin para los modelos de transformacin a nivel PIM y PSM y para los modelos de trazas. En este punto, conviene mencionar que, aunque el proceso propuesto por MeTAGeM-Trace permita la generacin (semi-)automtica de los modelos PSM y los modelos de trazas, el usuario tambin tiene la posibilidad de crearlos manualmente. En la Figura 5-28 se muestra parte del asistente para la creacin de nuevos modelos de trazas. En concreto, se muestra la forma en la que permite aadir nuevos modelos origen. En la siguiente sub-seccin, se presenta la implementacin de dicho asistente.

Figura 5-28. Asistente de creacin de modelos de Trazas

Solucin Tecnolgica 197

5.3.3.1

Implementacin del Asistente para la creacin de modelos de Trazas Como ya se ha comentado anteriormente, EMF proporciona por defecto un asistente (wizard) para la creacin de nuevos modelos. En esta seccin se muestra cmo modificar dicho asistente para adaptarlo a las caractersticas deseadas. 5.3.3.1.1 Modificando la extensin org.eclipse.ui.newWizards

Para la definicin del asistente de creacin por defecto, EMF define una extensin de tipo org.eclipse.ui.newWizards en el fichero plugin.xml ubicado en el proyecto editor del DSL. En dicha extensin, como muestra la Figura 5-29, se pueden definir caractersticas del asistente de creacin como el identificador, el nombre, el icono, la clase que lo implementa o la categora en la que se insertar, entre otros.

Figura 5-29. Extensin org.eclipse.ui.newWizards

En la Figura 5-29 se han resaltado dos parmetros de la extensin: class y category. El primero de ellos corresponde a la clase Java que implementa el asistente y que por tanto se debe modificar para invocar al asistente deseado, como se detalla ms adelante. El parmetro category permite especificar la categora en la que se alojar el asistente de creacin. En este caso, se ha empleado una categora (org.eclipse.kybele.metagem.Wizard.category.ID), definida con el objetivo de agrupar a todos los asistentes de creacin incluidos en MeTAGeM-Trace. De este modo, el asistente de creacin para nuevos modelos de trazabilidad podr ser invocado como muestra la Figura 5-30.

198

lvaro Jimnez Rielo

Figura 5-30. Categora MeTAGeM para agrupar a los asistentes de creacin

5.3.3.1.2

Modificando el cdigo Java que implementa el asistente de creacin

La clase Java TraceabilityModelWizard es la encargada de implementar la apariencia y funcionalidad del asistente de creacin por defecto de EMF. A continuacin se muestran los cambios realizados sobre dicha clase para obtener el asistente deseado. En primer lugar, se procede a modificar algunos atributos de la clase. As, se elimina el atributo initialObjectCreationPage, ya que no ser necesario disponer de una pgina para la eleccin del elemento raz del modelo porque se definir de forma automtica. Por otro lado, el atributo newFileCreationPage es renombrado a modelsCreationPage con el objetivo de disponer de un nombre ms representativo . Tambin se han creado los atributos sourceModels y targetModels. Estos atributos son listas que contienen elementos ModelData, una clase creada especficamente para almacenar datos de modelos y metamodelos. En concreto, registra el nombre, la ruta y el metamodelo (en caso necesario) de cada modelo y adems, un atributo que permite conocer si dicha informacin corresponde a un modelo o a un metamodelo. Ms adelante se presenta la implementacin de esta clase.

Solucin Tecnolgica 199

El siguiente paso consiste en modificar los siguientes mtodos de la clase TraceabilityModelWizard: init(), createInitialModel() y addPages(). En el mtodo init() tan solo se aaden las sentencias de inicializacin de los atributos sourceModels y targetModels que muestra la Figura 5-31.
sourceModels = new ArrayList<ModelData>(); targetModels = new ArrayList<ModelData>();
Figura 5-31. Inicializando los atributos sourceModels y targetModels

El mtodo createInitialModel() es el encargado de obtener la raz del modelo a crear. En este caso, para evitar que el usuario tenga que seleccionarlo manualmente, se selecciona automticamente el elemento TraceModel como elemento raz de todos los modelos conformes al metamodelo de trazabilidad, tal como muestra la Figura 5-32.
protected EObject createInitialModel() { EClass eClass = (EClass)traceabilityPackage.getEClassifier("TraceModel"); EObject rootObject = traceabilityFactory.create(eClass); return rootObject; }

Figura 5-32. Mtodo createInitialModel modificado

Por ltimo, el mtodo addPages() tiene por objetivo crear y aadir cada una de las pginas del asistente, entendiendo por pginas cada una de las pantallas que forman el asistente. En este caso, se ha creado un asistente con dos pginas: una para seleccionar el nombre del nuevo modelo y su ubicacin fsica y otra para seleccionar los modelos origen y destino que intervienen en el modelo de trazas que se va a construir. Esta segunda pantalla se corresponde con la mostrada anteriormente en la Figura 5-28. La primera pgina es proporcionada por el asistente por defecto y dado que se estn realizando las modificaciones directamente sobre l, no es necesario modificar el cdigo que aade esta pgina. Para aadir la segunda, como muestra la Figura 5-33, es necesario comentar las lneas correspondientes a la pgina de eleccin de la raz del modelo (proporcionada por el asistente por defecto) y aadir el cdigo correspondiente a la nueva pantalla. Para ello, se crea una instancia de la clase TraceabilityModelWizardModelsCreationPage que contiene la implementacin de la nueva pgina, se define el texto del ttulo y descripcin de la pgina y por ltimo se aade al conjunto de pginas.

200

lvaro Jimnez Rielo

//initialObjectCreationPage = new //TraceabilityModelWizardInitialObjectCreationPage("Source Models"); //initialObjectCreationPage.setTitle( //TraceabilityEditorPlugin.INSTANCE.getString("_UI_TraceabilityModelWizard_label")); //initialObjectCreationPage.setDescription( //TraceabilityEditorPlugin.INSTANCE.getString("_UI_Wizard_initial_object_description")); //addPage(initialObjectCreationPage); modelsCreationPage = new TraceabilityModelWizardModelsCreationPage( "Models",sourceModels,targetModels); modelsCreationPage.setTitle(TraceabilityEditorPlugin.INSTANCE.getString( "_UI_TraceabilityModelWizard_label")); modelsCreationPage.setDescription(TraceabilityEditorPlugin.INSTANCE.getString( "_UI_Wizard_models_description")); addPage(modelsCreationPage);

Figura 5-33. Mtodo addPages() modificado

5.3.3.1.3

Clase TraceabilityModelWizardModelsCreationPage

Como se ha indicado anteriormente, la implementacin de la nueva pgina que se construye en el asistente para especificar los modelos origen y destino se incluye en la clase TraceabilityModelWizardModelsCreationPage, que ha sido implementada en el fichero TraceabilityModelWizard.java. El objetivo es disponer de una pgina en el asistente cuya apariencia sea la mostrada en la Figura 5-34.

Figura 5-34. Pantalla de seleccin de modelos (Asistente de creacin de modelos de Trazas)

Solucin Tecnolgica 201

La pgina de seleccin de modelos se compone de dos partes principales: una para los modelos origen y otra para los modelos destino. Cada una de ellas se compone de una tabla y de tres botones (add, edit, remove). Para crear y definir estos elementos se define un conjunto de atributos:
public abstract class TraceabilityModelWizardModelsCreationPage extends WizardPage { private private private private private private private private private private Button addSourceModel; Button editSourceModel; Button removeSourceModel; Button addTargetModel; Button editTargetModel; Button removeTargetModel; Table modelSourceTable; Table modelTargetTable; ArrayList<ModelData> sourceModels; ArrayList<ModelData> targetModels;

Figura 5-35. Atributos de TraceabilityModelWizardModelsCreationPage

Esta clase se compone bsicamente de un mtodo llamado createControl() que se encarga de definir los elementos que forman parte de la pgina del asistente y su comportamiento. Debido al tamao de este mtodo (ms de 200 lneas de cdigo) se invita al lector a consultarlo en el CD adjunto a esta tesis doctoral. Este mtodo permite al usuario especificar los modelos que participan en el modelo de trazas. Para ello, hace uso del manejador TraceabilityWizardHandleModel, que se explica a continuacin. 5.3.3.1.4 Clase TraceabilityWizardHandleModel

Esta clase ha sido implementada para ofrecer un manejador visual para especificar los modelos origen y destino que intervienen en un modelo de relaciones, en este caso, el modelo de trazas. Su implementacin consiste bsicamente, en la definicin de un conjunto de elementos visuales (cuadros de texto, botones, etiquetas, etc.). La Figura 5-36 muestra la ventana ofrecida al usuario para llevar a cabo estas tareas. Una vez que el usuario ha seleccionado correctamente un modelo origen o destino, segn corresponda, la informacin relativa a dicho modelo (nombre, ruta, metamodelo) es trasladada al mtodo createControl(), descrito anteriormente, para que se encargue de rellenar las tablas mostradas en la Figura 5-34.

202

lvaro Jimnez Rielo

Figura 5-36. Ventana de definicin de modelos participantes

5.3.3.1.5

Clase ModelData

Esta clase, implementada en el fichero de mismo nombre, permite almacenar informacin de un modelo (o metamodelo). En concreto, almacena su nombre, su ruta y la ruta de su metamodelo (en caso de ser un modelo). Adems, contiene un atributo de tipo booleano que indica si se trata un metamodelo. Ha sido creada, principalmente, con el objetivo de poder definir estructuras de datos que contengan al mismo tiempo toda la informacin relativa a los modelos. Esta clase se compone de los constructores de la clase, los mtodos set() para asignar un valor a estos atributos y los mtodos get() para obtener su valor.

5.3.4

Implementacin de Transformaciones de modelos

Hasta el momento se ha presentado la implementacin de los metamodelos de los DSLs que componen la herramienta MeTAGeM-Trace y los mecanismos para crear, editar y visualizar modelos conformes a dichos metamodelos. El siguiente paso es implementar el procesador de modelos (Figura 5-2). As, en esta seccin se presenta la implementacin de la actividad ms importante que soporta este procesador: las transformaciones de modelos que permiten conectar los DSLs que forman parte de la herramienta MeTAGeM-Trace. Dichas transformaciones han sido especificadas en lenguaje natural en la seccin 4.3. Todas las transformaciones de MeTAGeM-Trace han sido implementadas con el lenguaje de transformacin ATL. ATL proporciona un plug-in de Eclipse, que incluye un conjunto de funcionalidades que facilitan el desarrollo de las transformaciones de modelos (resaltado de sintaxis, depurador, editor, etc.). La sintaxis de ATL se basa en el estndar OCL y soporta la programacin declarativa e imperativa, es decir adopta una aproximacin hbrida, aunque sus autores recomiendan la aproximacin declarativa.

Solucin Tecnolgica 203

Una transformacin ATL se compone de un conjunto de reglas que definen las relaciones que deben satisfacerse entre los modelos origen y destino. As, cada regla especifica qu elementos deben crearse en el modelo destino (patrn destino) cuando se encuentren determinados elementos en el modelo origen (patrn origen). De esta forma, la ejecucin de una transformacin ATL consiste en navegar los modelos origen en busca de coincidencias con los patrones origen definidos en cada regla de la transformacin. Cuando se detecta una coincidencia o matching, se ejecuta la regla correspondiente, aadiendo al modelo destino los elementso especificados por el patrn destino de la regla. Las transformaciones ATL son unidireccionales, es decir, los modelos origen son de solo lectura y los modelos destino, de solo escritura. Por ello, durante la ejecucin de la transformacin, los modelos origen pueden ser navegados pero no modificados y los modelos destino son modificados, pero no navegados. Una de las ventajas de ATL es que soporta la herencia entre reglas y la invocacin implcita y explcita de las mismas. La invocacin implcita se corresponde con las construcciones declarativas, mientras que la invocacin explcita se soporta por medio de llamadas (o invocaciones) desde construcciones imperativas. Adems, al ser eminentemente declarativo, ATL no ofrece mecanismos para definir el orden en que deben ejecutarse las reglas (ntese que no es necesario precisamente por ser declarativo). No obstante, si permite especificar que ciertas reglas deben ejecutarse antes (para inicializar algn elemento necesario para el resto de la transformacin) o despus (para completar algn resultado parcial) de todas las dems reglas que componenen la transformacin. Estas reglas se denominan respectivamente entrypoint y endpoint. En las siguientes secciones, se muestra la implementacin de las transformaciones ATL incluidas en MeTAGeM-Trace. 5.3.4.1 Transformacin de modelos PIM a modelos PSM Esta seccin presenta la implementacin con el lenguaje ATL de las reglas de transformacin PIM-PSM, especificados en la Tabla 4-1. Esta transformacin se denomina MeTAGeM2Hybrid, debido al nombre de los metamodelos que participan en la transformacin. En la Figura 5-37 se muestra la cabecera de la transformacin, que define como origen un modelo conforme al metamodelo MeTAGeM (nivel PIM) y como destino un modelo conforme al metamodelo Hybrid (nivel PSM).

204

lvaro Jimnez Rielo

module MeTAGeM2Hybrid; create OUT : Hybrid from IN : MeTAGeM;

Figura 5-37. Cabecera Transformacin MeTAGeM2Hybrid

Una vez definida la cabecera de la transformacin, se aborda la implementacin de cada una de las reglas que la componen, que en este caso son 16 reglas tipo matched, 1 regla tipo lazy y 7 helpers. En esta seccin solo se presentan las reglas ms relevantes de la transformacin. En primer lugar, se codifica la regla que transforma elementos de tipo ModelRoot en elementos de tipo Module. Como muestra la Figura 5-38, en esta regla se mapea el nombre del mdulo de la transformacin a construir ( name) y las referencias a los modelos origen y destino y a las reglas de la dicha transformacin.
rule ModelRoot2Module { from mr: MeTAGeM!ModelRoot to m: Hybrid!Module ( name <- mr.name, sourceModels <- mr.sourceModels, targetModels <- mr.targetModels, rules <- mr.relations ) }

Figura 5-38. Regla ModelRoot2Module (Transformacin MeTAGeM2Hybrid)

A continuacin, se codifican las reglas que mapean los modelos origen (SourceModel) y destino (TargetModel) de la transformacin (Figura 5-39).

Solucin Tecnolgica 205

rule SourceModelTransf2SourceModel{ from smt: MeTAGeM!SourceModelTransf to sm: Hybrid!SourceModel( name <- smt.name+'_model', path <- smt.path, type_mm <- smt.name ) } rule TargetModelTransf2TargetModel{ from tmt: MeTAGeM!TargetModelTransf to tm: Hybrid!TargetModel( name <- tmt.name+'_model', path <- tmt.path, type_mm <- tmt.name ) }

Figura 5-39. Reglas de transformacin de los modelos origen y destino (Transformacin MeTAGeM2Hybrid)

El siguiente paso es implementar las reglas de transformacin que convierten las relaciones definidas a nivel PIM en reglas de transformacin y relaciones de trazabilidad, a nivel PSM. En este punto, conviene tener en cuenta que todas las metaclases que describen las relaciones a nivel PIM heredan de una misma metaclase abstracta. La principal diferencia entre los distintos tipos de relaciones es la cardinalidad que admiten sus atributos source y target, es decir el nmero de elementos participantes en la relacin. Por ello, se ha codificado una regla abstracta Relations2Rule (Figura 5-40), que es extendida por las reglas que mapean los distintos tipos de relaciones definidas. Dado que las relaciones pueden depender directamente de la raz del modelo o estar contenidas en otras relaciones, la regla Relations2Rule define una pre-condicin o guarda (relation.isNotIncluded()), de forma que solo consume relaciones dependientes de la raz del modelo, es decir no contenidas en otras relaciones. A partir de estos elementos, genera una regla de transformacin (Rule) y una relacin de trazabilidad (TraceRule) en el modelo destino, que se relacionan entre s mediante el atributo trace del elemento Rule.

206

lvaro Jimnez Rielo

abstract rule Relations2Rule{ from relation:MeTAGeM!Relations(relation.isNotIncluded()) to r_hybrid:Hybrid!Rule( name <- relation.getRuleName(), isAbstract <- relation.role=#IsAbstract, isMain <- relation.role=#IsMain, isUnique <- false,-- is the default value "extends" <- relation.extends, isExtended <- relation.isExtended, typeRelation <- relation.typeRelation, typeElement <- relation.typeElement, guard <- if relation.guardCondition.oclIsUndefined() then OclUndefined else thisModule.getGuard(relation) endif, trace <- trace_rule ), trace_rule: Hybrid!TraceRule( name <- relation.getRuleName(), source <- if relation.haveSource() then relation.source else OclUndefined endif, target <- if relation.haveTarget() then relation.target else OclUndefined endif ) }

Figura 5-40. Regla abstracta Relations2Rule (Transformacin MeTAGeM2Hybrid)

Para ayudar a entender el funcionamiento de las reglas que extienden Relations2Rule, la Figura 5-41 presenta un ejemplo grfico. En concreto, ilustra el mapeo de una relacin OneToOne (nivel PIM) en una regla de transformacin y una relacin de trazabilidad (nivel PSM). En dicho ejemplo, la relacin Mother_2_Female, que se compone de un elemento origen (Mother) y uno destino (Female), es mapeada a una regla de transformacin (Rule Mother_2_Female). La regla a nivel PSM (Hybrid Model) se compone de los elementos origen y destino (Mother y Female) y una relacin de trazabilidad (Mother2Female) que relaciona dichos elementos.

Solucin Tecnolgica 207

MeTAGeM Model
<<Relations OneToOne>> Mother_2_Female
<<SourceElement>> Mother <<TargetElement>> Female

Hybrid Model
<<Rule>> Mother_2_Female
<<Source>> Mother

<<Target>> Female

<<TraceRule>> Mother2Female

Figura 5-41. Ejemplo grfico de regla Relations2Rule (Transformacin MeTAGeM2Hybrid)

Para mostrar cmo se concreta esta idea, la Figura 5-42 presenta la regla de transformacin que genera reglas y relaciones de trazabilidad a partir de una relacin de tipo OneToOne. Como se puede observar, se extiende la regla abstracta Relations2Rule y se aade la generacin de las propiedades sources y targets, a las que se asignan los valores de las propiedades source y target del elemento OneToOne.
rule oneToOne2rule extends Relations2Rule{ from relation: MeTAGeM!OneToOne to r_hybrid: Hybrid!Rule( sources <- relation.source, targets <- relation.target ) do { thisModule.countRules <- thisModule.countRules + 1; } }

Figura 5-42. Regla OneToOne2Rule (Transformacin MeTAGeM2Hybrid)

La transformacin del resto de tipos de relaciones (OneToZero, ZeroToOne, OneToMany, ManyToOne y ManyToMany), se codifica de manera

208

lvaro Jimnez Rielo

similar. En cada caso, vara el valor que se asigna a las propiedades sources y targets, dependiendo de la cardinalidad de la relacin. La transformacin de las relaciones contenidas en otras relaciones, se ha hecho de forma similar, empleando la regla abstracta Relations2Binding, que ha sido extendida por los distintos tipos de relacin soportadas en este caso (OneToOne, ManyToOne y ZeroToOne). En la Figura 5-43 se muestra esta regla abstracta, que genera un elemento de tipo Binding y una relacin de trazabilidad de tipo TraceBinding, relacionados entre s mediante el atributo trace.
abstract rule Relations2Binding{ from relation:MeTAGeM!Relations(relation.isIncluded()) to binding:Hybrid!Binding( name <- relation.getRuleName(), typeRelation <- relation.typeRelation, typeElement <- relation.typeElement, owned <- relation.refImmediateComposite(), trace <- trace_binding ), trace_binding: Hybrid!TraceBinding( name <- relation.getRuleName(), source <- if relation.haveSource()then relation.source else OclUndefined endif, target <- relation.target, parent <- thisModule.resolveTemp( relation.refImmediateComposite(). refImmediateComposite(),'trace_rule') ) }

Figura 5-43. Regla abstracta Relations2Binding (Transformacin MeTAGeM2Hybrid)

Para mejorar la modularidad de las reglas, se han definido algunas funciones auxiliares (helpers) como getRuleName(), que permite recuperar el nombre de la regla que se est generando. En caso de que el usuario no especifique el nombre de la relacin en el modelo PIM, otro helper (getInOutPatternName) lo construye a partir de la concatenacin de los nombres de los elementos origen y destino que participan en la relacin, o en su defecto, genera un nombre del tipo RN, donde N es un nmero que representa a la relacin. Mediante estos helpers, se asegura que todas las reglas tengan un nombre, evitando errores en la generacin de los siguientes modelos. El resto del cdigo que implementa esta transformacin puede consultarse en el CD adjunto a esta tesis doctoral.

Solucin Tecnolgica 209

5.3.4.2

Transformacin de modelos PSM a modelos PDM En esta seccin se presenta la implementacin de la transformacin para pasar de los modelos PSM (aproximacin hbrida) a los modelos dependientes de plataforma: ATL y ETL. Como ya se ha indicado en la seccin 4.3.2, estas transformaciones son las ms complejas de todas las que forman parte de MeTAGeM-Trace, ya que el modelo resultante debe contener el modelado de la transformacin a nivel PDM y las estructuras que conforman el generador de trazas (ver Figura 4-1). 5.3.4.2.1 Transformacin de modelos PSM a modelos ATL

A partir de la especificacin de la transformacin presentada en la Tabla 4-2, se lleva a cabo la implementacin de las reglas de la transformacin en el lenguaje ATL. La implementacin de esta transformacin se compone de 18 reglas tipo matched, 17 reglas tipo lazy, 2 reglas tipo called y 13 helpers. En esta seccin solo se presentan las partes ms relevantes de la transformacin y se invita al lector a consultar la transformacin completa en el CD adjunto. En la Figura 5-44(a) se muestra la regla que genera el elemento mdulo (Module), raz de la transformacin a nivel PDM, a partir del mdulo de la transformacin a nivel PSM. Esta regla, adems de generar la raz del modelo de la transformacin, debe crear varias estructuras para soportar, posteriormente, la generacin del modelo de trazas. As, es necesario crear un elemento que define el modelo de trazas como otro modelo destino de la transformacin (Figura 5-44(a)). Para facilitar la comprensin al lector, la Figura 5-44(b) presenta un ejemplo del cdigo ATL obtenido tras serializar el modelo destino de la transformacin Hybrid2atl. En este ejemplo y en los posteriores, se emplea el caso Families2Persons4 [8].

Se trata de una versin adaptada del caso Families2Persons al que se le han agregado las

construcciones para el generador de trazas.

210

lvaro Jimnez Rielo

-- Create module header (a) rule Module { from hybrid : Hybrid!Module to atl : ATL!Module ( isRefining <- false, name <- hybrid.name.debug('Module'), inModels <- hybrid.sourceModels, outModels <- hybrid.targetModels.append(traceModel), elements <- hybrid.rules, commentsBefore <- Set {'-- @atlcompiler atl2006'} ), traceModel: ATL!OclModel( name <- 'in2out_trace', metamodel <- ametamodelTrace ), ametamodelTrace : ATL!OclModel ( name <- 'TRACE' ),

module familes2persons; create Persons_model : Persons, in2out_trace : TRACE from Families_model : Families;

(b)

Figura 5-44. Fragmento regla Module: creando el modelo de Trazas (Transformacin Hybrid2ATL)

El modelo de trazas, como todos los modelos EMF, debe tener un elemento raz (TraceModel). Como muestra la Figura 5-45 (a), para que la ejecucin de la transformacin generada produzca este elemento y dado que se debe crear antes que el resto de elementos del modelo de trazas, la regla Module de la transformacin Hybrid2atl tambin genera una regla de tipo entrypoint (calledRule). Dicha regla inicializar el modelo de trazas, creando los modelos origen y destino. Adems, ya que este elemento raz se crea automticamente y ser necesario acceder a l durante la ejecucin de la transformacin final, esta regla tambin genera una operacin ATL (Helper) que devuelve dicho elemento.

Solucin Tecnolgica 211

rule Module { (a) from hybrid : Hybrid!Module to ... -- this called rule creates the root of the trace model createTraceModelRoot : ATL!CalledRule ( name <- 'CreateTraceModelRoot'.debug('CalledRule'), outPattern <- outPattern, "module" <- hybrid, actionBlock <- anAction, --To create first the trace model root: isEntrypoint <- true, commentsBefore <- Set {'-- Comments -> This is a CalledRule to create the root of Trace Model'} ), ... --creates a helper to get the root of the model trace modelRoot_var : ATL!Helper ( "module" <- hybrid, definition <- adefinition, commentsBefore <- Set {'-- Comments -> This is a Helper to get the root of model trace '} ), ...
-- Comments -> This is a CalledRule to create the root of Trace Model (b) entrypoint rule CreateTraceModelRoot() { to root : TRACE!TraceModel -- ActionBlock: do { thisModule.getTraceModelRoot <- root; thisModule.createSourceModel_c2_Families(); thisModule.createTargetModel_c2_Persons(); } } -- Comments -> This is a Helper to get the root of model trace helper def: getTraceModelRoot() : TRACE!TraceModel = OclUndefined;

Figura 5-45. Fragmento regla Module: creando un entrypoint (Transformacin Hybrid2ATL)

Una vez que se ha codificado la regla que genera la raz del modelo de la transformacin, se implementan las reglas que mapean los modelos origen y destino de la transformacin. Dichas reglas, adems de generar el elemento que los representa en el modelo ATL (OclModel), tambin generan las construcciones necesarias para crear su representacin en el modelo de trazas. Adems, tambin generan una regla tipo called y un helper para cada uno de los modelos origen y destino. Las reglas called sern invocadas por la parte imperativa de la regla entrypoint de la transformacin generada (Figura 5-45(b)) y los helper servirn para acceder a la representacin de los modelos en el modelo de trazas.

212

lvaro Jimnez Rielo

En cuanto al mapeo de las reglas de la transformacin, los objetos que representan a las reglas en el modelo PSM contienen diferentes atributos que permiten identificar a qu tipo de reglas ATL deben transformarse ( matched, lazy, unique lazy o called). Por ello, en la transformacin Hybrid2atl se codifica una regla por cada uno de los tipos soportados, empleando estos atributos como precondicin (guard) de cada una de ellas. A modo de ejemplo, la Figura 5-46 muestra parte de la regla de transformacin que genera las reglas de tipo matched.
-- Create MatchedRule rule createRule2MatchedRule{ from hybrid_rule : Hybrid!Rule (hybrid_rule.isMain=true and hybrid_rule.getSizeIP()>0) to atl : ATL!MatchedRule ( name <- hybrid_rule.name.debug('MatchedRule'), isAbstract <- hybrid_rule.isAbstract, isRefining <- false, isNoDefault <- false, superRule <- hybrid_rule."extends", inPattern <- inPattern, outPattern <- outPattern, actionBlock <- anAction ), ... }

Figura 5-46. Fragmento de regla createRule2MatchedRule (Transformacin Hybrid2ATL)

Por otra parte, siguiendo la propuesta presentada por Jouault en [103] para la generacin de trazas a partir de transformaciones ATL, las instancias de las relaciones de trazabilidad (enlaces de trazas) asociadas a las reglas de la transformacin sern generadas como elementos destino de dichas reglas, como muestra la Figura 5-47.
rule A2B_Trace { from a : MM_Source!A to b : MM_Target!B (), a_2_b_TL1 : TRACE!TraceLink ( name <- a2b_trace, source <- a_trace, target <- b_trace ), a_trace: Trace!Source(), b_trace: Trace!Target() }

Figura 5-47. Generando trazas como elementos destino de una regla

Solucin Tecnolgica 213

Para aplicar esta idea a la transformacin Hybrid2atl es necesario realizar dos tareas: por un lado generar un elemento destino por cada relacin de trazabilidad encontrada en el modelo PSM (reglas TraceRule2CreateTraceLink y TraceBinding2CreateTraceLink) y por otro, crear los bindings adecuados en dichos elementos destino por cada uno de los elementos origen y destino de la relacin de trazabilidad. Para esta segunda tarea, se han implementado seis reglas distintas que son invocadas por cada elemento origen o destino (tres reglas para elementos origen y tres para elementos destino). En dichas reglas se comprueba si la regla a la que pertenece el elemento contiene una relacin de trazabilidad o no y si el elemento est contenido en una regla o en un binding. Con esta informacin las reglas crean los elementos adecuados en el modelo ATL. A modo de ejemplo, la Figura 5-48 muestra un fragmento de la regla InPatternElement_withTrace, que transforma los elementos origen, contenidos en una regla que tiene asociada una traza. En dicha regla, se genera un elemento origen de la transformacin ATL (SimpleInPatternElement) y un elemento destino que representa el elemento de la traza (SimpleOutPatternElement). Respecto de la Figura 5-47, estos elementos se corresponden con los elementos a y a_trace.
--InputPattern (from part) rule InPatternElement_withTrace { from inPattern : Hybrid!Source (inPattern.refImmediateComposite(). oclIsTypeOf(Hybrid!Rule)and inPattern.traceLink.size()>0) to atl : ATL!SimpleInPatternElement ( varName <- inPattern.name.toLower()+'_in', type <- aType ), aType : ATL!OclModelElement( name <- inPattern.name, model <- thisModule.resolveTemp(inPattern.model,'ametamodelMM') ), trace_element: ATL!SimpleOutPatternElement ( varName <- inPattern.name.toLower()+ '_in_Trace_TE'+thisModule.countTE.toString(), outPattern <- thisModule.resolveTemp(inPattern."rule",'outPattern'), type <- aType_trace, bindings <- Sequence{nameBinding, refBinding, modelBinding} ), aType_trace : ATL!OclModelElement( name <- 'SourceElement', model <- thisModule.resolveTemp( inPattern.refImmediateComposite(). refImmediateComposite(),'ametamodelTrace') ),

Figura 5-48. Fragmento regla InPatternElement_withTrace (Transformacin Hybrid2ATL)

A partir de las reglas de transformacin descritas en esta seccin, se genera la mayor parte del generador de trazas embebido en la transformacin final.

214

lvaro Jimnez Rielo

5.3.4.2.2

Transformacin de modelos PSM a modelos ETL

En la Tabla 4-3 se ha presentado la especificacin de las reglas de transformacin entre modelos PSM (aproximacin hbrida) y modelos de transformacin para el lenguaje ETL que incluyen el generador de trazas. En esta seccin se presenta la implementacin de dichas reglas de transformacin, que es relativamente ms sencilla que la transformacin de PSM a ATL, debido a que el metamodelo definido para el lenguaje ETL (Figura 4-8) es ms pequeo y sencillo que el proporcionado por el lenguaje ATL (Figura 4-7). As, esta transformacin se compone de 20 reglas matched, 9 reglas lazy, 5 reglas called y 10 operaciones helpers. Al igual que en casos anteriores, en esta seccin solo se muestra la implementacin de las reglas de transformacin ms relevantes. Las decisiones que dirigen la implementacin de esta transformacin son similares a las tomadas en la implementacin de la transformacin de PSM a ATL. As, una de las prioridades es asegurar que, en la ejecucin de la transformacin generada, el elemento raz del modelo de trazas se genere en primer lugar. Esta tarea se llevar a cabo en el bloque pre de la transformacin ETL generada. Para ello, deber contener el cdigo ETL que genera el elemento raz del modelo de trazas (TraceModel). Sin embargo, es necesario que el bloque pre genere otros elementos (como el elemento raz del modelo de trazas) cuya informacin se recopila a lo largo de la ejecucin de la transformacin Hybrid2etl. Por ello, se ha codificado un helper (getPre()) que almacena, a lo largo de la transformacin, el cdigo de dicho bloque. As, como muestra la Figura 5-49(a), la regla que genera el mdulo de la transformacin a nivel PDM, incluye cdigo en el bloque pre para generar el nombre del elemento TraceModel (raz del modelo de trazas generado). Posteriormente, en sucesivas reglas de transformacin se aadirn nuevas lneas de cdigo ETL al bloque pre, actualizando el valor de retorno del helper getPre(). Al igual que en la seccin anterior, para facilitar la comprensin de la regla de transformacin, la Figura 5-49(b) muestra el cdigo ETL de la transformacin final que se ha generado (tras la serializacin del modelo) a partir del fragmento de cdigo mostrado en la parte (a) de dicha figura.

Solucin Tecnolgica 215

(a) --Helper -> Pre text helper def:getPre:String='var traceModel: new Traceability!TraceModel;'; -- Create module header rule Module { from hybrid : Hybrid!Module to etl : ETL!EtlModule ( name <- hybrid.name.debug('Module'), rules <- hybrid.rules, operations <- hybrid.operations ) do{ thisModule.getETLmodule <- etl; thisModule.getPre <- thisModule.getPre + ' traceModel.name = \''+hybrid.name+'_traces\'; '; } }
pre { var traceModel: new Traceability!TraceModel; traceModel.name = 'familes2persons_traces'; ... }

(b)

Figura 5-49. Helper getPre y regla Module: creando bloque pre (Transformacin Hybrid2ETL)

El metamodelo de ETL no almacena informacin acerca de los modelos origen y destino, ya que en el cdigo de la transformacin, los modelos son tratados como otras variables ms y posteriormente, en la configuracin de la ejecucin se relacionan dichas variables con los modelos origen y destino. Sin embargo, el modelo de trazas s requiere almacenar cierta informacin sobre los modelos origen y destino, por ello, el generador de trazas embebido en la transformacin ETL debe contener mecanismos para la generacin de los elementos que representan a los modelos relacionados por el modelo de trazas. Para esta tarea, se han definido dos reglas en la transformacin Hybrid2etl: una para los modelos origen (createSourceModel) y otra para los modelos destino (createTargetModel). Dado que los modelos origen y destino del modelo de trazas se deben crear al inicio de la ejecucin transformacin ETL generada, estas reglas se encargan se incluir esta funcionalidad en el bloque pre de dicha transformacin. A modo de ejemplo, la Figura 5-50(a) muestra el cdigo de la regla createSourceModel y la Figura 5-50 (b) muestra su correspondencia en la transformacin ETL generada (en negrita).

216

lvaro Jimnez Rielo

rule createSourceModel{ (a) from s: Hybrid!SourceModel do{ thisModule.getPre <- thisModule.getPre + 'var '+s.name+'_var: new Traceability!SourceModel; '+s.name+'_var.name = \''+s.name+'\'; '+s.name+'_var.metamodel = \''+s.path+'\'; traceModel.sourceModels.add('+s.name+'_var);'; } }
pre { 'Running ETL: familes2persons Transformation'.println(); var traceModel: new Traceability!TraceModel; traceModel.name = 'familes2persons_traces'; var Families_model_var: new Traceability!SourceModel; Families_model_var.name = 'Families_model'; Families_model_var.metamodel = '/metagem_F2P/Metamodels/Families.ecore'; traceModel.sourceModels.add(Families_model_var); var Persons_model_var: new Traceability!TargetModel; Persons_model_var.name = 'Persons_model'; Persons_model_var.metamodel = '/metagem_F2P/Metamodels/Persons.ecore'; traceModel.targetModels.add(Persons_model_var); }

(b)

Figura 5-50. (a): Regla createSourceModel; (b) bloque pre de la transformacin generada (Transformacin Hybrid2ETL)

El siguiente paso consiste en la implementacin de las reglas de transformacin que generan reglas ETL a partir de reglas definidas a nivel PSM. El lenguaje ETL define varios tipos de reglas, que han sido descritas en la seccin 4.2.4.2. Sin embargo, tanto en el metamodelo PSM como en el metamodelo ETL todas ellas son representadas mediante la metaclase Rule (TransformationRule en ETL) y se diferencian por el valor de un conjunto de atributos. As, para generar los elementos TransformationRule en los modelos ETL se ha implementado la regla createRule (Figura 5-51). En dicha regla se crean los valores de los atributos name, isAbstract, extends, lazy, guard de las reglas ETL as como los elementos origen, destino y los bindings. Como se ha indicado en la implementacin de la transformacin PSM a ATL, las relaciones de trazabilidad definidas a nivel PSM son transformadas en elementos de salida de las reglas PDM. Por ello, en el atributo target se concatenan los elementos de salida de la regla ETL con los elementos que se generan a partir de las relaciones de trazabilidad asociadas a dicha regla (TraceRule y TraceBinding).

Solucin Tecnolgica 217

rule createRule{ from r: Hybrid!Rule(r.sources.size()=1 and r.targets.size()>0) to etl_r: ETL!TransformationRule( name <- r.name, isAbstract <- r.isAbstract, "extends" <- r."extends", "lazy" <- not r.isMain, guard <- r.guard, source <- r.sources.first(), targets <-r.targets.append(thisModule.resolveTemp( r.trace,'trace_as_element')).append( r.trace.traceBindings->collect( b|thisModule.resolveTemp( b,'trace_as_element'))), bindings <- r.targets->collect(t|t.bindings).asSequence() )

Figura 5-51. Regla createRule (Transformacin Hybrid2ETL)

Para convertir las relaciones de trazabilidad (TraceRule y TraceBinding) en elementos destino de las reglas, se han implementado dos reglas de transformacin (TraceRule2CreateTraceLink y TraceRule2CreateTraceLink). Ambas reglas generan un elemento ETL (Element) y en su parte imperativa realizan una llamada a una regla tipo lazy (generateBindings_TraceRule y generateBindings_TraceBinding, respectivamente) que se encarga de definir los atributos de la futura traza. La principal diferencia entre estas reglas es el patrn de entrada de la regla. La regla TraceRule2CreateTraceLink consume objetos de tipo TraceLink definidos a nivel PSM, mientras que la regla TraceRule2CreateTraceLink consume objetos TraceBinding. La Figura 5-52 (a), muestra la codificacin de la regla ATL TraceRule2CreateTraceLink que genera un elemento ETL a partir de un elemento TraceRule (nivel PSM) y en la Figura 5-52 (b), se muestra un ejemplo del resultado de ejecutar dicha regla (en negrita).

218

lvaro Jimnez Rielo

--TraceLink_Rule rule TraceRule2CreateTraceLink{ from traceRule: Hybrid!TraceRule to trace_as_element: ETL!Element( name <- traceRule.name, className <- 'TraceLink', metamodel <- 'Traceability' ) do{ thisModule.generateBindings_TraceRule(traceRule, thisModule.resolveTemp( traceRule.refImmediateComposite(),'etl_r')); } }

(a)

(b) rule Father_2_Male transform father : Families!Father to male : Persons!Male, Father_2_Male : Traceability!TraceLink, Father_trace : Traceability!SourceElement, Male_trace : Traceability!TargetElement, { male.fullName := father.getFatherName(); Father_2_Male.name := 'Father_2_Male'; Father_2_Male.`operation` := Traceability!Operations#Transform; Father_2_Male.source := Sequence{Father_trace}; Father_2_Male.target := Sequence{Male_trace}; Father_2_Male.traceModel := traceModel; ... }
Figura 5-52. Regla TraceRule2CreateTraceLink (Transformacin Hybrid2ETL)

El siguiente paso es construir las reglas para definir los elementos origen y destino de las reglas de la transformacin modelada. Para ello, se han implementado ocho tipos de reglas distintas, de acuerdo a las caractersticas de los elementos (pre-condiciones o guards de las reglas). En la Tabla 5-1 muestra cuando se debe ejecutar cada una de ellas. Estas reglas, se encargan de generar los elementos origen y destino en las reglas de la transformacin ETL y en el caso de que estn implicados en alguna relacin de trazabilidad, generan los elementos destino que son necesarios para que el generador de trazas pueda completar adecuadamente el modelo de trazas final.

Solucin Tecnolgica 219

Tabla 5-1. Reglas de Transformacin implementadas para elementos origen y destino (Transformacin Hybrid2ETL)
Patrn origen Guarda o pre-condicin (AND) No implicado en relacin de trazabilidad Implicado en relacin de trazabilidad No implicado en relacin de trazabilidad Implicado en relacin de trazabilidad No implicado en relacin de trazabilidad Implicado en relacin de trazabilidad No implicado en relacin de trazabilidad Implicado en relacin de trazabilidad Regla a ejecutar

Source2Element_withoutTrace

Elemento de Regla Elemento Origen Elemento de Binding

Source2Element_withTrace

Source2Feature_withoutTrace

Source2Feature_withTrace

Target2Element_withoutTrace

Elemento de Regla Elemento Destino Elemento de Binding

Target 2Element_withTrace

Target 2Feature_withoutTrace

Target 2Feature_withTrace

El cdigo que implementa estas reglas y el resto de reglas no detalladas aqu, puede consultarse en el CD adjunto a esta tesis.

5.3.5

Implementacin de la Generacin de Cdigo

A continuacin, se presenta la implementacin de los mecanismos que permiten la serializacin de los modelos PDM (ATL y ETL) en el cdigo ATL y ETL, respectivamente, que implementa la transformacin. Como se indica en la seccin 4.3.3, el IDE ATL incluye un parser implementado con TCS (Textual Concrete Syntax [106]) que permite obtener el cdigo de la transformacin ATL a partir de un modelo conforme al metamodelo del lenguaje y viceversa. As pues, solamente es necesario integrar dicha funcionalidad con el resto de mdulos de MeTAGeM-Trace, como se muestra en la seccin 5.3.7. Por el contrario, dado que no exista soporte para el modelado de transformaciones ETL y ha sido necesario construir un DSL para tal fin, tambin

220

lvaro Jimnez Rielo

es necesario implementar un generador de cdigo para transformar modelos de transformacin ETL en cdigo ETL. En la siguiente seccin se detalla su implementacin. 5.3.5.1 Generacin de Cdigo ETL En esta seccin se presenta la implementacin de las reglas de generacin de cdigo ETL especificadas en la seccin 4.3.3. Para ello, de acuerdo al mtodo de construccin propuesto en [206], se utiliza el lenguaje MOFScript [149]. Para la implementacin del generador de cdigo, se crea un fichero MOFScript (extensin .m2t) y se declara su cabecera, indicando la URI del metamodelo (Figura 5-53). A partir de ah, se procede a implementar el cdigo que se generar a partir de cada una de las metaclases del metamodelo del DSL, en este caso el metamodelo de ETL. Una transformacin MOFScript tiene comportamiento imperativo, de hecho se debe definir qu regla se ejecuta en primer lugar (palabra reservada main). En este caso, la generacin de cdigo comienza por el elemento raz del metamodelo del lenguaje ETL (EtlModule). La Figura 5-53 muestra la regla generadora de cdigo para dicha metaclase. Dado que se trata de la regla principal, en esta regla se define dnde se almacenar el cdigo resultante. Para ello, se emplea la funcin file. En este caso, se ha decidido que el fichero de cdigo se guarde con el nombre del elemento raz y la extensin propia de los ficheros de transformacin ETL ( .etl). En caso de que no se haya definido el nombre del mdulo de la transformacin, el nombre por defecto del fichero de cdigo obtenido ser generated.etl. Como se puede observar en la Figura 5-53, para generar el cdigo relativo a los bloques pre y post, debido a que los atributos de la metaclase EolBlock (name y body) son de tipo String, tan solo es necesario incluir su nombre en la regla para aadirlos al cdigo resultante.

Solucin Tecnolgica 221

texttransformation ETLGenerator (in eco:"http://org.eclipse.kybele.metagem.ETL") { eco.EtlModule::main () { var name:String if (self.name.size()=0) name="generated.etl" else name=self.name + ".etl" file (name) println("pre "+self.pre.name+" {") if (self.name.size()!=0) println("'Running ETL: "+self.name+" Transformation'.println();") self.pre.body println("") println("}") println("") println("post "+self.post.name+" {") self.post.body println("") println("}") println("") self.rules->forEach(r:eco.TransformationRule){ r.generateRule() println("") } self.operations->forEach(o:eco.Operation){ o.generateOperation() println("") } }

Figura 5-53. Cabecera y Generacin de cdigo de la metaclase EtlModule

El caso de las reglas y las operaciones es distinto ya que es necesario generar estructuras de cdigo ms complejas. Por ello, por cada regla y operacin contenida en el modelo de la transformacin se invocan, respectivamente, las reglas generateRule() (Figura 5-54) y generateOperation() (Figura 5-55), que se muestran a continuacin.

222

lvaro Jimnez Rielo

eco.TransformationRule::generateRule(){ if(self.greedy) println("@greedy") if(self.isAbstract) println("@abstract") if(self.lazy) println("@lazy") if(self.primary) println("@primary") println("rule "+ self.name) print(" transform ") self.source.generateElementRule() println("") print(" to ") self.targets->forEach(e:eco.Element){ e.generateElementRule() if(self.targets.indexOf(e)!=self.targets.size()-1) print(", ") } println("") if(self._getFeature("extends").size()>0){ println("extends") self._getFeature("extends")->forEach(ex:eco.TransformationRule){ ex.name print(",")} } println("{") if(self._getFeature("guard").size()>0) println("guard : " + self._getFeature("guard").body) self.bindings->forEach(b:eco.Binding){b.generateBinding()} println("}") }

Figura 5-54. Generacin de cdigo de la metaclase TransformationRule

En la regla generateRule(), en primer lugar se generan las etiquetas o flags que definen el tipo de regla ETL (greedy, abstract, lazy o primary). Posteriormente se crea la cabecera de la regla, que incluye el nombre de la misma y los elementos origen y destino que participan, separados por comas. En caso de que la regla extienda otras reglas, se aade la palabra reservada extends del lenguaje ETL y el nombre de las reglas extendidas. A continuacin, se genera el cdigo relativo a la pre-condicin de la regla (guard) y finalmente, por cada una de las asignaciones de tipo binding se invoca a la regla generateBinding(). A continuacin, la Figura 5-55 muestra la generacin de cdigo para la metaclase Operation de ETL. En esta regla, se genera el cdigo de las pre-condiciones y post-condiciones de la operacin, la cabecera de la operacin,

Solucin Tecnolgica 223

que incluye el contexto de la operacin, el nombre, los parmetros y el tipo de retorno y por ltimo, el cuerpo de la operacin.
eco.Operation::generateOperation(){ if(self.annotation!=null and self.annotation.size()>0) println("@"+self.annotation) if(self.pre!=null and self.pre.body.size()>0) println("@pre "+self.pre.body) if(self.post!=null and self.post.body.size()>0) println("@post "+self.post.body) print("operation ") self.context.generateOPstatement() print(" "+self.name+"(") self.parameters->forEach(p:eco.OperationParameter){ p.generateOpParameter() if(p!=self.parameters.last())print(",") } print(") : ") self._getFeature("return").generateOPstatement() println(" {") println("\t"+self.body) println("}") }
Figura 5-55. Generacin de cdigo de la metaclase Operation

Para facilitar el entendimiento de la regla generateOperation(), la Figura 5-56 muestra, a modo de ejemplo, el cdigo generado para una operacin ETL que puede invocarse sobre un elemento Families!Father y devuelve una cadena de tipo String, que se forma a partir de dos atributos de dicho elemento.
Pre y post condiciones Contexto
Nombre

Parmetros

Tipo de Retorno

Cuerpo @pre nothing operation Families!Father getFatherName() : String { return self.firstName + ' ' + self.familyFather.lastName; } Figura 5-56. Operacin ETL generada

De manera similar, se han implementado las reglas generadoras para el resto de metaclases del metamodelo de ETL: generateOpParameter, generateOpStatement, generateStatement, generateBinding y generateElementRule. La implementacin de estas reglas se puede consultar en el cdigo fuente que se encuentra en el CD adjunto.

224

lvaro Jimnez Rielo

5.3.6

Validacin automtica de modelos

La tercera actividad que soporta el procesador de modelos de MeTAGeM-Trace es la validacin de los modelos de transformacin. En la seccin 4.4, se ha presentado la especificacin de las reglas de validacin que se deben comprobar para cada uno los elementos de los modelos PIM y PSM de MeTAGeM-Trace. Dicha comprobacin asegura que los errores de los modelos de transformacin no sean propagados a los niveles de abstraccin inferiores, mejorando la calidad de la transformacin generada. Para implementar dichas reglas de validacin, de acuerdo con el diseo tcnico presentado en la seccin 5.2, se ha empleado el lenguaje de validacin EVL (Epsilon Validation Language, [121]). En cierto modo, EVL es un lenguaje similar a OCL, que permite especificar restricciones sobre un metamodelo y evaluarlas sobre modelos conformes a dicho metamodelo. Adems, EVL permite soporta la implementacin de mecanismos de interactuacin con el usuario para solventar los posibles errores elevados por la evaluacin de las restricciones. Dichas restricciones se recogen en un mdulo EVL (ficheros con extensin .evl) que implementa el conjunto de reglas de validacin. Para el desarrollo de MeTAGeM-Trace se han implementado cuatro mdulos que corresponden a las especificaciones presentadas en la seccin 4.4: MeTAGeM, Hybrid, Hybrid_to_ATL y Hybrid_to_ETL. Mientras los dos primeros implementan la validacin de modelos PIM y PSM, los dos ltimos realizan una validacin adicional sobre los modelos PSM que sern usados como origen para la transformacin Hybrid2ATL o Hybrid2ETL, respectivamente. A continuacin, se muestra la implementacin de algunas de estas restricciones. La Figura 5-57 muestra una restriccin que comprueba (check) si el atributo name del elemento ModelRoot (context) est definido. Si un elemento no cumple esta restriccin, el usuario recibir un mensaje por pantalla, generado por la operacin getMessageNotEmptyName (message). Adems, podr corregir el problema haciendo uso de las acciones que define la regla (parte fix).

Solucin Tecnolgica 225

context ModelRoot { -- ModelRoot name cannot be empty constraint notEmptyModelRootName { check : self.name.isDefined() message : getMessageNotEmptyName(self.type().name.asString()) fix { title : getTitleNotEmptyName(self.type().name.asString()) do { self.name := getInputNotEmptyName(self.type().name.asString()); } } }

Figura 5-57. Regla de validacin notEmptyModelRootName (MeTAGeM)

El resto de reglas de validacin siguen una estructura similar: context, constraint, check, message y fix (este ltimo solo aparece en algunos casos). Adems, algunas incluyen una comprobacin adicional ( guard) que permite especificar una pre-condicin sobre la validacin de la restriccin. Por ejemplo, en la restriccin mostrada en la Figura 5-58, antes de comprobar que el atributo name del elemento raz (Module) es correcto, es necesario comprobar previamente que dicho atributo ha sido definido (Figura 5-58).
context Module{ [...] -- Module name cannot be empty and should start with a letter -- following letters, numbers, dashes and underscores constraint validModuleName { guard : self.satisfies('notEmptyModuleName') check : self.name.isValidName() message : getMessageValidName(self.type().name.asString()) fix { title : getTitleValidName("Module", self.name_module) do { self.name := getInputValidName( self.type().name.asString(), self.name_module); } } }

Figura 5-58. Regla de validacin validModuleName (Hybrid)

Finalmente, la regla de validacin mostrada en la Figura 5-59 muestra un ejemplo del tipo de restricciones que se definen en los mdulos de validacin Hybrid_to_ATL y Hybrid_to_ETL. El lenguaje de transformacin ETL no permite definir reglas con ms de un elemento origen. Sin embargo, a nivel PSM s es posible definir reglas con N

226

lvaro Jimnez Rielo

elementos origen. Por ello, en el ejemplo de la figura, perteneciente al mdulo de validacin Hybrid_To_ETL, se ha definido una restriccin que no permite modelar reglas a nivel PSM con ms de un elemento origen.
context Rule{ [...] -- Validation to transform to ETL: -- A rule cannot have more than one source constraint manySources{ check: (self.sources.size()<2) message: 'Due to current ETL version implemented: ' +self.type().name+' only must have one source' } Figura 5-59. Regla de validacin manySources (Hybrid_to_ETL)

La implementacin completa de las reglas de validacin se puede consultar en el cdigo fuente que se encuentra en el CD adjunto.

5.3.7

Desarrollo de controles de usuario e Integracin

Una de los problemas habituales de las herramientas MDE es la usabilidad [186]. MeTAGeM-Trace, la herramienta que se presenta en esta tesis doctoral, adems de ofrecer las herramientas necesarias para el desarrollo dirigido por modelos de transformaciones, pretende hacerlo manteniendo unos niveles aceptables de usabilidad. En este sentido, el hecho de estar construido sobre Eclipse ayuda decisivamente a proporcionar una interfaz comn, extensible y adaptable [47]. En esta seccin se muestra cmo, a travs del uso de los componentes existentes y la documentacin disponible de Eclipse [47, 75, 77], se ha implementado un conjunto de funcionalidades (lanzadores y mens contextuales) para proporcionar una interfaz de usuario integrada que facilite el uso de las tareas proporcionadas por MeTAGeM-Trace. En concreto, esta seccin se centra en presentar algunos de los resultados, sin profundizar en el cdigo que los implementa. Para poder agrupar los distintos mdulos que componen MeTAGeM-Trace en una misma herramienta, es necesario construir un mdulo o plug-in de integracin. Adems de actuar como elemento de cohesin entre los mdulos, dicho plug-in incluye lanzadores y mens contextuales para que el usuario

Solucin Tecnolgica 227

invoque la ejecucin de las transformaciones de modelos, la validacin de los modelos y la generacin de cdigo, de forma sencilla sobre Eclipse.
<<Metamodelo>> <<Transformacin M2M>>

MeTAGeM
<<Validacin>>
<<Metamodelo>>

MeTAGeM -> Hybrid

MeTAGeM
<<Validacin>>

<<Transformacin M2M>>

Hybrid Hybrid
<<Metamodelo>>

Hybrid -> ATL

<<Transformacin M2M>>

ATL
<<Validacin>>
<<Metamodelo>>

Hybrid -> ETL

Hybrid_to_ATL
<<Validacin>>
<<Transformacin M2T>>

ETL Hybrid_to_ETL
<<Metamodelo>>

ATL -> Cdigo

<<Transformacin M2T>>

Trace

ETL -> Cdigo

ATL

MeTAGeM_UI Mdulo de Integracin

Eclipse Platform
Figura 5-60. Dependencias del Mdulo de Integracin de MeTAGeM-Trace

Como muestra la Figura 5-60, para el desarrollo del mdulo de integracin es necesario hacer uso de las tecnologas empleadas (EMF, ATL, Epsilon, MOFScript y Java) para el desarrollo de cada uno de los mdulos anteriores y disponer de los metamodelos de los DSLs, las reglas de validacin y las reglas de transformacin que componen la herramienta. De esta forma, para aadir nuevos mdulos o funcionalidades, tan solo es necesario crearlos y actualizar el mdulo de integracin. El plug-in de integracin de MeTAGeM-Trace est compuesto por cinco metamodelos (MeTAGeM, Hybrid, ATL, ETL y Trace), cuatro mdulos de validacin (MeTAGeM, Hybrid, Hybrid_to_ATL y Hybrid_to_ETL), tres transformaciones de modelos (MeTAGeM2Hybrid, Hybrid2ATL y Hybrid2ETL) y dos generadores de cdigo (ATL y ETL). A continuacin se muestra cmo se han integrado estos componentes para llevar a cabo la validacin de los modelos, la ejecucin de las transformaciones de modelos y la generacin de cdigo en el entorno Eclipse.

228

lvaro Jimnez Rielo

5.3.7.1

Validacin de Modelos EMF incluye un lanzador de validaciones de modelos por defecto (Figura 5-62(1)). Para que dicho lanzador utilice las restricciones EVL definidas, es necesario asociar los ficheros .evl con los plug-in que manejan los modelos conformes a los DSLs. En este caso, dado que se han definido restricciones para los modelos PIM y PSM, ha sido necesario modificar los ficheros de configuracin plugin.xml de los proyectos MeTAGeM y Hybrid (PIM y PSM, respectivamente). En concreto, como muestra la Figura 5-61, se ha incluido y configurado la extensin org.eclipse.evl.emf.validation.

namespaceURI: URI del metamodelo

Punto de Extensin

constraints: ruta fsica del fichero EVL

Figura 5-61. Definiendo la extensin para la validacin EVL

Una vez definida la extensin, como muestra la Figura 5-62(1), es posible invocar la validacin a travs del men contextual del elemento raz del modelo. En caso de que alguna restriccin no sea satisfecha el usuario recibir un mensaje por pantalla (2) y en consecuencia el modelo ser marcado como invalido (3).

Solucin Tecnolgica 229

1
2

Figura 5-62. Lanzando una validacin de modelos en MeTAGeM-Trace

Adems, dado que los modelos PIM y PSM se emplean para generar nuevos modelos, es conveniente validarlos antes de ejecutar la transformacin para asegurar que los modelos que se generen sean correctos. Por ello, tal como se describe en la siguiente seccin, la validacin de los modelos PIM y PSM se integra en los mecanismos de lanzamiento de las transformaciones que consumen dichos modelos, de manera que se asegure la correcta ejecucin de la transformacin. 5.3.7.2 Lanzamiento de Transformaciones de Modelos Como ya se ha mencionado anteriormente, las transformaciones embebidas en MeTAGeM-Trace han sido implementadas con ATL. El IDE de ATL proporciona un asistente genrico para configurar la ejecucin de las transformaciones (Figura 5-63). El usuario puede especificar los metamodelos y los modelos origen y destino de la transformacin y guardar esa informacin para ejecutarla y/o modificarla despus. Para esto, es necesario disponer, en el espacio de trabajo, del cdigo de la transformacin, el modelo origen y los metamodelos participantes en la transformacin.

230

lvaro Jimnez Rielo

Figura 5-63. Configurando la ejecucin de una transformacin ATL

Para evitar que el usuario gestione directamente toda esta informacin, se proporcionan lanzadores especficos que, por un lado, encapsulan esta informacin y por otro, simplifican la definicin de configuraciones de ejecucin. Para llevar a cabo esta tarea se deben definir, por cada transformacin para la que se desee crear un lanzador especfico, las extensiones adecuadas sobre el fichero plugin.xml del proyecto correspondiente al mdulo de integracin (MeTAGeM.ui). En concreto, se crean las extensiones: launchConfigurationTypes, launchConfigurationTabGroups y launchShorcuts (Figura 5-64). La primera permite la creacin de tipos de configuraciones como por ejemplo la configuracin de ejecucin mostrada en la Figura 5-63. La extensin launchConfigurationTabGroups permite la agrupacin de pestaas en la ventana mostrada al usuario. Y por ltimo, la extensin launchShorcuts aade un lanzador a los mens Run/Debug de Eclipse.

Solucin Tecnolgica 231

Figura 5-64. Definicin de extensiones para los lanzadores de las transformaciones de modelos

Una vez definidas las extensiones, se deben codificar las clases Java que implementan cada extensin. La clase que implementa la extensin launchShorcuts permite al usuario seleccionar un modelo con la extensin adecuada (por ejemplo .metagem) y lanzar la configuracin del lanzador (Figura 5-65(a)). Si para dicho modelo ya se han definido configuraciones de ejecucin, al usuario se le mostrar una ventana en la que debe elegir una de las configuraciones definidas (Figura 5-65(b)). En el caso de que solo se haya definido una, automticamente se ejecuta la transformacin, comprobando previamente que el modelo origen cumple con las reglas de validacin implementadas. En cambio, si hasta el momento no se ha definido ninguna configuracin de ejecucin para el modelo seleccionado, se procede a mostrar la ventana de configuracin de la ejecucin (Figura 5-65(c)). Dado que todas las transformaciones incluidas en MeTAGeM-Trace tienen un modelo origen y uno destino (PIM-PSM o PSM-PDM), para facilitar al usuario la configuracin de la ejecucin de la transformacin, las rutas fsicas de los modelos origen y destino de la transformacin se establecen automticamente, a partir del fichero seleccionado. As por ejemplo, si el usuario selecciona el modelo Families2Persons.metagem y su objetivo es generar un modelo PSM (hybrid), automticamente se le sugerir que la ubicacin del modelo destino sea la misma que la del modelo origen, pero cambiando la extensin del fichero, es decir, Families2Persons.hybrid (Figura 5-65(c)).

232

lvaro Jimnez Rielo

(a)

(b)

(c)

Figura 5-65. Posibles comportamientos del lanzador de transformaciones: a) seleccin de configuracin ya establecida; b) creacin de una nueva configuracin

La ventana de configuracin se corresponde con la clase que implementa la extensin launchConfigurationTabGroups. En este caso, esta clase crea un grupo de dos pestaas: la propia pestaa de configuracin de ejecucin la transformacin y la pestaa comn a todos los lanzadores de Eclipse. La pestaa de configuracin de ejecucin de la transformacin es implementada en una nueva clase en la que se crea la configuracin de ejecucin y se definen los componentes visuales de la pestaa (botones, campos de texto, etiquetas, etc.). Adems, cada vez que se realiza un cambio en la configuracin, se comprueba la existencia del modelo origen, que su extensin sea la correcta y que se trata de un modelo vlido, es decir, cumple con las reglas de validacin. Si no se cumplen todas estas condiciones, el usuario recibir por pantalla el mensaje mostrado en la Figura 5-66. Del mismo modo, si no se ha seleccionado la ubicacin del modelo destino, tambin se muestra un error por pantalla.

Solucin Tecnolgica 233

Cuando el usuario pulsa sobre el botn Run de la ventana de configuracin, se ejecuta la transformacin de acuerdo a la configuracin especificada en la pantalla.

Figura 5-66. Mensaje de error en la ventana de configuracin

Respecto a la validacin de modelos, su invocacin se ha implementado en la clase ValidationExecution. Esta clase contiene un mtodo isValid que recibe el modelo origen, el metamodelo origen y el metamodelo destino (en caso de ser necesario). A partir de esta informacin crea una instancia del mdulo EVL, ejecuta el proceso de validacin y analiza el resultado obtenido. En caso de no cumplir con alguna de las reglas de validacin implementadas, el usuario recibir un mensaje por pantalla como muestra la Figura 5-67.

Figura 5-67. Mensaje de error de validacin

234

lvaro Jimnez Rielo

Una vez comprobado que el modelo origen es vlido de acuerdo a las reglas de validacin implementadas con EVL, se ejecuta la transformacin, de acuerdo a los parmetros de configuracin especificados por el usuario. Para ilustrar la ejecucin de las transformaciones incluidas en MeTAGeMTrace, la Figura 5-68 presenta un escenario donde el usuario desea obtener un modelo a nivel PSM (mT.hybrid) a partir de un modelo PIM (mT.metagem).
MeTAGeM-Trace
El usuario selecciona el modelo mT.metagem para generar mT.hybrid (MeTAGeM -> Hybrid) Se invoca la clase

S
Primera vez?

Carga las transformaciones:

MeTAGeM2Hybrid.atl Hybrid2ATL.atl Hybrid2ETL.atl

Transformations()

No metagem2hybrid
loadModelsMeTAGeM2Hybrid: Carga los metamodelos:
MeTAGeM.ecore y Hybrid.ecore mT.metagem y mT.hybrid

Carga los modelos: Mtodo metagem2hybrid

(origen: mT.metagem, destino: mT.hybrid) doMeTAGeM2Hybrid:

Ejecuta la transformacin sobre el modelo origen mT.metagem saveModels: Guarda el modelo destino mT.hybrid

Figura 5-68. Proceso de ejecucin de la transformacin MeTAGeM2Hybrid

En primer lugar el usuario lanza el proceso usando la opcin de men correspondiente. Como consecuencia, se invoca la clase Transformations, que carga en memoria las transformaciones que soporta MeTAGeM-Trace (metagem2hybrid, hybrid2atl y hybrid2etl). Dado que se trata de una tarea costosa en trminos de memoria y tiempo de procesamiento, se ha seguido el patrn singleton [76] para implementar esta carga en memoria. De esta forma las transformaciones se cargan la primera vez que se instancia la clase y permanecen disponibles hasta que se cierra la aplicacin (Eclipse). Adems de cargar las transformaciones en memoria, la clase Transformations implementa un mtodo que permite ejecutar cada una de ellas, de manera que cada mtodo se ocupa de identificar los metamodelos origen y destino correspondientes para cada transformacin y slo reciben como parmetro el path de los modelos origen y destino. Por ejemplo, en la Figura 5-68, se puede observar que el mtodo metagem2hybrid solo recibe como

Solucin Tecnolgica 235

parmetros las (mT.hybrid).

rutas

los

modelos

origen

(mT.metagem)

destino

El siguiente paso consiste en cargar los metamodelos y los modelos implicados en la transformacin. Para ello, se ejecuta un mtodo loadModelsXXX (siendo XXX el nombre de la transformacin, por ejemplo loadModelsMeTAGeM2Hybrid). Posteriormente, uno de los mtodos doXXX (por ejemplo, doMeTAGeM2Hybrid) se encarga de ejecutar la transformacin sobre la mquina virtual de ATL y finalmente, el mtodo saveModels se encarga de almacenar el resultado en el correspondiente modelo destino. En cuanto a la implementacin de todos los mtodos mencionados, a modo de ejemplo, la Figura 5-69 presenta la implementacin de metagem2hybrid, doMeTAGeM2Hybrid y loadModelsMeTAGeM2Hybrid.
public void metagem2hybrid(String inFilePath, String outFilePath) throws Exception { try{ Map<String, Object> models=loadModelsMeTAGeM2Hybrid(inFilePath); doMeTAGeM2Hybrid(models,new NullProgressMonitor()); saveModels(((IModel)models.get("OUT")),outFilePath); }catch(Exception e){ e.printStackTrace(); } } private void doMeTAGeM2Hybrid(Map<String, Object> models, NullProgressMonitor nullProgressMonitor) throws Exception { ILauncher launcher = new EMFVMLauncher(); Map<String, Object> launcherOptions = getOptions(_METAGEM2HYBRID); launcher.initialize(launcherOptions); launcher.addInModel(((IModel)models.get("IN")), "IN", "MeTAGeM"); launcher.addOutModel(((IModel)models.get("OUT")), "OUT", "Hybrid"); launcher.launch("run", nullProgressMonitor, launcherOptions, (Object[]) getModulesList(_METAGEM2HYBRID)); } private Map<String, Object> loadModelsMeTAGeM2Hybrid(String inFilePath) throws Exception { Map<String, Object> models = new HashMap<String, Object>(); ModelFactory factory = new EMFModelFactory(); IInjector injector = new EMFInjector(); IReferenceModel hybridMetamodel = factory.newReferenceModel(); injector.inject(hybridMetamodel, Utils.getFileURL("resources/Hybrid.ecore").toString()); IReferenceModel metagemMetamodel = factory.newReferenceModel(); injector.inject(metagemMetamodel, Utils.getFileURL("resources/MeTAGeM.ecore").toString()); IModel metagemInputModel = factory.newModel(metagemMetamodel); injector.inject(metagemInputModel, inFilePath); models.put("IN", metagemInputModel); IModel hybridOutputModel = factory.newModel(hybridMetamodel); models.put("OUT", hybridOutputModel); return models; }

Figura 5-69. Mtodos para la ejecucin programtica de la transformacin Metagem2hybrid

236

lvaro Jimnez Rielo

5.3.7.3

Lanzamiento de Generacin de Cdigo Ya que para la integracin de los generadores de cdigo no es necesario definir una configuracin de lanzamiento, se ha empleado otro tipo de interfaz. En concreto se han definido entradas en el men contextual de los modelos PDM (ATL y ETL), como muestra la Figura 5-70.
Modelo ATL -> Cdigo ATL

Modelo ETL -> Cdigo ETL

Figura 5-70. Entradas del men contextual para generar el cdigo de la transformacin

Para implementar cada una de estas entradas de men contextual, como muestra la Figura 5-71, se define un punto de extensin sobre la extensin org.eclipse.ui.popupMenus en el fichero plugin.xml del mdulo de integracin (proyecto MeTAGeM_UI).

Solucin Tecnolgica 237

Figura 5-71. Extensiones para la definicin de entradas de men contextual

Cada elemento de tipo objectContribution tiene asociada una accin (action) que se implementa mediante una clase Java: ATLExtract y ETLExtract. La primera de ellas contiene un mtodo ExtractATL que carga el modelo de la transformacin ATL seleccionado por el usuario, crea una instancia del parser TCS que proporciona el framework de ATL y ejecuta el proceso de extraccin del cdigo. Dicho cdigo es almacenado en un fichero con el mismo nombre que el modelo de entrada, pero cambiando su extensin por .atl. La clase ETLExtract proporciona la misma funcionalidad, pero para ello emplea el parser genrico que proporciona el framework de MOFScript, el lenguaje empleado para implementar las reglas de generacin de cdigo. El cdigo Java que implementan estas clases puede consultarse en el CD adjunto a esta tesis.

Validacin

6. Validacin
En los captulos anteriores se ha presentado el entorno MeTAGeM-Trace para el desarrollo de transformaciones de modelos que incluyen de forma embebida un generador de modelos de trazas. Para ello, se ha presentado por un lado la propuesta metodolgica y por otro lado, la herramienta que da soporte tecnolgico a dicha propuesta. En este captulo se presenta la validacin del trabajo de investigacin de esta tesis doctoral, de acuerdo al mtodo de validacin presentado en la seccin 2.4, basado en el uso de casos de estudio de laboratorio. As, en las siguientes secciones se detallar la definicin del protocolo de validacin (seccin 6.1), la ejecucin de los casos de estudio seleccionados (secciones 6.2 y 6.3) y se discuten las principales conclusiones (seccin 6.4).

6.1

Protocolo de Validacin

De acuerdo al mtodo de validacin presentado en la seccin 2.4, el primer paso del proceso de validacin es definir los casos de estudio a emplear y el protocolo para la recogida de datos, que se describen a continuacin.

6.1.1

Definicin de los Casos de Estudio

Como ya se ha indicado en la introduccin de esta tesis doctoral (seccin 1.3), el entorno MeTAGeM-Trace forma parte de MIDAS, una metodologa para el desarrollo dirigido por modelos de sistemas de informacin [53, 54, 137, 211, 216]. Para dar soporte al mdulo de contenido de MIDAS, en [206], se present la herramienta M2DAT-DB. M2DAT-DB es una herramienta MDA para soportar el desarrollo de esquemas de Bases de Datos (BD). Para ello, define un conjunto de DSLs conectados entre s mediante transformaciones de modelos. Dado que esta herramienta ya ha sido implementada [206], es posible acceder al cdigo que implementa cada una de las transformaciones contenidas en M2DAT-DB. Por todo ello, se propone el desarrollo de un meta-caso de estudio para la implementacin de una de las transformaciones de M2DAT-DB. En concreto, de todas ellas, se ha escogido la transformacin que permite obtener esquemas XML (XSD) a partir del modelo conceptual en UML (UML2XMLSchema). Se ha seleccionado este escenario porque al disponer de una codificacin de referencia de la transformacin, ser posible comparar y evaluar los resultados obtenidos con MeTAGeM-Trace.

242

lvaro Jimnez Rielo

Como resultado de la ejecucin de dicho meta-caso de estudio se obtendr una transformacin entre los metamodelos UML (origen) y XSD (destino), que contiene de forma embebida un generador de trazas para la creacin de un modelo de trazas entre los elementos de los modelos UML y XSD participantes en la transformacin. Para validar que la transformacin generada proporciona la funcionalidad requerida, se emplea un caso de estudio. El caso de estudio utilizado para probar las transformaciones implementadas se ha tomado de [70]. Concretamente, se trata de la construccin de una base de datos de pelculas online (OMDB, Online Movie Database). Este caso de estudio fue empleado en la validacin de las transformaciones contenidas en la herramienta M2DAT-DB [206], por tanto ser posible comparar los modelos resultantes de la ejecucin de la transformacin. Dado que para la implementacin de la herramienta M2DAT-DB se ha empleado ATL como lenguaje de transformacin de modelos, este proceso de validacin se centra en usar el entorno MeTAGeM-Trace para la generacin de transformaciones ATL. As mismo, es necesario destacar que al margen de esta validacin, se ha realizado un conjunto de pruebas para la generacin de transformaciones ETL con MeTAGeM-Trace. En concreto, adems de pruebas unitarias para validar el metamodelo de ETL y las transformaciones en la que participa, se ha implementado una adaptacin del caso de estudio Families to Persons, presentado en [8].

6.1.2

Protocolo para la Recogida de Datos

El siguiente paso del protocolo de validacin consiste en la definicin del protocolo para la recogida de datos. De acuerdo con Yin [230], este protocolo debe proporcionar una visin global de los casos de estudio, haciendo uso de mltiples fuentes de informacin siempre que sea posible y definir un conjunto de cuestiones que se deben resolver con la ejecucin de cada caso de estudio. As, en las siguientes secciones se proporciona una visin global de cada uno de los casos de estudio seleccionados y se establece un conjunto de preguntas a las que se dar respuesta en secciones posteriores. 6.1.2.1 Meta-caso de estudio UML2XMLSchema_Trace M2DAT-DB es una herramienta para el desarrollo dirigido por modelos de esquemas de Bases de Datos modernas, cuyo proceso es mostrado en la Figura 6-1.

Validacin 243

PIM

Modelo Conceptual de Datos

Escenario para el Meta-Caso de Estudio

PSM

UML2SQL2003

Modelo OR ORACLE

PSM

Modelo OR SQL2003

Modelo XML

CDIGO

SQL

SQL

XML Schema

Figura 6-1. Proceso de Desarrollo de Bases de Datos soportado por M2DAT-DB

M2DAT-DB, a partir de un modelo conceptual de datos definido a nivel PIM y representado por medio de un diagrama de clases de UML [34, 160], soporta la generacin a nivel PSM de esquemas de Bases de Datos Objeto-Relacionales (para el producto comercial Oracle 10g [84, 212] y el estndar SQL:2003 [97]) y esquemas XML [38, 161, 215, 216, 217, 223] y posteriormente, la generacin del cdigo que implementa el esquema modelado. Para obtener los modelos PSM (Oracle, SQL:2003 y XMLSchema) a partir de los modelos PIM (diagrama de clases UML), M2DAT-DB implementa, tres transformaciones ATL, una por cada modelo propuesto a nivel PSM: UML2ORA (UML a Oracle 10g), UML2SQL2003 (UML a SQL:2003) y UML2XMLSchema (UML a XMLSchema). De estas transformaciones, se ha optado por desarrollar la transformacin UML2XMLSchema con MeTAGeM-Trace para validar el trabajo presentado en esta tesis doctoral. Para diferenciar ambas transformaciones, la desarrollada con MeTAGeM-Trace se denominar UML2XMLSchema_Trace. Tras presentar el meta-caso de estudio, se definen las siguientes cuestiones a las que se deber dar respuesta (CMCE, Cuestin del Meta-Caso de Estudio): CMCE-1. Ha sido posible completar el desarrollo de la transformacin hasta obtener una transformacin en cdigo ATL? CMCE-2. Durante el proceso de desarrollo, el usuario ha tenido que modificar manualmente los modelos generados (PSM y PDM)?

244

lvaro Jimnez Rielo

CMCE-3. El cdigo obtenido es totalmente ejecutable? Si no es as, qu elementos no se han generado (semi-)automticamente? CMCE-4. En cuanto al nmero de lneas de cdigo de la transformacin generada, es menor, igual o mayor al de la transformacin UML2XMLSchema contenida en M2DAT-DB, codificada manualmente? Es necesario recordar que la transformacin incluida en la herramienta M2DAT-DB no proporciona generacin de trazas.

En cuanto a la recoleccin de datos que permitir obtener un conjunto de evidencias para dar respuesta a las preguntas anteriores se ha decidido emplear como fuentes de informacin: 6.1.2.2 La observacin directa del desarrollo del meta-caso de estudio. El cdigo que implementa la herramienta M2DAT-DB. La tesis doctoral en la que se presenta dicha herramienta [206].

Caso de estudio OMDB (UML2XMLSchema_Trace) El desarrollo del meta-caso de estudio UML2XMLSchema_Trace debe proporcionar como resultado una transformacin entre los metamodelos UML y XMLSchema, que incluye de forma embebida un generador de trazas. Con el objetivo de validar la funcionalidad de dicha transformacin y del generador de trazas, se desarrolla un caso de estudio que requiere la ejecucin de dicha transformacin. Este caso de estudio se corresponde con el desarrollo dirigido por modelos de una BD para la gestin de un catlogo de pelculas online (OMDB, Online Movie DataBase [70]). Una vez que se ha presentado el caso de estudio que se va a desarrollar, se definen las siguientes cuestiones a las que se deber dar respuesta a partir del desarrollo de este caso de estudio (CCE, Cuestin del Caso de Estudio): CCE-1. La transformacin generada mediante el meta-caso de estudio (UML2XMLSchema_Trace) se ejecuta correctamente tomando como origen el modelo OMDB.uml? CCE-2. El modelo OMDB.schemaxml que se ha obtenido es igual al modelo obtenido ejecutando la transformacin original, embebida en M2DAT-DB? Si no son iguales, qu diferencias existen? CCE-3. En cuanto al tiempo de ejecucin de la transformacin generada con MeTAGeM-Trace para obtener el modelo OMDB.schemaxml, es menor, igual o mayor que ejecutando la transformacin contenida en M2DAT-DB?

Validacin 245

CCE-4. Se ha generado un modelo que contiene las trazas entre los modelos origen (OMDB.uml) y destino (OMDB.schemaxml)?

En cuanto a la recoleccin de datos que permitir obtener un conjunto de evidencias para dar respuesta a las preguntas anteriores se ha decidido emplear como fuentes de informacin: La observacin directa del desarrollo del caso de estudio. El cdigo implementado para la validacin de la herramienta M2DAT-DB. La tesis doctoral en la que se aplica este caso de estudio a la herramienta M2DAT-DB [206]. El estudio del cual se ha obtenido el caso de estudio [70].

6.2

Diseo y Ejecucin del Meta-Caso de Estudio

Como se ha mencionado anteriormente, el meta-caso de estudio seleccionado consiste en usar este entorno para el desarrollo de la transformacin UML2XMLSchema_Trace, que forma parte de la implementacin de la herramienta M2DAT-DB [206]. El desarrollo de este meta-caso de estudio de laboratorio se lleva a cabo por el doctorando en un entorno controlado. Mediante el desarrollo de este meta-caso de estudio se comprueba el funcionamiento y la aplicabilidad del entorno MeTAGeM-Trace en un desarrollo externo. En otras palabras, el objetivo es evaluar si MeTAGeM-Trace produce transformaciones de modelos correctas que puedan aplicarse en desarrollos que impliquen la ejecucin de transformaciones de modelos. Como se describe en la Figura 6-2, el proceso de desarrollo de las reglas de la transformacin UML2XMLSchema consiste en: 1. Crear modelo PIM (modelo MeTAGeM) que recoja las relaciones de transformacin entre los elementos del metamodelo de UML y los elementos del metamodelo XMLSchema. 2. Generacin del modelo PSM (modelo hybrid), a partir de la ejecucin de la transformacin MeTAGeM2Hybrid. 3. Generacin del modelo PDM (modelo ATL) a partir de la ejecucin de la transformacin MeTAGeM2ATL. 4. El ltimo paso es la generacin del cdigo ATL que implementa la transformacin.

246

lvaro Jimnez Rielo

Conviene mencionar que cada uno de los artefactos resultantes de las transformaciones (los modelos PSM y PDM y el cdigo de la transformacin) pueden ser refinados manualmente por el desarrollador.

Metamodelo UML

Metamodelo XMLSchema

PIM

Modelo PIM (UML2XMLSchema_Trace)

Relaciones de Transformacin
Modelo Conceptual UML

PIM

Transformacin MeTAGeM2Hybrid

PSM

Transformacin UML2XMLSchema

Modelo PSM (UML2XMLSchema_Trace)

Reglas de Transformacin + Relaciones de Trazabilidad

PSM

Modelo XML Schema

Transformacin Hybrid2ATL
Modelo PDM (UML2XMLSchema_Trace)

PDM

CDIGO

XML Schema

Modelo ATL (incluye Generador de Trazas)

Generacin de Cdigo ATL2Code

Cdigo

Cdigo (UML2XMLSchema_Trace)

Cdigo ATL (incluye Generador de Trazas)

Figura 6-2. Proceso de Desarrollo de la Transformacin UML2XMLSchema_Trace con MeTAGeM-Trace

6.2.1

Especificacin de las Relaciones de Transformacin

El primer paso en el desarrollo de la transformacin UML2XMLSchema_Trace con MeTAGeM-Trace consiste en definir las relaciones de transformacin entre los elementos de los metamodelos UML (origen) y XMLSchema (destino), recogidas en la Tabla 6-1.
Tabla 6-1. Relaciones de Transformacin en UML2XMLSchema_Trace

Metamodelo UML (PIM)

Model Package Class (mapTo==Sequence and

Metamodelo XMLSchema (PSM)

Schema Schema ElementGlobal ComplexTypeLocal

Validacin 247

Metamodelo UML (PIM)

not getGeneralization)

Metamodelo XMLSchema (PSM)

Other Sequences ElementGlobal ComplexTypeLocal

Class (getGeneralization)

ComplexContent Extension ComplexContent Choice ElementGlobal

Class (mapTo==Choice and not getGeneralization)

ComplexTypeLocal Other Choice ElementGlobal

Class (mapTo==All and not getGeneralization) Property (contenido en un elemento Class) Association (isNM and not isAgregation and not isComposite) Association (is1N and not isAgregation and not isComposite) Association (is11 and not isAgregation and not isComposite) Association (isAgregation)

ComplexTypeLocal Other All ElementLocal ElementLocal minOccurs:N maxOccurs: N

ElementLocal minOccurs:1 maxOccurs: N

ElementLocal minOccurs:1 maxOccurs: 1

ElementLocal ElementLocal

Association (isComposite and not isAgregation and mapTo==Sequences)

ComplexTypeLocal Other Sequences ElementLocal

248

lvaro Jimnez Rielo

Metamodelo UML (PIM)

Metamodelo XMLSchema (PSM)

ElementLocal

Association (isComposite and not isAgregation and mapTo==All)

ComplexTypeLocal Other All ElementLocal

A continuacin, se procede a elaborar un modelo que recoja estas relaciones, usando el DSL de nivel PIM de MeTAGeM-Trace.

6.2.2

Definicin del Modelo PIM

Para definir el modelo de la transformacin UML2XMLSchema_Trace a nivel PIM se debe crear un nuevo modelo MeTAGeM utilizando el asistente de creacin de modelos implementado en MeTAGeM-Trace (seccin 5.3.3.). Una vez creado el modelo vaco, se van aadiendo objetos que representen las relaciones descritas en la Tabla 6-1 (y sus relaciones internas), en trminos de los elementos del metamodelo de MeTAGeM (Figura 5-3). As, por ejemplo, la relacin de transformacin entre un elemento origen Model y un elemento destino Schema (relacin model2schema), se debe modelar mediante una relacin de tipo OneToOne (uno-a-uno), que a su vez contiene otra relacin OneToOne que define que el atributo id del Schema se generar a partir del atributo name del elemento Model. De la misma forma, las relaciones cuyo elemento origen es Class deben ser definidas mediante relaciones OneToMany, ya que a partir de un objeto Class se obtienen cuatro o cinco elementos destino, dependiendo de si representa una generalizacin y del tipo de elemento al que debe mapearse (mapTo). La Figura 6-3 muestra una vista parcial del modelo de la transformacin a nivel PIM. Como se puede observar, en la parte izquierda se muestran los elementos del metamodelo origen (UML); en la parte derecha los elementos del metamodelo destino (XMLSchema); y en el centro, el modelo de la transformacin donde se han especificado todas las relaciones.

Validacin 249

Figura 6-3. Modelo de Transformacin a nivel PIM (UML2XMLSchema_Trace)

250

lvaro Jimnez Rielo

6.2.3

Definicin del Modelo PSM

Una vez definido el modelo de la transformacin a nivel PIM, se puede generar de forma (semi-)automtica, el modelo PSM de la transformacin, de acuerdo a las caractersticas de la aproximacin hbrida. Como se ha indicado en el captulo anterior, el modelo destino adems de las reglas de la transformacin, contendr las relaciones de trazabilidad identificadas automticamente a partir del modelo de la transformacin a nivel PIM. Dicho modelo PSM puede ser refinado manualmente por el usuario, aadiendo o modificando las reglas de transformacin y sus elementos origen y destino, las relaciones de trazabilidad, las operaciones de la transformacin, etc. En particular, para el desarrollo de la transformacin UML2XMLSchema_Trace ha sido necesario aadir un conjunto de operaciones que se deben ejecutar en el mbito de la transformacin. Para definir estas operaciones se ha consultado directamente la implementacin de la transformacin contenida en la herramienta M2DAT-DB. Adems, se han modificado diversos elementos de tipo RightPattern para establecer llamadas a dichas operaciones as como para establecer valores concretos que se asignarn al elemento destino (atributos minOccurs y maxOccurs de elementos ElementLocal). En la Figura 6-4 se muestra parte del modelo PSM de la transformacin UML2XMLSchema_Trace. A modo de ejemplo, al igual que en la figura del modelo PIM, se muestra la relacin model2schema.

Validacin 251

Figura 6-4. Modelo de Transformacin a nivel PSM (UML2XMLSchema_Trace)

252

lvaro Jimnez Rielo

6.2.4

Definicin del Modelo PDM

Una vez que se ha refinado el modelo PSM, es posible obtener (semi-)automticamente el modelo de la transformacin a nivel PDM, de acuerdo a los metamodelos que describen los lenguajes de transformacin ATL y ETL. Como se ha comentado anteriormente, la transformacin de referencia con la que se compararn los resultados de este proceso de validacin se encuentra implementada en ATL. Por este motivo, en este caso, se generar el modelo ATL (extensin -atl.ecore). Para obtener dicho modelo, se ejecuta la transformacin Hybrid2ATL, embebida en MeTAGeM-Trace. El modelo obtenido puede ser refinado por el desarrollador de la transformacin, para ello, se puede emplear el editor reflexivo que proporciona EMF. Conviene destacar que, en este caso, no ha sido necesario refinar el modelo ATL obtenido. En la Figura 6-5 se muestra parte del modelo de la transformacin conforme al metamodelo de ATL.

Figura 6-5. Modelo de Transformacin a nivel PDM: ATL (UML2XMLSchema_Trace)

Validacin 253

En la figura anterior, una vez ms, puede verse la regla de transformacin model2schema. Si bien su representacin en el modelo PSM ya era ms compleja que su definicin a nivel PIM, en el caso del modelo PDM, es evidente que el tamao y complejidad aumentan notablemente. Este aumento en la complejidad segn disminuye el nivel de abstraccin de la transformacin que incluye generacin de trazas, apoya la idea de la conveniencia de emplear modelos de alto nivel para el desarrollo de este tipo de transformaciones.

6.2.5

Generacin de Cdigo

El siguiente paso en el desarrollo de UML2XMLSchema_Trace con MeTAGeM-Trace es generar, a partir del modelo PDM, el cdigo que implementa la transformacin. En este caso, el modelo PDM se ha definido en trminos del metamodelo de ATL por tanto, se obtendr cdigo ATL (fichero . atl). En la Figura 6-6 se muestra un fragmento del cdigo de la transformacin generada. Siguiendo con el ejemplo usado anteriormente, esta figura se presenta el cdigo que implementa la regla de transformacin model2schema. El resto del cdigo de la transformacin UML2XMLSchema_Trace puede consultarse en el CD adjunto. Para ilustrar la diferencia entre el cdigo generado por la herramienta MeTAGeM-Trace y el cdigo de la transformacin implementado de forma manual y embebida en la herramienta M2DAT-DB, la Figura 6-7 muestra la regla model2schema, incluida en la segunda.

254

lvaro Jimnez Rielo

-- @atlcompiler atl2006 module UML2XMLSchema; create schemaXML_model : schemaXML, in2out_trace : TRACE from UML_model : UML, AnnotationMetamodel_model : AnnotationMetamodel; -- Comments -> This is a MatchedRule: model2schema -> do{thisModule.model;} rule model2schema { from model_in : UML!Model to schema_out : schemaXML!Schema ( id <- model_in.name ), model2schema_TL1 : TRACE!TraceLink ( name <- 'model2schema', traceModel <- thisModule.getTraceModelRoot, operation <- #Transform, source <- Sequence {model_in_Trace_TE1}, target <- Sequence {schema_out_Trace_TE35}, childLinks <- Sequence {name_2_id_TL14} ), name_2_id_TL14 : TRACE!TraceLink ( name <- 'name_2_id', operation <- #Transform, source <- Sequence {name_in_Trace_TE14}, target <- Sequence {id_out_Trace_TE69} ), model_in_Trace_TE1 : TRACE!SourceElement ( name <- model_in.getName(), ref <- model_in.__xmiID__, model <- thisModule.getModel_UML_model ), name_in_Trace_TE14 : TRACE!SourceElement ( name <- model_in.name.toString() + '(Feature: name)', belongsTo <- model_in_Trace_TE1, model <- thisModule.getModel_UML_model ), schema_out_Trace_TE35 : TRACE!TargetElement ( name <- schema_out.getName(), ref <- schema_out.__xmiID__, model <- thisModule.getModel_schemaXML_model ), id_out_Trace_TE69 : TRACE!TargetElement ( name <- schema_out.id.toString() + '(Feature: id)', belongsTo <- schema_out_Trace_TE35, model <- thisModule.getModel_schemaXML_model ) -- ActionBlock: do { thisModule.model; } }

Figura 6-6. Cdigo ATL de la regla model2schema generada con MeTAGeM-Trace (UML2XMLSchema_Trace)

Validacin 255

module UML2XMLW; -- Module Template create OUT : schemaXML from IN : UML, AMW : AnnotationMetamodel; rule model2schema { from c: UML!Model to xml: schemaXML!Schema ( id<-c.name) do {thisModule.model;} }

Figura 6-7. Cdigo ATL de la regla model2schema implementada manualmente para M2DAT-DB (UML2XMLSchema_Trace)

Como se puede ver, la regla de transformacin generada con MeTAGeM-Trace (Figura 6-6) es mucho mayor que la implementacin manual (Figura 6-7). Esta diferencia se debe fundamentalmente al generador de trazas que incluye la transformacin generada con MeTAGeM-Trace. Una vez ms, se evidencia que la inclusin del generador de trazas en la codificacin de la transformacin aumenta su complejidad de forma considerable. En consecuencia, el esfuerzo de los desarrolladores aumentara de forma muy notable si estos tuvieran que realizar la implementacin de forma manual.

6.3

Diseo y Ejecucin del Caso de Estudio

Mediante el desarrollo del meta-caso de estudio se ha obtenido el cdigo que implementa la transformacin UML2XMLSchema_Trace, incluyendo un generador de trazas. Con el objetivo de probar si dicha transformacin proporciona la funcionalidad requerida, se procede al desarrollo de un caso de estudio que requiera la ejecucin de dicha transformacin. En concreto, se ha optado por desarrollar el caso de estudio OMDB [70], que ya se emplea en la validacin de las transformaciones embebidas en la herramienta M2DAT-DB [206], entre las que se encuentra la transformacin UML2XMLSchema. As, ser posible comparar los resultados de la ejecucin de la transformacin UML2XMLSchema_Trace, desarrollada con MeTAGeM-Trace con los resultados de ejecutar la transformacin implementada de forma manual (UML2XMLSchema). Al igual que en el meta-caso de estudio, el desarrollo de este caso de estudio de laboratorio se lleva a cabo por el doctorando en un entorno controlado. Para desarrollar este caso de estudio, se parte del modelado conceptual de la base de datos OMDB a nivel PIM (fichero OMDB.uml). Este modelo se

256

lvaro Jimnez Rielo

describe en trminos de un diagrama de clases UML, implementado mediante el plug-in UML2 de Eclipse (Figura 6-8).

Figura 6-8. Modelo Conceptual de Datos (Caso de Estudio OMDB)

La BD OMDB est diseada para manejar informacin referente a pelculas, actores, directores, guionistas y en general, informacin relacionada con las pelculas. Los usuarios pueden acceder de forma online a esta informacin en la pgina web de OMDB y comprar productos (por ejemplo, videos de pelculas, DVDs, libros, CDs y otros productos relacionados con las pelculas). De cada una de las pelculas almacenadas en la BD se registra su ttulo, director, sitio web oficial, gnero, estudio, una breve sinopsis y el reparto de actores. Adems, cada pelcula tiene un mximo de cinco comentarios de editores externos, y el nmero ilimitado de comentarios de los usuarios. De los productos que se ponen a la venta en la web de OMDB, se almacena su informacin ms relevante como el ttulo, la categora, el precio, la fecha de lanzamiento, etc.

Validacin 257

Empleando este modelo conceptual como origen de la transformacin UML2XMLSchema_Trace, como muestra la Figura 6-9, se deben obtener dos modelos: un modelo de salida que describa la base de datos OMDB a nivel PSM, conforme al metamodelo XMLSchema (fichero OMDB.schemaxml) y un modelo que contenga las trazas entre los elementos de ambos modelos.

PIM

Modelo OMDB (UML)

UML2XMLSchema_Trace.atl

Modelo OMDB_UML2XML (Modelo de Trazas)

CDIGO

PSM

Modelo OMDB (XML Schema)

XML Schema

Figura 6-9. Proceso de Desarrollo del Caso de Estudio

Con el objetivo de comprobar que la transformacin desarrollada con MeTAGeM-Trace genera los modelos destinos correctos, se evalan dos factores: 1. Usando como origen el mismo modelo (OMDB.uml), el modelo destino OMDB.schemaxml que se obtiene a partir de la ejecucin de la transformacin UML2XMLSchema_Trace, que se ha desarrollado con MeTAGeM-Trace, debe ser igual o equivalente al modelo destino que se obtiene ejecutando la transformacin implementada de forma manual. Para ello se emplea la observacin directa de los modelos y el comparador de modelos EMFCompare [198]. Adems del modelo destino OMDB.schemaxml, se debe generar un modelo de trazas entre los elementos del modelo OMDB.uml y los elementos del modelo OMDB.schemaxml.

2.

Para el primer punto, la Figura 6-10 presenta el modelo obtenido a partir de la ejecucin de la transformacin desarrollada mediante MeTAGeM-Trace (Figura

258

lvaro Jimnez Rielo

6-10 (a)) y el modelo obtenido ejecutando la transformacin implementada de forma manual, contenida en la implementacin de la herramienta M2DAT-DB (Figura 6-10 (b)). Como se puede comprobar a simple vista en dicha figura, ambos modelos son iguales. En realidad, cambia el nombre que reciben algunos elementos. Por ejemplo en el caso del modelo (b), los elementos de tipo ElementGlobal incluyen la cadena <<ElementGlobal>> al final de su nombre. Esto se debe a que la transformacin de M2DAT-DB adopt una poltica de nombrado muy particular que consiste en aadir al nombre de cada objeto generado, un estereotipo que refleje el tipo del objeto. Esta poltica no se ha seguido en el desarrollo de la transformacin UML2XMLSchema_Trace. Adems, usando el comparador de modelos EMFCompare disponible en Eclipse, se verifica que no existen ms diferencias entre dichos modelos. Por tanto, se asume que la transformacin desarrollada con MeTAGeM-Trace ha proporcionado el mismo modelo de salida.
(a) (b)

Figura 6-10. Modelo OMDB.schemaxml: (a) obtenido a partir de la transformacin generada con MeTAGeM-Trace; (b) obtenido a partir de la transformacin manual embebida en M2DAT-DB

Validacin 259

Figura 6-11. Modelo de Trazas generado (Caso de Estudio OMDB)

260

lvaro Jimnez Rielo

El segundo factor para comprobar que la transformacin desarrollada con MeTAGeM-Trace genera los modelos destinos correctos es comprobar que se ha generado un modelo que contiene las trazas que se derivan de la transformacin entre los elementos del modelo origen OMDB.uml y los elementos del modelo destino OMDB.schemaxml. En la Figura 6-11 se confirma que se ha obtenido dicho modelo de trazas. Adicionalmente, se ha verificado por observacin directa que este modelo de trazas contiene las trazas correctas para cada una de las relaciones definidas.

6.4

Conclusiones de la Validacin

Finalmente, en esta seccin se presentan las conclusiones obtenidas a partir del proceso de validacin descrito en este captulo. Para ello, se dar respuesta a cada una de las preguntas establecidas cuando se defini el protocolo de validacin (seccin 6.1.2). En cuanto a las cuestiones establecidas para el meta-caso de estudio (CMCE): CMCE-1. Ha sido posible completar el desarrollo de la transformacin hasta obtener una transformacin en cdigo ATL? S, aunque en las primeras ejecuciones del proceso de validacin se han detectado errores de implementacin en la herramienta MeTAGeM-Trace que han sido reparados. As, como muestra la Figura 2-2, el proceso de validacin tambin ha servido como fase de pruebas de la herramienta. Una vez corregidos todos los errores detectados, el proceso de desarrollo se ha completado y se ha obtenido la transformacin ATL (seccin 6.2.5). CMCE-2. Durante el proceso de desarrollo, el usuario ha tenido que modificar manualmente los modelos generados (PSM y PDM)? S, como se ha indicado en la seccin 6.2.3, para satisfacer las necesidades de la transformacin que se ha desarrollado, ha sido necesario refinar el modelo PSM (modelo de la transformacin para la aproximacin hbrida). En concreto, se han aadido operaciones que se ejecutan en el mbito de la transformacin y que no son recogidas en el modelo PIM. Tambin se han refinado varios elementos RightPattern para invocar a dichas operaciones y para asignar valores concretos a los elementos destino. CMCE-3. El cdigo obtenido es totalmente ejecutable? Si no es as, qu elementos no se han generado semi-automticamente?

Validacin 261

No, algunas partes del cdigo han tenido que ser refinadas manualmente. En la transformacin que genera un modelo ATL a partir de un modelo PSM, el cuerpo de las operaciones (atributo body) definidas a nivel PSM se mapea en forma de comentario ATL. Por tanto, al generar el cdigo ATL, las operaciones definidas no contienen cdigo ejecutable, sino comentarios que funcionan a modo de indicadores para que el desarrollador complete el cdigo que implementa la funcin. Por otra parte, las reglas composite2ElementLocalSeq y composite2ElementLocalAll contienen errores de compilacin debido a la existencia de variables con el mismo nombre. Esta duplicidad se debe a que el nombre de las variables se genera a partir del tipo del elemento al que representan y en este caso, ambas reglas definen varios elementos destino del mismo tipo. CMCE-4. En cuanto al nmero de lneas de cdigo obtenidas, es menor, igual o mayor al de la transformacin UML2XMLSchema contenida en M2DAT-DB, codificada manualmente? Es necesario recordar que la transformacin incluida en la herramienta M2DAT-DB no proporciona generacin de trazas. Mayor. Una vez refinada la transformacin ATL desarrollada con MeTAGeM-Trace (UML2XMLSchema_Trace), esta se compone de 1731 lneas de cdigo ATL. En cambio, la transformacin UML2XMLSchema, implementada de forma manual y embebida en M2DAT-DB, se compone de dos ficheros de cdigo que suman un total de 460 lneas de cdigo ATL. Es decir, la transformacin generada con MeTAGeM-Trace ocupa casi 4 veces ms lneas de cdigo. En cuanto a las cuestiones establecidas para el caso de estudio (CCE): CCE-1. La transformacin generada mediante el meta-caso de estudio (UML2XMLSchema_Trace) se ejecuta correctamente tomando como origen el modelo OMDB.uml? S, una vez corregidos los errores detectados en la herramienta MeTAGeM-Trace, se ha ejecutado la transformacin generada (UML2XMLSchema_Trace) sobre el modelo origen OMDB.uml y el proceso ha concluido de forma satisfactoria, creando los modelos destino OMDB.schemaxml y omdb_uml2xml.mtrace.

262

lvaro Jimnez Rielo

CCE-2. El modelo OMDB.schemaxml que se ha obtenido es igual al modelo obtenido ejecutando la transformacin original, embebida en M2DAT-DB? Si no son iguales, qu diferencias existen? Son iguales. Como se ha indicado en la seccin 6.3 se han realizado dos tipos de pruebas para comparar ambos modelos: observacin directa y verificacin con EMFCompare. Como resultado de ambas pruebas, se ha comprobado que ambos modelos son iguales. Tan solo difieren los nombres de algunos elementos generados. Esta pequea diferencia se debe a que la transformacin UML2XMLSchema, embebida en M2DAT-DB, adopt una poltica de nombrado de los objetos generados muy particular. En concreto, al nombre de cada objeto se le aade un sufijo que refleja el tipo del objeto. Por ejemplo, si genera un elemento XML llamado casa, el nombre que se le asigna es casa <<element>>. Esta poltica no ha sido adoptada en el desarrollo de la transformacin UML2XMLSchema_Trace.

CCE-3. En cuanto al tiempo de ejecucin de la transformacin generada con MeTAGeM-Trace para obtener el modelo OMDB. schemaxml, es menor, igual o mayor que ejecutando la transformacin contenida en M2DAT-DB? Similar (algo mayor). Para evaluar esta pregunta se han realizado 10 ejecuciones de cada transformacin, anotando los tiempos de ejecucin que proporciona el plug-in de ATL. En la Tabla 6-2 se muestran los tiempos obtenidos en cada ejecucin y la media total. Como se puede observar, el tiempo de ejecucin de la transformacin desarrollada con MeTAGeM-Trace es ligeramente superior, del orden de 0,001 segundos. Esta diferencia puede considerarse despreciable. Es necesario destacar que MeTAGeM-Trace genera transformaciones que deben ser ejecutadas con la mquina virtual EMFVM de ATL, mientras que la transformacin contenida en M2DAT-DB, implementada manualmente, est desarrollada para ejecutarse sobre la mquina virtual Regular de ATL. EMFVM es una mquina virtual optimizada. Por ello, aun generando trazas, la transformacin desarrollada con MeTAGeM-Trace (UML2XMLSchema_Trace) obtiene tiempos de ejecucin similares a los de la transformacin codificada manualmente (UML2XMLSchema).

Validacin 263

Tabla 6-2. Comparativa de tiempos de ejecucin (Transformacin MeTAGeM-Trace vs. Transformacin manual)

Transformacin generada con MeTAGeM-Trace

N Ejec. 1 2 3 4 5 6 7 8 9 10 Tiempo (s.) 0,198 0,079 0,093 0,078 0,094 0,093 0,078 0,093 0,074 0,094

Transformacin implementada manualmente

Tiempo (s.) 0,094 0,094 0,109 0,093 0,125 0,094 0,093 0,094 0,094 0,079

Media

0,0974

0,0969

CCE-4. Se ha generado un modelo que contiene las trazas entre los modelos origen (OMDB.uml) y destino (OMDB. schemaxml)? S, como muestra la Figura 6-11, se ha obtenido un modelo de trazas conforme al metamodelo de trazabilidad propuesto por MeTAGeM-Trace. Dicho modelo contiene las trazas derivadas de la transformacin entre los elementos del modelo OMDB.uml y los elementos del modelo OMDB.schemaxml. Adems, este modelo de trazas se ha validado por observacin directa, concluyendo que ha generado las trazas correctas entre los elementos de los modelos origen y destino de la transformacin.

A partir de los resultados obtenidos, se puede concluir que el entorno MeTAGeM-Trace ha podido ser aplicado satisfactoriamente en el desarrollo de un caso de estudio: Primero, se han modelado las relaciones de transformacin entre los elementos de los metamodelos UML y XMLSchema a alto nivel. A partir de este modelo de transformacin y la ejecucin de varias transformaciones embebidas en

264

lvaro Jimnez Rielo

MeTAGeM-Trace, se ha obtenido el cdigo ATL que implementa la transformacin UML2XMLSchema_Trace, que incluye un generador de trazas. En el proceso de validacin se ha detectado que la transformacin ATL generada no es totalmente ejecutable, aunque la mayor parte de su cdigo s es correcto. Tan solo se han generado unos pocos errores de compilacin. As mismo, se ha comprobado que, una vez refinados estos errores, la transformacin puede ejecutarse en la mquina virtual de ATL, generando los modelos destino correctos. Adems, se ha observado que el tamao de la transformacin ATL generada con MeTAGeM-Trace es varias veces superior a la implementada manualmente. Esta diferencia de tamao se debe a que la transformacin que genera MeTAGeM-Trace incluye adems el generador del modelo de trazas. Esta diferencia no supone cambios ostensibles en cuanto al tiempo de ejecucin de las transformaciones, ya que la transformacin generada con MeTAGeM-Trace puede ser ejecutada por la mquina virtual optimizada de ATL (EMF-Specific VM) [64]. Por esta razn, el tiempo de ejecucin es similar al de la transformacin implementada manualmente. As pues, la diferencia de tamao se compensa con la mejora de rendimiento que proporciona la mquina virtual optimizada.

Conclusiones

7. Conclusiones
Para concluir esta memoria, en este captulo se resumen las principales contribuciones realizadas por esta tesis doctoral. Adems, se realiza un anlisis de los resultados obtenidos, enumerando las publicaciones que sirven para contrastarlos, tanto en foros nacionales como en foros internacionales. Por ltimo, se presentan las lneas de investigacin futuras que permitirn seguir trabajando en la mejora de la propuesta presentada.

7.1

Anlisis de la Consecucin de Objetivos

En el primer captulo de esta tesis doctoral, concretamente en la seccin 1.2, se establecieron un conjunto de objetivos parciales para completar el objetivo principal de la tesis: la definicin y construccin de un entorno de desarrollo de transformaciones de modelos que incorpore gestin de la trazabilidad. A continuacin se presentan los objetivos parciales establecidos y su grado de cumplimiento: O1. Estudio de trabajos previos. Para identificar el cuerpo del conocimiento en el que se basa esta tesis doctoral, se han realizado dos estudios diferentes. Por un lado, se han analizado y evaluado las propuestas existentes para el desarrollo dirigido por modelos de transformaciones de modelos (seccin 3.2) y por otro lado, se han analizado y evaluado las propuestas centradas en la gestin y generacin de informacin de trazabilidad a partir del desarrollo de transformaciones de modelos (seccin 3.3). Respecto al primero, se ha planteado un conjunto de cuestiones de investigacin a las que se ha dado respuesta y se ha establecido un conjunto de criterios de evaluacin para comparar las propuestas analizadas. Conviene destacar que este estudio surge como una evolucin del proceso de revisin sistemtica de la literatura, presentado en [31]. Como resultado de este estudio se constata que la mayora de las propuestas coinciden en los tipos de niveles de abstraccin a los que se debe definir las transformaciones de modelos: niveles independientes del lenguaje o motor de transformacin y niveles dependientes. Tambin conviene destacar que ninguna de las propuestas analizadas, considera la gestin y generacin de la

268

lvaro Jimnez Rielo

informacin de la trazabilidad en su propuesta para el desarrollo dirigido por modelos de transformaciones de modelos. Respecto al segundo estudio, en la seccin 3.3 se ha presentado el anlisis y estudio de las propuestas existentes centradas en la gestin de la trazabilidad a partir del desarrollo de transformaciones de modelos. Este estudio es el resultado de un proceso completo de revisin sistemtica de la literatura, basado en las guas propuestas por Kitchenham y Charters [111] y Biolchini [27]. Entre las conclusiones obtenidas en este segundo estudio cabe destacar el bajo nivel de automatizacin de las distintas propuestas. Uno de los principios de MDE es potenciar el nivel de automatizacin, por ello, cabra esperar una mayor automatizacin de los procesos para la gestin de la trazabilidad. Tambin cabe destacar que la mayora de las propuestas se han desarrollado para una aproximacin o lenguaje de transformacin concreto. Por otro lado, ambos estudios coinciden en poner de manifiesto la brecha o gap existente entre la teora y la prctica: mientras que la mayora de las propuestas metodolgicas son muy completas, las herramientas para dar soporte a dichas propuestas son incompletas e incluso en algunos casos, inexistentes. A partir de estos estudios previos, en esta tesis doctoral se propona la incorporacin de mecanismos generadores de informacin de trazabilidad en el desarrollo dirigido por modelos de transformaciones de modelos. O2. Especificacin de un metamodelo de trazabilidad genrico. Uno de los principales objetivos de la propuesta que se presenta en esta tesis doctoral, es la generacin (semi-)automtica de modelos de trazas. En consecuencia, es necesario definir un metamodelo de trazabilidad que describa la sintaxis abstracta de dichos modelos. La mayora de las propuestas analizadas para la gestin de la trazabilidad (seccin 3.3) coinciden en la conveniencia de utilizar metamodelos genricos que permitan modelar las trazas en cualquier escenario, ofreciendo distintas alternativas [36, 103, 117, 134, 143, 181, 224].Las conclusiones extradas del anlisis de dichos metamodelos se utilizaron en la especificacin del metamodelo de trazabilidad de MeTAGeM-Trace, presentado en la seccin 4.2.1. Dado que MeTAGeM-Trace soporta la generacin de modelos de trazas a partir de la definicin a alto nivel de transformaciones de modelos, su metamodelo de trazabilidad debera ser tambin genrico, para poder ser utilizado

Conclusiones 269

independientemente de cuales sean los metamodelos implicados en la transformacin. El metamodelo de trazabilidad de MeTAGeM-Trace permite definir trazas y elementos trazados. Pero, adems, con el objetivo de dar soporte a otras tareas como la visualizacin conjunta de trazas y elementos trazados, permite definir cules son los modelos origen y destino a los que pertenecen dichos elementos trazados. O3. Estudio y mejora (si procede) de la propuesta MeTAGeM para el desarrollo de transformaciones de modelos [31].

En [31] se presentaba MeTAGeM, un entorno para el desarrollo de transformaciones de modelos dirigido por modelos. Dicho entorno constitua una prouesta para la aplicacin de los principios de MDE al desarrollo de transformaciones. As, dado que en esta tesis doctoral el objetivo principal era proporcionar un entorno para el desarrollo dirigido por modelos de transformaciones de modelos que incluyan generadores de trazas, se opt por utilizar MeTAGeM como punto de partida. Para ello, se ha realizado un estudio completo de MeTAGeM, la propuesta metodolgica presentada en [31]. En dicho propuesta se consideraban los niveles de abstraccin PIM, PSM, PDM y Cdigo en el desarrollo de transformaciones. En esta tesis doctoral se ha aceptado esta aruitectura de modelado y se han analizado cada uno de los metamodelos propuestos en [31] con el objetivo de encontrar debilidades y puntos de mejora y utilizarlos como punto de partida para la especificacin de los metamodelos de MeTAGeM-Trace. Tras el anlisis de dichos metamodelos, en la seccin 4.2 se han presentado los metamodelos de MeTAGeM-Trace para el modelado de transformaciones de modelos a distintos niveles de abstraccin. A nivel PIM (seccin 4.2.2), se ha adoptado el metamodelo propuesto en [31], aunque se han introducido ciertas modificaciones, como la redefinicin de tipos de datos enumerados. A nivel PSM, la seccin 4.2.3 ha presentado el refinamiento del metamodelo propuesto en [31] para modelar transformaciones de modelos de acuerdo a la aproximacin hbrida (imperativa + declarativa). Finalmente, a nivel PDM, mientras que en [31] se soportaban los lenguajes de transformacin ATL y RubyTL, en MeTAGeM-Trace se ha optado por ATL y ETL. El primero sigue siendo considerado el estndar de-facto para el desarrollo de transformaciones de modelos, mientras que con la eleccin de ETL se pretende

270

lvaro Jimnez Rielo

demostrar que la propuesta es vlida para cualquier lenguaje de transformacin. En [31] y [99] se mostraba que lo era para RubyTL y en esta tesis, se ha demostrado que lo es tambin para ETL. O4. Especificacin de un metamodelo de transformacin a nivel PDM de acuerdo a las caractersticas del lenguaje hbrido ETL.

Epsilon [119, 121] es una familia de lenguajes para distintas tareas, propias de la Ingeniera Dirigida por Modelos. Entre estos lenguajes se encuentra ETL (Epsilon Transformation Language, [118]), un lenguaje de transformaciones de modelos que adopta el enfoque hbrido. A diferencia de ATL, no existe una especificacin completa del metamodelo de ETL. Para que MeTAGeM-Trace soporte el desarrollo de transformaciones ETL, se ha especificado e implementado el metamodelo de dicho lenguaje. Para ello, se ha analizado en profundidad la sintaxis abstracta de ETL, a partir de las publicaciones existentes [118, 119] y los ejemplos disponibles en el sitio web de Epsilon. Como resultado, en la seccin 4.2.4.2, se ha presentado una especificacin completa del metamodelo del lenguaje de transformacin ETL, que se utiliza para modelar las transformaciones a nivel PDM en MeTAGeM-Trace. O5. Identificacin de construcciones que, incorporadas a los metamodelos de transformacin definidos a nivel PIM, PSM y PDM, permitirn generar modelos de traza conformes al metamodelo definido en O2.

Este quinto objetivo pasaba por definir nuevos metamodelos para el modelado de transformaciones a distintos niveles de abstraccin, que permitiesen generar transformaciones que incorporen generacin de trazas. Como ya se ha mencionado en O2, en la seccin 4.2.1, se ha especificado el metamodelo de trazabilidad que describe como sern los modelos de trazas generados por MeTAGeM-Trace. A partir de los elementos de dicho metamodelo, se han identificado los elementos a incorporar en los metamodelos para soportar el modelado de transformaciones a distintos niveles que incorporen la generacin de las trazas. As, a nivel PIM, dado que el objetivo es modelar las relaciones entre los elementos de los modelos origen y destino, la genericidad del metamodelo hace que no sea necesario incorporar nuevas construcciones. A nivel PSM, el modelo de la transformacin se centra en el modelado de las reglas de transformacin. La ejecucin de cada una de ellas debe producir la

Conclusiones 271

creacin de una o varias trazas en el modelo de trazas. Por tanto, a partir de cada relacin definida a nivel PIM, a nivel PSM se genera una regla de transformacin y una relacin de trazabilidad. Para soportar el modelado de estas relaciones de trazabilidad, en la especificacin del metamodelo PSM (seccin 4.2.3) se ha aadido una nueva metaclase abstracta (TraceLink). Dicha metaclase es extendida por otras dos nuevas metaclases que permiten modelar las relaciones de trazabilidad derivadas de una regla de transformacin ( TraceRule) y derivadas de una asignacin (TraceBinding). A nivel PDM se describen las transformaciones de acuerdo a las caractersticas propias de los lenguajes de transformacin, por ello, no es posible definir construcciones especficas para la generacin de modelos de trazas. Por tanto, se ha optado por definir las trazas y los elementos trazados como elementos destino de la transformacin generada. Para la creacin de la raz del modelo de trazas y la representacin de los modelos origen y destino en el modelo de trazas, se ha decidido aprovechar las construcciones imperativas que soportan los lenguajes hbridos. En particular, se ha decidido utilizar las construcciones de ATL y ETL que permiten ejecutar acciones al principio de la transformacin. O6. Especificacin de transformaciones de modelos. Se ha definido un conjunto de transformaciones para automatizar el paso (semi-)automtico entre los distintos niveles de abstraccin a los que se modela la transformacin. Concretamente, se han especificado tres transformaciones de modelos: PIM-PSM, PSM-ATL (PDM) y PSM-ETL (PDM); y dos transformaciones de modelo a texto: PDM-Cdigo ATL y PDM-Cdigo ETL. La especificacin de estas transformaciones ha sido descrita en lenguaje natural en la seccin 4.3. O7. Construccin de la herramienta de soporte. Uno de los principales objetivos de esta tesis doctoral es la construccin de una herramienta que ofrezca soporte tecnolgico a la propuesta metodolgica MeTAGeM-Trace. La implementacin de dicha herramienta se presenta en el captulo 5. Para la consecucin de este objetivo, en la seccin 1.2 se ha planteado un conjunto de objetivos parciales. El primero de ellos, que consista en la especificacin de la arquitectura de la herramienta, ha sido satisfecho en la seccin 5.1, donde se presenta una arquitectura basada en capas (presentacin y lgica) que se compone de varios mdulos ortogonales a dichas capas. Cada uno de los

272

lvaro Jimnez Rielo

mdulos representa a uno DSLs que componen MeTAGeM-Trace para el modelado de transformaciones que incorporan generacin de trazas: DSL MeTAGeM (nivel PIM), DSL de aproximacin hbrida (nivel PSM), DSL del lenguaje ATL (nivel PDM), DSL del lenguaje ETL (nivel PDM) y DSL de Trazabilidad. El siguiente paso (sub-objetivos O7.2 y O7.3) era la implementacin de los DSLs mencionados. Para ello, se ha seguido el mtodo de construccin detallado en la seccin 2.3. El resultado, que se presenta en las secciones 5.3.1, 5.3.2, y 5.3.3, incluye la implementacin de los metamodelos, el desarrollo de editores ad-hoc adecuados a la naturaleza relacional de estos modelos y la construccin de asistentes para la creacin de modelos. Respecto a las transformaciones M2M y M2T mencionadas en O6, las secciones 5.3.4 y 5.3.5 presentan su implementacin con ATL y MOFScript, respectivamente. Estas implementaciones han satisfecho el sub-objetivo O7.4. Finalmente, en la seccin 5.3.7, se ha presentado la implementacin del mdulo integrador que incluye la construccin de un conjunto de componentes de Eclipse para proporcionar una interfaz de usuario integrada que facilite el uso de las tareas proporcionadas por el procesador de modelos (ejecucin de transformaciones, generacin de cdigo y validacin de modelos) de MeTAGeM-Trace. De esta forma, se ha satisfecho el sub-objetivo O7.5 O8. Validacin de la propuesta. El captulo 6 se presenta la aplicacin del mtodo de validacin, descrito en la seccin 2.4. Se ha desarrollado un meta-caso de estudio en el que se ha obtenido una transformacin de modelos que permite pasar de un modelo conceptual de datos expresado en trminos de un diagrama de clases UML, a un modelo lgico en trminos de un esquema XML. Adems, para comprobar que la transformacin generada es correcta, se ha desarrollado un caso de estudio que utiliza la transformacin generada para el desarrollo de una base de datos de pelculas online (OMDB). El meta-caso de estudio ha proporcionado una transformacin ATL, que consume un modelo UML parar generar un modelo XSD y un modelo que contiene las trazas entre los elementos ambos modelos. Por todo lo anterior, se concluye que se han cumplido satisfactoriamente todos los objetivos planteados y se ha probado la hiptesis propuesta.

Conclusiones 273

7.2

Principales Contribuciones

A continuacin se enumeran las principales contribuciones de la presente tesis doctoral, que en su mayora se alinean directamente con los objetivos anteriores. Evolucin y actualizacin de un estudio y anlisis de propuestas centradas en el desarrollo dirigido por modelos de transformaciones de modelos. Una de las contribuciones del trabajo presentado en [31] es un anlisis de las propuestas centradas en la utilizacin de los principios de MDE para el desarrollo de transformaciones de modelos. En esta tesis doctoral se han analizado los resultados de dicho estudio as como otros trabajos ms recientes para conocer cmo se aplican los principios de MDE en el desarrollo de transformaciones de modelos y en particular, si las propuestas existentes consideran la gestin de la trazabilidad en el desarrollo de las transformaciones (seccin 3.2). Como resultado de este estudio se ha constatado la conveniencia de: aplicar los principios de MDE al desarrollo de transformaciones de modelos, definir niveles de abstraccin para el modelado de las transformaciones y potenciar la automatizacin en el proceso de desarrollo de las transformaciones. As mismo, se ha puesto de manifiesto que las propuestas centradas en el DDM de transformaciones de modelos no consideran la gestin de la trazabilidad. Un estudio y anlisis completo de propuestas para la gestin de la trazabilidad a partir de transformaciones de modelos. Dado que en el estudio anterior se comprob que ninguna de las propuestas para el DDM de transformaciones de modelos consideraba la gestin de la trazabilidad, se han analizado las propuestas que abordan la gestin de las trazas a partir de transformaciones de modelos, aunque no apliquen los principios de MDE para la construccin de dichas transformaciones. Dicho estudio, que ha sido presentado en la seccin 3.3 se ha llevado a cabo mediante un proceso de revisin sistemtica de la literatura. Este estudio puso de manifiesto varias debilidades o cuestiones inmaduras en el estado del arte: la no aplicacin de los principios de MDE al desarrollo de las transformaciones; dependencia de lenguajes de transformacin o aproximaciones concretas; falta de mecanismos especficos de visualizacin y anlisis de las trazas generadas; y, ausencia de herramientas completas que den soporte a las propuestas metodolgicas presentadas.

274

lvaro Jimnez Rielo

Por otro lado, tambin se recopil informacin relevante acerca del almacenamiento de las trazas generadas, los diferentes metamodelos de trazabilidad existentes y los elementos comunes de dichos metamodelos. Propuesta metodolgica para el DDM de transformaciones de modelos que incluyan generadores de trazas. Una de las principales contribuciones de esta tesis doctoral es la especificacin de la metodologa MeTAGeM-Trace para el DDM de transformaciones de modelos que incluyen generadores de modelos de trazas (captulo 4). Dicha metodologa surge como una evolucin de la metodologa MeTAGeM, presentada en [31]. La propuesta metodolgica MeTAGeM-Trace incorpora un meta-generador de trazabilidad en el proceso de DDM de transformaciones de modelos. Para ello, se especifica un metamodelo de trazabilidad y se definen nuevos metamodelos para el modelado de transformaciones a diferentes niveles de abstraccin. Adems, tambin se especifican las transformaciones M2M y M2T que permiten automatizar el desarrollo de transformaciones que incluyen generacin de trazas. Desarrollo de un entorno de DDM de transformaciones de modelos que incluye generadores de modelos de trazas. Otra de las principales contribuciones de esta tesis es la construccin de la herramienta MeTAGeM-Trace (captulo 5), que soporta tecnolgicamente a la propuesta metodolgica del mismo nombre. Para ello, por un lado se ha definido una arquitectura conceptual basada en capas y compuesta por un conjunto de mdulos ortogonales que implementan los distintos DSLs que componen la herramienta. Por otro lado, se ha definido un diseo tcnico que establece la relacin entre los componentes de la arquitectura conceptual y los medios tecnolgicos empleados para su construccin. En este punto, conviene destacar la naturaleza extensible e interoperable de MeTAGeM-Trace, que facilita la incorporacin de nuevas funcionalidades como por ejemplo soportar nuevas aproximaciones para el desarrollo de transformaciones a nivel PSM o nuevos lenguajes de transformaciones a nivel PDM (y cdigo), sin la necesidad de establecer puentes tecnolgicos entre las nuevas funcionalidades y las existentes. Implementacin de editores/visualizadores especficos para representacin de modelos de transformaciones y modelos de trazas. la

Conclusiones 275

Finalmente, otra de las contribuciones a destacar de esta tesis doctoral es la implementacin de editores/visualizadores ad-hoc, construidos a partir de los editores genricos proporcionados por EMF. Estos editores permiten la edicin y visualizacin de los modelos de transformacin y de los modelos de trazas, respetando y potenciando la naturaleza relacional de estos modelos. En particular, permiten visualizar al mismo tiempo los modelos origen, destino y el modelo de transformacin o modelo de trazas que los relaciona.

7.3

Resultados Cientficos

Algunos de los resultados relacionados con el desarrollo de esta tesis se han publicado en diferentes foros, tanto nacionales como internacionales. A continuacin se presentan las diferentes publicaciones, agrupadas por tipo de publicacin. No obstante, conviene mencionar que dada la naturaleza tcnica de esta tesis doctoral, para la publicacin en foros de impacto, ha sido necesario esperar a finalizar la implementacin de la herramienta. Por ello, en el momento de redactar esta memoria de tesis se cuenta con publicaciones de menor impacto que recogen resultados parciales de la misma. En la actualidad se est trabajando en la publicacin en foros de mayor impacto. Artculos en Conferencias Internacionales Jimnez, ., Granada, D., Bollati, V.A., Vara, J.M. (2011). Using ATL to support Model-Driven Development of RubyTL Model Transformations. Proceedings of the 3rd International Workshop on Model Transformation with ATL (MtATL 2011), Tools Europe 2011 Federated Conferences. Zurich, Suiza. Publicado en CEUR-WS Workshop Proceedings, vol. 742, pp. 35-48.

Artculos en Conferencias Nacionales Jimnez, ., Vara, J.M., Bollati, V.A., Marcos, E. (2011). Gestin de la Trazabilidad en el Desarrollo Dirigido por Modelos de Transformaciones de Modelos: una revisin de la literatura. XVI Jornadas de Ingeniera del Software y Bases de Datos (JISBD 2011). A Corua, Espaa. Jimnez, ., Vara, J. M., Bollati, V. A., Marcos, E. (2010). Mejorando el nivel de automatizacin en el desarrollo dirigido por modelos de editores grficos. VII Taller sobre Desarrollo de Software Dirigido por Modelos. DSDM10. Valencia, Espaa.

276

lvaro Jimnez Rielo

Captulos de Libros Nacionales Jimnez, ., Granada, D., Garca, A. (Pendiente de publicacin). EuGENia. Captulo del libro: Desarrollo de Software Dirigido por Modelos: Conceptos, Mtodos y Herramientas. Red Espaola de DSDM. Ed. Ra-Ma.

Registro de la Propiedad Intelectual Ttulo: SOD-M Tool: Una herramienta para el Modelado de Sistemas de Informacin siguiendo la Metodologa SOD-M. Inventores: E. Marcos, V. De Castro, . Jimnez N de Aplicacin: M-007589/2011 Pas: Espaa Fecha: 30/09/2011 Entidad Titular: Universidad Rey Juan Carlos Pases Participantes: Espaa Trabajos enviados Bollati, V.A., Vara, J.M., Jimnez, ., Marcos, E. Applying MDE to the (semi-) automatic development of model transformations. Information and Software Technology (JCR-Q1, Factor de impacto: 1,507). Enviado 20 de Noviembre, 2011. Recibida minor revision 15 de Marzo, 2012. Actualmente elaborando nueva versin. Santiago, I., Jimnez, ., Vara, J.M., De Castro, V., Bollati, V. A., Marcos, E. Model-Driven Engineering as a new landscape for Traceability Management: a Systematic Review. Information and Software Technology (JCR-Q1, Factor de impacto: 1,507). Enviado 05 de enero, 2012. Jimnez, ., Vara, J.M., Bollati, V.A., Marcos, E. Supporting traces generation in Model Transformations development. 21st International Conference on Information Systems Development (ISD2012). Prato, Italia. (CORE A). Jimnez, ., Vara, J.M., Bollati, V.A., Marcos, E. Developing a Multipanel Editor for EMF trace models. First workshop on ACademics Modelling with Eclipse (ACME), 8th European Conferences on Modelling Foundations and Applications (ECMFA 2012) . Lyngby, Dinamarca.

Conclusiones 277

Jimnez, ., Bollati, V. A., Vara, J. M., Marcos, E. Aplicando los principios del DSDM al desarrollo de transformaciones de modelos en ETL. XVII Jornadas de Ingeniera del Software y Bases de Datos (JISBD 2012). Almera, Espaa.

7.4

Trabajos Futuros

A partir de las contribuciones realizadas en esta tesis, se han detectado varias lneas de investigacin en las que seguir trabajando. Algunas de ellas simplemente no se haban considerado como objetivos de esta tesis, mientras que otras han surgido durante el desarrollo de la misma. A continuacin, se resumen las principales lneas futuras de investigacin.

7.4.1

Generacin y Gestin de Trazas en MDE

Aunque la trazabilidad siempre ha sido objeto de inters en el mbito de la Ingeniera de Software, con la aparicin de MDE, y ms especficamente del DSDM, la generacin y gestin de trazas ha cobrado mayor importancia. En particular, esta tesis doctoral ha presentado una propuesta para la generacin de modelos de trazas a partir del desarrollo dirigido por modelos de transformaciones de modelos. Sin embargo, an hay mucho espacio de mejora en este campo. As, las siguientes secciones presentan algunas de las lneas de investigacin en gestin de la trazabilidad en las que el Grupo Kybele trabaja en la actualidad. Este trabajo se est desarrollando en el marco de la tesis doctoral de Ivn Santiago. 7.4.1.1 Generacin de trazas a partir de transformaciones M2T Del mismo modo que las transformaciones de modelos definen implcitamente relaciones de trazabilidad que pueden aprovecharse para la generacin (semi-)automtica de modelos de trazas, esta idea puede ser traslada al desarrollo de transformaciones de modelo a texto. En este sentido existe una propuesta, que ha sido analizada en la seccin 3.3.4.8 de esta tesis doctoral, donde los autores proponen dos caminos alternativos: emplear la trazabilidad implcita del motor de transformaciones M2T de MOFScript o definir explcitamente de las relaciones de trazabilidad en las reglas de la transformacin de modelo a texto. En nuestra opinin, la principal debilidad de esta aproximacin es que no aplica los principios de MDE al desarrollo de las transformaciones de modelo a texto.

278

lvaro Jimnez Rielo

Por ello, se plantea el desarrollo de mtodos o tcnicas para la generacin de modelos de trazas a partir de las relaciones implcitas que se derivan de la ejecucin de una transformacin M2T, aplicando los principios de MDE a la construccin de dichas transformaciones. Una posible forma de abordar este planteamiento sera definir un entorno para el desarrollo dirigido por modelos de transformaciones de modelo a texto, de forma similar a como lo hace MeTAGeM-Trace para las transformaciones de modelos. 7.4.1.2 Anlisis de trazas Como se ha comentado en varias ocasiones a lo largo de esta tesis doctoral, en la literatura se reconoce la importancia de analizar la informacin de trazabilidad para llevar a cabo otras actividades del desarrollo software, como el anlisis del impacto del cambio, las pruebas de regresin, la validacin de los requisitos, el anlisis de cobertura, la toma de decisiones, la gestin de la configuracin y en general, cualquier tarea de mantenimiento del software [5, 9, 39, 40, 44, 113, 147, 152, 164, 183, 188, 200, 225]. Sin embargo, como se sealaba en la discusin del estudio sobre las propuestas para la gestin de la trazabilidad a partir de transformaciones de modelos (seccin 3.3.5), se han identificado pocas propuestas que muestren cmo utilizar la informacin de trazabilidad una vez que ha sido generada. Por ello, se plantea como lnea de investigacin futura la definicin de una propuesta para el anlisis de la trazabilidad en el contexto de MDE. 7.4.1.3 Control sobre los tipos de trazas generadas De acuerdo con Aizenbud-Reshef et al. [5], los diferentes stakeholders (diseadores, programadores, testers, jefes de proyecto, ingenieros de sistemas o clientes, etc. [231]) implicados en el proceso de desarrollo tienen diferentes objetivos a la hora de acceder a la informacin de la gestin de la trazabilidad. Por ejemplo, el cliente o el jefe de proyecto necesitarn trazar los requisitos para comprobar que son satisfechos por el sistema final. En cambio, los encargados del mantenimiento del sistema necesitarn consultar las trazas entre los artefactos de bajo nivel. Por tanto, resultara conveniente proporcionar distintos tipos de informacin de la trazabilidad, dependiendo de quin la requiera. Aunque el usuario puede modificarlo, el comportamiento por defecto de MeTAGeM-Trace es generar todas las trazas entre los elementos origen y destino de una transformacin. No obstante, en el contexto de la identificacin de distintos

Conclusiones 279

tipos de informacin para los distintos tipos de stakeholders, estas trazas podran verse como informacin de bajo nivel. Los usuarios probablemente necesiten informacin agregada, obtenida a partir de un pre-procesamiento de dichas trazas (por ejemplo, todos los modelos de trazas en los que est implicado un cierto objeto). As, se est trabajando para proporcionar distintos tipos de anlisis de las trazas del sistema, dependiendo del perfil del usuario. Concretamente, en estos momentos se ha establecido una distincin a la hora de proporcionar los anlisis de trazas, de acuerdo a dos tipos de perfiles: perfil analtico (clientes, jefes de proyecto, analistas, etc.) y perfil operativo (desarrolladores, encargados de mantenimiento, diseadores, testers, etc.).

7.4.2

Mejoras en el Desarrollo de Transformaciones de Modelos

Otra de las reas en las que MeTAGeM-Trace mejora el estado del arte es el desarrollo de las transformaciones de modelos. Aun siendo un rea ms madura que la de la gestin de la trazabilidad en MDE, aun dispone de un amplio margen de mejora [83, 221]. Por ello, en las siguientes sub-secciones se presentan algunas lneas de investigacin futuras relacionadas con el desarrollo de transformaciones de modelos. 7.4.2.1 Transformaciones bidireccionales La bidireccionalidad es un mecanismo que facilita el mantenimiento de la coherencia entre dos (o ms) fuentes de informacin relacionadas [48]. En el contexto de MDE, una transformacin bidireccional permitira sincronizar los modelos origen y destino, y debera tenerse en cuenta si se quieren soportar tareas como la evolucin de metamodelos y la co-evolucin de modelos o dar soporte a mecanismos de ingeniera inversa. A pesar de la utilidad de las transformaciones bidireccionales, se trata de uno de los aspectos menos afrontados por la comunidad de investigadores [48, 195]. En el entorno MeTAGeM-Trace se podra soportar la bidireccionalidad mediante la implementacin de nuevas transformaciones, que deberan ser inversas a las que ya forman parte de MeTAGeM-Trace, es decir, se deberan implementar las transformaciones: PSM-PIM y PDM-PSM. Adems, debera ser posible crear los modelos PDM a partir del cdigo de la transformacin (para el lenguaje ATL ya se soporta esta funcionalidad).

280

lvaro Jimnez Rielo

7.4.2.2

Parametrizacin de transformaciones Las transformaciones que forman parte de la implementacin de MeTAGeM-Trace (PIM-PSM, PSM-PDM) son cerradas, en el sentido de que su comportamiento siempre es el mismo. En otras palabras, para un mismo modelo origen siempre se obtendr el mismo modelo destino. Sin embargo, en muchas ocasiones resultara deseable soportar la introduccin de algunas decisiones de diseo que guen el proceso de desarrollo, especialmente cuando se baja a niveles dependientes de plataforma y es necesario indicar cmo los conceptos abstractos descritos en niveles superiores se convierten en objetos concretos de la plataforma elegida. En otros casos, el dominio de aplicacin de los modelos implicados en la transformacin, puede hacer que aparezcan ambigedades en el proceso de transformacin que no puedan ser resueltas de forma automtica en tiempo de ejecucin [10]. Para abordar este tipo de problemas, se propone parametrizar las transformaciones. Es decir, proporcionar mecanismos para que antes de ejecutar la transformacin, el usuario pueda introducir decisiones de diseo que, en cierto modo, guen su ejecucin. En trabajos anteriores [206, 207], se propona emplear modelos de weaving [58] como modelos de anotacin que permitiesen introducir parmetros o decisiones de diseo que guiasen la ejecucin de la transformacin. De esta forma, partiendo de un mismo modelo origen se podran generar diferentes modelos destino, dependiendo de la informacin contenida en el modelo de anotacin. Una posible lnea de investigacin futura pasar por aplicar esta aproximacin para soportar la parametrizacin de las transformaciones incluidas en MeTAGeM-Trace. De esta forma se podra guiar la ejecucn de dichas transformaciones para, por ejemplo, especificar que se generasen trazas slo de cierto nivel de abstraccin o entre los objetos de ciertos tipos, etc. Para poner en prctica esta tarea, se pueden emplear modelos de weaving con AMW [58, 102] o para evitar la dependencia de AMW, desarrollar un DSL para la parametrizacin de transformaciones de modelos, simulando el comportamiento de AMW, mediante EMF. 7.4.2.3 Anlisis de calidad de las transformaciones Es evidente que la calidad del software que se construye es un aspecto diferenciador, cada vez ms contemplado por las organizaciones que se dedican al desarrollo de software [59, 93, 175].

Conclusiones 281

En el caso del Desarrollo de Software Dirigido por Modelos, la calidad de las transformaciones de modelos afecta directamente a los artefactos obtenidos [188], ya que los modelos que definen el sistema son el resultado directo de la ejecucin de transformaciones [22, 78, 185, 199]. Por ello, sera deseable asegurar la calidad de las transformaciones que guan el proceso de desarrollo. En general, uno de los mtodos ms empleados para evaluar la calidad del software es el uso de mtricas. Dado que, en el campo de las transformaciones de modelos ya existen algunos trabajos en esta direccin [202, 203, 204, 205], se plantea el anlisis de dichos trabajos con el objetivo de determinar su aplicabilidad para evaluar la calidad de las transformaciones generadas a distintos niveles de abstraccin con MeTAGeM-Trace. De esta forma, sera posible detectar una baja calidad de las transformaciones a alto nivel, antes de generar los niveles inferiores o si se detectara mala calidad de las transformaciones a bajo nivel, sera posible subir el nivel de abstraccin para mejorarlas.

7.4.3

Aplicacin de los principios de MDE a la construccin de otros artefactos MDE

Del mismo modo que en esta tesis se defienden las ventajas de aplicar los principios de MDE al desarrollo de transformaciones de modelos, sera recomendable y deseable aplicar estos mismos principios al desarrollo de cualquier artefacto software en el mbito de MDE. A continuacin, se presentan algunas lneas de investigacin en esta direccin. 7.4.3.1 Validacin de modelos La validacin de los modelos implicados en un proceso de desarrollo dirigido por modelos puede considerarse como una medida de calidad, dado que permite detectar errores de modelado y establecer restricciones que no pueden contemplarse en la definicin de los metamodelos [146, 174]. En general, las reglas de validacin se establecen a nivel de metamodelo, especificando qu condiciones deben cumplir cada una de las instancias de las metaclases. Por ello, el esfuerzo que se debe realizar a la hora de implementar las reglas de validacin es directamente proporcional al nmero de metaclases contenidas en el metamodelo y al nmero de restricciones que deben cumplir las instancias de dichas metaclases. As, si la validacin de modelos se considera un medio para mejorar la calidad de los modelos, se debe establecer algn mtodo que facilite la

282

lvaro Jimnez Rielo

implementacin de las reglas de validacin, especialmente si estas son complejas y numerosas. Al igual que esta tesis ha mostrado cmo el desarrollo dirigido por modelos de transformaciones de modelos proporciona una serie de ventajas y facilidades al desarrollo de transformaciones que incorporan la generacin de la trazabilidad, tambin se pueden obtener ventajas de aplicacin de los principios de MDE a la construccin de reglas de validacin de modelos. Por ejemplo, desarrollos ms rpidos que alejan al desarrollador de la complejidad de codificar en un lenguaje concreto o generar (semi-)automticamente la implementacin de las reglas de validacin en distintos lenguajes (EVL, OCL, etc.). 7.4.3.2 Desarrollo Dirigido por Modelos de Editores de modelos En general, como se ha mostrado en esta tesis y puede comprobarse en otros trabajos anteriores [100, 206], a pesar de la existencia de frameworks que facilitan la construccin de editores de modelos, esta tarea suele implicar bastante trabajo de refinamiento y recodificacin. Por ello, teniendo en cuenta que los editores de modelos son otro artefacto ms del sistema y que su construccin resulta compleja, una futura lnea de investigacin es el desarrollo dirigido por modelos de editores de modelos. Siguiendo un proceso similar al propuesto por MeTAGeM-Trace, sera posible definir un modelo a nivel PIM que describa la representacin de los elementos de un metamodelo, de forma independiente de plataforma. Dicho modelo podra ser transformado en un modelo a nivel PSM que describa dicha representacin de acuerdo a las caractersticas de las aproximaciones ms comunes (por ejemplo, representaciones grficas, representaciones textuales, etc.) y finalmente, se podra definir un nivel PDM que defina la representacin de los elementos de acuerdo a las caractersticas de los framework que facilitan el desarrollo de editores (por ejemplo, EMF o Graphiti). Actualmente se trabaja en esta lnea en el marco de la tesis doctoral de David Granada, becario FPI del Grupo Kybele. En concreto, se est trabajando en el desarrollo de un meta-editor que permita realizar la implementacin de editores, tanto grficos como textuales.

7.4.4

Mejoras en el contexto de la herramienta MeTAGeM-Trace

En esta seccin se presentan las futuras lneas de investigacin en el contexto de la herramienta MeTAGeM-Trace, presentada en esta tesis.

Conclusiones 283

Implementar otros metamodelos de trazabilidad. Actualmente, la herramienta ofrece soporte para la generacin de modelos de trazas conformes a un metamodelo de trazabilidad genrico. Dichos modelos registran las trazas derivadas de la ejecucin de la transformacin generada, los elementos implicados en dichas trazas y el tipo de operacin que ha generado la traza (transformacin, borrado y creacin). Sin embargo, es posible que en algunas ocasiones los usuarios deseen almacenar otro tipo de informacin adicional como por ejemplo la fecha de creacin de la traza o el usuario que ejecuta la transformacin. Del mismo modo, en otros casos puede que se requiera menor nivel detalle. Por ello, como posible trabajo futuro se plantea la implementacin de otros metamodelos de trazabilidad que permitan registrar diferente informacin acerca de las trazas generadas. Otra posibilidad puede ser la definicin de un metamodelo base que incluya elementos bsicos y pueda ser extendido, agregando nuevos elementos, para generar metamodelos de trazabilidad especficos. Implementar otros metamodelos a nivel PSM para dar soporte a otras aproximaciones de desarrollo de transformaciones. Como se especifica a lo largo de esta tesis, a nivel PSM, MeTAGeM-Trace propone el modelado de las transformaciones siguiendo la aproximacin hbrida. Como trabajo futuro se propone el desarrollo de nuevos DSLs para soportar el resto de aproximaciones (declarativa, imperativa, basada en grafos, etc.). As, tras modelar la transformacin a alto nivel, el desarrollador podra seleccionar la aproximacin que considere ms adecuada para implementar la transformacin. Implementar transformaciones entre los metamodelos definidos a nivel PSM. Una vez que se soportase el modelado de la transformacin para distintas aproximaciones a nivel PSM, sera interesante realizar transformaciones horizontales entre los modelos definidos al mismo nivel pero siguiendo diferentes aproximaciones, de forma que, por ejemplo, sea posible pasar (semi-)automticamente de un modelo para la aproximacin hbrida a un modelo para la aproximacin declarativa. Implementar otros lenguajes de transformacin a nivel PDM y cdigo. Una vez que se soporte el modelado de la transformacin para distintas aproximaciones, tambin sera deseable soportar a nivel PDM (y a nivel de cdigo), al menos, un lenguaje de transformacin que implemente cada una de las aproximaciones soportadas. Para ello, sera necesario especificar e

284

lvaro Jimnez Rielo

implementar un metamodelo que permita modelar la transformacin, de acuerdo a las caractersticas propias del nuevo lenguaje; una transformacin entre el metamodelo a nivel PSM y el metamodelo a nivel PDM; un conjunto de reglas de validacin para los modelos PSM que permita comprobar su validez antes de ser transformados a nivel PDM; y, un generador de cdigo que serialice los modelos PDM en el cdigo que implementa la transformacin para el lenguaje elegido. Implementar transformaciones de modelos inversas. Como se ha comentado anteriormente, una futura lnea de investigacin es dar soporte bidireccional a las transformaciones de MeTAGeM-Trace. Para ello, es necesario especificar e implementar transformaciones de modelos inversas a las que incluye MeTAGeM-Trace. Es decir, se debe especificar e implementar un conjunto de reglas de transformacin para pasar de modelos PDM a modelos PSM y de modelos PSM a modelos PIM. Implementar inyectores de modelos. En la misma lnea de dar soporte a la bidireccionalidad en MeTAGeM-Trace, del mismo modo que es posible obtener el cdigo de la transformacin a partir de los modelos PDM, sera deseable obtener los modelos a partir del cdigo. De hecho, el plug-in de ATL para Eclipse da soporte para realizar esta tarea. Para implementar estos inyectores para otros lenguajes, se estn analizando herramientas como EMFText (http://www.emftext.org) o Xtext (http://www.eclipse.org/Xtext/). Actualizar la herramienta a las ltimas versiones. Cuando se comenz a implementar MeTAGeM-Trace, se utilizaron las ltimas versiones disponibles en ese momento de Eclipse (3.6.1), EMF (2.6), ATL (3.2), Epsilon (0.9) y MOFScript (1.4.0.3). Sin embargo, durante el proceso de construccin de MeTAGeM-Trace se han publicado nuevas versiones de Eclipse (3.7), EMF (2.7), ATL (3.2.1) y Epsilon (0.9.1). Por tanto, uno de los trabajos futuros es la actualizacin de la herramienta MeTAGeM-Trace.

Apndice A: Detalles de las Revisiones Sistemticas

Apndice A.
Sistemtica

Detalles del Proceso de Revisin

En la seccin 2.2 de esta memoria de tesis doctoral se ha presentado el mtodo de identificacin del cuerpo de conocimiento, el cual consiste en un proceso de revisin sistemtica de la literatura [27, 111]. Posteriormente, en la seccin 3.3 se ha presentado una revisin sistemtica para la identificacin y anlisis de propuestas de gestin de la trazabilidad a partir de transformaciones de modelos . En dicha seccin se presentan los aspectos clave del proceso y el anlisis de las propuestas identificadas. Como complemento, en este apndice se presentan algunos detalles del proceso de revisin sistemtica (RS) realizado. En concreto, se presentan las decisiones tomadas en la fase de planificacin (seccin A.1), los resultados obtenidos y los estudios primarios seleccionados durante la fase de ejecucin (seccin A.2) y las limitaciones o debilidades del proceso de revisin sistemtica realizado (seccin A.3).

A.1 Planificacin
La fase de planificacin consiste en la definicin del objetivo de investigacin y del protocolo para llevar a cabo la revisin [27]. En concreto, se deben definir aspectos tales como: preguntas de investigacin, estrategias de bsqueda (fuentes de informacin y trminos clave), criterios de inclusin y exclusin y los datos que se extraern de cada estudio. A continuacin se presentan cada uno de estos aspectos.

A.1.1 Cuestiones de Investigacin

Uno de los primeros pasos del proceso de RS es definir el objetivo principal de la investigacin. En este caso se trata de: identificar y analizar propuestas centradas en generar y gestionar informacin de trazabilidad a partir del desarrollo de transformaciones de modelos. Para alcanzar este objetivo principal, se define un conjunto de cuestiones de investigacin (CI). En esta RS se han definido las siguientes CI:

288

lvaro Jimnez Rielo

CI-1. Qu nivel de automatizacin ofrecen o sugieren las propuestas metodolgicas para generar informacin de trazabilidad? Aunque en este estudio de la literatura el objetivo principal no es analizar si las propuestas aplican los principios de MDE al desarrollo de transformaciones, s que resulta interesante conocer qu tareas es posible automatizar y hasta qu nivel. As ser posible conocer si, en el estado del arte actual, la generacin de la trazabilidad se considera una tarea manual o si por el contrario, se proporcionan mtodos que la automaticen (completa o parcialmente).

CI-2. Segn las propuestas metodolgicas identificadas, cmo se deberan almacenar, visualizar y analizar las trazas generadas? Como se ha indicado en la introduccin de esta memoria de tesis doctoral, la informacin de trazabilidad puede ser muy til para llevar a cabo otras actividades del ciclo de vida software como por ejemplo el anlisis de impacto del cambio, la toma de decisiones o el mantenimiento general del sistema [5, 39, 40, 113, 147]. Por tanto, resulta interesante conocer cmo, segn las propuestas metodolgicas, deberan llevarse a cabo ciertas tareas relacionadas con la gestin de las trazas, como el almacenamiento (en modelos de trazas, en repositorios de trazas, embebidas en los modelos terminales, etc.), la visualizacin (de forma grfica o textual) y las tcnicas para facilitar su anlisis (informes tcnicos, estudios estadsticos, clasificaciones, etc.).

CI-3. Existen herramientas o marcos de trabajo que ofrezcan soporte tecnolgico para la gestin de la trazabilidad en el contexto del desarrollo de transformaciones de modelos? Una de las principales metas de este estudio de la literatura es identificar si las propuestas para la generacin y gestin de la trazabilidad a partir del desarrollo de transformaciones de modelos han sido puestas en prctica por medio de herramientas MDE. Por tanto, el objetivo de esta cuestin de investigacin es analizar si las propuestas existentes ofrecen algn tipo de soporte tecnolgico.

CI-4. Cules son las limitaciones encontradas en las propuestas para la gestin de informacin de trazabilidad a partir de transformaciones de modelos?

Detalles del Proceso de Revisin Sistemtica 289

Finalmente, en la ltima cuestin se combinarn las respuestas a las preguntas anteriores (CI-1, CI-2 y CI-3) para identificar problemas o limitaciones en el estado del arte actual de la gestin de la trazabilidad a partir de transformaciones de modelos.

A.1.2 Fuentes de Informacin y cadenas de bsqueda

En la fase de planificacin tambin se debe definir una estrategia de bsqueda para los estudios que contribuirn a la revisin sistemtica. Dicha estrategia consiste, bsicamente, en definir dnde se buscarn los estudios y qu palabras clave se usarn para realizar las bsquedas [27, 111]. Debido a las facilidades que ofrece Internet en cuanto a la cantidad de informacin disponible y al mbito en el que se desarrolla esta tesis doctoral, para llevar a cabo esta RS se ha decidido realizar las bsquedas en fuentes de informacin digitales que se encuentran disponibles de forma online. En concreto, se han seleccionado las siguientes bibliotecas de datos: ACM Digital Library (ACM). CiteSeerX (CSX). IEEEXplore (IEEEX). Google Scholar (GS). ISI Web of Knowledge (ISI). Science Direct (SD). SpringerLink (SL). The Collection of Computer Science Bibliographies (CSB).

Para realizar las bsquedas de los estudios en estas fuentes de informacin se ha establecido un conjunto de palabras clave, relacionadas con el objetivo principal de investigacin: (meta-)trazabilidad, transformaciones de modelos, dirigido por modelos y las siglas de las principales disciplinas dirigidas por modelos (MDE, MDD, MDSD y MDA). Estas palabras clave se han combinado mediante operadores lgicos, dando lugar a la siguiente cadena de bsqueda: (meta-traceability or traceability) AND (mda OR mdsd OR mdd OR mde OR model driven OR model transformation).

290

lvaro Jimnez Rielo

Conviene destacar que la mayora de los motores de bsqueda digitales solo admiten consultas a partir de cadenas de bsqueda, definidas en su sintaxis particular. Por ello, la cadena de bsqueda definida ha tenido que ser adaptada a la sintaxis que acepta cada uno de los motores de bsqueda.

A.1.3 Criterios de Inclusin y Exclusin

Aunque la cadena de bsqueda se ha definido teniendo en cuenta el objetivo principal de investigacin, es posible que un nmero considerable de los estudios obtenidos en las bsquedas no proporcionen informacin relevante acerca de dicho objetivo. As, de acuerdo con [111], es necesario definir criterios de inclusin y exclusin para filtrar los estudios obtenidos. En este proceso de RS se han incluido aquellos estudios que hayan sido publicados online antes de Marzo de 2011 y que cumplan al menos uno de los siguientes criterios de inclusin: Su resumen (abstract) indica que el objetivo del trabajo es la gestin o generacin de la trazabilidad en el mbito de MDE. Su ttulo o palabras clave incluyen los trminos (o sus derivados): trazabilidad y dirigido por modelos o trazabilidad y transfo rmacin de modelos.

A partir de los criterios de inclusin definidos es posible realizar un primer filtrado de los estudios obtenidos, sin embargo, es posible que muchos de ellos no proporcionen informacin suficientemente relevante para el objetivo buscado. As, se procede a leer por completo estos trabajos y se excluye aquellos que cumplan alguno de los siguientes criterios de exclusin: Consideren la gestin o generacin de la trazabilidad como una tarea deseable pero no proporcionen informacin acerca de cmo abordarla. Estn dirigidos a la gestin o generacin de la trazabilidad sin tener en cuenta a los principales artefactos de MDE: modelos y transformaciones de modelos. Su principal objetivo es clasificar otros trabajos o sean revisiones sistemticas en s mismos.

Detalles del Proceso de Revisin Sistemtica 291

A.1.4 Criterios de Evaluacin

Una vez que se han seleccionado aquellos trabajos que cumplen con los criterios de inclusin y no han sido descartados por los de exclusin, sera deseable disponer de mecanismos que permitan evaluar y comparar dichos estudios. Por tanto, de acuerdo a la gua propuesta por Kitchenham y Charters [111], para evaluar las propuestas y proporcionar una comparativa cuantitativa entre ellas, en esta RS se ha definido un conjunto de criterios de evaluacin (CE) y un conjunto de valores que pueden adoptar dichos criterios. Los valores que se les pueden asignar para cada uno de los criterios de evaluacin son: (S) = 1; (P)arcial = 0.5; y (N)o = 0. Los criterios de evaluacin para las propuestas centradas en la gestin de la trazabilidad a partir de transformaciones de modelos son: CE-1. La propuesta metodolgica sugiere o indica cmo se debera automatizar la identificacin de las relaciones de trazabilidad? (Recurdese que las relaciones de trazabilidad son aquellas que se definen entre tipos de elementos, por ejemplo clases o elementos de un metamodelo) Valores: (S), proporciona o especfica algn mtodo para mejorar el nivel de automatizacin de esta tarea; (P)arcial, no indica cmo debera automatizarse, pero lo considera deseable; (N)o, la propuesta no considera la automatizacin de la identificacin de las relaciones de trazabilidad, por tanto la asume como una tarea manual. CE-2. La propuesta metodolgica sugiere o indica cmo se debera automatizar la generacin de las trazas? (Recurdese que los enlaces de trazas, o simplemente trazas, son las instancias de las relaciones de trazabilidad, por ejemplo, entre objetos o elementos de un modelo). Valores: (S), la propuesta define cmo sera posible automatizar la generacin de las trazas; (P)arcial, la propuesta no especifica cmo automatizar esta tarea, aunque considera que sera deseable automatizarla; (N)o, no considera la automatizacin de la generacin de trazas. Es decir, se considera una actividad manual. CE-3. La propuesta para la gestin de la informacin de trazabilidad es independiente de cualquier lenguaje de transformacin concreto? Valores: (S), la propuesta es independiente de cualquier lenguaje de transformacin; (P)arcial, no es completamente independiente, o es

292

lvaro Jimnez Rielo

dependiente de un lenguaje concreto pero consideran deseable que fuera independiente; (N)o, la propuesta se define para un lenguaje concreto. CE-4. Propone alguna tcnica para el almacenamiento de las trazas? Valores: (S), la propuesta sugiere cmo almacenar las trazas generadas, en general, existen dos aproximaciones: almacenamiento interno (en los modelos terminales que describen el sistema) y almacenamiento externo (en otras estructuras de datos ad-hoc); (P)arcial, considera que el almacenamiento de las trazas es una caracterstica a tener en cuenta, pero no sugiere ningn mtodo de almacenamiento; (N)o, no considera el almacenamiento de las trazas. CE-5. Propone alguna tcnica para la visualizacin o representacin de las trazas? Valores: (S), sugiere el desarrollo de una herramienta ad-hoc para la visualizacin de trazas o sugiere el empleo de mecanismo existente para este propsito; (P)arcial, sugiere el empleo de visualizaciones no especficas para la representacin de trazas, es decir son representaciones genricas y por tanto, el resultado no es ptimo. Por ejemplo, si las trazas son almacenadas en modelos y emplea un editor de modelos genrico como el que ofrece EMF; (N)o, la propuesta no sugiere ningn tipo de mecanismo para la visualizacin de trazas. CE-6. Sugiere o propone tcnicas para llevar a cabo el anlisis de la informacin de trazabilidad generada? Valores: (S), la propuesta centra parte de sus objetivos en proporcionar tcnicas de anlisis de la informacin de trazabilidad; (P)arcial, la propuesta considera interesante clasificar o analizar la informacin obtenida a partir de las trazas, pero no especfica cmo hacerlo; (N)o, la propuesta no considera el anlisis de las trazas. CE-7. Proporciona alguna implementacin, herramienta, o soporte tecnolgico? Valores: (S), proporciona una herramienta o marco de trabajo completo para dar soporte a la propuesta metodolgica; (P)arcial, proporciona una implementacin parcial de la propuesta; (N)o, se trata de una propuesta puramente terica que no ofrece implementacin para ponerla en prctica.

Detalles del Proceso de Revisin Sistemtica 293

A.1.5 Extraccin de Datos y Anlisis

Finalmente, en la fase de planificacin tambin se deben definir los datos que se recogern de cada uno de los trabajos y sus propuestas. A partir de estos datos ser posible dar respuesta a los criterios de evaluacin y a las cuestiones de investigacin, establecidas anteriormente. As, en esta RS se ha decidido extraer la siguiente informacin: Ttulo, autores, resumen y ao de publicacin de cada estudio identificado (perteneciente a la propuesta). Si las relaciones de trazabilidad se identifican de forma (semi-)automtica o si el usuario debe especificarlas manualmente. Nivel de abstraccin de la transformacin en el que se identifican las relaciones de trazabilidad (en el cdigo de la transformacin o en algn modelo de la transformacin a alto nivel). Si la informacin de trazabilidad puede ser generada a partir de una transformacin independiente de cualquier lenguaje de transformacin o, si por el contrario, depende de un lenguaje o motor de transformacin especfico. Si las trazas se generan (semi-)automticamente o si por el contrario, debe crearlas el usuario. La forma de almacenar los enlaces de traza (en modelos de trazas, repositorios, modelos del sistema, etc.). Tipo de metamodelo de trazabilidad propuesto (especfico o genrico), si aplica. Esto es, una propuesta puede proporcionar un metamodelo de trazabilidad genrico para todos los escenarios o puede permitir la definicin de un metamodelo especfico para cada escenario de trazabilidad concreto. La forma en que se visualizan/representan las trazas. Las tcnicas que proporciona para el anlisis de las trazas. Si ofrece soporte tecnolgico y cmo lo hace (si aplica).

Con el objetivo de simplificar el anlisis de esta informacin y de los estudios en general, se ha decidido organizar los estudios en Grupos de Estudios Primarios (GPS, Group of Primary Studies). Cada GPS contiene a aquellos estudios que tienen uno o ms autores en comn y las ideas que se defienden en

294

lvaro Jimnez Rielo

dichos artculos se corresponden a una misma lnea de investigacin o al menos, son una evolucin de una misma hiptesis inicial.

A.2 Ejecucin
La fase de ejecucin de la RS consiste bsicamente en la ejecucin de las bsquedas y la seleccin de los estudios primarios que contribuyen a dar respuesta al objetivo de investigacin planteado. Por ello, en esta seccin se presentan los resultados obtenidos en la ejecucin de las bsquedas (seccin A.2.1) y la lista de los estudios primarios seleccionados (seccin A.2.2).

A.2.1 Bsqueda de Estudios Primarios

En el proceso de bsqueda, con el objetivo de maximizar los resultados obtenidos, se ha decidido ejecutar las bsquedas en el mayor mbito que permiten cada uno de los motores. En este contexto, mbito es entendido como la parte de los estudios en los que se buscarn las cadenas de bsqueda. En la Tabla A-1, se presentan el mbito seleccionado para cada motor de bsqueda as como la cadena de bsqueda adaptada.
Tabla A-1. Cadenas de Bsqueda adaptadas y mbito de bsqueda

Fuente
ACM CSX IEEEX GS ISI SD SL CSB

Cadena de Bsqueda Adaptada

(meta-traceability or traceability) and (mda or mdsd or mdd or mde or "model driven" or model transformation) ((meta-traceability OR traceability) AND (mda OR mdsd OR mdd OR mde OR "model driven" OR model transformation)) ((meta-traceability OR traceability) AND (mda OR mdsd OR mdd OR mde OR "model driven" OR model transformation)) (meta-traceability OR traceability) + (mda OR mdsd OR mdd OR mde OR "model driven" OR model transformation) TS=((meta-traceability OR traceability) AND (mda OR mdsd OR mdd OR mde OR "model driven" OR model transformation)) ALL((meta-traceability OR traceability) AND (mda OR mdsd OR mdd OR mde OR "model driven" OR model transformation)) ((meta-traceability OR traceability) AND (mda OR mdsd OR mdd OR mde OR "model driven" OR model transformation)) (meta-traceability OR traceability) AND (mda OR mdsd OR mdd OR mde OR "model driven" OR model transformation)

mbito
Title, Abstract, Review Text All All Topic All All Author, Title

Detalles del Proceso de Revisin Sistemtica 295

Como resultado de la ejecucin de estas bsquedas, se ha obtenido un total de 10.028 resultados. Las dos primeras columnas de la Tabla A-2 muestran el nmero de estudios devueltos por cada una de las fuentes de informacin. Para cada uno de estos estudios se ha evaluado su comportamiento frente a los criterios de inclusin y tan solo 267 de ellos, es decir el 2,66%, los han cumplido, y en consecuencia, se han convertido en estudios relevantes de la RS. En la tercera columna de la Tabla A-2 (Estudios Relevantes) puede comprobarse el nmero de estudios seleccionados de cada fuente de informacin. Adems, en la columna 4, se muestra el porcentaje de estudios relevantes de cada fuente de informacin respecto del total de resultados proporcionados por dicha fuente. As, por ejemplo, los 40 estudios relevantes obtenidos de ACM suponen un 9,71% del total de resultados proporcionados por la fuente (412 estudios). Finalmente, en la ltima columna se muestra el porcentaje que supone el nmero de estudios relevantes identificados en una fuente de informacin respecto del total obtenido, es decir 267. As, a modo de ejemplo, los 40 estudios relevantes de ACM representan el 14,98% de los 267 estudios seleccionados como relevantes para la RS.
Tabla A-2. Resultados de las bsquedas

Fuente
ACM CSX IEEEX GS ISI SD SL CSB

Resultados
412 451 923 69805 86 259 863 54

Estudios Relevantes
40 26 21 82 25 9 47 17

% estudios relevantes vs. resultados

9.71 % 5.76 % 2.28 % 1.17 % 29.07 % 3.47 % 5.45 % 31.48 %

% sobre el total de estudios relevantes

14.98 % 9.74 % 7.87 % 30.71 % 9.36 % 3.37 % 17.60 % 6.37 %

Total

10028

267

2.66 %

100 %

Google Scholar solo muestra los 1000 primeros resultados.

296

lvaro Jimnez Rielo

Dado que estas fuentes de informacin pueden compartir un alto nmero de estudios, es posible que parte de los estudios seleccionados hasta el momento, se hayan encontrado en varias fuentes, es decir que entre los 267 estudios relevantes pueden existir varias copias de un mismo trabajo. Por ello, el siguiente paso consiste en identificar dichas copias y eliminarlas. Como se muestra en la Tabla A-3, ms del 40% de los estudios relevantes son copias repetidas. As, una vez eliminadas estas duplicidades, se obtiene una lista de 157 estudios que son evaluados respecto del criterio de exclusin. Como resultado, solo 20 de ellos (es decir, un 12,78% de los estudios relevantes no duplicados) se convierten en estudios primarios de la RS. La lista completa de estos estudios primarios se presenta en la siguiente seccin.
Tabla A-3. Filtrado de estudios duplicados

Estudios
Estudios relevantes Estudios relevantes duplicados Estudios relevantes NO duplicados 267 110 157

Porcentaje
100 % 41.20 % 58.80 %

A.2.2 Estudios Primarios seleccionados

Una vez ejecutadas las bsquedas, evaluado los estudios de acuerdo a los criterios de inclusin y exclusin y eliminado las duplicidades, se han identificado los siguientes estudios primarios que contribuyen a la RS:
Tabla A-4. Lista de Estudios Primarios
Autores Allilaire Barbero, Del Fabro y Bzivin Bonde, Boulet y Dekeyser Boronat, Cars y Ramos Drivalos, Kolovos, Paige y Fernandes Drivalos, Kolovos, Paige y Fernandes Drivalos, Paige, Fernandes y

Ttulo del Estudio Primario

Towards traceability support in ATL with Obeo Traceability Traceability and provenance issues in global model management Traceability and interoperability at different levels of abstraction in model-driven engineering Automatic support for traceability in a generic model management framework A state-based approach to traceability maintenance Engineering a DSL for software traceability Towards Rigorously Defined Model- to-Model

Ref.
[6] [17] [33] [36] [61] [60] [62]

Detalles del Proceso de Revisin Sistemtica 297

Autores Kolovos Falleri, Huchard y Nebut Grammel y Kastenholz Guerra, de Lara, Kolovos y Paige Jouault Kolovos, Paige y Polack Kurtev, Van den Berg y Jouault Levendovszky, Balasubramanian, Smyth, Shi y Karsai Melby Oldevik y Neple Olsen and Oldevik Paige, Drivalos, Kolovos, Fernandes, Power, Olsen y Zschaler Snchez, Alonso, Rosique, lvarez y Pastor Valderas y Pelechano

Ttulo del Estudio Primario

Traceability Towards a traceability framework for model transformations in kermeta A generic traceability framework for facet-based traceability data extraction in model-driven software development Inter-modelling: From theory to practice Loosely Coupled Traceability for ATL On-Demand Merging of Traceability Links with Models Evaluation of rule-based modularization in model transformation languages illustrated with ATL A transformation instance-based approach to traceability Traceability in Model Driven Engineering Traceability in Model to Text Transformations Scenarios of Traceability in Model to Text Transformations Rigorous identification and encoding of trace-links in model-driven engineering Introducing safety requirements traceability support in model-driven development of robotic applications Introducing requirements traceability support in modeldriven development of web applications

Ref.
[68] [82] [87] [103] [117] [127] [134] [143] [150] [153] [163] [181] [200]

A.3 Limitaciones
Como se ha mencionado en varias ocasiones a lo largo de esta memoria de tesis doctoral, para llevar a cabo el proceso de revisin sistemtica se han seguido las guas propuestas por Kitchenham y Charters [111] y Biolchini [27]. No obstante, el proceso seguido se desva ligeramente de las pautas indicadas por dichas guas en los siguientes aspectos: No se han realizado bsquedas manuales. Debido a las posibilidades que ofrecen las nuevas tecnologas y en particular Internet, actualmente la mayor parte de los estudios publicados se encuentran disponibles para su consulta de forma online. Por ello en esta RS, el proceso de bsqueda de estudios se ha realizado nicamente mediante bsquedas en medios digitales. Esta desviacin puede hacer que

298

lvaro Jimnez Rielo

no se hayan identificado algunos trabajos publicados en revistas o actas de congresos que no se encuentren online. No se ha seguido el criterio PICOC (Population, Intervention, Comparison, Outcome and Context. En espaol: poblacin o problema, intervencin, comparacin, resultados o salidas y contexto) para la definicin de las cuestiones de investigacin. En la gua para el desarrollo de revisiones sistemticas de Kitchenham y Charters [111], se recomienda seguir el criterio PICOC, propuesto por Petticrew y Roberts en [166], para definir las cuestiones de investigacin. A pesar de que no se haya empleado este criterio de forma explcita para la definicin de las preguntas de investigacin, es cierto que se cumplen algunos de los componentes de este criterio. Por ejemplo, el contexto de las cuestiones definidas es MDE y la poblacin (problema) es la gestin de la trazabilidad. Aunque esta desviacin puede implicar que las cuestiones de investigacin definidas puedan ser de alguna manera desestructuradas o subjetivas, conviene mencionar que son resultado de un proceso iterativo en el que han sido mejoradas y refinadas en varias ocasiones. La revisin no ha sido revisada por expertos externos. A pesar de no haber contactado con expertos externos para la evaluacin de la revisin sistemtica, es necesario mencionar que una versin inicial de algunos de los principales resultados y conclusiones extradas fue presentada en las Jornadas de Ingeniera del Software y Bases de Datos (JISBD), celebradas en A Corua en septiembre de 2011 [101]. As mismo, tambin es necesario destacar que, durante el desarrollo de la revisin sistemtica, el doctorando hizo el papel de investigador mientras que los directores de esta tesis y otros miembros del Grupo Kybele actuaron como revisores, proporcionando evaluaciones internas.

Apndice B: Manual de Usuario de MeTAGeM-Trace

Apndice B.

Manual de Usuario de MeTAGeM-Trace

En este apndice se presenta el manual de usuario completo de la herramienta MeTAGeM-Trace, presentada en el captulo 5 de esta tesis doctoral.

B.1 Introduccin
MeTAGeM-Trace es una meta-herramienta para el desarrollo dirigido por modelos de transformaciones de modelos. Su principal caracterstica es que las transformaciones obtenidas incluyen un generador de trazas, de forma que cuando sean ejecutadas, adems de los modelos destino, crearn modelos que contienen las trazas entre los elementos implicados en la transformacin. El funcionamiento de la herramienta consiste bsicamente en que a partir de un modelado de la transformacin a alto nivel, realizado por el usuario, se generan de forma semi-automtica sucesivos modelos de la transformacin a menor nivel, hasta obtener el cdigo que implementa la transformacin en un lenguaje de transformaciones seleccionado por el usuario. La transformacin generada con MeTAGeM-Trace incluye un generador de trazas. Para dar soporte a esta funcionalidad, la herramienta se compone de un conjunto de lenguajes especficos de dominio (DSLs, Domain Specific Languages [220, 222]) que permiten el modelado y la visualizacin de la transformacin a diferentes niveles de abstraccin as como de las trazas generadas. Estos DSLs se dividen en cuatro niveles de abstraccin: Nivel independiente de plataforma (PIM), donde el usuario debe definir las relaciones entre los elementos de los metamodelos implicados en la transformacin. Este nivel se representa mediante los modelos MeTAGeM (extensin .metagem). Nivel especfico de plataforma (PSM), donde se describen las reglas de la transformacin y las relaciones de trazabilidad, de acuerdo a un paradigma o aproximacin de desarrollo de transformaciones. En este caso, la herramienta ofrece soporte para la aproximacin hbrida. Este nivel se representa mediante los modelos de aproximacin hbrida (extensin .hybrid). Nivel dependiente de plataforma (PDM), donde se especifica la transformacin en trminos del metamodelo que describe un lenguaje de transformacin concreto. De acuerdo a la aproximacin soportada a nivel PSM, MeTAGeM-Trace permite la definicin de modelos conformes a los

302

lvaro Jimnez Rielo

metamodelos de dos lenguajes que siguen la aproximacin hbrida: ATL [107] (ficheros atl.ecore) y ETL [118] (ficheros .etl_model). Cdigo. Implementa la transformacin modelada en el lenguaje de transformacin seleccionado por el usuario. En este caso, ATL o ETL.

B.2 Instalacin
En esta seccin se detallan los pasos para llevar a cabo la instalacin de la herramienta MeTAGeM-Trace: Instalar la Mquina Virtual de Java. En concreto, para el desarrollo de la herramienta se ha empleado la versin 1.6, por lo que se recomienda utilizar una versin igual o superior. Instalar el entorno Eclipse y la herramienta MeTAGeM-Trace. Para realizar esta tarea existen dos posibilidades:

Recomendado: Descargar la distribucin Eclipse-MeTAGeM-Trace que contiene el entorno Eclipse Modeling Tools y todos los plug-ins necesarios para el funcionamiento de la herramienta MeTAGeM-Trace. Se encuentra disponible para su descarga en: Una vez finalizada la descarga, slo se debe descomprimir el archivo.

http://www.kybele.es/members/ajimenez/thesis/software/Eclipse-MeTAGeM-Trace.zip

Instalar Eclipse y MeTAGeM-Trace por separado. Si no se dispone del entorno Eclipse, est disponible para su descarga en: http://www.eclipse.org/downloads/. De entre las distribuciones disponibles, se recomienda Eclipse Modeling Tools. Para el correcto funcionamiento de MeTAGeM-Trace, Eclipse debe tener instalados los siguientes plug-ins: EMF 2.6 ATL 3.2 Epsilon 0.9 MOFScript 1.4.0.3

Una vez que se dispone de Eclipse y los plug-ins mencionados, puede instalarse el conjunto de plug-ins de MeTAGeM-Trace, que se encuentra disponible para su descarga en:
http://www.kybele.es/members/ajimenez/thesis/software/MeTAGeM-Trace-Plugins.zip

Manual de Usuario de MeTAGeM-Trace 303

B.3 Modelado de la Transformacin Independiente de Plataforma

Para comenzar con el modelado de las transformaciones independientes de plataforma, el primer paso consiste en la creacin de un modelo MeTAGeM. Para ello, la herramienta MeTAGeM-Trace proporciona un asistente de creacin de este tipo de modelos al que se puede acceder a travs del men de Eclipse: FileNewOtherMeTAGeM-TraceMeTAGeM (Figura B-1). De la misma forma, el usuario puede crear otros modelos conformes a los DSLs de MeTAGeM-Trace.

Figura B-1. Seleccin del Asistente de Creacin para modelos MeTAGeM

Una vez seleccionado el tipo de modelo a crear, se debe seleccionar la ruta en la que se almacenar el nuevo modelo y posteriormente, como muestra la Figura B-2, se deben seleccionar los metamodelos origen y destino de la transformacin que se va a desarrollar.

304

lvaro Jimnez Rielo

Figura B-2. Creando el modelo de la Transformacin Independiente de Plataforma

A partir de la informacin introducida por el usuario en el asistente, se crea el nuevo modelo MeTAGeM, donde se pueden definir las relaciones de transformacin entre los elementos de los metamodelos origen y destino. Como se muestra en la Figura B-3, MeTAGeM-Trace proporciona un visor/editor compuesto por tres paneles para representar: metamodelos origen (izquierda), modelo que define la transformacin a alto nivel (centro) y metamodelos destino (derecha).

Figura B-3. Nuevo modelo de la Transformacin Independiente de Plataforma

Manual de Usuario de MeTAGeM-Trace 305

El siguiente paso en la definicin del modelo de transformacin es la especificacin de las diferentes relaciones entre los elementos de los metamodelos implicados en la transformacin. Para ello, se debe hacer clic con el botn secundario sobre el elemento raz del modelo (Model Root) y en la opcin New child seleccionar el tipo de relacin que se quiere definir (Figura B-4).

Figura B-4. Tipos de Relaciones

Como se puede comprobar en la Figura B-4, se pueden crear diferentes tipos de relaciones, dependiendo de su cardinalidad. As por ejemplo, el tipo de relacin OneToOne sirve para indicar que un nico elemento del metamodelo origen se relaciona con un nico elemento del metamodelo destino, de la misma manera, la relacin ManyToOne sirve para indicar que a partir de varios elementos del metamodelo origen se genera un nico elemento destino. En la Figura B-5, se muestra cmo especificar los elementos origen y destino que participan en una relacin OneToOne. En este caso, el elemento origen ya ha sido seleccionado anteriormente (Father). Para definir el elemento destino, se selecciona el elemento en el metamodelo destino (Male) y se arrastra hasta el elemento OneToOne del modelo de la transformacin (panel central). El editor de modelos ha sido implementado de forma que el usuario solo tiene que arrastrar el elemento y la propia herramienta se encarga de identificar si dicho elemento es origen o destino, dependiendo del metamodelo al que pertenezca. Adems, es importante mencionar que el editor solo permite arrastrar elementos mientras su cardinalidad no se haya completado, es decir, al definir una relacin de tipo OneToOne slo es posible seleccionar un elemento origen y un elemento destino. As, una vez que se hayan seleccionado estos elementos se deshabilita la posibilidad de seguir agregando ms.

306

lvaro Jimnez Rielo

Figura B-5. Especificando el elemento destino en una relacin OneToOne

De la misma forma se pueden crear relaciones incluidas en elementos destino. El objetivo de estas relaciones es definir transformaciones entre los atributos de los elementos. As, por ejemplo, como muestra la Figura B-6, se especifica que la propiedad fullName del elemento Male se genera a partir de la propiedad firstName del elemento Father.

Figura B-6. Creando una relacin incluida en un elemento destino

Manual de Usuario de MeTAGeM-Trace 307

B.4 Modelado de la Transformacin Especfica de Plataforma

A partir del modelo independiente de plataforma definido en la seccin anterior, es posible obtener de forma (semi-)automtica el modelo de transformacin especfico de plataforma. Como se ha comentado anteriormente, la implementacin actual de la herramienta MeTAGeM-Trace permite el modelado a nivel PSM de las transformaciones siguiendo la aproximacin hbrida. Para obtener el modelo de la transformacin a nivel PSM se debe hacer clic con el botn secundario sobre el modelo especificado a nivel PIM (modelo MeTAGeM), y seleccionar Run As MeTAGeM->Hybrid. En dicho men contextual, la herramienta MeTAGeM-Trace solo muestra las transformaciones disponibles para el tipo de modelo seleccionado. As, en este caso, la nica transformacin disponible para un modelo metagem es MeTAGeM -> Hybrid. Antes de ejecutar la transformacin se comprueba la validez del modelo MeTAGeM y si es vlido, se ejecuta la transformacin. Como resultado, se obtiene un modelo conforme al metamodelo de nivel PSM (aproximacin hbrida) que contiene las reglas de la transformacin y las relaciones de trazabilidad entre los elementos de los metamodelos. En la Figura B-7 se muestra el proceso para obtener el modelo PSM.

Figura B-7. Generando un modelo Hybrid a partir de un modelo MeTAGeM

308

lvaro Jimnez Rielo

La herramienta MeTAGeM-Trace permite refinar el modelo generado, agregando, modificando o eliminando elementos. El modelo de la transformacin a nivel PIM, slo permite establecer relaciones entre los elementos de los metamodelos, por lo que el modelo generado a nivel PSM slo contiene elementos de tipo Rule y de tipo TraceLink (TraceRule o Trace Binding). Sin embargo, muchas veces es necesario definir algn tipo de funcin especial que genere o recupere algn tipo de informacin. Para ello, se pueden definir elementos de tipo Operation. En la Figura B-8 se muestra la forma de crear un elemento de este tipo. Para ello se debe hacer clic con el botn secundario sobre el elemento raz del modelo y seleccionar la opcin New Child Operation.

Figura B-8. Creando un elemento Operation

Una vez creado el elemento se deben completar sus propiedades y elementos hijos. En el ejemplo que se muestra en la Figura B-8 se ha creado un elemento de tipo Operation cuyo atributo name es getFatherName, su valor de retorno es String y su contexto, el elemento origen Father. Del mismo modo, se pueden definir los parmetros de la operacin y cuerpo de la misma.

Manual de Usuario de MeTAGeM-Trace 309

Otro de los aspectos que debe ser modelado de forma manual por el usuario es el valor de los elementos de tipo RightPattern. En una relacin de tipo Binding, el RightPattern se encarga de describir el valor que se asigna al elemento LeftPattern. Cuando el valor de la asignacin se corresponde con un elemento origen como por ejemplo en la relacin creada en la Figura B-6 (fullName:=firstName), es posible definirlo a nivel PIM. En cambio, cuando el valor que se asigna es resultado de una operacin, es un valor concreto o se refiere a otro elemento destino, el usuario debe especificarlo a travs de los atributos del elemento RightPattern. A modo de ejemplo, en la Figura B-9, se muestra cmo definir una operacin creada anteriormente (getFatherName) como origen para una relacin de tipo Binding. As, a partir de ahora al atributo destino fullName se le asignar el resultado de la operacin: fullName:= getFatherName().

Figura B-9. Definiendo el atributo Operation de un elemento RightPattern

Continuando con la definicin de las relaciones de tipo Binding, en los elementos origen de las mismas, es necesario que el usuario defina explcitamente a qu elementos origen de la regla pertenecen (atributo belongsTo). En el caso de los elementos destino no es necesario porque cada relacin Binding pertenece a un elemento destino de la regla, por tanto, los elementos destino del Binding pertenecen a l. A modo de ejemplo, en la Figura B-10 puede verse una relacin mother2female que contiene dos elementos origen (member y mother) y un elemento destino (female). En el elemento destino se ha definido una relacin binding para modelar la creacin del atributo fullName de dicho elemento. Para

310

lvaro Jimnez Rielo

definir el valor de este atributo se emplean dos elementos entrada (firstName y familyMother.lastName). Para obtener, en niveles inferiores, la implementacin correcta de esta asociacin es necesario indicar la pertenencia de estos sub-elementos. As, el elemento familyMother.lastName pertenece al elemento entrada de la regla Mother.

Figura B-10. Definiendo los atributos BelongsTo

Es necesario destacar que cuando la regla a la que pertenece el Binding contiene un solo elemento origen, la herramienta realiza de forma automtica la asignacin del atributo belongsTo. Como se ha indicado anteriormente, el modelo de aproximacin hbrida permite definir relaciones de trazabilidad. Para ello, proporciona dos tipos de elementos: TraceRule y TraceBinding. El primero sirve para definir una traza que se deriva de una regla de transformacin y el elemento TraceBinding, para una traza que se deriva de una relacin Binding. En la Figura B-11 se muestra cmo crear un elemento de tipo TraceRule. Dado que estos elementos estn contenidos en los elementos Rule que especifican las reglas de la transformacin, la herramienta MeTAGeM-Trace establece, de forma automtica, los elementos origen y destino de la relacin de trazabilidad a partir de los elementos origen y destino del elemento Rule.

Manual de Usuario de MeTAGeM-Trace 311

Figura B-11. Creando un elemento Trace Rule

Del mismo modo, se puede crear un elemento de tipo TraceBinding. La diferencia entre este elemento y el anterior es que, como muestra la Figura B-12, a la hora de crear un TraceBinding, el usuario debe especificar a qu binding corresponde la relacin de trazabilidad. De esta forma, la herramienta MeTAGeM-Trace establece los elementos origen y destino de la relacin de trazabilidad, que se corresponden con el origen y destino del binding.

Figura B-12. Creando un elemento Trace Binding

B.5 Modelado de la Transformacin Dependiente de Plataforma

A nivel PDM, la versin actual de MeTAGeM-Trace propone el modelado de las transformaciones de acuerdo a dos lenguajes de transformacin que siguen la aproximacin hbrida: ATL y ETL. Por lo tanto, el usario debe seleccionar en

312

lvaro Jimnez Rielo

qu lenguaje desea implementar las transformaciones antes de realizar la transformacin. Como muestra la Figura B-13, la accin Run As del men contextual de los modelos PSM, que describen la transformacin de acuerdo a las caractersticas de la aproximacin hbrida (modelos hybrid), proporciona dos opciones de transformacin: Hybrid ATL y Hybrid ETL. Si se selecciona la primera opcin (Hybrid ATL), se obtiene un modelo de transformacin conforme al metamodelo del lenguaje ATL. En cambio, si se selecciona la segunda ( Hybrid ETL), se obtiene un modelo conforme al metamodelo del lenguaje ETL.

Figura B-13. Transformacin de PSM a PDM

En ambos casos, antes de realizar la ejecucin, se realiza de forma automtica el proceso de validacin del modelo definido a nivel PSM, teniendo en cuenta el modelo destino. Si la validacin es correcta se generarn los modelos PDM como muestra la Figura B-13. En caso contrario, el usuario recibir un mensaje por pantalla que le indicar los errores detectados.

B.6 Generacin de Cdigo

Para obtener el cdigo que implementa la transformacin a partir del modelo PDM, MeTAGeM-Trace proporciona una entrada en el men contextual de dichos modelos, ya sean conformes al metamodelo de ATL o al de ETL.

Manual de Usuario de MeTAGeM-Trace 313

Para obtener el cdigo de la transformacin en el lenguaje ATL, se debe hacer clic con el botn secundario sobre el modelo ATL y seleccionar la opcin Extract ATL model to ATL file (MeTAGeM-Trace). Como resultado, se obtiene un archivo con extensin .atl que contiene el cdigo que implementa la transformacin en dicho lenguaje (Figura B-14).

-- @atlcompiler atl2006 module familes2persons; create Persons_model : Persons, in2out_trace : TRACE from Families_model : Families; -- Comments -> This is a MatchedRule: Father_2_Male -> rule Father_2_Male { from father_in : Families!Father to male_out : Persons!Male ( fullName <- father_in.getFatherName() ), Father_2_Male_TL1 : TRACE!TraceLink ( name <- 'Father_2_Male', traceModel <- thisModule.getTraceModelRoot, operation <- #Transform, source <- Sequence {father_in_Trace_TE1}, target <- Sequence {male_out_Trace_TE11},

Figura B-14. Generando el cdigo de la transformacin en ATL

Del mismo modo, haciendo clic con el botn secundario sobre el modelo ETL y seleccionando la opcin Extract ETL model to ETL file (MeTAGeM-Trace), se obtiene el fichero de cdigo que implementa la transformacin en ETL (Figura B-15).

pre { 'Running ETL: familes2persons Transformation'.println(); var traceModel: new Traceability!TraceModel; traceModel.name = 'familes2persons_traces'; var Families_model_var: new Traceability!SourceModel; Families_model_var.name = 'Families_model'; Families_model_var.metamodel = '/metagem_F2P/Metamodels/Families.ecore'; traceModel.sourceModels.add(Families_model_var); var Persons_model_var: new Traceability!TargetModel; Persons_model_var.name = 'Persons_model'; Persons_model_var.metamodel = '/metagem_F2P/Metamodels/Persons.ecore'; traceModel.targetModels.add(Persons_model_var);} rule Father_2_Male transform father : Families!Father to male : Persons!Male, Father_2_Male : Traceability!TraceLink, R8 : Traceability!TraceLink, Father_trace : Traceability!SourceElement, Male_trace : Traceability!TargetElement, fullName_trace : Traceability!TargetElement { male.fullName := father.getFatherName(); Father_trace.name := father.getName(); Father_trace.ref := father.eResource().getURIFragment(father); Father_trace.`model` := Families_model_var;

Figura B-15. Generando el cdigo de la transformacin en ETL

314

lvaro Jimnez Rielo

B.7 Generacin del Modelo de Trazas

Siguiendo los pasos anteriores, el usuario habr obtenido el cdigo de la transformacin que contiene de forma embebida un generador de trazas. As, cuando se ejecute la transformacin sobre los modelos origen se generar, adems de los modelos destino, un modelo adicional que contendr las trazas entre los elementos de los modelos anteriores. Este modelo de trazas tendr una estructura similar al mostrado en la Figura B-16. Para llevar a cabo la ejecucin de las transformaciones, el usuario deber configurar los lanzadores de ejecucin de la forma requerida por el lenguaje en el que est implementada la transformacin (ATL o ETL).

Figura B-16. Ejemplo de Modelo de Trazas

Referencias

Referencias
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Abdelhalim, I., Sharp, J., Schneider, S., & Treharne, H. (2010), "Formal Verification of Tokeneer Behaviours Modelled in fUML Using CSP", in Formal Methods and Software Engineering. vol. 6447, J. Dong &H. Zhu, Eds., ed: Springer Berlin / Heidelberg, pp. 371-387. Abran, A. & Moore, J. W. (2004), Guide to the Software Engineering Body of Knowledge: IEEE Computer Society. Acua, C., Minoli, M., & Vara, J. M. (2009), "Model Driven Development of Semantic Web Services using Eclipse", in Mexican International Conference on Computer Science, ENC'09 , Mexico City (Mexico), 2009. Acua, C. J. (2007), "PISA Arquitectura de integracin de portales Web: un enfoque dirigido por modelos y basado en servicios Web semnticos", PhD thesis, Universidad Rey Juan Carlos (October 2007). Aizenbud-Reshef, N., Nolan, B. T., Rubin, J., & Shaham-Gafni, Y. (2006), "Model traceability", IBM Systems Journal, vol. 45 (3), pp. 515-526. Allilaire, F. (2009), "Towards Traceability support in ATL with Obeo Traceability", presented at the 1st International Workshop on Model Transformation with ATL (MtATL2009), Nantes, France, 2009, pp. 150-153. Allilaire, F., Bzivin, J., Jouault, F., & Kurtev, I. (2006), "ATL-eclipse support for model transformation", 2006. Allilaire, F. & Jouault, F. (2007), "ATL Use Case - Families to Persons", ATLAS, INRIA & University of Nantes. http://www.eclipse.org/m2m/atl/doc/ATLUseCase_Families2Persons.pdf. Anquetil, N., Kulesza, U., Mitschke, R., Moreira, A., Royer, J.-C., Rummler, A., & Sousa, A. (2010), "A model-driven traceability framework for software product lines", Software and Systems Modeling, vol. 9 (4), pp. 427-451. Aquino, N., Vanderdonckt, J., & Pastor, O. (2010), "Transformation templates: adding flexibility to model-driven engineering of user interfaces", presented at the Proceedings of the 2010 ACM Symposium on Applied Computing, Sierre, Switzerland, 2010, pp. 1195-1202. Asuncion, H. (2008), "Towards practical software traceability", in Companion of the 30th international conference on Software engineering, Leipzig, Germany, 2008, pp. 1023-1026. Asuncion, H. U., Asuncion, A. U., & Taylor, R. N. (2010), "Software traceability with topic modeling", in Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 1, Cape Town, South Africa, 2010, pp. 95-104. Atkins, C. & Louw, G. (2000), "Reclaiming Knowledge: A case for evidence-based information systems", 2000, pp. 39-45. Atkinson, C. & Kuhne, T. (2003), "Model-Driven Development: A Metamodeling Foundation", IEEE Software, vol. 20 (5), pp. 36-41. ATL (2006), "ATL: User Manual", version 0.7. Retrieved from http://www.eclipse.org/m2m/atl/doc/ATL_User_Manual[v0.7].pdf. Balasubramanian, D., Narayanan, A., van Buskirk, C., & Karsai, G. (2007), "The graph rewriting and transformation language: GReAT", Electronic Communications of the EASST. Barbero, M., Del Fabro, M. D., & Bezivin, J. (2007), "Traceability and provenance issues in global model management", in Proceedings of International Conference on Systems Engineering and Modelling (ICSEM07), 2007. Basili, V. R. (1996), "The role of experimentation in software engineering: past, current, and future", presented at the Proceedings of the 18th international conference on Software engineering, Berlin, Germany, 1996, pp. 442-449. Basili, V. R., Selby, R. W., & Hutchens, D. H. (1986), "Experimentation in software engineering", IEEE Transactions on Software Engineering, vol. 12 (7), pp. 733-743. Baxter, P. & Jack, S. (2008), "Qualitative case study methodology: Study design and implementation for novice researchers", The Qualitative Report, vol. 13 (4), pp. 544-559.

21. 22. 23. 24.

25.

26. 27. 28. 29. 30. 31. 32.

33. 34. 35. 36. 37. 38. 39. 40. 41.

Bernstein, P. (2003), "Applying model management to classical meta data problems", in First Biennial Conference on Innovative Data Systems Research, Asilomar, CA, USA, 2003. Bzivin, J. (2004), "In search of a basic principle for model driven engineering", Novatica Journal, Special Issue, vol. V (2), pp. 21-24. Bzivin, J. (2005), "On the unification power of models", Software and Systems Modeling, vol. 4 (2), pp. 171-188. Bzivin, J., Bttner, F., Gogolla, M., Jouault, F., Kurtev, I., & Lindow, A. (2006), "Model Transformations? Transformation Models!", in Model Driven Engineering Languages and Systems. vol. 4199, O. Nierstrasz, J. Whittle, D. Harel , & G. Reggio, Eds., ed: Springer Berlin / Heidelberg, pp. 440-453. Bzivin, J., Farcet, N., Jzquel, J.-M., Langlois, B., & Pollet, D. (2003), "Reflective Model Driven Engineering", in UML 2003 - The Unified Modeling Language. Modeling Languages and Applications. vol. 2863, P. Stevens, J. Whittle , & G. Booch, Eds., ed: Springer Berlin / Heidelberg, pp. 175-189. Bezivin, J. & Gerbe, O. (2001), "Towards a precise definition of the OMG/MDA framework", in Automated Software Engineering, 2001. (ASE 2001). Proceedings. 16th Annual International Conference on, 2001, pp. 273-280. Biolchini, J., Mian, P. G., Natali, A. C. C., & Travassos, G. H. (2005), "Systematic review in software engineering", System Engineering and Computer Science Department COPPE/UFRJ, Technical Report ES, vol. 679 (05). Birrell, N. & Ould, M. A. (1988), A practical handbook for software development: Cambridge University Press. Birsan, D. (2005), "On Plug-ins and Extensible Architectures", ACM Queue, vol. 3 (2), pp. 4046. Blumberg, R. & Atre, S. (2003), "The problem with unstructured data", DM REVIEW, vol. 13 pp. 42-49. Bollati, V. A. (2011), "MeTAGeM: Entorno de Desarrollo de Transformaciones de Modelos Dirigido por Modelos", PhD thesis, Universidad Rey Juan Carlos (February 2011). Bollati, V. A., Snchez, E. V., Vela, B., & Marcos, E. (2009), "Anlisis de QVT Operational Mappings: un caso de estudio", VI Taller sobre Desarrollo de Software Dirigido por Modelos (DSDM). Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos (JISBD2009). vol. 3 (2). Bonde, L., Boulet, P., & Dekeyser, J. L. (2006), "Traceability and interoperability at different levels of abstraction in model-driven engineering", Applications of specification and design languages for SoCs: selected papers from FDL 2005, p. 263. Booch, G., Rumbaugh, J., & Jacobson, I. (2000), El Lenguaje Unificado de Modelado, manual de referencia: Addison Wesley, Madrid. Boronat, A. (2007), "MOMENT: a formal framework for MOdel manageMENT", PhD in Computer Science, Universitat Politenica de Valencia (UPV), Spain . Boronat, A., Cars, J., & Ramos, I. (2005), "Automatic Support for Traceability in a Generic Model Management Framework", in 1st European Conference on Model-Driven Architecture Foundations and Applications (ECMDA-FA'05), Nuremberg, Germany, 2005. Bourque, P. & Dupuis, R. (2004), "Guide to the Software Engineering Body of Knowledge 2004 Version", Guide to the Software Engineering Body of Knowledge, 2004. SWEBOK. Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., & Yergeau, F. (2000) "Extensible markup language (XML) 1.0", ed: W3C Brcina, R. & Riebisch, M. (2008), "Defining a traceability link semantics for design decision support", in Proceedings of the 4th European Conference on Model Driven Architecture Traceability Workshop (ECMDA-TW'08), Berlin, Germany, 2008, pp. 39-48. Briand, L. C., Labiche, Y., & O'Sullivan, L. (2003), "Impact analysis and change management of UML models", in Software Maintenance, 2003. ICSM 2003. Proceedings. International Conference on, 2003, pp. 256-265. Budgen, D. & Brereton, P. (2006), "Performing systematic literature reviews in software engineering", presented at the Proceedings of the 28th international conference on Software engineering, Shanghai, China, 2006, pp. 1051-1052.

42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63.

Budinsky, F. (2004), Eclipse modeling framework: a developer's guide : Addison-Wesley Professional. Bunge, M. (1983), La investigacin cientfica. Barcelona: Ed. Ariel. Campos, P. & Nunes, N. J. (2007), "Practitioner Tools and Workstyles for User-Interface Design", IEEE Softw., vol. 24 (1), pp. 73-80. Clark, T., Sammut, P., & Willans, J. (2008), "Applied metamodelling: a foundation for language driven development". -Oliet, N., Meseguer, J., & Quesada, J. F. (2002), "Maude: specification and programming in rewriting logic", Theoretical Computer Science, vol. 285 (2), pp. 187-243. Clayberg, E. & Rubel, D. (2006), Eclipse: Building Commercial-Quality Plug-ins (Eclipse): Addison-Wesley Professional. Czarnecki, K., Foster, J., Hu, Z., Lmmel, R., Schrr, A., & Terwilliger, J. (2009), "Bidirectional Transformations: A Cross-Discipline Perspective", in Theory and Practice of Model Transformations. vol. 5563, R. Paige, Ed., ed: Springer Berlin / Heidelberg, pp. 260-283. Czarnecki, K. & Helsen, S. (2003), "Classification of Model Transformation Approaches", presented at the OOPSLA03 Workshop on Generative Techniques in the Context of Model Driven Architecture, 2003. Czarnecki, K. & Helsen, S. (2006), "Feature-based survey of model transformation approaches", IBM Systems Journal, vol. 45 (3), pp. 621-645. Dausend, M. & Raiser, F. (2011), "Model Transformation using Constraint Handling Rules as a basis for Model Interpretation", in Proceedings of the Eighth International Workshop on Constraint Handling Rules, El Cairo, Egypt, 2011, pp. 64 - 78. de Castro, M. (2007), "Aproximacin MDA para el desarrollo orientado a servicios de sistemas de informacin web: del modelo de negocio al modelo de composicin de servicios web", PhD thesis, Universidad Rey Juan Carlos (March 2007). de Castro, V., Marcos, E., & Cceres, P. (2004), "A user service oriented method to model web information systems", Web Information SystemsWISE 2004, pp. 41-52. de Castro, V., Marcos, E., & Lopez Sanz, M. (2006), "A model driven method for service composition modelling: a case study", International Journal of Web Engineering and Technology, vol. 2 (4), pp. 335-353. de Castro, V., Mesa, J. M., Herrmann, E., & Marcos, E. (2008), "A Model Driven Approach for the Alignment of Business and Information Systems Models", in Mexican International Conference on Computer Science, 2008. ENC '08. , Baja California, Mexico, 2008, pp. 33-43. de Castro, V., Mesa, J. M., Herrmann, E., & Marcos, E. (2009), "From Real Computational Independent Models to Information System Models: An MDE Approach", in 4th International Workshop on Model-Driven Web Engineering (MDWE 2008), Toulouse, France., 2009. de Castro, V., Vara, J. M., & Marcos, E. (2007), "Model transformation for service-oriented web applications development", in 3rd International Workshop on Model-Driven on Web Engineering (MDWE 2007), Como, Italy, 2007, pp. 284-198. Didonet Del Fabro, M. (2007), "Metadata management using model weaving and model transformation", PhD thesis, Universit de Nantes. Dorling, A. (1993), "SPICE: Software Process Improvement and Capability Determination", Software Quality Journal, vol. 2 (4), pp. 209-224. Drivalos, N., Kolovos, D., Paige, R., & Fernandes, K. (2009), "Engineering a DSL for Software Traceability Software Language Engineering", in Software Language Engineering. vol. 5452, ed: Springer Berlin / Heidelberg, pp. 151-167. Drivalos, N., Kolovos, D., Paige, R., & Fernandes, K. (2010), "A state-based approach to traceability maintenance", presented at the Proceedings of the 6th ECMFA Traceability Workshop, Paris, France, 2010, pp. 23-30. Drivalos, N., Paige, R., Fernandes, K., & Kolovos, D. (2008), "Towards rigorously defined model-to-model traceability", in Proceedings of the 4th European Conference on Model Driven Architecture - Traceability Workshop (ECMDA-TW'08), Berlin, Germany, 2008, pp. 17-26. Eckstein, R., Loy, M., & Wood, D. (1998), Java swing: O'Reilly & Associates, Inc.

64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86.

Eclipsepedia. (2011). ATL/Developer Guide. Available in: http://wiki.eclipse.org/ATL/Developer_Guide Edwards, G., Seo, C., & Medvidovic, N. (2008), "Model Interpreter Frameworks: A foundation for the analysis of Domain-specific software architectures", Journal of Universal Computer Science, vol. 14 (8), pp. 1182-1206. Egyed, A. (2004), "Resolving uncertainties during trace analysis", SIGSOFT Softw. Eng. Notes, vol. 29 (6), pp. 3-12. Eisenhardt, K. M. (1989), "Building Theories from Case Study Research", The Academy of Management Review, vol. 14 (4), pp. 532-550. Falleri, J. R., Huchard, M., & Nebut, C. (2006), "Towards a traceability framework for model transformations in kermeta", in Procedings of the 2th European Conference on Model Driven Architecture - Traceability Workshop (ECMDA-TW'06), Bilbao, Spain, 2006. Favre, J. M. (2004), "Towards a basic theory to model model driven engineering", presented at the Workshop on Software Model Engineering, WISME 2004, Lisbon, Portugal, 2004. Feuerlicht, G., Pokorn, J., & Richta, K. (2009), "Object-Relational Database Design: Can Your Application Benefit from SQL:2003?", in Information Systems Development, C. Barry, M. Lang, W. Wojtkowski, K. Conboy , & G. Wojtkowski, Eds., ed: Springer US, pp. 975-987. Flore, F. (2003), "MDA: The proof is in automating transformations between models", OptimalJ White Paper, pp. 14. Fowler, M. (2009), "Code Generation for Dummies", in METHODS & TOOLS, ed: Spring, pp. 65 - 89. Fowler, M. & Parsons, R. (2010), Domain-specific languages: Addison-Wesley Professional. Frankel, D. S. (2002), Model Driven Architecture: Applying MDA to Enterprise Computing. New York, USA: John Wiley & Sons. Gallardo, D., Burnette, E., & McGovern, R. (2003), Eclipse in action: a guide for Java developers: Manning Publications. Gamma, E., Acebal, C. F., & Lovelle, J. M. C. (2003), Patrones de diseo: elementos de software orientado a objetos reutilizable: Addison-Wesley. Gamma, E. & Beck, K. (2004), Contributing to Eclipse: principles, patterns, and plug-ins: Addison-Wesley Professional. Gerber, A., Lawley, M., Raymond, K., Steel, J., & Wood, A. (2002), "Transformation: The Missing Link of MDA ", in Graph Transformation. vol. 2505, A. Corradini, H. Ehrig, H. Kreowski , & G. Rozenberg, Eds., ed: Springer Berlin / Heidelberg, pp. 90-105. Gervais, M. P. (2002), "Towards an MDA-oriented methodology", in Computer Software and Applications Conference, 2002. COMPSAC 2002. Proceedings. 26th Annual International, 2002, pp. 265-270. Gknil, A., Topaloglu, N. Y., & van den Berg, K. G. (2008) "Operation Composition in Model Transformations with Complex Source Patterns", ed. Enschede: Centre for Telematics and Information Technology, University of Twente. Gotel, O. C. Z. & Finkelstein, C. W. (1994), "An analysis of the requirements traceability problem", in Proceedings of the First International Conference onRequirements Engineering, Colorado Springs, CO , USA 1994, pp. 94-101. Grammel, B. & Kastenholz, S. (2010), "A generic traceability framework for facet-based traceability data extraction in model-driven software development", presented at the Proceedings of the 6th ECMFA Traceability Workshop, Paris, France, 2010, pp. 7-14. Gray, J. (2010), "Model comparison: the marrow of model transformation", presented at the Proceedings of the 1st International Workshop on Model Comparison in Practice, Malaga, Spain, 2010, pp. 1-1. Greenwald, R., Stackowiak, R., & Stern, J. (2004), Oracle Essentials, 3e: Oracle Database 10g: O'Reilly & Associates, Inc. Gronback, R. C. (2009), Eclipse modeling project: a domain-specific language toolkit: AddisonWesley Professional. Grunbacher, P., Rabiser, R., Dhungana, D., & Lehofer, M. (2009), "Model-based customization and deployment of Eclipse-based tools: Industrial experiences", in 24th IEEE/ACM

87. 88.

89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100.

101.

102. 103. 104. 105.

International Conference on Automated Software Engineering, 2009. ASE '09. , Auckland, New Zealand, 2009, pp. 247-256. Guerra, E., de Lara, J., Kolovos, D., & Paige, R. (2010), "Inter-modelling: From Theory to Practice", in Model Driven Engineering Languages and Systems. vol. 6394, D. Petriu, N. Rouquette , & . Haugen, Eds., ed: Springer Berlin / Heidelberg, pp. 376-391. Guerra, E., de Lara, J., Kolovos, D., Paige, R., & dos Santos, O. (2010), "transML: A Family of Languages to Model Model Transformations", in Model Driven Engineering Languages and Systems. vol. 6394, D. Petriu, N. Rouquette , & . Haugen, Eds., ed: Springer Berlin / Heidelberg, pp. 106-120. Guerra, E., de Lara, J., Kolovos, D., Paige, R., & dos Santos, O. (2011), "Engineering model transformations with transML", Software and Systems Modeling, pp. 1-23. Guttman, M. & Parodi, J. (2007), Real-life MDA: solving business problems with model driven architecture: Morgan Kaufmann. Hailpern, B. & Tarr, P. (2006), "Model-driven development: The good, the bad, and the ugly", IBM Systems Journal, vol. 45 (3), pp. 451-461. Hayes, J. H., Dekhtyar, A., & Sundaram, S. K. (2006), "Advancing candidate link generation for requirements tracing: the study of methods", Software Engineering, IEEE Transactions on, vol. 32 (1), pp. 4-19. Herbsleb, J., Zubrow, D., Goldenson, D., Hayes, W., & Paulk, M. (1997), "Software quality and the Capability Maturity Model", Commun. ACM, vol. 40 (6), pp. 30-40. IBM. (2011). Rational Rose Product line. Available in: http://www01.ibm.com/software/awdtools/developer/rose/index.html IEEE (1990), "IEEE Standard Glossary of Software Engineering Terminology", IEEE Std 610.12-1990. ISO (1995), "Information technology Software life cycle processes", International Organization for Standardization ISO/IEC 12207:1995. ISO&IEC (2003) "ISO/IEC 9075:2003. Information technology Database languages SQL:2003", ed: ISO (International Standards Organization for Standardization) & IEC (International Electrotechnical Commission). Jacobson, I., Booch, G., & Rumbaugh, J. (1999), The Unified Software Development Process The complete guide to the Unified Process from the original designers : Addison-Wesley Professional. Jimnez, ., Granada, D., Bollati, V. A., & Vara, J. M. (2011), "Using ATL to support ModelDriven Development of RubyTL Model Transformations", in 3rd International Workshop on Model Transformation with ATL (MtATL2011), Zrich, Switzerland, 2011, pp. 35 - 48. Jimnez, ., Vara, J. M., Bollati, V., & Marcos, E. (2010), "Mejorando el nivel de automatizacin en el desarrollo dirigido por modelos de editores grficos", in VII Taller sobre Desarrollo de Software Dirigido por Modelos (DSDM 2010), XV Jornadas de Ingeniera del Software y Bases de Datos (JISBD, 2010), Valencia, Spain, 2010, pp. 29 - 37 Jimnez, ., Vara, J. M., Bollati, V. A., & Marcos, E. (2011), "Gestin de la trazabilidad en el desarrollo dirigido por modelos de Transformaciones de Modelos: una revisin de la literatura", in XVI Jornadas de Ingeniera del Software y Bases de Datos (JISBD2011) , A Corua, Spain, 2011, pp. 783-796. Jossic, A., Del Fabro, M. D., Lerat, J. P., Bezivin, J., & Jouault, F. (2007), "Model Integration with Model Weaving: a Case Study in System Architecture", in Systems Engineering and Modeling, 2007. ICSEM '07. International Conference on , 2007, pp. 79-84. Jouault, F. (2005), "Loosely coupled traceability for ATL", presented at the 1st European Conference on Model-Driven Architecture Foundations and Applications (ECMDA-FA'05), Nuremberg, Germany, 2005. Jouault, F., Allilaire, F., Bzivin, J., & Kurtev, I. (2008), "ATL: A model transformation tool", Science of Computer Programming, vol. 72 (1-2), pp. 31-39. Jouault, F., Allilaire, F., Bzivin, J., Kurtev, I., & Valduriez, P. (2006), "ATL: a QVT-like transformation language", presented at the Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications, Portland, Oregon, USA, 2006, pp. 719-720.

106. Jouault, F., Bzivin, J., & Kurtev, I. (2006), "TCS: a DSL for the specification of textual
concrete syntaxes in model engineering", presented at the Proceedings of the 5th international conference on Generative programming and component engineering, Portland, Oregon, USA, 2006, pp. 249-254. Jouault, F. & Kurtev, I. (2006), "Transforming Models with ATL", in Satellite Events at the MoDELS 2005 Conference. vol. 3844, ed: Springer Berlin / Heidelberg, pp. 128-138. Kent, S. (2002), "Model Driven Engineering", in Integrated Formal Methods. vol. 2335, M. Butler, L. Petre , & K. Sere, Eds., ed: Springer Berlin / Heidelberg, pp. 286-298. Kish, L. (1959), "Some statistical problems in research design", American Sociological Review, pp. 328-338. Kitchenham, B. (2004), "Procedures for performing systematic reviews", Keele, UK, Keele University, Technical Report vol. 33. Kitchenham, B. & Charters, S. (2007), "Guidelines for performing systematic literature reviews in software engineering", Engineering, vol. 2 (EBSE 2007-001). Kleppe, A. G., Warmer, J., & Bast, W. (2003), MDA explained: the model driven architecture: practice and promise: Addison-Wesley Knethen, A. v. & Grund, M. (2003), "QuaTrace: A Tool Environment for (Semi-) Automatic Impact Analysis Based on Traces", presented at the Proceedings of the International Conference on Software Maintenance, 2003, p. 246. Koch, N. (2001), "Software engineering for adaptive hypermedia applications", PhD. Thesis, FAST Reihe Softwaretechnik, Uni-Druck Publishing Company, Munich, Germany. Kolovos, D., Paige, R., & Polack, F. (2006), "The Epsilon Object Language (EOL)", in Model Driven Architecture Foundations and Applications. vol. 4066, A. Rensink &J. Warmer, Eds., ed: Springer Berlin / Heidelberg, pp. 128-142. Kolovos, D., Paige, R., & Polack, F. (2006), "Merging Models with the Epsilon Merging Language (EML)", in Model Driven Engineering Languages and Systems. vol. 4199, ed: Springer Berlin / Heidelberg, pp. 215-229. Kolovos, D., Paige, R., & Polack, F. (2006), "On-demand merging of traceability links with models", in Procedings of the 2th European Conference on Model Driven Architecture Traceability Workshop (ECMDA-TW'06), Bilbao, Spain, 2006. Kolovos, D., Paige, R., & Polack, F. (2008), "The Epsilon Transformation Language", in Theory and Practice of Model Transformations. vol. 5063, A. Vallecillo, J. Gray , & A. Pierantonio, Eds., ed: Springer Berlin / Heidelberg, pp. 46-60. Kolovos, D., Rose, L., Paige, R., & Polack, F. (2010), "The Epsilon Book", Retrieved from http://www.eclipse.org/epsilon/doc/book/. Kolovos, D. S. (2008), "An Extensible Platform for Specification of Integrated Languages for Model Management", PhD thesis, University of York. Kolovos, D. S., Paige, R. F., & Polack, F. A. C. (2006), "Eclipse development tools for epsilon", in Eclipse Summit Europe, Eclipse Modeling Symposium. , Esslingen, Germany., 2006. Kruchten, P. (2004), The rational unified process: an introduction : Addison-Wesley Professional. Kulkarni, V. & Reddy, S. (2003), "Separation of concerns in model-driven development", Software, IEEE, vol. 20 (5), pp. 64-69. Kulkarni, V., Venkatesh, R., & Reddy, S. (2002), "Generating Enterprise Applications from Models", in Advances in Object-Oriented Information Systems. vol. 2426, J.-M. Bruel &Z. Bellahsene, Eds., ed: Springer Berlin / Heidelberg, pp. 309-315. Kurtev, I. (2005), "Adaptability of model transformations", PhD thesis, University of Twente (May 2005), Twente. Kurtev, I. (2008), "State of the Art of QVT: A Model Transformation Language Standard", in Applications of Graph Transformations with Industrial Relevance. vol. 5088, A. Schrr, M. Nagl , & A. Zndorf, Eds., ed: Springer Berlin / Heidelberg, pp. 377-393. Kurtev, I., Van den Berg, K., & Jouault, F. (2006), "Evaluation of rule-based modularization in model transformation languages illustrated with ATL", presented at the Proceedings of the 2006 ACM symposium on Applied computing, Dijon, France, 2006, pp. 1202-1209.

107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127.

128. Kusel, A. (2009), "TROPIC-a framework for building reusable transformation components", in 129. 130. 131. 132. 133. 134. 135.
Proceedings of the Doctoral Symposium at MODELS 2009 , School of Computing, Queen's University, Denver, 2009. Kster, J. & Abd-El-Razik, M. (2007), "Validation of model transformationsfirst experiences using a white box approach", MoDELS Conference, pp. 193-204. Kster, J., Gschwind, T., & Zimmermann, O. (2009), "Incremental development of model transformation chains using automated testing", in MoDELS Conference, 2009, pp. 733-747. Kster, J. M., Ryndina, K., & Hauser, R. (2005), "A Systematic Approach to Designing Model Transformations", Report RZ 3621, IBM. Zurich. Lano, K. & Kolahdouz-Rahimi, S. (2011), "Model-Driven Development of Model Transformations", in Theory and Practice of Model Transformations. vol. 6707, J. Cabot &E. Visser, Eds., ed: Springer Berlin / Heidelberg, pp. 47-61. Lemesle, R. (1998), "Transformation rules based on meta-modeling", in Enterprise Distributed Object Computing Workshop, 1998. EDOC '98. Proceedings. Second International , 1998, pp. 113-122. Levendovszky, T., Balasubramanian, D., Smyth, K., Shi, F., & Karsai, G. (2010), "A transformation instance-based approach to traceability", presented at the Proceedings of the 6th ECMFA Traceability Workshop, Paris, France, 2010, pp. 55-60. Li, S., Liu, S., Wang, X., & Geng, Z. (2010), "A Research and Implementation of Model Execution Method Based on MOF", presented at the Proceedings of the Third International Symposium on Computer Science and Computational Technology(ISCSCT 10), Jiaozuo, P. R. China, 2010, pp. 91 - 93. Lichter, H., Schneider-Hufschmidt, M., Z\, H., \#252, & llighoven (1993), "Prototyping in industrial software projects\&mdash;bridging the gap between theory and practice", presented at the Proceedings of the 15th international conference on Software Engineering, Baltimore, Maryland, United States, 1993, pp. 221-229. Lpez-Sanz, M., Acua, C. J., Cuesta, C. E., & Marcos, E. (2008), "Modelling of ServiceOriented Architectures with UML", Electronic Notes in Theoretical Computer Science, vol. 194 (4), pp. 23-37. Mder, P., Gotel, O., & Philippow, I. (2009), "Enabling Automated Traceability Maintenance through the Upkeep of Traceability Relations", in Model Driven Architecture - Foundations and Applications. vol. 5562, R. Paige, A. Hartman , & A. Rensink, Eds., ed: Springer Berlin / Heidelberg, pp. 174-189. Marcos, E. (2005), "Software engineering research versus software development", SIGSOFT Softw. Eng. Notes, vol. 30 (4), pp. 1-7. Marcos, E., Acua, C., & Cuesta, C. (2006), "Integrating Software Architecture into a MDA Framework", in Software Architecture, Third European Workshop vol. 4344, ed Heidelberg, Alemania: Springer Verlag, pp. 127-143. Marcos, E. & Marcos, A. (1998), "An Aristotelian Approach to the Methodological Research: a Method for Data Models Construction", Information Systems-The Next Generation. L. Brooks & C. Kimble (Eds.). Mc Graw-Hill, pp. 532-543. Margaria, T. & Steffen, B. (2009), "Continuous Model-Driven Engineering", IEEE Computer, vol. 42 (10), pp. 106-109. Melby, S. (2007), "Traceability in Model Driven Engineering", Master Thesis. University of Oslo, Norway, http://urn.nb.no/URN:NBN:no-18721. Mellor, S. J., Kendall, S., Uhl, A., & Weise, D. (2004), MDA distilled: Addison Wesley. Mernik, M., Heering, J., & Sloane, A. M. (2005), "When and how to develop domain-specific languages", ACM Comput. Surv., vol. 37 (4), pp. 316-344. Molina, F., Lucas, F. J., Toval, A., Vara, J. M., Cceres, P., & Marcos, E. (2007), "Towards quality web information systems through precise model driven development", Handbook of research on web information systems quality, Idea Group Publishing, pp. 317-355. Naslavsky, L., Alspaugh, T. A., Richardson, D. J., & Ziv, H. (2005), "Using scenarios to support traceability", presented at the Proceedings of the 3rd international workshop on Traceability in emerging forms of software engineering, Long Beach, California, 2005, pp. 25-30.

136.

137. 138.

139. 140. 141. 142. 143. 144. 145. 146. 147.

148. Nuthall, G. (2004), "Relating classroom teaching to student learning: A critical analysis of why 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164.
research has failed to bridge the theory-practice gap", Harvard Educational Review, vol. 74 (3), pp. 273-306. Oldevik, J. (2006), "MOFScript user guide", Version 0.6 (MOFScript v 1.1. 11). Oldevik, J. & Neple, T. (2006), "Traceability in model to text transformations", in Procedings of the 2th European Conference on Model Driven Architecture - Traceability Workshop (ECMDATW'06), Bilbao, Spain, 2006, pp. 17-26. Oldevik, J., Neple, T., Grnmo, R., Aagedal, J., & Berre, A.-J. (2005), "Toward Standardised Model to Text Transformations", in Model Driven Architecture Foundations and Applications. vol. 3748, A. Hartman &D. Kreische, Eds., ed: Springer Berlin / Heidelberg, pp. 239-253. Oliveto, R. (2008), "Traceability Management meets Information Retrieval Methods - Strengths and Limitations", in Software Maintenance and Reengineering, 2008. CSMR 2008. 12th European Conference on, 2008, pp. 302-305. Olsen, G. K. & Oldevik, J. (2007), "Scenarios of traceability in model to text transformations", presented at the Proceedings of the 3rd European Conference on Model Driven Architecture Foundations and Applications (ECMDA-FA'07), Haifa, Israel, 2007, pp. 144-156. OMG. Architecture Driven Modernization (ADM). Available in: http://adm.omg.org/ OMG (2002), "MOF 2.0 Query/Views/Transformations RFP", OMG document ad/2002-04-10. OMG (2002), "Software Process Engineering Metamodel (SPEM)", OMG Document Formal/02-11, vol. 14. OMG (2003), "MDA Guide, Version 1.0.1", Object Management Group. OMG (2006), "The Meta Object Facility (MOF) Core Specification", version 2.0, OMG Document - formal/06-01-01. OMG (2006), "Object Constraint Language Specification (OCL) ", version 2.0. OMG Document - formal/2006-05-01. OMG (2007), "UML 2.1.1 Formal Specification", OMG Document - formal/07-02-03. OMG (2007), "XML Metadata Interchange (XMI) specification ", version 2.1.1. OMG Document - formal/2007-12-01. OMG (2008), "MOF Model to Text Transformation Language", version 1.0, OMG Document formal/2008-01-16. Paige, R., Drivalos, N., Kolovos, D., Fernandes, K., Power, C., Olsen, G., & Zschaler, S. (2011), "Rigorous identification and encoding of trace-links in model-driven engineering", Software and Systems Modeling, vol. 10 (4), pp. 469-487. Paige, R., Olsen, G. K., Kolovos, D., Zschaler, S., & Power, C. (2008), "Building model-driven engineering traceability classifications", in Proceedings of the 4th European Conference on Model Driven Architecture - Traceability Workshop (ECMDA-TW'08), Berlin, Germany, 2008, pp. 49-58. Parnas, D. L. (1972), "On the criteria to be used in decomposing systems into modules", Commun. ACM, vol. 15 (12), pp. 1053-1058. Petticrew, M. & Roberts, H. (2005), Systematic reviews in the social sciences: A practical guide: Blackwell Publishing. Pfleeger, S. L. & Atlee, J. M. (1998), Software engineering: theory and practice. Pfleeger, S. L. & Kitchenham, B. A. (2001), "Principles of survey research: part 1: turning lemons into lemonade", SIGSOFT Softw. Eng. Notes, vol. 26 (6), pp. 16-18. Pino, F., Garca, F., & Piattini, M. (2008), "Software process improvement in small and medium software enterprises: a systematic review", Software Quality Journal, vol. 16 (2), pp. 237-261. Poole, J. D. (2001), "Model-driven architecture: Vision, standards and emerging technologies", in Workshop on Metamodeling and Adaptive Object Models, ECOOP , 2001. Pressman, R. S. (2002), Ingeniera del Software, un enfoque prctico. Madrid: McGraw-Hill, Interamericana de Espaa. Ramesh, B., Stubbs, C., Powers, T., & Edwards, M. (1997), "Requirements traceability: Theory and practice", Annals of Software Engineering, vol. 3 pp. 397-415.

165. 166. 167. 168. 169. 170. 171. 172.

173. Rose, L., Paige, R., Kolovos, D., & Polack, F. (2008), "The Epsilon Generation Language", in 174. 175. 176. 177. 178.
Model Driven Architecture Foundations and Applications. vol. 5095, I. Schieferdecker &A. Hartman, Eds., ed: Springer Berlin / Heidelberg, pp. 1-16. Rossini, A., Mughal, K. A., Wolter, U., Rutle, A., & Lamo, Y. (2011), "A Formal Approach to Data Validation Constraints in MDE", Proceedings of TTSS 2011: 5th InternationalWorkshop on Harnessing Theories for Tool Support in Software, pp. 65-76. Rothenberger, M. A., Kao, Y.-C., & Van Wassenhove, L. N. (2010), "Total quality in software development: An empirical study of quality drivers and benefits in Indian software projects", Information &amp; Management, vol. 47 (78), pp. 372-379. Royce, W. W. (1987), "Managing the development of large software systems: concepts and techniques", presented at the Proceedings of the 9th international conference on Software Engineering, Monterey, California, United States, 1987, pp. 328-338. Rugaber, S. & Stirewalt, K. (2004), "Model-driven reverse engineering", Software, IEEE, vol. 21 (4), pp. 45-53. Snchez-Barbudo, A., Snchez, E. V., Roldn, V., Estvez, A., & Roda, J. L. (2008), "Providing an open virtual-machine-based QVT implementation", in Taller DSDM (Desarrollo de Software Dirigido por Modelos), Jornadas de Ingeniera del Software y Bases de Datos (JISBD 2008) , Gijn, Espaa, 2008. Snchez Cuadrado, J., Garca Molina, J., & Menarguez Tortosa, M. (2006), "RubyTL: A Practical, Extensible Transformation Language", in Model Driven Architecture Foundations and Applications. vol. 4066, A. Rensink &J. Warmer, Eds., ed: Springer Berlin / Heidelberg, pp. 158-172. Snchez, D. M., Cavero, J. M., & Marcos, E. (2009), "The concepts of model in information systems engineering: a proposal for an ontology of models", The Knowledge Engineering Review, vol. 24 (01), pp. 5-21. Snchez, P., Alonso, D., Rosique, F., lvarez, B., & Pastor, A. P. (2011), "Introducing Safety Requirements Traceability Support in Model-Driven Development of Robotic Applications", IEEE Transactions on Computers, vol. 60 pp. 1059-1071. Schmidt, D. C. (2006), "Model-driven engineering", IEEE Computer, vol. 39 (2), pp. 25-31. Schwarz, H. (2009), "Taxonomy and definition of the explicit traceability information suppliable for guiding model-driven, ontology-supported development. Project Deliverable ICT216691/UoKL", WP4-D1/D/PU/b1, MOST Project. Seidewitz, E. (2003), "What models mean", Software, IEEE, vol. 20 (5), pp. 26-32. Selic, B. (2003), "The pragmatics of model-driven development", Software, IEEE, vol. 20 (5), pp. 19-25. Selic, B. (2008), "MDA manifestations", The European Journal for the Informatics Professional, IX (2), pp. 12-16. Selic, B. (2008), "Personal reflections on automation, programming culture, and model-based software engineering", Automated Software Engineering, vol. 15 (3), pp. 379-391. Sendall, S. & Kozaczynski, W. (2003), "Model transformation: the heart and soul of modeldriven software development", Software, IEEE, vol. 20 (5), pp. 42-45. Sjoeberg, D. I. K., Hannay, J. E., Hansen, O., Kampenes, V. B., Karahasanovic, A., Liborg, N. K., & Rekdal, A. C. (2005), "A survey of controlled experiments in software engineering", Software Engineering, IEEE Transactions on, vol. 31 (9), pp. 733-753. Sommerville, I. (2005), Ingeniera del Software. Madrid: Pearson Educacin. Spanoudakis, G. & Zisman, A. (2005), "Software traceability: a roadmap", Handbook of Software Engineering and Knowledge Engineering, vol. 3 pp. 395-428. Stahl, T., Vlter, M., & Czarnecki, K. (2006), Model-Driven Software Development: Technology, Engineering, Management: John Wiley & Sons. Stake, R. E. (1995), The art of case study research: Sage Publications, Inc. Steinberg, D., Budinsky, F., Paternostro, M., & Merks, E. (2008), EMF: Eclipse Modeling Framework, 2nd Edition ed.: Addison-Wesley Professional. Stevens, P. (2008), "A Landscape of Bidirectional Model Transformations", in Generative and Transformational Techniques in Software Engineering II. vol. 5235, R. Lmmel, J. Visser , & J. Saraiva, Eds., ed: Springer Berlin / Heidelberg, pp. 408-424.

179.

180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195.

196. Technologies, I. (2011). Medini QVT. Available in: http://projects.ikv.de/qvt 197. Tisi, M., Jouault, F., Fraternali, P., Ceri, S., & Bzivin, J. (2009), "On the Use of Higher-Order 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214.
Model Transformations", in Model Driven Architecture - Foundations and Applications. vol. 5562, R. Paige, A. Hartman , & A. Rensink, Eds., ed: Springer Berlin / Heidelberg, pp. 18-33. Toulm, A. & Inc, I. (2006), "Presentation of EMF compare utility", 2006, p. 2009. Tratt, L. (2005), "Model transformations and tool integration", Software and Systems Modeling, vol. 4 (2), pp. 112-122. Valderas, P. & Pelechano, V. (2009), "Introducing requirements traceability support in modeldriven development of web applications", Information and Software Technology, vol. 51 (4), pp. 749-768. Vallecillo, A. (2008), "A Journey through the Secret Life of Models", in Perspectives Workshop: Model Engineering of Complex Systems (MECS) Dagstuhl, Germany, 2008. van Amstel, M., Lange, C., & van den Brand, M. (2009), "Using Metrics for Assessing the Quality of ASF+SDF Model Transformations", in Theory and Practice of Model Transformations. vol. 5563, R. Paige, Ed., ed: Springer Berlin / Heidelberg, pp. 239-248. van Amstel, M. & van den Brand, M. (2010), "Quality assessment of ATL model transformations using metrics", in 2nd International Workshop on Model Transformation with ATL (MtATL2010), Malaga, Spain, 2010. van Amstel, M. & van den Brand, M. (2011), "Using Metrics for Assessing the Quality of ATL Model Transformations", in 3rd International Workshop on Model Transformation with ATL (MtATL2011), Zrich, Switzerland, 2011, pp. 20-34. van Amstel, M., van den Brand, M., & Nguyen, P. H. (2010), "Metrics for model transformations", in 9th Belgian-Netherlands Software Evolution Workshop (BENEVOL 2010), Lille, France, 2010. Vara, J. M. (2009), "M2DAT: a Technical Solution for Model-Driven Development of Web Information Systems", PhD thesis, Universidad Rey Juan Carlos (September 2009). Vara, J. M., Bollati, V. A., Vela, B., & Marcos, E. (2008), "Uso de Modelos de Anotacin para automatizar el Desarrollo Dirigido por Modelos de Bases de Datos Objeto-Relacionales", Actas de los Talleres de las Jornadas de Ingeniera del Software y Bases de Datos, vol. 2 (3). Vara, J. M., Bollati, V. A., Vela, B., & Marcos, E. (2009), "Leveraging Model Transformations by means of Annotation Models", in Proceedings of 1st International Workshop on Model Transformation with ATL (MtATL2009), Nantes, France, 2009, pp. 88 -102. Vara, J. M., de Castro, V., & Marcos, E. (2005), "WSDL automatic generation from UML models in a MDA framework", in Next Generation Web Services Practices, 2005. NWeSP 2005. International Conference on, 2005. Vara, J. M., Vela, B., Bollati, V. A., & Marcos, E. (2009), "Supporting Model Driven Development of ObjectRelational Database Schemas: A Case Study", in Theory and Practice of Model Transformations. vol. 5563, ed: Springer Berlin / Heidelberg, pp. 181-196. Vara, J. M., Vela, B., Cavero, J. M., & Marcos, E. (2007), "Model transformation for objectrelational database development", 2007, pp. 1012-1019. Vara, J. M., Vela, B., & Marcos, E. (2006), "Oracle XML DB como repositorio integrado para herramientas CASE. Aplicacin al desarrollo de MIDAS-CASE, una herramienta MDA", presented at the XVI Congreso Nacional Usuarios de Oracle (CUORE), 2006. Varr, D. & Pataricza, A. (2003), "VPM: A visual, precise and multilevel metamodeling framework for describing mathematical domains and UML (The Mathematics of Metamodeling is Metamodeling Mathematics)", Software and Systems Modeling, vol. 2 (3), pp. 187-210. Varr, D. & Pataricza, A. (2004), "Generic and Meta-transformations for Model Transformation Engineering", in UML2004 - The Unified Modeling Language. Modelling Languages and Applications. vol. 3273, T. Baar, A. Strohmeier, A. Moreira , & S. Mellor, Eds., ed: Springer Berlin / Heidelberg, pp. 290-304. Vela, B., Acua, C., & Marcos, E. (2004), "A Model Driven Approach for XML Database Development", in Conceptual Modeling ER 2004. vol. 3288, P. Atzeni, W. Chu, H. Lu, S. Zhou , & T.-W. Ling, Eds., ed: Springer Berlin / Heidelberg, pp. 780-794. Vela, B., Fernndez-Medina, E., Marcos, E., & Piattini, M. (2006), "Model driven development of secure XML databases", ACM Sigmod Record, vol. 35 (3), pp. 22-27.

215. 216.

217. Vela, B. & Marcos, E. (2003), "Extending UML to represent XML Schemas", presented at the 218. 219. 220. 221. 222. 223. 224. 225. 226. 227.
15th Conference On Advanced Information Systems Engineering. CAISE03 FORUM, Klagenfurt/Velden (Austria), 2003. Vignaga, A. (2007), "A Methodological Approach to Developing Model Transformations", Model-Driven Engineering Languages and Systems (MoDELS 2007). Nashville (TN), Estados Unidos. Vignaga, A., Perovich, D., & Bastarrica, M. C. (2007), "Towards Layered Specifications of Model Transformation", Technical Report. Vlter, M. (2009), "Best Practices for DSLs and Model-Driven Development", Journal of Object Technology, vol. 8 (6), pp. 79 - 102, September-October 2009. Vlter, M. (2011), "From Programming to Modeling-and Back Again", Software, IEEE, vol. 28 (6), pp. 20-25. Vlter, M. (2011), "MD*/DSL Best Practices (Version 2.0)", Retrieved November, 2011, from: http://voelter.de/data/pub/DSLBestPractices-2011Update.pdf. W3C (1998), "Extensible markup language (XML) 1.0", W3C XML, February. Walderhaug, S., Johansen, U., Stav, E., & Aagedal, J. (2006), "Towards a generic solution for traceability in MDD", presented at the 2th European Conference on Model Driven Architecture Traceability Workshop (ECMDA-TW'06), Bilbao, Spain, 2006. Walderhaug, S., Stav, E., Johansen, U., & Olsen, G. K. (2009), "Traceability in Model-Driven Software Development", in Designing Software Intensive Systems: Methods and Principles, P. Tiako, Ed., ed, pp. 133-159. Watson, A. (2008), "A brief history of MDA", Upgrade, the European Journal for the Informatics Professional, vol. 9 (2), pp. 7-11. Wimmer, M., Kusel, A., Schoenboeck, J., Kappel, G., Retschitzegger, W., & Schwinger, W. (2009), "Reviving QVT Relations: Model-Based Debugging Using Colored Petri Nets", in Model Driven Engineering Languages and Systems. vol. 5795, A. Schrr &B. Selic, Eds., ed: Springer Berlin / Heidelberg, pp. 727-732. Winkler, S. & von Pilgrim, J. (2010), "A survey of traceability in requirements engineering and model-driven development", Software and Systems Modeling, vol. 9 (4), pp. 529-565. Wu, G., Liu, W., Zheng, Q., & Zhang, Z. (2009), "Model Interpretation Development: Analysis Design of Automatic Control System", Interpretation of Information Processing Regulations. Yin, R. K. (2003), Case Study Research: Design and Methods vol. 5: Sage Publications, Thousand Oaks, USA. Yu, E. S. K. & Mylopoulos, J. (1994), "Understanding "why" in software process modelling, analysis, and design", presented at the Proceedings of the 16th international conference on Software engineering, Sorrento, Italy, 1994, pp. 159-168.

228. 229. 230. 231.

Acrnimos

Tabla de Acrnimos
Acrnimo AMW ATL BD CCE CE CI CIM CMCE DDM DSDM DSL EMF EMOF EMP Epsilon ETL EVL GMT HOT IDM M2DAT Descripcin ATLAS Model Weaver ATLAS Transformation Language Bases de Datos Cuestin del Caso de Estudio Criterio de Evaluacin Cuestin de Investigacin Computation Independent Models Cuestin del Meta-Caso de Estudio Desarrollo Dirigido por Modelos Desarrollo de Software Dirigido por Modelos Domain Specific Language Eclipse Modeling Framework Essential MOF Eclipse Modeling Project Extensible Platform for Specification of Integrated Languages for mOdel Management Epsilon Transformation Language Epsilon Validation Language Generative Modeling Technologies Higher Order Transformation Ingeniera Dirigida por Modelos MIDAS MDA Tool

Acrnimo M2M M2T MDA MDD MDE MDSD MeTAGeM MeTAGeM-Trace MOF OCL OMDB OMG PDM PIM PSM QVT RS RUP SI UML XML XSD

Descripcin Model-to-Model Model-to-Text Model-Driven Architecture Model-Driven Development Model-Driven Engineering Model-Driven Software Development A Meta-Tool for the Automatic Generation of transformation Models A Meta-Tool for the Automatic Generation of transformation Models and Trace models Meta-Object Facility Object Constraint Language Online Movies DataBase Object Management Group Platform Dependent Models Platform Independent Models Platform Specific Models Query/View/Transformation Revisin Sistemtica Rational Unified Process Sistema de Informacin Unified Modelling Language eXtensible Markup Language XML Schema Definition