DISEÑO DE UN MÉTODO PARA DETERMINAR UN CONJUNTO DE RECOMENDACIONES PARA REALIZAR LA INTEGRACIÓN DE APLICACIONES EMPRESARIALES

Tamaño: px
Comenzar la demostración a partir de la página:

Download "DISEÑO DE UN MÉTODO PARA DETERMINAR UN CONJUNTO DE RECOMENDACIONES PARA REALIZAR LA INTEGRACIÓN DE APLICACIONES EMPRESARIALES"

Transcripción

1 DISEÑO DE UN MÉTODO PARA DETERMINAR UN CONJUNTO DE RECOMENDACIONES PARA REALIZAR LA INTEGRACIÓN DE APLICACIONES EMPRESARIALES VICTOR DANNEY GARCIA PLAZA MARIA TERESA LOPEZ DUEÑAS UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍAS MAESTRÍA EN INGENIERÍA DE SOFTWARE SANTIAGO DE CALI ENERO DE

2 DISEÑO DE UN MÉTODO PARA DETERMINAR UN CONJUNTO DE RECOMENDACIONES PARA REALIZAR LA INTEGRACIÓN DE APLICACIONES EMPRESARIALES MARIA TERESA LOPEZ DUEÑAS VICTOR DANNEY GARCIA PLAZA DIEGO ARMANDO GOMEZ MOSQUERA Director de trabajo de grado UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍAS MAESTRÍA EN INGENIERÍA DE SOFTWARE SANTIAGO DE CALI ENERO DE

3 Nota de aceptación Presidente del Jurado Jurado Jurado Santiago de Cali, enero de

4 DEDICATORIA A Dios sobre todas las cosas, a mi familia por ser el motor que me impulsa a crecer cada día y a mis amigos quienes con su apoyo y consejos me ayudan a mantener firmes mis objetivos. MARIA TERESA LÓPEZ DUEÑAS A Dios, a mi pequeño Juan Pablo, a mi esposa Angélica, y a mis padres, por su gran amor y apoyo en cada una de las etapas de mi vida. VICTOR D. GARCIA PLAZA 4

5 AGRADECIMIENTOS A Dios a quien confío mis retos, a mi familia y amigos quienes con su cariño y respaldo me acompañaron en este proceso y a mi director de tesis y colegas quienes nos respaldaron, con sus valiosos conocimientos y aportes, para el logro de este objetivo. MARIA TERESA LÓPEZ DUEÑAS A Dios por darme la oportunidad de aprender, a mi familia por su enorme apoyo y a Diego A. Gómez, por su tiempo, dedicación e ideas que contribuyeron satisfactoriamente a la culminación de este trabajo de grado. VICTOR D. GARCIA PLAZA 5

6 TABLA DE CONTENIDO 1. PLANTEAMIENTO DEL PROBLEMA MARCO TEORICO METODOLOGÍA Fase I, denominada Recopilación Etapa I Etapa II Etapa III Fase II, denominada Diseño Etapa I Etapa II Etapa III Etapa IV Etapa V Fase III, denominada Aplicación Etapa I Etapa II RESULTADOS Fase I Recopilación de información Etapa I Determinar conjunto de variables Etapa II Determinar conjunto de soluciones conocidas Etapa III Determinar el conjunto de buenas prácticas Fase II Diseño del método Etapa I: Definición de categorías Etapa II: Soluciones conocidas aplicables por categoría Etapa III: Buenas prácticas aplicables por categoría Etapa IV: Definición de filtros Etapa V: El método diseñado Fase III Prueba del diseño del método

7 4.3.1 Etapa I: Refinamiento del método Etapa II: Aplicación del método diseñado CONCLUSIONES RECOMENDACIONES Y TRABAJOS FUTUROS

8 LISTA DE TABLAS Tabla 1 Ventajas y desventajas de los estilos de integración Tabla 2 Estilos de integración y los Frameworks que los implementan. Tabla 3 Buenas prácticas agrupadas por cada solución conocida. Tabla 4 Comparativo entre solución real y soluciones recomendadas. 8

9 LISTA DE FIGURAS Figura 1. Esquema de la metodología desarrollada. Figura 2. Transferencia de archivos. Figura 3. Bases de datos compartidas. Figura 4. Invocación a procedimientos remotos. Figura 5. Mensajería. Figura 6. Aplicaciones comunicadas usando mensajería. Figura 7. Comunicación basada en mensajería a través de un MOM. Figura 8. Transmisión de mensajes paso a paso. Figura 9. Categorización de Patrones de integración empresarial. Figura 10. Esquema del método diseñado. 9

10 LISTA DE ANEXOS Anexo 1: Resultados de la encuesta: Anexo 1.1 Encuesta. Anexo1.2 Necesidades de integración. Anexo 1.3 Criterios y restricciones para la integración. Anexo 1.4 Tipos de aplicaciones a integrar. Anexo 1.5 Características de calidad de la solución de integración. Anexo 1.6 Cuadro de tecnologías Anexo1.7 Caracterización de las empresas de los profesionales objeto de la encuesta Anexo 2: Combinación de variables: Anexo 2.1 Tipos de aplicaciones Anexo 2.2 Criterios y restricciones Anexo 2.3 Características de calidad Anexo 2.4 Criterios y restricciones tipo de aplicación origen Anexo 2.5 Criterios y restricciones tipo de aplicación destino Anexo 3: Aplicación del método diseñado Anexo 3.1: Soluciones conocidas criterios y restricciones Anexo 3.2: Criterios y restricciones refinado Anexo 3.3: Soluciones conocidas tipo de aplicación origen Anexo 3.4: Soluciones conocidas tipo de aplicación destino Anexo 3.5: Caracterización de los casos de negocio y soluciones 10

11 RESUMEN Cuando un constructor de aplicaciones empresariales se enfrenta a la integración de dos aplicaciones para un caso específico de negocio, se encuentra con un conjunto bastante amplio de estrategias, métodos y arquitecturas que pueden ser utilizados. Sin embargo, cuando debe elegir una opción de entre el conjunto de posibilidades, surgen las restricciones que están dadas por las características de las aplicaciones de su negocio y los requerimientos no funcionales del caso específico objeto de la integración; por lo que seleccionar la opción más adecuada resulta ser un problema no trivial de resolver. En este proyecto de investigación se diseñó un método que al ser usado por un constructor de aplicaciones empresariales, que se enfrenta a un caso de integración, le entrega una recomendación sobre las posibles opciones a usar; considerando las características de las aplicaciones a integrar y las restricciones presentes en su caso específico de negocio. Para diseñar este método se inició con la recolección y definición de las características de las aplicaciones y restricciones comunes presentes en las empresas de Santiago de Cali; así como el conjunto de métodos, estrategias, buenas prácticas, soluciones conocidas y otras reglas usadas para la integración de aplicaciones empresariales. Posteriormente se realizó el diseño del método a través de la identificación y definición de las categorías en las que se clasifican los casos de negocio y la identificación y definición del conjunto de buenas prácticas y soluciones conocidas aplicables a cada categoría. Con lo anterior se definió una serie de filtros que permitieron garantizar la correcta caracterización y categorización de los casos de negocio dados y por consiguiente cuales son las buenas prácticas y soluciones conocidas que le son aplicables. Finalmente se 11

12 probó el diseño del método a diez (10) casos de negocio reales y al mismo tiempo se hizo el refinamiento a través de la definición y validación de criterios que permitieron determinar la pertinencia del conjunto de recomendaciones entregado por el método diseñado, frente a la caracterización del caso de negocio. 12

13 INTRODUCCIÓN Cuando se piensa en una empresa, esta se ve como un sistema complejo que tiene un propósito u objetivo específico. Las aplicaciones empresariales intentan apoyar a la empresa en la consecución de estos objetivos [1]. Debido a esto, los constructores de aplicaciones empresariales se enfrentan al reto de implementar soluciones especializadas que deben procesar tareas específicas, enfocadas a un conjunto determinado de procesos y diseñadas a la medida de las necesidades del negocio; que a su vez deben integrarse con otras aplicaciones de negocio y/o sistemas legados que desempeñan otras tareas específicas. En la búsqueda de mecanismos u opciones para realizar la integración de aplicaciones, un constructor de aplicaciones empresariales, que se enfrenta a un caso de negocio, encuentra un amplio conjunto de soluciones que pueden ser en alguna medida aplicables al caso de integración. Seleccionar la mejor opción es una habilidad que resulta de la experiencia, pues en la actualidad no se cuenta con un método conocido que permita llegar a una mejor opción. En el presente proyecto de investigación se diseñó un método que al ser usado por un constructor de aplicaciones empresariales, que se enfrenta a un caso de negocio en el que deba realizar integración de aplicaciones, este le entregara una recomendación sobre las posibles opciones a usar; considerando las características propias de las aplicaciones y restricciones con las que trabaja. Para lo anterior se identificó un conjunto de características y restricciones que al ser agrupadas, permitieron definir las categorías en las que se pueden clasificar los casos de negocio; complementando lo anterior se definió cuáles son las buenas prácticas y soluciones conocidas que se pueden aplicar a cada categoría. De manera que una vez clasificado un caso de negocio en una categoría, se relacionan las buenas prácticas y soluciones conocidas que son aplicables. 13

14 En los capítulos siguientes se presentan el planteamiento del problema para el cual el método fue diseñado; el marco teórico en el que se ambientan, a través de los diferentes enfoques y autores, el problema y las aproximaciones que se le han dado a la integración de aplicaciones empresariales; Además se presenta, también, cada una de las fases y etapas de la metodología definida; los resultados hallados en cada fase de la metodología desarrollada; las conclusiones encontradas durante la realización del proyecto, las recomendaciones y trabajos futuros derivados de este proyecto. 14

15 1. PLANTEAMIENTO DEL PROBLEMA La integración de aplicaciones empresariales, por sus siglas en ingles EAI [16] (Enterprise Application Integration) es un término utilizado comercialmente para denominar los planes, métodos y herramientas utilizados para integrar y coordinar las aplicaciones en una empresa [1]. El constructor de aplicaciones empresariales en el proceso de análisis y diseño de integración de aplicaciones [3] para un caso específico de negocio, además de encontrarse con un conjunto genérico de posibles estrategias [16], arquitecturas y métodos de integración [4]; se encuentra también con un número importante de características propias de las aplicaciones de su negocio tales como: plataformas, lenguajes de programación, protocolos, motores de bases de datos, sistemas operativos y arquitecturas de aplicación [4] que le agregan complejidad a la elección de una opción de integración de aplicaciones. Ahora, si se piensa en que esa integración debe responder eficiente y efectivamente a las necesidades de los procesos de negocio, dadas en términos de los requerimientos no funcionales asociados a tiempos de respuesta e integridad de los datos, y que está condicionada por la tecnología, nivel de madurez y cultura propios del negocio; nos enfrentamos a un problema que no es trivial de resolver. El presente proyecto tiene como objetivo principal diseñar un método que entregue un conjunto de recomendaciones para realizar la integración de aplicaciones empresariales aplicables a un caso de negocio dado. Los objetivos específicos de este proyecto son: recopilar las diferentes estrategias, métodos y estilos de integración existentes para realizar la integración de aplicaciones empresariales; identificar las características más comunes a las aplicaciones presentes en las empresas; identificar los posibles valores que pueden tomar cada una de estas características; identificar las restricciones comunes presentes en las empresas; 15

16 identificar los posibles valores que pueden tomar cada una de estas restricciones; definir una taxonomía con la que se puedan clasificar, categorizar y/o tipificar los casos de negocio de aplicaciones empresariales; recopilar y seleccionar un conjunto de buenas prácticas de integración de aplicaciones, que apliquen a cada categoría; recopilar y seleccionar un conjunto de soluciones conocidas de integración de aplicaciones, que puedan aplicar a cada categoría; definir un conjunto de filtros, aplicables a la integración de aplicaciones, que permitan realizar la correcta caracterización de cada caso de negocio; probar y refinar el diseño del método aplicándolo a un conjunto de casos de negocio reales. 16

17 2. MARCO TEORICO En la actualidad es cada vez más común que las organizaciones usen paquetes de software para sus procesos de negocio principales, tales como Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Customer Relationship Management (CRM) y Electronic Commerce (EC). Estos les permiten a las empresas enfocarse en los sistemas de información (IS) que soportan su operación y metas financieras [12]. Sin embargo debido a la especialización de cada uno de estos paquetes de software, existen diferentes proveedores líderes que brindan soluciones específicas para cada una de estas necesidades; por lo tanto es muy común ver empresas que tienen al menos dos o más proveedores que satisfagan sus necesidades específicas en cada uno de sus procesos de negocio. Como resultado de la adquisición de estas herramientas o paquetes de software por parte de las empresas, y debido a los constantes cambios en los requerimientos del negocio para atender al mercado en el tiempo esperado, los cortos ciclos de vida de los productos y el aumento en la interdependencia con los socios de negocio [15], se hace entonces necesario que los procesos de negocio de las empresas deban amoldarse a dichos cambios para poder cubrir las necesidades de sus clientes, lo que implica que los sistemas que soportan estos procesos de negocio y sus interdependencias deban estar también cambiando. Por esto, es necesaria la interoperabilidad entre los distintos paquetes de software o aplicaciones de una empresa y además el intercambio de información con sus socios de negocio. Por lo tanto la integración de las aplicaciones y los procesos de negocio son una prioridad para las empresas en la actualidad [16]. No cabe duda que la integración entre aplicaciones sea una constante en el día a día de las grandes empresas, a tal punto que se encuentra involucrada incluso en los 17

18 paradigmas computacionales más actuales, como es el caso de la interoperabilidad de aplicaciones en la nube [14]. Esto evidencia que los procesos de integración seguirán siendo vigentes en el futuro de las empresas, por esta razón cada vez más las compañías buscan maneras para mejorar sus procesos de integración. Un ejemplo claro de esto se puede observar en la actualidad cuando se intentan mitigar los problemas de interoperabilidad entre los paquetes de software de una compañía, que como se ha hecho referencia en este mismo documento son normalmente heterogéneos, a través de la adquisición de software que provenga de un mismo proveedor, sin embargo, los resultados no han cumplido las expectativas y debido a eso muchas organizaciones están cambiando su estrategia a una que permita un rápido ensamble y desensamble de los procesos de negocio y de los correspondientes componentes de software [12]. Otra forma de resolver los problemas de integración, se da con la aparición de modelos de integración tal como el Modelo de Integración Empresarial (EMI) [15], que permite a través de un enfoque de meta-modelo orientado a objetos, la construcción de un lenguaje que describe un cierto dominio [15]. Además dicho modelo permite la reutilización de experiencias a través de la propuesta de patrones para el meta-modelo de integración [15]. Otra solución es el uso de un conjunto de patrones de integración empresariales, que son el resultado de años de trabajo por parte de expertos en la materia, con diferentes organizaciones en procesos de integración de aplicaciones empresariales [16, 20, 22]. Estos patrones brindan solución a un conjunto amplio de problemas de integración entre aplicaciones empresariales. Se debe tener en cuenta que las soluciones de integración son una tarea compleja, pues existe más de una solución posible, sin embargo saber si la solución definida es una buena opción, no se conocerá sino hasta muchos meses o aun años más tarde, cuando inevitablemente los cambios y la dinámica del negocio pongan a prueba la solución original [16]. 18

19 En la actualidad, la computación orientada a servicios aparece como un nuevo paradigma computacional fundamentado en buena parte en el paradigma orientado a objetos [6] y en la programación orientada a aspectos [7]. Se basa fundamentalmente en el concepto de servicio definido como un contenedor de capacidades que se compone de: un cuerpo de lógica que le permite llevar a cabo esas capacidades y un contrato que expresa cuales de estas capacidades están disponibles para ser usadas [21]. Uno de los elementos fundamentales en la computación orientada a servicios es la arquitectura orientada a servicios, SOA[21] por sus siglas en inglés, y dentro de SOA la integración tiene un lugar relevante, y es resaltada por Thomas Earl, como una parte importante, de alto perfil de la industria de las tecnologías de información [21]. Esto se debe a que prácticamente los servicios se construyen con la capacidad intrínseca de interactuar con múltiples consumidores y que prácticamente ninguno de ellos es conocido en el momento de su creación [21]. Con este concepto, SOA podría ser entonces la solución a los problemas de integración; sin embargo, esto es algo que solo se puede presentar cuando un porcentaje importante de los servicios de una organización está representado en un inventario de servicios de calidad [21]. Implementar SOA requiere tanto habilidades técnicas como habilidades organizacionales, lo que quiere decir que la implementación de SOA pasa las fronteras de lo técnico y comienza a ser un asunto organizacional [23]. Es por ello que el mismo Thomas Earl indica que mientras se trabaja hacia el logro de un inventario de servicios de calidad, es probable que existan muchos requisitos para la integración tradicional entre los sistemas heredados existentes, y también entre los sistemas heredados y sus servicios [21]. Los métodos desarrollados por los diferentes investigadores se enfocan como propuestas metodológicas que permiten evaluar la pertinencia o riesgos sobre las decisiones tomadas en el diseño de arquitecturas de aplicaciones. Ejemplo de ello es ATAM (Architecture Tradeoff Analysis Method), cuyo propósito es analizar un diseño de arquitectura y determinar si este diseño satisface los objetivos de calidad para los cuales fue 19

20 construido, determinando las posibles consecuencias o riesgos de esta decisión en función de los atributos de calidad definidos por los requisitos del sistema [8]. Otro ejemplo de un método para realizar el análisis de arquitecturas de software es SAAM (Software Architecture Analysis Method), evalúa las arquitecturas de software basándose en la adopción de escenarios como los medios mas descriptivos para especificar y evaluar los atributos de calidad, de esta manera SAAM plantea que los escenarios deben reflejar los tributos de calidad de interés y también mostrar la interacción entre las diferentes personas que utilizaran el sistema: usuarios finales, administrador, desarrolladores, etc. Cabe anotar que en este método, los escenarios son analizados desde tres perspectivas fundamentales: la perspectiva funcional, la perspectiva de estructura y la perspectiva de distribución o asignación [9]. Otros métodos de análisis de arquitecturas se enfocan en criterios específicos a evaluar, como la reutilización, o en la comparación de arquitecturas desarrolladas bajo diferentes paradigmas [10]. Sin embargo no se ha identificado métodos específicos que determinen un conjunto de pasos para encontrar posibles soluciones a un caso de integración de aplicaciones empresariales. Es aquí donde se fundamenta el objetivo del presente trabajo de investigación aplicada. 20

21 3. METODOLOGÍA La metodología definida para el desarrollo del proyecto se muestra en la Figura 1, se divide en tres (3) fases principales, a continuación se detalla las etapas y actividades de cada una de estas fases: Figura 1. Esquema de la metodología desarrollada. 3.1 Fase I, denominada Recopilación La fase de recopilación, como su nombre lo indica, esta fase se centra en la recopilación de información. Se divide en tres etapas, las actividades a realizar en cada etapa se detallan a continuación: 21

22 3.1.1 Etapa I Determinar el conjunto de variables con las que se puede caracterizar un caso de integración de aplicaciones Empresariales: En la cual el trabajo se orientará a la construcción de los siguientes entregables: Conjunto de estrategias, métodos y arquitecturas existentes para realizar la integración inter-aplicación de aplicaciones empresariales. Conjunto de las características más comunes a las aplicaciones presentes en las empresas con sus respectivos valores. Conjunto de las restricciones comunes presentes en las empresas con sus respectivos valores. En esta etapa se realizará la identificación de estos elementos en la literatura existente y se realiza la validación del uso de los mismos en el contexto de Santiago de Cali, a través de la elaboración de una encuesta Etapa II Determinar el conjunto de soluciones conocidas aplicables a un caso de integración de aplicaciones empresariales: el cual se realizará con la revisión de la literatura existente Etapa III Determinar el conjunto de buenas prácticas aplicables a un caso de integración de aplicaciones empresariales: para esta recopilación se hace uso de entrevistas con expertos y revisión de la literatura existente. 3.2 Fase II, denominada Diseño En esta fase el trabajo se centrará en el diseño del método, teniendo como insumos los entregables de la fase de Recopilación, Fase I; los entregables de esta fase son descritos en las siguientes etapas: 22

23 3.2.1 Etapa I Definición de categorías: Para esta actividad el entregable será la taxonomía en la que se puedan clasificar, categorizar o tipificar los casos de negocio de integración de aplicaciones empresariales Etapa II Definición de soluciones conocidas aplicables por categoría: Para esta actividad el entregable será el conjunto de soluciones conocidas aplicables a cada categoría definida en la Etapa I Etapa III Definición de buenas prácticas aplicables por categoría: Para esta actividad el entregable será el conjunto de buenas prácticas o reglas aplicables a cada categoría definida en la Etapa I Etapa IV Definición de Filtros: Para esta actividad el entregable será el conjunto de filtros y el orden en el que se deben aplicar en el proceso de caracterización, estos filtros se construyen para garantizar la coherencia de los valores de las variables con las que se caracteriza el caso de negocio, compatibilidad y complemento de las mismas, y con ello garantizar que la categoría en la que se clasificará el caso de negocio, objeto de la aplicación del método diseñado, sea correcta Etapa V Con la recopilación de las etapas anteriores se realizará la definición de los pasos del método. En esta fase las definiciones se realizarán teniendo como insumo principal la recopilación de la literatura y entrevistas con expertos realizada en la Fase I. 3.3 Fase III, denominada Aplicación En esta fase se pondrá a prueba el diseño del método definido en la fase de Diseño (Fase II). Y comprende las siguientes actividades: 23

24 3.3.1 Etapa I Definición de criterios para determinar la pertinencia de la(s) recomendación(es) entregada(s) por el método frente a la caracterización del caso de negocio Etapa II Aplicación y refinamiento del método diseñado. En esta fase se trabajará aplicando el método diseñado en la Fase II (Fase de diseño), a casos de integración de aplicaciones empresariales, que se han presentado en los proyectos de construcción de aplicaciones realizados en los dos últimos años en el Grupo Empresarial Coomeva. La pertinencia de las recomendaciones entregadas por el diseño del método será determinada por los criterios definidos en la Etapa I de esta fase. 24

25 4. RESULTADOS Conforme a lo establecido en la metodología definida para el desarrollo del proyecto, se llevaron a cabo las actividades de las tres (3) fases, los resultados de estas actividades se mostraran a continuación: 4.1 Fase I Recopilación de información La fase de recopilación de información consistió, como su nombre lo indica, en un proceso de recolección de información sobre la integración de aplicaciones empresariales, el cual se orientó en la elaboración de seis (6) conjuntos; cuatro (4) de los cuales representan el dominio de las entradas al método que se va a diseñar que corresponden a los conjuntos de variables con las cuales se puede caracterizar un caso de negocio. Y dos (2) más que son el engranaje fundamental del método y que corresponden al conjunto de soluciones conocidas y el conjunto de buenas prácticas respectivamente Etapa I Determinar conjunto de variables El propósito de esta etapa es determinar el conjunto de variables con las que se puede caracterizar un caso de integración de aplicaciones Empresariales: Estos elementos tienen la característica principal de influenciar la integración de aplicaciones empresariales y ser decisivos al momento de analizar un caso de integración de aplicaciones empresariales. Para la elaboración de estos cuatro (4) conjuntos fue necesario la ejecución de dos (2) actividades: La revisión de la literatura existente y la realización y análisis de resultados de la encuesta Revisión de la literatura existente Como se mencionó anteriormente, el propósito de esta revisión se orientó en la elaboración de cuatro (4) conjuntos que fueron identificados durante la revisión de la literatura, durante la cual se reconocieron dos textos principales [16, 18] y un 25

26 grupo de artículos [4, 5, 11, 12, 13, 14]; a partir de los cuales se logró establecer una serie de elementos que se agruparon como se muestra a continuación: Necesidades de integración La principal característica de este primer grupo es que reúne los elementos que motivan la integración de aplicaciones empresariales. En otras palabras, es el porqué y el para qué se integran las aplicaciones empresariales. Los elementos de este grupo se describen a continuación: Transferencia de archivos: El sistema necesitará producir archivos para compartir datos o necesitará consumir archivos que otros producen. Bases de datos compartidas: El sistema necesitará almacenar o extraer datos de una base de datos externa al sistema, que ha sido compartida a través de mecanismos propios del motor de base de datos. Invocación remota de procedimientos: El sistema necesitará exponer algunos de sus procedimientos para que sean invocados remotamente o deberá invocar procedimientos para dar inicio a un proceso e intercambiar datos. Mensajería: El sistema necesitará usar un Middleware de mensajería para el intercambio de datos o para inducir eventos en otros sistemas o subsistemas Criterios de Integración Este segundo grupo contiene los elementos que marcan los criterios a tener en cuenta en el momento en que son tomadas las decisiones de integración y las restricciones que se pueden presentar durante esta toma de decisiones: Intrusión: Cuando el enfoque por el menor impacto, es decir reducir al mínimo los cambios o la cantidad de código de integración no pueden proporcionar la mejor solución de integración en la empresa. 26

27 Selección de la tecnología: Cuando se requiere del uso de software y hardware especializado para llevar a cabo la solución de integración, pues el hecho de construir la solución desde cero, puede resultar en un mayor esfuerzo de lo previsto inicialmente y puede significar volver a hacer parcial o totalmente algo que ya existe, es decir reinventar la rueda. Formato de los datos: Se presenta cuando aparece alguno de estas situaciones: Utilizar un formato de datos común para la integración de las aplicaciones. Modificar la aplicación para usar un formato de datos común. Utilizar un traductor o mediador que homologue los formatos de los datos. Usar un formato de datos extensible en el tiempo. Latencia en el intercambio de datos: Se presenta cuando se requiere que: La información compartida entre aplicaciones debe estar disponible para el receptor tan pronto el emisor la haya generado totalmente, es decir que el receptor nunca recibirá parcialmente la información. La información compartida entre aplicaciones estará disponible desde el momento en que el emisor la esté generando, es decir el receptor podrá recibir la información a medida que esta se vaya generando por el emisor, esto implica el envió de información fragmentada y se hace compleja su sincronización. Datos o Funcionalidad: Se presenta cuando: La integración permitirá a las aplicaciones compartir solo datos. 27

28 La integración permitirá compartir funcionalidades en vez de simplemente datos. Comunicación Remota: Se presenta cuando se desea establecer comunicación con aplicaciones que no se encuentran en la misma instancia de sistema operativo de la aplicación que tiene la intención del llamado. En este caso la comunicación con las aplicaciones puede ser simplemente síncrona o asíncrona. Esta última implica mayor complejidad en el diseño, desarrollo y depuración. Confiabilidad: Se presenta cuando por ejemplo una solución de integración permitirá la comunicación asíncrona entre dos o mas aplicaciones, garantizando que en el momento que el emisor solicite una funcionalidad, esta se realizara cuando el receptor esté disponible Tipos de aplicaciones. El tercer grupo describe los tipos de aplicaciones empresariales, enfocándose en el manejo de los eventos y los tipos de datos que procesan. La clasificación adoptada para este grupo está definida en [31] y se seleccionó para el desarrollo de este trabajo de grado debido a que es la que más se aproxima al contexto empresarial en el que se va a trabajar el proyecto, tanto para la aplicación de la encuesta como para la caracterización y análisis de los casos de negocio además se ajusta a los tipos de escenarios cubiertos por los Frameworks de integración más comunes del mercado [30,31,33]. Batch: No procesan eventos. Transaccionales 1: Procesan eventos en la medida que ocurren. 28

29 Procesan eventos de los usuarios que se conectan vía interfaz de usuario. Deben estar disponibles. No manejan tipos de datos complejos. Transaccionales 2: Procesan eventos en la medida que ocurren. Procesan eventos de los usuarios que se conectan vía interfaz de usuario. Deben estar disponibles. Cliente servidor: Procesan eventos en la medida que ocurren. Procesan eventos de los usuarios que se conectan vía interfaz de usuario. Deben estar disponibles. Manejan tipos de datos complejos. Procesamiento importante en el cliente. Web: Manejan tipos de datos complejos. Procesamiento importante en el cliente. Procesan eventos en la medida que ocurren. Procesan eventos de los usuarios que se conectan vía interfaz de usuario. Deben estar disponibles. Manejan tipos de datos complejos. Sin procesamiento en el cliente. Tiempo Real: Procesan eventos en el instante que ocurren Paquetes de Software: Adquiridos y/o fabricados por terceros y proveen mecanismos de integración predefinidos desde el fabricante. 29

30 Características de calidad: En este cuarto grupo se consideraron las características de calidad, no para las aplicaciones a integrar; sino de la solución de integración. Para el desarrollo de este proyecto se seleccionó el marco de trabajo de las características de calidad de acuerdo con la norma ISO/EIC [2,19]. Esta selección se realizó teniendo en cuenta que es el marco con el que los investigadores han venido trabajando durante el proceso de formación profesional y es el marco con el que está más familiarizado el contexto empresarial en el que se va a aplicar la encuesta. Las características de calidad conforme al marco seleccionado se definen como sigue: Funcionalidad: Grado al cual un producto software provee las funciones que satisfacen las necesidades explícitas e implícitas cuando el software se utiliza bajo condiciones específicas Seguridad: La protección del sistema de accesos maliciosos o accidentales, uso, modificación, destrucción o divulgación. Capacidad de transferencia: Grado en el cual un producto software puede ser transferido de un ambiente a otro. Fiabilidad: Grado de un producto de software para mantener un nivel específico de funcionamiento cuando se está utilizando bajo condiciones especificadas. Capacidad de operación: Grado al cual un producto software puede ser entendido, aprendido, usado y atractivo al usuario, cuando es utilizado bajo las condiciones especificadas. Eficiencia de rendimiento: Grado al cual un producto software provee un rendimiento adecuado, de acuerdo con la cantidad de recursos utilizados y bajo las condiciones planteadas Compatibilidad: La capacidad de dos o más componentes software para el intercambio de información y/o para cumplir con sus funciones, Compartiendo el mismo hardware o el entorno de software. 30

31 Capacidad de mantenimiento: Grado en el cual un producto software puede ser modificado. Las modificaciones pueden incluir correcciones, mejoras o adaptación del software a cambios en el entorno, y especificaciones de requisitos y funcionalidades Encuesta Una vez revisada la literatura existente y luego de recopilar y agrupar los diferentes elementos ahí presentados; se procedió a trabajar con la segunda herramienta, que consistió en la elaboración y análisis de resultados de una encuesta realizada a veintiuno (21) voluntarios que trabajan o han trabajado en proyectos de integración de aplicaciones empresariales. Los objetivos de esta encuesta fueron: Someter a calificación (entre 1 y 5) cada uno de los elementos recopilados, en la revisión de la literatura, de acuerdo al nivel influencia de estos elementos en la integración de aplicaciones empresariales. Recolectar información sobre los métodos que se emplean actualmente. Identificar las tecnologías en las que están construidas las aplicaciones empresariales con las que se trabajan en proyectos de integración en las empresas de Santiago de Cali. Los resultados obtenidos para cada uno de los objetivos de la encuesta se muestran a continuación: Todos los elementos recopilados en la literatura, fueron calificados con algún grado de influencia y todos se usan con mayor a menor frecuencia dentro de los proyectos que han realizado los encuestados. Por lo tanto todos los elementos recopilados en la literatura van a ser utilizados como entradas al método para realizar la caracterización de los casos de negocio. No aparecieron nuevos elementos, necesidades, criterios, restricciones, características de calidad y de las aplicaciones, a incluir en el conjunto de elementos ya recopilados. 31

32 Solo uno de los encuestados respondió afirmativamente a la pregunta de si conocía un método que le permitiera identificar la mejor opción de integración dentro de un grupo de casos de integración de aplicaciones empresariales. Sin embargo el método descrito por el encuestado es más una descripción de un conjunto de actividades en orden lógico usado a nivel personal para resolver casos de integración; que un método formalmente descrito y referenciado. Se logró identificar las tecnologías en las que están construidas las aplicaciones empresariales (bases de datos, lenguajes de programación y sistemas operativos) en las que han trabajado los encuestados y se identificó que corresponde a un conjunto amplio de distintas tecnologías y fabricantes; incluso dentro de una misma empresa. Estos resultados se presentan de manera gráfica y detallada en el Anexo 1 Resultados de la encuesta Etapa II Determinar conjunto de soluciones conocidas El resultado del trabajo realizado en esta etapa de la metodología, básicamente se resume en el uso de los estilos de integración definidos en [16] como soluciones conocidas, dado que en la actualidad son las más utilizadas dentro de la bibliografía sobre la que se basa este documento. A continuación se profundiza sobre cada uno de estos estilos: Transferencia de archivos Figura 2. Transferencia de archivos [16]. 32

33 Esta solución se basa en el estilo de integración que lleva su mismo nombre (File Transfer) [16]. Cuando se usa la transferencia de archivos como solución a un problema de integración, una aplicación simplemente escribe los datos que desea compartir con otras aplicaciones dentro de un archivo, en un sistema de archivos, desde donde otras aplicaciones puedan leerlo y procesarlo. En este punto los encargados de los proceso de integración tienen la responsabilidad de transformar los archivos en diferentes formatos en caso que las aplicaciones destino así lo requieran. Como también de identificar los intervalos de producción de dichos archivos de acuerdo a la naturaleza del negocio. Recomendación: En caso que sea necesario tener la información con una periodicidad mayor a la que la aplicación productora puede generar, o en el caso que sea necesario realizar más transformaciones para realizar la integración con nuevos sistemas, se recomienda usar una solución con estilo de bases de datos compartidas. O en el caso que los periodos de frecuencia hayan disminuido y esto redunde en intercambios de información muy pequeños comparados con los identificados en el diseño de la solución original, se recomienda el uso del estilo de mensajería Bases de datos compartidas Figura 3. Bases de datos compartidas [16]. 33

34 Las bases de datos compartidas, al igual que la solución de transferencia de archivos, se basa en un estilo de integración, en este caso se basa en el estilo de integración de base de datos compartida (Shared Database) [16]. Cuando se utiliza este estilo como solución a un problema de integración, se usa una base de datos la cual es compartida por todas las aplicaciones que participaran en la solución, de esta manera todas las aplicaciones que comparten su información tienen la posibilidad de ver la información más actualizada y sin inconsistencias, a diferencia de la solución de trasferencia de archivos. Sin embargo para lograr esto, se requiere de un trabajo extenso, por parte de los integradores, los responsables de las aplicaciones y el administrador de la base de datos, pues deberá diseñarse el esquema de base de datos que satisfaga las necesidades de cada una de las aplicaciones involucradas y lo mantenga consistente, además de las políticas que limitaran el rango de acción y visibilidad a cada aplicación, a solo lo necesario, de tal manera que se disminuya el riesgo de deadlocks y por ende cuellos de botella que generen problemas de acceso o hasta la falta de disponibilidad del servicio. Recomendación: En caso que sea necesario integrar la funcionalidad y ya no los datos, se sugiere el uso del estilo de integración de procedimientos almacenados, o en caso que las aplicaciones deseen intercambiar información en pequeñas cantidades de datos, entre ellas y ya no a través de un esquema universal, se sugiere el uso del estilo de integración de mensajería. 34

35 Invocación remota de procedimientos Figura 4. Invocación remota de procedimientos [16]. En esta solución, al contrario del estilo de integración de bases de datos compartidas, no son los datos, si no la funcionalidad la que se comparte con las demás aplicaciones. Esto se logra a través del llamado de los métodos de las aplicaciones remotas, los cuales previamente han sido publicados por la aplicación remota y son accesibles por las aplicaciones cliente. Este tipo de soluciones, lucen muy agradables para los desarrolladores, debido a que esta permite llamar los métodos de aplicaciones externas, de la misma manera como se hace con los métodos locales. Sin embargo esto puede generar inconvenientes, pues al invocar un método remoto, este no se comporta de la misma manera que uno local y por esta razón pueden generarse errores inesperados. Estos pueden deberse a fallas en la red, lo cual evita que el método pueda ser invocado, o que la aplicación propietaria del método remoto no se encuentra disponible en este momento. Finalmente otro aspecto a tener en cuenta en esta solución es la modificación de dichos métodos, pues mientras no se alteren las firmas de dichos métodos no habrán problemas, pero en caso de necesitarlo, es necesario informar a los administradores de las aplicaciones clientes, quienes deben hacer los cambios necesarios para que las invocaciones 35

36 tengan en cuenta dichas modificaciones, pues de lo contrario se producirá un error al intentar llamar el método con los parámetros equivocados. Recomendación: En caso que se necesitara hacer llamados asíncronos a las aplicaciones, y/o de buscar un menor acoplamiento entre las aplicaciones a integrar, se sugiere el uso de mensajería como solución a estos nuevos requerimientos de integración Mensajería Figura 5. Mensajería [16]. La mensajería es una tecnología que permite a dos aplicaciones su comunicación de manera confiable, asíncrona y con alto rendimiento. Al utilizar esta tecnóloga las aplicaciones se comunican a través de canales enviándose paquetes de datos denominados mensajes, como se muestra en la Figura 5. Un canal funciona como una colección de mensajes que puede ser compartido por múltiples aplicaciones y utilizado concurrentemente. Las aplicaciones actúan con roles bien definidos en la comunicación: productor y consumidor. Un productor (o emisor) es una aplicación que envía mensajes escribiéndolos en un canal, mientras que un consumidor (o receptor) es una aplicación que recibe los mensajes leyéndolos del canal. En un esquema de este tipo tanto productor como consumidor no tienen que estar necesariamente disponibles al mismo tiempo para poder comunicarse. Esto se debe a que la comunicación en sí misma es llevada a cabo a través de los 36

37 denominados sistemas de mensajería. Figura 6. Aplicaciones comunicadas usando mensajería. Sistemas de mensajería Las capacidades de mensajería son típicamente provistas por sistemas de software denominados sistema de mensajería o Message Oriented Middleware (MOM). Los MOMs son componentes especializados en el manejo de mensajes. Su fin principal es participar como intermediario entre la comunicación de aplicaciones, logrando desacoplarlas. Las aplicaciones se comunican con los sistemas de mensajería a través de clientes provistos por los proveedores de MOMs. Estos brindan interfaces mediante las cuales las aplicaciones pueden enviar y recibir mensajes como se ilustra en la Figura 7. Figura 7. Comunicación basada en mensajería a través de un MOM. 37

38 Debido a que tanto los equipos como las redes que los conectan no son cien por ciento seguros y confiables, hace relevante la existencia de los MOMs. Por ejemplo, puede que no siempre que se envíe un mensaje el destinatario esté activo y disponible, o en caso de que lo esté, podría ser que la red de comunicación presente no disponibilidad. Previo a la aparición de los MOMs, para atacar este tipo de problemática se implementaba manualmente la retransmisión de mensajes hasta asegurarse que el receptor los había procesado. Esto hacía que cada vez que se deseaba usar mensajería se debieran afrontar una y otra vez los mismos problemas. Como respuesta a esto, surgen los sistemas de mensajería, que permiten a quien envía un mensaje olvidarse del mismo luego del envío, delegando al sistema de mensajería la responsabilidad de asegurar la entrega del mensaje a su destinatario. A continuación se enumeran los componentes de un sistema de mensajería así como su responsabilidad según [16]: Canales: Son direcciones lógicas en el sistema de mensajería a las cuales las aplicaciones hacen referencia, y es donde colocan los mensajes para ser entregados. Mensajes: Son las entidades que transporta el sistema de mensajería. Puntos de acceso (endpoints): Es el punto de entrada al sistema de mensajería. Para poder acceder a un canal, las aplicaciones tienen que conectarse al sistema de mensajería, y dicha conexión se da a través de un endpoint. Tubos y filtros (pipes and filters): Son los componentes encargados de procesar mensajes complejos en varios pasos de forma flexible. Enrutador de mensajes (message router): Cuando un mensaje debe ser procesado pasando por varios destinos, o tiene que seguir cierta ruta óptima, los enrutadores de mensajes se encargan de tal problemática independizando a las aplicaciones de este manejo. 38

39 Componentes de transformación de mensajes: Estos componentes son filtros particulares que se encargan de realizar transformaciones para poder comunicar aplicaciones que utilizan formatos de mensaje diferentes. Proceso de transmisión: El proceso de transmisión de los mensajes es el proceso más relevante para un sistema de mensajería y este se descompone en cinco pasos: Crear: El emisor crea un mensaje y coloca en el los datos que desea transmitir. Enviar: El emisor coloca el mensaje en un canal. Entregar: El sistema de mensajería transporta el mensaje logrando que este esté disponible para el receptor. Recibir: El receptor lee el mensaje desde el canal. Procesar: El receptor extrae los datos del mensaje. Figura 8. Transmisión de mensajes paso a paso [16]. En la Figura 8, se muestran los pasos descritos anteriormente, además se puede apreciar la aplicación de los conceptos: Send and Forget y Store and Forward. Estos se dan en los pasos 2 y 3 respectivamente. Observando el paso 2, se puede ver que una vez que la aplicación entrega el mensaje en el canal, puede seguir 39

40 ejecutando dado que esta delegó la entrega del mensaje al sistema de mensajería. La aplicación confiará en que el receptor recibirá el mensaje, y no esperará hasta que esto ocurra. En el paso 2, en el momento que la aplicación entrega el mensaje en el canal, el sistema de mensajería lo almacena. Luego en el paso 3, el sistema de mensajería entrega el mensaje redirigiéndolo a la computadora destinataria en la que es nuevamente almacenado. Este proceso puede ser repetido varias veces hasta que el mensaje se persista en la máquina destino. Modelos de comunicación: generalmente los sistemas de mensajería soportan alguno de estos modelos de comunicación: Point-to-Point: Este modelo es basado en canales punto a punto. Cuando una aplicación produce un mensaje, lo coloca en un canal de este tipo y un receptor recibirá el mensaje. A este tipo de canales se pueden suscribir varios interesados en recibir mensajes, pero sólo uno obtendrá cada mensaje. El sistema de mensajería se encargara de determinar cuál de los destinatarios subscritos obtendrá el mensaje. Publish-Subscribe: Este modelo permite que una aplicación varios destinatarios simultáneamente. Para esto, las aplicaciones colocan los mensajes en un canal que corresponde a cierto tópico definido, el cual tiene el siguiente comportamiento: los interesados en recibir mensajes del tópico se suscriben al mismo, el emisor coloca el mensaje en el canal, y una copia del mismo será entregada a cada uno de los subscritos al mismo. Características y servicios de un MOM: en general, los MOMs brindan varias de las características y servicios que se describen a continuación: Garantía de Entrega de mensajes: dos aplicaciones que se están comunicando mediante un MOM no necesitan estar conectadas 40

41 simultáneamente para que el envío de los mensajes sea exitoso. El MOM asegura que los mensajes enviados a un destinatario que no esté conectado, serán entregados al mismo cuando este vuelva a estarlo. Comunicación Asíncrona: luego que una aplicación envía un mensaje a otra, el MOM permite que la aplicación cliente siga trabajando sin tener que esperar que el mensaje sea procesado por el destinatario del mismo. Soporte transaccional: el uso de transacciones es soportado, y además en general se proveen mecanismos de integración con otros recursos, de forma que las transacciones contra el MOM se puedan incorporar a transacciones globales. Entrega en orden, y una sola vez: un MOM garantiza que los mensajes serán entregados una sola vez, y que además los mismos serán entregados respetando el orden en que fueron enviados. Servicios de ruteo de mensajes: permiten definir reglas de ruteo a nivel de configuración mediante las cuales al enviar un mensaje a un determinado canal, los mismos son enrutados según las configuraciones indicadas. Servicios de notificación: en algunos casos las aplicaciones que envían los mensajes necesitan tener una forma de saber si el mensaje enviado ya fue procesado por el consumidor u obtener el resultado generado en este. Para esto, los MOM s proveen mecanismos de notificación, de forma que al ser procesado el mensaje por su receptor se pueda entregar el resultado de este procesamiento al productor del mismo. Después de conocer los conceptos básicos y los elementos que componen un sistema de mensajería, se procederá a la explicación de los patrones de integración empresarial y su categorización. 41

42 Los patrones de integración empresarial fueron descritos por primera vez en la conferencia de Patrones de Lenguaje de Programación [27], en el año 2002 por Gregor Hohpe [26]. Dichos patrones, son una evolución de los patrones de diseño de software tradicionales, a un contexto especifico, como lo es la integración de aplicaciones empresariales. Estos patrones representan las decisiones que deberán tomarse al momento de integrar dos o más aplicaciones en un contexto empresarial y las consideraciones que implica tomar esas decisiones. En la actualidad, se consideran 65 patrones de integración empresarial [16], cuyo planteamiento se basa en la mensajería asíncrona como piedra angular para la integración. A continuación se describen las categorías que componen estos patrones y que parte del problema de comunicación dentro de la mensajería solucionan Categorización de Patrones de Integración Empresarial Los patrones de integración empresarial han sido agrupados en seis (6) categorías [16], como se muestra en la Figura 9, las cuales reflejan el alcance (scope) y la abstracción de los patrones. Resolviendo de esta manera una situación específica dentro del proceso de integración. 42

43 Figura 9. Categorización de Patrones de integración empresarial [16]. Patrones de canal del mensaje Estos patrones describen los aspectos que deben ser tenidos en cuenta a la hora de escoger el canal de comunicación entre las aplicaciones, cuando se desea integrar dos o más sistemas de software. Por lo tanto estos patrones resuelven distintos problemas de transporte de los mensajes entre aplicaciones. Por ejemplo, las aplicaciones que envían información por un canal no tienen por qué conocer cuál es el receptor final de los datos que produce, sin embargo seleccionando un canal en particular el productor puede asegurarse que quien reciba la información es quien la esperaba. Apuntan a especificar características de los canales de comunicación a utilizar, como por ejemplo: si el mensaje es enviado a uno o a muchos receptores, garantía de entrega de los mensajes que se transportan por el canal, expiración de los mensajes enviados al canal, entre otros. Los patrones que integran la categoría son: 43

44 Point-to-Point Channel. Publish-Subscribe Channel. Datatype Channel. Invalid Message Channel. Dead Letter Channel. Guaranteed Delivery. Channel Adapter. Messaging Bridge. Message Bus. Patrones de construcción del mensaje Estos patrones, contemplan los aspectos que se encargan de envolver los datos de interés en un mensaje, para que pueda ser transmitido a través de los canales, que llevaran la información hacia los interesados en el mensaje. De esta manera abordan el diseño de los mensajes que envían los diferentes participantes de una comunicación. Por ejemplo, en el intercambio que se realiza entre dos aplicaciones, la información se envía insertándola en un mensaje. Apuntan a especificar la información que contienen los mensajes, su semántica, información adicional para permitir su procesamiento adecuado, entre otros. Los patrones que integran esta categoría son: Command Message. Document Message. Event Message. Request-Reply. Return Address. Correlation Identifier. Message Sequence. 44

45 Message Expiration. Format Indicator. Patrones de enrutamiento del mensaje Estos patrones, describen las distintas soluciones para proveer enrutamiento e intermediación para una solución de integración. Dichos patrones están relacionados con el ruteo de los mensajes desde una aplicación a otra. Por ejemplo, permiten desacoplar los componentes que realizan en conjunto el procesamiento en etapas de determinada información, logrando que la secuencia de pasos a realizar dependa de un conjunto de condiciones. Apuntan a la configuración de rutas por las que deben pasar los mensajes para su procesamiento, independizando a quien envía o recibe los mensajes de esta lógica. Cabe anotar que muchos de los patrones agrupados en esta categoría son refinamientos o combinaciones del patrón Message Router [16]. Los patrones que componen esta categoría son: Content-Based Router. Message Filter. Dynamic Router. Recipient List. Splitter. Aggregator. Resequencer. Composed Message Processor. Scatter-Gather. Routing Slip. Process Manager. Message Broker. 45

46 Patrones de transformación del mensaje Estos patrones, identifican y dan solución a las diferentes situaciones que generalmente se presentan cuando se tiene la necesidad de operar entre sistemas que usan diferentes formatos, por lo tanto estos patrones permiten definir el manejo de transformaciones que pueden realizarse sobre los mensajes que se intercambian, en lo que refiere a los diferentes formatos requeridos por cada aplicación. Así como también modificaciones automáticas que se realizan sobre los mensajes. Los patrones que integran esta categoría son: Message Translator. Envelope Wrapper. Content Enricher. Content Filter. Claim Check. Normalizer. Canonical Data Model. Patrones de puntos de acceso (EndPoint) Estos patrones, describen cómo las aplicaciones involucradas en la integración, pueden conectarse al sistema de mensajería, para que puedan enviar y recibir mensajes. Es decir estos patrones entregan pautas relacionadas a la generación y el consumo de mensajes, especificando por ejemplo como un productor puede interactuar con el canal para producir un mensaje o como un receptor puede comportarse ante la ocurrencia de un nuevo mensaje. Los patrones que integran la categoría son: Message Endpoint. Messaging Gateway. Messaging Mapper. Transactional Client. 46

47 Polling Consumer. Event-Driven Consumer. Competing Consumers. Message Dispatcher. Selective Consumer. Durable Subscriber. Idempotent Receiver. Service Activator. Patrones de gestión del sistema Indican cómo atacar las necesidades de administración, monitoreo y testeo de los componentes del sistema y de los canales de comunicación. Un claro ejemplo de esto es la necesidad de extraer información sobre los datos que circulan por los canales, con el fin de monitorear cual es la capacidad de procesamiento del sistema en general y poder así detectar caídas en el rendimiento. Los patrones que integran la categoría son: Control Bus. Detour. Wire Tap. Message History. Message Store. Smart Proxy. Test Message. Channel Purger. La solución de mensajería, está asociada al estilo de integración empresarial de mensajería (Messaging) [16]. Cuando este estilo es usado como solución a un problema de integración, es necesario una infraestructura de mensajería, que 47

48 además de proveer el canal de comunicación entre la aplicación emisor y destino involucradas en la integración, provea los mecanismos de reintentos necesarios para que los mensajes enviados entre las aplicaciones, sean entregados y no se pierdan, además en caso que la aplicación receptor no se encuentre disponible, la infraestructura deberá estar en la capacidad de almacenar los mensajes enviados en un datastore, y entregarlos a su receptor cuando este se encuentre de nuevo disponible. Claramente se observa que este tipo de soluciones, están soportadas por infraestructuras que promueven la fiabilidad de la comunicación, además de un esquema de comunicación asíncrona entre las aplicaciones involucradas en el proceso de integración, lo que a su vez permite que las soluciones de integración puedan cada vez mas tener un comportamiento más parecido a la naturaleza de los negocios, pues es posible modelar los eventos de negocio necesarios para la ejecución de los procesos internos y la de aquellos que requieran de la comunicación de otras aplicaciones con las que se desea integrar. Recomendación: Después de tomar la decisión que la solución escogida será el estilo de integración de mensajería, se sugiere tener en cuenta, estas mínimas consideraciones: Debe definirse un canal o Message Channel, el cual se utilizara como medio de comunicación del mensaje. A donde deben ser enviados los mensajes. Qué tipo de formato utilizar para el mensaje. Implementar un traductor para desacoplar las aplicaciones a integrar. Conectar las aplicaciones a la infraestructura de mensajería por medio de un Message Endpoint. 48

49 La búsqueda de las soluciones conocidas permitió refinar las variables de entrada al método definidas en el grupo de necesidades encontrando que mas que necesidades estos cuatro (4) estilos de integración son soluciones y básicamente las necesidades se pueden clasificar como: compartir datos y compartir funcionalidad Etapa III Determinar el conjunto de buenas prácticas El objetivo de la etapa es determinar el conjunto de buenas prácticas aplicables a la integración de aplicaciones empresariales, basado en la recopilación a través de la consulta directa a un grupo de expertos y recopilación de información en la literatura existente. El resultado del trabajo realizado se detalla a continuación Consulta a expertos La selección de los miembros de este grupo se realizó fundamentalmente porque son personas con una trayectoria que supera los 5 años en la construcción de importantes proyectos de integración de aplicaciones empresariales, definición de estándares y mecanismos de integración de las aplicaciones del core de los negocios para las empresas en que ellos trabajan. Al consultar las buenas prácticas, que estos expertos aplican en su trabajo diario, se observó que las respuestas se enfocaban a cada una de las necesidades de integración que se identificaron en la caracterización de los casos de negocio. En la mayoría de los casos los expertos resaltaron los pros y los contras de la buena práctica. Por lo anterior la descripción de estas buenas prácticas, se hace agrupada por cada una de las necesidades de integración y se identifican las ventajas y desventajas de utilizarla: 49

50 Datos Para la necesidad de integración compartir datos, las buenas prácticas, entregadas por el grupo de expertos, se resume a continuación: Uso de formato: por estándar, a nivel mundial el formato de los archivos para hacer integración debe ser XML. Las ventajas están en la facilidad para realizar las validaciones de los datos a través del uso de XSD o DTD, en la facilidad que tienen para ser leídas por parte de los humanos y rapidez con la que son validados por las maquinas. La desventaja está en el tamaño de los archivos, los archivos en formato XML siempre son de mayor tamaño que los archivos de otros formatos; esto se debe a que la meta-data está inmersa en los archivos. Generación de archivos: la recomendación entregada en este sentido es que los archivos deben ser generados por los sistemas dueños de los datos, en lugar que la aplicación destino o una tercera aplicación, genere el archivo ingresando a los datos de la aplicación origen. Transporte: para este propósito existen en el mercado herramientas que utilizan como medio de transporte protocolos especializados como son: FTP, SFTP o SCP. El uso de buses de servicios no se recomienda para realizar el transporte de archivos. Bases de datos: Como buenas prácticas en el caso cuando existe la misma entidad de base de datos en ambos sistema se recomienda: Realizar sincronización con replicación. Definir las políticas de sincronización como por ejemplo la periodicidad. Utilizar en lo posible los tipos de datos nativos del motor de base de datos. 50

51 Definir un buen gobierno de datos. Quien es el dueño de los datos. Si están en la misma instancia se debe usar sincronización en línea ya que no es necesario hacer uso de la red de datos. La práctica más usada y recomendada por los expertos es utilizar gatillos, también conocidos por la palabra en inglés trigers, siempre y cuando se tengan bien establecidos los accesos y permisos sobre las tablas. Si están diferente instancias se recomienda crear una tabla temporal de trabajo, para posteriormente, a través de un proceso asíncrono, realizar la integración Funcionalidades Para la necesidad de integración compartir funcionalidad, las buenas prácticas, entregadas por el grupo de expertos, se resume a continuación: Mecanismo de exposición: para realizar la exposición de funcionalidades el estándar adoptado por la industria son los servicios web usando SOAP o Restful. Consulta de información: Los servicios web son muy útiles para consumir lógica de negocio de otras aplicaciones, sin embargo si los servicios retornan bloques de datos mayores de 5MB, los servicios web no son recomendados. Para retornar bloques de resultados de más de 5MB es mejor usar protocolos binarios tales como RMI-IIOP, DCOM o RPC. Llamado a procedimientos: es el mecanismo recomendado para realizar la invocación de funcionalidades de forma síncrona. 51

52 Datos y funcionalidades El grupo de expertos entregó un conjunto de buenas prácticas aplicables a las necesidades compartir datos y compartir funcionalidad, las cuales se describen a continuación: Los sistemas de mensajería entre aplicaciones Message Oriented Middleware son el mejor mecanismo asíncrono de integración en las aplicaciones empresariales. El principal problema de este mecanismo es que los protocolos no son abiertos y cada proveedor tiene su mecanismo propietario de integración. Formato de los mensajes: Si la integración es entre sistemas que tienen el soporte nativo para el MOM lo mejor es usar mensajes binarios y no mensajes en modo texto. Si la integración es entre sistemas que no tiene soporte nativo para MOM, se deben usar mensajes de texto en formato XML o JSON. Mecanismo de entrega de los mensajes: para entrega del mismo mensaje desde una aplicación hacia diferentes aplicaciones se debe usar Publish and Subscribe. Para la entrega de mensajes solo entre dos aplicaciones, no se conoce en el mediano plazo la inclusión de otras aplicaciones interesadas en consumir este mensaje, se debe usar Point to Point Buenas prácticas extraídas de la literatura En la revisión de la literatura se encontraron las siguientes buenas prácticas o recomendaciones para cada una de los estilos de integración: Buenas prácticas para la transferencia de archivos La transferencia de archivos, ha sido una de las tecnologías comúnmente más utilizadas en el mundo, por las empresas de TI para intercambiar información [29], 52

53 Sin embargo la complejidad de los negocios y la necesidad continua de tener respuestas con tiempos cada vez más ajustados a las necesidades reales, han desplazado a los antiguos procesos en batch, que comúnmente se ejecutan fuera de línea y normalmente son concebidos para procesar grandes volúmenes de información [30], debido a su naturaleza desatendida. Todo lo anterior unido a la aparición de las herramientas de EAI [16], como respuesta a las necesidades cada vez mas crecientes de integrar las aplicaciones de una o múltiples negocios, generaron el surgimiento de tecnologías tales como la mensajería, que permitió una comunicación con solicitudes y operaciones más granulares que las que se alcanzaban con los procedimientos anteriores [29]. Sin embargo, la existencia de sistemas legados de misión crítica, en las empresas actuales, renovaron el enfoque de la transferencia de archivos, y le ha permitido mantenerse como un elemento fundamental dentro de las herramientas de EAI [29], debido a que su uso puede ser estratégico para: Reducir los riesgos del negocio. Entregar un nivel de retorno (RoI) atractivo. Mayor velocidad de entrega para nuevas implementaciones y/o servicios. Permitir rápidamente la intercomunicación con los sistemas de otras empresas (B2B). A continuación se describen cinco (5) buenas prácticas para la implementación de este estilo de integración: Confirmar la transmisión de los archivos: todos aquellos que están involucrados en la transferencia de uno o varios archivos generalmente desean saber si estos han arribado satisfactoriamente a su destino final, por esta razón una confirmación explicita es bastante útil para saber si el o los 53

54 archivos han sido recibidos correctamente [32]. Para esto se puede generar un mensaje de retroalimentación al cliente a través de: Colocando un archivo con la información de confirmación en un FTP del emisor. Enviando un correo electrónico. Haciendo una invocación a un servicio web, informando la confirmación. Colocando un mensaje en una cola. Almacenando el registro en una tabla de base de datos. Fallas en la transmisión y avisos: cuando la transferencia de un archivo falla, puede deberse a causas muy comunes como son [32]: Problemas de red. El servidor con el que se tiene la conexión no se encuentra disponible. No es posible autenticarse al servidor. La ruta del archivo, no se encuentra disponible. No hay permisos suficientes para acceder al archivo. Una buena práctica en este caso es la de las soft fail [32], que consisten en el reintento de la operación sin intervención humana, en un período de una hora, sin embargo después de cinco (5) soft fail seguidas, deberá generarse una hard fail que de inmediato generara una notificación al personal encargado de los servidores de archivos, tanto los de recepción como los de emisión de los archivos. Verificación de falla de archivos: aún después de transferir el archivo satisfactoriamente, es posible que dicho archivo no tenga el formato esperado, o que el archivo esté corrupto. En este escenario las soft fail y 54

55 las hard fail no son útiles, y por ende se sugiere seguir las siguientes buenas prácticas: Verificar los archivos después de recibidos, por parte del receptor. Verificar los archivos de gran tamaño, antes de transmitirlos, por parte del emisor. Enviar notificación a los encargados de recibir el archivo y al receptor en caso que la verificación falle en cualquiera de los casos anteriormente descritos. Mejor protocolo: a menudo se presentan ciertas restricciones sobre los protocolos que podrán ser usado para la transferencia de los archivos, sin embargo cuando dicha restricción no exista y se pueda escoger SFTP (SSH File Protocol) [32], se recomienda este protocolo debido a que es ampliamente usado, soportado y bien conocido por un gran número de comunidades en Internet, además de su seguridad. Usar fechas, horas y minutos en la convención de nombramiento de archivos: generalmente nuevos archivos son generados diariamente y en algunos casos son generados son generados cada hora, en este caso para evitar confusión y para prevenir que los viejos archivos sean sobre escritos con los últimos datos, por esta razón el uso de fechas, hora y minutos en los nombres de los archivos permiten alcanzar esta meta [32]. Finalmente siguiendo estas buenas prácticas, pueden ser construidos ambientes robustos para la transferiría de archivos dentro de una organización o entre sus proveedores o clientes (B2B). 55

56 Buenas prácticas para bases de datos compartidas Cuando se requiere que varias aplicaciones, almacenen los datos que quieren compartir en una base de datos en común, es necesario dar acceso a la base de datos a cada una de las aplicaciones involucradas, sin embargo esto no es un enfoque favorable, debido a que expone los datos a diferentes clientes, quienes pueden no respetar las restricciones que se han establecido, pero no codificado [33]. Por esta razón un par de buenas prácticas para evitar esta situación son: Limitar el acceso de los clientes, solo a los objetos de interés para el. Utilizar vistas o snapshots, para la extracción de la información, esto previene que los clientes observen las estructuras de las entidades y la información que no es de su interés [33]. Permitir la manipulación de los datos a través del uso de procedimientos almacenados, que permitan un manejo transparente de las transacciones y brinden encapsulamiento de las operaciones y entidades que se ven afectadas [33]. El uso de estas prácticas para compartir bases de datos, no son por si solas la mejor solución, pues deben estar acompañadas por una correcta verificación del administrador de la base de datos, quien definirá con ayuda de lo descrito por el cliente, la información que este realmente necesita y la definición de posibles casos que llevarían a abortar la transacción al momento de modificar los datos, además de identificar los posibles escenarios, que podrían generar inconsistencias y como evitarlas pues no se debe olvidar que la información puede estar siendo manipulada por varias aplicaciones al tiempo Buenas prácticas para invocación remota de procedimientos En la revisión de la literatura realizada no se encontraron buenas prácticas para este estilo de integración. Por lo tanto en lo que sigue del desarrollo del método trabajaremos con las buenas prácticas para invocación remota de procedimientos identificadas en la consulta directa a expertos. 56

57 Buenas prácticas para mensajería En la actualidad, los sistemas de mensajería, se muestran como los medio de comunicación más adecuados para la intercomunicación de aplicaciones empresariales [16], por esta razón y después de su uso intensivo por parte de millones de desarrolladores, se encuentra en la literatura [16] las buenas prácticas en un grupo de patrones que se han denominado patrones de integración empresarial, como se expuso en la etapa II de esta fase, y que se basan en el uso del estilo de integración de mensajería como pilar principal para la integración. Como se mostró en esta etapa, existen buenas prácticas conocidas para cada estilo de integración, por lo tanto no existe un estilo mejor que otro, sino que cada situación indica qué estilo debe ser usado, o en algunos casos, cuáles estilos deben ser combinados [31]. A continuación se presentan en la Tabla 1, algunos pros y contras de cada uno de los estilos. Estilo de integración Ventajas Desventajas Transferencia de archivos Bases de datos compartidas Invocación remota de procedimientos Mensajería Simple, Interoperable. Simple, transaccional. Simple, puede ser rápido. Asíncrono, escalable. No es transaccional, ni para necesidades en tiempo real. Puede ser lento y difícil de evolucionar. No es interoperable, síncrono y altamente acoplado. Complejo. Tabla 1 Ventajas y desventajas de los estilos de integración [31]. 57

58 Para finalizar esta sección de buenas prácticas, se presenta a continuación un cuadro que ofrece una primera alternativa hacia el uso de Frameworks, en caso de requerir alguno de estos estilos. Estilo de integración Transferencia de archivos Bases de datos compartidas Invocación remota de procedimientos Framework Spring resource abstraction, Spring Batch, GoAnyWhere, Kettle Spring data access (JDBC, Object-Relational Mapping, transaction) Spring Remoting (Remote Method Invocation, HttpInvoker, Hessian, Burlap), EJB Session Stateless Spring JmsTemplate, Spring message container Mensajería listeners, Spring Integration, Message Driver Bean, EJB Tabla 2 Estilos de integración y los Frameworks que los implementan. 4.2 Fase II Diseño del método Conforme a la metodología establecida, se desarrolló la fase II del proyecto. El resultado de las actividades realizadas se detalla a continuación: Etapa I: Definición de categorías Para la definición de las categorías en las que se pueden clasificar los casos de negocio que son objeto del método diseñado, se tomó la decisión de categorizarlos de acuerdo a la necesidad de integración que se busca resolver. La decisión se tomó en un inicio teniendo en cuenta que la necesidad de integración es la que prácticamente define el caso de negocio y que las otras características son complementos que permiten particularizar aspectos del mismo. Durante la etapa de definición de filtros se validó completamente la decisión aquí tomada; pues en esta etapa se pudo evidenciar que la necesidad de integración es una 58

59 sola para cada caso de negocio y que las otras variables se pueden presentar simultáneamente en la caracterización de este; siendo la necesidad de integración la que determina la combinación que se puede presentar entre demás variables. Por lo anterior en esta etapa se definieron: Categoría 1: casos de negocio para compartir datos. Categoría 2: casos de negocio para compartir funcionalidad Etapa II: Soluciones conocidas aplicables por categoría Para la Categoría 1, casos de negocio regidos por datos, las soluciones conocidas aplicables son [16]: Transferencia de Archivos Bases de datos compartidas Mensajería Para la Categoría 2, casos de negocio regidos por funcionalidad, las soluciones conocidas aplicables son [16]: Invocación Remota de procedimientos Mensajería Etapa III: Buenas prácticas aplicables por categoría Esta etapa de la metodología, básicamente se resolvió en la Etapa III de la Fase I en la que las buenas prácticas quedaron clasificadas de acuerdo a las necesidades de integración y en la Etapa I de la Fase II en la que las necesidades de integración se definieron como las categorías del método Etapa IV: Definición de filtros Como se definió, en la Etapa I de la Fase I, determinar el conjunto de variables con las que se puede caracterizar un caso de integración de aplicaciones empresariales se identificaron cuatro (4) grupos de variables. El objetivo de esta etapa de la metodología fue identificar cuáles variables son excluyentes y cuáles son complementarias; identificación que corresponde al insumo necesario y 59

60 suficiente para la creación de los filtros que conducirán a la correcta la caracterización del caso de negocio Combinación de variables La identificación de estas exclusiones o complementos se realizó en dos niveles: En las variables pertenecientes al mismo grupo y entre las variables que pertenecen a grupos distintos. A continuación se muestra el proceso realizado y el resultado de esta identificación, para lo cual es importante resaltar que los casos en que las variables se subdividen en varias sub-variables, el análisis se realizó a nivel de sub-variables Entre el mismo grupo El propósito de esta actividad fue evaluar la compatibilidad entre las variables de un mismo grupo. El resultado de este trabajo se muestra a continuación: Grupo I: Tipos de Aplicaciones Para realizar esta actividad se parte de dos premisas fundamentales: Una aplicación solo puede tener un único tipo y se excluyen las aplicaciones tipo Tiempo Real que al ser evaluadas por la encuesta no obtuvieron una calificación promedio relevante para este estudio; Como se trabaja con un aplicación origen y una aplicación destino el análisis se centró en identificar las posibles combinaciones de tipos de aplicaciones entre ellas. Para ello se elaboró una matriz en la que las filas corresponden a los tipos de aplicación origen y las columnas a los tipos de aplicación destino; así, la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), ver Anexo 2.1 Tipos de aplicaciones. Después de realizar el análisis de cada una de las combinaciones se encuentra que no hay limitantes en cuanto al tipo de la aplicación origen y destino, por lo cual el resultado de esta actividad arroja una matriz con todas las posiciones con valor 60

61 uno (1) lo que define que todas las combinaciones son posibles y que en esta actividad no se identificaron filtros. Grupo II: Necesidades Como se ha expuesto en el planteamiento del problema, cada necesidad de integración puede tener una o varias soluciones conocidas; por lo cual el alcance del diseño del método se restringe al manejo de una única necesidad de integración por cada caso de negocio; en la ocasión en que el mismo caso de negocio contemple diferentes necesidades de integración, el caso de negocio debe ser caracterizado tantas veces como necesidades de integración contemple. Por lo anterior en esta actividad no se identificaron filtros. Grupo III: Criterios y Restricciones Se elaboró una matriz en la que las que tanto las filas como las columnas corresponden a cada uno de los criterios y restricciones; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), ver Anexo 2.2 Criterios y restricciones. En el análisis realizado se encontraron criterios y restricciones que son mutuamente excluyentes, a continuación se detallan las exclusiones resultantes: Cada variable consigo misma: Debido a que la herramienta utilizada para el análisis es una matriz en la intersección de filas y columnas surgió esta relación. Sin embargo en el diseño del método esta relación no existe así que la diagonal de la matriz se marcó con valor cero (0). En este análisis no hubo identificación de filtros. Sub-variables asociadas a la misma variable: Por la definición de cada subvariable, en el análisis se encontró que las sub-variables son mutuamente excluyentes entre sí cuando están asociadas a la misma variable. Por lo anterior las casillas de intersección entre sub-variables asociadas a la misma variable se marcaron con cero (0). En este análisis se identificó el 61

62 Filtro 1. Es importante resaltar que esta exclusión tiene contenida la exclusión del numeral anterior. Intrusión no permitida: Por definición de la sub-variable Intrusión no permitida y de la sub-variable Modificar la aplicación para usar un formato de datos común, se encuentra la mutua exclusión. Es este análisis se identificó el Filtro 2. Formato de los datos: Por definición de la variable Formato de los datos y de la sub-variable Funcionalidad se encuentra la mutua exclusión. Es este análisis se identificó el Filtro 3. Latencia en el intercambio de datos: Por definición de la variable Latencia en el intercambio de datos y de la sub-variable Funcionalidad se encuentra la mutua exclusión. Es este análisis se identificó el Filtro 4. Destino NO siempre disponible y síncrona: Por definición de la sub-variable Síncrona y de la sub-variable Destino NO siempre disponible se encuentra la mutua exclusión. Es este análisis se identificó el Filtro 5. Destino NO siempre disponible y Funcionalidad: Por definición de la subvariable Funcionalidad y de la sub-variable Destino NO siempre disponible se encuentra la mutua exclusión. En este análisis se identificó el Filtro 6. Además en el análisis también se identificó que la aplicación que provee la funcionalidad siempre es la aplicación destino lo cual llevó a identificar el Filtro 6 Funcionalidad y destino. Como resultado de este análisis se obtuvo una matriz simétrica debido a que las exclusiones encontradas entre las sub-variables son mutuas. Grupo IV: Características de calidad En este grupo el análisis se orientó con la revisión de la literatura [25], en la que se encuentra ampliamente documentada la exclusión entre las características de calidad. Se identificaron cuatro (4) filtros como resultado de esta revisión: 62

63 Filtro 7: Características de calidad que se ven afectados negativamente al definir funcionalidad como requerimiento Filtro 8: Características de calidad que se ven afectados negativamente al definir eficiencia de rendimiento como requerimiento Filtro 9: Características de calidad que se ven afectados negativamente al definir Capacidad de operación como requerimiento Filtro 10: Características de calidad que se ven afectados negativamente al definir seguridad o compatibilidad o capacidad de transferencia como requerimiento Se elaboró una matriz en la que las que tanto las filas como las columnas corresponden a cada uno de las características de calidad; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), ver Anexo 2.3 Características de calidad Entre los diferentes grupos Como parte del análisis se definió la siguiente premisa fundamental: Las variables del grupo características de calidad no son excluyentes con las variables de ningún otro grupo, porque las características de calidad pueden ser requeridos independientemente de la necesidad de integración, los tipos de aplicaciones y los criterios y restricciones. Por lo anterior solo se evaluaron las exclusiones entre los siguientes grupos: Criterios y Restricciones Vs. Tipo de Aplicación Origen Se elaboró una matriz en la que las que las filas corresponden a los criterios y restricciones y las columnas corresponden a los tipos de aplicaciones origen; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), para este análisis se separaron los tipos de aplicaciones transaccionales 1 y 2 que se habían venido 63

64 manejando, en los anteriores análisis como uno solo; lo anterior debido a que la diferencia entre estos dos tipos de aplicaciones es el tipo de estructuras de datos que manejan y que para este análisis es requerido revisar por separado, ver Anexo 2.4 Criterios y restricciones tipo de aplicación origen. En el análisis realizado se encontró que en por la definición de aplicación tipo batch, es excluyente con las sub-variables: funcionalidad y aplicación destino no siempre disponible en este segundo caso solo se puede resolver cuando hay tecnología disponible que lo permita. En este análisis se identificaron los filtros 11A y 11B. Y el filtro 12 que corresponde al tipo de aplicaciones transaccionales 1 que no procesan datos complejos, por tanto buscar un formato de datos extensible en el tiempo se considera excluyente. Criterios y Restricciones Vs Tipo de Aplicación Destino Se elaboró una matriz en la que las que las filas corresponden a los criterios y restricciones y las columnas corresponden a los tipos de aplicaciones destino; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), para este análisis se separaron los tipos de aplicaciones transaccionales 1 y 2 que se habían venido manejando, en los anteriores análisis como uno solo; lo anterior debido a que la diferencia entre estos dos tipos de aplicaciones es el tipo de estructuras de datos que manejan y que para este análisis es requerido revisar por separado, ver Anexo 2.5 Criterios y restricciones tipo de aplicación destino. En el análisis realizado se encontró el Filtro 13. En el cual se define: Filtro 13A: Batch y criterios y restricciones necesarias: si se define que el tipo de aplicación origen es batch, se encontró que las siguientes subvariables del grupo criterios y restricciones deben estar presentes: intrusión permitida, compartir datos, comunicación síncrona y destino siempre disponible. 64

65 Filtro 13B: Batch y criterios y restricciones excluyentes: el resultado del numeral anterior implica que las sub-variables: intrusión no permitida, compartir funcionalidad, comunicación asíncrona y destino No siempre disponible; son excluyentes con la variable bases de datos compartidas. Filtro 13C Batch criterios y restricciones que no aplican: las variables formato de los datos, latencia en el intercambio de datos y selección de la tecnología no son requeridas ni excluyentes con la necesidad bases de datos compartidas; pues no es relevante que estén presentes o ausentes al analizar este tipo de aplicación. El filtro 14 que corresponde al tipo de aplicaciones transaccionales 1 que no procesan datos complejos, por tanto buscar un formato de datos extensible en el tiempo se considera excluyente Utilización de Filtros: En esta actividad se muestran los filtros identificados en la actividad anterior de manera consolidada. Se parte como premisa que la necesidad de integración es la que determina la caracterización del caso de negocio y por ende es la que define los valores que pueden tomar las demás variables y sub-variables. A continuación se muestran los filtros y el orden en que se aplicarán Identificar necesidad de integración: Como se había expuesto anteriormente, se parte de la premisa que la necesidad de integración es una sola para el caso de negocio. Una vez identificada la necesidad de integración, datos o funcionalidad, la siguiente variable a identificar es el tipo de aplicación origen; se establece que una aplicación origen solo puede tener un único tipo. Una vez identificada la necesidad de integración y el tipo de aplicación origen, la siguiente variable a identificar es el tipo de aplicación destino; al igual que en el punto anterior la aplicación destino solo puede tener un único tipo, en caso que se requiera integrar una aplicación origen con varias 65

66 destino cada integración se considera un caso de negocio distinto y debe evaluarse por separado en el método. No hay exclusiones a evaluar entre los tipos de aplicaciones origen y destino; Con la necesidad de integración y los tipos de aplicaciones origen y destino identificadas, se pasa a identificar los criterios y restricciones de integración. En este punto se pueden identificar varios criterios y restricciones para un caso de negocio. Las exclusiones que se deben evaluar son: Necesidad de integración identificada vs. Criterios y restricciones. Tipo de aplicación origen identificada vs. Criterios y restricciones. Tipo de aplicación destino identificada vs. Criterios y restricciones. Criterios y restricciones vs. Criterios y restricciones. Características de calidad vs. Características de calidad Etapa V: El método diseñado Como resultado de esta fase de la metodología, se resume en los siguientes pasos: Paso1: Documentar el caso de negocio determinando los valores para cada una de las variables de caracterización definidas. Con ello se definen las variables de entrada al método. Paso2: Aplicar los filtros, en el orden descrito en la última etapa de esta fase, para con ello encontrar la correcta caracterización del caso de negocio y por consiguiente asociarlo a una de las siguientes categorías: Categoría 1: casos de negocio regidos datos. Categoría 2: casos de negocio regidos por funcionalidad. Paso3: Buscar las soluciones conocidas aplicables a la categoría encontrada. Paso4: Buscar las buenas prácticas aplicables a la categoría encontrada. Paso5: Entregar la soluciones conocidas en el orden de aplicabilidad. 66

67 4.3 Fase III Prueba del diseño del método Conforme a la metodología establecida se desarrollo la tercera y última fase del proyecto. Los resultados se muestran a continuación: Etapa I: Refinamiento del método El objetivo de esta etapa es encontrar una serie de criterios que permitan validar el conjunto de recomendaciones que el método entrega. Para ello se trabajó en elaborar un conjunto de filtros adicionales que trabajan sobre las soluciones conocidas y las demás variables de caracterización. Estos filtros adicionales se describen a continuación Soluciones conocidas Vs. Criterios y Restricciones Se elaboró una matriz en la que las que las filas corresponden a las necesidades de integración y las columnas corresponden a cada uno de los criterios y restricciones; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), ver Anexo 3.1 Soluciones conocidas criterios y restricciones. En el análisis realizado se encontraron necesidades de integración con criterios y restricciones que son mutuamente excluyentes, a continuación se detallan las exclusiones resultantes: Transferencia de Archivos y Funcionalidad: Por definición de la sub-variable Funcionalidad y de la variable Transferencia de Archivos se encuentra la mutua exclusión. En este análisis se identificó el Filtro Bases de Datos Compartidas Por definición de la variable Bases de datos compartidas se encuentra la exclusión con la todas las variables del grupo criterios y restricciones. En este análisis se identificó el Filtro 16. En el cual se define: 67

68 Filtro 16A Requisitos de criterios y restricciones necesarios para la solución bases de datos compartidas: si se define que la solución es compartir bases de datos, se encontró que las siguientes sub-variables del grupo criterios y restricciones deben estar presentes: intrusión permitida, compartir datos, comunicación síncrona y destino siempre disponible Filtro 16B Criterios y restricciones excluyentes para la solución bases de datos compartidas: el resultado del numeral anterior implica que las sub-variables: intrusión no permitida, compartir funcionalidad, comunicación asíncrona y destino, no siempre disponible; son excluyentes con la variable bases de datos compartidas Filtro 16C Criterios y restricciones para las que no aplica la solución bases de datos compartidas: las variables formato de los datos, latencia en el intercambio de datos y selección de la tecnología no son requeridas ni excluyentes con la solución bases de datos compartidas; pues no es relevante que estén presentes o ausentes al analizar la solución bases de datos compartidas Invocación Remota de Procedimientos Por definición de la solución Invocación Remota de Procedimientos se encuentra la exclusión con todas las variables y sub-variables del grupo criterios y restricciones asociadas al intercambio de datos: formato de los datos, latencia en el intercambio de datos y datos. En este análisis se identificó el Filtro Mensajería Por definición de la solución Mensajería se encuentra la exclusión la sub-variable del grupo criterios y restricciones selección de la tecnología no disponible. En este análisis se identificó el Filtro

69 Soluciones Conocidas Vs. Tipo de Aplicación Origen Se elaboró una matriz en la que las que las filas corresponden a las soluciones conocidas de integración y las columnas corresponden a los tipos de aplicaciones origen; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), ver Anexo 3.3 Soluciones conocidas tipo de aplicación origen. En el análisis realizado se encontró que la solución conocida de integración invocación remota de procedimientos es excluyente con el tipo de aplicación origen batch. En este análisis se identificó el filtro Soluciones Conocidas Vs. Tipo de Aplicación Destino Se elaboró una matriz en la que las que las filas corresponden a las soluciones conocidas de integración y las columnas corresponden a los tipos de aplicaciones destino; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), ver Anexo 3.4 Soluciones conocidas tipo de aplicación destino. En el análisis realizado se encontró que en por la definición de aplicación tipo batch, la única solución conocida de integración que puede tener como aplicación destino tipo batch es la de bases de datos compartidas. En este análisis se identificó el filtro 20. En este punto se define incluir un nuevo paso para realizar la aplicación de los filtros encontrados en esta etapa. El método refinado se define en los siguientes pasos: Paso1: Documentar el caso de negocio determinando los valores para cada una de las variables de caracterización definidas. Con ello se definen las variables de entrada al método. Paso2: Aplicar los filtros para con ello encontrar la correcta caracterización del caso de negocio y por consiguiente asociarlo a una de las siguientes categorías. La aplicación de los filtros debe realizarse en el siguiente orden: 69

70 Identificar necesidad de integración: La necesidad de integración es una sola para el caso de negocio Con la necesidad de integración definir la categoría del caso de negocio Una vez identificada la necesidad de integración, la siguiente variable a identificar es el tipo de aplicación origen Una vez identificada la necesidad de integración y el tipo de aplicación origen, la siguiente variable a identificar es el tipo de aplicación destino Con la necesidad de integración y los tipos de aplicaciones origen y destino identificadas, se pasa a identificar los criterios y restricciones de integración. En este punto se pueden identificar varios criterios y restricciones para un caso de negocio. Las exclusiones que se deben evaluar son: o Tipo de aplicación origen identificada vs. Criterios y restricciones o Tipo de aplicación destino identificada vs. Criterios y restricciones o Criterios y restricciones vs. Criterios y restricciones o Características de calidad vs. Características de Calidad Paso3: Buscar las soluciones conocidas aplicables a la categoría encontrada Paso4: Aplicar los filtros: Soluciones conocidas vs. criterios y restricciones Soluciones conocidas vs. tipo de aplicación origen Soluciones conocidas vs. tipo de aplicación destino Paso5: Buscar las buenas prácticas aplicables a la categoría encontrada. Paso6: Entregar la soluciones conocidas y buenas prácticas aplicables a la categoría 70

71 4.3.2 Etapa II: Aplicación del método diseñado Para la prueba del método se recolectaron diez (10) casos reales de integración de aplicaciones presentados en los dos últimos años en los proyectos de integración de aplicaciones del grupo empresarial Coomeva. Cada uno de los casos de negocio se sometió a los seis (6) pasos del método diseñado. La documentación de la aplicación del método para los diez (10) casos de negocio probados se encuentra detallada en el Anexo3.5 Caracterización de los casos de negocio y soluciones Paso1: Durante la ejecución del Paso1 se observó que las variables identificadas y los valores definidos para ellas, fueron las necesarias y resultaron suficientes para la caracterización de los casos de negocio. Paso2: Durante la ejecución del Paso2 se encontró que en la definición de los filtros faltó la evaluación de la existencia de una posible exclusión entre los criterios Formato de datos y Selección de la tecnología, en cuanto a que en algunos casos puede ser requerido utilizar un mediador que homologue los datos lo que implica que deba existir tecnología para realizarlo. En este análisis y por tratarse de solo algunos casos se agregó a la matriz de combinación de variables de criterios y restricciones la Evaluación 1. La matriz actualizada se muestra en el Anexo 3.2 Criterios y restricciones refinado. Adicional a lo anterior, durante la aplicación de filtros, se encontró que es necesario caracterizar el caso de negocio con una característica de calidad principal que determinará la inclusión o exclusión de las restantes características en la caracterización del caso de negocio. Paso3: Durante la ejecución se observó que realizar el Paso3 se obtiene como consecuencia inmediata una vez se ha realizado el paso2 de manera adecuada. 71

72 Paso4: Durante la ejecución del paso4 se observó que los filtros identificados, fueron los adecuados para refinar la caracterización de los casos de negocio. Paso5: Durante la ejecución se observó que realizar el paso5 se obtiene como consecuencia inmediata una vez se han realizado el Paso2 y el Paso4 de manera adecuada. Sin embargo, se evidenció una relación directa de buenas prácticas con soluciones conocidas. Por lo anterior el método se refinó para agrupar las buenas prácticas a cada una de las soluciones conocidas. El Paso 5 quedó entonces definido así: buscar las buenas prácticas asociadas a cada solución conocida aplicable a la categoría encontrada como se muestra en la Tabla 3. Paso6: Durante la ejecución se observó que realizar el Paso6 se obtiene como consecuencia inmediata una vez se han realizado el Paso2, el Paso4 y el Paso5 de manera adecuada. Solución Conocida Transferencia de archivos Bases de datos compartidas Invocación remota de procedimientos Mensajería Buenas prácticas Uso de Formato Generación de Archivos Transporte Sincronización y políticas Tipos de datos nativos Gobierno de datos Mecanismo de Exposición Consulta de información Llamado a procedimientos Formato de los mensajes Mecanismos de entrega de los mensajes Tabla 3 Buenas prácticas agrupadas por cada solución conocida. 72

73 El método final refinado y aplicado quedó definido como lo muestra la Figura 10. Los pasos se describen a continuación: Paso1: Documentar el caso de negocio determinando los valores para cada una de las variables de caracterización definidas. Con ello se definen las variables de entrada al método. Paso2: Aplicar los filtros para con ello encontrar la correcta caracterización del caso de negocio y por consiguiente asociarlo a una de las siguientes categorías. La aplicación de los filtros debe realizarse en el siguiente orden: Identificar necesidad de integración: La necesidad de integración es una sola para el caso de negocio Con la necesidad de integración definir la categoría del caso de negocio Una vez identificada la necesidad de integración, la siguiente variable a identificar es el tipo de aplicación origen Una vez identificada la necesidad de integración y el tipo de aplicación origen, la siguiente variable a identificar es el tipo de aplicación destino Con la necesidad de integración y los tipos de aplicaciones origen y destino identificadas, se pasa a identificar los criterios y restricciones de integración. En este punto se pueden identificar varios criterios y restricciones para un caso de negocio. Las exclusiones que se deben evaluar son: o Tipo de aplicación origen identificada vs. Criterios y restricciones o Tipo de aplicación destino identificada vs. Criterios y restricciones o Criterios y restricciones vs. criterios y restricciones o Características de calidad vs. características de Calidad Paso3: Buscar las soluciones conocidas aplicables a la categoría encontrada Paso4: Aplicar los filtros: Soluciones conocidas vs. criterios y restricciones 73

74 Soluciones conocidas vs. tipo de aplicación origen Soluciones conocidas vs. tipo de aplicación destino Paso5: Buscar las buenas prácticas asociadas a cada solución conocida aplicable a la categoría. Paso6: Entregar la soluciones conocidas y buenas prácticas aplicables a la categoría encontrada. Figura 10. Esquema del método diseñado Al realizar el análisis cualitativo de las soluciones entregadas por el método para los diez (10) casos de negocio caracterizados se encontró que: 74

75 En todos los casos la solución real implementada coincide con una de las soluciones recomendadas por el método. En todos los casos la solución real implementada se encuentra entre las dos soluciones más recomendadas por el método. En el cuarenta por ciento de los casos la solución real implementada es la solución más recomendada por el método. En el sesenta por ciento de los casos la solución más recomendada por el método fue la mensajería, la cual no coincidió con la solución real implementada. Esto se debe a que en el Grupo Empresarial Coomeva, la mensajería no había sido evaluada como una solución viable para los problemas de integración. La Tabla 4 muestra de manera general lo anteriormente descrito: Tabla 4 Comparativo entre solución real y soluciones recomendadas. Al realizar el análisis cualitativo para los casos en los que la solución más recomendada entregada por el método no coincide con la solución real implementada, se encontró en todos los casos la posibilidad de mejorar la implementación real así: En los Caso1 y Caso8, donde la solución real implementada es Transferencia de Archivos y la solución más recomendada por el método 75

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3

Más detalles

MENSAJERÍA EN SISTEMAS DE INFORMACIÓN

MENSAJERÍA EN SISTEMAS DE INFORMACIÓN Instituto de Computación Facultad de Ingeniería Universidad de la República MENSAJERÍA EN SISTEMAS DE INFORMACIÓN Informe de Proyecto de Grado 16 de diciembre de 2008 Montevideo - Uruguay Autores: Marcelo

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

Más detalles

Tema 4: Diseño de flujos interaplicación

Tema 4: Diseño de flujos interaplicación Tema 4: Diseño de flujos interaplicación 4.1 Introducción a los Sistemas EAI Modelo de referencia (1) INTEGRACIÓN B2B INTEGRACIÓN DE APLICACIONES Y PROCESOS INTEGRACIÓN DE DATOS INTEGRACIÓN DE PLATAFORMA

Más detalles

8.1 Arquitectura funcional

8.1 Arquitectura funcional 1 Colección de Tesis Digitales Universidad de las Américas Puebla Zuñiga, Víctor Alejandro 8.1 Arquitectura funcional La arquitectura de un sistema define sus componentes básicos y los conceptos importantes,

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

INTEGRACIÓN DE SISTEMAS HEREDADOS

INTEGRACIÓN DE SISTEMAS HEREDADOS CAPÍTULO 2 INTEGRACIÓN DE SISTEMAS HEREDADOS En el presente capítulo, se presenta el problema de integración de sistemas de Software. Una de cuyas características es la presencia de los llamados Sistemas

Más detalles

Components & Connectors Viewtype. Estilos

Components & Connectors Viewtype. Estilos Components & Connectors Viewtype Estilos 1 Estilos Especializan el C&C viewtype introduciendo tipos de componente y conector a los cuales pertenecerán las instancias del modelo Especifican patrones de

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Acoplamiento e interoperabilidad

Acoplamiento e interoperabilidad Máster Universitario en Ingeniería Informá3ca Acoplamiento e interoperabilidad Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 Acoplamiento débil Tipos de acoplamiento Cabalgando el

Más detalles

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario

Más detalles

Integración de Aplicaciones *

Integración de Aplicaciones * Integración de Aplicaciones * Rafael Z. Frantz (1), Rafael Corchuelo (2) (1) Universidade Regional do Noroeste do Estado do Rio Grande do Sul São Francisco, 501. Ijuí 98700-000 RS (Brasil) rzfrantz@unijui.edu.br

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Las tecnologías SOA y ESB como herramientas integradoras para el acceso unificado a servicios colaborativos heterogéneos

Las tecnologías SOA y ESB como herramientas integradoras para el acceso unificado a servicios colaborativos heterogéneos Tesina Licenciatura en Informática (UNLP) Las tecnologías SOA y ESB como herramientas integradoras para el acceso unificado a servicios colaborativos heterogéneos Boccalari Cristian Temario General Visión

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

Más detalles

Antes de imprimir este documento piense en el medio ambiente!

Antes de imprimir este documento piense en el medio ambiente! Versión 1.0 Página 1 de 14 1. OBJETIVO: Suministrar la metodología que se aplicará para la estimación de esfuerzo para los desarrollos nuevos en el ICBF, para lo cual se detallan los aspectos a tener en

Más detalles

6.1 Introducción a los sistemas EAI

6.1 Introducción a los sistemas EAI 6.1 Introducción a los sistemas EAI Integración de Aplicaciones (1) El problema de la integración de aplicaciones consiste en hacer colaborar entre sí a aplicaciones distribuidas, heterogéneas y posiblemente

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

S s i t s em a s de d Inf n o f r o m a ió i n TIPOS DE SISTEMAS

S s i t s em a s de d Inf n o f r o m a ió i n TIPOS DE SISTEMAS Sistemas de Información TIPOS DE SISTEMAS La Empresa en la Sociedad de la Información: Impacto en las Organizaciones TICS TICS - COMPONENTES el factor humano los contenidos de la información el equipamiento

Más detalles

Qué se entiende por diseño arquitectónico? Comprende el establecimiento de un marco de trabajo estructural básico para un sistema. Alude a la estructura general del software y el modo en que la estructura

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

Más detalles

<TITULO DEL PROYECTO DE DESARROLLO DE SW > Diana Milena Pérez Riveros 1 Diana Milena Pérez Riveros Pagina de

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

Arquitectura de Proyectos de IT

Arquitectura de Proyectos de IT Arquitectura de Proyectos de IT Apunte: Introducción a MQ y conceptos de mensajería Autores: Patricio Echagüe patricioe@gmail.com Ing. Gastón Escobar gescobar@gmail.com Versión: 0.1 Octubre, 2005 1 Índice

Más detalles

Arquitecturas de Integración

Arquitecturas de Integración Arquitecturas de Integración Ing. Gastón Escobar Ing. Nicolás Passerini Ing. Juan Arias Ing. Santiago Blanco 2006 Agenda Enterprise Architecture Integración de Sistemas Evolución histórica Métodos de integración

Más detalles

SISTEMAS DE INFORMACIÓN III TEORÍA

SISTEMAS DE INFORMACIÓN III TEORÍA CONTENIDO: Introducción a los Web services Las bases de los Web services La nueva generación de la Web Interactuando con los Web services La tecnología de Web services XML: Lo fundamental WSDL: Describiendo

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reutilizable Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Objetivos Para explicar los beneficios del software reutilizable y algunos de sus problemas Para discutir

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

El desarrollo de aplicaciones

El desarrollo de aplicaciones e d i t o r i a l Entendiendo el desarrollo de los sistemas SOA María Consuelo Franky R. El desarrollo de aplicaciones orientadas y basadas en servicios, como estilo de arquitectura, emergió sobre la arena

Más detalles

LA ARQUITECTURA TCP/IP

LA ARQUITECTURA TCP/IP LA ARQUITECTURA TCP/IP Hemos visto ya como el Modelo de Referencia de Interconexión de Sistemas Abiertos, OSI-RM (Open System Interconection- Reference Model) proporcionó a los fabricantes un conjunto

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Base de Datos ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Una base de datos es un conjunto de elementos de datos que se describe a sí mismo, con relaciones entre esos elementos, que presenta

Más detalles

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Isaac Gutiérrez Gómez, Salvador Otón Tortosa Universidad de Alcalá, Departamento de Ciencias de la Computación, 28871 Alcalá de Henares, Spain igutierrez09@yahoo.es, salvador.oton@uah.es

Más detalles

Service Oriented Architecture: Con Biztalk?

Service Oriented Architecture: Con Biztalk? Service Oriented Architecture: Con Biztalk? Pablo Abbate Servicios Profesionales Danysoft SOA supone una nueva forma de pensar acerca de la arquitectura IT para las empresas. De hecho, es una asociación

Más detalles

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar

Más detalles

Arquitecturas de Software

Arquitecturas de Software Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña cjacunia@escet.urjc.es Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles

GLOSARIO DE TERMINOS

GLOSARIO DE TERMINOS GLOSARIO DE TERMINOS A Aplicaciones Legacy.- Conjunto de aplicaciones desarrolladas o implementadas en plataformas de sistemas anteriores o antiguos. B Bases de Datos.- Organización y conservación de datos

Más detalles

4. Programación Paralela

4. Programación Paralela 4. Programación Paralela La necesidad que surge para resolver problemas que requieren tiempo elevado de cómputo origina lo que hoy se conoce como computación paralela. Mediante el uso concurrente de varios

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

Gestión de la Información

Gestión de la Información Gestión de la Información Sociedad de la Información Recurso Información Sistemas de Información Tecnologías de la Información Internet ii Fundamentos de SI: Gestión de la Información 49 Un Sistema de

Más detalles

Visibilidad en la Cadena de Suministro.

Visibilidad en la Cadena de Suministro. Visibilidad en la Cadena de Suministro. Ing. Nataly Sanchez. 1 ; Ing. Pedro Gutierrez. 2 ; Ing. Víctor Quitiaquez. 3 1. Introducción. El concepto de cadena de suministro hace referencia al seguimiento

Más detalles

Módulo 2 Comunicación

Módulo 2 Comunicación Sistemas Distribuidos Módulo 2 Comunicación Facultad de Ingeniería Departamento de Informática Universidad Nacional de la Patagonia San Juan Bosco Comunicación en Sistemas Distribuidos Modelos de Comunicaciones

Más detalles

Cómo puedo administrar mejor los activos de software y mitigar el riesgo de las auditorías de cumplimiento?

Cómo puedo administrar mejor los activos de software y mitigar el riesgo de las auditorías de cumplimiento? RESUMEN DE LA SOLUCIÓN CA SERVICE MANAGEMENT: ADMINISTRACIÓN DE ACTIVOS DE SOFTWARE Cómo puedo administrar mejor los activos de software y mitigar el riesgo de las auditorías de cumplimiento? CA Service

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción El WWW es la mayor fuente de imágenes que día a día se va incrementando. Según una encuesta realizada por el Centro de Bibliotecas de Cómputo en Línea (OCLC) en Enero de 2005,

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Módulo Profesional 01: Bases de datos (código: 0484).

Módulo Profesional 01: Bases de datos (código: 0484). Módulo Profesional 01: Bases de datos (código: 0484). Actividades de enseñanza-aprendizaje que permiten alcanzar los objetivos del módulo. Interpretar diseños lógicos de bases de datos. Realizar el diseño

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos Espiñeira, Sheldon y Asociados No. 4-2010 Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción 4 Qué

Más detalles

Gobernabilidad de TI. Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur. 2do.

Gobernabilidad de TI. Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur. 2do. Gobernabilidad de TI COBIT Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur 2do. Cuatrimestre 2010 T. 2 Contenido Introducción a la Gobernabilidad de TI

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

DGSIE RESUMEN TEMA 7 NOCIÓN DE ebusiness

DGSIE RESUMEN TEMA 7 NOCIÓN DE ebusiness DGSIE RESUMEN TEMA 7 NOCIÓN DE ebusiness 7.1. DEFINICIÓN DE EBUSINESS. DIFERENCIAS CON ECOMMERCE. ebusiness designa a cualquier empresa o negocio que gestiona sus procesos, de modo total o parcial, sobre

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

Replicación de Datos en SQL Server... 3. Resumen... 3. 1. Introducción... 3. 2. Componentes del modelo de replicación... 3

Replicación de Datos en SQL Server... 3. Resumen... 3. 1. Introducción... 3. 2. Componentes del modelo de replicación... 3 REPLICACIÓN DE DATOS EN SQL SERVER CONTENIDO Replicación de Datos en SQL Server... 3 Resumen... 3 1. Introducción... 3 2. Componentes del modelo de replicación... 3 3. Escenarios típicos de la replicación...

Más detalles

Memoria Compartida Distribuida (DSM) Sistema de Archivos

Memoria Compartida Distribuida (DSM) Sistema de Archivos Memoria Compartida Distribuida (DSM) La memoria compartida distribuida es una abstracción que se propone como alternativa a la comunicación por mensajes. Memoria compartida basada en páginas: este esquema

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico Capítulo II Guía Gerencial de la Plataforma de Gobierno Electrónico 12 Capítulo II Guía Gerencial de la PGE Introducción Este capítulo presenta el concepto de gobierno electrónico, los desafíos de interoperabilidad

Más detalles

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic ARQUITECTURAS ORIENTADAS A SERVICIOS SOA en la Seguridad Social por Mario triguero garrido 48 boletic El deber de ofrecer al ciudadano el mejor servicio ha sido siempre la motivación por la cual la Gerencia

Más detalles

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles

UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA

UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA Estudio de las herramientas TOAD y DBArtisan para la administración e integración de bases de datos relacionales. PREVIA OPCION AL TÍTULO DE: INGENIERO

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

Notas. Introducción. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow. Palabras claves: Groupware, Workflow, BPCM, WfMC.

Notas. Introducción. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow. Palabras claves: Groupware, Workflow, BPCM, WfMC. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow Palabras claves: Groupware, Workflow, BPCM, WfMC. Introducción A partir de la llegada de las computadoras personales al ambiente empresarial

Más detalles

Guía Metodológica para el diseño de procesos de negocio

Guía Metodológica para el diseño de procesos de negocio Guía Metodológica para el diseño de procesos de negocio La guía desarrollada para apoyar TBA, se diseñó con base en las metodologías existentes para el desarrollo BPM, principalmente en aquellas que soportan

Más detalles

WebSphere Message Broker como Entreprise Service Bus

WebSphere Message Broker como Entreprise Service Bus IBM Software Group WebSphere Message Broker como Entreprise Service Bus Irene Couso, IT Specialist, SWG WebSphere Services Agenda WebSphere Problemática En Los Clientes Por Qué Esta Arquitectura? Oferta

Más detalles

Cómo lograr una implementación exitosa de SOA?

Cómo lograr una implementación exitosa de SOA? Software Huibert Aalbers Certified Executive Software IT Architect BUE Technical Sales, SW Services Manager IBM de Mexico 2007 IBM Corporation Agenda!Interoperabilidad! De dónde viene SOA?!Las distintas

Más detalles

Planificación del Help Desk de su escuela

Planificación del Help Desk de su escuela Capítulo 1 Planificación del Help Desk de su escuela Después de terminar este capítulo usted será capaz de: Describir cuál es la función de un Help Desk; Describir qué es el soporte de nivel 1; Explicar

Más detalles

2.1 Compuertas para Bases de Datos

2.1 Compuertas para Bases de Datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Uno de los aspectos mas importantes en un sistema multibase de datos es la forma en como llevar a cabo la comunicación

Más detalles

SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS

SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS Universidad de Carabobo Facultad Experimental de Ciencias y Tecnología Departamento de Computación Unidad Académica Base de Datos SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS Integrantes: Fidel Gil

Más detalles

SISTEMAS DE INFORMACIÓN III TEORÍA

SISTEMAS DE INFORMACIÓN III TEORÍA CONTENIDO: PROCESOS, SISTEMAS DE INFORMACIÓN Y TECNOLOGÍAS DE INFORMACIÓN - LA INTEGRACIÓN DE SISTEMAS - VÍNCULOS ENTRE LOS SISTEMAS Y LA INTEGRACIÓN DEL NEGOCIO - SISTEMAS EMPRESARIALES - ENFOQUES DE

Más detalles

CEP/ESP: Procesamiento y correlación de gran cantidad de eventos en arquitecturas SOA

CEP/ESP: Procesamiento y correlación de gran cantidad de eventos en arquitecturas SOA CEP/ESP: Procesamiento y correlación de gran cantidad de eventos en arquitecturas SOA Víctor Ayllón 1 y Juan M. Reina 1 1 Novayre {vayllon, jmreina}@novayre.es Abstract. El matrimonio entre ESP/CEP y las

Más detalles

Arquitectura Empresarial. Ministerio de Salud

Arquitectura Empresarial. Ministerio de Salud Arquitectura Empresarial Ministerio de Salud Arquitectura de TI - Arquitectura de Aplicaciones Versión 1.1 Versión 1.1 Página: 1 of 34 Tabla de Contenido 1. INTRODUCCIÓN... 3 2. ARQUITECTURA DE APLICACIONES...

Más detalles

BPMN 2.0. Bizagi Suite. Copyright 2014 Bizagi

BPMN 2.0. Bizagi Suite. Copyright 2014 Bizagi BPMN 2.0 Bizagi Suite BPMN 2.0 1 Tabla de Contenido Scope... 2 BPMN 2.0... 2 Qué es BPMN?... 2 Por qué es importante modelar con BPMN?... 3 Conceptos clave... 3 Proceso De Solicitud De Crédito... 3 Proceso

Más detalles

Interoperabilidad. Conferencia: Presente y futuro de las SMART GRIDS en México. Ing. Alfredo Espinosa Reza aer@iie.org.mx

Interoperabilidad. Conferencia: Presente y futuro de las SMART GRIDS en México. Ing. Alfredo Espinosa Reza aer@iie.org.mx Interoperabilidad Conferencia: Presente y futuro de las SMART GRIDS en México Ing. Alfredo Espinosa Reza aer@iie.org.mx 29 de Octubre de 2013 Contenido Introducción. Estrategias para modelado y acceso

Más detalles

Introducción a SOA (II) Huibert Aalbers Senior Certified Software IT Architect

Introducción a SOA (II) Huibert Aalbers Senior Certified Software IT Architect Introducción a SOA (II) Huibert Aalbers Senior Certified Software IT Architect IT Insight podcast Este podcast pertenece a la serie IT Insight Pueden suscribirse al podcast a través de itunes. El material

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Programa de Capacitación y Certificación. INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Contenido PERFIL DE UN ESPECIALISTA EN BASES DE DATOS.... 3 6231. MANTENIENDO UNA BASE DE DATOS DE SQL SERVER 2008

Más detalles

TEMA: PROTOCOLOS TCP/IP

TEMA: PROTOCOLOS TCP/IP TEMA: PROTOCOLOS TCP/IP HISTORIA: El Protocolo de Internet (IP) y el Protocolo de Transmisión (TCP), fueron desarrollados inicialmente en 1973 por el informático estadounidense Vinton Cerf como parte de

Más detalles

MODELACION Y ANALISIS DE PROCESOS EMPRESARIALES MAPE

MODELACION Y ANALISIS DE PROCESOS EMPRESARIALES MAPE MODELACION Y ANALISIS DE PROCESOS EMPRESARIALES MAPE Thomas A. Little Ph. D Traducción Autorizada por el Autor. Traductor: MANUEL H RAMIREZ Alta Via Consulting-América Latina La Modelación y Análisis de

Más detalles

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Ramón Gómez-Romero, Karen Cortés Verdin, Juan Carlos Pérez Arriaga, Ángeles Arenas Valdés Universidad

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Arquitectura Empresarial. Ministerio de Salud

Arquitectura Empresarial. Ministerio de Salud Arquitectura Empresarial Ministerio de Salud Arquitectura de TI Arquitectura de Integración Versión 1.5 Documento: Arquitectura de Integración Ministerio de Salud Fecha:5/16/2013 Versión 1.5 Página: 1

Más detalles

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

Formatos para prácticas de laboratorio

Formatos para prácticas de laboratorio Fecha de efectividad: CARRERA Ing. En Comp. y L.S.C. PLAN DE ESTUDIO CLAVE ASIGNATURA NOMBRE DE LA ASIGNATURA 2003-1 5038 Programación Orientada a Objetos II PRÁCTICA No. 6 LABORATORIO DE NOMBRE DE LA

Más detalles

Patrones de software y refactorización de código

Patrones de software y refactorización de código Patrones de software y refactorización de código Introducción y antecedentes de los patrones de software Los patrones permiten construir sobre la experiencia colectiva de ingenieros de software habilidosos.

Más detalles

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Implantación de una arquitectura orientada a servicios. Un caso de uso Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Introducción Los compromisos

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

9.1 Conceptos básicos

9.1 Conceptos básicos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Zuñiga, Víctor Alejandro 9.1 Conceptos básicos En este capítulo, se analizarán cinco arquitecturas diferentes y se discutirá cómo están

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

MARCANDO LA DIFERENCIA

MARCANDO LA DIFERENCIA MARCANDO LA DIFERENCIA INTEGRACIÓN RÁPIDA Y CONFIABLE entre sus sistemas Simplifique la integración y el mantenimiento de su lógica de negocio con nuestra arquitectura orientada a servicios. Ahorre dolores

Más detalles

Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables.

Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables. Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables. Para obtener el grado de Maestro en Ciencias (Ciencias y Tecnologías de la Información) P R E S E N T A Lic.

Más detalles

Service Oriented Architecture

Service Oriented Architecture Programación Concurrente y Distribuida Ingeniería en Informática Service Oriented Architecture José Carlos Cortizo Pérez josecarlos.cortizo@uem.es http://www.esp.uem.es/jccortizo D. Sistemas Informáticos

Más detalles

CAPÍTULO V PROPUESTA DE LA SOLUCIÓN

CAPÍTULO V PROPUESTA DE LA SOLUCIÓN CAPÍTULO V PROPUESTA DE LA SOLUCIÓN 5.1 Introducción En los últimos tres años la entidad financiera ha venido sufriendo cambios que le han permitido crecer y pasar de ser una Sociedad Financiera a un Banco

Más detalles