Documento de Arquitectura de Software Versión 1.0 Historia de la Revisión Fecha Versión 22 de Mayo de 2006 1.0 1. Descripción Descripción de la arquitectura Introducción Autor Nadia Alvarez Juan Gómez 4 1.1. Propósito 4 1.2. Alcance del documento 4 1.3. Definiciones, Siglas y Abreviaturas 4 1.4. Referencias 5 1.5. Visión Global 5 2. Análisis de la solución a implementar 5 2.1. Generalidades 6 2.2. Diseño General de la solución a implementar 6 Capas Generales de la solución a implementar 7 Overview de la Estructura Interna del Componente. 9 2.3. Transaccionalidad 9 2.4. Manejo de Errores 10 Errores de aplicación 10 Diagramas de Secuencia de la Solución 11 Representación de la Arquitectura de Referencia 12 2.5. 3. 3.1. Vista Funcional 12 3.2. Vista Lógica 12 3.3. Vista de Despliegue 12 3.4. Vista de Implementación 13 4. Objetivos y Restricciones de la Arquitectura de referencia 4.1. 5. Modelo Cliente-Servidor 14 Visión General del modelo cliente-servidor 14 Vista Funcional 5.1. 13 Casos de uso significativos 5.1.1. Ingresar información de monitoreo 15 15 15 6. 5.1.2. Ingresar información predial 16 5.1.3. Realizar consultas de atributos espaciales y no espaciales 16 Vista Lógica 6.1. Paquetes de la Capa de Adaptación 6.1.1. 6.2. Paquetes de la Capa de Administración de Servicios 6.2.1. 6.3. Fachada paquete servicios. Paquetes de la Capa de Servicios del negocio 16 18 18 19 19 19 1. Introducción A partir de este documento de Arquitectura de Software se busca proveer una visión general de la arquitectura del sistema que ayudará a manejar la información cartográfica y espacial, usando un número de vistas de arquitectura diferentes para describir distintos aspectos del sistema. 1.1. Propósito Este documento sirve como medio de comunicación entre los desarrolladores del sistema, sus usuarios y las personas que en un futuro quieran continuar con la consolidación de la propuesta de manejo de información cartográfica y espacial, respetando las decisiones significativas para la arquitectura sobre las cuales se realizará el proyecto. Sobre todo el principal objetivo es plantear un lenguaje común con la Unidad de Parques Nacionales de Colombia sobre como se plantea solucionar el problema en cuestión. 1.2. Alcance del documento Este documento formará las bases arquitectónicas del proyecto, las cuales serán respetadas en las fases e iteraciones posteriores. Todos los componentes y artefactos serán elaborados teniendo como base esta este documento. Es importante recalcar que se plantea la arquitectura macro de la solución a implementar e implantar, no se plantea un diseño detallado de todos los subcomponentes que harán parte integral de la solución. 1.3. Definiciones, Siglas y Abreviaturas SIG: Sistema de Información Geográfica UPNN: Unidad de Parques Naturales Nacionales. 1.4. Referencias Documentación RUP UML y Patrones, Craig Larman. 2ª edición. Prentice Hall Documentación XP 1.5. Visión Global Este documento está organizado en varias secciones. En las primeras secciones se presenta una vista global de la arquitectura a utilizar en el proyecto: su representación, objetivos y restricciones. Posteriormente se presenta una sección importante donde se plantean los aspectos generales de la solución a diseñar. Enseguida se dan las vistas del análisis, diseño e implementación de los casos de uso priorizados: de casos de uso, lógica, de despliegue y de implementación. Finalmente, se especifican los criterios que se tendrán en cuenta para asegurar la calidad, escalabilidad y el desempeño del sistema, y los patrones de diseño que serán usados para su implementación. 2. Análisis de la solución a implementar A pesar de que esta sección no pertenece al documento de arquitectura, se ha puesto debido a lo importante que es plantear los aspectos específicos de la propuesta que se ha diseñado. 2.1. Generalidades Este proyecto ofrece una propuesta orientada a un sistema de información geográfico que le permitirá a la UPNN proponer de manera efectiva políticas, planes y programas, normas y procedimientos relacionados con las áreas protegidas a partir de la información almacenada en éste. De la misma manera le ayudará a reunir y unificar toda la información que se almacena en cada uno de los parques protegidos de Colombia creando una memoria colectiva que perdure a través del tiempo. 2.2. Diseño General de la solución a implementar Un diagrama global de los componentes que interactúan en el contexto operativo nacional de la aplicación se muestra a continuación en la figura No 1: Parque Datos Estación de trabajo Territorial Datos Servidor Estaciones de trabajo UPNNC Datos Estaciones de trabajo Servidor Figura 1: Diseño general Capas Generales de la solución a implementar EL sistema a implementar tendrá una orientación de Arquitectura cliente servidor, y trabajara con las capas a continuación presentadas. Capa de Adaptación Capa de administración de servicios Capa de servicios Figura 2: Capas generales Capa de Adaptación: Se encarga de realizar la selección de servicios ofrecidos por cualquiera de los dos administradores de bases de datos que se van a usar, Oracle o Access. Capa de administración de servicios: Se encarga de almacenar las consultas pesadas que puedan existir en el sistema, como también de administrar las funcionalidades de la capa siguiente. Capa de servicios: Se encarga del procesamiento de reportes, visualización de información y mapas e interfaces de carga de datos. Overview de la Estructura Interna del Componente. Datos Adaptador de servicios Access Adaptador de servcios Oracle Adaptador Capa de Adaptación Lógica de datos Administración de la capa de servicios Capa de administración de servicios Funciones GIS Función de reportes Ingreso a datos Capa de servicios Figura 3: Estructura interna de las capas 2.3. Transaccionalidad Debido a que se opto por una arquitectura cliente servidor, el manejo de las transaccionalidad se le delegara al motor de base de datos, esta decisión fue tomada en base al hecho de que el sistema no maneja una lógica de negocio pesada, por el contrario el sistema trabaja como repositorio de información mas que como un sistema de análisis, ya que del análisis cartográfico se encarga el aplicativo GIS. 2.4. Manejo de Errores Sobra afirmar que este es un de los aspectos mas importantes de cualquier sistema de información, mas si se trata de un sistema GIS. El sistema debe encargarse de analizar errores operativos, tales como son fallos en las comunicaciones y en la sincronización de la información, pero lo errores asociados a los datos cargados serán responsabilidad del usuario. A continuación se especifican los errores que serán manejados por el sistema. Errores de aplicación Este tipo de errores agrupa únicamente aquellos originados por fallos en la ejecución normal del componente. Se consideran entre estos: Fallos en la comunicación entre el aplicativo GIS y la base de datos. Fallos en la comunicación entre una de las interfaces de cargue de datos y la base de datos. Fallos en la sincronización de datos. 2.5. Diagramas de Secuencia de la Solución El sistema consta de dos módulos esenciales, el de manejo de información de monitoreo de animales y el manejo de información de predios; estos dos módulos cuentan con sus respectivos atributos espaciales y no espaciales que se encargan de georeferenciar los diferentes aspectos que maneja este tipo de información en los mapas pertinentes. Las consultas a las que hace referencia el diagrama de secuencia le ofrecen al usuario datos de salida en formato de reportes o representados en un mapa. 3. Representación de la Arquitectura de Referencia Este documento presenta la arquitectura como una serie de vistas: vista de casos de uso, vista de despliegue y vista de implementación. Estas vistas son presentadas como Modelos empleando el Lenguaje de Modelado Unificado (UML). A continuación se explica brevemente como se orientará y que significa cada vista. 3.1. Vista Funcional Contiene la lista de casos de uso y escenarios, para presentar la funcionalidad significante del sistema. Ésta tiene un amplio cubrimiento de la arquitectura e ilustra los puntos críticos de la misma. 3.2. Vista Lógica Aquí se plantean elementos importantes sobre la estructura y organización de la solución a implementar e implantar. Se describe las partes significativas de la arquitectura del Modelo de Diseño, descomponiéndolo entre subsistemas y paquetes. Algunos de estos paquetes significativos muestran la descomposición en clases, esta vista también introduce las clases importantes para la arquitectura y describe sus responsabilidades, sus relaciones, operaciones y atributos. 3.3. Vista de Despliegue A través de esta vista se describe con poco nivel de detalle la configuración y los componentes de la arquitectura en la cual el software es implantado y ejecutado. 3.4. Vista de Implementación Describe globalmente la estructura de implementación del modelo del sistema, la descomposición del sistema en niveles y subsistemas, y otros componentes significativos. 4. Objetivos y Restricciones de la Arquitectura de referencia En la definición de la arquitectura se consideran los siguientes elementos: Requerimientos Funcionales, capturados en el Modelo de Casos de Uso. Este análisis de casos de uso se esta realizando en base a las entrevistas y a los documentos generados por la UPNN. Requerimientos no Funcionales, capturados por medio de entrevistas, observación de la infraestructura de la UPNN y estudio acerca de las posibilidades de inversión en proyectos. Algunas de las especificaciones no funcionales encontradas son: Disponibilidad de la información en ambientes conectados y no conectados: Debido a las restricciones que tienen los parques en Colombia en cuanto a la infraestructura física (redes eléctricas y de información primordialmente) no es posible desarrollar una aplicación que dependa de una conexión permanente a una red. Tampoco puede pensarse en una aplicación con la información totalmente centralizada sobre un servidor en una posición estratégica (con el fin de ahorrar dinero en licencias y en la compra de equipos con las capacidades necesarias para soportar software de análisis de información cartográfica) ya que en las oficinas centrales de parques, específicamente en la unidad de planeación y sistemas de información, no cuentan con los equipos, personal capacitado o capital suficiente para asegurar una disponibilidad permanente de la información. Teniendo en cuenta que la UPNN es una entidad estatal no se puede contar con la solución a corto plazo de este problema, es por esto que es necesario buscar estrategias que permitan lidiar con estas dificultades. Necesidad de sincronizar las bases de datos: Debido a los problemas de conectividad, es necesario generar estrategias que permitan sincronizar las bases de datos locales con las nacionales. Sin embargo, es muy importante recalcar que estas no son las únicas influencias que formarán la arquitectura ya que otras restricciones se impondrán por el entorno del sistema, por la necesidad de reutilizar elementos ya existentes, por la imposición de las normas internas de la UPNN, por los decretos o acuerdos que intervengan con los formatos de la información manejada, entre otras. El objetivo principal de la arquitectura es la visión común, descrita como un conjunto de Componentes que son reutilizados a través de diferentes módulos para facilitar la integración entre ellos. El punto inicial de esta visión común es la arquitectura cliente servidor, la cual divide diferentes tareas entre equipos con el fin de lograr una mayor eficiencia en el momento de cumplirlas. 4.1. Modelo Cliente-Servidor Visión General del modelo cliente-servidor La arquitectura cliente servidor muestra la relación de diferentes procesos corriendo en máquinas separadas con el fin de balancear cargas y mejorar la eficiencia y el tiempo de respuesta de las aplicaciones. En este modelo el trabajo se reparte entre dos o más máquinas, en donde una de ellas actúa como cliente y otra como servidor; para éste caso se usará un cliente pesado, el cual asume aspectos de la lógica del negocio y la presentación de la aplicación ante los usuarios, por otro lado el servidor se encarga de almacenar datos y actuar como repositorio. Debido a los requerimientos no funcionales de la aplicación, el modelo cliente servidor fue modificado de tal manera que los clientes pueden manejar además de la capa de presentación y lógica del negocio, una pequeña base de datos que les permita trabajar en condiciones de nulo acceso a la red. Sin embargo, el usuario final podrá acceder a un mayor número de servicios conectado al servidor principal que maneja la base de datos de los parques nacionales. 5. Vista Funcional La vista de casos de uso presenta un subconjunto del modelo de casos de uso global, presentando la arquitectura significante de los casos de uso del sistema. Esta describe un conjunto de escenarios que son significantes, y que tienen funcionalidad central. También describe escenarios y casos de uso que tiene una cobertura substancial y que impactan o ilustran un punto delicado de la arquitectura de forma especifica. La descripción de casos de uso estará definida por la documentación de RUP. 5.1. Casos de uso significativos Pueden definirse los siguientes casos de uso del sistema: 5.1.1. Ingresar información de monitoreo Este caso de uso abarca el ingreso y verificación del formato de los datos ingresados para describir el avistamiento de una especie en el área del parque. Los datos a ingresar corresponden a la información biológica de la especie (nombre común de la especie y cualquier otro dato referente a este), la localización geográfica del avistamiento (latitud, longitud, altura, base cartográfica usada) e información acerca de las evidencias físicas que soportan los datos anteriores. Esta información debe estar acompañada del metadato correspondiente, en donde se especifican las condiciones en que se tomaron los datos. 5.1.2. Ingresar información predial Este caso de uso busca el ingreso de cualquier modificación hecha sobre los predios identificados dentro del parque, esto con el fin de mantener actualizado el historial del predio. Su referenciación en el mapa se hace por medio de polígonos que representen los predios del lugar. 5.1.3. Realizar consultas de atributos espaciales y no espaciales Este caso de uso abarca las siguientes operaciones: - Mantenimiento y análisis de los datos espaciales - Mantenimiento y análisis de los datos atributos - Análisis integrado de los datos espaciales y los atributos - El formato de salida 6. Vista Lógica Como se mencionó en la sección Descripción General de la solución a implementar, el componente de integración se divide en las siguientes capas funcionales: Capa de Adaptación: Se encarga de realizar la selección de servicios ofrecidos por cualquiera de los dos administradores de bases de datos que se van a usar, Oracle o Access. Capa de administración de servicios: Se encarga de almacenar las consultas pesadas que puedan existir en el sistema, como también de administrar las funcionalidades de la capa siguiente. Capa de servicios: Se encarga del procesamiento de reportes, visualización de información y mapas e interfaces de carga de datos. Los paquetes principales que conforman estas capas son los siguientes: 6.1. Paquetes de la Capa de Adaptación 6.1.1. Fachada En este subpaquete se agrupan los manejadores de tipos de acceso al sistema: los dos tipos de administradores de bases de datos, la comunicación sincrónica que debe hacer en el momento de descargar datos para hacer consultas y la comunicación asincrónica que debe hacer en el momento de subir datos. 6.2. Paquetes de la Capa de Administración de Servicios 6.2.1. paquete servicios. Estos paquetes pueden denorminarse como el core del sistema. En estos se encuentran los elementos responsables de cargar e instanciar los servicios atómicos a ejecutar. 6.3. Paquetes de la Capa de Servicios del negocio Los subpaquetes de este paquete se encargan de instanciar todas las funciones de consulta, modificación, agregación o eliminación con el que debe contar un GIS orientado al manejo de información cartográfica.