extracción y reconstrucción de modelos empresariales

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 deAutenticació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

1

Í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. Con�guració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

3

Í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 uni�cado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

A.1. Especi�cación de Ecore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

A.2. Modelo Ecore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Índice de tablas

3.1. Archivo de con�guració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

5

Capítulo 1

Introducción

El Modelamiento Empresarial (EM por sus siglas en inglés) entendido como la construcción yanálisis de modelos que representan uno o varios aspectos de una empresa1 es una disciplinaen crecimiento, considerada como una manera e�ciente para entender mejor las organizacionesy planear cambios sign�cativos [11]. El valor que puede ganarse al hacer EM es directamenteproporcional a la calidad de los modelos y la calidad de las herramientas disponibles para realizarlos análisis. Si los modelos son muy pequeños, con bajo nivel de detalle o no estructurados, esdifícil ejecutar análisis signi�cativos.

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, secompromete la calidad al tener que limitarse la amplitud o profundidad de los modelos elabo-rados. Adicionalmente algunos modelos se crean usando tecnologías que di�cultan su procesa-miento automatizado, por ejemplo, en procesadores de texto, hojas de cálculo o diagramas noestructurados.

El proceso de modelamiento conlleva a tener modelos grandes con diferente sintaxis que describensistemas heterogéneos haciendo que la información relevante para un usuario especí�co en unmomento determinado esté a menudo dispersa a través de varios modelos. Por lo tanto se necesitacomponer o enlazar estos modelos o parte de ellos para proveer información uni�cada y usablede 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óndesplegados para crear modelos empresariales construídos en tiempo y costo menores que losque 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 modelosempresariales 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 modelosempresariales utilizando información de diferentes fuentes. Este enfoque se implementó en unaherramienta 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 detalleel 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

6

CAPÍTULO 1. INTRODUCCIÓN 7

la solución propuesta. En el capítulo 3 se describen los detalles de la solución y se presenta elescenario del caso de estudio.

El enfoque propuesto y su implementación están descritos en los capítulos 4 y 5 junto con losresultados de su aplicación al caso de estudio. Finalmente el capítulo 6 concluye el trabajorealizado.

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 lasorganizaciones, su uso permite a las empresas crear mejores diseños de su estructura, haceranálisis del desempeño organizacional y mejorar la administración de sus operaciones [8].

Aunque no hay una de�nició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 ovarios 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 laestructura, actividades, procesos, información, recursos, personas, comportamiento, objetivos yrestricciones de un negocio, entidad u otra empresa con el propósito de que el análisis, diseño yoperació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; elcosto 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 bene�ciosde construir modelos no son intrínsecos al modelo sino que dependen del propósito con el que seconstruye, por ejemplo, para documentación o comunicación, incrementar la comprensión de unaempresa, 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 de�nido que un modelo debasatisfacer, existen diferentes respuestas a la pregunta de cuáles son las cualidades que debetener un modelo para cumplir una tarea determinada [8]. Consideramos que un modelo deberiatener las siguientes propiedades para que resulte adecuado para describir una organización:

Preciso: debe re�ejar la realidad que intenta modelar, de otro modo no puede ser usadopara responder de manera con�able sobre asuntos de la organización. La toma de decisionesbasada 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 ydetalle.

Actualizado: un modelo debe tener la información que describa el estado más reciente delsistema, de otro modo pierde precisión progresivamente.

8

CAPÍTULO 2. MOTIVACIÓN Y ESTRATEGIA DE SOLUCIÓN 9

Estructurado: debe estar construído sobre estructuras de�nidas y expresado en representa-ciones que favorezcan el procesamiento automático. Los modelos creados en documentos,diagramas y hojas de cálculo di�cultan 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 deinformación que se espera que contenga.

Factible en costo: el costo de construir y mantener un modelo empresarial debe ser tanbajo como sea posible, de otro modo, los modelos progresivamente quedan desactualizados.

Debido a que los modelos intentan proveer información con�able y deben capturar los aspectosde relevancia para la organización, frecuentemente crecen en un alto número de entidades yrelaciones entre ellas. La creación de estos modelos consume tiempo y en varios casos se requiereel involucramiento de los responsables de las diferentes piezas de información que deben serrecolectadas. Incluso, durante el proceso de creación de modelos ya existe la posibilidad de quequeden parcialmente desactualizados [1].

Una respuesta a la situación descrita consiste en la automatización de la construcción de losmodelos 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 modelosa diferentes niveles de detalle y enfocándose en dominios particulares. Un enfoque ha sido elanálisis de activos de infraestructura de tecnología en las redes corporativas para identi�caraplicaciones desplegadas. Entre ellos se encuentran el trabajo de Buschle et al. [5] el cual proponereconstruir modelos de arquitectura empresarial basados en escaneo de redes y representaciónde los principales componentes de la infraestructura de aplicaciones mediante una estructura enforma de grafo. Este enfoque utiliza información capturada con herramientas de análisis de redy de exploración de vulnerabilidades. De manera similar, el trabajo de Binz et al. [3] combinaun enfoque semi-automatizado con asistencia manual para la reconstrucción de modelos. Laparte automatizable consiste en el descubrimiento de las familias de aplicaciones activas en lared, ej. bases de datos, servidores de aplicaciones. De manera asistida se realiza manualmentela caracterización de estos conceptos para darles un signi�cado en el modelo de acuerdo a su rolen 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álisisde código fuente. El uso exitoso de estos enfoques depende en gran medida de que el códigofuente 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 con�guración para crear modelos que representanuno o varios sistemas. Por otra parte, el proyecto DiscoTect [12] combina el análisis de códigofuente con el análisis de eventos de bajo nivel del sistema para obtener una representacion querelaciona 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 paraconstruir con esta información metamodelos de un sistema. A continuación se describen con másdetalle estas propuestas:


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 yprecisos de un sistema, teniendo en cuenta que el número de sus elementos y relaciones crecenpara poder soportar cambios en las organizaciones. La estrategia de solución que proponen losautores consiste en escanear la red corporativa con NeXpose1, un scanner de vulnerabilidadesque provee información sobre los dispositivos conectados, �rewalls, y otros activos de red. Elsistema identi�ca el sistema operativo o �rmware que corren los dispositivos y los servicios enejecució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 modeloscomo el de la Figura 2.1.

Figura 2.1: Mapping de un sistema según Buschle et al.Tomado de [5]

1Vulnerability Management Software. http://www.rapid7.com/products/nexpose/


Improving the Manageability of Enterprise Topologies Through Segmentation, GraphTransformation, 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 representalos servicios, aplicaciones e infraestructura tecnológica de una empresa. El descubrimiento delos activos de TI se realiza a través de modelamiento manual y análisis de red. Adicionalmentese de�ne 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álisisde la arquitectura modelada.

En la Figura 2.2 se ilustra el panorama general de una topología empresarial. Las áreas enlas que se enfoca el trabajo descrito están resaltadas en un color más intenso. El propósitoes formalizar usando el modelo de la Figura 2.3 la información extraída de los sistemas deinformación empresariales para permitir realizar operaciones de manera automatizada sobre unconjunto grande de elementos y permitir su análisis posterior.

Figura 2.2: Esquema de una topología empresarialTomado de [3]


Figura 2.3: Modelo de representación propuesto por Binz et alTomado 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óncon modelamiento manual. Cada sistema descubierto se modela como un nodo del grafo y lasrelaciones como los arcos entre nodos, algunas relaciones no son detectables y se completanmanualmente en el modelo.

Para realizar análisis de arquitectura sobre el modelo obtenido, se de�ne la operacion de seg-mentación que permite obtener subconjuntos de elementos de interés de tamaño menor que elmodelo original. Además se de�nen 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 representana 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 aplicacionesque conforman los sistemas de información en las organizaciones y está especialmente diseñadapara realizar análisis de dependencia entre componentes a nivel de infraestructura, preveer elimpacto de migraciónes, y dar una visión de las plataformas tecnológicas que componen elsistema.


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 managementAPIs [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 instanciasde componentes en ejecución, representando estos conceptos en forma de modelos estructuradospara ser procesados de manera automática. Dado que cada sistema provee diferentes datos entiempo de ejecución, es necesario construir primero un metamodelo que de�ne los tipos de datosdel 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ónde las aplicaciones JEE vía JMX.

La información extraída contiene un conjunto de probables tipos de datos y atributos que serepresentan en forma de grafo (ver Figura 2.4) y sobre el cual se aplican reglas de inferenciapara descubrir relaciones y entidades; adicionalmente se simpli�ca el metamodelo removiendoconceptos duplicados y no signi�cativos 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énaccede a c3 directamente, en este caso se elimina la referencia (c1,c3) ya que un caminoimplica el otro.

3. Debilitar clases que acceden a otras a través de atributos: si una clase c1 tiene una referenciaa c2, y esta relación no tiene ningún estado o apunta a otra clase, se descarta y se agregacomo atributo de c1.

4. Eliminar clases �débiles�: son clases que no tienen ninguna asociación directa, ni manerade 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 laextracción; estos metamodelos están formulados para modelar sistemas que describen conceptosde 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]


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 paraprocesos de migración o modernización, haciendo la reingeniería de estos sistemas con el menorcosto posible. Para lograrlo, propone la reconstrucción de las funcionalidades y la arquitectura deun sistema en una representación que pueda ser manipulada automáticamente, y en un formatoque provea soporte genérico para ser procesado en diferentes tecnologías.

MoDisco busca transformar la heterogeneidad del mundo de las diferentes implementacionesheterogéneas en un mundo homogénego de modelos. La idea general es poder extraer informaciónde varios sistemas y construir modelos dependiendo de los puntos de vista de interés para despuésoperar 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 actividadde 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 metamodelo para la extracción de información de archivos de con�guraciónXML.

Figura 2.6: Fases de operación del proyecto MoDiscoTomado de [4]


Dynamically discovering architectures with DiscoTect [12]

Este proyecto propone el descubrimiento dinámico de arquitecturas a traves del monitoreo delcomportamiento de aplicaciones en tiempo de ejecución, transformación de estos comportamien-tos en eventos signi�cativos desde el punto de vista de infraestructura y representación de estosconceptos en un grafo.

DiscoTect captura eventos del sistema como llamados a métodos, utilización de CPU, consumode red, uso de memoria mediante el uso de harramientas de monitorieo o inyección de códigoen 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 entreellos.

<call method_name=�java.net.ServerSocket.accept�callee_id=�19efb05� return_id=�1d1acd3� />

Figura 2.7: Ejemplo de una llamada al sistema. Proyecto DiscoTectTomado 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 conocimientoa-priori del estilo arquitectural de la aplicación implementada. Por esta misma razón las im-plementaciones analizadas deben seguir ciertas convenciones de codi�cación y además se debeconocer 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 medianteiteraciones 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 demodelos UML a partir de la instrospección de codigo fuente de los sistemas de informaciónempresariales. El propósito de este trabajo es lograr hacer ingeniería inversa de una aplicación


de software y crear diagramas de �ujo a partir del código. Esto se representa en diagramas dondeaparecen componentes de tipo Package, Objects, Classes y Nodes.

Las vistas que se reconstruyen en este trabajo son las vistas Componente y Conector (C&C), lascuales 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 di�cil obtener información a partir de aplicacionesexistentes y así mismo encontrar una herramienta que permita modelar los componentes delsistema desplegado.

2.3. Estrategia de la solución propuesta

Para la creación de modelos empresariales que re�ejen el estado de la organización proponemosun enfoque automatizado para la recolección de datos y la creación de los modelos con el �n delograr menores tiempos y costos de modelamiento y un incremento en la calidad de los modelosobtenidos. En este trabajo nuestro interés está en la extracción de información de los sistemas deinformación directamente, con el �n de construir modelos precisos, actualizados, estructuradosy 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. Abarcamosdeterminadas 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 procesosde negocio. Construimos un componente reutilizable para la creación de modelos estructuradosy 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 unmodelo que describa la empresa de manera uni�cada.

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 eligieronfuentes 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 diferentesestructuras, 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 procesadoo 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 con�gurables y procesar las salidas que producen. Los Extractores son componentesindependientes, cada uno es capaz de conectarse a alguna clase de fuente especí�ca para extraerinformació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 saberde 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 usadopara construir el modelo.

Como punto �nal de la estrategia se componen los modelos y metamodelos de las diferentesfuentes extraidas. La composición de modelos no es completamente automatizable [7], asi queeste paso se realiza a traves de la especi�cación de un usuario, quien declara las relacionesnecesarias entre los metamodelos y los modelos. Finalmente se obtiene un modelo conforme aun metamodelo uni�cado 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,identi�camos 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 enuna 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 escompatible

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 conectaruna serie de extractores con�gurables de acuerdo a unos parámetros de entrada suministradospor el usuario, para ello EM-AutoBuilder provee una interfaz grá�ca para seleccionar y con�gurarextractores compatibles con su arquitectura. Para que un extractor sea compatible con EM-AutoBuilder debe implementar la interface IExtractor y generar como salida un metamodeloEcore 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 funcionamientoespecí�co de algunos Extractores Concretos se presenta con un mayor nivel de detalle en elCapítulo 4.

Figura 3.1: Componentes de EM-AutoBuilder

El Core de EM-AutoBuilder expone una interface que todos los Extractores Concretos debenimplementar. Esta interface tiene los siguientes métodos:

con�gure: 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 unextractor para recolectar información de una base de datos relacional accedida a

18

CAPÍTULO 3. IMPLEMENTACIÓN DE LA SOLUCIÓN 19

traves de JDBC las propieddes incluiran la url para localizar la base de datos, elpuerto, el nombre de usuario y el password de conexión.

collectInformation: este método utiliza la información de con�guración para extraer la informa-ción y estructura en un modelo EMF. La salida de este método es un archivo quecontiene 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. Con�guracion de los parámetros del extractor (Figura 3.4 y 3.1)

4. Construcción del metamodelo y modelo del sistema (Figura 3.5)


Figura 3.3: Creación de un proyecto en EM-AutoBuilder

Figura 3.4: Con�guración de un extractor a traves de EM-AutoBuilder


url:127.0.0.1

port:3306

user: root

password:

db:cca

Tabla 3.1: Archivo de con�guración de un extractor de base de datos

Al construir el metamodelo y modelo del sistema EM-AutoBuilder almacena los modelos y lacon�guració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, sepueden especi�car las composiciones requeridas a nivel de metamodelo y modelos del sistemabasadas 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 empresarialesse creó la BPO Los Alpes, una empresa del Grupo Empresarial Los Alpes [6]. Los Alpes cuentacon 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 enel mercado, pero cuyos procesos y arquitectura son homólogos a organizaciones similares queoperan 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 outsourcinge insourcing. Su portafolio de servicios se concentra en la gestión de campañas de donación. LaMisión de la BPO Los Alpes es ofrecer soluciones estratégicas de outsourcing de manera rentablea sus clientes, para incrementar la e�ciencia de sus negocios, mejorar la calidad de su servicio yreducir sus costos operativos, apoyándose en soluciones informáticas. Sus actividades invoucranel manejo de información, recolección de información sobre donantes potenciales, contacto adonantes, recolección de pagos, y registro del éxito o fallos de las campañas. El macroprocesode 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.


Nombre del proceso Descripción

Crear nueva campaña Proceso para crear una nueva campaña en el sistema. Unacampaña es una agrupación lógica para la gestión de unconjunto de donaciones que asocia los fondos recolectadoscon 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 LosAlpes 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 correoelectrónico o vía telefónica.

Realizar cobros Proceso que describe las actividades para cobro de unadonació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 desarrolladossobre tecnologías heterogéneas y basados en licencias GPL, estos sistemas han sido en su mayoriaconstruídos in-house. El esquema de despliegue está ilustrado en la Figura 3.6. A continuaciónse describen las aplicaciones del escenario de la BPO:

Sistema de donaciones: sistema para el manejo de campañas de donación, maneja la lógicadel negocio y almacena información sobre campañas de donación, contacto de donantespotenciales, recolección de contribuciones y seguimiento de campañas.

CCA (Contact Center Anytime): sistema para contactar a los donantes y programar fechade recolección de contribuciones en el caso de donaciones con dinero en efectivo. Tambienpermite contactar donantes potenciales y registrar su información.

LDAP: sistema que almacena información de los usuarios de las diferentes aplicaciones ypermite o denega el acceso.

Banco: servicios para el manejo de las transacciones correspondientes a las contribucioneshechas por los donantes.

BAM (Bussiness Activity Monitor): para análisis de indicadores y medición de rendimientodel 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 laBPO.

Alfresco: aplicación para la gestión información no estructurada como certi�cados de do-nación.

Gate-In Portal: portal que integra todos los front-end de los diferentes sistemas de la BPO.


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 otrasherramientas de modelamiento. Para más detalles sobre EMF puede consultar el Apéndice A.

Capítulo 4

Descubrimiento y reconstrucción demodelos

4.1. Funcionamiento de un conector/extractor

El primer paso para la reconstrucción automática de modelos empresariales es la extracciónde información de las fuentes relevantes. Sin embargo, estas fuentes son de una variedad queimposibilitan tener un componente que pueda consultarlas todas. La solución para este problemade heterogeneidad fue de�nir un componente abstracto llamado Extractor que provee unaAPI para con�gurar y usar sus servicios.

El componente extractor presenta una interface que cada conector especí�co implementa deacuerdo 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 paraextraer 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 modelos del sistema. Cada extractorcontiene unos recursos descritos en la Figura 4.1. La Clase Extractor implementa los métodosde la interface IExtractor y basado en el metamodelo en Ecore y los componentes ModelGen yPersistance 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 procesode 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

24

CAPÍTULO 4. DESCUBRIMIENTO Y RECONSTRUCCIÓN DE MODELOS 25

para esa fuente en particular. Por otro lado, la relación instanceOf entre instancias y sus tiposexiste de manera natural en algunos dominios, ej. bases de datos; es por esto que las instanciasdeben aparecer en el mismo modelo y la estructura de las instancias debe ser conforme a suscorrespondientes 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 deestudio. El modelo incluye dos clases de elementos, unos de tipo instancia <�<instance>�>, ylos otros del tipo genérico Entidad <�<type>�>. Los elementos de tipo instancia aparecen enel modelo pues eran registros de la base de datos. Los elementos Entidad <�<type>�> aparecenpues eran las tablas de la bases de datos. La relacion instanceOf entre una instancia y su Entidades un re�ejo de la relacion que existe entre un registro en la base de datos y la tabla que locontiene.

Figura 4.2: Modelo de base de datos CCA y Donaciones


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 casode estudio.

El primer paso consiste en extraer información del schema de la base de datos a través deconsultas SQL a las tablas que contienen el schema. Con la información recolectada se construyeun modelo de la base de datos Mbd (Figura 4.4) que es conforme al metamodelo genérico deBases de Datos Relacionales MMbd ilustrado en la Figura 4.3. Este metamodelo genérico contienetambién los conceptos para modelar las instancias de entidades, es decir, los registros de la basede datos dentro del mismo modelo. La decisión de representar instancias y entidades dentro deun mismo modelo obedece a las restricciones mencionadas en la sección 4.1.

El segundo paso consiste en recorrer el modelo génerico Mbd obtenido en el paso 1 y para cadainstancia de los elementos de tipo Entity, Attribute y Relationship, crear una EClass en unnuevo metamodelo (MMcca) que será especí�co de la base de datos de la cual se está extrayendola información (ver �gura 4.5).

Finalmente, para crear el modelo especí�co (Mcca) de la base de datos, se extraen de Mbd losvalores de los elementos de tipo Instance y RelationshipInstance y se copian al modelo especí�codel CCA. Como resultado Mccacontiene elementos de tipo Entity, que representan las tablas yrelaciones en la base de datos y elementos de tipo Instance, que representan los registros de cadatabla.

Figura 4.3: MMbd: Metamodelo genérico de base de datos


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(Se omitieron algunos elementos presentes en el metamodelo para lograr una mejor visualización)


LDAP

Para la extracción del modelo del sistema LDAP se empleó una estrategia similar a la utilizadaen 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 sistemaLDAP el metamodelo especí�co y el metamodelo genérico son equivalentes. En la Figura 4.6 yFigura 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 instanciasdinámicas que contienen la información de cada registro.

De manera similar al sistema de bases de datos, el metamodelo contiene los conceptos pararepresentar tanto las entidades como sus instancias; la relación llamada instanceOf vincula lasinstancias con sus respectivas entidades en el modelo.

Figura 4.6: Metamodelo del sistema LDAP

Figura 4.7: Modelo del sistema LDAP


4.3. Extracción de modelos de Presentación (JSP) y Lógicade Negocio (EJB)

Para estos sistemas se utiliza un enfoque similar, las fuentes de datos corresponden a los archivosde con�guració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

Figura 4.9: Modelo JSP del sistema CCA del caso de estudio


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 lasURL de sus descriptores y se realiza la transformación directa a metamodelos Ecore basándoseutilidades 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");

Tabla 4.1: Extracción WSDL y BPEL

Capítulo 5

Composición de modelos

Para realizar análisis que involucre múltiples dominios es necesario componer conceptos entre losmodelos obtenidos de cada sistema de información. Las operaciones de composición de artefactosextraídos se realizan a nivel de metamodelo y modelo. Para el tejido de metamodelos y modelosse utilizaron scripts basados en Fusion [9], los cuales se enriquecen con condiciones que indicanal lenguaje los elementos a nivel de instancia que deberán componerse. A esta extensión de laherramienta Fusion para componer modelos le hemos llamado xFusion.

Los extractores, como se explica en el Capítulo 4, son independientes, y sus salidas son modelosque no están relacionados con los otros. Sin embargo, el valor del modelamiento empresarial sebasa en parte la obtención de modelos que integren elementos de la organización. Sin relacionesque unan estos modelos, es di�cil realizar un análisis que involucre múltiples dominios. Laestrategia 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 permitela manipulación de metamodelos a partir de un conjunto de instrucciones, automatizando elproceso de composición de metamodelos a partir de una serie de metamodelos suministradoscomo entrada.:

Figura 5.1: Lenguaje Fusion [9]

31

CAPÍTULO 5. COMPOSICIÓN DE MODELOS 32

Fusion provee varias instrucciones para adaptar y coponer elementos basados en metamodelosexistentes, como se enumeran a continuación:

Tipo Operacion

Declaracionesimportexport

Instrucciones

newEntitydeleteEntityrenameEntitysetAbstractEntitysetNonAbstractEntityaddAttributeremoveAttributeupdateAttributerenameAttributenewLinkdeleteLinkupdateLinknewInheritanceLinkdeleteInheritanceLinkmergeEntitiessplitEntity

Tabla 5.1: Instrucciones del lenguaje Fusion [9]

En la composición y tejido de metamodelos y modelos se utilizaron especi�camente las instruc-ciones newLink para crear nuevas relaciones entre entidades y mergeEntities para realizar eltejido entre conceptos que comparten signi�cados equivalentes entre los diferentes modelos delsistema. Esta idea se presentará con más detalle en sección a continuación donde se explica laestrategia para el tejido de modelos.

5.2. Tejido de modelos

Para el tejido de modelos se implementaron las funciones NewLink y MergeEntity. Para ilustrarel tejido de modelos consideraremos el caso de la creación de una relación que permita relacionarun Empleado de la BPO con su respectiva entrada en el LDAP el grupo organizacional al quepertenece, partiendo de su identi�cació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.6respectivamente. Para la creación de las relaciones entre entidades se crea un script de xFusioncon las siguientes instrucciones. La última instrucción visita los dos modelos importados y creainstancias de relaciones, poniendo como referencia los objetos que en los modelos originales (esdecir, sin componer) presentan la caracteristica que son empleados del CCA, y son entidadestipo Persona en el LDAP y que adicionalmente su identi�cador personal en los dos sistemas esel 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 enla nueva relación, y para los objetos involucrados en la relación se crean solo las instancias quetengan 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 laFigura 5.4. Esto es una ventaja de representar los modelos estructuradamente, pues aunque suscomponentes crezcan en número pueden ser manipulados sistemáticamente.


Figura 5.4: Modelo del sistema uni�cado

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, conlos scripts de xFusion correspondientes.

Capítulo 6

Conclusiones

En este trabajo hemos abordado la problemática de construir modelos empresariales que seanprecisos, 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 implementaeste enfoque: EM-AutoBuilder.

Esta herramienta provee una API para la implementación de extractores de información defuentes especi�cas, 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énprovee una interfaz de con�guración y ejecución de extractores y permite la adaptación de nuevosextractores al ambiente de la aplicación.

Los resultados de las funcionalidades de EM-AutoBuilder se demostraron a lo largo de estetrabajo en cada sección aplicados sobre el caso de estudio de la BPO Los Alpes, para cadasistema, su extractor produce un metamodelo y un modelo con la información y estructura dela fuente que consulta.

A partir de los modelos construídos se utilizó la herramienta Fusion para la composición demetamodelos basada en un DSL, el cual se extendió con instrucciones adicionales para tambiénhacer la composición a nivel de modelos. Esta aproximación permite la integración de diferentesdominios 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 laretrotrazabilidad de los modelos que se emplean como fuentes para la composición se pierdeal realizar el tejido o la creación de nuevas relaciones, en este proceso las condiciones para lacomposición a nivel de modelos implica descartar las instancias especí�cas de elementos que nocumplen 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 puesnuestro escenario en cada composición entre dos modelos el número de instancias puede comomí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 lasfuentes de información para las cuales se creen extractores, y permite la composición de losmodelos independientes y no relacionados en una representación integrada de la organización.

35

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 basedon enterprise architecture models. In Jan Mendling, Stefanie Rinderle-Ma, and WernerEsswein, editors, EMISA, volume 152 of LNI, pages 141�154. GI, 2009. 9

[2] J. Aldrich, Craig Chambers, and D. Notkin. Archjava: connecting software architectureto implementation. In Software Engineering, 2002. ICSE 2002. Proceedings of the 24rdInternational Conference on, pages 187�197, 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. InEnterprise Distributed Object Computing Conference (EDOC), 2012 IEEE 16th Interna-tional, pages 61�70, 2012. 9, 11, 12

[4] Hugo Bruneliere, Jordi Cabot, Frédéric Jouault, and Frédéric Madiot. Modisco: a genericand extensible framework for model driven reverse engineering. In Charles Pecheur, JamieAndrews, and Elisabetta Di Nitto, editors, ASE, pages 173�174. 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 25�32. 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 GuillaumeGueltas. Amw: a generic model weaver. In Proceedings of the 1ère Journée sur l'IngénierieDirigé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:1267�1273, 2013. 8, 15

[11] J.K. Ostic, NM (United States). Technology Modeling Cannon, C.E. [Los Alamos Natio-nal Lab., and Analysis Group]. An introduction to enterprise modeling and simulation. Sep1996. 6, 8

36

BIBLIOGRAFÍA 37

[12] Bradley R. Schmerl, Jonathan Aldrich, David Garlan, Rick Kazman, and Hong Yan.Discovering architectures from running systems. Transactions on Software Engineering,32(7):454�466, 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. InDorina C. Petriu, Nicolas Rouquette, and Øystein Haugen, editors, MoDELS (2), volume6395 of Lecture Notes in Computer Science, pages 168�182. 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 StandardWidget Toolkit (SWT). Usa los controlesque 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 simpli�car el desarollo deinterfaces 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 almacenarel modelo en memoria, accederlo y modi�carlo. Además de esto, los modelos se guardan enel disco duro y deben accederse desde allí. Eclipse Modeling Framework permite realizar estasoperaciones. 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 FiguraA.1 está su notación. Todos los metamodelos utilizados en EMF están basados en Ecore.

38

APÉNDICE A. TECNOLOGÍAS 39

Figura A.1: Especi�cación de Ecore.

Los elementos de un modelo EMF están organizados en una estructura de árbol. Las referenciasentre los nodos permiten representar cualquier estructura. En un metamodelo basado en Ecoreel primer nivel bajo el elemento raíz contiene las clases y los tipos de datos. Las propiedades yoperaciones 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 almismo nivel de los atributos y operaciones. Una conexión es especi�cada como una clase condos referencias, una apuntando al elemento fuente y otra al nodo de destino. Por otro lado, unnodo contiene dos arrays, uno que contiene las referencias salientes y otro las entrantes. EMFmantiene consistentes automáticamente los arrays de referencias en los nodos y las referenciasdentro de las conexiones.

extracción y reconstrucción de modelos empresariales

Documents