tesis de máster en ingeniería de software, métodos...

Tesis de Máster en Ingeniería de Software,Métodos Formales y Sistemas de Información

Un soporte a la comparación demodelos conceptuales en escenarios

de evolución

Julio César Sandobalín Guamán

Febrero 2014, Valencia España

Universitat Politècnica de ValènciaDepartamento de Sistemas Informáticos y Computación

Tutores

Óscar Pastor López

Sergio España Cubillo

Dedicado a mi madre, por ser mi inspiración de

lucha y tenacidad para conseguir mis sueños.

Agradecimientos

A la Secretaría Nacional de Educación Superior, Ciencia, Tecnología e Inno-vación SENESCYT de Ecuador, por concederme la beca de estudios en elPROGRAMA DE BECAS CONVOCATORIA ABIERTA 2012 para cur-sar mis estudios de Maestría.A mis tutores de tesis Óscar Pastor y Sergio España, por darme la oportunidadde conocer el mundo de la investigación.Quiero dar las gracias de manera especial a Marcela Ruiz, por permitirmedesarrollar mi tema de tesis en torno a sus investigaciones sobre un método deanálisis de evolución de modelos conceptuales y una técnica de análisis delta.

i

Abstract

Continuous improvement of information systems are primarily motivated by organi-zational changes. Companies must rethink the way business processes that meet thenew requirements, strategic goals and changes in their environment to meet businessobjectives. Changes in the organizations trigger the need to think in a reengineeringof the information systems.Reengineering has three processes defined: the process of reverse engineering per-forms the extraction from an existing system for obtain the system specification, theevolution process consists of a set of transformations from the current system to anew system and forward engineering process are conventional software developmentactivities. In the evolution process a system is changed to a higher level of abstrac-tion, so the changes are made to the current system model (model As-Is) to obtain anew model (model To-Be) that has evolved to meet the changes of the organization.From the set of modifications made in the model of the current system to obtain themodel of the new system, comes the need to study these changes for analyze theirimpact.This thesis presents a proposal to offer a support to the analysis of the modelscomparison in evolution scenarios with the development of a plugin to Eclipse. Fromthe result of the models comparison is derived a delta model that is an instanceof a metamodel evolution. A delta model has information about of the modelscomparison and with the help of operators (EQUAL, MODIFIED, ADDED, DELETED)specifies the kind of change between the elements of each model. Each element ofa delta model has information about the traceability of evolution that suffered asystem during reengineering. Traceability is a widely used concept because helpsidentify relations between the elements that belong to different models.To measure a delta model is used a set of metrics to get a numerical value, whichis used to quantify changes over the resulting model in the evolution process. Eachmetric has the ability to assign a weight or numerical value to each of its elementsfor analyze the changes between models.

iii

Resumen

La continua evolución de los sistemas de información están motivados principal-mente por cambios organizacionales. Las empresas deben repensar los procesos denegocio de manera que respondan a los nuevos requerimientos, metas estratégicasy cambios de su entorno para cumplir con los objetivos de la empresa. Los cambiosorganizacionales originan la necesidad de pensar en una reingeniería de los sistemasde información.La reingeniería posee tres procesos bien definidos: el proceso de ingeniería inversarealiza la extracción de un sistema existente para obtener la especificación del siste-ma, el proceso de evolución consiste en un conjunto de transformaciones desde unsistema actual hacia un sistema nuevo y el proceso de ingeniería directa son acti-vidades convencionales de desarrollo de software. Durante el proceso de evoluciónse modifica un sistema desde un nivel más alto de abstracción, de esta manera serealizan los cambios en el modelo del sistema actual (modelo As-Is) para obtenerun nuevo modelo que ha evolucionado (modelo To-Be) para satisfacer los cambiosorganizaciones. A partir del conjunto de modificaciones que se realizan en el modelodel sistema actual para conseguir el modelo del sistema nuevo, surge la necesidadde realizar un estudio sobre estos cambios para analizar su impacto.Esta tesis presenta una propuesta para ofrecer un soporte al análisis de la compa-ración de modelos en escenarios de evolución con el desarrollo de un plugin paraEclipse. A partir del resultado de la comparación de dos modelos se deriva un mo-delo delta que es una instancia de un metamodelo de evolución. Un modelo deltaposee la información de la comparación de los modelos y con la ayuda de operadores(EQUAL, MODIFIED, ADDED, DELETED) especifica el tipo de cambio que existe entrelos elementos de cada modelo. Cada elemento de un modelo delta, tiene informaciónsobre la trazabilidad de la evolución que sufre un sistema durante la reingeniería.La trazabilidad es un concepto ampliamente utilizado porque ayuda a identificar lasrelaciones entre los elementos que pertenecen a diferentes modelos.Para medir un modelo delta se emplea un conjunto de métricas para obtener un valornumérico, que se utiliza para cuantificar los cambios sobre el modelo resultante enel proceso de evolución. Cada métrica tiene la capacidad de asignar un peso o valornumérico a cada uno de sus elementos, para realizar el análisis de los cambios entrelos modelos.

v

Índice general

1. Introducción 11.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Metodología de investigación . . . . . . . . . . . . . . . . . . . . . . . 41.4. Solución propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.6. Potenciales usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.7. Estructura de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2. Estado del arte 92.1. Comparación de modelos . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2. Análisis de modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3. Análisis y discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3. Diseño de la solución 173.1. Un método para el análisis de modelos delta . . . . . . . . . . . . . . 17

3.1.1. Derivación del modelo delta . . . . . . . . . . . . . . . . . . . 203.1.2. Medición del modelo delta . . . . . . . . . . . . . . . . . . . . 203.1.3. Análisis de cambios . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2. Soporte al análisis de modelos delta . . . . . . . . . . . . . . . . . . . 223.2.1. Comparar modelos . . . . . . . . . . . . . . . . . . . . . . . . 233.2.2. Derivar el modelo delta . . . . . . . . . . . . . . . . . . . . . . 283.2.3. Medir el modelo delta . . . . . . . . . . . . . . . . . . . . . . 30

3.3. Análisis y discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4. Validación de la solución 334.1. Soporte tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2. Instalación del plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3. Uso del plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4. Validación del plugin con un ejemplo ilustrativo . . . . . . . . . . . . 40

4.4.1. Caso I: métrica Size weighted . . . . . . . . . . . . . . . . . . 424.4.2. Caso II: métrica Size weighted meta . . . . . . . . . . . . . . . 434.4.3. Caso III: métrica Size weighted related . . . . . . . . . . . . . 444.4.4. Caso IV: métrica Size weighted related meta . . . . . . . . . . 46

4.5. Análisis y discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

vii

Índice general Índice general

5. Conclusiones 495.1. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2. Publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Bibliografía 53

viii

Índice de figuras

1.1. Marco de un proceso de reingeniería. . . . . . . . . . . . . . . . . . . 21.2. Visión general de la metodología de investigación. . . . . . . . . . . . 41.3. Vista general de la solución propuesta. . . . . . . . . . . . . . . . . . 6

2.1. Fases de la comparación de modelos en EMF Compare. . . . . . . . . 112.2. Arquitectura de GenericDiff. . . . . . . . . . . . . . . . . . . . . . . . 13

3.1. Proceso de reingeniería guiado por el modelo de herradura. . . . . . . 183.2. Metamodelo de evolución. . . . . . . . . . . . . . . . . . . . . . . . . 193.3. Método para el análisis de modelos delta. . . . . . . . . . . . . . . . . 193.4. Modelo delta d(M1, M2). . . . . . . . . . . . . . . . . . . . . . . . . 213.5. Arquitectura del soporte al análisis de modelos delta. . . . . . . . . . 233.6. Componentes del soporte al análisis de modelos delta. . . . . . . . . . 243.7. Modelo de dominio del soporte al análisis de modelos delta. . . . . . . 253.8. Arquitectura de EMF Compare. . . . . . . . . . . . . . . . . . . . . . 263.9. Esquema de la comparación de modelos. . . . . . . . . . . . . . . . . 273.10. Esquema de la derivación del modelo delta. . . . . . . . . . . . . . . . 293.11. Esquema de las métricas. . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1. EMF unifica Java, XML y UML. . . . . . . . . . . . . . . . . . . . . 344.2. Modelo Ecore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3. Plugin pros.upv.sizeweighted.jar. . . . . . . . . . . . . . . . . . . . . 364.4. Seleccionar un diagrama Ecore. . . . . . . . . . . . . . . . . . . . . . 364.5. Modelo As-Is para crear una instancia de un modelo Ecore. . . . . . . 374.6. Modelo To-Be para crear una instancia de un modelo Ecore. . . . . . 374.7. Seleccionar una métrica Size Weighted. . . . . . . . . . . . . . . . . . 384.8. Resultado del cálculo de la métrica Size weighted meta. . . . . . . . . 394.9. Modelo As-Is del ejemplo ilustrativo. . . . . . . . . . . . . . . . . . . 404.10. Aplicación del ejemplo ilustrativo. . . . . . . . . . . . . . . . . . . . . 424.11. Modelo To-Be del ejemplo ilustrativo. . . . . . . . . . . . . . . . . . . 434.12. Métrica Size weighted. . . . . . . . . . . . . . . . . . . . . . . . . . . 444.13. Métrica Size weighted meta. . . . . . . . . . . . . . . . . . . . . . . . 454.14. Métrica Size weighted related. . . . . . . . . . . . . . . . . . . . . . . 464.15. Métrica Size weighted related meta. . . . . . . . . . . . . . . . . . . . 47

ix

Índice de tablas

3.1. Peso de cada operador del modelo delta. . . . . . . . . . . . . . . . . 213.2. Peso de los estados de M1 y M2. . . . . . . . . . . . . . . . . . . . . 213.3. Peso de cada metaclase del metamodelo del diagrama de estados. . . 22

4.1. Tabla de pesos de la métrica Size weighted meta. . . . . . . . . . . . . 394.2. Caso II: tabla de pesos de la métrica Size weighted meta. . . . . . . 454.3. Caso III: tabla de pesos de la métrica Size weighted related. . . . . . 474.4. Caso IV: tabla de pesos de la métrica Size weighted related meta. . . 47

xi

1 IntroducciónLa constante evolución de los sistemas de información están motivados principalmen-te por cambios en los objetivos empresariales. Los sistemas de hardware juegan unrol importante en las organizaciones, pero dependen en gran medida de los sistemasde software. Por lo tanto, al pensar en una evolución que se origina por el cambioorganizacional, también surge la necesidad de pensar en un proceso de reingenieríade los sistemas de información.Por otro lado, el Desarrollo de Software Dirigido por Modelos (DSDM) es un paradig-ma que proporciona a los modelos algunas ventajas, como la capacidad para derivarmodelos conceptuales para la generación de software de una manera automática.El DSDM también facilita el proceso de reingeniería de los sistemas de informa-ción porque se centra en el análisis de los modelos y se apoya en transformacionesautomáticas para generar código ejecutable.En este capítulo se presenta la motivación para realizar la investigación sobre unsoporte a la comparación de modelos conceptuales en escenarios de evolución. Seespecifica el objetivo principal de la investigación que se apoya sobre un conjuntode preguntas del conocimiento. Se presenta la metodología de investigación con laayuda de un ciclo de ingeniería y las actividades que guían el desarrollo de esta tesis.Además, se resume la solución propuesta al reto de la investigación y el contextodonde se desarrolla. Finalmente, se detalla a quién está dirigida esta tesis.

1.1. Motivación

Los sistemas de información están en continua evolución debido a factores que de-penden del contexto de las organizaciones, por ejemplo nuevos requisitos, migraciónhacia nuevas tecnologías, cumplimiento de nuevas metas, etc. lo que origina la ne-cesidad de repensar los procesos de negocio de manera que respondan a los nuevosrequerimientos, metas estratégicas y cambios de su entorno. Los sistemas de softwarey hardware deben ser parte del proceso de evolución dentro del contexto empresa-rial. Los sistemas de hardware juegan un rol importante en la organización perodependen en gran medida de los sistemas de software. Por lo tanto, al pensar en unaevolución que se origina por el cambio organizacional, también surge la necesidadde pensar en una reingeniería de los sistemas de información.Un proceso de reingeniería consiste en un conjunto de actividades dirigidas a laevolución de un sistema, desde una sistema actual (sistema As-Is) hacia un nuevo

1

Capítulo 1 Introducción

sistema que satisface los requerimientos o metas (sistema To-Be) [1] de la organiza-ción. Al realizar la abstracción del sistema As-Is se obtiene un modelo As-Is, sobreel modelo As-Is se realiza los cambios para cumplir con nuevos requerimientos de laempresa y el resultado es un modelo To-Be. El nuevo sistema se denomina sistemaTo-Be y se desarrolla en base al modelo To-Be.

SISTEMA

AS-IS

MODELO

AS-IS

MODELO

TO-BE

SISTEMA

TO-BE

MODELO

EVOLUCIÓN

METAMODELO

EVOLUCIÓN

EVOLUCIÓN

ING

EN

IER

ÍA

INV

ER

SA

ING

EN

IER

ÍA

DIR

EC

TA

NIV

EL

DE

AB

ST

RA

CC

IÓN

+-

ARTEFACTO METAMODELO PROCESO INSTANCIARELACIONES DE

ASOCIACIÓN

LEYENDA

Figura 1.1: Marco de un proceso de reingeniería.

El paradigma del Desarrollo de Software Dirigido por Modelos (DSDM) soportala evolución de los sistemas de información en entornos empresariales, donde losmodelos se utilizan para representar a los sistemas de información, la Figura 1.11muestra un marco de un proceso de reingeniería bajo el paradigma de DSDM. Enbase a la metáfora de la herradura [3] se proporciona un marco para la evoluciónde sistemas empresariales. El marco de evolución está compuesto de tres procesosy cuatro artefactos. El primer proceso, es el proceso de ingeniería inversa, dondeingresa como primer artefacto el sistema As-Is y como salida del proceso se obtieneel segundo artefacto denominado modelo As-Is. El segundo proceso, es el proceso deevolución, que maneja de manera abstracta a los sistemas de información, la entradaal proceso es el modelo As-Is y la salida es el tercer artefacto el modelo To-Be conlos cambios para evolucionar y cumplir con los nuevos requerimientos del sistemade información. El tercer proceso, es el proceso de ingeniería directa, su entradaes el modelo To-Be y su salida es el cuarto artefacto el sistema To-Be. El sistemaTo-Be es el resultado del proceso de reingeniería y cumple con los nuevos objetivosempresariales.

En el proceso de evolución es posible analizar el modelo As-Is y el modelo To-Bemediante un metamodelo [2] que soporta la trazabilidad entre los elementos de cada

1Esta figura se tomó y modificó de [2]

2

1.2 Objetivos

modelo. Se obtiene un modelo intermedio que agrupa los elementos de los modelosy sus relaciones. Con la ayuda de operadores de comparación (EQUAL, MODIFIED,

DELETED, ADDED) podemos obtener información sobre la comparación de los modelos.En esta tesis presentamos2 un soporte DSDM para el análisis a la comparaciónde modelos en escenarios de evolución. Se crea una instancia del metamodelo deevolución propuesto en [2] y deriva un modelo delta con la información del resultadode la comparación entre modelos. Para medir el modelo delta, se utiliza un conjuntode métricas que se proponen en [4] para conocer valores cuantitativos acerca de losatributos del modelo delta. Finalmente, cada métrica tiene la capacidad de asignarun valor numérico a cada uno de sus elementos y realizar un análisis de los cambiosentre los modelos.

1.2. Objetivos

El principal objetivo de esta tesis es proporcionar un soporte a la comparación demodelos conceptuales en escenarios de evolución. Esta tesis propone una soluciónal análisis de la comparación de modelos en el proceso de evolución del marco dereingeniería para la evolución de las organizaciones presentado en [2]. Para guiarel objetivo principal, debemos definir un conjunto de preguntas de investigación(research questions RQ) que dirigen la investigación descrita en esta tesis. Debemosdistinguir entre preguntas del conocimiento (knowledge problems KP) y problemasde diseño (design problems DP) como se define en [5]:

RQ1 (KP). ¿Cuáles son los elementos que participan en la evolución de mo-delos conceptuales? La respuesta a esta pregunta debe aclarar la terminología,los grupos de interés y ayudar a establecer un marco conceptual para facilitarel razonamiento sobre la comparación de modelos.RQ2 (KP). ¿Cuáles son las herramientas que dan soporte a la comparaciónde modelos? La respuesta a esta pregunta debe establecer el estado del artesobre la comparación de modelos.

• RQ2.1 (KP). ¿Cuáles de estas herramientas soportan el paradigma DSDM?

RQ3 (KP). ¿Cuáles son las fases y actividades que guían la comparación demodelos en un entorno DSDM? La respuesta a esta pregunta ayuda a com-prender las actividades y fases que apoyan la comparación de modelos.RQ4 (KP). ¿Cómo se puede dar soporte al método de evolución de modelosconceptuales? La respuesta a esta pregunta ayuda a establecer el diseño deuna herramienta para el análisis de la comparación de modelos en escenariosde evolución.

2Voy a utilizar la primera persona del plural para reconocer a mis tutores Sergio España y ÓscarPastor. Además, para recocer a Marcela Ruiz por su ayuda en el desarrollo de esta tesis.

3


• RQ4.1 (DP). ¿Qué directrices se necesitan para derivar un modelo apartir de un metamodelo de evolución?

• RQ4.2 (DP). ¿Qué transformaciones son necesarias para generar au-tomáticamente un modelo a partir del resultado de la comparación demodelos?

RQ5 (KP). ¿Cómo pueden apoyar un conjunto de métricas al análisis de lacomparación de modelos? La respuesta a esta pregunta ayuda a comprenderla necesidad de derivar un modelo delta a partir de la comparación de modelosy obtener su medición cuantitativa.RQ6 (KP). ¿Cómo se puede validar el soporte tecnológico al resultado delmétodo de evolución de modelos conceptuales? La respuesta a esta preguntaayuda a comprender la factibilidad de implementación de esta propuesta.

1.3. Metodología de investigación

Esta tesis de Maestría sigue el marco de design science propuesto en [5][6]. Lametodología de investigación se explica por medio de un ciclo de ingeniería EC1,con el fin de responder a las preguntas de investigación (RQ1-RQ6) que se describenen la Sección 1.2. La Figura 1.2 presenta la metodología de investigación.

T2. DISEÑO DE LA SOLUCIÓNT2.1 Estado del arte (RQ2)T2.2 Analizar la comparación de modelos (RQ3)T2.3 Diseñar un modelo resultante de la comparación de modelos (RQ4) T2.3.1 Crear una instancia de un metamodelo de evolución. T2.3.2 Derivar un modelo a partir del resultado de la comparación entre modelos.T2.4 Definir un conjunto de métricas (RQ5) T2.4.1 Definir métricas cuantitativas T2.4.2 Aplicar métricas en el modelo resultante de la comparación de modelosT2.5 Proporcionar una herramienta para Eclipse

T1. INVESTIGACIÓN DEL PROBLEMA (RQ1)T1.1 MotivaciónT1.2 ObjetivosT1.3 Metodología de investigaciónT1.4 Solución propuestaT1.5 ContextoT1.6 Potenciales usuarios

T3. VALIDACIÓN DE LA SOLUCIÓN (RQ6)T3.1 Validar la viabilidad de la solución a través de un ejemplo ilustrativo

T4. IMPLEMENTACIÓN DE LA SOLUCIÓNT4.1 Utilizar la herramienta en un caso de estudio (Trabajo Futuro)

T5. VALIDACIÓN DE LA IMPLEMENTACIÓNT5.1 Evaluar la satisfacción de potenciales usuarios con la herramienta (Trabajo Futuro)

EC1.SOPORTE A LA

COMPARACIÓN DE MODELOS

CONCEPTUALES EN ESCENARIOS DE EVOLUCIÓN

Figura 1.2: Visión general de la metodología de investigación.

EC1: Soporte a la comparación de modelos conceptuales en escenarios deevolución.

4

1.3 Metodología de investigación

T1 Investigación del problema

• T1.1 Motivación (ver Sección 1.1).

• T1.2 Objetivos (ver Sección 1.2).

• T1.3 Metodología de investigación (ver Sección 1.3).

• T1.4 Solución propuesta (ver Sección 1.4).

• T1.5 Contexto de la investigación (ver Sección 1.5).

• T1.6 Potenciales usuarios (ver Sección 1.6).

T2 Diseño de la solución

• T2.1 Estado del arte (ver Capítulo 2).

• T2.2 Analizar la comparación de modelos (ver Sección 2.1).

• T2.3 Diseñar un modelo resultante de la comparación de modelos (verSubsección 3.2.2).

◦ T2.3.1 Crear una instancia de un metamodelo de evolución.

◦ T2.3.2 Derivar un modelo a partir del resultado de la comparaciónentre modelos.

• T2.4 Definir un conjunto de métricas (ver Subsección 3.2.3).

◦ T2.4.1 Definir métricas cuantitativas.

◦ T2.4.2 Aplicar métricas en el modelo resultante de la comparaciónde modelos

• T2.5 Proporcionar una herramienta para Eclipse.

T3 Validación de la solución

• T3.1 Validar la viabilidad de la solución a través de un ejemplo ilustrativo(ver Sección 4.4).

T4 Implementación de la solución

• T4.1 Utilizar la herramienta en un caso de estudio (Trabajo Futuro).

T5 Validación de la implementación

• T5.1 Evaluar la satisfacción de potenciales usuarios con la herramienta(Trabajo Futuro).

5


1.4. Solución propuestaLos sistemas de información se encuentran en constante evolución. Las organizacio-nes están altamente motivadas en agilizar sus procesos de innovación y adaptacióna los nuevos requisitos y demandas del entorno. Adicionalmente, una práctica co-mún en las organizaciones, es guiar la evolución utilizando modelos de referencia queles permita garantizar su adaptación a nuevas normativas, leyes, requisitos, etc. Unmétodo que soporta la evolución de procesos organizacionales dentro del paradigmadel DSDM se propone en [1][2], donde el objetivo principal es dar un soporte a laevolución de modelos conceptuales, lo que da origen a un nuevo reto de investiga-ción, la creación de una herramienta que de soporte al análisis de la comparaciónde modelos en escenarios de evolución.

MODELO M1 MODELO M2d(M1,M2)

METAMODELO EVOLUCIÓN

RELACIÓN DE INSTANCIA

RELACIÓN DE ASOCIACIÓN

MÉTRICAS

MÉTRICASMETAMODELO MODELO

d(a,b)

COMPARACIÓN Modelo Delta (d) entre

los modelos a y b

1. Derivación del modelo delta

2. Medición del modelo delta

3. Análisis de cambio

DIMENSIONES DE ANÁLISIS

DIMENSIONES

LEYENDA

Figura 1.3: Vista general de la solución propuesta.

En la propuesta de M. Ruiz [2] se presenta un metamodelo de evolución que apoyala trazabilidad entre un modelo inicial (M1) y un modelo que ha evolucionado apartir de los nuevos requerimientos de la organización (M2). La trazabilidad es unconcepto ampliamente utilizado en el DSDM porque ayuda a identificar las relacionesentre los elementos que pertenecen a diferentes modelos. Se proporciona artefactospara almacenar información sobre la trazabilidad de la evolución de los modelosconceptuales y con la ayuda de operadores (EQUAL, MODIFIED, DELETED, ADDED) seespecifica la relación que existe entre los elementos de cada modelo. Se realiza lacomparación entre los modelos M1 y M2, y del resultado de la comparación sederiva un modelo delta a partir del metamodelo de evolución. Un modelo deltaespecifica los cambios de un modelo M2 respecto a un modelo M1. Se ha diseñado lasolución con el fin de especificar modelos delta, siguiendo el paradigma del DSDMen escenarios de evolución (ver Figura 1.3). En resumen, la solución propone tresactividades principales:

1. Derivación de modelos delta para especificar los cambios del modelo M2 res-pecto al modelo M1 (d(M1, M2)). Los modelos M1 y M2 son conformes al

6

1.5 Contexto

mismo metamodelo. Cada modelo delta describe trazas entre los elementosde los modelos M1 y M2. Adicionalmente, estas trazas están cualificadas me-diante operadores (EQUAL, MODIFIED, DELETED, ADDED) que indican el tipo demodificación entre elementos de M1 y M2.

2. Medición del modelo delta para proporcionar información sobre la compara-ción. Se aplican un conjunto de métricas con el fin de obtener informacióncuantitativa sobre el modelo delta resultante de la comparación.

3. Análisis de la evolución para proporcionar ayuda en la interpretación de lamedición del modelo delta.

El diseño e implementación de la solución sigue la arquitectura de plugins3 de Eclip-se4. Se utiliza el plugin EMF Compare [7] para realizar la comparación de modelosporque forma parte de los componentes de Eclipse. Además se crea un plugin parala derivación del modelo delta y para el repositorio de métricas. Los plugins sonsoportados por Eclipse Modeling Framework (EMF) [8].

1.5. Contexto

Este trabajo de fin de Máster se ha desarrollado en el contexto del Centro de Inves-tigación en Métodos de Producción de Software PROS de la Universidad Politécnicade Valencia. El desarrollo de esta tesis es posible en el marco de los siguientes pro-yectos de investigación:

Proyecto Español MICINN PROS-Req (TIN2010-19130-C02-02).

Proyecto de la Generalitat Valenciana ORCA (PROMETEO/2009/015).

Proyecto de la Comisión Europea FP7 CaaS (611351).

1.6. Potenciales usuarios

Los potenciales usuarios son todas las persona implicadas en el Desarrollo de Soft-ware Dirigido por Modelos (DSDM), principalmente las personas que se dedican alas actividades de requisitos, análisis y diseño, dónde como resultado se obtienenmodelos conceptuales. A los estudiantes de Maestría y Doctorado en Informática,esta tesis les puede resultar útil como punto de partida para nuevas investigacionessobre el análisis de la comparación de modelos en escenarios de evolución.

3Un plugin es una aplicación que se relaciona con otra para aportarle una función nueva y gene-ralmente muy específica

4http://www.eclipse.org/

7


1.7. Estructura de la tesis

El presente documento esta divido en cinco capítulos:Capítulos 1 es la introducción, donde se presenta la motivación para reali-zar el presente trabajo, los objetivos de la investigación, la metodología deinvestigación con un conjunto de procedimientos racionales utilizados en la in-vestigación, la solución propuesta con las actividades para el soporte al análisisde la comparación de modelos en escenarios de evolución y el contexto dondese desarrolla la presente tesis.Capitulo 2 describe el estado del arte de los trabajos relacionados con la so-lución propuesta al análisis de la comparación de modelos en escenarios deevolución, donde se explica modelos y técnicas para la comparación de mode-los y su soporte tecnológico.Capítulo 3 es el diseño de la solución, donde se presenta las actividades delmétodo para el análisis de modelos delta, la arquitectura de los componentesque forman parte de la solución, las fases del soporte al análisis de modelosdelta y el conjunto demétricas para medir cuantitativamente los modelos delta.Capítulo 4 es la validación de la solución, donde se presenta un ejemplo ilus-trativo para validar la solución propuesta al análisis de la comparación demodelos en escenarios de evolución.Capítulo 5 se explica las lecciones aprendidas en las conclusiones y se proponenuevos retos en trabajos futuros.

8

2 Estado del arte

De acuerdo con la metodología de design science [5] el segundo paso en el ciclode ingeniería EC1 es el diseño de la solución al problema práctico. Se debe iniciarcon una búsqueda sistemática en la literatura científica para encontrar si existenpropuestas que resuelvan el reto de la investigación. En el caso que exista solucionesal problema se debe hacer un inventario de las soluciones disponibles. Si no existesoluciones alternativas se debe crear el diseño de una nueva solución o partir de lasalternativas que existen.Este capítulo cubre diferentes propuesta relacionadas con métodos y técnicas para lacomparación de modelos y el análisis de modelos dentro del paradigma de Desarrollode Software Dirigido por Modelos (DSDM).

2.1. Comparación de modelos

Todo software evoluciona debido a cambios en los requerimientos iniciales. La evo-lución estructural a nivel del diseño sufre cambios durante el ciclo de vida del mo-delado, y con ello surge la necesidad de implementar operaciones en los cambiosrealizados sobre las diferentes versiones subsecuentes del modelado del software.La diferencia entre modelos es compleja para analizar y proponer una posible solu-ción, es imprescindible descomponer el problema en partes porque su complejidades múltiple, en [9][10] se propone considerar al menos los siguientes aspectos:

Cálculo: se ha propuesto una serie de alternativas para realizar la compara-ción de modelos, desde técnicas basadas en comparación de texto hasta unmodelo de diferenciación. Los algoritmos de cálculo pueden ser clasificadospor distintos puntos de vista, existen dos propuestas principales:

1. Identificadores que son asignados a elementos del modelo por las herra-mientas de modelado.

2. Establecer cuan similar son los elementos de dos modelos por la compa-ración de las propiedades locales de los elementos.

Representación: detectar las diferencias e identificar la trazabilidad entre lasdistintas versiones del diseño del sistema es necesario para presentar al menosparte de dicho conocimiento. La eficiencia de la representación de las dife-rencias de modelos está a menudo comprometida por factores tales como el

9

Capítulo 2 Estado del arte

método del cálculo. Problemas en la escasez de abstracción permite única-mente la capacidad de reconstrucción del modelo final, y no es fácil permitirninguna manipulación complementaria o análisis desde herramientas de re-querimientos ad-hoc. Para proponer una representación debe contener toda lainformación, definir las diferencias y hacer este conocimiento disponible parafuturos análisis y manipulaciones.Visualización: la diferencia entre modelos se debe visualizar en una notacióncomprensible para los humanos. Las diferencias requieren ser presentadas deacuerdo a una necesidad especifica, destacando artefactos de información queson relevantes únicamente para un objetivo establecido.

Los cálculos y representaciones son elementos centrales de cualquier solución a lacomparación de modelos, dejando a la visualización como una requerimiento espe-cífico que depende del contexto de la solución. Existe un conjunto de propiedadesdeseables sobre la representación:

Basado en el modelo: la respuesta del cálculo de la diferencia de modelos debeser representado como un modelo para habilitar un amplio rango de posibili-dades, tales como el análisis subsecuentes del modelo resultante, detección deconflictos y corrección de errores.Compacidad: el modelo resultante de la comparación debe ser compacto y con-tener únicamente información para representar las modificaciones, sin duplicarinformación.Autónomo: el resultado de la comparación no debe utilizar fuentes externas deinformación.Transformador: cada diferencia que se origine en la comparación debe inducira una transformación, de tal manera que cuando se aplica la transformacióndel modelo origen se obtenga el modelo final.Independencia del metamodelo: no debe estar limitado o centrado en ningúnmetamodelo para realizar la comparación.

Propuestas sobre la comparación de modelos deben tener en cuenta al menos losaspectos y propiedades antes mencionados, para obtener una solución genérica yextensible a la comparación de modelos.

2.1.1. Herramientas

2.1.1.1. EMF Compare

EMF Compare [7] es un proyecto de Eclipse que lanza su primera versión en el año2006 bajo la colaboración de las empresas Obeo1 e Intalio2. Es una herramienta

1http://www.obeo.fr/pages/acceleo-pro-compare/en2http://www.intalio.com

10

2.1 Comparación de modelos

que proporciona un soporte genérico para cualquier tipo de metamodelo. Ofreceuna implementación genérica, estable y eficiente a la comparación de modelos, conun marco extensible que trabaja en Eclipse Modeling Framework (EMF) [8]. Lapropuesta de implementar EMF Compare en Eclipse Modeling Framework (EMF)se detalla en [11]. El proceso de comparación está formado por dos fases principales:

El agrupamiento en pares (matching) entre dos elementos de diferentes mode-los.La diferencia (diff ) entre elementos de diferentes modelos.

Estas fases trabajan de manera separada (ver Figura 2.13) gracias a dos tipos deprocesadores de datos que son el motor de agrupamiento y el motor de diferen-cia. Ambos motores pueden analizar cualquier modelo conforme a un metamodeloarbitrario.

Motor genérico de agrupamiento

Motor de diferencia

Modelo versión 1

Modelo versión 2

Modelo de agrupamiento

Modelo de diferencias

Figura 2.1: Fases de la comparación de modelos en EMF Compare.

Analizar los elementos de cada modelo que participa en la comparación, ayuda aidentificar los elementos semejantes que serán agrupados en pares y es una partefundamental del proceso de comparación, la falta de exactitud en esta fase afectarála calidad del mecanismo de detección de diferencias. Se debe considerar a todos loselementos de todas las versiones del modelo y decidir si un elemento en la primeraversión es igual que otro en una segunda versión. Se utiliza la palabra igual paraencontrar un elemento que ha sido comparado con su antecesor.El motor genérico que realiza el agrupamiento en pares está basado en estadísticas,heurísticas y casos que son comparados con cuatro métricas diferentes. Estas métri-cas analizan el nombre de un elemento, su contenido, su tipo y las relaciones que hatenido con otros elementos. Las funciones de cada métrica son:

Nombre: encuentra un atributo permanente para un elemento del modelo.Tipo: compara las características de las métricas de la metaclase.Relación: analiza que las instancias vinculadas, tanto las que contienen y nocontienen relación.

3Esta figura se tomó y modificó de http://www.eclipse.org/emf/compare

11


Contenido: analiza el contenido intrínseco de la instancia.El resultado del agrupamiento en pares retorna un valor numérico, que va desde 0(nada en común) a 1 (iguales). En general, la comparación utiliza una gran cantidadde información que no es relevante, por lo tanto, puede ser llamada informaciónruidosa. Se obtienen resultados falsos porque la mayoría de la información vienedesde valores por defecto, los cuales son compartidos entre las instancias.EMF Compare utiliza un algoritmo de comparación denominado Subsecuencia Co-mún más Larga (Longest Common Subsequence – LCS) donde el objetivo es deter-minar una subsecuencia más larga que se puede obtener mediante la eliminaciónde cero o más símbolos de cada una de dos cadenas dadas, el algoritmo se explicadetalladamente en [12][13].Tanto la información del agrupamiento y de la diferencia son representadas pormedio de modelos que pueden ser reutilizados en modelos de transformación, talesmodelos corresponde al metamodelo Ecore4. Un propuesta detalla sobre la compa-ración de modelos con EMF Compare se presenta en [14][15].El rendimiento es un reto clave de los motores genéricos de EMF Compare. Un grannúmero de parámetros afecta la ejecución de la comparación. Si se desea realizaruna gran cantidad de comparaciones, especialmente el añadir o eliminar un elemen-to, se debe iterar más veces a través de los elementos restantes. Para eliminar elgran número de iteraciones se utiliza modelos estructurados que permiten compara-ciones rápidas, debido a que una estructura facilita la tarea de agrupar en pares loselementos similares.

2.1.1.2. GenericDiff

GenericDiff [16] es un marco general para la comparación de modelos. La herra-mienta separa las propiedades y la sintaxis de un modelo específico, desde un procesogeneral de agrupamiento en un gráfico y utiliza una composición de vectores numé-ricos y gráficos para codificar las propiedades y sintaxis específicas en el contexto dela comparación. La Figura 2.25 muestra arquitectura de GenericDiff.GenericDiff toma dos modelos como entradas para la comparación y las especifi-caciones de las propiedades y sintaxis del modelo en términos de propiedades deun dominio específico, agrupa los predicados factibles y recorre aleatoriamente susfunciones. El proceso de comparación genérico soluciona el problema de reconocer elmáximo común subgrafo [17] (Maximum Common Subgraph - MCS) y las escriturasatribuidas a los gráficos (Typed Attributed Graphs - TAG). Se utiliza dos estructurasde datos: un vector numérico compuesto y un gráfico de agrupamiento, el cual per-mite modelar las propiedades y la sintaxis de un dominio especifico para el procesode comparación.

4El metamodelo Ecore junto con el metamodelo Genmodel son la base de Eclipse ModelingFramework (EMF) [8]


12

2.1 Comparación de modelos

Proceso genérico de agrupamiento

M1

M2

PARSE

TAG

1

TAG

2

Construcción PairupGraph

RW PairupGraph

Pairup Graph

Vector rangos

Agrupamiento bipartito

Diferencias simétrica

Aplicaciones

Entradas de dominio específico

LEYENDA

MODELOS TAGs PROCESOS DATOS AGRUPAMIENTO DE PROCESOS

Figura 2.2: Arquitectura de GenericDiff.

A partir de dos modelos M1 y M2, GenericDiff analiza los modelos de entrada en dosTAGs de acuerdo al metamodelo de M1 y M2. Los tipos de nodo y bordes del gráficocorresponden a las metaclases y metaasociaciones definidos en el metamodelo. Enel proceso de análisis se recoge los datos de las propiedades seleccionadas de cadaelemento del modelo para presentar un atributo de un vector numérico compuesto,asociado con el correspondiente nodo y vértice del gráfico. GenericDiff define unconjunto de vectores de números atómicos y realiza el cálculo de la distancia están-dar para los tipos de datos comunes. Los vectores atómicos puedes ser compuestosen vectores. Los atributos del vector compuesto son una representación compactade las propiedades de los elementos del modelo y de las relaciones para una indexa-ción gráfica eficiente. A partir de dos TAGs: TAG1(V1, E1) y TAG2(V2, E2), de dosmodelos comparados se construye un PairupGraph [17] PUG(Vpu, Epu) el cual es elproducto de dos TAGs. PairupGraph captura la estructura gráfica de la comparaciónde dos modelos.

La construcción de PairupGraph es guiada por un conjunto de predicados de via-bilidad definidos por el usuario. Estos predicados ayudan a recortar el espacio debúsqueda de acuerdo al conocimiento de un dominio específico. El valor inicial dela distancia de un nodo PairupGraph se calcula como la distancia Euclidiana de ladistancia normalizada entre los dos nodos del gráfico.

GenericDiff realiza un recorrido randómico sobre PairupGraph, por medio de unproceso iterativo que propaga los valores de la distancia desde un par de nodoshacia un par de nodos basados en la estructura del gráfico. Un recorrido randómicosobre el gráfico pude ser descrito por un modelo probabilístico que permite calcularla probabilidad rn(t) de iniciar la localización en cada nodo n en un solo paso t.

13


La distribución de probabilidades sobre todos los nodos es presentado por el vectorr(t) = [r1(t), ..., rN(t)], siendo N el número de nodos en el gráfico.

Se utiliza GenericDiff en aplicaciones con el propósito de detectar cambios en lascaracterísticas de familias de productos de software, la depuración de comporta-mientos que evolucionan de una especificación formal, el reconocimiento de cambiosevolutivos de un programa y para identificar las diferencias entre copias de unamisma instancias.

2.2. Análisis de modelos

En etapas posteriores al desarrollo de software, los procesos de pruebas y el controlde versiones en la ingeniería de software estándar, han sido aceptadas como acti-vidades para asegurar la calidad y el mantenimiento del software. Una actividadmuy utilizada durante cualquier etapa del ciclo de vida del software es almacenarvarias versiones de artefactos de software y la capacidad de retornara a una confi-guración anterior. Los sistemas de control de versiones tradicionales trabajan conarchivos de texto lineales, pero no son de gran ayuda con los modelos, porque losmodelos son estructuras de datos que se representan a través de un árbol jerárquicoo mediante notación gráfica. Por lo tanto, existe un desfase de abstracción entre lasherramientas de control de versiones actualmente disponibles (por ejemplo: CVS6,SVN 7, Microsoft SourceSafe8) y la naturaleza jerárquica de los modelos.

Existe mucho interés por parte de la comunidad científica por dar un soporte alcontrol de versiones y a las pruebas de transformación de modelos en el DSDM,trabajos como [18][19][20] proponen alternativas para dar soporte a estos procesos.El requisito principal es la comparación de modelos, por tal motivo herramientascomo GenericDiff [16] y EMF Compare [7] soportan la comparación de modelos enproyectos de DSDM. El resultado de la comparación se especifica con el estándar deficheros XMI9. KIELER [21] es una propuesta de visualización gráfica que propor-ciona una solución basada en EMF Compare con una vista estructurada y gráficadel resultado de la comparación.

La utilización de métricas en el contexto del DSDM ofrecen una alternativa pararealizar un análisis a los modelos. Existen varias propuestas para aplicar métricas amodelos, por ejemplo la propuesta de [22] ofrece una herramienta para obtener unreporte de métricas sobre los esfuerzo de migración de aplicaciones software, o lapropuesta de [23] que establece una métrica para medir la reutilización de modelosa nivel empresarial. Finalmente, la investigación de M. Ruiz [24] propone un métodode análisis a la evolución de modelos conceptuales con la aplicación de métricas al

6http://sourceforge.net/apps/trac/sourceforge/wiki/CVS7http://subversion.apache.org/8http://msdn.microsoft.com/es-es/library/3h0544kx(v=vs.80).aspx9http://www.omg.org/spec/XMI/

14

2.3 Análisis y discusión

resultado de la comparación entre modelos, para analizar los cambios realizados enel desarrollo de un nuevo sistema de información.

2.3. Análisis y discusión

Este capítulo presentó un conjunto de propuestas que se utilizan como punto departida para solventar el reto de la investigación. Se explica un conjunto de aspectosy propiedades que se deben considerar al realizar una comparación de modelos. Pro-puestas como GenericDiff [16] y EMF Compare [7] ofrecen un solución a la compara-ción de modelos, en cambio la propuesta de KIELER [21] propone una comparaciónvisual de modelos gráficos con EMF Compare como motor de comparación.La mayor parte de los esfuerzos de investigación en el campo del DSDM se centran endar un soporte al control de versiones o a la transformación de modelos. La propuestade M. Ruiz [24] ofrece un método de análisis de evolución de modelos conceptualesen base a la comparación de modelos. Las propuestas para la comparación y análisisde modelos que se presentan en este capítulo tienen relevancia en el desarrollo deesta tesis. Experiencias de los trabajos presentados han sido tomados en cuenta paraafronta el reto de proponer una solución al análisis del resultado de la comparaciónde modelos.

15

3 Diseño de la soluciónEl avance de la tecnología ocasiona que el mundo se encuentre en un continuo cam-bio, las empresas deben considerar reinventar sus procesos de negocio de acuerdo alas nuevas demandas de su entorno o cambios en sus objetivos empresariales. Unapráctica común en las organizaciones, es guiar la evolución utilizando modelos dereferencia que les permita garantizar su adaptación a nuevas normativas, leyes, re-quisitos, etc. Los sistemas de información juegan un rol importante dentro de laevolución de una organización porque facilitan la automatización de los procesos denegocio. La evolución de los sistemas de información tienen un soporte dentro de lareingeniería de procesos. Dentro del paradigma de Desarrollo de Software Dirigidopor Modelos (DSDM) un método que soporta la evolución de procesos organizacio-nales se propone en [1][2], donde el objetivo principal es dar un soporte a la evoluciónde modelos conceptuales, lo que da origen a un nuevo reto de investigación, la crea-ción de una herramienta que de soporte al análisis de la comparación de modelos enescenarios de evolución.En este capítulo se presenta el diseño de la solución que da soporte al análisis dela comparación de modelos conceptuales en escenarios de evolución. Se explica elmétodo para el análisis de modelos delta a partir de la comparación de modelos.Se propone una arquitectura genérica y extensible a la solución bajo la tecnologíade plugins1 en Eclipse Modeling Framework (EMF) [8]. Finalmente se define unconjunto de métricas que deben ser aplicadas sobre los modelos delta con el fin deobtener información cuantitativa del modelo delta resultante de la comparación.

3.1. Un método para el análisis de modelos delta

Tradicionalmente en el desarrollo de software, la evolución de los procesos y el man-tenimiento de los sistemas de información han sido enfrentados por medio de pro-cesos de reingeniería [3]. La reingeniería de procesos es ampliamente utilizada porla comunidad científica por medio de la metáfora del modelo la herradura [2] (verFigura 3.12), el cual consta de tres procesos y cuatro artefactos:

Proceso de ingeniería inversa: consiste en una extracción desde un sistemaexistente para obtener una especificación del sistema. Ingresa como primer

1Un plugin es una aplicación que se relaciona con otra para aportarle una función nueva y gene-ralmente muy específica.

2Esta figura se tomó y modificó de [2].

17

Capítulo 3 Diseño de la solución

artefacto el sistema As-Is que es el sistema sobre el cual se desea realizarlas modificaciones. El resultado del proceso es el segundo artefacto, el modeloAs-Is que es un modelo con un nivel más alto de abstracción.Proceso de evolución: consiste de un conjunto de transformaciones desde unsistema viejo hacia un sistema nuevo. Se realizan los cambios necesarios enel modelo As-Is para que el sistema viejo evolucione y cumpla con los nuevosrequisitos y metas de la organización. El resultado es el tercer artefacto, elmodelo To-Be.Proceso de ingeniería directa: consiste en actividades de desarrollo de softwareconvencional. A partir del modelo To-Be se realizan un conjunto de transfor-maciones para obtener código ejecutable. El resultado de este proceso es elcuarto artefacto, el sistema To-Be.

SISTEMA

AS-IS

MODELO

AS-IS

MODELO

TO-BE

SISTEMA

TO-BE

MODELO

DELTA

METAMODELO

EVOLUCIÓN

EVOLUCIÓN

ING

EN

IER

ÍA

INV

ER

SA

ING

EN

IER

ÍA

DIR

EC

TA

NIV

EL

DE

AB

ST

RA

CC

IÓN

-

MODELO METAMODELO PROCESO INSTANCIA

EXISTENCIA DE

RELACIONES DE

ASOCIACIÓN

METRICAS

+

Figura 3.1: Proceso de reingeniería guiado por el modelo de herradura.

El proceso de evolución permite realizar un análisis entre el modelo As-Is y el modeloTo-Be mediante un metamodelo de evolución [2] (ver Figura 3.23) que soporta latrazabilidad entre los modelos. La trazabilidad es un concepto ampliamente utilizadoporque ayuda a identificar las relaciones entre elementos que pertenecen a diferentesmodelos. Con la ayuda de operadores se especifica la relación que existe entre loselementos de cada modelo. Se especifica cuatro operadores básico de evolución:

Operador EQUAL: se utiliza cuando un elementos del modelo As-Is es igual aun elemento del modelo To-Be.Operador MODIFIED: se utiliza cuando un elementos delmodelo As-Is es igual aun elemento del modelo To-Be pero algunas de sus propiedades han cambiado.Por ejemplo, el nombre es una propiedad de un elemento que puede cambiar.


18

3.1 Un método para el análisis de modelos delta

Operador ADDED: se utiliza cuando se ha agregado un nuevo elemento en elmodelo To-Be que no existe en el modelo As-Is.Operador DELETED: se utiliza cuando se ha eliminado un elemento en elmodeloTo-Be que existe en el modelo As-Is.

MODEL_ELEMENT

OPERATOR: EVOLUTION_OPERATOR

EVOLUTION_TRACE0..1 0..*

0..1 0..*

As-Is

To-Be

EQUAL MODIFIED ADDED DELETED

<<ENUMERATOR>>EVOLUTION_OPERATOR

Figura 3.2: Metamodelo de evolución.

El reto del diseño de una solución que de soporte al análisis de la comparación demodelos conceptuales en escenarios de evolución tiene como base la comparaciónde modelos. En el proceso de evolución se deriva un modelo delta que especifica loscambios de un modelo To-Be respecto a un modelo As-Is. El procedimiento paraderivar un modelo delta a partir del resultado de una comparación de modelos hasido concebido para dar soporte al paradigma de DSDM en escenarios de evolución.El método para el análisis de modelos delta consta de tres actividades principales:derivación del modelo delta, medición del modelo delta y el análisis de cambios. LaFigura 3.34 muestra el método para el análisis de modelos delta.

MODELO M1 MODELO M2

d(M1,M2)

METAMODELOEVOLUCIÓN

RELACIÓN DE INSTANCIA

RELACIÓN DE ASOCIACIÓN

MÉTRICAS

MÉTRICASMETAMODELO MODELO

d(a,b)

COMPARACIÓN Delta (d) entre los

modelos a y b

1. Derivación del modelo delta

2. Medición del modelo delta

3. Análisis de cambio

MODELODELTA

LEYENDA

DIMENSIONES DE ANÁLISIS

DIMENSIONES

Figura 3.3: Método para el análisis de modelos delta.


19


3.1.1. Derivación del modelo delta

La derivación del modelo delta se realiza en base a la propuesta de M. Ruiz [4].Es actividad comienza con la comparación entre el modelo M2 (modelo To-Be) conrespecto al modelo M1 (modelo As-Is). La comparación se realiza entre los atributode los elementos de cada modelo. Con la ayuda de los operadores básicos de evoluciónse especifica el tipo de relación que existe entre los elementos de cada modelo. Parareferirnos a la comparación entre los modelos M1 y M2 se utiliza el término delta yla expresión d(M1, M2).

A partir del metamodelo de evolución se deriva un modelo delta que se utiliza paraalmacenar la información del resultado de la comparación. Los modelos M1, M2 ydelta pertenecen al mismo metamodelo.

El modelo delta describe las trazas que existe entre los elementos del modelo M1 yel modelo M2. Estas trazas están cualificadas mediante los operadores de evoluciónque indican el tipo de relación que existe entre los elementos cada modelo.

3.1.2. Medición del modelo delta

La medición del modelo delta se realiza en base a la propuesta de [4]. Para realizarla medición del modelo delta se debe recorrer todos los elementos del modelo quepertenezcan a un comparación específica. Cuando se recorre los elementos se debeasignar un valor numérico a cada elemento para obtener la cardinalidad del modelo.Por razones de diseño la cardinalidad es el número de elementos del modelo delta.La cardinalidad es la base para aplicar cuatro tipos de métricas genéricas sobre loselementos del modelo delta.

3.1.2.1. Métricas para modelos delta

Peso ponderado (S) La métrica peso ponderado es la sumatoria de los pesos Wde los elementos de un modelo M.

La Figura 3.45 muestra el modelo delta d(M1, M2) que se obtiene de las diferencias(*) y semejanzas (=) entre dos diagramas de transición de estados M1 y M2. Parael modelo delta un elemento es una traza, es decir, la traza es la relación entre elelemento A del modelo M1 y el elemento A del modelo M2.

Ejemplo: el cálculo del peso ponderado de d(M1, M2) donde el peso de cada trazaes 1, es: S(d(M1, M2)) = 8

5Esta figura se tomó de [4]

20

3.1 Un método para el análisis de modelos delta

A

B

C

A

B D

C

=

=

=

=

=

**

*

= *

LEYENDA

ESTADO TRANSICIÓN IGUAL CAMBIO TRAZA

M1 M2d(M1, M2)

Figura 3.4: Modelo delta d(M1, M2).

Peso ponderado meta (S↑) Es la sumatoria de los pesos W de los elementosde un modelo M, donde las ponderaciones se derivan de los pesos asignados en elmetamodelo MM.Con el fin de enfatizar la importancia del operado de igualdad en d(M1, M2) dela Figura 3.4 se asigna un peso de 1, al contrario del operador de cambio al que seasigna un peso de 0 (ver Tabla 3.1).

OPERADOR = *PESO 1 0

Tabla 3.1: Peso de cada operador del modelo delta.

Ejemplo: El cálculo del peso ponderado meta de d(M1, M2) de acuerdo con laTabla 3.1 es: S↑(d(M1,M2)= 5.

Peso ponderado relacionado (S ←) Es la sumatoria de los pesos W de los ele-mentos de un modelo Ma, donde los pesos son derivados desde la asignación de pesosen un modelo Mb.Para enfatizar la importancia de algunos estados en d(M1, M2) de la Figura 3.4 seda un peso a cada elemento según la Tabla 3.2.

ELEMENTO A B C D

PESO 1 1 0.5 0.5

Tabla 3.2: Peso de los estados de M1 y M2.

21


Ejemplo: El cálculo del peso ponderado relacionado de d(M1, M2) de acuerdo a laTabla 3.2 es: S←(d(M1, M2)) = 4.

Peso ponderado relacionado meta (S ↖) Es la sumatoria de los pesos W de loselementos del modelo Ma, donde las ponderaciones se derivan de los pesos asignadosen un metamodelo MMb de tal manera que se relaciona con el modelo Mb.Para conocer cuantas trazas enlazan las instancias del concepto de estado en d(M1,M2) de la Figura 3.4, se asigna un peso de 1 a la metaclase estado y 0 a la metaclasetransición (ver Tabla 3.3).

METACLASE ESTADO TRANSICION

PESO 1 0

Tabla 3.3: Peso de cada metaclase del metamodelo del diagrama de estados.

Ejemplo: El cálculo del peso ponderado relacionado meta de d(M1, M2) de acuerdoa la Tabla 3.3 es: S ↖ (d(M1, M2)) = 4.

3.1.3. Análisis de cambios

El análisis del modelo delta se realiza a partir de aplicar el conjunto de métricas sobrelos elementos del modelo delta. Cada métrica da como resultado un valor numéricoque depende de los pesos asignados a los elementos de cada métrica. Gracias a laposibilidad de asignar a cada elemento de cada métricas un valor numérico se puedeanalizar el impacto que tendrán las modificaciones del modelo M2 con respecto almodelo M1. El resultado de cada métrica por el alcance de esta solución únicamenteproporciona las directrices para la interpretación del resultado de la comparación.

3.2. Soporte al análisis de modelos delta

Esta sección describe el soporte a las actividades (ver Figura 3.3) del método parael análisis de modelos delta. Las actividades de derivación y medición del modelodelta se detallan en esta sección. Por el alcance de esta tesis se deja la actividadanálisis de cambios como un reto de investigación para trabajos futuros.El soporte al análisis de modelos delta es el resultado de agrupar un conjunto deartefactos de acuerdo a sus características para dar una solución al problema delanálisis a la comparación de modelos. Estos artefactos forman una herramientaque se implementa siguiendo la arquitectura de plugins de Eclipse6. Cada pluginespecifica una funcionalidad de la herramienta, de este modo la derivación del modelo

6http://www.eclipse.org/

22

3.2 Soporte al análisis de modelos delta

delta es soportado por el plugin EMF Compare [7] y el componente de derivación delmodelo delta. La medición del modelo es soportado por el componente de métricas.El componente de derivación del modelo delta y el componente de métricas formanun plugin que da soporte al análisis de la comparación de modelos. Los pluginsson soportados por Eclipse Modeling Framework (EMF). La Figura 3.57 presenta eldiseño de la arquitectura para la implementación del soporte al análisis de modelosdelta.

COMPONENTE MÉTRICAS

EMF Compare

COMPONENTE DERIVACIÓN

MODELO DELTA

Eclipse Modeling Framework

ANALISTA

S=7

S↑=5

1. Derivación del modelo delta 2. Medición del modelo deltaMODELOS

MEDICIONES

Figura 3.5: Arquitectura del soporte al análisis de modelos delta.

La Figura 3.68 presenta el detalle de las actividades de derivación y medición demodelos delta, donde se puede observar el conjunto artefactos que interactúan conlos diferentes componentes. Por razones de diseño se han establecido fases en elsoporte del análisis de modelos delta para facilitar la comprensión de las funcionesque cumplen cada artefacto dentro de la solución.El soporte para el análisis de modelos delta consta de tres fases principales: compararmodelos, derivar el modelo delta y medir el modelo delta. La Figura 3.6 muestra losartefactos que están involucrados en cada fase y un resumen de la secuencia deactividades de cada plugin.La Figura 3.79 muestra el modelo de dominio de la solución técnica para el análisisde la comparación de modelos. El modelo de dominio se representa mediante diagra-mas de clases UML10, donde se explica las clases conceptuales y las relaciones queforman parte del dominio del problema. Finalmente, esta sección muestra partes dela funcionalidad mediante pedazos de código en lenguaje de programación Java11.

3.2.1. Comparar modelos

Esta fase se ocupa de la comparación de dos modelos M1 y M2 que corresponden a unmismo metamodelo. El plugin EMF Compare realiza la agrupación de los elementosde dos modelos (M1 y M2) que sean similares de acuerdo al valor de sus atributos,

7Esta figura se tomó y modificó de [25]8Esta figura se tomó y modificó de [25]9Esta figura se tomó y modificó de [25]

10http://www.uml.org11http://www.java.com/es/download/whatis_java.jsp

23


PLUGIN EMF Compare

COMPONENTEDERIVACIÓN

MODELO DELTA

COMPONENTEMÉTRICAS

1) Comparar modelos

2) Derivar modelo delta

3) Medir modelo delta

MÉTRICAS

MODELO M1

METAMODELO MODELO DELTA

MODELO DELTA

d(M1, M2)

RESULTADO COMPARACIÓN

M1 M2

MEDIDAS

S = 7

METAMODELO MODELO

MODELO M2

MÉTRICAS PARA

MODELOS

Figura 3.6: Componentes del soporte al análisis de modelos delta.

luego realiza la comparación entre cada atributo para determinar si existe un cambioo una similitud entre los elementos. El resultado de la comparación está agrupadoen listas por la jerarquía de los elementos y con la información necesaria sobre lacomparación entre los elementos de cada modelo.

3.2.1.1. EMF Compare

Es una herramienta que proporciona un soporte genérico para cualquier tipo de mo-delo en Eclipse Modeling Framework (EMF)[8]. Ofrece una implementación establey eficiente a la comparación de modelos, con un marco extensible que trabaja en elentorno de desarrollo integrado Eclipse. La primera versión de EMF Compare fuedesarrollada por Eclipse Foundation12 en colaboración con las empresas Obeo13 e Inta-lio14 en el año 2006. EMF Compare posee seis fases dentro del proceso de comparación demodelos:

1. Resolución de modelos: dado dos modelos M1 y M2 se valida que pertene-cen a un metamodelo común para garantizar que se pueda realizar la fase deagrupamiento.

2. Agrupamiento: el objetivo de esta fase es descubrir cual de los elementos delmodelo M1 son similares al modelo M2 para agruparlos en parejas. Se puederecorrer los elementos de los modelos y agruparlos por su identificador, o en

12http://www.eclipse.org13http://www.obeo.fr/pages/acceleo-pro-compare/en14http://www.intalio.com

24


SizeWeighted

SizeWeightedMetaSizeWeightedRelatedSizeWeightedRelatedMetaModelComparison

Model Concept Element Operator

ModelElement

EvolutionTrace ElementComparison

EvolutionOperator

Figura 3.7: Modelo de dominio del soporte al análisis de modelos delta.

caso que no tengan un identificador por medio de un mecanismo de distanciadonde se realiza el cálculo de la similitud.

3. Diferencia: en esta fase EMF Compare ya no recorre los elementos de losmodelos M1 y M2. A partir del agrupamiento de parejas de la fase anterior seprocede a realizar el cálculo de la diferencia entre los modelos. Si existe unapareja con un elemento del modelo M1 y un elemento del modelo M2 se calculasu similitud o diferencia. En el caso que exista solo un elemento del modeloM1 se entiende que existe una eliminación del elemento en el modelo M2 y enel caso contrario si solo existe un elemento en el modelo M2 se entiende queexiste la incorporación de un nuevo elemento en el modelo M2.

4. Equivalencia: el resultado de la fase anterior se aísla para obtener las relacionesentre las diferencias de los modelos M1 y M2. Se puede dar el caso que si se ac-tualiza manualmente una referencia otra se actualizará automáticamente, porejemplo en el caso de UML existe un concepto de referencia para subconjuntosy superconjuntos, si se agrega un elemento en un subconjunto se actualizaráautomáticamente la referencia en el superconjunto, pero no sucede en el casocontrario.

5. Requerimientos: se utiliza para hacer frente a las limitaciones estructurales yasegurar la calidad del modelo. Por ejemplo, el complemento de una referenciarequiere el complemento del objeto referenciado y el complemento del objetoque contiene esta referencia.

25


6. Conflictos: se realiza la solución de conflictos, por ejemplo en el caso de agregarun elemento en un subconjunto de UML y no se agregue automáticamente enun superconjunto.

EMF Compare utiliza un algoritmo de comparación denominado Subsecuencia Co-mún más Larga (Longest Common Subsequence – LCS) donde el objetivo es determi-nar la subsecuencia común más larga que se puede obtener mediante la eliminaciónde cero o más símbolos de cada una de dos cadenas dadas, el algoritmo se explicadetalladamente en [12].La Figura 3.815 muestra la arquitectura de EMF Compare, donde EMF CompareCore es el núcleo de un conjunto de componentes de Eclipse Modeling Framework.GMF Compare es un marco para la comparación de modelos en un entorno gráfico.UML Compare realiza el soporte para la comparación de modelos UML. EMF Com-pare UI, GMF Compare UI y UML Compare UI se encargan de permitir la creacióny manipulación de modelos que serán el insumo de la comparación de modelos.

EMF Compare Core

EMF Compare UIGMF Compare UML Compare

GMF Compare UI UML Compare UI

Figura 3.8: Arquitectura de EMF Compare.

Al ser Eclipse un entorno de desarrollo extensible está compuesto por un conjuntode plugins, donde cada plugin cumple una función especifica. Por lo tanto, EMFCompare necesita un conjunto de dependencias o plugins para que pueda operar connormalidad. El siguiente es el conjunto mínimo de dependencias de EMF Compare:

org.eclipse.emf.commonorg.eclipse.emf.ecoreorg.eclipse.emf.ecore.xmiorg.eclipse.emf.comparecom.google.guava

EMF Compare está desarrollado bajo el lenguaje de programación Java. Para realizaruna comparación entre dos modelos se debe seguir una secuencia básica de comandosque se detalla en el Algoritmo 3.1. Las líneas 1 y 2 realizan la carga de los modelosen objetos URI. La línea 3 permite que los archivos del tipo Ecore16 puedan serreconocidos e interpretados en el proceso de comparación. Si se desea utilizar otro15Esta figura se tomó y modificó de http://www.eclipse.org/emf/compare/doc/21/16http://www.omg.org/spec/MOF/2.4.1/

26


tipo de archivos con EMF Compare se debe registrar de la misma forma que enla línea 3, especificando su extensión y la clase que permitirá la interpretación delos objetos del nuevo modelo. Desde la línea 4 a la 7 se crean recursos del tipoResourceSet para resolver los modelos mediante un árbol de contenidos. La línea 8limita el alcance de la comparación, para el caso del ejemplo se realiza la comparacióncon dos modelos pero se puede realizar la comparación con tres modelos en caso deutilizarlo con un control de versiones. La línea 9 ejecuta el proceso de comparación yfinalmente en la línea 10 se obtiene un una lista con las diferencias entre los modelos.

Algoritmo 3.1 Ejemplo básico de EMF Compare con Java.1. URI uri1 = URI.createFileURI("path/to/first/model.xmi");2. URI uri2 = URI.createFileURI("path/to/second/model.xmi");3. Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().put("ecore", new EcoreRe-sourceFactoryImpl());4. ResourceSet resourceSet1 = new ResourceSetImpl();5. ResourceSet resourceSet2 = new ResourceSetImpl();6. resourceSet1.getResource(uri1, true);7. resourceSet2.getResource(uri2, true);8. IComparisonScope scope = new DefaultComparisonScope(resourceSet1, resourceSet2);9. Comparison comparison = EMFCompare.builder().build().compare(scope);10. List<Diff> differences = comparison.getDifferences();

Durante el proceso de comparación, la estrategia es descomponer el problema enpartes porque su complejidad es múltiple y se deben tener en cuenta aspectos comoel cálculo de la comparación, la representación de la diferencia y la visualización enuna notación comprensible de los resultados de la comparación.

La Figura 3.9 presenta un resumen general del esquema que se implementa en lasolución técnica para utilizar el plugin EMF Compare dentro de la herramienta delanálisis de la comparación de modelos. Para el uso de este plugin, se han implemen-tado las siguientes clases Java:

Model: Gestiona la carga de los modelos, de manera que puedan ser utilizadospor EMF Compare.

ModelComparison: Utiliza la funcionalidad de EMF Compare para realizar lacomparación de modelos y entregar el resultado de la comparación al siguientecomponente.

ModelComparison

Model

Figura 3.9: Esquema de la comparación de modelos.

27


EMF Compare está implementado en Eclipse con Graphical Modeling Framework(GMF)17 para dar soporte a la comparación de modelos gráficos. GMF proporcionauna infraestructura de componentes en tiempo de ejecución para el desarrollo deeditores gráficos basados en Eclipse Modeling Framework (EMF)18 y en el GraphicalEditing Framework (GEF)19.Se puede utilizar EMF Compare de manera autónoma sin la necesidad de un en-torno gráfico (ver Algoritmo 3.1) pero con la limitación que reconoce únicamente losdiagramas Ecore. Eclipse soporta la comparación de cualquier tipo de modelo quese instale en su entorno de desarrollo integrado. Por ejemplo, si se utiliza Papyrus20para crear dos modelos en un entorno gráfico, EMF Compare se apoya en los pluginsde GMF, UML y Papyrus que están instalados en Eclipse para realizar el procesode lectura e interpretación de cada modelo desde el entorno gráfico, de manera quela información llegue en un formato genérico XMI21 para realizar la comparación.El diseño de la solución para el soporte al análisis de la comparación de modelos,utiliza en primera instancia a EMF Compare de manera autónoma, lo que significaque únicamente soporta diagramas Ecore para realizar la comparación de mode-los, dejando como trabajo futuro la integración con Graphical Modeling Framework(GMF) y dar soporte a la comparación de modelos que sean instancia de Ecore.

3.2.2. Derivar el modelo delta

Esta fase se encarga de realizar el procesamiento del resultado de la comparaciónpara utilizar esta información en la derivación del modelo delta. Es fase realiza dosprocesos fundamentales:

1. Procesamiento del resultado de la comparación de modelos: se debe recorrerel resultado de la comparación entre los modelos M1 y M2 para identificar eltipo de cambio o similitud que existe entre cada elemento. En cada iteraciónse debe clasificar los elementos de acuerdo a los operadores de evolución (verFigura 3.2) .

2. Instanciación del modelo delta: a partir del metamodelo de evolución (verFigura 3.2) se genera una instancia denominada modelo delta para almacenarla información que se produce luego del procesamiento del resultado de la com-paración de modelos en base a la clasificación de los operadores de evolución.La información que se almacena en el modelo delta es la trazabilidad entre losmodelo M1 y M2 respecto a los cambios realizados.

Con el fin de dar un soporte a la derivación de modelos delta, se ha implementadoel metamodelo de evolución presentado en [2] (ver Figura 3.2). Este metamodelo17http://www.eclipse.org/modeling/gmp/18http://www.eclipse.org/modeling/emf/19http://www.eclipse.org/gef/20http://www.eclipse.org/papyrus/21http://www.omg.org/spec/XMI/

28


ha sido desarrollado con el objetivo de especificar modelos de cambio en escenariosde evolución, comúnmente utilizados en la reingeniería de sistemas de información.El modelo de evolución está diseñado para indicar los cambios entre dos modelosM1 y M2, donde el modelo M1 representa un sistema actual (sistema As-Is) y elmodelo M2 representa el sistema que satisface los requisitos que han dado lugar auna reingeniería (sistema To-Be). El metamodelo de evolución se compone de unametaclase EVOLUTION_TRACE para especificar cuatro operadores, los cuales se utilizanpara describir la evolución de los elementos de un modelo M1 hacia un modelo M2.Los cuatro operadores (EQUAL, MODIFIED, ADDED, DELETED) cualifican la evoluciónde los elementos pertenecientes a M1 y M2. La metaclase EVOLUTION_TRACE tienedos asociaciones bidireccionales con la metaclase MODEL_ELEMENT que representanal modelo M1 (modelo As-Is) y al modelo M2 (modelo To-Be).La Figura 3.10 presenta un resumen general del esquema que se implementa parala derivación del modelo delta. A partir del metamodelo de evolución se crea uninstancia para generar el modelo delta y con el resultado de la comparación delos modelos M1 y M2 se almacena la información sobre la comparación de cadaelementos. Con la ayuda de los cuatro operadores se especifica el tipo de diferenciao similitud que existen entre cada elementos de los modelos M1 y M2. Por cuestionesde diseño se almacena la información de los elementos del modelo delta para facilitarla aplicación de métricas al resultado de la comparación.

ModelElement

EvolutionTrace ElementComparison

EvolutionOperator

Figura 3.10: Esquema de la derivación del modelo delta.

El detalle de cada clase del esquema para implementar la derivación del modelodelta se explica a continuación:

ModelElement: es la implementación de la metaclase MODEL_ELEMENT del me-tamodelo de evolución, donde se gestionan los elementos de los modelos M1 yM2.EvolutionTrace: es la implementación de la metaclase EVOLUTION_TRACE delmetamodelo de evolución, donde se gestiona el resultado de la comparación delos modelos.ElementComparison: esta clase identifica los cambios en el modelo delta resul-tante de la comparación de los modelos M1 y M2.

29


EvolutionOperator : especifica los operadores EQUAL, MODIFIED, ADDED y DELE-

TED.

3.2.3. Medir el modelo delta

Esta fase se ocupa de la medición del modelo delta para obtener información cuan-titativa acerca de los elementos del modelo. Se debe recorrer el modelo delta paraobtener la cardinalidad del modelo. Por razones de diseño se agrega a la cardina-lidad información como: tipo de cambio, nombre del elemento y el modelo al quepertenece el elemento. Se aplica el componente de métricas para obtener informacióncuantitativa que depende del peso asignado a cada elemento de cada métrica. Lasmétricas actualmente implementadas en el repositorio son:

Peso ponderado (Size weighted): es el tamaño del modelo según el peso de loselementos del modelo. Cardinalidad del modelo es un caso especial de estamétrica, donde el peso de cada elemento del modelo es 1. La cardinalidad dainformación del número de elementos del modelo.

Peso ponderado meta (Size weighted meta): es el tamaño del modelo donde lospesos de los elementos son derivados del peso asignado a la metaclases de lacual los elementos son instancia.

Peso ponderado relacionado (Size weighted related): es el tamaño del modeloMa relacionado al modelo Mb, donde los pesos de los elementos de Ma sonderivados de los elementos de Mb.

Peso ponderado relacionado meta (Size weighted related meta): es el tamañodel modelo Ma relacionado al modelo Mb, donde los pesos de los elementosde Ma son derivados de los pesos asignados a los elementos del metamodeloMMb del cual Mb es instancia.

El componente de métricas (ver Figura 3.6) se encarga de la medición del modelodelta para obtener información cuantitativa de los elementos del modelo. Se deberecorrer el resultado del componente de derivación del modelo delta para calcular sucardinalidad. La cardinalidad es el número de elementos que tiene el modelo delta.Cada métrica tiene un conjunto de parámetros que se debe ingresar para medir elmodelo delta, por ejemplo si se elige la métrica peso ponderado meta se de asignarel peso a cada operador (EQUAL, MODIFIED, ADDED, DELETED), donde el peso que seasigna a cada operador depende de la importancia que tenga el cambio o similitudde un elemento del modelo delta. Finalmente luego de asignar los valores a cadaelemento de la métrica seleccionada se procede a realizar el cálculo para obtener unvalor cuantitativo que sirve para la analizar del impacto que tendrán los cambios enel modelo M2 (modelo To-Be) con respecto al modelo M1 (modelo As-Is).

La Figura 3.11 presenta un resumen general del esquema que implementa el reposi-torio de métricas. El detalle de cada clase del esquema se explica a continuación:

30


SizeWeighted

SizeWeightedMetaSizeWeightedRelatedSizeWeightedRelatedMeta

Concept Element Operator

Figura 3.11: Esquema de las métricas.

SizeWeigthed: realiza el cálculo de la sumatoria de los pesos asignados a cadaelemento de un modelo, para obtener el peso ponderado del modelo resultantede la comparación de modelos.SizeWeightedMeta: realiza el cálculo de la sumatoria de los pesos asignados acada elemento de un modelo, donde la ponderación de los pesos es asignadoen el metamodelo de evolución.SizeWeightedRelated: realiza el cálculo de la sumatoria de los pesos de loselementos de un modelo Ma, donde la ponderación de los pesos se asigna enlos elementos un modelo Mb relacionado al modelo Ma.SizeWeightedRelatedMeta: realiza el cálculo de la sumatoria de los pesos de loselementos de un modelo, donde la ponderación se deriva de los pesos asignadoa los elementos relacionados a su metamodelo.Operator : gestiona los operadores de evolución.Element: gestiona la evolución de los elementos del modelo resultante de lacomparación de modelos.Concept: gestiona los elementos relacionados a un metamodelo, por ejemplolos elementos relacionados con el metamodelo Ecore.


Este capítulo presentó las actividades que dan soporte al diseño de la solución.La actividad de derivación del modelo delta permite almacenar el resultado de lacomparación de modelos en una instancia que se crea a partir del metamodelo deevolución propuesto en [2] y con la ayuda de los operadores de comparación se espe-cifica el tipo de cambio que existe entre los elementos de los modelos. La aplicaciónde un conjunto de métricas sobre el modelo delta, permite realizar la actividad demedición del modelo delta para obtener un valor cuantitativo que se utiliza paraanalizar el impacto del cambio en el modelo M2 con respecto al modelo M1.

31


El diseño de la herramienta que solventa el análisis de la comparación de modelosestá desarrollado bajo la tecnología de plugins de Eclipse. Como soporte a la compa-ración de modelos se utiliza a EMF Compare[7] de manera autónoma para facilitar lamanipulación de los resultados de la comparación de manera programática. Sin em-bargo, esta manera autónoma de trabajo da como resultado la restricción de utilizardiagramas Ecore para realizar la comparación de modelos. EMF Compare trabaja enEclipse junto con un conjunto de componentes para facilitar la comparación gráficade modelos, y gracias a los componentes de Graphical Modeling Framework (GMF)se puede realizar la comparación de cualquier tipo de modelo. Por el alcance de estatesis se deja la integración de la solución en un entorno gráfico como un trabajofuturo.

32

4 Validación de la soluciónPara facilitar el uso de la solución al análisis de la comparación de modelos, se propo-ne un soporte tecnológico que automatice el análisis al resultado de la comparativamediante la implementación de un conjunto de métricas. Para lograr este objeti-vo, se propone el desarrollo de una herramienta para Eclipse Modeling Framework(EMF) [8]. La herramienta debe tener la arquitectura de plugins1 porque facilita suintegración con otros plugins dentro de EMF.En el ciclo de ingeniería EC1 descrito en la Sección 1.3 la validación del diseño esuna tarea del conocimiento, donde se valida si la herramienta propuesta cumple conlos objetivos de la investigación y se aplica en el contexto del dominio del problema.Por tal motivo, este capítulo detalla la validación de la herramienta con la ayudade modelos Ecore para aplicar un conjunto de métricas y analizar el resultado de lacomparación de modelos en escenarios de evolución.

4.1. Soporte tecnológico

Eclipse2 es un proyecto de software de código abierto, su principal objetivo es pro-porcionar una plataforma de herramientas altamente integrado. Eclipse incluye unmarco básico que soporta un marco genérico para la integración de herramientas yun entorno de desarrollo Java. Otros proyectos se extienden del marco básico paraapoyar a determinados tipos de herramientas y entornos de desarrollo. Los proyec-tos en Eclipse se implementan en Java y se ejecutan en varios sistemas operativos,incluyendo Windows, Mac OSX y Linux.Eclipse fue desarrollado originalmente por IBM como el sucesor de la familia deherramientas para desarrollo visual VisualAge. La Fundación Eclipse es una orga-nización independiente sin ánimo de lucro que fomenta una comunidad de códigoabierto y es quien ofrece el soporte a Eclipse y a todos sus componentes.El software que es desarrollado por la Fundación Eclipse está disponible bajo laLicencia Pública Eclipse (EPL)3, donde se explica en términos legales como se de-be utilizar, modificar y redistribuir el software de forma gratuita, y también paradistribuirlo junto a componentes propietarios como parte de un producto comercial.

1Un plugin es una aplicación que se relaciona con otra para aportarle una función nueva y gene-ralmente muy específica.

2http://www.eclipse.org3http://opensource.org/licenses/EPL-1.0

33

Capítulo 4 Validación de la solución

Eclipse se divide en numerosos proyectos, entre ellos están el proyecto Eclipse, elproyecto de modelado, el proyecto de herramientas y el proyecto de tecnología. Elproyecto Eclipse contiene los componentes necesarios para actividades de desarrolloen este marco de trabajo. Se puede descargar todos los componentes de Eclipse unasola unidad funcional que se denomina como el kit de desarrollo de software Eclipse(SDK).Eclipse Modeling Framework (EMF) es un marco de Eclipse que se encarga degestionar los modelos, como principal lenguaje de modelado utiliza UML4, ademáspuede gestionar una amplia jerarquía de modelos. EMF es un marco que facilita lageneración de código a partir de la definición de un modelo. La Figura 4.15 muestracomo EMF unifica tres tecnologías importantes Java, XML6 y UML para generarun modelo EMF.

Modelo EMF

UMLXML

Java

Figura 4.1: EMF unifica Java, XML y UML.

El modelo utilizado para representar modelos en EMF se llama Ecore. La Figura 4.27describe un ejemplo de un diagrama Ecore, donde cada clase representa un elementodel modelo:

EClass se utiliza para representar una clase del modelo.EAttribute se utiliza para representar un atributo del modelo.EReference se utiliza para representar una asociación entre clases.EDataType se utiliza para representar el tipo de un atributo.

El código Java, un esquema XML o un diagrama UML llevan información adicionalsobre el modelo Ecore debido a su estructura, pero no es obligatorio implementarestas tres tecnologías para crear un modelo Ecore. Por lo tanto, se creó el estándarXMI8 para la serialización de metadatos de forma concisa mediante XML y para laespecificación del intercambio de diagramas Ecore.Las siguientes secciones explican como se implementa el plugin para el análisis de lacomparación de modelos en el entorno de desarrollo integrado Eclipse. Este plugin

4http://www.uml.org5Esta figura se tomó y modificó de [8]6http://www.w3.org/XML/7Esta figura se tomó y modificó de [8]8http://www.omg.org/spec/XMI/

34

4.2 Instalación del plugin

name : String

EClass

name : String

EAttribute

EDataType

name : String contaniment : boolean

EReference

eAttributes

0..*

eAttributeType

1

eReferences

0..*

eReferenceType

1

Figura 4.2: Modelo Ecore.

está desarrollado bajo la arquitectura de plugins del proyecto Eclipse y se apoya enla tecnología de modelado de Eclipse Modeling Framework (EMF) para ejecutar lacomparación de dos modelos Ecore.

4.2. Instalación del plugin

De acuerdo al diseño de la herramienta descrito en la Capítulo 3, se desarrolló unplugin siguiendo las directrices de [26]. Como plataforma de desarrollo se utilizóEclipse Modeling Tools en su versión 4.3 del proyecto Eclipse Kepler y como lenguajede compilación y ejecución del plugin se utiliza Java en su versión Java SE 1.7. Pararealizar la comparación de modelos se utilizó a EMF Compare en su versión 3.0porque es compatible con el proyecto Eclipse Kepler. Para el normal funcionamientodel plugin que da soporte al análisis de la comparación de modelos se debe utilizarlas siguientes dependencias:

org.eclipse.core.resourcesorg.eclipse.ui.consoleorg.eclipse.debug.uicom.google.guavaorg.eclipse.emf.commonorg.eclipse.emf.ecore.xmiorg.eclipse.emf.ecoreorg.eclipse.emf.compare

La instalación del plugin pros.upv.sizeweighted.jar para el soporte de la compara-ción de modelos necesita como marco de trabajo a Eclipse Modeling Tools en suversión 4.3. En la carpeta principal de la instalación de Eclipse se debe accedera la carpeta plugins (Eclipse\plugins) y pegar el plugin pros.upv.sizeweighted.jar.

35


Cuando se inicie Eclipse para verificar que el plugin se instaló correctamente se de-ber ir a los detalles de la instalación y en la sección de plugins buscar el pluginpros.upv.sizeweighted.jar como se muestra en la figura Figura 4.3

Figura 4.3: Plugin pros.upv.sizeweighted.jar.

4.3. Uso del plugin

Primero se debe crear un Java Project. Se crea un diagrama Ecore mediante File→ New → Other → Ecore Tools → Ecore Diagram se ingresa el nombre deldiagrama y para finalizar se da clic en el botón Finish. La figura Figura 4.4 muestrala selección de un diagrama Ecore.

Figura 4.4: Seleccionar un diagrama Ecore.

Una vez creado el diagrama Ecore tenemos un lienzo en blanco para empezar a crearlos modelos. Para iniciar el análisis a la comparación de modelos se necesita unmodelo actual (modelo As-Is) del sistema o el modelo sobre el cual se desea realizarlas modificaciones para cumplir con los nuevos requerimientos de la organización.

36

4.3 Uso del plugin

Por otra parte necesitamos también el modelo que ha evolucionado (modelo To-Be)con los nuevos requerimientos implementados. La Figura 4.5 muestra un sistemaAs-Is que describe como se crea una instancia de modelo Ecore con EFactory.

Figura 4.5: Modelo As-Is para crear una instancia de un modelo Ecore.

Por cuestiones de diseño se elimina la clase SimpleType y se agrega el atributonombre a la clase Model, entonces como resultado a las modificaciones realizadas seobtiene elmodelo To-Be que se muestra en la Figura 4.6. Elmodelo To-Be representalos cambios realizados respecto al modelo As-Is.

Figura 4.6: Modelo To-Be para crear una instancia de un modelo Ecore.

Una vez que obtenemos el modelo As-Is y el modelo To-be, se procede a seleccionarel tipo de métrica que se desea obtener. Para seleccionar una métrica en Eclipsese debe señalar los dos modelos (modelo As-Is y modelo To-Be) dar clic derecho yaparece un menú donde debemos seleccionar la opción Size Weighted, entoncesse despliega un submenú con cuatro métricas. Las métricas que se describen en la

37


Subsección 3.2.3 están implementadas. La Figura 4.7 muestra como seleccionar lamétrica Size weighted meta.

Figura 4.7: Seleccionar una métrica Size Weighted.

Luego de seleccionar una métrica inicia el proceso de comparación, con la ayuda delplugin de EMF Compare se realiza el agrupamiento y la comparación de los elemen-tos de cada modelo. El resultado de la comparación es una estructura jerárquicaque agrupa la información de cada modelo y el resultado de la comparación en unconjunto de listas. Una vez que finaliza el proceso de comparación ya no se iterasobre los modelos (modelo As-Is y modelo To-Be), a partir de este punto se utilizala respuesta de EMF Compare para derivar un modelo delta que se crea a partir delmetamodelo que se explica en la Sección 3.1.

Con la creación del modelo delta a partir de la información del resultado de lacomparación se inicia el proceso para calcular la métrica seleccionada. Primero serealiza el cálculo de la cardinalidad del modelo delta, que es simplemente el cálculodel número de elementos del modelo delta. Para la métrica Size weighted metase debe ingresar un conjunto de valores a cada operador de cambio. La Tabla 4.1muestra los pesos asignados a cada operador.

38

4.3 Uso del plugin

OPERADOR EQUAL MODIFIED ADDED DELETED

PESO 0 1 2 3

Tabla 4.1: Tabla de pesos de la métrica Size weighted meta.

Con un rango de 0 a 3, donde el menor peso tiene el 0 y el mayor peso tiene el3 se asigna un peso de 2 al operador ADDED y un peso de 3 al operador DELETED

para evaluar las modificaciones realizadas. Por consiguiente, con los valores de cadaelemento de la métrica asignado se realizan los cálculos para obtener el resultado delanálisis a la comparación de modelos. La Figura 4.8 muestra el resultado del cálculode la métrica Size weighted meta, en la parte superior se detalla en un cuadrolos elementos de cada modelo con el resultado de la comparación de modelos y en laparte inferior están los pesos asignados a cada operador con el resultado del cálculode la métrica que para este caso es: Size weighted meta (d(model, model)) = 5.

Figura 4.8: Resultado del cálculo de la métrica Size weighted meta.

Por razones de simplicidad y para demostrar la utilización del conjunto de métricasse seleccionó la métrica Size weighted meta. Para utilizar el resto de métricasse debe seguir el procedimiento descrito en esta sección y asignar los pesos a cadaelemento de cada métrica, excepto a la métrica Size weighted porque es un casoespecial y su resultado es la cardinalidad del modelo delta.

39


4.4. Validación del plugin con un ejemplo ilustrativo

En esta sección se realiza el análisis del resultado de la comparación de modelosmediante la aplicación de las métricas descritas en la Subsección 3.2.3. Por lo tan-to, utilizamos como ejemplo ilustrativo un metamodelo9 a partir del cual se creaninstancias que representan aplicaciones de software basadas en ventanas o páginasen el caso de aplicaciones web.

El metamodelo puede crear aplicaciones con varias ventanas y a cada una asignarleun nombre para identificarla. Cada ventana puede tener varios marcos donde se pue-de visualizar distintos tipos de información, a cada marco se le asigna un nombre,la descripción del contenido y la posición en la cual se debe ubicar en la ventana.Además cada ventana puede mostrar un máximo de cinco menús, donde cada menúpuede especificar un nombre, la posición donde se debe ubicar y el número de ele-mentos que debe contener. Cada menú puede agrupar un máximo de diez elementosy cada elemento debe especificar su nombre y un enlace de navegación dentro o fuerade la aplicación.

La Figura 4.9 muestra el metamodelo que se utiliza para el caso de estudio, eneste caso el metamodelo es el modelo As-Is. Se describe el conjunto de clases y lasrelaciones que son necesarias para crear una instancias a partir del metamodelo, unejemplo de instancia es una página web básica.

Figura 4.9: Modelo As-Is del ejemplo ilustrativo.

9El ejemplo ilustrativo se tomó de la asignatura Ingeniería de Software con Modelos.

40

4.4 Validación del plugin con un ejemplo ilustrativo

La Figura 4.10 muestra un ejemplo para explicar el caso de estudio. Se utiliza lapágina web de la Universidad Politécnica de Valencia (UPV) para ejemplificar loselementos de una aplicación, donde una ventana es la página de presentación de laUPV. La ventana posee cinco menús: Admisión, Estudios, Investigación, Organiza-ción y Perfiles. El menú Estudios posee los elementos: Estudio de grado, Estudiode posgrado y Aula abierta. Existen cuatro marcos done se exponen las temáticas:Premio Convivencia y Progreso, Rechazo al recorte, Fibras de naranja y Aperitivode arándanos.Para obtener el modelo To-Be se realizan modificaciones sobre el modelo As-Is. Lanecesidad de nuevas características en las instancias del metamodelo genera una listade nuevos requisitos:

La aplicación debe tener una ventana principal con un banner central, dondese visualice alternadamente un total de siete imágenes.Cada imagen del banner debe tener un enlace de navegación.Para el caso de una ventana no principal el banner debe mostrar una imagenen la parte superior.Cada marco de la aplicación debe tener la capacidad de mostrar un imagenque describa la temática del marco.Cada imagen del marco debe tener un enlace de navegación que abra unanueva página con información detallada acerca de la temática del marco.Cada ventana puede tener un máximo de seis cuadros.Cada menú puede tener un máximo de seis elementos.

A partir de los nuevos requerimientos se realizan las modificaciones sobre el mo-delos As-Is para crear el nuevo modelo To-Be con las nuevas características de laaplicación. A continuación se detallan las modificaciones creadas sobre el modeloAs-Is:

Se agregó una clase Imagen.En la clase Imagen se agregaron los tributos Enlace y Ruta.Se agregó una clase Banner.Se agregó una asociación entre las clases Banner e Imagen donde se indica larestricción que un Banner puede contener de 1 a 7 imágenes.En la clase Ventana se se agregó el atributo Principal para especificar cual esla ventana principal de la Aplicación.Se agregó una asociación entre las clases Ventana y Banner donde se indicala restricción que una Ventana puede contener solo un Banner.Se modificó las relación entre las clases Ventana y Marco, donde se indica larestricción que una Ventana puede tener un máximo de seis Marcos.Se modificó las relación entre las clases Menú y Elemento, donde se indica larestricción que un Menú puede tener un máximo de seis Elementos.

41


Figura 4.10: Aplicación del ejemplo ilustrativo.

4.4.1. Caso I: métrica Size weighted

Se explica la métrica Size weighted en la Subsección 3.2.3 y en [4]. Una vez quese obtiene el modelos As-Is y el modelo To-Be se procede a realizar el análisis delresultado de la comparación de los modelos. El procedimiento para utilizar el pluginde análisis a la comparativa se explica en la Sección 4.3. La Figura 4.12 muestrael resultado de aplicar la métrica Size weighted sobre los modelos. El resultado deaplicar la métrica se despliega en la consola del Eclipse Modeling Tools, en la partesuperior de la consola se muestra un cuadro que contiene tres columnas. La primeracolumna describe mediante una estructura jerárquica los elementos que pertenecenal modelo As-Is. La segunda columna representa la diferencia que existe entre losmodelos y con la ayuda de operadores (EQUAL, ADDED, MODIFIED, DELETED) seespecifica el tipo de modificación que existe entre los elementos de cada modelo.La tercera columna describe mediante una estructura jerárquica los elementos quepertenecen al modelo To-Be.La métrica Size weighted es un tipo especial de métrica porque representa la cardi-nalidad del modelo delta resultante de derivar el resultado de la comparación de losmodelos. La cardinalidad por cuestiones de diseño representa el número de elementos

42


Figura 4.11: Modelo To-Be del ejemplo ilustrativo.

del modelo delta que pertenecen a una única comparación entre modelos.El resultado de aplicar la métrica Size weighted sobre el modelo As-Is y el modeloTo-Be es: Size weighted (d(modelo, modelo)) = 35.

4.4.2. Caso II: métrica Size weighted meta

Se explica la métrica Size weighted meta en la Subsección 3.2.3 y en [4]. La métricaSize weighted meta calcula el tamaño del modelo delta que resulta de derivar elresultado de la comparación de modelos, donde se debe asignar un peso a cadaelemento del enumerador EVOLUTION_TRACES que se explica en la Sección 3.1.Para continuar con el ejemplo ilustrativo y analizar los cambios que se realizaron enel modelo As-Is para evolucionar hasta el modelo To-Be, se crea un rango numéricopara asignar los pesos a los elementos de la métrica. El rango es de 0 a 3, dondeel menor peso tiene el número 0 y el mayor peso tiene el número 3. La Tabla 4.2muestra los pesos asignados a cada elemento de la métrica:Debido a las modificaciones que se realizaron en el modelo del ejemplo ilustrativo,se asignó el peso de 0 al operador EQUAL porque se considera que si un elementodel modelo As-Is es igual a un elemento del modelo To-Be no posee una influenciasobre el análisis del resultado de la comparación de los modelos. Se asignó el peso de

43


Figura 4.12: Métrica Size weighted.

1 al operador DELETED porque no se eliminó ningún elemento del modelo As-Is.Se asignó el peso de 2 al operador MODIFIED porque se modificó relaciones entrelas tablas del modelo As-Is y se desea realizar el análisis de las modificaciones en lasrelaciones. Finalmente se asignó el peso de 3 al operador ADDED porque se agregódos tablas nuevas y se desea analizar el impacto de las creación de las tablas.El resultado de aplicar la métrica Size weighted meta sobre el modelo As-Is y elmodelo To-Be es: Size weighted meta (d(modelo, modelo)) = 37.

4.4.3. Caso III: métrica Size weighted related

Se explica la métrica Size weighted realted en la Subsección 3.2.3 y en [4]. La métri-ca Size weighted related calcula el tamaño del modelo As-Is relacionado al modeloTo-Be, donde los pesos de los elementos del modelo As-Is son derivados de los ele-mentos del modelo To-Be. Esta métrica tiene la particularidad que se puede asignar

44


OPERADOR PESO

EQUAL 0

DELETED 1

MODIFIED 2

ADDED 3

Tabla 4.2: Caso II: tabla de pesos de la métrica Size weighted meta.

Figura 4.13: Métrica Size weighted meta.

un peso al par de elementos relacionados en la fase de agrupamiento del procesode comparación de modelos. Los elementos de la métrica adjuntan la siguiente in-formación: elemento del modelos As-Is, operador de comparación y el elemento delmodelo To-Be. La Figura 4.14 muestra el cálculo de la métrica.

A diferencia de la métrica descrita en la Subsección 4.4.2 ahora se puede asignar unpeso con un valor decimal a cada elemento de la métrica, lo que favorece el análisisporque existe la posibilidad de asignar diferentes pesos a un mismo operador. Porejemplo, se puede asignar un peso de 2 a la modificación de la relación R1 entreclase A y la clase B y un peso de 2.5 a la modificación de la relación R2 entre laclase B y la clase C. De los pesos asignados a las relaciones R1 y R2 se concluye quela relación R2 tiene mayor complejidad que la relación R1.

La Tabla 4.3 muestra los pesos asignado a cada elemento de la métrica Size weightedrelated donde se especifica el nivel de dificultad de cada operador. Se clasificó a lacomplejidad en alta y baja para diferencia el nivel de dificultad que implica realizarlas modificaciones. Se puede asignar un peso a cada operador dentro del rango de 0a 3.9, donde el menor peso tiene el 0 y el mayor peso tiene el 3.9.

El resultado de aplicar la métrica Size weighted related sobre el modelo As-Is y elmodelo To-Be es: Size weighted related (d(modelo, modelo)) = 41.5.

45


Figura 4.14: Métrica Size weighted related.

4.4.4. Caso IV: métrica Size weighted related meta

Se explica la métrica Size weighted related meta en la Subsección 3.2.3 y en [4]. Lamétrica Size weighted related meta es el tamaño del modelo As-Is relacionado almodelo To-Be, donde los pesos de los elementos del modelo As-Is son derivados delos pesos asignados a los elementos del metamodelo Ecore del cual el modelo To-Bees instancia. Esta métrica tiene la característica que puede asignar un peso a loselemento del metamodelo del cual los modelos son instancias. Por lo tanto, permiterealizar el análisis de la comparación de modelos a partir del peso que se asigne alos elementos del metamodelo Ecore y especificar la complejidad del cambio a partirde un metamodelo.

La Tabla 4.4 muestra los pesos asignado a cada elemento de la métrica Size weightedrelated meta donde se especifica los elementos que se utilizan en los modelos que

46


OPERADOR DIFICULTAD PESO

EQUAL – 0

DELETED BAJA 1

DELETED ALTA 1.5

MODIFIED BAJA 2

MODIFIED ALTA 2.5

ADDED BAJA 3

ADDED ALTA 3.5

Tabla 4.3: Caso III: tabla de pesos de la métrica Size weighted related.

Figura 4.15: Métrica Size weighted related meta.

corresponden al metamodelo Ecore. Se debe asignar un peso a cada elemento enun rango de 0 a 3, donde el menor peso tiene el número 0 y el mayor peso tiene elnúmero 3.

ELEMENTO PESO

EPackage 0EClass 1

EAttribute 2EReference 3

Tabla 4.4: Caso IV: tabla de pesos de la métrica Size weighted related meta.

El resultado de aplicar la métrica Size weighted related meta sobre el modelo As-Isy el modelo To-Be es: Size weighted related meta (d(modelo, modelo)) = 75.


El desarrollo de la herramienta para el análisis de la comparación de modelos ha cola-borado para cumplir con el objetivo principal del reto de investigación: proporcionarun soporte a la comparación de modelos conceptuales en escenarios de evolución .

47


El ejemplo ilustrativo ayuda a validar el diseño de la solución que se explicó en elCapítulo 3. Finalmente, con la ayuda del ejemplo ilustrativo se valida el funciona-miento de cada métrica sobre el resultado de la comparativa entre modelos, y seobtiene un valor cuantitativo para realizar el estudio del análisis de la comparaciónde modelos.

48

5 Conclusiones

Una vez finalizadas las actividades relacionadas con esta tesis de Maestría, se anali-zan los resultados del presente trabajo. Se presentan las principales conclusiones queson el punto culminante después del desarrollo de las tareas del ciclo de ingenieríaEC1 propuesto en la Sección 1.3 y que son las directrices para cumplir con el retode la investigación.

Este capítulo presenta las contribuciones relacionadas con los objetivos y pregun-tas de investigación presentados en el Capítulo 1. Además, se nombra un artículode investigación relacionado con esta tesis, que confirman el nivel de aceptación yrelevancia de este proyecto. Por último, se concluye con el trabajo futuro.

5.1. Contribuciones

En base a los trabajos de M. Ruiz [1][2] y S. España[27] se ofrece un soporte a laevolución de sistemas de información a través de una herramienta que realiza elanálisis de la comparativa entre modelos. A partir del resultado de la comparaciónde dos modelos se deriva un modelo delta que es una instancia de un metamodelode evolución [2]. Un modelo delta posee la información de la comparación de losmodelos y con la ayuda de operadores especifica el tipo de cambio que existe entrelos elementos de cada modelo. Cada elemento de un modelo delta, tiene informaciónsobre la trazabilidad de la evolución que sufre un sistema. Para medir un modelodelta se emplea un conjunto de métricas [4] para obtener un valor numérico, quese utiliza para cuantificar los cambios sobre el modelo resultante en el proceso deevolución. Cada métrica tiene la capacidad de asignar un peso o valor numérico acada uno de sus elementos, para realizar el análisis de los cambios entre los modelos.

Las principales contribuciones de esta tesis de Maestría se presentan a continuación:

Soporte al análisis de la evolución de modelos conceptuales bajo elparadigma de DSDM. Se instancia un metamodelo de evolución propues-to en [2] que brinda soporte a la reingeniería de sistemas de información. Sederiva un modelo delta con el resultado de la comparación entre el modelo deun sistema actual (modelo As-Is) y el modelo de un sistema deseado (modeloTo-Be) para satisfacer nuevos requisitos. Se brinda apoyo al proceso de evo-lución de una reingeniería guiada por el paradigma de Desarrollo de SoftwareDirigido por Modelos (DSDM). El proceso de evolución gestiona los sistemas

49

Capítulo 5 Conclusiones

de información en un nivel más alto de abstracción a través de modelos. Porlo tanto, realizar un análisis a la comparación de los modelos que se gene-ran en el proceso de evolución ofrece información valiosa sobre el impacto queocasionarán los cambios en un nuevo sistema de información.Una herramienta que soporta el paradigma de DSDM. El Desarrollode Software Dirigido por Modelos (DSDM ) tiene como principal artefacto alos modelos. Por lo tanto, el desarrollo de una herramienta que brinde apoyoal análisis de la comparación de modelos proporciona directamente el soporteal paradigma del DSDM. La herramienta ofrece la posibilidad de realizar lacomparativa y posterior análisis de diagramas Ecore.Aplicación de un conjunto de métricas al resultado de la compariciónde modelos. Se utilizó cuatro métricas propuestas en [4] para obtener unvalor cuantitativo del resultado de la comparación de dos modelos Ecore. Elresultado de aplicar las métricas, se utiliza para cuantificar los cambios que seproducen en los modelos del proceso de evolución en una reingeniería. Cadamétrica tiene la posibilidad de asignar un conjunto de valores numéricos alos elementos del modelo resultante de la comparación, de esta manera seespecifica el peso o importancia que tienen las modificaciones realizadas sobrelos modelos. La aplicación de las métricas sirve para realizar un análisis delimpacto que tendrán los cambios sobre el nuevo sistema.Integración con el proyecto Eclipse. El desarrollo de la herramienta si-gue la arquitectura de plugins del Eclipse Modeling Tools. Por lo tanto, laherramienta tiene la posibilidad de interactuar con todos los componentes queforman parte del proyecto Eclipse. Un claro ejemplo es la utilización e inte-gración del plugin EMF Compare con la herramienta que brinda soporte alanálisis de la comparación de modelos.

5.2. Publicaciones

Publicaciones relacionadas a esta tesis

Sandobalín, J., Ruiz, M., Espana, S., y Pastor, O., “Soportando el análisis dela comparación de modelos en un entorno DSDM,” en CibSE, XVII CongresoIberoamericano en Ingeniería de Software, En revisión, (Pucón, Chile). Abril2014.

5.3. Trabajo futuro

Actualmente el resultado del análisis de la comparación de modelos ofrecevalores cuantitativos como punto de partida para realizar la interpretación

50

5.3 Trabajo futuro

de los cambios realizados. Con el fin de ofrecer una solución mas completaal análisis de la comparativa de modelos, se propone como trabajo futuro laimplementación del módulo de análisis de impacto de las métricas propuestoen [4].Finalmente, se desea integrar la herramienta con los componentes de GraphicalModeling Framework (GMF) para ofrecer la posibilidad de realizar el análisisde modelos que sean instancias del metamodelo Ecore de Eclipse ModelingFramework (EMF).

51

Bibliografía

[1] M. Ruiz, S. Espana, and A. Gonzalez, “Model-driven organisational reengi-neering a framework to support organisational improvement,” in Informatica(CLEI), 2012 XXXVIII Conferencia Latinoamericana En, pp. 1–9, 2012.

[2] M. Ruiz, S. Espana, O. Pastor, and A. Gonzalez, “Supporting organisationalevolution by means of model-driven reengineering frameworks,” in 2013 IEEESeventh International Conference on Research Challenges in Information Scien-ce (RCIS), pp. 1–10, 2013.

[3] R. Kazman, S. G. Woods, and S. J. Carrière, “Requirements for integratingsoftware architecture and reengineering models: CORUM II,” in Reverse Engi-neering, 1998. Proceedings. Fifth Working Conference on, p. 154–163, 1998.

[4] Ruiz, M., España, S., Salinesi, C., Mazo, R., and Pastor, O., “Realising theanalysis of change scenarios: a delta analysis technique,” in 26th Internatio-nal Conference on Advanced Information Systems Engineering (CAiSE 2014),(Thessaloniki, Greece), 2014.

[5] R. Wieringa, “Design science as nested problem solving,” in Proceedings ofthe 4th International Conference on Design Science Research in InformationSystems and Technology, DESRIST ’09, (New York, NY, USA), p. 8:1–8:12,ACM, 2009.

[6] R. J. Wieringa and J. M. G. Heerkens, “The methodological soundness of re-quirements engineering papers: a conceptual framework and two case studies,”Requirements engineering, vol. 11, no. 4, p. 295–307, 2006.

[7] A. Toulmé and I. Inc, “Presentation of EMF compare utility,” in Eclipse Mo-deling Symposium, p. 1–8, 2006.

[8] D. Steinberg, F. Budinsky, E. Merks, and M. Paternostro, EMF: Eclipse Mo-deling Framework. Pearson Education, Dec. 2008.

[9] D. Kolovos, D. Di Ruscio, A. Pierantonio, and R. Paige, “Different models formodel matching: An analysis of approaches to support model differencing,”in ICSE Workshop on Comparison and Versioning of Software Models, 2009.CVSM ’09, pp. 1–6, May 2009.

[10] S. Förtsch and B. Westfechtel, “Differencing and merging of software diagrams,”State of the Art and Challenges, 2007.

53

Bibliografía

[11] C. Brun and A. Pierantonio, “Model differences in the eclipse modeling fra-mework,” UPGRADE, The European Journal for the Informatics Professional,vol. 9, no. 2, p. 29–34, 2008.

[12] N. Nakatsu, Y. Kambayashi, and S. Yajima, “A longest common subsequencealgorithm suitable for similar text strings,” Acta Informatica, vol. 18, no. 2,p. 171–179, 1982.

[13] E. Ukkonen, “Algorithms for approximate string matching,” Information andControl, vol. 64, pp. 100–118, Jan. 1985.

[14] P. Konemann, “Model-independent differences,” in Proceedings of the 2009 IC-SE Workshop on Comparison and Versioning of Software Models, CVSM ’09,(Washington, DC, USA), p. 37–42, IEEE Computer Society, 2009.

[15] P. Könemann and P. Könemann, “Model-independent diffs,” tech. rep., DTUInformatics, Building 321, 2008.

[16] Z. Xing, “Model comparison with GenericDiff,” in Proceedings of theIEEE/ACM International Conference on Automated Software Engineering,ASE ’10, (New York, NY, USA), p. 135–138, ACM, 2010.

[17] C. Bron and J. Kerbosch, “Algorithm 457: Finding all cliques of an undirectedgraph,” Commun. ACM, vol. 16, p. 575–577, Sept. 1973.

[18] D. S. Kolovos, R. F. Paige, and F. A. Polack, “Model comparison: A foundationfor model composition and model transformation testing,” in Proceedings of the2006 International Workshop on Global Integrated Model Management, GaMMa’06, (New York, NY, USA), p. 13–20, ACM, 2006.

[19] Y. Lin, J. Zhang, and J. Gray, “Model comparison: A key challenge for transfor-mation testing and version control in model driven software development,” inOOPSLA Workshop on Best Practices for Model-Driven Software Development,vol. 108, p. 6, 2004.

[20] K. Altmanninger, P. Brosch, G. Kappel, P. Langer, M. Seidl, K. Wieland, andM. Wimmer, “Why model versioning research is needed!? an experience report,”in Proceedings of the MoDSE-MCCM 2009 Workshop@ MoDELS, vol. 9, 2009.

[21] A. Schipper, H. Fuhrmann, and R. von Hanxleden, “Visual comparison of grap-hical models,” in 2009 14th IEEE International Conference on Engineering ofComplex Computer Systems, pp. 335–340, 2009.

[22] J. Izquierdo and J. Molina, “An architecture-driven modernization tool for cal-culating metrics,” IEEE Software, vol. 27, pp. 37–43, July 2010.

[23] M. A. Rothenberger and J. C. Hershauer, “A software reuse measure: Moni-toring an enterprise-level model driven development process,” Information &Management, vol. 35, pp. 283–293, May 1999.

[24] Ruiz, M., “A model-driven method to support conceptual model evolution,” in19th International Working Conference on Requirements Engineering: Founda-tion for Software Quality (REFSQ 2013), (Essen, Germany), 2013.

54

Bibliografía

[25] Sandobalin, J., Ruiz, M., España, S., and Pastor, O., “Soportando el análisis dela comparación de modelos en un entorno DSDM.,” in CibSE, XVII CongresoIberoamericano en Ingeniería de Software, En revisión., (Pucón, Chile.), 2014.

[26] E. Clayberg and D. Rubel, Eclipse Plug-ins. Pearson Education, Dec. 2008.[27] S. Espana, M. Ruiz, and A. Gonzalez, “Systematic derivation of conceptual

models from requirements models: A controlled experiment,” in 2012 Sixth In-ternational Conference on Research Challenges in Information Science (RCIS),pp. 1–12, 2012.

55

tesis de máster en ingeniería de software, métodos...

Documents