Documento de Arquitectura de

Software
Versión 1.0

Historia de la Revisión

Fecha Versión Descripción Autor

22 de Mayo de 1.0 Descripción de la arquitectura Nadia Alvarez
2006
Juan Gómez

1. Introducción 3
1.1. Propósito 3
1.2. Alcance del documento 3
1.3. Definiciones, Siglas y Abreviaturas 3
1.4. Referencias 4
1.5. Visión Global 4
2. Análisis de la solución a implementar 4
2.1. Generalidades 5
2.2. Diseño General de la solución a implementar 5
 Capas Generales de la solución a implementar 7
 Overview de la Estructura Interna del Componente. 8
2.3. Transaccionalidad 8
2.4. Manejo de Errores 9
 Errores de aplicación 9
2.5. Diagramas de Secuencia de la Solución 10
3. Representación de la Arquitectura de Referencia 11
3.1. Vista Funcional 11
3.2. Vista Lógica 11
3.3. Vista de Despliegue 11
3.4. Vista de Implementación 12
4. Objetivos y Restricciones de la Arquitectura de referencia 12
4.1. Modelo Cliente-Servidor 13
 Visión General del modelo cliente-servidor 13
5. Vista Funcional 15
5.1. Casos de uso significativos 15
5.1.1. Ingresar información de monitoreo 15
5.1.2. Ingresar información predial 16
5.1.3. Realizar consultas de atributos espaciales y no espaciales 16
6. Vista Lógica 17
6.1. Paquetes de la Capa de Adaptación 18
 6.1.1. Fachada 18
6.2. Paquetes de la Capa de Administración de Servicios 19
6.2.1. paquete servicios. 19
6.3. Paquetes de la Capa de Servicios del negocio 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:
 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.
 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.

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.