Extracción y Reconstrucción de Modelos Empresariales
Trabajo de tesis presentado al
Departamento de Ingeniería de Sistemas y Computación
Por
Julio César Reyes Cadena
Asesor
Jorge Alberto Villalobos Salcedo, PhD.
Para optar por el título de
Magíster en Ingeniería.
Área: Sistemas y Computación
Universidad de Los Andes
2013
Abstract
In order to be valuable, enterprise models should have five characteristics: they have to be
accurate representations of the reality; they have to be structured so that they can be
automatically processed; they have to be complete with respect to their intended usage;
they have to be kept up-to-date; and the cost of their construction and maintenance has to
be as low as possible. In this paper we present an approach for the construction of
enterprise models that posses those characteristics.
Our approach automatically gathers information from multiple sources, and then weaves
the information together to form a single model. This approach is based on modeling and
metamodeling techniques, and has been implemented in a tool called EM-AutoBuilder.
Índice general
1. Introducción 6
2. Motivación y estrategia de solución 8
2.1. Planteamiento del problema . . . 8
2.2. Trabajos de investigación previos . . . 9
2.2.1. Reconstrucción basada en análisis de infraestructura . . . 10
2.2.2. Reconstrucción basada en análisis de código e introspección de aplicaciones 13 2.3. Estrategia de la solución propuesta . . . 16
2.4. Objetivos . . . 17
3. Implementación de la solución 18 3.1. Diseño de EM-AutoBuilder . . . 18
3.2. Caso de estudio: Empresa BPO Los Alpes . . . 21
3.2.1. Contexto de la empresa . . . 21
3.2.2. Arquitectura de aplicaciones de la BPO Los Alpes . . . 22
3.3. Tecnologías . . . 23
4. Descubrimiento y reconstrucción de modelos 24 4.1. Funcionamiento de un conector/extractor . . . 24
4.2. Extracción de modelos de Información y Usuarios: Bases de datos y Sistemas de Autenticación . . . 26
4.3. Extracción de modelos de Presentación (JSP) y Lógica de Negocio (EJB) . . . . 29
4.4. Extraccion de modelos de Descriptores de Servicios (WSDL) y procesos (BPEL) 30 5. Composición de modelos 31 5.1. Tejido de metamodelos . . . 31
5.2. Tejido de modelos . . . 32
6. Conclusiones 35
ÍNDICE GENERAL 2
Bibliografía 35
A. Tecnologías 38
A.1. JFace . . . 38 A.2. EMF (Eclipse Modeling Framework) . . . 38 A.2.1. Ecore . . . 38
Índice de guras
2.1. Mapping de un sistema según Buschle et al. . . 10
2.2. Esquema de una topología empresarial . . . 11
2.3. Modelo de representación propuesto por Binz et al . . . 12
2.4. Grafo de transición de datos. Song et al. . . 13
2.5. Metamodelo de una aplicación JEE propuesto por Song et al. . . 14
2.6. Fases de operación del proyecto MoDisco . . . 14
2.7. Ejemplo de una llamada al sistema. Proyecto DiscoTect . . . 15
2.8. Grafo de eventos, entradas y salidas del sistema. . . 15
2.9. Estructura general EM-AutoBuilder . . . 17
3.1. Componentes de EM-AutoBuilder . . . 18
3.2. Interface del componente ModelGen para la creación de modelos . . . 19
3.3. Creación de un proyecto en EM-AutoBuilder . . . 20
3.4. Conguración de un extractor a traves de EM-AutoBuilder . . . 20
3.5. Salidas obtenidas de EM-AutoBuilder . . . 21
3.6. Sistemas de la BPO Los Alpes . . . 23
4.1. Contenido de un extractor . . . 24
4.2. Modelo de base de datos CCA y Donaciones . . . 25
4.3. MMbd: Metamodelo genérico de base de datos . . . 26
4.4. Mbd: Modelo de base de datos conforme al Metamodelo genérico . . . 27
4.5. MMcca: Metamodelo especíco de la base de datos CCA . . . 27
4.6. Metamodelo del sistema LDAP . . . 28
4.7. Modelo del sistema LDAP . . . 28
4.8. Metamodelo JSP . . . 29
4.9. Modelo JSP del sistema CCA del caso de estudio . . . 29
4.10. Metamodelo Servicio de Vinculación/Desvinculación de empleados . . . 30
ÍNDICE DE FIGURAS 4
4.11. Proceso de pago en efectivo Sistema de Donaciones . . . 30
5.1. Lenguaje Fusion [9] . . . 31
5.2. Script xFusion para relacionar un usuario en dos sistemas diferentes . . . 33
5.3. NewLink entre LDAP y CCA . . . 33
5.4. Modelo del sistema unicado . . . 34
A.1. Especicación de Ecore. . . 39
Índice de tablas
3.1. Archivo de conguración de un extractor de base de datos . . . 21
3.2. Procesos para la Gestión de Campañas de donación . . . 22
4.1. Extracción WSDL y BPEL . . . 30
5.1. Instrucciones del lenguaje Fusion [9] . . . 32
Capítulo 1
Introducción
El Modelamiento Empresarial (EM por sus siglas en inglés) entendido como la construcción y análisis de modelos que representan uno o varios aspectos de una empresa1 es una disciplina
en crecimiento, considerada como una manera eciente para entender mejor las organizaciones y planear cambios signcativos [11]. El valor que puede ganarse al hacer EM es directamente proporcional a la calidad de los modelos y la calidad de las herramientas disponibles para realizar los análisis. Si los modelos son muy pequeños, con bajo nivel de detalle o no estructurados, es difícil ejecutar análisis signicativos.
El principal problema que afecta la calidad de los modelos es el costo de construción y man-tenimiento. Dado que la construcción de modelos es tradicionalmente una tarea humana, se compromete la calidad al tener que limitarse la amplitud o profundidad de los modelos elabo-rados. Adicionalmente algunos modelos se crean usando tecnologías que dicultan su procesa-miento automatizado, por ejemplo, en procesadores de texto, hojas de cálculo o diagramas no estructurados.
El proceso de modelamiento conlleva a tener modelos grandes con diferente sintaxis que describen sistemas heterogéneos haciendo que la información relevante para un usuario especíco en un momento determinado esté a menudo dispersa a través de varios modelos. Por lo tanto se necesita componer o enlazar estos modelos o parte de ellos para proveer información unicada y usable de los sistemas modelados.
La hipótesis que intentamos validar con este trabajo es que parte de la información que está incluída en un modelo empresarial puede ser obtenida de manera estructurada y automatizada. Por ejemplo, debería ser posible recolectar información a partir de los sistemas de información desplegados para crear modelos empresariales construídos en tiempo y costo menores que los que conllevaria su elaboración manual y que además puedan ser actualizados automáticamente. Adicionalmente la automatización de la construcción y la actualización de estos modelos de-beria reducir la posibilidad de errores e inconsistencias y por ende, la producción de modelos empresariales más precisos que permitan extraer mayor valor para su análisis.
Para validar esta hipótesis, diseñamos un enfoque y una arquitectura para constuir modelos empresariales utilizando información de diferentes fuentes. Este enfoque se implementó en una herramienta llamada EM-Autobuilder, probada sobre el escenario de la empresa BPO Los Alpes. Este documento está estructurado de la siguiente manera: en el capítulo 2 se aborda con detalle el problema, los enfoques y estrategias que se han formulado y un planteamiento general de
1Actividades y recursos que son requeridos para desarrollar y proveer productos y/o servicios a un cliente
la solución propuesta. En el capítulo 3 se describen los detalles de la solución y se presenta el escenario del caso de estudio.
El enfoque propuesto y su implementación están descritos en los capítulos 4 y 5 junto con los resultados de su aplicación al caso de estudio. Finalmente el capítulo 6 concluye el trabajo realizado.
Capítulo 2
Motivación y estrategia de solución
2.1. Planteamiento del problema
Los modelos empresariales juegan un rol importante en la capacidad de transformación de las organizaciones, su uso permite a las empresas crear mejores diseños de su estructura, hacer análisis del desempeño organizacional y mejorar la administración de sus operaciones [8]. Aunque no hay una denición estándar de lo que es un Modelo Empresarial, se puede reco-nocer como una representación de los elementos de una organización que pertenecen a uno o varios dominios (procesos de negocio, regulaciones, estructura y tecnologías de información) [11]. También podría decirse que un modelo empresarial es una representación computacional de la estructura, actividades, procesos, información, recursos, personas, comportamiento, objetivos y restricciones de un negocio, entidad u otra empresa con el propósito de que el análisis, diseño y operación empresarial se puedan operar bajo el enfoque basado en modelos (model-driven) [8]. La construcción de estos modelos no es una tarea trivial [10] y conlleva costos y tiempo; el costo depende de dos factores: el nivel de detalle requerido y el alcance del modelo, es decir, cuantos y cuales dominios de la empresa deben ser representados. Adicionalmente, los benecios de construir modelos no son intrínsecos al modelo sino que dependen del propósito con el que se construye, por ejemplo, para documentación o comunicación, incrementar la comprensión de una empresa, como punto inicial para el análisis de la situación actual (as-is) de una organización, o para evaluar proyectos de transformación.
Aunque no existe un conjunto de propiedades completamente denido que un modelo deba satisfacer, existen diferentes respuestas a la pregunta de cuáles son las cualidades que debe tener un modelo para cumplir una tarea determinada [8]. Consideramos que un modelo deberia tener las siguientes propiedades para que resulte adecuado para describir una organización:
Preciso: debe reejar la realidad que intenta modelar, de otro modo no puede ser usado para responder de manera conable sobre asuntos de la organización. La toma de decisiones basada en información incorrecta puede ser más perjudicial que tomar ninguna decisión. Además el modelo construído debe permitir el análisis a varios niveles de abstracción y detalle.
Actualizado: un modelo debe tener la información que describa el estado más reciente del sistema, de otro modo pierde precisión progresivamente.
Estructurado: debe estar construído sobre estructuras denidas y expresado en representa-ciones que favorezcan el procesamiento automático. Los modelos creados en documentos, diagramas y hojas de cálculo dicultan su uso para el análisis empresarial.
Funcionalmente completo: un modelo debe contener los conceptos requeridos para el pro-pósito que fue construído o para la tarea en la que se va a emplear, no deberia carecer de información que se espera que contenga.
Factible en costo: el costo de construir y mantener un modelo empresarial debe ser tan bajo como sea posible, de otro modo, los modelos progresivamente quedan desactualizados.
Debido a que los modelos intentan proveer información conable y deben capturar los aspectos de relevancia para la organización, frecuentemente crecen en un alto número de entidades y relaciones entre ellas. La creación de estos modelos consume tiempo y en varios casos se requiere el involucramiento de los responsables de las diferentes piezas de información que deben ser recolectadas. Incluso, durante el proceso de creación de modelos ya existe la posibilidad de que queden parcialmente desactualizados [1].
Una respuesta a la situación descrita consiste en la automatización de la construcción de los modelos partiendo de algún tipo de información obtenible de los sistemas observados. A conti-nuación se presentan algunos enfoques.
2.2. Trabajos de investigación previos
Varias propuestas de investigación han abordado el problema de la reconstrucción de modelos a diferentes niveles de detalle y enfocándose en dominios particulares. Un enfoque ha sido el análisis de activos de infraestructura de tecnología en las redes corporativas para identicar aplicaciones desplegadas. Entre ellos se encuentran el trabajo de Buschle et al. [5] el cual propone reconstruir modelos de arquitectura empresarial basados en escaneo de redes y representación de los principales componentes de la infraestructura de aplicaciones mediante una estructura en forma de grafo. Este enfoque utiliza información capturada con herramientas de análisis de red y de exploración de vulnerabilidades. De manera similar, el trabajo de Binz et al. [3] combina un enfoque semi-automatizado con asistencia manual para la reconstrucción de modelos. La parte automatizable consiste en el descubrimiento de las familias de aplicaciones activas en la red, ej. bases de datos, servidores de aplicaciones. De manera asistida se realiza manualmente la caracterización de estos conceptos para darles un signicado en el modelo de acuerdo a su rol en el sistema; el resultado es un grafo que representa la topología del sistema.
Otros trabajos han abordado el problema desde la extracción de modelos a partir del análisis de código fuente. El uso exitoso de estos enfoques depende en gran medida de que el código fuente cumpla varias convenciones de escritura. Entre estos trabajos se encuentran MoDisco [4], el trabajo de Schmerl et al. [12] y el trabajo de Song et al. [13]. MoDisco es un framework ex-tensible creado para dar soporte a la modernización de software; permite analizar código fuente, estructuras de base de datos y archivos de conguración para crear modelos que representan uno o varios sistemas. Por otra parte, el proyecto DiscoTect [12] combina el análisis de código fuente con el análisis de eventos de bajo nivel del sistema para obtener una representacion que relaciona eventos que suceden en casos de uso especícos en instancias de ejecución especícas. Finalmente, el trabajo de Song [13] analiza las API de administración de una aplicacion para construir con esta información metamodelos de un sistema. A continuación se describen con más detalle estas propuestas:
CAPÍTULO 2. MOTIVACIÓN Y ESTRATEGIA DE SOLUCIÓN 10
2.2.1. Reconstrucción basada en análisis de infraestructura
A Tool for automatic enterprise architecture modeling [5]
Este trabajo plantea un enfoque para construir automatizadamente modelos actualizados y precisos de un sistema, teniendo en cuenta que el número de sus elementos y relaciones crecen para poder soportar cambios en las organizaciones. La estrategia de solución que proponen los autores consiste en escanear la red corporativa con NeXpose1, un scanner de vulnerabilidades
que provee información sobre los dispositivos conectados, rewalls, y otros activos de red. El sistema identica el sistema operativo o rmware que corren los dispositivos y los servicios en ejecución.
Los resultados del análisis se obtienen en archivos XSD cuyos conceptos se mapean a un metamo-delo construido para lenguajes de modelado de seguridad. Como resultado se obtienen mometamo-delos como el de la Figura 2.1.
Figura 2.1: Mapping de un sistema según Buschle et al. Tomado de [5]
Improving the Manageability of Enterprise Topologies Through Segmentation, Graph Transformation, and Analysis Strategies [3]
En este trabajo se presenta un enfoque para representar y analizar modelos empresariales com-plejos. Para ello se propone la construcción de un grafo de topología empresarial que representa los servicios, aplicaciones e infraestructura tecnológica de una empresa. El descubrimiento de los activos de TI se realiza a través de modelamiento manual y análisis de red. Adicionalmente se dene un conjunto de operaciones para segmentar el modelo obtenido y disminuir su comple-jidad y un conjunto de transformaciones para operar sobre estos elementos y permitir el análisis de la arquitectura modelada.
En la Figura 2.2 se ilustra el panorama general de una topología empresarial. Las áreas en las que se enfoca el trabajo descrito están resaltadas en un color más intenso. El propósito es formalizar usando el modelo de la Figura 2.3 la información extraída de los sistemas de información empresariales para permitir realizar operaciones de manera automatizada sobre un conjunto grande de elementos y permitir su análisis posterior.
Figura 2.2: Esquema de una topología empresarial Tomado de [3]
CAPÍTULO 2. MOTIVACIÓN Y ESTRATEGIA DE SOLUCIÓN 12
Figura 2.3: Modelo de representación propuesto por Binz et al Tomado de [3]
Para realizar la construcción del grafo de topología empresarial los autores se apoyaron en enfo-ques existentes como el análisis de red para el descubrimiento de activos de TI, en combinación con modelamiento manual. Cada sistema descubierto se modela como un nodo del grafo y las relaciones como los arcos entre nodos, algunas relaciones no son detectables y se completan manualmente en el modelo.
Para realizar análisis de arquitectura sobre el modelo obtenido, se dene la operacion de seg-mentación que permite obtener subconjuntos de elementos de interés de tamaño menor que el modelo original. Además se denen 6 operaciones de transformación:
Abstracción, que permite generalizar tipos concretos para representaciones más generales. Agrupación de propiedades (min, max, avg, count, concatenate, sum).
Creación y eliminación de entidades
Agrupación de entidades en segmentos, que permite crear nuevas entidades que representan a un conjunto de entidades con propiedades comunes.
Filtrado, para visualizar entidades con propiedades de interés particular. Desacoplamiento, que permite separar entidades de un segmento.
Este enfoque permite tener una representación automáticamente procesable de las aplicaciones que conforman los sistemas de información en las organizaciones y está especialmente diseñada para realizar análisis de dependencia entre componentes a nivel de infraestructura, preveer el impacto de migraciónes, y dar una visión de las plataformas tecnológicas que componen el sistema.
2.2.2. Reconstrucción basada en análisis de código e introspección de
aplicaciones
Inferring meta-models for runtime system data from the clients of management APIs [13]
Este trabajo propone un enfoque para monitoreo de sistemas de información y describir su es-tado, estructura y ambiente de ejecución, extrayendo datos como uso de memoria e instancias de componentes en ejecución, representando estos conceptos en forma de modelos estructurados para ser procesados de manera automática. Dado que cada sistema provee diferentes datos en tiempo de ejecución, es necesario construir primero un metamodelo que dene los tipos de datos del sistema, en la mayoría de enfoques estos metamodelos se construyen manualmente, sin em-bargo, este enfoque propone la extracción de información a partir de las APIs de administración de las aplicaciones JEE vía JMX.
La información extraída contiene un conjunto de probables tipos de datos y atributos que se representan en forma de grafo (ver Figura 2.4) y sobre el cual se aplican reglas de inferencia para descubrir relaciones y entidades; adicionalmente se simplica el metamodelo removiendo conceptos duplicados y no signicativos de acuerdo a las siguientes reglas:
1. Fusionar referencias equivalentes, es decir asociaciones con el mismo nombre que pertene-cen a un objeto origen o destino.
2. Eliminar shortcuts: una clase c1 accede a c2 y a través de ella a c3, además c1 también accede a c3 directamente, en este caso se elimina la referencia (c1,c3) ya que un camino implica el otro.
3. Debilitar clases que acceden a otras a través de atributos: si una clase c1 tiene una referencia a c2, y esta relación no tiene ningún estado o apunta a otra clase, se descarta y se agrega como atributo de c1.
4. Eliminar clases débiles: son clases que no tienen ninguna asociación directa, ni manera de ser accedidas por la clase raíz del modelo.
Los metamodelos inferidos (Figura 2.5) dependen de los clientes sobre de los cuales se realice la extracción; estos metamodelos están formulados para modelar sistemas que describen conceptos de la ejecución de una aplicación, pero no información especíca de cada sistema.
Figura 2.4: Grafo de transición de datos. Song et al. Tomado de [13]
CAPÍTULO 2. MOTIVACIÓN Y ESTRATEGIA DE SOLUCIÓN 14
Figura 2.5: Metamodelo de una aplicación JEE propuesto por Song et al. Tomado de [13]
MoDisco: A Generic And Extensible Framework For Model Driven Reverse Engi-neering [4]
El proyecto MoDisco propone una solución al problema de reconstruir sistemas legado para procesos de migración o modernización, haciendo la reingeniería de estos sistemas con el menor costo posible. Para lograrlo, propone la reconstrucción de las funcionalidades y la arquitectura de un sistema en una representación que pueda ser manipulada automáticamente, y en un formato que provea soporte genérico para ser procesado en diferentes tecnologías.
MoDisco busca transformar la heterogeneidad del mundo de las diferentes implementaciones heterogéneas en un mundo homogénego de modelos. La idea general es poder extraer información de varios sistemas y construir modelos dependiendo de los puntos de vista de interés para después operar directamente sobre estos modelos.
La operacion de MoDisco tiene dos fases: descubrimiento de información y generación de modelos (Figura 2.6). Para el descubrimiento de información provee metamodelos que guían la actividad de los componentes de software que luego reconstruyen los modelos de los sistemas especícos. MoDisco ofrece soporte para hacer ingenieria inversa de proyectos JEE, incluyendo un meta-modelo de Java y metameta-modelo para la extracción de información de archivos de conguración XML.
Figura 2.6: Fases de operación del proyecto MoDisco Tomado de [4]
Dynamically discovering architectures with DiscoTect [12]
Este proyecto propone el descubrimiento dinámico de arquitecturas a traves del monitoreo del comportamiento de aplicaciones en tiempo de ejecución, transformación de estos comportamien-tos en evencomportamien-tos signicativos desde el punto de vista de infraestructura y representación de escomportamien-tos conceptos en un grafo.
DiscoTect captura eventos del sistema como llamados a métodos, utilización de CPU, consumo de red, uso de memoria mediante el uso de harramientas de monitorieo o inyección de código en el sistema objetivo. Partiendo de un conjunto de reglas y restricciones, se construye un grafo (Figura 2.7) que representan los inputs y outputs del sistema y las posibles transiciones entre ellos.
<call method_name=java.net.ServerSocket.accept callee_id=19efb05 return_id=1d1acd3 />
Figura 2.7: Ejemplo de una llamada al sistema. Proyecto DiscoTect Tomado de [12]
Figura 2.8: Grafo de eventos, entradas y salidas del sistema. Tomado de [12]
Este enfoque aprovecha las regularidades en la implementación del software y el conocimiento a-priori del estilo arquitectural de la aplicación implementada. Por esta misma razón las im-plementaciones analizadas deben seguir ciertas convenciones de codicación y además se debe conocer el estilo arquitectural para que DiscoTect pueda generar mapear los conceptos de en-trada al vocabulario del modelo de salida. Adicionalmente los análisis deben hacerce mediante iteraciones y pruebas, pues el mapeo de eventos solo puede hacerse monitoreando el comporta-miento capturado en una instancia de ejecución en un escenario de ejecución especíco.
A Tool Analysis In Architectural Reconstruction [10]
Propone y analiza diferentes soluciones comerciales y de codigo abierto para la creación de modelos UML a partir de la instrospección de codigo fuente de los sistemas de información empresariales. El propósito de este trabajo es lograr hacer ingeniería inversa de una aplicación
CAPÍTULO 2. MOTIVACIÓN Y ESTRATEGIA DE SOLUCIÓN 16
de software y crear diagramas de ujo a partir del código. Esto se representa en diagramas donde aparecen componentes de tipo Package, Objects, Classes y Nodes.
Las vistas que se reconstruyen en este trabajo son las vistas Componente y Conector (C&C), las cuales proveen una visión de alto nivel del sistema en términos de sus principales componentes. (Clientes, Servidores, Almacenes de datos).
Este trabajo concluye que en general, es dicil obtener información a partir de aplicaciones existentes y así mismo encontrar una herramienta que permita modelar los componentes del sistema desplegado.
2.3. Estrategia de la solución propuesta
Para la creación de modelos empresariales que reejen el estado de la organización proponemos un enfoque automatizado para la recolección de datos y la creación de los modelos con el n de lograr menores tiempos y costos de modelamiento y un incremento en la calidad de los modelos obtenidos. En este trabajo nuestro interés está en la extracción de información de los sistemas de información directamente, con el n de construir modelos precisos, actualizados, estructurados y funcionalmente completos.
El enfoque que presentamos se diferencia de los mencionados anteriormente en varios aspectos: nos enfocamos en diferentes dominios para crear un modelo multidimensional de la empresa; nuestro enfoque permite la extracción de información de múltiples fuentes y tipos. Abarcamos determinadas aplicaciones desplegadas, introspección a bases de datos, sistemas de autenticación, descriptores de servicios, lógica del negocio, componentes de capa de presentación y procesos de negocio. Construimos un componente reutilizable para la creación de modelos estructurados y procesables automatizadamente. Adicionalmente construímos una plataforma para la compo-sición de modelos heterogéneos obtenidos de diversas fuentes de información para construir un modelo que describa la empresa de manera unicada.
La solución propuesta está diseñada teniendo en cuenta cuatro requirimientos críticos:
1. Los modelos se deben crear de modo tan automático como sea posible, por ello se eligieron fuentes de información que pueden ser automáticamente procesadas.
2. La construcción de modelos debe soportar heterogeneidad en los sistemas que representa. Es decir, debe ser posible extraer información de diversas fuentes que tengan diferentes estructuras, diferentes propósitos y que esten construídas en diferentes tecnologias. 3. El enfoque debe ser extensible para permitir la adaptación de nuevas fuentes de
informa-ción.
4. Las salida obtenida del proceso deben ser un artefacto integrado que pueda ser procesado o cargado en otras herramientas.
Dados estos requerimientos, diseñamos el enfoque ilustrado en la Figura 2.9 , el cual está imple-mentado en la herramienta EM-AutoBuilder.
EM-AutoBuilder consta de un componente central que es capaz de conectarse a varios ex-tractores congurables y procesar las salidas que producen. Los Exex-tractores son componentes independientes, cada uno es capaz de conectarse a alguna clase de fuente especíca para extraer información. Esta información es entregada al componente central en forma de modelos. Después de que cada extractor entrega uno o varios modelos, la aplicación central debe proce-sarlos para obtener un modelo integrado. Sin embargo, como se trata de sistemas heterogéneos,
cada modelo es conforme a un metamodelo diferente y el componente central no puede saber de antemano cuales son estos medamodelos ya que son especícos para cada tipo de aplicación. Por lo tanto, cada extractor también tiene la capacidad de proveer el metamodelo que es usado para construir el modelo.
Como punto nal de la estrategia se componen los modelos y metamodelos de las diferentes fuentes extraidas. La composición de modelos no es completamente automatizable [7], asi que este paso se realiza a traves de la especicación de un usuario, quien declara las relaciones necesarias entre los metamodelos y los modelos. Finalmente se obtiene un modelo conforme a un metamodelo unicado del sistema.
Figura 2.9: Estructura general EM-AutoBuilder
2.4. Objetivos
Para abordar el problema planteado en este capítulo de acuerdo a la estrategia formulada, identicamos los siguientes objetivos para esta propuesta:
Objetivo General
Desarrollar una plataforma2 que permita la construcción automatizada de modelos
em-presariales a partir de fuentes especícas que conforman los Sistemas de Información en una organización.
Objetivos Especícos
Desarrollar una plataforma para la creación de modelos estructurados.
Desarrollar herramientas para la extracción de información de sistemas informáticos espe-cícos.
Desarrollar una herramienta para la composición de modelos basada en un DSL.
2Sistema que sirve como base para hacer funcionar determinados componentes de software con los que es
Capítulo 3
Implementación de la solución
3.1. Diseño de EM-AutoBuilder
EM-AutoBuilder permite la conexión a diversas fuentes de datos de un sistema de información. Como se ilustra en la gura 2.9 en la página anterior el core de EM-Autobuilder permite conectar una serie de extractores congurables de acuerdo a unos parámetros de entrada suministrados por el usuario, para ello EM-AutoBuilder provee una interfaz gráca para seleccionar y congurar extractores compatibles con su arquitectura. Para que un extractor sea compatible con EM-AutoBuilder debe implementar la interface IExtractor y generar como salida un metamodelo Ecore y un modelo XMI.
Los componentes ModelGen y Persistance proveen un conjunto de utilidades para que un Ex-tractor Concreto pueda generar las entidades de sus metamodelos y modelos. El funcionamiento especíco de algunos Extractores Concretos se presenta con un mayor nivel de detalle en el Capítulo 4.
Figura 3.1: Componentes de EM-AutoBuilder
El Core de EM-AutoBuilder expone una interface que todos los Extractores Concretos deben implementar. Esta interface tiene los siguientes métodos:
congure: este método recibe un conjunto de propiedades Java con la información que el ex-tractor necesita para encontrar su fuente de datos. Por ejemplo, en el caso de un extractor para recolectar información de una base de datos relacional accedida a
traves de JDBC las propieddes incluiran la url para localizar la base de datos, el puerto, el nombre de usuario y el password de conexión.
collectInformation: este método utiliza la información de conguración para extraer la informa-ción y estructura en un modelo EMF. La salida de este método es un archivo que contiene el metamodelo y otro que contiene el modelo que se usaran subsecuente-mente por el Core de EM-AutoBuilder.
Adicionalmente, el Core de EM-AutoBuilder provee dos componentes reutilizables por los co-nectores concretos. El componente ModelGen y el componente Persistance.
Los métodos principales de el componente ModelGen se presentan en la Figura 3.2
Figura 3.2: Interface del componente ModelGen para la creación de modelos
El funcionamiento básico de EM-AutoBuilder se resume en los siguientes pasos:
1. Creación de un proyecto (Figura 3.3 ).
2. Selección de un extractor concreto (de acuerdo a los que estén creados para el proyecto) (Figura 3.4)
3. Conguracion de los parámetros del extractor (Figura 3.4 y 3.1) 4. Construcción del metamodelo y modelo del sistema (Figura 3.5)
CAPÍTULO 3. IMPLEMENTACIÓN DE LA SOLUCIÓN 20
Figura 3.3: Creación de un proyecto en EM-AutoBuilder
url:127.0.0.1 port:3306 user: root password: db:cca
Tabla 3.1: Archivo de conguración de un extractor de base de datos
Al construir el metamodelo y modelo del sistema EM-AutoBuilder almacena los modelos y la conguración del extractor el el directorio del proyecto (Figura 3.5)
Figura 3.5: Salidas obtenidas de EM-AutoBuilder
Una vez obtenidos los artefactos creados por el extractor de los sistemas de información, se pueden especicar las composiciones requeridas a nivel de metamodelo y modelos del sistema basadas en el DSL Fusion. Este aspecto está explicado con mayor detalle en el Capítulo 5.
3.2. Caso de estudio: Empresa BPO Los Alpes
Como caso de estudio para ilustrar la reconstrucción y composición de modelos empresariales se creó la BPO Los Alpes, una empresa del Grupo Empresarial Los Alpes [6]. Los Alpes cuenta con un conjunto de escenarios empresariales diseñados para permitir la simulación y experimen-tación dentro de una inciativa académica, lo cual permite tener empresas que no participan en el mercado, pero cuyos procesos y arquitectura son homólogos a organizaciones similares que operan con recursos reales.
3.2.1. Contexto de la empresa
La BPO Los Alpes es una compañía que ofrece servicios de Centro de Contacto en outsourcing e insourcing. Su portafolio de servicios se concentra en la gestión de campañas de donación. La Misión de la BPO Los Alpes es ofrecer soluciones estratégicas de outsourcing de manera rentable a sus clientes, para incrementar la eciencia de sus negocios, mejorar la calidad de su servicio y reducir sus costos operativos, apoyándose en soluciones informáticas. Sus actividades invoucran el manejo de información, recolección de información sobre donantes potenciales, contacto a donantes, recolección de pagos, y registro del éxito o fallos de las campañas. El macroproceso de gestión de campañas de donación en el cual nos enfocamos en este caso de estudio, está compuesto por los procesos descritos en la tabla 3.2.
CAPÍTULO 3. IMPLEMENTACIÓN DE LA SOLUCIÓN 22
Nombre del proceso Descripción
Crear nueva campaña Proceso para crear una nueva campaña en el sistema. Una campaña es una agrupación lógica para la gestión de un conjunto de donaciones que asocia los fondos recolectados con un objetivo particular en un período de tiempo. Donar en forma voluntaria Proceso que describe las actividades que una persona
rea-liza para donar a una de las campañas de la BPO Los Alpes por iniciativa propia.
Contactar donantes potenciales Proceso que agrupa las actividades de contacto a los do-nantes potenciales de una campaña, bien sea por correo electrónico o vía telefónica.
Realizar cobros Proceso que describe las actividades para cobro de una donación
Cerrar campaña Proceso para cierre o clausura de una campaña de dona-ción
Tabla 3.2: Procesos para la Gestión de Campañas de donación
3.2.2. Arquitectura de aplicaciones de la BPO Los Alpes
La BPO Los Alpes apoya su operación sobre los siguientes sistemas de información desarrollados sobre tecnologías heterogéneas y basados en licencias GPL, estos sistemas han sido en su mayoria construídos in-house. El esquema de despliegue está ilustrado en la Figura 3.6. A continuación se describen las aplicaciones del escenario de la BPO:
Sistema de donaciones: sistema para el manejo de campañas de donación, maneja la lógica del negocio y almacena información sobre campañas de donación, contacto de donantes potenciales, recolección de contribuciones y seguimiento de campañas.
CCA (Contact Center Anytime): sistema para contactar a los donantes y programar fecha de recolección de contribuciones en el caso de donaciones con dinero en efectivo. Tambien permite contactar donantes potenciales y registrar su información.
LDAP: sistema que almacena información de los usuarios de las diferentes aplicaciones y permite o denega el acceso.
Banco: servicios para el manejo de las transacciones correspondientes a las contribuciones hechas por los donantes.
BAM (Bussiness Activity Monitor): para análisis de indicadores y medición de rendimiento del negocio.
SD-RRHH: aplicación para la administración del recurso humano de la BPO y del CCA. Permite ejecutar los procesos de contratación o retiro de personal de la empresa.
SD-MSN: aplicación de gestión de visitas a donantes por parte de los cobradores de la BPO.
Alfresco: aplicación para la gestión información no estructurada como certicados de do-nación.
Figura 3.6: Sistemas de la BPO Los Alpes
3.3. Tecnologías
EM-Autobuilder esta basada en Java y EMF 2. Estas tecnologias la hacen compatible con otras herramientas de modelamiento. Para más detalles sobre EMF puede consultar el Apéndice A.
Capítulo 4
Descubrimiento y reconstrucción de
modelos
4.1. Funcionamiento de un conector/extractor
El primer paso para la reconstrucción automática de modelos empresariales es la extracción de información de las fuentes relevantes. Sin embargo, estas fuentes son de una variedad que imposibilitan tener un componente que pueda consultarlas todas. La solución para este problema de heterogeneidad fue denir un componente abstracto llamado Extractor que provee una API para congurar y usar sus servicios.
El componente extractor presenta una interface que cada conector especíco implementa de acuerdo a la lógica particular para cada fuente a la que requiere conectarse y extraer información. Como se mencionó la Sección 3.1 cada extractor concreto implementa la lógica requerida para extraer los datos que necesita para construir el metamodelo y el modelo de un sistema. Cada extractor concreto está empaquetado en un archivo .jar que provee la lógica y el metamo-delo de acuerdo al cual se hace la extracción y se crean los mometamo-delos del sistema. Cada extractor contiene unos recursos descritos en la Figura 4.1. La Clase Extractor implementa los métodos de la interface IExtractor y basado en el metamodelo en Ecore y los componentes ModelGen y Persistance crea el modelo del sistema.
Figura 4.1: Contenido de un extractor
El metamodelo que cada extractor genera es algunas veces calculado como parte del proceso de recolección de información, es decir, si bien se conoce el metamodelo genérico de una apli-cación, el metamodelo especíco que contiene la información de la fuente debe ser construído
para esa fuente en particular. Por otro lado, la relación instanceOf entre instancias y sus tipos existe de manera natural en algunos dominios, ej. bases de datos; es por esto que las instancias deben aparecer en el mismo modelo y la estructura de las instancias debe ser conforme a sus correspondientes tipos. Para lograr esta caractristica se adopta la siguiete estrategia:
La Figura 4.2 presenta un fragmento de dos modelos obtenidos de bases de datos del caso de estudio. El modelo incluye dos clases de elementos, unos de tipo instancia <<instance>>, y los otros del tipo genérico Entidad <<type>>. Los elementos de tipo instancia aparecen en el modelo pues eran registros de la base de datos. Los elementos Entidad <<type>> aparecen pues eran las tablas de la bases de datos. La relacion instanceOf entre una instancia y su Entidad es un reejo de la relacion que existe entre un registro en la base de datos y la tabla que lo contiene.
CAPÍTULO 4. DESCUBRIMIENTO Y RECONSTRUCCIÓN DE MODELOS 26
4.2. Extracción de modelos de Información y Usuarios:
Ba-ses de datos y Sistemas de Autenticación
Bases de datos
La fase de Descubrimiento del Modelo de bases de datos se realiza aplicando dos pasos consecu-tivos, el procedimiento se ilustrará sobre la base de datos del sistema CCA descrito en el caso de estudio.
El primer paso consiste en extraer información del schema de la base de datos a través de consultas SQL a las tablas que contienen el schema. Con la información recolectada se construye un modelo de la base de datos Mbd (Figura 4.4) que es conforme al metamodelo genérico de
Bases de Datos Relacionales MMbdilustrado en la Figura 4.3. Este metamodelo genérico contiene
también los conceptos para modelar las instancias de entidades, es decir, los registros de la base de datos dentro del mismo modelo. La decisión de representar instancias y entidades dentro de un mismo modelo obedece a las restricciones mencionadas en la sección 4.1.
El segundo paso consiste en recorrer el modelo génerico Mbdobtenido en el paso 1 y para cada
instancia de los elementos de tipo Entity, Attribute y Relationship, crear una EClass en un nuevo metamodelo (MMcca) que será especíco de la base de datos de la cual se está extrayendo
la información (ver gura 4.5).
Finalmente, para crear el modelo especíco (Mcca) de la base de datos, se extraen de Mbd los
valores de los elementos de tipo Instance y RelationshipInstance y se copian al modelo especíco del CCA. Como resultado Mccacontiene elementos de tipo Entity, que representan las tablas y
relaciones en la base de datos y elementos de tipo Instance, que representan los registros de cada tabla.
Figura 4.4: Mbd: Modelo de base de datos conforme al Metamodelo genérico
Figura 4.5: MMcca: Metamodelo especíco de la base de datos CCA
CAPÍTULO 4. DESCUBRIMIENTO Y RECONSTRUCCIÓN DE MODELOS 28
LDAP
Para la extracción del modelo del sistema LDAP se empleó una estrategia similar a la utilizada en el extractor de base de datos. En este caso no es necesario ejecutar el segundo paso, es decir, la transformación de un metamodelo genérico en uno particular del sistema, pues para el sistema LDAP el metamodelo especíco y el metamodelo genérico son equivalentes. En la Figura 4.6 y Figura 4.7 se ilustran el metamodelo y un fragmento del modelo obtenido respectivamente. Para la creación del modelo se recorren y extraen las entradas del LDAP y se crean las instancias dinámicas que contienen la información de cada registro.
De manera similar al sistema de bases de datos, el metamodelo contiene los conceptos para representar tanto las entidades como sus instancias; la relación llamada instanceOf vincula las instancias con sus respectivas entidades en el modelo.
Figura 4.6: Metamodelo del sistema LDAP
4.3. Extracción de modelos de Presentación (JSP) y Lógica
de Negocio (EJB)
Para estos sistemas se utiliza un enfoque similar, las fuentes de datos corresponden a los archivos de conguración ejb-jar.xml y los directorios de deployment de las webapps.
Para estos sistemas se obtuvo los modelos ilustrados en las Figuras 4.8 y Figura 4.9
Figura 4.8: Metamodelo JSP
CAPÍTULO 4. DESCUBRIMIENTO Y RECONSTRUCCIÓN DE MODELOS 30
4.4. Extraccion de modelos de Descriptores de Servicios
(WSDL) y procesos (BPEL)
Para los archivos WSDL y los descriptores BPEL se extraen los esquemas XSD a partir de las URL de sus descriptores y se realiza la transformación directa a metamodelos Ecore basándose utilidades de EMF (Figura 4.1).
Figura 4.10: Metamodelo Servicio de Vinculación/Desvinculación de empleados
Figura 4.11: Proceso de pago en efectivo Sistema de Donaciones
Xsd2Ecore x2e = new Xsd2Ecore();
x2e.go("wsdlSchema.xsd", "wsdlModel.xmi");
Capítulo 5
Composición de modelos
Para realizar análisis que involucre múltiples dominios es necesario componer conceptos entre los modelos obtenidos de cada sistema de información. Las operaciones de composición de artefactos extraídos se realizan a nivel de metamodelo y modelo. Para el tejido de metamodelos y modelos se utilizaron scripts basados en Fusion [9], los cuales se enriquecen con condiciones que indican al lenguaje los elementos a nivel de instancia que deberán componerse. A esta extensión de la herramienta Fusion para componer modelos le hemos llamado xFusion.
Los extractores, como se explica en el Capítulo 4, son independientes, y sus salidas son modelos que no están relacionados con los otros. Sin embargo, el valor del modelamiento empresarial se basa en parte la obtención de modelos que integren elementos de la organización. Sin relaciones que unan estos modelos, es dicil realizar un análisis que involucre múltiples dominios. La estrategia para unir estos modelos se presenta a continuación.
5.1. Tejido de metamodelos
Para la composición de los metamodelos se empleó el lenguaje Fusion. Este lenguaje permite la manipulación de metamodelos a partir de un conjunto de instrucciones, automatizando el proceso de composición de metamodelos a partir de una serie de metamodelos suministrados como entrada.:
Figura 5.1: Lenguaje Fusion [9]
CAPÍTULO 5. COMPOSICIÓN DE MODELOS 32
Fusion provee varias instrucciones para adaptar y coponer elementos basados en metamodelos existentes, como se enumeran a continuación:
Tipo Operacion Declaraciones importexport
Instrucciones newEntity deleteEntity renameEntity setAbstractEntity setNonAbstractEntity addAttribute removeAttribute updateAttribute renameAttribute newLink deleteLink updateLink newInheritanceLink deleteInheritanceLink mergeEntities splitEntity
Tabla 5.1: Instrucciones del lenguaje Fusion [9]
En la composición y tejido de metamodelos y modelos se utilizaron especicamente las instruc-ciones newLink para crear nuevas relainstruc-ciones entre entidades y mergeEntities para realizar el tejido entre conceptos que comparten signicados equivalentes entre los diferentes modelos del sistema. Esta idea se presentará con más detalle en sección a continuación donde se explica la estrategia para el tejido de modelos.
5.2. Tejido de modelos
Para el tejido de modelos se implementaron las funciones NewLink y MergeEntity. Para ilustrar el tejido de modelos consideraremos el caso de la creación de una relación que permita relacionar un Empleado de la BPO con su respectiva entrada en el LDAP el grupo organizacional al que pertenece, partiendo de su identicación en los dos sistemas.
El metamodelo de la base de datos del CCA y del sistema LDAP estan en las Figuras 4.5y 4.6 respectivamente. Para la creación de las relaciones entre entidades se crea un script de xFusion con las siguientes instrucciones. La última instrucción visita los dos modelos importados y crea instancias de relaciones, poniendo como referencia los objetos que en los modelos originales (es decir, sin componer) presentan la caracteristica que son empleados del CCA, y son entidades tipo Persona en el LDAP y que adicionalmente su identicador personal en los dos sistemas es el mismo.
Figura 5.2: Script xFusion para relacionar un usuario en dos sistemas diferentes
Los resultados obtenidos son el siguiente metamodelo compuesto:
Figura 5.3: NewLink entre LDAP y CCA
A nivel de modelos se copian las instancias de las demás clases que no estan involucradas en la nueva relación, y para los objetos involucrados en la relación se crean solo las instancias que tengan la condición descrita en el script de xFusion.
Una visualización global del sistema después de la composición realizada esta ilustrado en la Figura 5.4. Esto es una ventaja de representar los modelos estructuradamente, pues aunque sus componentes crezcan en número pueden ser manipulados sistemáticamente.
CAPÍTULO 5. COMPOSICIÓN DE MODELOS 34
Figura 5.4: Modelo del sistema unicado
El resultado del proceso de composición es un modelo conforme a un metamodelo compuesto. La operación de composición se puede realizar sobre los modelos obtenidos sucesivas veces, con los scripts de xFusion correspondientes.
Capítulo 6
Conclusiones
En este trabajo hemos abordado la problemática de construir modelos empresariales que sean precisos, completos, estructurados y actualizados. Para ello propusimos un enfoque de construc-ción de modelos automatizado en su mayor parte y presentamos una herramienta que implementa este enfoque: EM-AutoBuilder.
Esta herramienta provee una API para la implementación de extractores de información de fuentes especicas, además provee componentes para la creación y persistencia de modelos es-tructurados para reducir el esfuerzo de creación de nuevos extractores. EM-AutoBuilder también provee una interfaz de conguración y ejecución de extractores y permite la adaptación de nuevos extractores al ambiente de la aplicación.
Los resultados de las funcionalidades de EM-AutoBuilder se demostraron a lo largo de este trabajo en cada sección aplicados sobre el caso de estudio de la BPO Los Alpes, para cada sistema, su extractor produce un metamodelo y un modelo con la información y estructura de la fuente que consulta.
A partir de los modelos construídos se utilizó la herramienta Fusion para la composición de metamodelos basada en un DSL, el cual se extendió con instrucciones adicionales para también hacer la composición a nivel de modelos. Esta aproximación permite la integración de diferentes dominios de la organización de una manera sistemática.
Creemos que este enfoque podría enriquecerse con el uso de transformaciones de los metamo-delos obtenidos para hacer un uso menos intensivo de EMF a nivel estructural. Así mismo la retrotrazabilidad de los modelos que se emplean como fuentes para la composición se pierde al realizar el tejido o la creación de nuevas relaciones, en este proceso las condiciones para la composición a nivel de modelos implica descartar las instancias especícas de elementos que no cumplen dichas condiciones. Seria necesario evaluar si el uso de instancias virtuales que referen-cian los cambios de los modelos puedan resolver esta situación para los modelos generados pues nuestro escenario en cada composición entre dos modelos el número de instancias puede como mínimo crecer a la suma de los elementos de los dos modelos.
Este trabajo presenta varias ventajas para su uso pues permite extensibilidad mediante el desa-rrollo de componentes, reutilización de componentes base, permite obtener información de las fuentes de información para las cuales se creen extractores, y permite la composición de los modelos independientes y no relacionados en una representación integrada de la organización.
Bibliografía
[1] Stephan Aier, Sabine Buckl, Ulrik Franke, Bettina Gleichauf, Pontus Johnson, Per Närman, Christian M. Schweda, and Johan Ullberg. A survival analysis of application life spans based on enterprise architecture models. In Jan Mendling, Stefanie Rinderle-Ma, and Werner Esswein, editors, EMISA, volume 152 of LNI, pages 141154. GI, 2009. 9
[2] J. Aldrich, Craig Chambers, and D. Notkin. Archjava: connecting software architecture to implementation. In Software Engineering, 2002. ICSE 2002. Proceedings of the 24rd International Conference on, pages 187197, 2002.
[3] T. Binz, F. Leymann, A. Nowak, and D. Schumm. Improving the manageability of enter-prise topologies through segmentation, graph transformation, and analysis strategies. In Enterprise Distributed Object Computing Conference (EDOC), 2012 IEEE 16th Interna-tional, pages 6170, 2012. 9, 11, 12
[4] Hugo Bruneliere, Jordi Cabot, Frédéric Jouault, and Frédéric Madiot. Modisco: a generic and extensible framework for model driven reverse engineering. In Charles Pecheur, Jamie Andrews, and Elisabetta Di Nitto, editors, ASE, pages 173174. ACM, 2010. 9, 14 [5] Markus Buschle, Hannes Holm, Teodor Sommestad, Mathias Ekstedt, and Khurram
Shah-zad. A tool for automatic enterprise architecture modeling. In Selmin Nurcan, editor, CAiSE Forum, volume 734 of CEUR Workshop Proceedings, pages 2532. CEUR-WS.org, 2011. 9, 10
[6] Laboratorio de Arquitecturas Empresariales. Grupo empresarial los alpes. http://www.losalpes.com.co @ONLINE, 2013. 21
[7] Marcos Didonet Del Fabro, Jean Bezivin, Frederic Jouault, Erwan Breton, and Guillaume Gueltas. Amw: a generic model weaver. In Proceedings of the 1ère Journée sur l'Ingénierie Dirigée par les Modèles (IDM05), 2005. 17
[8] Mark S. Fox and Michael Gruninger. Enterprise modeling, 1998. 8
[9] Florez H., Sanchez M., and Villalobos J. Enar-fusion: A tool for metamodel composi-tion. http://backus1.uniandes.edu.co/enar/dokuwiki/doku.php?id=fusion. Technical re-port, Universidad de los Andes, 2012. 4, 5, 31, 32
[10] J. Nielsen and M. Lykke. A tool analysis in architectural reconstruction. J. Comput. Sci., 9:12671273, 2013. 8, 15
[11] J.K. Ostic, NM (United States). Technology Modeling Cannon, C.E. [Los Alamos Natio-nal Lab., and ANatio-nalysis Group]. An introduction to enterprise modeling and simulation. Sep 1996. 6, 8
[12] Bradley R. Schmerl, Jonathan Aldrich, David Garlan, Rick Kazman, and Hong Yan. Discovering architectures from running systems. Transactions on Software Engineering, 32(7):454466, 2006. 9, 15
[13] Hui Song, Gang Huang 0001, Yingfei Xiong, Franck Chauvel, Yanchun Sun, and Hong Mei. Inferring meta-models for runtime system data from the clients of management apis. In Dorina C. Petriu, Nicolas Rouquette, and Øystein Haugen, editors, MoDELS (2), volume 6395 of Lecture Notes in Computer Science, pages 168182. Springer, 2010. 9, 13, 14
Apéndice A
Tecnologías
A.1. JFace
Las herramientas desarrolladas como parte de esta Tesis estan basadas en Eclipse framework. Eclipse es principalmente conocido por su IDE para desarrollo en Java, de hecho es una plata-forma abierta para desarrollo de aplicaciones.
Uno de los componentes utilizados para la creación de las interfaces de la herramienta EM-AutoBuilder es el toolkit de JFaces, basado en Standard Widget Toolkit (SWT). Usa los controles que provee el sistema operativo y por lo tanto luce como cualquier aplicación nativa del sistema. El toolkit JFace introduce nuevos componentes basados en SWT para simplicar el desarollo de interfaces de usuario, e implementa un patrón de arquitectura MVC.
A.2. EMF (Eclipse Modeling Framework)
Para trabajar con los modelos generados, requeríamos una estructura de datos para almacenar el modelo en memoria, accederlo y modicarlo. Además de esto, los modelos se guardan en el disco duro y deben accederse desde allí. Eclipse Modeling Framework permite realizar estas operaciones. Todos los modelos fueron creados y accedidos a traves de EMF.
A.2.1. Ecore
El metamodelo general de EMF es llamado Ecore. Ecore es su propio metamodelo. En la Figura A.1 está su notación. Todos los metamodelos utilizados en EMF están basados en Ecore.
Figura A.1: Especicación de Ecore.
Los elementos de un modelo EMF están organizados en una estructura de árbol. Las referencias entre los nodos permiten representar cualquier estructura. En un metamodelo basado en Ecore el primer nivel bajo el elemento raíz contiene las clases y los tipos de datos. Las propiedades y operaciones estan en una capa siguiente a la clase correspondiente (Figura A.2).
Figura A.2: Modelo Ecore
Las conexiones de una clase a otra pueden crearse a traves de referencias, las cuales residen al mismo nivel de los atributos y operaciones. Una conexión es especicada como una clase con dos referencias, una apuntando al elemento fuente y otra al nodo de destino. Por otro lado, un nodo contiene dos arrays, uno que contiene las referencias salientes y otro las entrantes. EMF mantiene consistentes automáticamente los arrays de referencias en los nodos y las referencias dentro de las conexiones.