Aproximación a un Prototipo de un

Sistema de Información Geográfica

de apoyo al Proceso de
Administración y Despliegue de
Fotografías Aéreas Digitales basado
en una Arquitectura Orientada a
Servicios

Pedro José Sandoval Sánchez

Universidad Nacional de Colombia

Facultad de Ciencias Agrarias, Maestría en Geomática
Bogotá, Colombia
2017

1
 Aproximación a un Prototipo de un
Sistema de Información Geográfica de
apoyo al Proceso de Administración y
Despliegue de Fotografías Aéreas
Digitales basado en una Arquitectura
Orientada a Servicios

Pedro José Sandoval Sánchez

Tesis presentada como requisito parcial para optar al título de:

Magister en Geomática

Directora:
Ph.D. Helga Duarte Amaya

Línea de Investigación:
Tecnologías Geoespaciales

Universidad Nacional de Colombia

Facultad de Ciencias Agrarias, Maestría en Geomática

Bogotá, Colombia

2017

2
 (Dedicatoria o lema)

Quien no vive para servir no sirve para vivir

Agnes Gonxha Bojaxhi

3
Agradecimientos.

A la infinita conciencia superior, a mis padres, a mi esposa y mi hijo por su comprensión y

apoyo y a los docentes de la Universidad Nacional que han ofrecido de forma amable y
desinteresada su apoyo y conocimiento.

4
Resumen
Existen diferentes posibilidades de Vehículos Aéreos no Tripulados - UAV, (Unmanned
Aerial Vehicles, por sus siglas en inglés), también conocidos como Drones. Todos ellos
ofrecen la oportunidad de aumentar el nivel de detalle temporal y espacial de la información
geográfica básica en zonas de interés que exigen mayor escala cartográfica de la que la
fotogrametría convencional puede brindar. La fotogrametría convencional es el escenario
en formación en Colombia mientras los UAV son el escenario mucho más popular a nivel
mundial. Usados como un recurso innovador en el dominio de la cartografía, los UAV
generan un gran número de fotografías, las cuales se deben administrar a través de un
Sistema de Información, de preferencia en un ambiente web que aproveche las
Tecnologías de la Información y las Comunicaciones – TIC.
Este trabajo diseña un Sistema de Información (SI) basado en conceptos de Arquitectura
Orientada a Servicios (SOA), implementado en un prototipo que permita administrar las
imágenes cartográficas tomadas con la tecnología de los UAV, para permitir su consulta
en determinadas áreas geográficas a través de un sitio web.

Este SI se diseñó usando una arquitectura que permite implementar un proceso de

negocio, el cual tiene como finalidad la prestación de servicios relativos a las fotografías
aéreas que usan la técnica de UAV.
La tesis presenta como resultado y aporte principal combinar áreas destacadas de la
Ingeniería de Sistemas y la Geomática para diseñar un sistema de información que
materializado en un prototipo, permita una idea general no detallada, basándose en los
conceptos de arquitecturas empresariales orientadas a servicios para administrar
fotografías aéreas digitales. Este diseño también hace uso de la adecuación de una
solución a un problema cambiando escalas de operación del proceso cartográfico, es decir,
se conceptualiza el proceso cartográfico en un proceso de negocio que requiere, en un
principio, una pequeña infraestructura de operación, pero dicha solución es escalable
cuando el aumento de usuarios así lo amerite, haciendo que la inversión sea mínima y
proporcional al crecimiento del momento.

Palabras clave:

Arquitectura Orientada a Servicios (SOA), Modelamiento y Arquitectura Orientado a

Servicios (SOMA), Sistemas de Información Geográfica (SIG). Servicios Web.

5
Abstract

Exist different possibilities of Unmanned Aerial Vehicles (UAVs), also known as Drones. All
of them offer the opportunity to increase the level of temporal and spatial detail of basic
geographic information in areas of interest that require a greater cartographic scale than
conventional photogrammetry can provide. Conventional photogrammetry is the scenario
in Colombia, while UAVs are the most popular scenario in the world. Used as an innovative
resource in the field of cartography, UAV generate a large number of photographs, which
must be managed through an Information System, preferably in a web environment that
takes advantage of Information and Communication Technologies - IT.

This work designs an Information System based on concepts of Service Oriented

Architecture (SOA), implemented in a prototype that allows to manage the cartographic
images taken with UAV technology, to allow its consultation in certain geographic areas
through a website.

This Information System was designed using an architecture that allows the implementation
of a business process, which has the purpose of providing services related to aerial
photographs using the UAV technique.

The thesis presents as a result and main contribution to combine outstanding areas of
Systems Engineering and Geomatics to design an information system that materialized in
a prototype, allowing a general idea not detailed, based on the concepts of enterprise
architectures oriented service to manage Digital aerial photographs. This design also
makes use of the adequacy of a solution to a problem by changing scales of operation of
the cartographic process, that is, the cartographic process is conceptualized in a business
process that initially requires a small operating infrastructure, but said Solution is scalable
when the increase of users so warrants, making investment minimal and proportional to the
growth of the moment.

Keywords:

Service Oriented Architecture (SOA), Modeling and Service Oriented Architecture (SOMA),
Geographic Information Systems (GIS). Web services.

6
Contenido
Resumen.......................................................................................................................................... 5
Abstract ........................................................................................................................................... 6
Contenido ........................................................................................................................................ 7
Lista de Tablas ............................................................................................................................. 10
Lista de Ilustraciones ................................................................................................................. 11
Lista de Ecuaciones. .................................................................................................................. 12
Lista de Símbolos y abreviaturas. .......................................................................................... 13
Motivación..................................................................................................................................... 15
Introducción ................................................................................................................................. 16
Capítulo 1 Objetivos del Estudio. ........................................................................................... 18
1.1. Planteamiento del Problema. .................................................................................................... 18
1.2. Objetivos. ................................................................................................................................. 20
1.2.1. Objetivo General. ................................................................................................................ 20
1.2.2. Objetivos Específicos ........................................................................................................... 20
1.3. Preguntas de Investigación e Hipótesis .................................................................................... 20
1.4. Delimitación del Alcance. ........................................................................................................ 21
1.5. Justificación. ............................................................................................................................. 23
Capítulo 2 Marco de Referencia. ............................................................................................. 25
2.1. Marco Teórico. ......................................................................................................................... 25
2.1.1. Arquitectura Orientada A Servicios. .................................................................................... 26
2.1.2. Arquitectura de Referencia ................................................................................................. 31
2.1.3. Metodologías Empleadas .................................................................................................... 36
2.1.4. Modelos de datos. ............................................................................................................... 38
2.1.5. BPMN................................................................................................................................... 39
2.2. Estado del Arte. ........................................................................................................................ 42
Capítulo 3 Elicitación de Requerimientos del Sistema. .................................................... 47
3.1. Requerimientos Funcionales. ................................................................................................... 47
3.2. Requerimientos No Funcionales. ............................................................................................. 49
Capítulo 4 Análisis del Sistema............................................................................................... 51
4.1. Diagrama del Proceso de Negocio. .......................................................................................... 55
4.2. Reglas del Negocio................................................................................................................... 58

7
4.3. Casos de Uso. ........................................................................................................................... 59
4.3.1. Identificación de Actores..................................................................................................... 59
4.3.2. Involucrados o Stakeholders (a quien le interesa) .............................................................. 60
4.3.3. Identificación de Escenarios. ............................................................................................... 61
4.3.4. Identificación de Casos de Uso............................................................................................ 62
4.3.5. Términos usados / glosario. ................................................................................................ 67
Capítulo 5 Diseño del Sistema................................................................................................. 68
5.1. Modelo de Dominio del Sistema. ............................................................................................. 68
5.2. Diagramas de Estado UML. ..................................................................................................... 71
5.3. Modelo de datos geográfico. .................................................................................................... 74
5.4. Servicios ................................................................................................................................... 75
5.4.1. Identificación de servicios. .................................................................................................. 76
5.4.1.1. Descomposición del Proceso. ...................................................................................... 80
5.4.1.2. Especificación de Servicios. ......................................................................................... 84
5.4.1.3. Análisis de Dependencias. ........................................................................................... 91
5.4.1.4. Análisis de Subsistemas ............................................................................................... 92
5.4.2. Componentes. ..................................................................................................................... 93
5.4.2.1. Comunicaciones............................................................................................................. 98
5.4.2.2. Estructura física. ............................................................................................................ 99
5.4.3. Catálogo de Productos Y Portafolio de Servicios. ............................................................. 100
5.4.3.1. Productos. ..................................................................................................................... 100
5.4.3.2. Portafolio de Servicios. ............................................................................................... 100
5.5. Gobierno de SOA. .................................................................................................................. 101
5.6. Objetivos Estratégicos. ........................................................................................................... 103
5.7. Modelo de Arquitectura de Referencia................................................................................... 104
Capítulo 6 Implementación del Prototipo. .......................................................................... 108
6.1. Implementación de los Servicios. ........................................................................................... 108
6.1.1. Servicio de Consulta de Información Geográfica .............................................................. 109
6.1.1.1. Operación Ingresar Área de Interés.......................................................................... 109
6.1.1.2. Operación Análisis de Cobertura. ............................................................................. 110
6.1.1.3. Operación Identificación de Imágenes ..................................................................... 110
6.1.2. Servicio Cargue de Imágenes. ........................................................................................... 111

8
6.1.2.1. Operación Cargue de Imágenes ............................................................................... 112
6.1.3. Servicio de Planeación de Vuelo ....................................................................................... 113
6.1.3.1. Operación Calcular Líneas de Vuelo ........................................................................ 113
6.2. Lenguajes. .............................................................................................................................. 114
6.3. Bases de Datos. ...................................................................................................................... 115
6.4. Componentes. ......................................................................................................................... 117
6.4.1. Sistema Operativo. ............................................................................................................ 118
6.4.2. Servidores .......................................................................................................................... 118
6.4.3. Visor................................................................................................................................... 119
6.4.4. Motor de Procesos de Negocio y Aplicación. .................................................................... 120
6.4.4.1. Secuencia del Prototipo. ............................................................................................. 123
Capítulo 7 Evaluación del Prototipo. ................................................................................... 132
7.1. Formularios de Evaluación..................................................................................................... 133
7.1.1. Evaluación de Requerimientos Funcionales...................................................................... 133
7.1.2. Evaluación de Requerimientos no Funcionales................................................................. 134
7.1.3. Evaluación de Casos de Uso. ............................................................................................. 137
7.2. Pruebas Realizadas. ................................................................................................................ 140
7.2.1. Evaluación con Actor. ........................................................................................................ 141
7.2.2. Métricas en el Prototipo. .................................................................................................. 144
7.2.2.1. Reporte de Resultados. .............................................................................................. 145
7.3. Ajustes. ................................................................................................................................... 148
7.4. Evaluación de Objetivos y Discusión. .................................................................................... 148
Capítulo 8 Conclusiones y Recomendaciones. ................................................................ 156
8.1. Respuestas a las preguntas de la investigación....................................................................... 156
8.2. Conclusiones sobre el alcanzado realmente obtenido con respecto a los objetivos. .............. 163
8.3. Trabajo Futuro. ....................................................................................................................... 165
Referencias Bibliográficas. .................................................................................................... 167
Anexos. ........................................................................................................................................ 172
Glosario ....................................................................................................................................... 173

9
Lista de Tablas
Tabla 1 Evolución de Paradigmas de Programación. .................................................................... 27
Tabla 2 Posibles formas de articulación flexible en SOA ............................................................. 29
Tabla 3 Elementos básicos de Modelamiento .................................................................................. 40
Tabla 4 Comparación entre Organizaciones proveedoras de Imágenes Digitales .................. 46
Tabla 5 Requerimientos Funcionales ............................................................................................... 48
Tabla 6 Requerimientos No Funcionales ......................................................................................... 49
Tabla 7. Reglas del negocio ............................................................................................................... 58
Tabla 8 Actores ..................................................................................................................................... 60
Tabla 9 Escenario Actualización Catastral ...................................................................................... 61
Tabla 10 Escenario Estimación de producción de Biodiesel ....................................................... 61
Tabla 11. Caso de Uso de Sistema: Consultar Producto. ............................................................. 62
Tabla 12. Caso de uso de sistema: Diseñar Vuelo. ........................................................................ 64
Tabla 13. Caso de uso de sistema: Registro de Cliente ................................................................ 64
Tabla 14. Caso de uso de sistema: Facturación y Pago de Servicios ........................................ 65
Tabla 15. Caso de uso de sistema: Entrega de producto ............................................................. 66
Tabla 16. Identificación de Clases .................................................................................................... 68
Tabla 17. Modelado de Metas de Servicio ....................................................................................... 77
Tabla 18. Áreas Funcionales y Subsistemas. ................................................................................. 80
Tabla 19. Descomposición del Proceso. .......................................................................................... 80
Tabla 20. Aplicación de la Prueba de Tornasol para Servicios (SLT): ....................................... 85
Tabla 23. Servicio de Consulta de Información Geográfica. ........................................................ 87
Tabla 24. Operación Ingresar área de interés del Servicio de Consulta de Información
Geográfica (WFS-T): .................................................................................................................... 87
Tabla 25. Operación Análisis de cobertura del Servicio de Consulta de Información
Geográfica (WPS)......................................................................................................................... 87
Tabla 26. Operación Identificación de imágenes del Servicio de Consulta de Información
Geográfica. (WPS)........................................................................................................................ 88
Tabla 27.Servicio Cargue de Imágenes. ........................................................................................... 88
Tabla 28. Operación Cargue de Imágenes del Servicio de Cargue de Imágenes ..................... 88
Tabla 29. Servicio de Planeación de Vuelo (WPS). ........................................................................ 88
Tabla 30. Operación Calcular líneas de vuelo del Servicio de Planeación de Vuelo (WPS). .. 89
Tabla 21. Análisis de dependencias ................................................................................................. 91
Tabla 22. Análisis de Subsistemas. .................................................................................................. 93
Tabla 31 Comparación de tipos de evaluación. ............................................................................ 132
Tabla 32. Evaluación de Requerimientos Funcionales ............................................................... 133
Tabla 33. Evaluación de Requerimientos no Funcionales. ......................................................... 134
Tabla 34. Evaluación del Caso de Uso "Consultar Producto". .................................................. 137
Tabla 35. Evaluación Caso de Uso de Sistema “Diseñar Vuelo”. ............................................. 139

10
Lista de Ilustraciones
Ilustración 1 Fases RUP ................................................................................................26
Ilustración 2 Marco de ejecución de SOA: ..................................................................32
Ilustración 3 Vista Lógica de la Arquitectura de referencia SOA: ..............................32
Ilustración 4 Diagrama BPMN del Modelo de Negocio: ..............................................56
Ilustración 5 Diagrama de casos de uso en ArgoUML ................................................67
Ilustración 6 Modelo Conceptual del Sistema de Información Empresarial. .............70
Ilustración 7 Modelo Lógico del Sistema de Información Empresarial. ....................70
Ilustración 8 Modelo Físico del Sistema Empresarial: ................................................71
Ilustración 9 Diagrama de estado de Registro e Inicio de Sesión. ............................71
Ilustración 10 Diagrama de estado del Planeación de Vuelo. ....................................72
Ilustración 11 Diagrama de estado del cargue de imágenes. .....................................72
Ilustración 12 Diagrama de estado de Entrega De Productos....................................73
Ilustración 13 Diagrama de estado de Entrega De Productos....................................73
Ilustración 14 Modelo Conceptual del SIG ..................................................................74
Ilustración 15 Modelo Lógico del SIG: .........................................................................74
Ilustración 16 Modelo Físico del SIG: ..........................................................................75
Ilustración 17 Subproceso de inscripción e inicio de sesión: ...................................81
Ilustración 18 Subproceso de Consulta.......................................................................81
Ilustración 19 Subproceso de Análisis de Cobertura. ................................................82
Ilustración 20 Diseño de Vuelo. ....................................................................................82
Ilustración 21 Subproceso Producción. ......................................................................83
Ilustración 22 Subproceso de Pago. ............................................................................83
Ilustración 23 Subproceso de Entrega.........................................................................83
Ilustración 24 Diagrama de Despliegue. ......................................................................95
Ilustración 25 Diagrama de clases para el nodo de ServicioGeografico. ..................96
Ilustración 26 Estructura física.....................................................................................99
Ilustración 27 Capa de Gobierno. ...............................................................................104
Ilustración 28. Capa de Arquitectura de Información: ..............................................105
Ilustración 29. Capa de Calidad del Servicio. (Requerimientos no funcionales) ....106
Ilustración 30. Capa de Integración. ..........................................................................106
Ilustración 31. Capas de Procesos de Negocio, Servicios, Componentes y S.
Operativos ............................................................................................................107
Ilustración 32 Paneles y herramientas del visor Heron MC. .....................................109
Ilustración 33 Resultado de la búsqueda. .................................................................110
Ilustración 34 Visualización de Imagen. ....................................................................111
Ilustración 35 Cargue de Imágenes............................................................................112
Ilustración 36 Generación de líneas de vuelo ...........................................................113
Ilustración 37 Interfaz de Bonita Studio.....................................................................120
Ilustración 38 Administrador en el Portal de Bonita BPM. .......................................121
Ilustración 39 Diseñador de Interfaz de Usuario. ......................................................121

11
Ilustración 40 Interfaz para diseño de páginas web..................................................122
Ilustración 41 Interfaz del Editor de Formularios. .....................................................122
Ilustración 42 Editor de Widgets Personalizados. ....................................................123
Ilustración 43 Portal Corporativo. ..............................................................................123
Ilustración 44 Acceso a servicios. .............................................................................124
Ilustración 45 Asignación de Actividades. ................................................................124
Ilustración 46. Actualización de Actividades.............................................................125
Ilustración 47 Formulario de Consulta Espacial. ......................................................125
Ilustración 48 Asignación de la Actividad de Diseño. ..............................................126
Ilustración 49 Resumen Actividad de Diseño............................................................127
Ilustración 50 Asignación tarea de aprobación - calculo automático......................127
Ilustración 51 Ejemplo Reporte de Cotización. .........................................................127
Ilustración 52 Asignación Actividad de Pago............................................................128
Ilustración 53 Ejemplo de Formulario para escoger tipo de pago. ..........................128
Ilustración 54 Asignación de la actividad de producción.........................................129
Ilustración 55 Ejemplo de formulario para iniciar procesos de producción. ..........129
Ilustración 56 Asignación Actividad de Entrega. ......................................................130
Ilustración 57 Compuerta para Bucle de Reclamos. .................................................130
Ilustración 58 Asignación Actividad de Reclamos....................................................131
Ilustración 59 Ejemplo Formulario de Descripción del Problema. ...........................131
Ilustración 60 Fin del Proceso. ...................................................................................131
Ilustración 61 Modelo generado con Bizagi BPM......................................................140
Ilustración 62 Reporte de resultados 1. .....................................................................145
Ilustración 63 Reporte de resultados 2. .....................................................................146
Ilustración 64 Reporte de resultados 3 ......................................................................147
Ilustración 65 Reporte de actividad Consulta. ..........................................................147

Lista de Ecuaciones.
Ecuación 1 .....................................................................................................................90
Ecuación 2 .....................................................................................................................90
Ecuación 3 .....................................................................................................................91

12
 Lista de Símbolos y abreviaturas.
Abreviatura Sigla en Ingles Término
Association for Cooperative Operations Asociación para el Desarrollo e
ACORD
Research and Development Investigación de Operaciones Cooperativas
Atomicity, Consistency, Isolation, Atomicidad, Consistencia, Aislamiento,
ACID
Durability. Durabilidad.
BCM Business-Centric Methodology Metodología Centrada en el Negocio
Notación para Administración de Procesos
BPMN Business Process Modeling Notation
de Negocio
BPM Business Process Management Administración de Procesos de Negocio.
Computer Assisted Software Ingeniería de Software Asistida por
CASE
Engineering Computadora.
Consistency, Availability, Partition Consistencia, Disponibilidad, Tolerancia al
CAP
tolerance Particionamiento
CSS Cascading Style Sheets Hoja de Estilos en Cascada
Common Object Request Broker Arquitectura Común de Agente de Solicitud
CORBA
Architecture de Objetos
CRUD Create, Retrieve, Update, Delete Crear, Recuperar, Actualizar, Borrar
DEM (Digital Elevation Model) Modelo Digital de Elevación
DTM (Digital Terrain Model) Modelo Digital de Terreno
EAI Enterprise Architecture Integration Integración de Arquitecturas Empresariales
GSD Ground Sample Distance Distancia de la Muestra en Terreno
HTML HiperText Markup Language Lenguaje de Marcas de Hipertexto
HTTP Hypertext Transfer Protocol Protocolo de Transferencia de Hipertexto
IDEF Integrated DEFinition Definición Integrada
IAA Insurance Application Architecture Arquitectura de Aplicaciones de Seguros
IT Information Technologies Tecnologías de la Información (TI)
IVR Interactive Voice Response Respuesta de Voz Interactiva
JXDD Justice XML Data Dictionary Diccionario de Datos XML de Justicia
KML Keyhole Markup Language
LBS Localization Based Services Servicios Basados en Localización
Detección de Imágenes Laser y
LIDAR Laser Imaging Detection and Raging
Distanciómetro
MOM Message Oriented Middleware Middleware Orientado a Mensajes
NoSQL Not Only SQL No solo SQL
OGC Open Geospatial Consortium Consorcio Geoespacial Abierto

13
ORB Object Request Broker Agente de Solicitud de Objetos
RPC Remote Procedure Call Llamada a Procedimiento Remoto
RUP Rational Unified Process Proceso Unificado de la compañía Rational
REST Representational State Transfer Transferencia de Estado Representacional
RMI Remote Method Invocation Método de Invocación Remota
SIG Sistema de Información Geográfica
SDLC Software Development Life Cycle Ciclo de Vida del Desarrollo de Software
SOA Service Oriented Architecture Arquitectura Orientada a Servicios
SOAP Simple Object Access Protocol Protocolo de Acceso a Objeto Simple
Service Oriented Modeling and Modelado y Arquitectura Orientados a
SOMA
Architecture Servicios
SLD Style Layer Descriptor Descriptor de Estilos de Capas
SLT Services Litmus Tests Pruebas de Tornasol para Servicios
SQL Structured Query Language Lenguaje Estructurado de Consultas
UAV Unmanned Aerial Vehicle (Drone) Vehículo Aéreo no Tripulado (Dron)
Universal Description, Discovery and Descripción, Descubrimiento e Integración
UDDI
Integration Universal
UML Unified Modeling Language Lenguaje Modelamiento Unificado
WCS Web Coverage Service Servicio Web de Coberturas
Servicio Web de Capa Vectorial –
WFS-T Web Feature Service - Transactional
Transaccional
Lenguaje de Etiquetas para dispositivos
WML Wireless Markup Language
Inalámbricos
WMS Web Map Service Servicio Web de Mapas
WSDL Web Services Description Language Lenguaje de Descripción de Servicios Web
XML eXtensible Markup Language Lenguaje de Marcas Extensible

14
Motivación.
El ambiente tecnológico empresarial en el área de la fotogrametría de objeto cercano ha
popularizado técnicas empíricas y casi artísticas (aeromodelos modificados), donde se
emplean combinaciones de artefactos óptico-electrónicos y aerodinámicos que se han ido
sofisticando para llegar a los drones1 comerciales. Estos dispositivos son cada vez más
accesibles a un mayor número de usuarios en virtud de su menor costo, tamaño y
versatilidad, mejorando cada vez la resolución (espacial y temporal) gracias a su facilidad
de uso. La necesidad permanente de actualización de la información geográfica básica,
capturada por satélites alrededor del globo, permite la incursión de nuevas empresas en el
mercado de la cartografía, trayendo novedosos avances tecnológicos.
Con el fin de aprovechar esta oportunidad de mercado, visualizada a partir de la
popularización de artefactos y aunarla a tecnologías Web que permitan interoperabilidad,
se observa la posibilidad de diseñar un Sistema de Información e implementarlo a través
de un prototipo que, vía un proceso de negocio específico, permita administrar y
automatizar procesos de captura de información para actividades como la actualización
catastral, estudios, diseños y seguimiento de proyectos de infraestructura de transporte o
de redes, prevención y atención de desastres, entre otros. Todo, haciendo la información
más próxima a usuarios con poco conocimiento de cómo se produce tal información.
Los procesos y aplicaciones en cartografía exigen actualización permanente y por lo tanto
una captura de datos de manera expedita para llevar a cabo tal actualización. Incluso los
cambios o factores climáticos que afecten escenarios de producción o población en riesgo,
pueden ser rápidamente monitoreados con un sistema diseñado para tal fin.
La necesidad de veracidad y rapidez en la producción de información geográfica exige una
lógica de proceso que satisfaga expectativas de sencillez y eficiencia para resolver
problemas cada vez más complejos debido al crecimiento natural del sistema social y el
uso de la información geográfica.
En el contexto que este trabajo ha desarrollado, el proceso de negocio diseñado permite
mostrar una manera de trabajar con fotografías aéreas (F.A.) tomadas con drones, con el
objetivo de bajar costos en el levantamiento cartográfico y por lo tanto hacerlas más
accesibles a los usuarios. Con el uso de los drones en aumento, la producción y
disponibilidad de F.A. puede llevarse a cabo en un menor tiempo y a un menor costo.

1 Anglicismo popular equivalente a zángano en traducción al castellano.

15
Introducción
Las organizaciones son cada vez más dependientes de los sistemas de información como
herramienta de apoyo para la toma de decisiones. En el ámbito de las aplicaciones
científicas o de la gestión de recursos, la bondad de una decisión se evalúa en virtud de
los problemas que soluciona y de los impactos positivos sobre áreas relacionadas
directamente e indirectamente con los motivos de tal decisión.
En el dominio de la Información Geográfica - IG, a medida que las organizaciones fueron
descubriendo la importancia de la información espacial en la toma de decisiones (Smith &
Collock, 1999), también se fue evidenciando la necesidad de tener datos veraces y
actualizados de éste tipo de información. Diversas técnicas han evolucionado a tecnologías
en el campo de los dispositivos de captura para adquirir información de la superficie
terrestre, los adelantos en la capacidad de almacenamiento, velocidad de procesamiento
del hardware y niveles de abstracción del software, a su vez, potencian la capacidad de
análisis de datos y la comunicación entre aplicaciones.
Los sistemas distribuidos e internet han facilitado el acceso a la información espacial. Las
primeras generaciones de Sistemas de Información Geográfica - SIG, tuvieron problemas
de flexibilidad y escalabilidad, ya que no se acomodaban a necesidades como el uso de
datos distribuidos o el aprovechamiento de recursos de máquina del usuario, tampoco se
adaptaban a los cambios como el incremento exponencial de usuarios, o la adaptación,
mantenimiento y modificación del software en diferentes entornos operativos de hardware
(Reinhardt, 2000).

Desde comienzos de los 80, se ha demostrado cómo los principios de ingeniería de

software pueden ser aplicados al desarrollo de procedimientos para mejorar la
productividad en la captura y análisis de datos geográficos.
Los SIG han incrementado la capacidad de análisis de múltiples tipos de datos del mundo
real, estos datos pueden ser geográficos, financieros, científicos, etc. El procesamiento de
datos geográficos en sistemas de referencia globales ha devenido en infinidad de
aplicaciones personalizadas, por ejemplo los Servicios Basados en Localización - LBS. A
su vez, los resultados de ésta multiplicidad de aplicaciones pueden ser empleados como
insumos de otras aplicaciones; por ejemplo en las redes de distribución de servicios las
cuales se amplían en la medida en que puedan encadenar servicios cada vez más
distantes. Una analogía para los términos de mercado y regulaciones, según el autor del
presente trabajo, sería el acople entre lenguaje de negocios y lenguaje tecnológico

16
apoyados por los conceptos de Servicios Web y SIG distribuidos. La demanda de
información geográfica actualizada se traduce en diseñar un servicio que cumpla
regulaciones estándar del mercado y sea fácil de encontrar y adquirir por los usuarios
interesados. La necesidad de este servicio es el objetivo de este proyecto y se alcanzará
diseñando un SIG basado en una arquitectura orientada a servicios – SOA.

En el área de la Información Geográfica, la superficie del planeta cambia constantemente

tanto a nivel cultural o antrópico como natural. Estos cambios requieren actualizaciones
cada vez más frecuentes así como mayor acceso a los cambios que presenta esta
información. Un sistema de información orientado a servicios, facilita la disponibilidad del
historial de cambios relativos a cualquier fragmento geográfico a una escala más local que
global, es decir a grandes escalas; 1:2000, 1:1000, 1:500 e incluso mayores. La escala
temporal también se puede manejar según la disponibilidad de vehículos aéreos (varios
vuelos diarios) dependiendo de restricciones legales.

El alcance está definido por el prototipo del sistema de información geográfica en la sección
1.4. Delimitación del Alcance, al cual se accederá a través de un navegador de internet
mediante unas interfaces que ofrezcan un visor geográfico y permitan al usuario hacer una
consulta de información acerca de fotos aéreas disponibles para adquisición, recibiendo
de esta manera una respuesta a su consulta espacial de fotos aéreas en un área que el
usuario dibuja en el browser. Este prototipo ejemplarizará los casos de uso para un usuario
que desee consultar un grupo de imágenes que han superado los filtros que el mismo
usuario crea según su conveniencia u opciones que se especificarán más adelante.

A medida que los SIG se han ido integrando con las TIC, la ingeniería de software ha sido
una herramienta de apoyo para el desarrollo de aplicaciones SIG. Así, en este proyecto se
utilizan los conceptos de Fotogrametría, SIG e Ingeniería de Software para determinar la
función de negocio de una organización (Lo Chong & Yeung, (2007). Estas áreas son
combinadas con técnicas estándares de modelado para crear Sistemas de Información y
de Procesos de Negocio.

17
Capítulo 1 Objetivos del Estudio.
1.1. Planteamiento del Problema.
El principal problema que se desea resolver con el diseño de este Sistema de Información
Geográfica2, es el bajo acceso a la información geográfica actualizada. Lo anterior no
permite responder rápidamente en el momento de una catástrofe o emergencia, exigiendo
una actualización permanente de cualquier tipo de datos geográficos para que estén al
alcance de la población civil interesada lo antes posible. En virtud del diseño desde el punto
de vista técnico y del bajo costo de operación, con el uso de drones, se podrán llevar a
cabo vuelos de reconocimiento a intervalos de tiempo mucho menores, lo que redundará
en una actualización de terreno mucho más fidedigna y eficiente.

Se entiende que la problemática principal es el bajo acceso a la información, puesto que

el costo de las fotografías aéreas digitales es bastante alto, sobre todo para imágenes
digitales recientes ya sea de satélites u otras plataformas de captura como los aviones. El
problema a la vez se entiende como la falta de un sistema de información para la gestión
de la producción masiva de imágenes capturadas por unidades o por flotas de drones, lo
que conduce a la necesidad de administrar dichas fotografías y ponerlas a disposición de
potenciales usuarios mediante el diseño de un proceso de negocio, desplegado a través
de una aplicación web. Para resolver la problemática mencionada, se diseñara un Sistema
de Información Geográfica basado en el paradigma de Arquitectura Orientada a Servicios
y se implementará mediante un prototipo.

De acuerdo con la experiencia principalmente académica del autor de este trabajo, el

aumento de la población y la precaria planeación territorial han hecho que tanto los
asentamientos humanos, como los medios para abastecer dicha población hayan dado
lugar a soluciones pensadas únicamente en el corto plazo, y que por lo tanto no tuvieron
en cuenta los diferentes fenómenos que amenazarían la permanencia de la población y los
medios de abastecimiento, lo que incrementa el problema con el paso del tiempo.
A pesar de la multiplicidad de sensores e instrumentos de monitoreo in situ, existe un grado
de impredictibilidad en la detección de terremotos, erupciones volcánicas, deslizamientos,

2 De cuyo diseño solamente se implementará un prototipo con algunas funcionalidades

18
inundaciones, además de las amenazas antrópicas como los derrames de petróleo,
destrucción del recurso hídrico por explotación minera, fenómenos asociados al
incremento de la actividad solar, calentamiento global, etc., la certeza es estos cambios
van a suceder y si se tienen escasos mecanismos de prevención, éstos cambios tomarán
a la población por sorpresa. Estos sucesos en el espacio geográfico exigen una acción
inmediata para solucionarlos y una visión amplia de este espacio siempre será una buena
opción. Sin embargo, actualmente la planeación y ejecución de acciones de prevención,
atención o mitigación son demorados (con lapsos de tiempo comprendidos en días o
semanas para su ejecución), debido a que las plataformas de operación de imágenes
aéreas son generalmente muy complejas para escalas cartográficas de 1:5.000 a 1:1.000
y superiores, además de que en el escenario nacional los métodos de captura aún son
escasos.

19
1.2. Objetivos.
1.2.1. Objetivo General.
Desarrollar un prototipo de Sistema de Información Geográfica que soporte el proceso de
negocio relacionado con el uso, administración y despliegue de fotografías aéreas
digitales, usando una arquitectura orientada a servicios.

1.2.2. Objetivos Específicos

- Diseñar y modelar el proceso de negocio para la administración de fotografías aéreas
digitales desde el punto de vista de la Geomática y los SIG.
- Analizar y determinar el gobierno, las reglas de negocio, los stakeholders, los usuarios
y los servicios de soporte del proceso, para el tratamiento de fotografías aéreas
digitales utilizando una arquitectura orientada a servicios.
- Definir y organizar la ejecución del proceso de negocio apoyándose en las tecnologías
disponibles en el mercado para tal fin.
- Exponer el proceso de negocio diseñado como un servicio sobre internet con el fin de
hacerlo visible para consumo de los usuarios.

1.3. Preguntas de Investigación e Hipótesis

La investigación plantea 4 preguntas iniciales a partir de las cuales se establece la
hipótesis:
1. ¿Cómo administrar eficiente y eficazmente las fotografías aéreas digitales en un
entorno web?
2. ¿Cómo ayudan los conceptos de SOA a los SIG para la administración de
Fotografías Aéreas Digitales?
3. ¿Qué especificaciones tecnológicas en hardware y software son necesarias para la
administración y control de las Fotografías Aéreas Digitales?
4. ¿Cómo ha de ser diseñado el proceso de negocio para monitorear y rastrear la
captura de fotografías y la actividad de los servicios?
La respuesta a estos interrogantes plantea la implementación del prototipo de un sistema
de información geográfica, que usando el paradigma SOA, materialice un sistema de
información web para administrar y poner a disposición de los usuarios imágenes
digitales aéreas capturadas por drones.

20
1.4. Delimitación del Alcance.
Diseñar e implementar mediante un prototipo, un Sistema de Información que permita la
consulta de fotografías aéreas digitales (imágenes captadas por drones) y el trazado de
líneas de vuelo para regiones que aún no disponen de material, además de permitir la
administración y monitoreo de las actividades relevantes para la captura de fotografías
aéreas vía el proceso de negocio definido.
Durante la etapa de diseño son asumidos procesos o escenarios de forma que la
abstracción para un diseño de alto nivel conceptual permita concentrarse en los
componentes más generales del sistema, evitando particularidades con detalles excesivos
que no se contemplan dentro del diseño global y no aportan información a los objetivos del
trabajo. No se tienen en cuenta ciertos detalles de codificación del sistema diseñado (pero
si del prototipo), o detalles fotogramétricos como los procesos de aerotriangulación,
restitución, generación de DEM o DTM. Sin embargo fueron necesarios ciertos parámetros
de vuelo y cámara fotogramétrica o alturas para calcular áreas de fotos, que aunque que
son bastante variables en función de la marca de la cámara o las condiciones del terreno,
se necesitaron como un ejemplo en el prototipo. Tampoco se hacen observaciones acerca
de diferentes procesos y productos como la georreferenciación, la ortorrectificación, la
clasificación digital supervisada o no supervisada de imágenes, ni los ortofotomapas o los
métodos y software para generar cualquiera de estos productos, puesto que son opciones
que puede ofrecer una organización y su especificación no es el alcance de este prototipo.
Cabe aclarar que como parte del diseño se podrían poner a disposición del usuario otros
productos geográficos, resultado de diferentes procesamientos sobre fotografías aéreas
digitales para diferentes rangos espectrales de sensores activos y pasivos. Estos
productos son específicos de la implementación de un sistema ya visualizado pero más
complejo, en un ambiente de producción y que se encuentre en operación, por lo que no
serán objeto del presente trabajo.

Otro aspecto a tener en cuenta es la cobertura o extensión terrestre para la cual pueden
ser útiles los drones. En este tema el límite puede ser definido por dos situaciones
generales: (i) el alcance de la comunicación entre el control de maniobras y el dron, en
caso de que dicho dron no sea programable o no trabaje de manera autónoma, o (ii) por
el tiempo de actividad máximo que permita la fuente de energía del dispositivo. Sin

21
embargo es claro que se puede cubrir cualquier extensión si ésta se subdivide en vuelos
que cumplan las restricciones dadas por la tecnología usada.
En cuanto a las bases de datos, se implementará solamente la base de datos geográfica
puesto que la implementación de la base de datos corporativa, no tiene una participación
relevante para la parte práctica del trabajo.

En cuanto a la parte de implementación del prototipo, tal y como se observa en el marco

teórico, SOA es un paradigma para el diseño de arquitecturas de sistemas de información
y es la evolución de técnicas y paradigmas de la programación orientada a objetos junto
con el desarrollo de software basado en componentes.
El presente trabajo hace una aproximación a una arquitectura mediante la aplicación de
los conceptos de SOA, sin embargo la especificación completa de una arquitectura para el
sistema de información propuesto no incluye los sistemas legados, no serán
implementados dentro del prototipo, repositorios de servicios o un Bus de Servicios
Empresariales – ESB, tampoco se harán Patrones de Mensajes Empresariales MEP
puesto que las comunicaciones manejadas entre componentes del prototipo son
efectuadas automáticamente por el software instalado.

De acuerdo con lo anterior, el énfasis del proyecto se hace principalmente en el diseño, en

tanto que la implementación del prototipo se efectúa como una forma de materializar y
evidenciar los conocimientos y teoría adquiridos tanto en la parte de sistemas como en la
parte de Geomática, y no pretende ser una forma de aplicación detallada del diseño
propuesto.

22
1.5. Justificación.
Desde el aumento en la capacidad de procesamiento de datos hasta el aumento de la
capacidad de producción de bienes y servicios, diferentes tipos de máquinas han
demostrado ser la herramienta por excelencia para tomar actividades mecánicas o
repetitivas, optimizar procesos y aprovechar eficientemente recursos. Estos recursos en
repetidas ocasiones son mal empleados debido a la falta de información acerca de su uso.
Según Digital Globe, la empresa de comercialización de fotos de satélite de la plataforma
Quick Bird, se capturan y procesan aproximadamente 2000 Km2/minuto, en muchos casos
con resoluciones submétricas (marzo de 2015 y aumentando). Esta relación para altas
resoluciones espaciales (submétricas) presenta elevados costos, debido al manejo de un
gran volumen de datos, al costo de la infraestructura de transporte de datos, al costo de
operación de las plataformas de captura y al costo de operación del sistema. Sin embargo,
para escalas cartográficas grandes 1:5000 a 1:2000 y mayores; donde se pueden tomar
imágenes a menores alturas que las de un avión y que son útiles para aplicaciones más
detalladas o que necesiten información más actualizada como el caso del catastro, los
drones son una alternativa viable. Los costos de los recursos bajan sensiblemente cuando
se habla de plataformas de operación más ligeras del tipo aeromodelo o dron, haciendo
posible la sostenibilidad económica de los procesos, dado que los costos que se transmiten
al usuario final, se perciben mucho menos elevados que los costos de los complejos
sistemas satelitales o de aviones especializados.
Estos aspectos económicos y administrativos también tienen implícitos aspectos de control
del flujo de la información a través de un sistema de hardware y software, por lo cual se
diseñará un proceso de negocio que permita la consulta y demanda de imágenes captadas
por drones (y que también serviría para las tradicionales, si es el caso), además de la
administración y el monitoreo de las actividades relevantes para la captura de fotografías
aéreas.

La innovación y la oferta de nuevos servicios en función de la auto sostenibilidad de una

organización es la premisa y la intensión en cuanto al diseño de los servicios web. La
industria de software en la era de la información ha sido gran productora de capital, lo que
garantiza la sostenibilidad de un emprendimiento en esta área. Facebook, Twiter, o los
Servicios Basados en Localización (LBS), son buenos ejemplos y permiten ver el impacto
de aplicaciones simples de software que al convertirse en una necesidad, generan
ostensibles retornos de inversión.

23
Existen grandes empresas y agencias multinacionales dedicadas a la captura y venta de
imágenes aéreas, estas poseen sistemas de información geográfica en línea y además
implementan visores para diferentes tipos de usuarios y aplicaciones geográficas. No
obstante, el proyecto es único para un proceso de negocio que ya puede tener varias
versiones, pero cuya diferencia esencial radica en que el proceso de negocio y el escenario
son visualizados de forma local o regional, a menor costo y de gran escala cartográfica
(1:500 a 1:2000 y mayores) explotando las capacidades de los SIG y tecnologías web.

Entendiendo la sostenibilidad financiera como la capacidad de conseguir recursos para ser

procesados y servidos, en general las aplicaciones en internet se mantienen en función de
la cantidad de usuarios que las utilizan, o sea, al tener un acceso relativamente fácil a la
información geográfica y con mayor resolución, es posible garantizar la sostenibilidad del
aplicativo. El detalle importante son los porcentajes de beneficio económico; inicialmente
una estrategia sería una baja utilidad para atraer usuarios, sin que incida demasiado en la
calidad y confiabilidad de los datos; el aspecto de la confiabilidad quedaría cubierto con
reconocidas plantillas de herramientas de metadatos como SWAMI, que incluyen la
información de quien capturó el dato y a quién pertenece cada cambio. Los datos serían
protegidos solamente de la eliminación, el acceso a datos de análisis ordenados por un
usuario sería una restricción y datos crudos podrían estar disponibles a un costo razonable.

Tecnologías como Google Glass, la holografía y la realidad aumentada fortalecen la

información geográfica como una necesidad imprescindible y en aumento, abriendo un sin
número de posibilidades para negocios y aplicaciones de servicios web de todo tipo.
Aumentar el nivel de detalle de fotografías aéreas también permite la generación de
modelos de terreno y modelos de elevación más detallados alcanzando niveles de
información nunca antes imaginados.
En cuanto a la posible duda respecto a la conveniencia o pertinencia de usar SOA para un
caso como el expuesto, SOA y sus herramientas son un poderoso paradigma de desarrollo
que es empleado principalmente en casos donde:
- Los componentes de los sistemas distribuidos corren en diferentes plataformas y con
diferentes productos de diferentes vendedores.
- Se necesita exponer una aplicación para que sea usada en una red y pueda ser
encapsulada en un servicio web.
- Se construye una aplicación compuesta a partir de servicios existentes” (Guo , Gong,
Sun, & Wei, 2010).

24
Capítulo 2 Marco de Referencia.
2.1. Marco Teórico.
Existen varios temas a partir de los cuales se puede iniciar una aproximación al marco de
referencia teórico, entre estos podemos distinguir dos de forma general y los más
importantes: Arquitecturas Orientadas a Servicios SOA y Sistemas de Información
Geográfica SIG, ambos con una cantidad ingente de información y casi tantas
profundizaciones como autores puedan innovar en sus investigaciones. Aunque los SIG
son una herramienta importante en amplias áreas de estudios y análisis sociales,
medioambientales, políticos, económicos y cualquier combinación de estos; para el
presente trabajo se aborda el área de SIG desde la perspectiva de la arquitectura más que
la del desarrollo y codificación, o un exhaustivo análisis espacial, pero sin olvidar estos
como herramienta para el prototipo y los procesos de negocio planteados.
En estos términos, la investigación inicia con las metodologías y últimas tecnologías para
el desarrollo de Sistemas de Información, campo que le corresponde a la ingeniería de
software en el ámbito de la información geográfica. En el libro "An introduction to Software
Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de diseño
que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la
computación; el diseño y especificación de la estructura global del sistema es un nuevo
tipo de problema" (Garlan & Shaw, 1993).
Reconocidos autores abordan el desarrollo de software desde las etapas iniciales de
planificación, requerimientos del sistema y modelado (Sommervile, 2005), (Pressman,
2010), (Weitzenfeld, 2005) y otros; sus obras se traslapan de forma general en la definición
del problema, el desarrollo y el mantenimiento como fases globales enmarcadas en el Ciclo
de Vida del Desarrollo de Sistemas (SDLC por sus siglas en inglés), desagregándose en
diferentes etapas según el autor.
En este contexto, las herramientas de Ingeniería de Software Asistidas por Computadora
(CASE por sus siglas en inglés) son herramientas que permiten el modelado de un sistema
o algún evento del mundo real, desde la conceptualización de su objetivo hasta el diseño
de sus arquitecturas de datos y arquitecturas tecnológicas, estas herramientas
conceptualizan el Ciclo de Vida del Desarrollo de Sistemas en la automatización
(Gonzáles , Gonzáles, & Gallud, 2011). Más recientemente estas herramientas se han
especializado en las diferentes fases del ciclo de vida del software utilizando lenguajes de

25
cuarta generación para el modelamiento.
En vista de la amplia aceptación del Rational Unified Process RUP en el desarrollo de
Sistemas de Información, su metodología se adopta como principal referencia para el
desarrollo del presente trabajo. En cuanto a la aproximación a los conceptos de desarrollo
de software y los cambios que se presenten, todos serán evaluados a la luz del RUP y
UML, aunque es claro que al ser una metodología para grandes proyectos no se seguirán
todos sus procesos ni se obtendrán sus artefactos de forma rigurosa.

Ilustración 1 Fases RUP

Tomado de: https://es.wikipedia.org/wiki/Proceso_Unificado_Racional

Los SIG desde hace varios años fueron visualizados en el ambiente del mercado;
Goodchild a finales de los 80 ya discutía el estado de las aplicaciones SIG en el mercado
(Goodchild, 1989). De esta manera se puede observar la antigua relación entre los SIG y
los procesos de negocio para abordar el tema de los diagramas de flujo y cómo ha
evolucionado su notación a lo que hoy se conoce como BPMN, que es el tema central del
proceso creativo junto con el diseño de servicios en el presente trabajo.

2.1.1. Arquitectura Orientada A Servicios.

Los rápidos avances en los métodos de integración de información industrial han
incentivado un asombroso crecimiento en el uso de sistemas empresariales. Se han usado
varias técnicas para sondear los sistemas empresariales. Estas técnicas incluyen
Administración de Procesos de Negocios (BPM), administración de flujo de trabajo (WFM),

26
 Integración de Aplicaciones Empresariales (EAI), SOA, Grid Computer, y otras (Xu, 2011).
De acuerdo con el estándar ANSI/IEEE Std 1471-2000, la arquitectura es definida como la

“Organización fundamental de un sistema, incorporado en sus componentes, sus

relaciones entre sí y con el entorno, y los principios que gobiernan su diseño y
evolución” (IEEE, 2000). SOA es un paradigma de diseño arquitectónico de software
que define una interfaz entre servicios, construye toda la topología de las interfaces
de cada aplicación y las coreografías de la interacción de una serie de servicios con
el fin de alcanzar el objetivo de negocio “ (Kim & Lim, 2007).

Aunque SOA es un paradigma de desarrollo de aplicaciones basado en la tecnología de

Servicios Web, implementar Servicios Web no es tener una SOA (Josuttis, 2007). Los
paradigmas de desarrollo de sistemas evolucionaron luego de la programación
estructurada hacia el desarrollo de software orientado objetos, luego al desarrollo de
software basado en componentes y luego a SOA, estos paradigmas se comparan en el
siguiente cuadro (Saleh, Yaghoobi, & Faraahi, 2012).

Tabla 1 Evolución de Paradigmas de Programación.

Aproximación Orientación A Basado En
SOA
Parámetro Objetos Componentes
Unidad Objeto Componente Servicio
Independencia De La
Dependiente Dependiente Independiente
Plataforma
Requerimiento de Requerimiento de
Propósito De Diseño Adaptación al Cambio
Implementación Implementación
Granularidad Granularidad Fina Granularidad Fina Granularidad Gruesa
Específica de la Reusable en toda la Reusable a Través de los
Reusabilidad
Aplicación Aplicación Dominios
Especifica de la Interface Separada Especifico al Protocolo
Interface De Aplicación Objeto/Clase. Ejemplo desde los de Descripción del
IDL Componentes Servicio (Ejem. WSDL)
Enrutado a una única Enrutado a un Una Dirección de Punto
Direccionamiento
Instancia De Objeto Componente Final por Servicio
Tomado de (Saleh, Yaghoobi, & Faraahi, 2012).

SOA es un estilo de arquitectura que utiliza métodos y tecnologías que aprovisionan a las
empresas para conectar y comunicar dinámicamente aplicaciones de software entre
diferentes socios de negocios y plataformas, ofreciendo servicios genéricos y confiables
que pueden ser usados como bloques de construcción de aplicaciones, esto hace posible

27
desarrollar sistemas de información y aplicaciones más enriquecidos y avanzados (Güner,
2005).

La mayoría de las SOA actuales han sido construidas a partir de sistemas legados y
entornos distribuidos que se han consolidado con middleware y el empleo de estándares
ampliamente aceptados, sin embargo para el caso de este trabajo en una aproximación
top-down al sistema, es decir, desde las metas, estrategias y políticas hacia los datos, la
oportunidad de hacer todo correctamente orientado a servicios permite obviar o evitar
prácticas concernientes a comunicar sistemas legados puesto que se empieza desde cero,
por esto es innecesario el uso de middleware. De acuerdo con (SOA Alliance Group of
SOA Practitioners, 2006) los tres componentes de cimentación son:

“Arquitectura de Negocio: Basada en la estrategia de negocio, los objetivos, las

prioridades y los procesos. Esto también incluye los procesos de negocio, así como
la implementación de aplicaciones de negocios.

Arquitectura de Infraestructura: Este es el motor que permite una SOA y debe

abordar todos los aspectos de la infraestructura de redes, servidores, centros de
datos, cortafuegos, para aplicaciones de seguridad, vigilancia, middleware, etc.

Información y Arquitectura de Datos: Esto se refiere a la identificación de los

indicadores clave de rendimiento y las necesidades de información que guían la
empresa. Arquitectura de datos trata con el modelado lógico y físico de los datos, así
como la manipulación de datos y los datos de calidad.”

Además las SOA están compuestas de tres principales conceptos técnicos y cuatro
ingredientes (Josuttis, 2007). Iniciando con los conceptos técnicos tenemos:

Interoperabilidad: Esta referida a las conexiones entre sistemas heterogéneos y ha

evolucionado a partir de la EAI (Josuttis, 2007). Según la IEEE la interoperabilidad es la
habilidad de dos o más sistemas o componentes de intercambiar información y utilizar la
información intercambiada.
Este aspecto es cubierto mediante la utilización de estándares puesto que la
heterogeneidad se presenta al conectarse con otros sistemas en web, en estos términos
la herramienta más apta para el manejo de esta información es un visor geográfico con
servicios web WFS-T para la captura de información vectorial y WMS para el despliegue
de cartografía base ya que son estándares OGC. En estas condiciones el lenguaje más

28
apropiado es GML (Geography Mark-up Language) debido a que se ha adoptado como
estándar para codificación de información geográfica y es basado en XML, aunque en las
opciones del servicio se pueden habilitar otros formatos para descarga de información
como KML o GeoJSON.

Bajo Acoplamiento: Concepto utilizado habitualmente para hacer frente a los requisitos
de escalabilidad, flexibilidad y tolerancia a fallos. El objetivo es minimizar dependencias.
Cuando hay menos dependencias, las modificaciones o fallos en un sistema tendrán
menos consecuencias sobre otros sistemas.
El bajo acoplamiento es un principio; no es ni una herramienta, ni una lista de verificación.
El diseñador define qué tipo y cantidad de acoplamiento introduce. Sin embargo hay
algunos temas típicos que son posibles de considerar cuando se piensa en la articulación
flexible en su sistema. Esta tabla está lejos de ser completa, pero es bastante típico de
grandes sistemas distribuidos (Josuttis, 2007).

Tabla 2 Posibles formas de articulación flexible en SOA

Conexiones físicas
Estilo de comunicación
Modelo de datos tipos
Tipo de sistema
Patrón de interacción
Control de lógica de proceso
Enlaces
Plataforma dependencias
Transaccionalidad
Despliegue
Versionado
Fuerte acoplamiento Bajo Acoplamiento
Punto a punto A través mediador
Síncrona Asíncrono
Tipos complejos comunes Solo tipos comunes simples
Fuerte Débil
Navega por árboles de objetos Centrado en los datos,
complejos mensaje auto contenido
Control central Control distribuido
Estáticamente Dinámicamente
Fuerte dependencia de la
Independiente de la plataforma
plataforma
Two Phase Commit 2PC (en
Compensación
dos fases)
Simultáneo En diferentes momentos
Actualizaciones explícitas Actualizaciones implícitas
Tomado de: (Josuttis, 2007).

Esto no es una lista de verificación. No existe certificación de conformidad con SOA

diciendo que todos o, al menos, el 50 por ciento de las formas de bajo acoplamiento están
en uso. Sin embargo, sería muy extraño que ninguna de estas formas de bajo acople se
utilicen en una SOA. Si esto fuera posible, el sistema parecería no tener los requisitos

29
comunes de grandes sistemas distribuidos (Josuttis, 2007). El acoplamiento desde el punto
de vista de las bases de datos y haciendo referencia al lenguaje de consulta, tiene que ver
con los tipos de bases de datos conocidos que pueden ser relacionales o no relacionales
(SQL o NoSQL), para lo cual se propone una base de datos hibrida3, es decir que maneje
ambos tipos según la necesidad.
El hecho de usar uno u otro lenguaje implica un acoplamiento no solo con el lenguaje sino
con las tecnologías desarrolladas a partir de tal lenguaje, por esto la opción de software
libre para el desarrollo a la medida es fundamental para no tener que adquirir herramientas
innecesarias, o que traigan consigo problemas de compatibilidad entre versiones, o tener
que adquirir otras herramientas para aprovechar las primeras.

Es importante tener en cuenta que amén de las anteriores situaciones; el acoplamiento es

algo inevitable, aquí solo se intenta mantener en sus mínimos niveles.

Servicios y comunicaciones entre Servicios: para la realización de este concepto se ha

escogido la metodología SOMA para el descubrimiento y diseño de servicios. Según
(Josuttis, 2007) los Ingredientes de SOA son:

Infraestructura:
Comprende el software y hardware proporcionados para las actividades SOA. En cuanto
a software se encuentra en fuentes como (Josuttis, 2007), (Hurwitz, Bloor, Baroudi, &
Kaufman, 2007), (Güner, 2005) que es imprescindible el Bus de Servicios Empresariales
ESB puesto que es un aspecto de implementación clave para las comunicaciones. Sin
embargo para el prototipo de este sistema no es necesaria la implementación, puesto que
las comunicaciones del prototipo no son tan complejas como las de sistemas atendiendo
gran cantidad de usuarios, aplicaciones y comunicación con otros sistemas legados o
socios.
Arquitectura:
Este es un ingrediente bastante denso puesto que puede abarcar desde los estilos
arquitectónicos como Cliente/Servidor, n-tier, Arquitectura Impulsada por Modelos (MDA),
Arquitectura Impulsada por Eventos (EDA), etc., hasta aspectos tecnológicos de
almacenamiento, administración, comunicaciones, estándares, etc. Se utiliza una SOA.

3. En la literatura de este concepto se refiere a bases de datos no relacionales combinadas con

bases de datos orientadas a objetos. Para el presente trabajo se hace referencia a una base de
datos relacional combinada con una base de datos no relacional.

30
Procesos:
Los procesos son el encadenamiento de actividades que generan servicios, los procesos
se modelan en BPMN 2.0 puesto que es el estándar para la notación de procesos de
negocio, los diagramas hechos en este estándar se pueden traducir a BPEL para cuando
haya necesidad de cambiar entre motores de procesos (Activity, Orchestra, Open ESB…).

Gobierno:
Así como se necesita documentación para la formalización de los modelos, también se
necesita para la formalización de las responsabilidades, las políticas y las estrategias en
una SOA.

Aunque el tema de SOA ha alcanzado una etapa de madurez en cuanto a los conceptos
principales, cada autor o grupo de autores tienen enfoques diferentes con respecto a su
experiencia y necesidades, esta misma situación de enfoques se presenta en la relación
entre SOA y SIG. Los SIG son una herramienta de apoyo espacial a las SOA; en el
problema propuesto sirven para el aprovechamiento de las capacidades de análisis de
procesos junto al permanente rediseño o reingeniería que necesitan los modelos de
negocio en sistemas abiertos (Davenport, 1993). Otra forma de ver el enlace entre las SOA
y los SIG se halla en los servicios de información, despliegue y procesamiento de datos
geográficos.

2.1.2. Arquitectura de Referencia

Una arquitectura de referencia modela elementos arquitecturales abstractos en el dominio
de interés, independientemente de las tecnologías, los protocolos y productos que son
usados para implementar una solución específica para el dominio. Difiere de un modelo de
referencia en que el modelo de referencia describe conceptos importantes y las relaciones
en el dominio enfocándose en lo que distingue los elementos del dominio; la arquitectura
de referencia elabora más en el modelo para mostrar un cuadro más completo que incluye
mostrar las implicaciones de la realización de las entidades modeladas mientras
permanece independiente de soluciones particulares (OASIS, 2012).

Fabricantes destacados de software (Hewlett-Packard, BEA, Oracle, Microsoft, etc.) e

incluso los menos conocidos así como también los grandes consorcios (OGC, W3C,
OASIS, etc.) tienen arquitecturas propias y profusamente documentadas, esto es evidente
puesto que cada organización es única, aunque esté compitiendo con similares por el

31
mismo mercado. Se observan varias opciones de arquitecturas de referencia, pero la
elección queda atada a la que ofrece la metodología SOMA, no solo por coherencia sino
porque es la que mejor se ajusta a las actividades desarrolladas previas al hallazgo de
dicha metodología, aun así la arquitectura de referencia para SOMA puede variar
ligeramente según el autor o puede ser expuesta de forma más simplificada por otros
documentos, como se observa a continuación donde se expone como un framework de
ejecución.

Ilustración 2 Marco de ejecución de SOA:

Tomado de: Government's Adoption of SOA and SOA Examples Presented by: Ajay Budhraja,

El documento de IBM adoptado para el presente caso ofrece el siguiente diagrama:

Ilustración 3 Vista Lógica de la Arquitectura de referencia SOA:

Tomado de: (IBM, 2008)

Las arquitecturas han evolucionado desde el modelo cliente/servidor en función de la

escalabilidad y el mantenimiento hacia arquitecturas de 3-capas y luego a n-capas,
aumentando así la complejidad de forma simultánea con el aumento de capacidad de los

32
diferentes dispositivos. La arquitectura de referencia de la metodología SOMA presenta un
modelo de 9 capas, sus descripciones se hacen necesarias ya que son el eje central de
trabajo para el descubrimiento de servicios.

Capa 1. Sistemas operativos: contiene los sistemas operativos que existen en el

ambiente real de TI en la empresa apoyando las actividades de negocios. Incluye
aplicaciones personalizadas, paquetes de aplicaciones, sistemas legados, sistemas de
procesamiento de transacciones y las bases de datos (IBM, 2008).

Capa 2. Capa de componentes de servicios: los componentes en esta capa se ajustan

a los contratos definidos por los servicios en la capa de servicios. Un componente de
servicio puede comprender uno o más servicios y proporciona una fachada de
implementación que agrega la funcionalidad de los sistemas operativos múltiples y
posiblemente dispares, a la vez que oculta las complejidades de integración y de acceso
del servicio expuesto a los consumidores. Así, el consumidor es agnóstico del componente
de servicio, que encapsula la complejidad de ejecución. La ventaja de este componente
fachada proviene de la flexibilidad de cambiar los sistemas operativos sin afectar a la
definición de servicio. El componente de servicio proporciona un punto de aplicación en la
realización de servicios para garantizar la calidad de servicio (QoS) y el cumplimiento de
acuerdos de nivel de servicio (IBM, 2008).

Capa 3. Capa de servicios: incluye todos los servicios definidos en el portafolio de

servicios, definición de cada servicio, información sintáctica y semántica. Mientras la
información sintáctica es esencialmente acerca de las operaciones en cada servicio, los
mensajes de entrada y salida y la definición de las fallas del servicio, la información
semántica es acerca de las políticas de servicio, las decisiones de administración de
servicios, requisitos de acceso al servicio, y así sucesivamente. Los servicios se definen
de tal manera que sean accesibles e invocables por canales y consumidores
independientes de la aplicación y del protocolo de transporte. El paso crítico es la
identificación de los servicios utilizando las diversas técnicas que se pueden emplear para
el mismo (IBM, 2008).

Capa 4. Capa de Procesos de negocio: Describe cómo funciona el negocio. Esta capa
representa los procesos como una orquestación o una composición de servicios con bajo
acoplamiento aprovechando los servicios representados en la capa de servicios. La capa
también es responsable de toda la gestión del ciclo de vida de los procesos, junto con su

33
orquestación y coreografía. El flujo de datos e información entre los pasos dentro de cada
proceso también se representa en esta capa. Los procesos representados en esta capa
son el medio de conexión, entre los requerimientos del negocio y su manifestación en
forma de soluciones a nivel de TI, utilizando bloques de construcción de arquitectura de
otras capas horizontales y verticales en la pila de la arquitectura (IBM, 2008).

Capa 5. Capa de Consumidores: Esta capa representa los diversos canales a través de
los cuales se entregan las funciones de TI. Los canales pueden estar en forma de
diferentes tipos de usuarios (por ejemplo, los externos y los consumidores internos que
acceden a la funcionalidad de la aplicación a través de los mecanismos de acceso como
los sistemas B2B, portales, clientes enriquecidos, y otras formas). El objetivo de esta capa
es la estandarización del protocolo de acceso y el formato de datos, para permitir la
creación rápida de front-ends para procesos de negocio y servicios expuestos de las capas
inferiores. Algunos de estos estándares se han convertido en forma de portlets,
componentes de Arquitectura de componentes de servicios (SCA) y Servicios Web para
Portlets Remotos (WSRP) (IBM, 2008).

Capa 6: Capa de Integración: proporciona la capacidad para que los consumidores de

servicios localicen a los proveedores de servicios e inicien las invocaciones de servicios.
A través de las tres capacidades básicas mediación, enrutamiento y transformación de
protocolos y datos, esta capa ayuda a fomentar un ecosistema de servicios en el que los
servicios se pueden comunicar entre sí, mientras son parte de un proceso de negocio. Los
requisitos no funcionales clave como la seguridad, latencia y la calidad del servicio entre
las capas adyacentes de la arquitectura de referencia, son implementados por los bloques
de construcción de arquitectura en esta capa. Las funciones de esta capa normalmente y
cada vez más, se están definiendo colectivamente como el bus de servicios empresariales
(ESB). Un ESB es una colección de patrones de arquitectura que utiliza estándares y
protocolos abiertos para aplicar las capacidades básicas de esta capa y proporcionar una
capa de direccionamiento indirecto entre los consumidores de servicios y el proveedor de
servicios mediante la exposición de servicios a través del ESB. Productos ESB suelen
añadir algunas características especializadas para proporcionar capacidades
diferenciadas en el mercado (IBM, 2008).

Las capacidades de integración son más utilizadas por bloques de construcción de

arquitecturas y residen entre la Capa 2 y la Capa 5. La belleza de la capa de integración

34
basada en ESB es que cualquier función o característica que puede ser expuesta de una
manera; siguiendo estándares abiertos y protocolos de acceso se puede conectar a la ESB
para que se habilite a participar en un ecosistema basado en servicios. (IBM, 2008)

Capa 7. QoS Calidad del Servicio: Esta capa se centra en la implementación y gestión
de los requerimientos no funcionales (RNF) que los servicios necesitan implementar.
Aunque SOA trae una propuesta de gran valor a través de un nuevo estilo arquitectónico,
el modelo de programación que apoya la construcción de una SOA de primera clase añade
algunos desafíos inherentes no triviales de resolver. Los desafíos que surgen al tratar de
cumplir con los principios esenciales de la SOA: Abstracción, estándares y protocolos
abiertos, computación distribuida, infraestructuras informáticas heterogéneas,
ecosistemas, servicio federado, y así sucesivamente. El cumplimiento de estos
requerimientos a menudo hace que la aplicación de los NFR sea mucho más complicada.
Esta capa proporciona las capacidades de infraestructura para realizar los NFR y captura
los elementos de datos que proporcionan la información acerca del incumplimiento de los
NFR en cada una de las capas horizontales. Los NFR estándar que esta capa monitorea
son seguridad, disponibilidad, escalabilidad y fiabilidad. (IBM, 2008).

Capa 8. Capa de Arquitectura de Información: Esta capa garantiza una representación

adecuada de los datos y la información requerida en una SOA. La arquitectura de datos y
la representación de la arquitectura de información en cada capa horizontal específica
(junto con consideraciones clave y pautas de diseño y uso), son las responsabilidades de
esta capa. Modelos de la industria (ACORD, IAA, JXDD) y su uso para definir la
arquitectura de la información, junto con protocolos de negocio utilizados para el
intercambio de datos de negocio, son ejemplos de apoyo a esta capa. Esta capa también
almacena los metadatos necesarios para minería de datos e inteligencia de negocios (IBM,
2008).
Capa 9. Capa de Gobierno: Es responsable de priorizar que servicios de alto valor deben
implementarse para cada una de las capas de la arquitectura, y de proporcionar una
racionalización basada en la forma en que el servicio se ajusta a un objetivo de negocio o
de TI de la empresa. Una de las principales responsabilidades de esta capa es hacer
cumplir en tiempo de diseño y tiempo ejecución las políticas que los servicios deben
implementar y a las cuales deben ajustarse. En esencia, esta capa proporciona un marco
de trabajo que supervisa de manera eficiente el diseño y la implementación de servicios
para que cumplan con los diversos requerimientos y políticas que regulan el negocio y las

35
TI. Asegura la correcta gestión de todo el ciclo de vida de los servicios,
ésta gestión depende de la herramienta escogida y la creatividad en su utilización. Los
servicios prioritarios son los que procesan información y los que se exponen en el front-
end a partir de los servicios de procesamiento. (IBM, 2008).

La capa de gobierno de SOMA parece bastante dependiente del software de

implementación y la cuestión del gobierno puede diferir según el autor, por esto el gobierno
se establece con políticas, es decir con lo que se entiende acerca del fenómeno, el
ecosistema y el mejor aprovechamiento de los recursos. Esto es posiblemente el nivel de
abstracción más elevado y el producto de todo proceso. Las preguntas de gobierno que se
plantean (Hurwitz, Bloor, Baroudi, & Kaufman, 2007) son una buena aproximación inicial
al gobierno por permitir intensión al responderlas, es decir se intentan reflejar los objetivos
estratégicos mediante cada respuesta.

2.1.3. Metodologías Empleadas

La ingeniería de software como disciplina ha tenido una importante profundización en las
metodologías de desarrollo de software desde la década de los 80s, el Ciclo de Vida de
Desarrollo de Sistemas (SDLC) ha sido un paradigma profundamente estudiado y
extensamente empleado incluso en el desarrollo de otros paradigmas y modelos como el
modelo de cascada o el de espiral. De esta forma también ha sido un paradigma en el
desarrollo de Sistemas de información Geográfica SIG.
Se distinguen tres fases genéricas en este paradigma, la Fase de Definición del Problema,
la Fase de Desarrollo y la Fase de Mantenimiento (Pressman, 2010).
En la ciencia de los sistemas de información, el Proceso Unificado de Rational (RUP,
producto IBM) ha desagregado el desarrollo de software concebido por el SDLC en los
años 60 para adaptarse a un sistema particular. RUP evalúa los riesgos y se enfoca en el
proceso de generación de productos de software desde un punto de vista iterativo que
permite el mejoramiento continuo, ésta metodología hace un uso abundante de artefactos
y documentación, aunque es una referencia importante no se aplica de manera exhaustiva
sino global en la medida en que se traslape con SOA y en virtud del prototipo. También
cabe mencionar que UML es una metodología de gran aceptación, por lo cual se aplica
pero su acople a bases de datos relacionales puede degradar la calidad del bajo
acoplamiento general, por esto las opciones serian usar solo bases de datos NoSQL o usar
una hibridación de bases de datos. En vista de que los sistemas relacionales no se pueden

36
ignorar por haber liderado el desarrollo de sistemas, la decisión es proponer una base de
datos hibrida, es decir RDBMS+NoSQL, la posibilidad de la implementación queda sujeta
a las restricciones que se especifican en el capítulo de implementación del prototipo. En la
industria el uso de uno o el otro depende del escenario existente en infraestructura, pero
sí se diseña de forma escalable, las bases de datos NoSQL deben estar incluidas.

La investigación realizada para este trabajo, ha permitido entender una SOA como un
paradigma y un conjunto de conceptos para el desarrollo de aplicaciones llamadas
Servicios. Estos Servicios deben cumplir ciertas características conceptuales y
tecnológicas (deben permitir composición, ser descubribles, usar un lenguaje común,
cumplir estándares, etc.) para que puedan comunicarse entre sí y sean independientes de
la plataforma de operación.
SOA y su metodología de desarrollo queda embebida en la Fase de Definición del
problema del SDLC, enfocándolo a los servicios y permitiendo emplear la ingeniería de
software para modelar los procesos de negocio al tiempo que se diseñan simultáneamente
las clases, las relaciones, los casos de uso y los servicios básicos para estructurar la
información empresarial mediante los artefactos necesarios.
IBM ha desarrollado SOMA como una extensión de RUP, SOMA es una técnica que explica
cómo identificar, especificar, y realizar los servicios, los componentes de servicio y el flujo.
SOMA como metodología hace referencia a la brecha entre SOA y la orientación a objetos.
Este enfoque proporciona una metodología de modelado, análisis, técnicas de diseño y
actividades para definir las bases de una SOA, ayuda a la definición de los elementos en
cada una de las capas SOA y a tomar decisiones arquitectónicas en cada nivel.
El núcleo de SOMA es la identificación y especificación de los servicios, componentes y
flujos de proceso. A un alto nivel, SOMA es un plan de tres fases para identificar,
especificar, realizar servicios, componentes y flujos (por lo general, coreografía de los
servicios). La primera fase es la de identificación de servicio, donde se utilizan diversas
técnicas para identificar una exhaustiva lista de candidatos a servicios. La segunda fase
es la de especificación de servicios en la cual se completa un diseño detallado de servicios
y componentes (Güner, 2005).

Existen otras metodologías en el ambiente de las SOA, se observaron los rasgos generales
de metodologías como UMM (UN/CEFACT, 2011), RosettaNet (IBM, 2010 ), BCM (OASIS,
2003). Sin embargo se perfilan de manera más compleja en tanto que por ejemplo UMM
exige mayor conocimiento de UML aunque se enfoca en diseñar los Servicios que cada

37
socio debe proveer para colaborar, autodenominándose Arquitectura de Colaboración
Orientada al Servicio. RosettaNet a la vez que metodología es un framework de
implementación de Oracle que utiliza varias de sus propias herramientas y otras de IBM o
BizTalk. BCM desarrollada por OASIS, a diferencia de las anteriores presenta un nivel de
abstracción de arquitectura más elevado en términos organizativos y empresariales que
tienen de forma implícita los procesos de negocio y el descubrimiento de servicios.

2.1.4. Modelos de datos.

Debido a que SOA ha sido considerado como la evolución natural de los diferentes
paradigmas de programación, se observa que continúa su relación con las bases de datos
relacionales orientadas a objetos, por esto se hace necesario un modelo de datos para
manejar la información espacial y otro para la información empresarial, es decir un modelo
de datos corporativo y un modelo de datos geográfico.

Convencionalmente, el diseño de los modelos de datos comprende tres etapas

secuenciales de modelado: conceptual, lógica y física, tanto para el modelo corporativo
como para el geográfico. Cuando el proceso de modelado de datos se lleva a cabo en
estas tres etapas, las bases de datos llegan a ser más rigurosamente definidas, resultando
en una serie de descripciones y especificaciones formalizadas progresivamente, llamados
esquemas conceptual, lógico y físico. Bajo el concepto de entidad-relación (E-R), los
modelos pueden definirse de la siguiente forma (Lo Chong & Yeung, (2007):

Modelo conceptual: el propósito de este modelo es definir en términos amplios y

genéricos el ámbito y los requerimientos de la base de datos identificando entidades
relevantes en las funciones del negocio, atributos que caracterizan la entidad, relaciones
entre entidades y realizando el diagrama que representa los conceptos básicos del modelo.
El modelo conceptual es independiente del hardware y software que serán usados para
implementar la base de datos. Representa el nivel más alto en el modelado de datos,
debido a que describe el contenido más que la estructura de almacenamiento de la base
de datos. Usa expresiones y diagramas conocidos como esquemas conceptuales cuyo
proceso de comprensión y transformación de los requerimientos de los usuarios es
demasiado complicado para ser realizado en forma apropiada por un software.
Actualmente pueden utilizarse las herramientas CASE (Computer-Assisted Software
Engineering) para apoyar este proceso, pero luego de la etapa de conceptualización.

38
Modelo lógico: consolida, refina y convierte el esquema conceptual en un sistema
específico de modelado definido como esquema lógico, a través de tres pasos:
 Proyectar el esquema conceptual al esquema lógico.
 Identificar las claves principales y foráneas.
 Normalizar las tablas de atributos.
Para el caso de bases de datos geoespaciales se usan las entidades espaciales para
realizar el diseño de capas o coberturas de acuerdo con la estructura del software
seleccionado para implementar el SIG. El esquema lógico no representa aún la
implementación completa del modelo de datos, debido a que solo es expresado en
términos de las características de la base de datos sin tener en cuenta los requerimientos
del hardware tales como estructuras de almacenamiento y volúmenes de datos. El
propósito de este esquema es representar la base de datos en su totalidad e identificar los
problemas potenciales que podrían existir en el modelo conceptual como: datos
irrelevantes, omisiones o pérdida de datos, representación inadecuada de entidades, falta
de integración ente varias partes de la base de datos.

Modelo físico: representa el nivel más bajo en el modelado de datos. Define la estructura
específica de almacenamiento y las rutas de acceso a las bases de datos. Especifica cómo
los datos serán almacenados y cómo fluirán dentro del proceso. Por lo tanto, este modelo
es dependiente del software y del hardware que serán utilizados. El resultado es un
esquema físico conocido como diccionario de datos que contiene las características de los
ítems y las especificaciones de la base de datos física. El modelo físico puede tener
muchas alternativas de diseño, por lo que éste puede ser muy complejo en el desarrollo
de una base de datos a gran escala.

2.1.5.BPMN
El Object Management Group (OMG) ha desarrollado una Notación para Modelado de
Procesos de Negocio (BPMN) estándar. El objetivo principal de BPMN es proporcionar
una notación que sea fácilmente comprensible por todos los usuarios de la empresa, desde
los analistas de negocio que crean los borradores iniciales de los procesos, hasta los
desarrolladores técnicos responsables de implementar la tecnología que llevará a cabo
dichos procesos, y por último, a los hombres de negocios que gestionarán y monitorearan
esos procesos. Por lo tanto, BPMN crea un puente estandarizado para la brecha entre el
diseño de procesos de negocio y la implementación de procesos (OMG, 2011).

39
 Esta especificación proporciona una notación y modelo para Procesos de Negocio y un
formato de intercambio que puede ser utilizado para intercambiar definiciones de Procesos
BPMN (tanto de modelo de dominio como de diseño del diagrama) entre diferentes
herramientas. El objetivo de la especificación es permitir la portabilidad de las definiciones
de Proceso, de modo que los usuarios puedan tomar definiciones de procesos creados en
el entorno de un proveedor y utilizarlos en el entorno de otro proveedor (OMG, 2011).

Tabla 3 Elementos básicos de Modelamiento

Elemento Descripción Notación
Evento Un evento es algo que "sucede" en el curso de un proceso o una
coreografía. Estos acontecimientos afectan el flujo del modelo y por lo
general tienen una causa (trigger) o un impacto (resultado).
Los eventos son círculos con centros abiertos para permitir marcadores
internos para diferenciar diferentes factores desencadenantes o resultados.
Hay tres tipos de eventos, basados en cuando afectan el flujo: Inicio,
Intermedio y Final.
Actividad Una actividad es un término genérico para el trabajo que realiza la empresa
en un proceso. Una actividad puede ser atómica o no atómica (compuesta).
Los tipos de actividades que forman parte de un modelo de proceso son:
Sub-Proceso y tareas, que son rectángulos redondeados. Las actividades
se utilizan tanto en los procesos estándar y en coreografías.

Compuerta Una puerta de enlace se utiliza para controlar la divergencia y convergencia

de los flujos de secuencia en un proceso y en una coreografía. Así, se
determinará la ramificación, bifurcación, fusión y unión de caminos.
Marcadores internos indicarán el tipo de control de la conducta.
Flujo de Un flujo de secuencia se utiliza para mostrar el orden en que las actividades
Secuencia se realizarán en un proceso y en una coreografía.
Flujo de Un flujo de mensajes se utiliza para mostrar el flujo de mensajes entre dos
mensajes participantes que están preparados para enviar y recibir. En BPMN, dos
piscinas separadas en un Diagrama de Colaboración representarán a los
dos participantes (por ejemplo, Partner Entities y/o Partner Roles).
Asociación Una asociación se utiliza para vincular la información y artefactos con
elementos gráficos de BPMN. Anotaciones de texto y otros artefactos se
pueden asociar a los elementos gráficos. Una flecha en la Asociación indica
una dirección del flujo (por ejemplo, datos), cuando sea apropiado.
Piscina Piscina es la representación gráfica de un participante en una colaboración.
(Pool) También actúa como un "Swim lane" y un contenedor gráfico para
particionar un conjunto de actividades de otras agrupaciones, por lo general
en el contexto de situaciones B2B. Una piscina puede tener detalles
internos, en la forma del proceso que se ejecutará. O puede no tener
detalles internos, es decir, puede ser un "Recuadro negro".

Carril (Swim Un carril es un sub-partición dentro de un proceso, a veces dentro de una

lane) piscina, y se extenderá a todo lo largo del proceso, ya sea vertical u
horizontalmente. Los carriles se utilizan para organizar y categorizar
actividades.

40
Objetos de Los Objetos de Datos proporcionan información sobre qué actividades
Datos requieren ser realizadas y/o qué producen, los objetos de datos pueden
representar un objeto singular o una colección de objetos. Entrada y salida
de datos proporcionan la misma información para los procesos.

Mensaje Un mensaje se utiliza para describir el contenido de una comunicación entre

dos participantes (según la definición de un negocio o un negocio Partner
Role Partner Entity).

Grupo Un grupo es un conjunto de elementos gráficos que están dentro de la

misma categoría. Este tipo de agrupación no afecta a la secuencia de los
flujos dentro del Grupo. El nombre de la categoría aparece en el diagrama
como la etiqueta de grupo. Las categorías pueden ser utilizadas para la
documentación o con fines de análisis. Los grupos son una forma en que
las categorías de objetos se pueden mostrar visualmente en el diagrama.
(OMG, 2011).

41
2.2. Estado del Arte.
Desde hace más de cinco décadas las agencias estatales gubernamentales
norteamericanas, europeas y asiáticas han sido artífices de la adquisición, disposición y
manejo de datos geográficos. Las primeras imágenes del satélite de observación terrestre
capturadas por el Landsat 1 en 1954, fueron liberadas 55 años después de su captura
(Oyola Lepe, 2009).
La capacidad tecnológica de la sociedad actual es difícil de establecer debido a políticas
bélicas y económicas que hacen de la información un objeto de acceso restringido, solo
hasta hace poco (2007) los datos han estado siendo liberados por los gobiernos del primer
mundo (Gobierno en Línea, 2012), en buena medida por los adelantos tecnológicos que
ahora permiten mayor y más rápido acceso, lo que hace de la liberación una evolución del
fenómeno más que una iniciativa gubernamental. En fabricación de dispositivos óptico-
electrónicos con desplazamiento autónomo, agencias como la United States National Aero
spatial Agency - NASA o el United States Department of Defence - DoD tienen varias
aplicaciones ejemplares como el Predator (Colomina & Molina, 2014).
De esta forma los SIG han madurado simultáneamente con los Sistemas de Información
en general y las TIC; de sistemas aislados con geodatos estrechamente acoplados, se ha
pasado al modelo incremental de comunicación entre sistemas y a la comunicación entre
aplicaciones independientes del proveedor, todo gracias al desarrollo de tecnologías web
e Internet (Alameh, N., 2007).
La mejor oportunidad para las organizaciones se encuentra en los SIG y en la creación de
soluciones para SIG Empresariales. Con la proliferación de software y datos, los
principales problemas presentados en la industria han sido en interoperabilidad y el
ineficiente intercambio de datos entre componentes internos de una organización basada
en SIG.

Los modernos sistemas de información geográfica, combinando el reconocimiento por

satélite con el desarrollo de dispositivos móviles, permiten un mayor y más profundo
conocimiento de nuestro entorno. Estas tecnologías móviles están tan extendidas que hoy
en día es posible acceder a información visual desde cualquier lugar a través del teléfono
o tableta con internet satelital o 4G (Alameh, 2003). Las capacidades actuales fácilmente
presentan información en tiempo real de tantos datos como sea posible en función de la
calidad de la conexión y potencia del hardware; dada la amplia disponibilidad de datos
espaciales y de acuerdo a las aplicaciones según el tipo de cliente y permisos. En este

42
ambiente las SOA han madurado para diferentes propósitos comerciales y académicos
aprovechando el crecimiento y dispersión geográficos de los sistemas distribuidos
mediante iniciativas gubernamentales como INSPIRE, o las diferentes aplicaciones
académicas estadounidenses como (UCONN, 2016) con la implementación de estándares
en información geográfica y servicios web.
La fotogrametría de objeto cercano ya es popular para emporios como Google maps que
incluso ya ha traído a Colombia escáneres callejeros que extraen automáticamente
modelos digitales de elevación mediante la técnica LIDAR. Este tipo de captura excede la
resolución para los problemas planteados, y en ciertos casos no los soluciona pues el
acercamiento exclusivamente terrestre a una zona amplia puede estar impedido por vías
de acceso afectadas. No obstante, un dispositivo LIDAR es susceptible de ser instalado en
un dron.
Google Earth ofrece la posibilidad de consultar imágenes recientes de cualquier parte del
planeta aunque su deficiencia respecto al presente trabajo radica en la baja resolución que
ofrece para zonas de poca demanda de imágenes como las zonas rurales, donde la
solución que ofrece el sistema diseñado en este trabajo es de menor costo y más accesible
a un usuario con escasos recursos. Sin ahondar en detalles es fácil ver que son más
económicas y rentables las maniobras de un dron que las del tradicional cesna colombiano,
un avión comercial o un satélite.
Los visores académicos de instituciones norteamericanas o europeas permiten el acceso
a información de fotografías aéreas en el entorno local o nacional de la institución, pero
además de que las necesidades que se quieren cubrir con este proyecto en el
planteamiento del problema se encuentran principalmente en Colombia, no se ofrecen
posibilidades de planear vuelos rápidamente, sin embargo el uso de las herramientas es
digno de imitar.
En el sector comercial, por cierto precio alguien interesado en un área de gran escala
cartográfica municipal o urbana (1:2000 a 1:500 y mayores) puede solicitar imágenes de
satélite de diversas empresas internacionales, las cuales tienen en Colombia filiales o
franquicias que ofrecen la entrega de productos en diferentes formatos a través de
diferentes medios físicos.
En todos estos casos, los costos de los productos están cubriendo el mantenimiento y
operación de complejas plataformas, también el transporte y el intermediario, además en
el mejor de los casos es necesario esperar que uno de los vehículos espaciales tenga en
su campo de visión el área de interés, el tiempo puede reducirse cuando el dispositivo

43
puede capturar imágenes oblicuas pero esto implica perdidas de resolución y precisión,
aun cuando la imagen sea capturada en el momento justo, el costo de la plataforma de
vuelo sique siendo elevado. En contraste, los UAV ofrecen un rápido acceso y costo
reducido, es decir dado que el área de captura se reduce, la resolución aumenta en virtud
de la baja altura de vuelo del dispositivo de captura y así mismo la relación costo beneficio.

Los Servicios geográficos en línea se han expandido rápidamente y de manera distribuida

en organizaciones privadas, agencias gubernamentales, bibliotecas, comunidades
científicas y comunidades de usuarios de información geográfica, desarrollando sitios web
que entregan datos geográficos, imágenes y metadatos de diferentes fuentes. Estos
servicios se dividen principalmente en cinco categorías:
- (Snapshots) instantáneas de mapas.
- librerías y catálogos de bases de datos espaciales (vector y ráster).
- generadores de mapas.
- navegadores de mapas.
- mapas e imágenes en tiempo real. (Cobb & Olivero, 1997)

Los usuarios de internet pueden fácilmente acceder a mapas pre-generados y vistas

simples del nivel de calles, también pueden crear mapas censales con datos de población,
consultar el cajero o restaurante más cercano, planear rutas entre lugares e incluso
construir mapas personalizados combinando de forma interactiva gran variedad de capas
o coberturas geográficas. Actualmente todos los proyectos de software libre y vendedores
y de software para SIG tienen SIG para servidores de internet y “middleware”. Existen
también mapas en tiempo real y Servicios de imágenes basados en sensores en línea para
proporcionar información del clima y tráfico (Cobb & Olivero, 1997).

Las aplicaciones distribuidas son parte fundamental de los SIG en línea, gracias a la
evolución del middleware, las aplicaciones Java de lado del usuario, los métodos de
cacheado y compresión de datos, el acceso a más potentes máquinas y el incesante
aumento del ancho de banda de la internet (Tsou, Guo, & Stow, 2003); los recursos para
la producción de Servicios de información geográfica son ahora más fáciles de encontrar
y rápidos de adquirir.
Una tecnología popular para SIG en línea son los Clientes Web de Servicios Web
Geográficos; son piezas de software (aplicaciones, librerías, frameworks, entre otros) que
proveen o extienden un componente interactivo para visualizar mapas en Internet desde

44
fuentes remotas. Algunos de los proyectos que proveen dicho componente usan
únicamente tecnología del lado del cliente mientras que la amplia mayoría depende de
funcionalidades del lado del servidor para ejecutar tareas avanzadas como seguridad,
administración de usuarios y grupos, análisis espacial, personalización de controles y
funcionalidades de interfaces gráficas de usuario, entre otras (Alameh, N., 2007).

El encadenamiento de servicios aplicado a la información geográfica en línea es un área

importante y parte integral del desarrollo de aplicaciones personalizadas, un
encadenamiento de servicios puede realizarse a través de tres métodos;
 Encadenamiento coordinado por el cliente.
 Encadenamiento estático usando servicios agregados.
 Encadenamiento de flujo de trabajo usando servicios mediadores (Alameh, 2003).
La necesidad de comunicación entre bases de datos y aplicaciones distribuidas induce a
la estandarización de los datos y metadatos compatibles con IDEs (Infraestructuras de
Datos Espaciales) locales y globales, el Consorcio Geoespacial Abierto (OGC) se encarga
de promover el uso de estándares para Servicios Web Geográficos.

Desde sus inicios los SIG han estado fuertemente ligados al análisis espacial, los primeros
retos fueron la superposición de capas ráster y vector para los análisis y luego para la toma
de decisiones, sin embargo fueron haciéndose más complejos los análisis, y los mapas
estáticos empezaron a exhibir el efecto del cambio de variables como el tiempo y el espacio
exigiendo maquinas más capaces (Mangina, 2005). Una de las perspectivas y retos más
interesantes en el campo de los servicios web geográficos en línea es el desarrollo de
agentes inteligentes web para el monitoreo de entidades con estos componentes
espaciales y temporales (Mangina, 2005).
Ahora encontramos Agentes Inteligentes que son herramientas en las que el usuario
introduce frases y/o palabras aisladas, pudiendo utilizar estructuras sintácticas de alto nivel
propias del lenguaje humano, las cuales son analizadas e interpretadas por el Agente, de
manera tal que extrae la parte concerniente a la demanda de información relativa a
contenidos de la web y devuelve las coincidencias encontradas con el fin de gestionar de
manera eficiente la información (Cobb & Olivero, 1997).
Existen varios desarrollos y modelos con lógica difusa, por ejemplo para el clima terrestre;
en función de la computación distribuida cada máquina corre un modelo y proporciona
datos de los resultados.

45
 Una comparación del sistema propuesto resulta compleja en cuanto a la elección de los
criterios sobre los cuales se van a comparar los sistemas u organizaciones que cumplen
objetivos similares, sin embargo se pueden tener en cuenta los siguientes criterios para
aproximarse a un escenario nacional.

Tabla 4 Comparación entre Organizaciones proveedoras de Imágenes Digitales

Grupo interno
Proveedores de
Digital de imágenes Sistema
Imágenes. Google Maps
Criterios Globe aeroespaciales Propuesto
IGAC
Plataforma de captura Vehículo Cesna Vehículo espacial, UAV
espacial vehículo terrestre
Complejidad del sistema Alta Media Alta Baja -
escalable
Deficiencias en Orbita Largo tiempo Orbita visible, Según cambios
Aplicabilidad al problema visible, de respuesta al altitud elevada, en el
planteado altitud evento. posibilidad de vías ecosistema
elevada inaccesibles tecnológico.
Costo de plataforma Alto Medio-Alto Alto Bajo
Costos administrativos Alto Alto Alto Bajo
Costo total de operación Alto Medio Alto Bajo
Fuente: Elaboración propia

Finalmente, en cuanto a SOA los recientes adelantos se encuentran en la profundización

del paradigma en evolucionan a SOA2 o SOA Avanzado.

46
Capítulo 3 Elicitación de Requerimientos del
Sistema.
La ingeniería de requerimientos tiene dos actividades principales: elicitación de
requerimientos y análisis, la primera resulta en la especificación del sistema que el cliente
entiende y la segunda resulta en el modelo de análisis que los desarrolladores pueden
interpretar unívocamente. Un requerimiento es una característica que el sistema debe
tener o una restricción que debe cumplir para ser aceptado por el cliente. (Bruegge &
Dutoit, 2005).
Los requerimientos elicitados a continuación son diseñados con una perspectiva amplia y
un poco más comercial que técnica del sistema, reconociendo la poca experiencia en el
diseño de sistemas; se hace el esfuerzo de tener en cuenta la mayor cantidad de variables
y escenarios que muestren las necesidades de un sistema en producción. La
documentación en teorías de desarrollo y la amplitud de detalles del sistema en
producción, permiten ver la conformación de un equipo de profesionales que no está
disponible para la implementación de todos los requerimientos en el prototipo.
En el Capítulo 6 Implementación del Prototipo quedan especificadas las funciones que el
prototipo ofrece y la forma como son accedidas, las que no se desarrollan con respecto al
diseño también quedan identificadas.

3.1. Requerimientos Funcionales.

Se observa de la literatura que el análisis de requerimientos es la etapa preliminar de la
obtención de requerimientos, sin embargo se ha experimentado con el desarrollo de este
trabajo que la obtención y el análisis son casi simultáneos, de esta forma el análisis de
requerimientos se perfila desde las secciones de Planteamiento del Problema y
Justificación del presente trabajo ampliándose más adelante con una breve descripción.
Según el estándar IEEE Std 830-1998; un requerimiento es la definición de acciones
fundamentales que debe realizar el software al recibir información, procesarla y producir
resultados. En estas acciones se incluyen: Comprobación de validez de las entradas,
Secuencia exacta de operaciones, Respuesta, a situaciones anormales (desbordamientos,
comunicaciones, recuperación de errores), Parámetros, Generación de salidas,
Relaciones entre entradas y salidas (secuencias de entradas y salidas, fórmulas para la
conversión de información), Especificación de los requisitos lógicos para la información
que será almacenada en base de datos (tipo de información, requerido).

47
 Breve descripción del proceso de negocio general:
Un usuario necesita las fotos correspondientes a un área particular de un terreno. Para
ello, el usuario necesita que el S.I. le permita definir el área del terreno y le dé la opción de
comprar las respectivas fotos, sí éstas existen en la base de datos del sistema, o de lo
contrario pueda solicitar un vuelo de tipo UAV con el fin de obtener la fotografía del terreno
de interés.

Para poder generar una consulta y visualizar estos datos, el usuario debe disponer de un
visor geográfico en un navegador con conexión web y herramientas básicas (zoom in,
zoom-out, pan, dibujar polígono, dibujar rectángulo), la aplicación debe tener la capacidad
de capturar (con el mouse, un lápiz digital o el dedo según el dispositivo que se use) un
polígono regular o irregular en el zoom escogido por el usuario sobre la cartografía básica;
este polígono digital o área de interés son los vértices del polígono en coordenadas planas
y en un sistema de referencia común con la cartografía básica para que un procesamiento
del sistema halle el total de fotos o productos que caen dentro de dicha área, esto con el
fin de desplegar los productos correctamente orientados y escalados en la cartografía
base. Luego se envía al cliente la información de su solicitud (descripción de cada
producto, costo, forma de pago, modo de adquisición). El primer paso para construir
servicios de información geográfica es decidir las codificaciones apropiadas para describir
los datos. La importancia del formato de datos yace en el hecho de que estos son los
bloques básicos de construcción del sistema, lo que a su vez determina el nivel de
interoperabilidad (Aydin, 2007), por lo tanto las codificaciones deben hacerse con
estándares comerciales.

Tabla 5 Requerimientos Funcionales

 El sistema debe permitir cargue de datos, compra on-line, análisis, consulta, visualización
ráster y edición de información geográfica vectorial, según permisos de roles y restricciones de
acceso en internet.
 Los atributos de calidad y metadatos de los productos consultados son desplegados junto con
una pre-visualización del producto.
 La entrega del producto final debe hacerse por medio digital o descarga, el usuario podrá
contactar servicios de impresión y envío.
 Todas las funciones del sistema incluidas las de análisis, deben ofrecerse como servicios
reutilizables, su acceso dependerá de la naturaleza interna o externa en la que cumplan su ciclo
los servicios.

48
 El sistema debe ofrecer los servicios de cuentas de usuario y pagos.
 Las herramientas de administración deben ser operadas por internet.
 Se le debe proveer al usuario la forma de registrar las insatisfacciones acerca del servicio o los
productos a través de un cuadro de texto de 200 caracteres máximo.

3.2. Requerimientos No Funcionales.

Dentro del concepto de Arquitectura Empresarial (Montaldo, 2005) y de acuerdo con las
necesidades del sistema y el negocio, los requerimientos no funcionales se definen de
acuerdo a la siguiente estructura:

Tabla 6 Requerimientos No Funcionales

Requerimientos No Funcionales

El despliegue de la cartografía básica no debe superar los 2 segundos y el de las

imágenes no debe superar los 3 segundos. (Teniendo en cuenta que éstas al ser
Rendimiento pre-visualizaciones de las originales deberán tener menor calidad y por lo tanto
menor tamaño en bytes.)

El procesamiento de datos no debe superar los 4 segundos.

Se debe reducir al máximo la carga transaccional cuando se haga transferencia de

imágenes aun cuando tengan una menor resolución.

Desempeño Se necesitan procesar imágenes en formato ráster en extensiones PNG, JPG, Geo
TIFF y SVG.

Se deben satisfacer la totalidad de los pedidos de los clientes.

La administración debe hacerse con herramientas tecnológicas que permitan

operación a través de internet.

Portabilidad Las ubicaciones de las bases de datos deben estar distribuidas en la nube.

El sistema operativo debe estar basado en Linux con una distribución que permita
el uso de un SMBD como PostgreSQL o MySQL

Se aborda desde el punto de vista de las restricciones de acceso para los roles de
acuerdo a las responsabilidades que cada rol tiene durante el proceso. Para esto se
diferencian distintos perfiles:
- Cliente: será a quien se le permite la visualización de imágenes capturadas por la
organización, las cuales han sido procesadas para reducir la resolución espacial. El
Seguridad
cliente puede visualizar imágenes cargadas por él mismo, acceder a datos de su
cuenta de usuario y modificar su área de interés, puede leer los resultados de los
procesamientos o análisis solicitados por medio de descarga o entrega del producto.
Estos procesamientos y análisis solo pueden ser modificados por un operario
responsable del producto o el asesor.

49
 - Operario: tiene permiso de modificar y pos procesar y procesar la información
producida por las fotografías aéreas digitales pero no la del usuario ni la de sí mismo.
- Jefe técnico: tiene permiso de modificar la información de todos los usuarios y
operadores pero no la de sí mismo.
- Administrador: tiene permisos totales.

Los usuarios no registrados como clientes no podrán acceder a ninguna

información diferente a la que se visualice en el Portal Web.

Para evitar recibir información inválida o alteraciones indeseadas de datos, deben

implementarse herramientas de metadatos y el bus de servicios.

Los clientes deben tener garantizada la protección de su información personal.

La exactitud de posición de los productos debe ser como máximo de un metro, es

decir, los datos no pueden tener errores de posición por encima de un metro.

En caso de perderse la conexión con el usuario durante la sesión de consulta, debe

guardarse la información de la sesión y el historial de cambios hechos por el
Fiabilidad usuario en la solicitud de información o el área de interés para retomar la consulta
cuando se reinicie la sesión.

Se deben implementar herramientas que permitan medir la integridad transaccional

y las propiedades ACID, con el fin de que los servicios tengan la propiedad de la
Idempotencia

Las herramientas ofrecidas por las interfaces de usuario y las mismas interfaces de
usuario deben ser altamente intuitivas para que el sistema se pueda usar por
Usabilidad personas con bajo conocimiento de los mapas en internet y la información espacial.

Las interfaces graficas de usuario en el navegador deben ser manejables por

dispositivos táctiles (Responsive).

La disponibilidad no necesita ser 24/7 (24 horas al día / 7 días a la semana),

Disponibilidad: aunque idealmente el sistema debería estar disponible la mayor parte del tiempo, la
disponibilidad mínima diseñada es 18/7.

Los dispositivos de hardware así como los de software deben ser escogidos de
forma que permitan escalabilidad vertical y horizontal, la primera con el fin de
mantener funcionalidades que se vayan enriqueciendo con el tiempo, y la segunda
con el fin de soportar el aumento permanente de usuarios y datos.
Mantenibilidad
Las aplicaciones deben ser desarrolladas con estándares para servicios web
geográficos y en lenguajes de programación empleados en el software libre.

Es necesario que el sistema cumpla con los conceptos de SOA como el bajo
acoplamiento e interoperabilidad.

Las funciones del proceso de negocio y en lo posible del procesamiento de datos,

Flexibilidad deben ser codificadas en forma de servicios de manera que el sistema permita una
independencia de la plataforma y de los proveedores de software.

50
Capítulo 4 Análisis del Sistema.
El capital y los negocios rigen el mundo globalizado por el sistema económico dominante,
las actividades más importantes del ser humano están ligadas a este sistema; educación,
salud, recreación, etc. De una forma u otra éste sistema debe ser abierto para que el flujo
de energía, es decir los recursos le permitan auto-sustentarse, en estos términos el flujo
puede considerarse como el negocio o mejor, un proceso de negocio donde se encauza la
energía o los recursos, con el fin específico de colaborar con la divulgación de la
información.
Un proceso de negocio es un conjunto de actividades medibles y estructuradas diseñadas
para producir unas salidas específicas para un cliente particular o para un mercado
(Cockburn, 2000). Un negocio también se puede considerar como una actividad económica
entre dos o más entes para invertir sus recursos en la ejecución de uno o varios procesos
y obtener beneficios, en el ambiente financiero estos beneficios son monetarios, en un
ambiente social estos beneficios también pueden ser monetarios o una mejor calidad de
vida, acceso a información veraz y actualizada gubernamental, jurídica, científica o
económica, eficiente utilización de recursos naturales por medio del monitoreo
permanente, aumento de la cobertura y calidad en salud y educación, etc.

En el ambiente tecnológico la evolución de los lenguajes de programación ha llevado a los

fabricantes de software a incluir herramientas de desarrollo de aplicaciones en lenguajes
de 4a generación dentro de los que se contempla Business Process Modelling and Notation
BPMN; empleado en este trabajo.
En el ambiente de la información geográfica es obvia la existencia de procesos de negocio,
los cuales según lo observado y desde un punto de vista general, se componen de tareas
comunes al SDLC como el análisis, diseño e implementación, para hacer un uso eficiente
de la tecnología con un enfoque arquitectónico hacia los servicios web geográficos. Para
el caso de esta investigación, junto con tareas de análisis espacial y procesamientos de
información geográfica, se obtienen productos que a su vez pueden ser servicios; este es
el caso de las fotografías aéreas y sus productos digitales actuando como servicios de los
datos capturados por un sensor óptico en el rango visible del espectro.

De acuerdo al escenario del proyecto en nuestro país, la investigación de mercado con los
profesionales de la fotogrametría, quienes conocen a sus clientes pero sobre todo a sus
clientes potenciales, comprueba que es bastante probable que la información solicitada

51
por un usuario civil no exista o sea inalcanzable con los medios que ofrece la fotogrametría
convencional, escenario que si es accesible con la fotogrametría horizontal de objeto
cercano a un precio obviamente menor en función de las grandes diferencias económicas
que existen entre las plataformas satelitales o aerotransportadas y los drones. Éstos
últimos permiten aumentar la frecuencia de captura, ampliando potencialmente el alcance
del sistema propuesto a procesamientos multidimensionales incluida la dimensión
comercial, así como procesamientos y análisis de datos geográficos para un mayor número
de usuarios. Estos productos pueden ser ofrecidos como un servicio web geográfico
publicado, cuyo proceso de negocio utiliza la información del sistema y la colaboración
entre servicios para aumentar capacidades de análisis en el ambiente del negocio y
mantener al proceso como un ente dinámico, justificado en función del beneficio del usuario
y el retorno de la inversión a través del incremento permanente del número de usuarios.

Lo primero que se asume para la ejecución del proceso de negocio, o según la metodología
de casos de uso, una precondición (Weitzenfeld, 2005), es que al menos un proceso de
captura haya finalizado y que las fotografías aéreas estén pos procesadas y cargadas en
la base de datos, todo esto en virtud de técnicas de fotogrametría digital como la
fotogrametría de objeto cercano. Esta técnica permite que un vehículo aéreo no tripulado
(UAV) equipado con una cámara que puede o no ser fotogramétrica, capture imágenes
digitales de la superficie terrestre a menores alturas que las de los vuelos fotogramétricos
convencionales, los cuales usan cámaras específicamente fotogramétricas de
instrumentos más robustos en una plataforma aérea de operación más compleja y costosa.
Las fotografías capturadas por el UAV son post-procesadas con el fin de determinar la
información correspondiente a los parámetros de posición en un sistema de referencia
(MAGNA-SIRGAS), orientación respecto a los ejes tridimensionales terrestres
(georreferenciación) y la geometría de la imagen, estos datos y sus procesamientos
generan productos geográficos o cartográficos (DEMs, DTMs, clasificaciones digitales,
Ortofotografías, Ortofotomapas, Ortofotomosaicos, vectorizaciones, análisis espaciales,
etc…) que pueden ser diseñados por el analista, el jefe técnico y ofrecidos por la
organización o solicitados por el cliente. Estos productos alimentan la base de datos del
proveedor, obteniendo así la información alfanumérica y de ubicación espacial que será
evaluada por el cliente al acceder al servicio a través de internet.

Para las actividades de consulta de imágenes el sistema de información debe ser accedido
a través de un navegador web, en la página web corporativa el usuario hace clic a un

52
enlace o botón que inicia el Proceso de Registro para utilizar el servicio de Consulta de
Información. Si el usuario no está registrado, la secuencia de registro de nuevos usuarios
permite que sea registrado. Después de ser usuario registrado se brinda la opción de
escoger entre tres actividades diferentes: Realizar Consulta, Diseñar Vuelo o Cargar
Imágenes; el usuario puede escoger alguna de las dos o las dos al tiempo. Al escoger
cualquier combinación se le pregunta de nuevo cual hacer primero, aunque Realizar
Consulta siempre será antes que Diseñar Vuelo, cualquiera de las dos genera su propio
proceso y al finalizar se continúa con el proceso de la actividad faltante. En la actividad de
Consultar Imágenes el usuario accede a un visor geográfico con herramientas básicas que
permitan presentar el mapa de Colombia con su división política y/o cartografía básica a
escala que permita una fácil ubicación del área de interés del usuario, esta base
cartográfica es una ventana en el browser la cual ofrece herramientas básicas de paneo y
zoom con las cuales el usuario puede navegar hasta una escala más detallada que permita
trazar el área de su proyecto. Luego de estar perfectamente ubicado, el usuario traza sobre
el mapa un polígono digital que define el área de interés sobre la cartografía base.
Una vez se conoce la geometría y posición del área de interés, esta se cruza con la
información del proveedor para permitir que el usuario visualice los parámetros de captura
e información adicional de las imágenes que están dentro de su área de interés., lo cual
puede implementarse mediante el uso de servicios de mapas o servicios cartográficos
básicos que ya están disponibles en varios lugares de internet. Todo con el fin de
proporcionar herramientas suficientes para capturar el Área de Interés.
El polígono regular o irregular es ingresado a través del servicio WFS-T, al tomar la
proyección cartográfica en coordenadas planas se extraen del Área de Interés las
coordenadas mínimas y máximas de los ejes X e Y. Una sentencia o función consulta la
base de datos Geoespacial del proveedor por medio de un filtrado, este proceso de filtrado
deduce una intersección entre la información suministrada por el usuario y la base de datos
del proveedor del servicio en función de los rangos de coordenadas y los polígonos de las
imágenes cuya tabla de atributos será mostrada en el visor, los centros de las imágenes y
otros atributos que serán consultados en esta ventana de coordenadas ya han sido
calculados en el pos-proceso de las imágenes.
De acuerdo a sus expectativas, el usuario hace una selección de las imágenes que
satisfacen sus necesidades en términos de los parámetros y la información alfanumérica.
El usuario a través de una aplicación web solicita al sistema dos tipos de datos, uno
alfanumérico y otro espacial; los datos alfanuméricos representan la información de las

53
fotografías aéreas digitales que pueden ser visualizados de forma tabular y los datos
espaciales representan los niveles digitales de los pixeles en la fotografía.
Los datos alfanuméricos son principalmente campos o atributos correspondientes a la
información de calidad de cada fotografía aérea digital, estos campos son:
 Porcentaje de traslape con la fotografía siguiente.
 Porcentaje de traslape con las fotografías laterales.
 Altura de vuelo.
 Angulo de desviación en omega.
 Angulo de desviación en phi.
 Angulo de desviación en kappa.
 Azimut de la línea de vuelo.
 Fecha y hora de la captura.

Los datos espaciales referentes a los niveles digitales se visualizan en conjunto en forma
de imágenes en un visor auxiliar de forma que el usuario señale la imagen y elija
visualizarla con un botón para que sea evaluada visualmente por el usuario en diferentes
bandas y tenga la oportunidad de realizar un último filtro en función de tonalidades,
iluminación, contraste u otros comportamientos espectrales no deseados. Luego de que el
usuario descarta imágenes del conjunto total de imágenes ofrecidas. El conjunto final de
imágenes queda dispuesto para que el usuario escoja que tratamientos o productos
necesita a partir de las imágenes, los procesos posteriores corresponden a la etapa de
producción y pueden ser automáticos, asistidos por computadora o incluso contratados
(ortorrectificación, generación de DTM, DEM clasificación, etc.). Cabe mencionar que los
tratamientos o procesos efectuados a las imágenes se reflejan en el costo,

Finalizado el proceso de consulta el usuario puede solicitar un vuelo sea que existan o no
imágenes dentro del área de interés que acaba de dibujar, al presionar el botón de Diseñar
Vuelo se observan las líneas y puntos que identifican las fajas y los centros de fotos, y se
pregunta al usuario si acepta o rechaza el vuelo diseñado por el sistema, la respuesta
afirmativa del usuario inicia la actividad de Diseño de Vuelo.
Posteriormente el sistema calcula el costo total de los productos solicitados, se confirma la
decisión del usuario de ordenar los tratamientos y se inicia el subproceso de Pago, según
la elección del usuario se genera un recibo de pago descargable e imprimible o se enlaza
un servicio de pago electrónico. Luego de la verificación del pago se presenta la opción de
descarga de la información o contactar un servicio de impresión y envió.

54
La disposición de fotografías aéreas concebida como un servicio web permite que las
imágenes digitales sean consumidas como un producto geográfico a través de Internet, es
decir, sean descargadas junto con sus productos o interactúen con otro servicio de internet
como el de impresión y envío. El producto específico se autoriza para descarga o enlace
con otro servicio y finalmente se presenta la posibilidad de registrar un reclamo dentro de
un periodo de tres días hábiles posteriores a la entrega.
La actividad llamada Cargar Imágenes permite al usuario abrir una ventana de navegación
para ubicar la carpeta local de los archivos de imagen que desea cargar, también permite
registrar los servicios o tratamientos que se deseen sobre las imágenes cargadas.

La Seguridad es un factor que afecta el escenario real de implementación y en producción

se puede efectuar a través de servicios de seguridad y los protocolos del ESB. También
se considera un objetivo de diseño la comunicación asíncrona para disminuir la carga de
red.

4.1. Diagrama del Proceso de Negocio.

Un proceso de negocio se ha entendido como un conjunto de tareas relacionadas
lógicamente llevadas a cabo para lograr un resultado de negocio definido.
“Un proceso de negocio es cualquier sistema o procedimiento que una organización
utiliza para conseguir un objetivo de negocio más elevado. Cuando se descompone, se
ve que un proceso de negocio es en realidad una serie de tareas individuales, y cada
tarea se ejecuta en un orden específico” (IBM, 2009).
Cada proceso de negocio tiene sus entradas, funciones y salidas. Las entradas son
requisitos que deben tenerse antes de que una función pueda ser aplicada. Cuando una
función es aplicada a las entradas de un método, tendremos salidas resultantes
(Romagnano, Gomez, & De Luca, 2010).
Las técnicas para modelar procesos de negocios han existido en muchas formas desde
principios del siglo XX. Diagramas de flujo básicos se remontan a la década de 1920
desarrollándose en enfoques más modernos tales como IDEF en la década de los 70, más
recientemente UML y en hoy en día BPMN. El termino actual BPM puede tener origen con
S. Williams (1967) pero llego a ser más popular en los 90’s. BPM surgió como una
aproximación estructurada, a menudo usada como apoyo a la ingeniería de software para
describir una colección de actividades relacionadas para entregar un objetivo deseado. El

55
proceso de pensamiento se convirtió en la piedra angular de mejora de negocios y condujo
a una mayor productividad en muchas organizaciones (Hook, 2011).

De forma simultánea al análisis se obtiene el diagrama conceptual del proceso de negocio,

el aspecto más complejo en el diseño de una SOA es el relacionado con el cambio, no solo
el cambio ante la obsolescencia o sofisticación de los dispositivos electrónicos, también el
cambio frente a los requerimientos para lo cual un modelo E-R podría no ajustarse
correctamente y para lo cual también fueron desarrollados los Servicios Web. También
existe un cambio durante la interiorización y conceptualización de SOA. Este cambio
también se ve reflejado en el diseño de actividades del proceso a través de la metodología
SOMA al momento de aislarse de la tecnología, es decir hacerlo independiente de la
plataforma de implementación. De hecho, el mismo proceso concebido inicialmente ha ido
cambiando principalmente en función de la metodología y las herramientas puesto que son
muy influyentes en la aclaración de conceptos como los servicios web y la exposición de
servicios que son el objetivo de todo el proceso. Otro cambio también se debió a la
adaptación de los conceptos y bocetos iniciales del proyecto adaptándose a BPMN.

A través de este ejercicio se ha observado el concepto de granularidad del servicio y se

han jerarquizado o se han englobado procesos con características comunes, aquí también
se empiezan a pensar los servicios como composiciones de servicios reutilizables, hasta
llegar a las tareas manuales de interacción hombre-máquina que se detallan más adelante
en el modelado de los subprocesos.
En este diagrama se observa que los subprocesos de Cargue de Imágenes y Planeación
de Vuelo presentan una diferencia grafica en cuanto al grosor de la línea, esto lo identifica
ante la notación BPMN como un proceso reutilizable que es empleado en otros
subprocesos como en el Subproceso de Producción.

Ilustración 4 Diagrama BPMN del Modelo de Negocio:

56
57
4.2. Reglas del Negocio.
Desde la perspectiva de los sistemas de información, una regla de negocio es una
declaración que define o restringe algún aspecto del negocio. Su intención es afirmar,
controlar o influenciar la estructura y el comportamiento del negocio (Bussines Rules
Group, 2016).
“Una regla de negocio es una condición que se debe satisfacer cuando se realiza
una actividad de negocio. Una regla puede imponer una política de negocio, tomar
una decisión o inferir nuevos datos de datos existentes.” (IBM, 2009).
Como cualquier servicio, el servicio de fotografías aéreas digitales busca satisfacer las
necesidades de los clientes y mejorar cada día el servicio de acuerdo a las dinámicas del
mercado; las reglas del negocio son:

Tabla 7. Reglas del negocio

1. Si el área de interés no está totalmente cubierta por la oferta del proveedor, sugerir al
usuario que genere una orden de planeación de vuelo para el área faltante.
2. Si el área de interés está totalmente desprovista de productos, sugerir al usuario que
genere una orden de vuelo para el área de interés.
3. Los servicios de consulta y asesoría son gratuitos, el costo se debe asumir dentro de
los costos de mantenimiento de los servicios.
4. El usuario puede escoger entre adquirir productos del área de interés exacta o el área
cubierta por fotos.
5. El usuario debe estar registrado para acceder a la información de fotos.
6. El usuario debe especificar el motivo de rechazo de las fotos en cada etapa de filtrado.
7. Los productos adquiridos a los proveedores de servicios deben cumplir estándares
de calidad solicitados por el cliente y estándares de comunicación.
8. Los procesamientos solicitados por el usuario se iniciarán solo después de obtener la
confirmación del pago.
9. El usuario tiene un plazo de 72 horas para hacer un reclamo sobre el producto.
10. Se debe ofrecer asesoría gratuita al usuario en procesamientos de datos según las
necesidades que comunique.
11. El proceso se puede cancelar en cualquier momento anterior al pago de los
productos o servicios solicitados, luego del pago no hay cancelación.

58
4.3. Casos de Uso.
Un caso de uso es la descripción de las posibles secuencias de interacciones (escenarios)
entre el Sistema de Información Geográfica para Fotografías y sus actores externos con
respecto a una meta particular (Cockburn, 2000).
Una historia del sistema en uso (o historia de usuario, como se le llama a veces) es un
ejemplo localizado del caso de uso en funcionamiento; una sola historia de ejemplo
altamente específica de un actor con el sistema. No se trata de un caso de uso, y en la
mayoría de los proyectos sobrevive en el documento oficial de requisitos. Sin embargo, se
trata de un artefacto muy útil (Cockburn, 2000):

Historia del sistema en uso “Crudo Invierno”: El aumento en las precipitaciones ha

desencadenado inundaciones en la llanura del magdalena, el programa de atención y
prevención de desastres ha asignado recursos para los damnificados y se necesita
conocer con exactitud la cantidad y localización de predios afectados, aunque el catastro
del municipio tiene una vigencia reciente, la extensión es muy grande para determinar los
predios a simple vista y las imágenes disponibles exceden el presupuesto. El jefe de la
oficina de planeación del municipio conoce el sistema que ya ha usado para la vigilancia y
seguimiento del avance de obras públicas e ingresa para solicitar un vuelo; luego de
registrarse rápidamente ubica el municipio en un visor y la zona aproximada de inundación
según informes recientes para trazar un polígono de acuerdo a sus estimaciones. El
sistema arroja un resultado de 150 imágenes capturadas por una empresa de silvicultura
en un área de la zona afectada, el funcionario escoge 100 para comparaciones
cronológicas e ingresa datos (resolución, bandas espectrales del visible, imagen LIDAR y
ortorrectificación de fotos aéreas) para la captura del área total trazada. El sistema
determina los costos de los productos finales y se estima que serán autorizados para la
descarga en un plazo máximo de 7 días mientras se cumplan las condiciones de pago. El
funcionario cuenta con unos archivos de otras imágenes que desea comparar con la
situación actual por lo cual también accede al servicio de cargar imágenes solicitando
georreferenciación, orto-rectificación y un análisis espacial del impacto del fenómeno.

4.3.1. Identificación de Actores.

Actor: Entidad externa que necesita intercambiar información con el sistema. Un actor
puede representar un papel de usuario o puede representar a otro sistema (Bruegge &

59
Dutoit, 2005). Los actores representan los roles que las personas (o dispositivos) juegan
mientras el sistema está en operación (Cockburn, 2000).

Tabla 8 Actores
ACTORES METAS

PRIMARIOS Cliente - Ser usuario registrado.

- Obtener o cargar imágenes o productos cartográficos y
fotogramétricos digitales.
SECUNDARIOS Operador Procesar y cargar imágenes digitales y generar productos
según especificaciones del cliente

Administrador Conceder diferentes tipos de permisos a los diferentes roles y

tomar decisiones durante el proceso
Jefe Técnico Analizar, planear, asesorar y autorizar vuelos y productos

El desarrollador puede ser un actor o no, dependiendo de la necesidad de implementar

este rol de operador puesto que aunque él interactúa con el sistema, lo hace generalmente
con el rol del cliente para hacer pruebas y basado en los resultados de estas pruebas el
desarrollador hace las modificaciones necesarias en la funcionalidad. De cualquier forma
las actuaciones del desarrollador quedan registradas mediante herramientas de control de
cambios y versiones.

4.3.2. Involucrados o Stakeholders (a quien le interesa)

El termino stakeholder se usa para referirse a cualquier persona o grupo que se verá
afectado por el sistema, directa o indirectamente. Entre los stakeholders se encuentran los
usuarios finales que interactúan con el sistema y todos aquellos en la organización que se
pueden ver afectados por su instalación (Sommervile, 2005).
 Clientes: entidades públicas, privadas o personas naturales que requieran información
geográfica actual a escalas 1:5.000, 1:2.000, 1:1.000 (o mayores) y eventualmente otros
servicios web.
 Operadores técnicos: recursos humanos o tecnológicos que alimentan el sistema y
las comunicaciones para procesar información y habilitar servicios.
 Operadores administrativos: tomadores de decisiones, analistas de negocio,
arquitectos de software y del sistema.
 Proveedores de servicios web que complementen el proceso de negocio.
 Agentes financieros, inversores o socios potenciales.

60
4.3.3. Identificación de Escenarios.
Escenario: Instancia de un caso de uso. Un escenario representa una secuencia concreta
de interacciones entre uno o más actores y el sistema (Bruegge & Dutoit, 2005).

Tabla 9 Escenario Actualización Catastral

Nombre del Escenario Actualización Catastral
Nombre del Caso de Uso Consultar Producto
Actores Participantes Alcalde: Cliente
El alcalde del municipio de Leticia prepara insumos para la
actualización catastral de la zona urbana ordenada por la ley,
para reducir costos y planear un grupo de reconocedores elige
comprar unas fotos recientes del municipio a través de un
servicio web en internet.
Ingresa al sitio web de la empresa y accede a la sección de
consultas en la página principal, se registra y accede al
servicio haciendo clic en la opción de Consulta de Imágenes.
Flujo de Eventos
Se despliega un visor geográfico donde ubica el área urbana
del municipio y dibuja su área de interés.
Su solicitud es procesada y se le informa de la cantidad, costo
y otros detalles de los productos disponibles.
El alcalde hace un filtro final y confirma qué producto desea
adquirir.
Se realiza el proceso de pago a través del caso de uso de
facturación y pagos y se activa el proceso de entrega.

Tabla 10 Escenario Estimación de producción de Biodiesel

Nombre del Escenario Estimación de producción de biodiesel.
Nombre del Caso de
Solicitar Vuelo.
Uso de sistema
Actor Participante Propietario finca palmicultora: Cliente.
El cliente necesita conocer el estado fenológico y la cantidad de
plantas sembradas en su extensa finca de cultivo de palma
africana, para esto ingresa al website empresarial y se registra.
El propietario ingresa a la página web corporativa y luego de
Flujo de Eventos
registrarse accede al servicio de consulta. Luego de la consulta
se obtiene un resultado de cero productos en la zona y se
presenta la opción de solicitar un vuelo que cubra sus
necesidades.

61
 El cliente acepta y el vuelo es programado y ejecutado en el
menor tiempo posible, también se solicitaron tratamientos de
georreferenciación, clasificación y análisis espectrales para
determinar el estado fenológico del cultivo así como índices de
vegetación y suelos.
Se informa al cliente vía mail que las fotos son cargadas en el
sistema para que el cliente vuelva a consultarlas y seleccionarlas
para adquirirlas.

4.3.4. Identificación de Casos de Uso.

Crearemos un caso de uso del sistema por cada actividad del diagrama de proceso que
deba ser soportada por el sistema de software. Por tanto, el rol que lleva a cabo la actividad
será el actor principal del caso de uso. Nótese que, de acuerdo con la definición de caso
de uso, no todas las actividades del diagrama de proceso serán consideradas como casos
de uso, sino solamente aquellas que sean de valor para algún actor. (García Molina, Ortín,
Moros Valle, & Toval Álvarez, 2007)

Tabla 11. Caso de Uso de Sistema: Consultar Producto.

Nombre del
Consultar Producto
Caso de Uso
Actores
Cliente, Servicio Web de selección de productos
Participantes
El cliente es un usuario registrado
El sistema tiene el servicio web en operación
Condiciones Existe información de calidad y parámetros de las imágenes cargadas al
Iniciales subsistema de almacenamiento.
Las pre-visualizaciones de las imágenes existentes han sido procesadas
y están cargadas en el sub-sistema de almacenamiento.
1. En el sitio web empresarial el cliente hace clic en el link del servicio de
consulta de productos cartográficos y otros servicios, a continuación se
activa el caso de uso de registro de cliente.
Flujo de 2. Con el registro exitoso el cliente hace clic en los servicios deseados
eventos opción “Consultar Imágenes” (activada por defecto) u opción “Cargar
Imágenes”, la opción “Diseñar Vuelo” es ofrecida luego de la actividad de
Consultar Imágenes.
3. Se despliega en el browser una ventana con un visor donde están los
límites departamentales nacionales y la cartografía básica nacional.

62
 4. Con herramientas de navegación el cliente hace un acercamiento al
departamento, luego al municipio y finalmente al área de interés.
5. Con la herramienta de trazado, el cliente dibuja un polígono y se
despliega una lista de productos hallados en el área de interés trazada
6. El servicio compara el área cubierta por las imágenes de la base de
datos con el área de interés suministrada por el cliente e informa. Se
ofrece la posibilidad de solicitar un vuelo ya sea para completar el área o
para hacer una nueva captura, y en una zona contigua al visor geográfico
se presenta la información de las imágenes existentes en forma tabular,
mientras pre visualizaciones de las imágenes se despliegan en un visor
auxiliar según la imagen que desee ver el usuario.
7. El cliente selecciona las imágenes que desea adquirir junto con
productos adicionales (desempeñados por la organización o contratados
online) ofrecidos por el sistema.
8. Se solicita confirmar los productos y procesos a ordenar y se activa el
servicio de facturación y pagos.
9. Se activa el servicio Entrega de producto.
1. del flujo Nº 1, si el cliente no es un usuario registrado, se inicia el caso
de uso Registro de Cliente.
2. del flujo Nº 6: si el cliente luego de "Consultar Imágenes" selecciona la
opción "Diseñar Vuelo", el sistema activa el caso de uso Diseñar Vuelo
usando la misma área de interés y envía notificación al cliente de que la
Subflujos solicitud está siendo atendida, será contactado en menos de 6 horas vía
e-mail para consultar información adicional y comunicar el tiempo que
tardara la ejecución y el costo adicional. Al terminar se continúa la
secuencia.
3. del flujo Nº 2: si además de "Consultar Imágenes " o "Diseñar vuelo" el
cliente activa la opción "Cargar Imágenes", el sistema activa el servicio
de cargar imágenes digitales.
Luego de las consultas y el reporte de costos el cliente confirma si desea
Condiciones de adquirir los productos y procesos seleccionados para activar el servicio
Salida de pago.
Todos los datos de la consulta quedan registrados y asociados al cliente.
Los servicios seleccionados deben ser independientes y ejecutarse uno
a la vez.
Requerimientos Las imágenes y la información deben desplegarse en un lapso máximo
de calidad de 5 segundos.
El sistema debe ofrecer un medio para que el cliente comunique sus
inconformidades o sugerencias.

63
 La interrupción del proceso por caída del servicio o del sistema debe
generar un reporte y la opción de continuarlo en el punto donde se
interrumpió.

Tabla 12. Caso de uso de sistema: Diseñar Vuelo.

Nombre del
Diseñar Vuelo
Caso de Uso
Actores
Cliente, Jefe Técnico, Operador
Participantes
El cliente ha ingresado el área de interés.
El cliente ha sido informado si existe o no una diferencia de cobertura
Condiciones entre el área total cubierta y el área de interés.
Iniciales Aun cuando no halla diferencia entre áreas se ofrece la opción de Solicitar
Vuelo.
El cliente ha confirmado su interés en programar y ejecutar un vuelo.
1. Enviar la solicitud al jefe técnico.
2. El jefe técnico calcula los parámetros del vuelo (altura, recubrimientos,
líneas de vuelo) haciendo las preguntas pertinentes al cliente acerca del
nivel de detalle deseado.
Flujo de 3. El jefe técnico notifica al operador la información del vuelo y los
eventos parámetros para la ejecución.
4. El operador efectúa el vuelo, pos procesa las imágenes y extrae la
información de calidad que se carga al sistema.
5. Se informa vía e-mail al cliente que las imágenes están listas para
consulta a través de internet.
Subflujos -
Condiciones de Las imágenes y la totalidad de la información de calidad deben quedar
Salida cargadas en el sistema al final del proceso.
Los procesos de ejecución de vuelo, pos procesamiento, extracción de
Requerimientos
información de calidad y cargue de imágenes deben ser monitoreados
de calidad
para incrementar la eficiencia.

Tabla 13. Caso de uso de sistema: Registro de Cliente

Nombre del
Registro de Cliente
Caso de Uso
Actores
Cliente.
Participantes
Condiciones La base de datos de clientes se encuentra activa y en operación.
Iniciales El cliente no se encuentra registrado.

64
 El cliente debe tener e-mail y teléfono celular.
1. Luego de que el cliente hace clic para acceder al servicio, se despliega
la pantalla de inicio de sesión con nombre de usuario y contraseña.
2. Se verifican los datos, si el cliente no está registrado se accede al
formulario de registro que debe llenar completamente para hacer una
Flujo de
consulta.
eventos
3. Luego que el registro de usuario es satisfactorio se ofrece un botón
para que el cliente inicie sesión como usuario registrado.
4. El cliente ingresa su usuario y contraseña para iniciar sesión y se activa
el caso de uso de seleccionar producto.
Del flujo Nº 2, si el cliente ya está registrado la secuencia pasa al flujo Nº
Subflujos
4.
Se le envía al cliente una confirmación vía mail de que ha sido registrado
Condiciones de exitosamente.
Salida El cliente y todos sus datos pueden ser consultados en la base de datos
por un usuario con perfil apropiado.
Un cliente que proporcione un e-mail que ya exista en la base de datos
debe ser informado de que ya está registrado.
Requerimientos El servicio es reutilizable para el acceso y registro de personal de la
de calidad organización.
El cliente debe finalizar el registro ingresando desde un link enviado a su
correo personal.

Tabla 14. Caso de uso de sistema: Facturación y Pago de Servicios

Nombre del Caso
Facturación y Pago de Servicios
de Uso
Actores
Cliente.
Participantes
Existe una notificación de que el cliente ha aceptado la adquisición de
productos o servicios junto con los datos del cliente y la factura
Condiciones
generada.
Iniciales
La lista de productos o servicios solicitados existe; se creó a partir del
numeral 8 en el flujo de seleccionar producto.
1. Se calcula el valor en función del área total procesada y los procesos
efectuados en ésta.
Flujo de eventos
2. Se informa el valor al cliente y se presentan las opciones de pago; en
línea (PSE), datafono o personalmente en efectivo.

65
 1. del flujo Nº 2, según el medio de pago escogido, se conecta el servicio
Subflujos respectivo si el medio es digital o se genera pdf del recibo de pago con
información de entidades receptoras del efectivo.
En caso de interrupción o caída del sistema durante el proceso, debe
Requerimientos
disponerse de un mecanismo confiable para establecer el estado del
de calidad
proceso en el momento de la caída del sistema.

Tabla 15. Caso de uso de sistema: Entrega de producto

Nombre del
Entrega de producto
Caso de Uso
Actores
Cliente, servicio de entrega.
Participantes
El caso de uso de Facturación y Pago de servicios se ha efectuado
Condiciones satisfactoriamente.
Iniciales
Los procesos de los productos solicitados han culminado totalmente.
1. consultar al cliente el formato de entrega deseado y los parámetros de
tal formato.
2. contratar el servicio adecuado si el formato de entrega escogido fue el
Flujo de de impresión
eventos 3. generar el link de descarga si la forma de entrega seleccionada fue el
archivo digital.
4. solicitar al cliente observaciones o sugerencias de la totalidad del
servicio para finalizar el proceso.
Subflujos 1. Del flujo Nº 3: Activar el proceso de quejas y reclamos.
Iniciar un cronometro para dar la posibilidad de reclamo con un lapso de
Condiciones de 3 días.
Salida El link de descarga quedara habilitado por 24 horas, este lapso puede
repetirse 2 veces.
Si la descarga es muy pesada, el cliente debe ser avisado y deben dársele
Requerimientos
opciones de adquisición.
de calidad
Pertinente, confiable y reutilizable.

66
Ilustración 5 Diagrama de casos de uso en ArgoUML

4.3.5. Términos usados / glosario.

Aunque este ítem aparece referenciado en la bibliografía como un documento que describe
textualmente las clases identificadas durante el modelo de dominio del problema
(Weitzenfeld, 2005), se entiende que este documento surge de reuniones entre
stakeholders, por lo cual la elicitación de requerimientos está debidamente documentada
y se asume como el documento a partir del cual sería desarrollado un eventual glosario.

67
 Capítulo 5 Diseño del Sistema.
El diseño de la solución consiste en establecer los aspectos de más alto nivel
organizacional, a partir de los de bajo nivel metodológico y conceptual que convienen para
el control de procesos, manejo de datos y políticas en las que se enmarcan las SOA para
establecer los principios orientadores en la toma de decisiones concertadas.
No todas las características diseñadas en este capítulo se han considerado para la
implementación del prototipo (Capitulo 6); solo se implementan aquellas que permiten una
demostración funcional mínima suficiente para obtener un ejemplo claro de las ideas más
generales que se visualizaron al momento del diseño de las secuencias en el proceso.

5.1. Modelo de Dominio del Sistema.

El modelo de dominio define un modelo de clases común para todos los involucrados en
el modelo de requisitos; tanto analistas como clientes, este modelo de clases consiste en
los objetos del dominio del problema, o sea objetos que tienen una correspondencia directa
en el área de la aplicación (Weitzenfeld, 2005).
La identificación de clases presenta un punto de inflexión entre la teoría y la práctica ya
que es un proceso creativo con alto grado de subjetividad que incide directamente en la
eficiencia del sistema y está fuertemente ligado al conocimiento del código y las técnicas
de programación.

Identificación De Clases
La identificación de clases del dominio se obtiene principalmente de algún documento
textual que describa el sistema. Se comienza el proceso a partir de la identificación de
clases candidatas, para ello se extraen sustantivos de la descripción del problema
(Weitzenfeld, 2005). Para efectuar la identificación de clases usamos el análisis del
proceso de negocio y no la descripción del problema por presentar mayor cantidad de
información relevante.

Tabla 16. Identificación de Clases

CLASES
CLASES CANDIDATAS ENTIDADES
IDENTIFICADAS
registro de usuario Redundante Usuario – Rol – Bitácora – Auditoría -Permiso
Imágenes aéreas Ok Tipo servicio – Tipo archivo - Imagen
Jefe técnico Ok Usuario - rol

68
UAV Irrelevante Tipo servicio – vuelo - UAV
Operador técnico Ok Usuario- rol
Parámetros de posición Atributos Parámetro de Sistema
sistema de referencia Atributos Parámetro de Sistema
Orientación ejes tridimensionales Atributos N/A
geometría de la imagen Atributos Parámetro de Sistema
posición relativa Atributos Tipo Servicio – Mapa – Propiedad Mapa
base de datos del proveedor Redundante Proveedor
Cliente Ok Usuario- rol
Servicio Implementación Tipo servicio
Navegador web Interface N/A
visor geográfico Interface N/A
herramientas básicas Redundante N/A
mapa de Colombia con división política Redundante Tipo servicio – mapa
página web corporativa Implementación Modelo relacional
servicio de consulta de información Implementación Tipo servicio
aplicación de registro Implementación Usuario – Rol – Bitácora – Auditoría -Permiso
área de interés Ok Tipo Servicio – Área Interés
Enlace implementación N/A
producto geográfico Ok Tipo servicio - Tipo producto - Tipo archivo
servicio de impresión y envío implementación Tipo servicio - Tipo producto - Tipo archivo
proceso de filtrado operación N/A
base de datos Geoespacial redundante Modelo relacional
Rangos de coordenadas atributos N/A
Vuelo (plan de vuelo) Ok Tipo servicio – vuelo
Fajas (línea de vuelo) Ok Tipo servicio – vuelo - línea vuelo
costo del producto Operación Posible entidad
recibo de pago Irrelevante Posible entidad
servicio de pago electrónico Implementación Tipo servicio

La tabla muestra la extracción de los sustantivos relevantes candidatos a clases en el

modelo y su reagrupación en entidades, estas permiten observar el punto de vista del
desarrollo entendiendo en principio que el sistema y en general cualquier modelo está
orientado a la interacción con humanos, entonces el usuario y el sistema son las obvias
entidades. La entidad usuario tiene definidos roles con los cuales el sistema identifica e
interactúa de forma diferente según el rol, estos roles son; cliente, jefe técnico, operador
técnico. La siguiente entidad llamada tipo servicio permite tener en cuenta el diseño y
orientación a servicios que son materia de investigación en este trabajo, esta entidad
también tiene una sub-clasificación análoga a la de los usuarios según el tipo de servicio.

69
Se ha diseñado una entidad llamada permisos con el fin de parametrizar los permisos de
los usuarios, es decir hacerla una tabla alimentada por un usuario puesto que si se toma
el permiso como un registro o tupla en la tabla de usuario, un usuario con varios roles
generaría un incremento de registros aumentando innecesariamente la cantidad de
información por usuario, obligando a una tabla de rompimiento o tabla de paso. Además
este aspecto también tiene implicaciones en la reducción de redundancia de relaciones
para evitar que se cierre el modelo según las premisas de (Codd, 1970).

Ilustración 6 Modelo Conceptual del Sistema de Información Empresarial.

Área de Producto
contiene Geográfico procesa
Interés

crea Operador
técnico

Cliente asesora

Jefe técnico

tiene Cuenta

Ilustración 7 Modelo Lógico del Sistema de Información Empresarial.

FechaSolicitud Tipo Prod

Área
Área Idarea ID Prod
procesa
Área de Producto
contiene
Interés Geográfico
Operador
técnico
crea

cedula nombre

Cliente cargo
asesora

cedula Jefe técnico

nombre
e-mail
cedula
tiene
Cuenta nombre

especialidad

fecha ID Cuenta

NumFactura

70
Ilustración 8 Modelo Físico del Sistema Empresarial:

5.2. Diagramas de Estado UML.

Continuando con el modelado del sistema en UML a través de la herramienta ArgoUML,

se han obtenido los diagramas de estado y de despliegue de componentes para los
diferentes procesos.

Ilustración 9 Diagrama de estado de Registro e Inicio de Sesión.

71
Ilustración 10 Diagrama de estado del Planeación de Vuelo.

Ilustración 11 Diagrama de estado del cargue de imágenes.

72
Ilustración 12 Diagrama de estado de Entrega De Productos.

Ilustración 13 Diagrama de estado de Entrega De Productos.

73
5.3. Modelo de datos geográfico.
Como se mencionó en el marco teórico en la sección de modelos de datos para el proyecto;
se hace necesario un modelo de datos para manejar la información espacial y otro para la
información empresarial. Para los análisis geográficos deben ser claras las capas de
información con sus atributos; un modelo de datos geográfico es la organización e
identificación de las entidades espaciales en el dominio del problema de acuerdo a la
topología arco/nodo empleada en todos los sistemas de información geográfica, o según
el modelo geométrico del OGC se establecen punto, curva, superficie (Aydin, 2007):
- Puntos: Centros de imagen.
- Curvas: Líneas de vuelo.
- Superficies: Área de interés, Área de Fotografía Aérea, Vuelo (polígono de captura de
un vuelo), Ortofotografía, (polígono del producto de la ortorrectificación de una Fotografía
Aérea), DEMs y DTMs (modelos de Superficie).
- Datos Ráster: Fotografías aéreas digitales, Ortofotomapa, Ortofotomozaico.

Ilustración 14 Modelo Conceptual del SIG

Ilustración 15 Modelo Lógico del SIG:

74
Ilustración 16 Modelo Físico del SIG:

5.4. Servicios
El concepto de servicio es bastante intuitivo para cualquiera que haya asistido a un
restaurante, contratado un plomero o haya hecho compras por internet. Sin embargo
tecnológicamente o en términos de TI, un Servicio web es un sistema de software diseñado
para soportar interacción de operaciones entre maquinas sobre una red. Tiene una
interface descrita en un formato procesable por maquina (específicamente WSDL). Otros
sistemas interactúan con el servicio Web de forma prescrita por su descripción con
mensajes SOAP típicamente transportados usando HTTP, exhibe una serialización XML
en conjunción con otros estándares relacionados a la Web (W3C, 2004) . “Los Servicios
Web son aplicaciones modulares, auto-contenidas que pueden ser descritos, publicados,
localizados e invocados sobre una red generalmente Internet” (IBM, 2000). “Un servicio se
implementa como una entidad de software descubrible de granularidad gruesa, que existe
como una sola instancia e interactúa con las aplicaciones y otros servicios” (Cotroneo, Di
Flora, & Russo, 2002). Estos conceptos tecnológicos con los que se aproxima a la
interoperabilidad y el bajo acoplamiento se observan en el uso de servicios OGC en el
sistema.

La información Geoespacial como cualquier otro dato capturado, analizado y procesado,

75
necesita de herramientas tecnológicas que permitan y hagan eficiente su manipulación
principalmente para grandes volúmenes. Con el crecimiento de los sistemas distribuidos y
adelantos como la web 3.0 y la visión 3D para maquinas, las interacciones entre los
productos de los datos son cada vez más complejas así como su administración. En la
búsqueda de control, las ciencias de la computación y la informática han usado la
experiencia de la industria para alcanzar niveles de abstracción cada vez más elevados.
En su objetivo más elevado los procesos de la industria siempre apuntan a la
comercialización de bienes y servicios, situación que no es ajena a la información
Geoespacial.

Los servicios web son piezas de software y como tal son susceptibles de metodologías de
desarrollo como el SDLC aunque con sus respectivas diferencias, sin profundizar
demasiado en el ciclo de vida de los servicios se observa que la primera fase es la de
identificación, según IBM, con la metodología SOMA la experiencia sugiere que los
enfoques generales para identificar los servicios son a veces demasiado restrictivos;
normalmente no se explotan todas las fuentes posibles para identificar los servicios a nivel
de empresa. Para llegar a dicha lista exhaustiva de servicios "candidatos", se recomienda
el uso de una combinación de tres técnicas complementarias: Descomposición de
Dominio, Análisis de Activos Existentes, y Modelado de Metas de Servicios.

5.4.1. Identificación de servicios.

Para generar la exhaustiva lista de servicios candidatos SOMA recomienda una
combinación de tres técnicas complementarias. De acuerdo con la aplicación realizada de
la metodología y la sugerencia de (W3C, 2004) se aborda la identificación a partir del
Modelamiento de Metas de Servicios por ser una actividad que toma ventaja respecto a la
Descomposición de Dominio en cuanto a que es una aproximación Top-Down y amplía la
visión del ecosistema (OASIS, 2012). Teniendo en cuenta que el proyecto se haya
enmarcado en la conceptualización y diseño de un sistema que aún no existe; se descarta
la técnica de Análisis de bienes existentes.
Después de haber compilado la lista de servicios candidatos, se utiliza una técnica que
extrae de la lista de servicios de candidatos sólo aquellos servicios relevantes para la
exposición.

Modelamiento de Metas de Servicios (MMS):

MMS Se utiliza para validar y desenterrar otros servicios no capturados por cualquiera de

76
 los enfoques de identificación de servicio. Asegura que los servicios clave no se han
olvidado. MMS proporciona el vínculo clave entre los objetivos de negocio y de IT a través
de la trazabilidad de los servicios directamente a un objetivo de negocio. El logro de la
meta a través del servicio de soporte, se mide a través de los KPI (Key Performance
Indicators) y sus métricas que son parte de las entradas del negocio. MMS también se
asegura de que la participación de los interesados y la rendición de cuentas se mantienen
a través de su consentimiento en los objetivos de negocio que deben ser logrados. Los
servicios directamente vinculados a los objetivos de negocio tendrían una mayor
probabilidad de ser priorizados y financiados para su posterior diseño e implementación.
Cabe señalar que MMS se puede utilizar como un mecanismo de alcance que ayuda a
definir el alcance de un proyecto, centrándose más profundamente en el dominio del
problema. Un dominio del problema es a menudo demasiado grande para ser abordado en
una iteración y por lo tanto es un método recomendado para verificar el alcance y para
reducir y determinar la identificación del área que ofrezca el más alto impacto (por la
realización de uno o más objetivos de negocio) en la empresa, en un plazo razonable y
aceptable (IBM, 2008).
Como en todo proceso que tiende a la automatización, lo más importante es reducir el
tiempo del proceso sin olvidar la evaluación de la calidad.

Tabla 17. Modelado de Metas de Servicio

Metas Submetas KPIs Métricas Procesos - Servicios Potenciales
Reducir el Cambio de la - Ingreso de área de
Velocidad promedio
tiempo de velocidad de cargue interés (AI).
de cargue; cantidad
cargue de del mes actual - Identificar
de imágenes /
imágenes respecto al mes Productos dentro de
unidad de tiempo.
crudas anterior AI.
Velocidad promedio - Cruce AI y áreas
Cambio en la Servicios de
de captura de de cobertura.
automatizar los velocidad de consulta de IG.
información; unidad - Análisis de áreas
procesos de captura del mes
de área capturada / de cobertura.
captura actual respecto del Recuperación y
Reducir tiempos unidad de tiempo - Captura de
mes anterior. procesamiento
de ejecución empleada. imágenes.
de información
- Recuperación y
geográfica
Velocidad promedio despliegue de
vectorial y
Cambio de la de procesamiento información de
ráster.
automatizar velocidad de de productos: calidad.
procesamientos procesamiento del cantidad productos - Servicios de
y análisis mes actual respecto procesados / monitoreo.
al mes anterior tiempo de - Recuperación y
procesamiento. visualización de
imágenes.

77
 Registro.
Cambio en número Número de clientes
Ofrecer
de clientes que que utilizan
servicios Inicio de sesión.
utilizan servicios servicios gratuitos /
gratuitos
gratuitos / mes mes
Análisis de áreas de
Relación productos cobertura.
cantidad de Servicios de
o servicios análisis.
asesorías Análisis
consumidos y
suministradas / geoestadísticos y
procesar asesorías que los Servicio de
unidad de tiempo predicciones.
resultados de conectaron Registro.
Atraer y
servicios Relación entre
mantener resultados de la Análisis de redes de
resultados Servicio de
clientes evaluación del distribución
favorables y facturación y
cliente geográfica.
desfavorables mensajería.
Servicios de
Servicios de
consulta.
cantidad de clientes Procesamiento
demostrar Consultas de
contactados por Servicios de
ventajas de los clientes por
servicios asesoría.
servicios a servicios
potenciales / unidad
pagar potenciales.
de tiempo Facturación y Pago
Mensajería.
Aumento de áreas
cantidad de áreas
analizar áreas potenciales de
potenciales de Meteorología y
potenciales de captura y de
captura analizadas sismología.
captura procesamientos Servicios de
por mes Servicios
Ampliar campos analizadas por mes. procesamiento
geoestadísticos y
de acción cantidad productos de información
redes.
contratar relación entre vendidos sin geográfica
Servicios de
asesorías nuevos procesos y solicitud previa clasificación
profesionales demanda de estos cantidad nuevos
procesos
Cantidad productos
Relaciones entre
consultados Entrega Servicio de
producto
ofrecer servicios servicios de consulta de IG.
consultado, Cantidad productos
de manejo de monitoreo
producto entregado entregados
Cumplir reclamaciones (disparadores) Servicio de
y producto
expectativas del Cantidad productos servicio de reclamos entrega.
cancelado
cliente cancelados y sugerencias Servicio de
pagos.
responder todos existencia Cantidad de Servicio de
los reclamos y reclamaciones no reclamaciones en análisis de AI.
sugerencias resueltas proceso de atención
Minutos de caída
relación entre del sistema durante
actualización tiempos de caída y el tiempo de
Mejorar gradual de TI disponibilidad disponibilidad
desempeño y escalables en diseñado. servicio de
aumentar función de Diferencia en monitoreo
Tiempo de duración
disponibilidad número de tiempos medidos de
de despliegue de
usuarios duración de
datos
despliegue de datos
(milisegundos).
(imágenes y tablas).

78
Como se puede observar en la columna llamada Procesos o Servicios Potenciales, se ha
hecho una agrupación inicial que permite tener una aproximación a las áreas funcionales
tal como lo sugiere la metodología, también se han homologado las agrupaciones de
servicios con las metas pero esta clasificación o agrupación cambia según el enfoque del
administrador, bien sea desarrollo o negocio. Además se puede ver como un servicio
puede ser invocado en diferentes áreas, como es el caso del servicio de análisis de áreas
de cobertura o los servicios de consulta de Información Geográfica.

Descomposición del Dominio.

Esta es una técnica Top-Down que también puede desagregarse en varias técnicas, para
(IBM, 2008) implica la descomposición del dominio del negocio en sus áreas funcionales y
subsistemas, incluyendo la descomposición de sus procesos de negocio en subprocesos
y casos de uso de negocio de alto nivel. Estos casos de uso son a menudo buenos
candidatos a servicios empresariales expuestos en la frontera de la empresa, o a través
de las líneas de negocio para que se utilicen dentro de los límites de la empresa. Además
de la identificación de servicios de candidatos, esta técnica ayuda a identificar las áreas
funcionales que aclaran los límites de los subsistemas. Para (Arsanjani, y otros, 2008) es
un análisis Top-Down de los dominios de negocios y el modelado de procesos de negocios
para identificar servicios componentes y flujos. Se analizan las vistas estática y dinámica
de los negocios incluyendo la información, reglas y variaciones.

De la comparación entre las dos fuentes principales se extraen los aspectos importantes
redundantes en la aplicación de la metodología; el dominio del negocio, la determinación
de áreas funcionales, la descomposición del modelo de negocio, la identificación de
servicios y los casos de uso de negocio.

Áreas Funcionales y Subsistemas.

En el análisis de áreas funcionales se descomponen los dominios del negocio en unidades
funcionales lógicas cohesivas y se nombra cada unidad como un área funcional (IBM,
2008), esta técnica provee un medio natural de identificar componentes más adelante
(Arsanjani, y otros, 2008), lo que concuerda con la metodología de UML para el diseño de
componentes. El modelo de dominio diseñado ayuda a establecer las principales áreas de
actividad, que se pueden organizar en una tabla presentada como ejemplo en la
metodología SOMA para la hallar los dominios del negocio y las áreas funcionales:

79
 Tabla 18. Áreas Funcionales y Subsistemas.
DOMINIOS
ÁREAS FUNCIONALES SUBSISTEMAS
DE NEGOCIO
Información Procesamientos y tratamientos de la 1. Almacenamiento, procesamiento y
geográfica información geográfica (productos y servicios administración de datos, productos y
sobre información vectorial y ráster). servicios geográficos.
Clientes y Clientes y Perfiles 2. Almacenamiento y administración de
facturación clientes y cuentas.
Facturación Pagos y Entrega 3. Almacenamiento y administración de
facturación asociada a cada cliente.
Recursos Personal y Roles, 4. Almacenamiento y administración de
Activos y especificaciones de activos. recursos humanos, tecnológicos y
perfiles de empleados.

Se entiende que el concepto de subsistema para UML tiene bastante afinidad con el de
Áreas Funcionales en SOMA puesto que se describen como agrupaciones de
funcionalidades o paquetes de aplicaciones comunes.

5.4.1.1. Descomposición del Proceso.

Según la metodología SOMA este es el siguiente paso en la descomposición del dominio,

consiste en descomponer el proceso de negocio en subprocesos constituyentes y luego
en actividades más atómicas o tareas. El modelo de proceso resultante presenta el flujo
de eventos a nivel de negocio y a nivel de TI (IBM, 2008), se enfoca en el modelamiento,
reglas, información y análisis orientado a la variación, proporciona la oportunidad no solo
de identificar servicios sino de los flujos de servicio que serán usados para orquestar los
servicios (Arsanjani, y otros, 2008).

Tabla 19. Descomposición del Proceso.

Subproceso de Inscripción e Inicio de Sesión.
Subproceso de Consulta.
Subproceso de Producción.
Subproceso de Pago.
Subproceso de Entrega.
Subproceso de Reclamos.

El conjunto de reglas de negocio ya ha sido establecido en el capítulo anterior de análisis

de la solución. A continuación la subdivisión lógica de los subprocesos en actividades:

Actividades del Subproceso de Inscripción e inicio de sesión.

- Ingresar Datos (datos de usuario y contraseña).

80
 - Crear cuenta.
- Registrar Datos (ingresar datos del cliente).
- Actualizar cuenta.
- Iniciar sesión.

Ilustración 17 Subproceso de inscripción e inicio de sesión:

Actividades del Subproceso de consulta.

- Asesoría Online.
- Ingresar Área de Interés.
- Análisis de Cobertura.
- Selección de Imágenes: el usuario selecciona las imágenes rechazadas del total
de imágenes desplegadas

Ilustración 18 Subproceso de Consulta.

Se observa en el diagrama del subproceso de consulta que la actividad de Análisis de

Cobertura es a la vez un subproceso reutilizable. Se modelo este proceso interno teniendo
en cuenta que el análisis se basa en hacer una conocida operación en el tema de
procesamientos digitales entre polígonos llamada “Clip” entre dos polígonos; el de
cobertura de imágenes y el de área de interés. Sus actividades son:

81
 - Porcentuar área de interés con área de cobertura.
- Generar Reporte.

Ilustración 19 Subproceso de Análisis de Cobertura.

Actividades del Subproceso de Diseño.

El subproceso de Diseño de vuelo ha sido creado como un servicio automático que se

especificará más adelante como un servicio reutilizable por el cliente o el operador en
momentos pertinentes durante el proceso de negocio:
- Generar Líneas de Vuelo. - Generar Fotocentros.

Ilustración 20 Diseño de Vuelo.

Actividades del Subproceso Producción.

Este subproceso se modela visualizando varios procesos efectuados por el operario y

diferentes programas o dispositivos, como los UAV o programas de procesamiento de
imágenes e información geográfica. Las principales tareas de producción son las
siguientes:
- Ejecución de vuelo. - Clasificación.
- Extracción y almacenamiento de - DEM, DTM.
atributos de imágenes. - Ortorrectificación.
- Preparación de imágenes y - Otros Análisis
georreferenciación.

82
Ilustración 21 Subproceso Producción.

Actividades del Subproceso de pago.

- Elegir forma de pago. - Generar Factura.

- Pagar Online - Confirmar pago

Ilustración 22 Subproceso de Pago.

Actividades del Subproceso de Entrega

- Elegir medio de entrega (físico o - Crear y enviar link de descarga.
digital). - Contactar servicio de impresión y envío

Ilustración 23 Subproceso de Entrega.

83
Cada actividad en el modelo de proceso resultante o en el árbol de fraccionamiento del
proceso es considerada un candidato para la exposición de servicios. Por esto cada una
es adicionada a una lista de servicios llamada Portafolio de servicios. En este punto, el
portafolio de servicios consta de todos los subprocesos, actividades y tareas desde las
definiciones para cada único proceso. La sección 5.4.3.2. Portafolio de Servicios, es el
recipiente de la lista de servicios candidatos que son identificados en este paso (IBM,
2008). Los métodos del ciclo de vida de la Información (CRUD) para cada una de las
entidades clave pueden ser considerados como servicios candidatos de información.
Diversas experiencias de la industria referenciadas en (Arsanjani, y otros, 2008) también
sugieren la inclusión de servicios que se observan comunes en áreas de CRM como:
Obtener datos del Cliente, Actualizar Cliente, Eliminar Cliente, Crear Cuenta, Obtener
Datos de Cuenta, Actualizar Cuenta, Borrar Cuenta, Crear Transacción, Obtener Datos de
Transacción, Actualizar Transacción, Eliminar Transacción y Buscar Clientes. Éstos se
encuentran implícitos en los subprocesos de registro, además hay servicios que evidencian
cuestiones de diseño como la posibilidad que un cliente pueda tener varias cuentas.

Especificación
La fase de especificación ayuda a diseñar los tres constructores de primera clase de SOA:
servicios, componentes de servicios y flujos. Se usa una combinación de tres actividades
de alto nivel para determinar qué servicios exponer, se provee una especificación detallada
para los servicios expuestos y se especifican los flujos y los componentes de servicios
(IBM, 2008). Las actividades son:
- Especificación de servicios.
- Análisis de subsistemas.
- Especificación de componentes.

5.4.1.2. Especificación de Servicios.

La especificación de servicios define las dependencias, composición, decisiones de

exposición, mensajes, restricciones de calidad del servicio y restricciones respecto a la
administración del estado dentro del servicio.
El portafolio de servicios tuvo una exhaustiva lista de servicios obtenidos a través de las
técnicas usadas para identificación de servicios. Es fácil comprender que esta lista puede
contener demasiados servicios candidatos, no todos del nivel de granularidad correcto para
ser expuestos como servicios. La decisión de exponer la lista entera de candidatos es el
perfecto anti patrón en SOA conocido como “síndrome de proliferación de servicios”, lo

84
 cual debe ser evitado principalmente por sus implicaciones prácticas y económicas. Para
este fin SOMA incluye en su metodología una técnica llamada Prueba de Tornasol para
Servicios (SLT por sus siglas en ingles). Aquellos servicios candidatos que superan la
prueba son los escogidos para exposición. La prueba consiste en cuatro criterios aplicados
en la tabla de la siguiente forma:

1. Alineación con el negocio: Implica trazabilidad del servicio con las metas del negocio.
2. Componibilidad: capacidad de un servicio a ser utilizado en un contexto totalmente
diferente del que el servicio era originalmente identificado. Un servicio debe ser capaz de
participar en múltiples procesos de negocio sin comprometer el cumplimiento de los
Requerimientos No Funcionales para el proceso.
3. Viabilidad de Implementación: se evalúa la factibilidad técnica de la aplicación del
servicio en función de la eficiencia en costos y tiempo. consideraciones prácticas limitan
que servicios demasiado complejo se usen en la implementación.
4. Eliminación de redundancia: pruebas de si el servicio se puede utilizar dentro de todos
los procesos y aplicaciones donde se necesita (IBM, 2008).

Tabla 20. Aplicación de la Prueba de Tornasol para Servicios (SLT):

PRUEBA
1 2 3 4 RESULTADO
SERVICIO
Registro si si si exponer
inicio de sesión si si si Redundante dentro de registro
recuperación de contraseña si si si Redundante dentro de registro
ingreso de área de interés si si si Redundante Dentro de Consulta, recuperación, etc.…
Cruce de áreas de interés con
si si si Redundante dentro de análisis de áreas de cobertura
puntos de foto centros.
Cruce de áreas de interés con
si si si Redundante dentro de análisis de áreas de cobertura
áreas de cobertura.
análisis de áreas de cobertura si si si Redundante dentro de análisis y procesamientos
Análisis y procesamientos si si si Redundante área funcional
Consulta y recuperación de IG
si si si exponer
vectorial y ráster
recuperación y despliegue de
no si si Redundante Dentro de Consulta, recuperación, etc.…
información de calidad
recuperación y despliegue de
no si si Redundante Dentro de Consulta, recuperación, etc.…
fotos
captura de imágenes si si si exponer
Planeación de vuelo – Diseño
si si si exponer
de Vuelo
dentro del servicio de captura de
Ejecución de vuelo si si si redundante
imágenes
Cargue de imágenes al sistema. si si si exponer

85
Calculo de precio. si si si redundante Dentro de Consulta, recuperación, etc.…
Facturación no si si redundante dentro de pago
Pago si si si exponer
Entrega si si si exponer
Mensajería no si si redundante dentro de entrega
meteorología y sismología no no si consumo de servicios
Monitoreo de KPIs no si si servicios internos
Asesoría si si si exponer
Análisis geoestadísticos y
si si si redundante dentro de asesorías
predicciones.
Análisis de redes de distribución
si si si redundante dentro de asesorías
geográfica.
Crear AI no no si redundante dentro de Ingreso de AI
Modificar AI no no si redundante dentro de Ingreso de AI
Borrar AI no no si redundante dentro de Ingreso de AI
Visualizar AI no no si redundante Dentro de Consulta, recuperación, etc.…
Obtener datos de cliente no si si redundante redundante con Obtener datos de cuenta
Actualizar cliente no si si redundante dentro de Registro
Borrar cliente no no si redundante dentro de Registro
Crear cuenta no no si redundante dentro de Registro
Obtener datos de cuenta no si si redundante dentro de generar recibo de pago
Actualizar cuenta no si si redundante dentro de Registro
borrar cuenta no no si redundante dentro de Registro

Las redundancias fueron analizadas con respecto a la composición más que al hecho de
que ya existan los servicios o funcionalidades en otras áreas de la organización, es decir
inicialmente los servicios básicos no serían expuestos y quedan redundantes si se exponen
junto con servicios que los contienen.

Cabe mencionar que los criterios también pueden ser diseñados de acuerdo al entorno,
ambiente o ecosistema, además se han tenido en cuenta en la evaluación y el diseño los
aspectos que caracterizan a los servicios como la granularidad, carencia de estado
(stateless), idempotencia, reusabilidad y componibilidad, en este caso la información
georreferenciada gráfica también representa un agente en el ecosistema. Un criterio de
decisión que se hace visible para la exposición de servicios en función del área de negocios
también podría ser (según el autor de esta tesis): Exponer solo servicios que procesen
información georreferenciada.

Ahora que la lista de servicios ha sido definida, la lista de servicios escogidos para
exposición constituye el portafolio de servicios refinado, cada servicio en este portafolio
ahora necesita ser provisto con una especificación detallada. El primer paso en la

86
especificación es identificar las dependencias de servicios.

De los servicios que han sido producto de los procesos de la metodología SOMA, se han
escogido tres principales a ser documentados, se aclaran las operaciones del servicio y se
describe en leguaje natural así como las precondiciones funcionales, no las técnicas.
1. Servicio de Consulta de Información Geográfica.
2. Servicio Cargue de Imágenes.
3. Servicio de Planeación de Vuelo
Estos representarían las líneas de contacto con el usuario y la información o “núcleo del
negocio” como se verá en la sección de gobierno, en el escenario de implementación del
prototipo el Servicio Cargue de Imágenes se evidencia con un formulario que simula un
ejemplo de cómo sería la vista para la actividad de Cargue de Imágenes. A continuación
se explican los servicios y la forma como establece lo que hace cada servicio mediante la
documentación de las operaciones:

Tabla 21. Servicio de Consulta de Información Geográfica.

Nombre Servicio Consulta de IG

El Servicio identifica los productos o datos geográficos que tienen

Descripción Servicio relación espacial con el área de interés del cliente y genera un reporte
de los atributos de cada producto.

Tabla 22. Operación Ingresar área de interés del Servicio de Consulta de Información
Geográfica (WFS-T):

Nombre Operación Ingresar área de interés.

El cliente dibuja un polígono en un mapa con información

Descripción Operación
cartográfica básica a la escala deseada.
Precondiciones La cartografía básica se visualiza en el visor geográfico
Se genera un polígono en archivo .shp con los campos de datos
Post condiciones
del usuario, fecha de creación y área en m2.

Tabla 23. Operación Análisis de cobertura del Servicio de Consulta de Información

Geográfica (WPS).
Nombre Operación Análisis de cobertura
Operación que permite hallar el porcentaje de área de interés del cliente
Descripción que no es cubierto por el área de cobertura total de los productos de la
Operación organización. La operación espacial es un clip entre el polígono de
aéreas de interés que corta al de áreas de productos.

87
 Los polígonos de área de interés y área total capturada de productos
Precondiciones
están actualizados.
Se genera un reporte en metros cuadrados
Post condiciones
Se visualiza el área faltante.

Tabla 24. Operación Identificación de imágenes del Servicio de Consulta de Información

Geográfica. (WPS)
Nombre Operación Identificación de imágenes
Operación que permite identificar las imágenes afectadas por el Área
Descripción de Interés mediante una operación espacial de selección por
Operación localización entre los polígonos de las imágenes que sean cruzadas por
el área de interés.
Las imágenes deben haber sido procesadas para que sus polígonos en
Precondiciones
formato .shp permitan hacer la consulta espacial.
Se visualiza una lista de las imágenes afectadas por el área de interés
Post condiciones
del usuario con su respectiva información de calidad.

Tabla 25.Servicio Cargue de Imágenes.

Nombre Servicio Cargue de Imágenes
El Servicio permite que un usuario que puede ser un cliente registrado o
Descripción
un operario cargue o almacene imágenes digitales en la base de datos
Servicio
geográfica de la organización.

Tabla 26. Operación Cargue de Imágenes del Servicio de Cargue de Imágenes

Nombre Operación Cargar imágenes
El cliente registrado o el operario cargan la imagen digital a una
Descripción
ubicación determinada en la estructura de almacenamiento de datos de
Operación
la organización.
Si la imagen es cargada por el operario, debe estar post procesada.
Precondiciones
El cliente puede cargar imagen en cualquier tipo de formato.
Se notifica la confirmación de la cantidad de imágenes que han sido
cargadas.
Post condiciones
Si la imagen es cargada por el cliente se le pregunta qué tipo de procesos
desea sobre esta.

Tabla 27. Servicio de Planeación de Vuelo (WPS).

Nombre Servicio Planeación de vuelo
Nombre Técnico Planeación de vuelo

88
 El Servicio crea líneas de vuelo y centros de exposición dentro del
Descripción Servicio área de interés del cliente, calcula la cantidad de fotos y genera
archivos .shp de línea y punto

Tabla 28. Operación Calcular líneas de vuelo del Servicio de Planeación de Vuelo (WPS).
Nombre Operación Calcular líneas de vuelo
Operación que crea las líneas de vuelo y las distancias entre centros de
Descripción
fotografías en función de los traslapes horizontales y verticales que el
Operación
usuario ingrese.
Se conoce el área de la foto, el usuario ha ingresado el área de interés
Precondiciones y los porcentajes de los traslapes vertical y horizontal.

Se genera un informe con la información de la cantidad de fotos que se

Post condiciones
pueden tomar y el valor.

Cálculo de líneas
La sucesión de imágenes para la fotogrametría convencional de captura con avión se
puede reproducir en un vuelo fotogramétrico de objeto cercano con UAV, la trayectoria está
basada en una línea de vuelo en forma de S alargada horizontalmente,

Para calcular las líneas de vuelo se emplean los porcentajes de los traslapes deseados
por el cliente o los valores por defecto. Según las premisas de diseño, existe una alta
probabilidad de que el cliente no tenga conocimientos de fotogrametría de manera que no
está en capacidad de proporcionar o estimar traslapes de vuelo, por lo que el servicio
podría tener un traslape por defecto entre fotos consecutivas de un 60% y entre fotos de
fajas adyacentes de un 30%, aunque los vuelos con drones permiten traslapes
favorablemente más elevados con la lógica demanda de almacenamiento. Las líneas de
vuelo se pueden calcular automáticamente para este trabajo, así:
Tomando como base el área de interés representada en coordenadas planas, la diferencia
de coordenadas en el eje X permite determinar la distancia horizontal a dividir; es decir la
distancia de separación de las líneas de vuelo en dirección norte-sur (el azimut puede
variar). Se asume que el área de interés no es demasiado irregular como para que los
cálculos puedan arrojar resultados poco eficientes de la cantidad de imágenes, este
aspecto hace evidente la necesidad de que cada área sea revisada por un operador o un
algoritmo que permita evaluar la regularidad de un polígono o la eficiencia de la estimación,
una condición para evitar revisión puede ser que la relación entre la base (diferencia de

89
coordenadas horizontales) y la altura (diferencia de coordenadas verticales) del área de
interés sea lo más cercana posible a 1, es decir casi un cuadrado.
La distancia entre líneas depende del área de captura del UAV (tomada sobre un plano),
ésta área de captura de cada fotografía aérea depende a su vez de la altura y de la
distancia principal de la cámara, así como de los megapíxeles de ancho y alto que tenga
el sensor, estas variables se analizan aun cuando son parámetros específicos de la cámara
en el UAV y reglamentaciones locales de operación de estos dispositivos. La utilización de
ecuaciones fotogramétricas estándar halladas en la bibliografía, seguramente esta
embebida en los componentes de software fotogramétrico y de las cámaras. La altura
máxima de vuelo permitida por la Aerocivil en Colombia es de 500 pies (150.4 m) (Aerocivil,
2014).

Mediante una simple relación se ha deducido y expresado en la Ecuación 1 la extracción

de la distancia de separación de las líneas de vuelo:

(100− %tv)
Ecuación 1 DL = bi ∗
100

Donde:
DL = Distancia entre líneas de vuelo
bi = longitud de la base de la imagen (extraíble de los parámetros de vuelo y cámara)
%tv = porcentaje de traslape vertical

Esta relación también aplica para calcular la separación entre foto centros a lo largo de
una línea de vuelo de la siguiente forma.

(100− %th)
Ecuación 2 DF = ai ∗
100
Donde:
DF = Distancia entre foto-centros.
ai = longitud de la altura de la imagen.
%th = porcentaje de traslape horizontal.

Un análisis más riguroso que tenga en cuenta los parámetros de la cámara y la altura de
vuelo se hace reemplazando en la ecuación 1 el término bi por su equivalente en función
de la distancia focal, la altura de vuelo y el tamaño del pixel en la cámara, así:

90
 Tp∗Np∗h (100− %tv)
Ecuación 3 DL = [ ]
f 100
Donde:
DL = Distancia entre líneas de vuelo.
Tp =Tamaño del pixel de la cámara (generalmente expresado en micrómetros).
Np =Numero de pixeles del ancho del sensor.
h = Altura de vuelo (generalmente en metros).
f = Distancia focal de la cámara (generalmente en milímetros).
%tv = porcentaje de traslape vertical.

La misma relación aplica para la distancia entre fotocentros pero teniendo en cuenta que
existen cámaras en cuyo sensor el ancho es diferente del alto; esto significa que para la
reemplazar en la ecuación 2 el término Np se debe observar la documentación de la
cámara.

5.4.1.3. Análisis de Dependencias.

En la Tabla 20 de dependencias se asigna el valor de 1 a los servicios que presentan

dependencia y el valor de 0 a los que son independientes, sin embargo esta dependencia
fue analizada en función de procesos como servicios potenciales y la secuencia que
plantea el proceso de negocio.
Se puede observar que todos los servicios dependen de que el usuario esté registrado, en
este contexto la relación entre Pago y Registro que establece la dependencia es de forma
que el cliente debe estar registrado para pagar los servicios recibidos puesto que pagar
para registrarse puede ser una estrategia comercial poco promisoria, la relación inversa se
refleja en la sección opuesta (superior derecha) a la diagonal de la matriz.

Tabla 29. Análisis de dependencias

Consulta de
Información
Diseño de

Imágenes

Asesoría
Registro

Captura

Entrega
Cargar
Vuelo

Pago

Registro - 0 0 0 0 0 0 0
Diseño de Vuelo 1 - 1 0 0 0 0 0
Consulta de Información 1 0 - 1 1 0 0 0
Cargar Imágenes 1 1 0 - 1 0 0 0
Captura 1 1 0 0 - 1 0 0
Pago 1 1 1 1 0 - 0 0
Asesoría 1 0 0 0 0 0 - 0
Entrega 1 1 1 1 1 1 0 -

91
El servicio de Diseño de Vuelo es gratuito y el cliente puede solicitarlo independiente de
otros, pero no de Registro ni de Consulta. El servicio de Consulta de IG también es gratuito,
su dependencia en el proceso se ve reflejada cuando el cliente luego de haberse registrado
lo solicita directamente, para lo cual deben existir imágenes capturadas y cargadas a la
base de datos bien sea que hayan sido cargadas por el cliente luego del servicio de Cargue
de Imágenes; donde la relación de dependencia toma el valor de 1 con éste servicio, pero
si el cargue es realizado por el operario podría tomar el valor de 0 en lo que se podría
considerar un proceso asíncrono, (extrapolando el concepto de comunicación asíncrona)
en términos donde la secuencia no es inmediata ni se activa por el mismo actor.
El servicio de Captura de Imágenes (asociado al Subproceso de Producción) y el de
Cargue de Imágenes presentan dependencia de forma en que si la captura ha sido hecha
mediante procesos internos de la organización; la dependencia existe pero si ha sido el
Cliente quien ha cargado las imágenes, entonces el servicio no tiene dependencia.
Las dependencias en función de componentes tecnológicos específicos no se analizan
puesto que no se actúa sobre un sistema legado.
Según (IBM, 2008), con las dependencias representadas, la siguiente actividad natural es
identificar composiciones y flujos de servicios. Los servicios que toman parte en una
composición, son una colección de servicios relacionados para solucionar una función de
negocio específica de alto nivel. Sin embargo, las composiciones y flujos de servicios son
visualizadas en la subsección Descomposición del Proceso.

5.4.1.4. Análisis de Subsistemas

Los subsistemas se identifican al efectuar descomposición funcional de las áreas

funcionales (Arsanjani, y otros, 2008), esta actividad se realizó de forma simultánea con la
identificación de áreas funcionales al inicio de esta sección llamada Identificación de
Servicios.
Así como las áreas funcionales proporcionan una agrupación lógica de un dominio de
negocio, un subsistema de TI es una agrupación semánticamente significativa de
artefactos lógicamente coherentes, que están en forma de componentes y clases (IBM,
2008). El análisis corresponde a la subdivisión lógica de los subsistemas en componentes
que según la metodología UML son agrupaciones de clases. Como se ha observado a lo
largo de la aplicación de la metodología SOMA, las actividades han sido análogas a la
metodología UML, no es coincidencia que el resultado del análisis de subsistemas se
traslape con los componentes puesto que la SOMA se ha basado en estándares y UML es

92
 ampliamente aceptado. Es en el análisis de subsistemas donde convergen las
aproximaciones bottom-up de UML y top-down de SOMA para el sistema de información.

Tabla 30. Análisis de Subsistemas.

SUBSISTEMA SERVICIOS
Registro Inicio de sesión Recuperación de contraseña
Borrar cliente Actualizar cliente
Crear cliente
Análisis y Cruce de áreas de interés con áreas meteorología y sismología
procesamientos de fotos.
Cruce de áreas de interés con áreas Análisis geoestadísticos y
de cobertura. predicciones.
Análisis de áreas de cobertura Análisis de redes de geográficas.
Consulta y Crear Area de Interes (AI), Modificar Ingreso de área de interés
recuperación de AI, Borrar AI, Visualizar AI
IG vectorial y Recuperación y despliegue de Monitoreo
ráster información de calidad

Recuperación y despliegue de fotos

Captura de Planeación de vuelo
imágenes Ejecución de vuelo
Cargue de imágenes al sistema.
Pago Crear factura Facturación
Obtener datos de cuenta, Actualizar Calculo de precio.
cuenta, borrar cuenta
Entrega Descarga. Envío, Impresión.

5.4.2. Componentes.
Los componentes han sido esbozados desde el punto de vista lógico y de acuerdo con el
diseño que se ha realizado en la sección de modelamiento de metas de servicios. Desde
el punto de vista de agrupaciones de código para áreas específicas, y en cuanto al diseño
en UML se conceptuaron los siguientes componentes con la herramienta ArgoUML.
 Componente Geográfico  Componente Servicios
 Componente Presentación  Componente Persistencia
 Componente Lógico de negocio  Componente Acceso a datos.

Se ha seguido un patrón para invocación de servicios web del lado del servidor; por cada
servicio expuesto del componente geográfico que también es un servidor se planea tener
una interfaz, por lo cual se dividen los componentes en siete nodos de acuerdo a los
componentes de servicio e interfaces, luego en los componentes de clase se implementan
las interfaces y la lógica de operaciones.

93
A continuación una breve descripción de los componentes diseñados para cada nodo:
Nodo ServicioGeográfico: manejo de Información Geográfica.
 IServicioOperacionGeografico: este es un componente geográfico que abarca todo lo
relacionado con las operaciones geográficas.
 IServicioOperacionGeograficoImp: componente de implementación de las operaciones
espaciales de los servicios.

Nodo InterfazServicioOperación: alojamiento de la lógica de negocio.

 IServicioConsultaIG: componente de invocación del servicio de consulta de Información
Geográfica.
 IServicioIngresarAI: componente de invocación del servicio de ingresar Área de Interés.
 IServicioCargueImagenes: componente de invocación del servicio de Cargue de
Imágenes al sistema.

Nodo Web: encargado de presentación.

 WebController: componente derivado del modelo vista controlador encargado de mediar
lógica y presentación.
 xhtml: codificación de la vista de la página.

Nodo InterfazSevicioProcesos: administración de procesos.

 IServicioProceso: interfaz de servicios de procesos.
 IServicioTarea: interfaz de servicios de las respectivas tareas de cada proceso.

Nodo ServicioOperacionImplementacion: implementación que hace parte de la lógica

de negocio.
 ServicioConsultaIGImpl: componente de implementación de las interfaces de los
servicios de consulta de Información Geográfica.
 ServicioIngresarAIImpl: componente de implementación de las interfaces de los servicios
de ingreso de Área de Interés.
 ServicioCargueImagenesImpl: componente de implementación de las interfaces de los
servicios cargue de imágenes.

Nodo ServicioProcesosImplementacion: hace parte de la implementación para las

interfaces del componente de procesos.
 ServicioProcesoImpl: componente de implementación de interfaces de servicios de
procesos.

94
ServicioTareaImpl: componente de implementación de interfaces de servicios tareas de
procesos.

Nodo AccesoDatos: Persistencia y acceso a datos.

 EntityBean: componente de referencia a persistencia en bases de datos.
 DAO: consultas hacia la base de datos
La siguiente ilustración corresponde al diagrama de despliegue para los componentes del
sistema:

Ilustración 24 Diagrama de Despliegue.

Debido a restricciones en recursos para codificación del sistema, ya que el diseño de

diagramas de clase UML por nodo exige experiencia para hallar relaciones y enfoque en
el desarrollo de funciones más complejas, se ha optado por diseñar únicamente las clases

95
del nodo de ServicioGeografico en el componente de procesos para mostrar un ejemplo.
Las interfaces modeladas en diagrama de clases son descomposiciones o
especializaciones de componentes interface del diagrama de despliegue.
Por cada clase hay tres operaciones que se pueden ver en el diagrama. Los Gestores
(modelados como clases) se encargan de recibir peticiones REST, estas peticiones son la
puerta de entrada de servicio puesto que todo servicio se comporta bajo el modelo
arquitectónico cliente/servidor. En los gestores se reciben las peticiones, como se trata de
procesos todo se trabajara por REST debido a que los procesos cumplen la dupla
clave/valor donde la clave seria el nombre del atributo y el valor seria el valor que toma ese
atributo. Las características de este diseño de clases también fueron orientadas por las
premisas de monitoreo que se encuentran implícitas en los conceptos de SOA.

En cuanto a la arquitectura en el servidor de procesos, se ha diseñado en la clase Proceso

que el identificador del Proceso sea IdObjeto generado manualmente para la identificación
del proceso. El identificador del proceso es generado por el servidor de procesos
automáticamente y el IdObjeto es generado de forma secuencial con el fin de facilitar la
búsqueda en la base de datos, puesto que es más fácil buscar un autonumérico que la
cadena de texto generada por el servidor de procesos.

La secuencia se realiza de la siguiente forma; primero se hace la invocación, cada gestor

es el encargado de dar punto de partida para la invocación del servicio, luego se usa la
interfaz para llamar el método respectivo. A continuación el servicio invoca el DAO por
medio de una interfaz, en el DAO es donde se hace la consulta de base de datos respectiva
y finalmente el DAO usa el EntityBean respectivo como contenedor de información para
retornar la respuesta en los EntityBean de Proceso y de Tarea.
La clase consulta sobre procesos no sigue el mismo esquema de los DAOs porque realiza
consultas particulares sobre tareas en las cuales los parámetros de entrada son procesos.

Ilustración 25 Diagrama de clases para el nodo de ServicioGeografico.

96
97
5.4.2.1. Comunicaciones.

Como ya se ha mencionado los servicios web no son la única forma de implementar una
SOA, sin embargo de acuerdo al proyecto, resultan la mejor forma de aplicación puesto
que las arquitecturas de comunicación como RPC, CORBA, ORB o RMI han sido
desarrolladas en base a una comunicación entre sistemas en funcionamiento o legados, a
partir de lo cual han evolucionado los servicios web. Un eventual problema con la
comunicación a través de servicios web seria el aumento en la complejidad de
comunicaciones al aumentar el número de usuarios y peticiones. Pero esta eventualidad
tendrá una solución pertinente mediante la implementación de un Bus de Servicios
Empresariales ESB. En SOA la unidad básica de comunicación es el mensaje para lo cual
se definiría un contrato en WSDL para los patrones de intercambio de mensajes.
De la información que ofrece la arquitectura de referencia acerca de la capa de integración,
es evidente que para SOA es necesario el ESB. SOA podría funcionar sin este elemento
de software pero esto delegaría más trabajo al proveedor y al consumidor de servicios en
cuanto al establecimiento de las conexiones y comunicaciones causando el aumento del
acople de los servicios, perdida de escalabilidad y a la vez de interoperabilidad. Además
de esto el ESB provee otras ventajas relacionadas con el mapeo de datos, ruteo inteligente
(balanceo de carga), administración de servicios, monitoreo e incluso seguridad. Las
opciones del ESB con respecto a la conexión son:
- Conexión punto a punto. - Conexión través de un mediador.
Las conexiones punto a punto presentan un problema al aumentar la cantidad de acople
en las conexiones físicas y la tolerancia a fallos es bastante baja, aun cuando el ESB
provea solamente de conexiones punto a punto también se puede lograr bajo acoplamiento
pero incrementando la complejidad con el uso de middleware interceptores o proxies
adicionales, en tanto que las conexiones a través de un mediador o agente hacen una
infraestructura de acople más holgado, (Josuttis, 2007).
En cuanto a la responsabilidad del ESB desde el punto de vista de los consumidores y
proveedores, hay dos aproximaciones; que sea dirigido por el protocolo o que sea dirigido
por APIs, la conclusión es que las mayores ventajas son ofrecidas por el ESB dirigido por
APIs en cuanto a implementación y escalabilidad, en este caso el problema de mapear
llamadas de servicios e implementaciones de servicios a mensajes bien formados que los
participantes puedan enviar sobre el ESB, es tarea del grupo que provee el ESB. El ESB
se ha desarrollado igual que las SOA con los sistemas distribuidos y su implementación en
un escenario real seria obligatoria dependiendo de la escala del sistema.

98
La mensajería con objetos para la comunicación entre servidores será atendida mediante
la técnica REST se empleara como trama XML para la interacción entre datos geográficos.

5.4.2.2. Estructura física.

La estructura física del sistema corresponde a los tipos de servidores y la lógica de

conexiones para las peticiones que son enviadas y recibidas por cada servidor; las
peticiones enviadas desde la aplicación web en internet son enviadas al servidor web, este
consulta al servidor de aplicaciones donde se almacena la lógica de negocio que a su vez
hace la solicitud al servidor geográfico de los datos espaciales y al servidor FTP. El servidor
geográfico a emplear será Geoserver que responde al servidor de aplicaciones. El servidor
de aplicaciones será Apache y el servidor web será Tomcat.
Teniendo en cuenta que las imágenes que han de ser cargadas necesitan ser livianas,
tendrán una calidad y por tanto resolución menores, para mejorar el desempeño se
instalara un servidor FTP como archivador temporal para disponer de las imágenes tanto
para la descarga como para el despliegue en internet, este servidor recibirá las peticiones
del servidor de aplicaciones y responderá al servidor web de forma asíncrona.

Ilustración 26 Estructura física.

99
5.4.3. Catálogo de Productos Y Portafolio de Servicios.
En el ciclo de vida de los servicios de forma general para todas las metodologías, está
contemplado como primero el descubrimiento o identificación, al igual que en SOMA, de
esta forma el ingrediente básico de la arquitectura son los servicios que también pueden
ser productos, para este caso específico tenemos los servicios básicos y de información
geográfica que pueden ser consumidos u ofrecidos en una coreografía. Cada actividad en
el modelo de proceso es considerada candidata a la exposición como servicio, de aquí que
sea adicionada a una lista llamada portafolio de servicios (IBM, 2008).

5.4.3.1. Productos.

Los productos son los resultados finales de las tareas y procesos efectuados sobre las
entradas de Información Geográfica, son principalmente imágenes que han tenido algún
tipo de procesamiento o modelos de superficie representando diferentes aspectos de los
datos originales. Pueden adquirirse en diferentes formatos digitales o impresos, la
siguiente lista es un ejemplo pero puede ser corta:
- Imagen Cruda. - Imagen Ortorrectificada. - Imagen Georreferenciada.
- Imagen Clasificada. - Imagen Ortofotomapa. - DTM, DEM.
Ninguno de los productos mencionados es generado en la implementación del prototipo,
mencionarlos es parte únicamente del diseño puesto que cada uno corresponde a labores
técnicas especializadas que incluyen análisis, las cuales no son objeto de investigación en
este trabajo.

5.4.3.2. Portafolio de Servicios.

Los análisis en SIG tienen el principal propósito de apoyar la toma de decisiones y el

modelado de posibles consecuencias y oportunidades en el proceso de negocio (Pascaul,
y otros, 2012), la clasificación de servicios dentro del sistema ayuda a la delimitación de
las fronteras del sistema, fronteras tanto internas como externas que pueden iniciar su
delimitación con los tipos de servicios sobre los que se basa el diseño del sistema.

Servicios básicos de sistema:

Registrar usuario, Actualizar datos de usuario, Borrar usuario, Recuperar contraseña,
Obtener datos de cliente, Inicio de sesión, Crear cuenta, Actualizar cuenta, Borrar cuenta,
Crear Área de Interés (AI), Modificar AI, Borrar AI, Visualizar AI (WFS-T). Despliegue de

100
información de calidad. (WFS). Cruce de AI con polígonos de productos disponibles.
Análisis de cobertura (WPS). Recuperación y despliegue de productos. (WMS).

Servicios compuestos de sistema.

Captura de imágenes, Cargue de imágenes al sistema, Planeación de vuelo (WPS),
Ejecución de vuelo, Meteorología y sismología (WMS), (WPS), Monitoreo de KPIs, Análisis
geoestadísticos y predicciones (WPS), Análisis de redes de distribución geográfica (WPS),
Sesión de Usuario, Cálculo de precio, Facturación, Mensajería, Pagos, Impresión, Envío.
Al pasar las actividades del proceso de negocio a servicios, es necesaria una
conceptualización clara de lo que es un servicio web y como debe diseñarse para que sea
útil en un ambiente distribuido, sin embargo buena parte del éxito en el diseño se encuentra
en la experiencia de diseño de subsistemas y el conocimiento de entornos de desarrollo.

5.5. Gobierno de SOA.

Esta sección se considera necesaria de acuerdo a la documentación en (Josuttis, 2007)
adoptada para la proposición de la arquitectura. Documentación adicional hallada en
(Pavlovič, 2009), establece que las bases de gobierno incluyen:
 Políticas que definan lo que está bien.
 Procesos que respalden las políticas (sección 4.1).
 Métricas que permitan visibilidad y verificar la aplicación de las políticas (definidas como
indicadores clave de desempeño (KPI) en la sección de análisis de la solución).
 Organización que establezca una cultura que apoye el proceso de gobierno.
Las preguntas específicas para la definición de gobierno en una SOA se han compilado de
(Hurwitz, Bloor, Baroudi, & Kaufman, 2007) y (OASIS, 2012), se presentan a continuación
seguidas de las respectivas respuestas para establecer los lineamientos de la organización:

¿Cuál es el núcleo de valores que define el negocio?

La organización está dedicada a administrar información espacial, entre cuyas actividades
se encuentra capturar y distribuir fotografías aéreas de un dron, así como los productos y
análisis derivados de esta información básica, todo en Internet usando servicios web.

¿Cómo se negocia con los clientes?

El cliente realiza un pedido y debe recibir una respuesta del tiempo de ejecución (tiempo
de entrega estimado a partir de la confirmación de la orden de pedido) y costo de su pedido
en menos de 6 horas.

101
Se ofrecen servicios gratuitos con el fin de registrar la información que el cliente suministra
y analizarla para poder descubrir servicios potenciales y mejorar los actuales.

¿Cómo se negocia con los socios?

La relación con los socios debe ser de carácter cooperativo y estratégico en función de las
demandas o sugerencias de los clientes y los márgenes de utilidades; se negociará con
otras organizaciones la oportunidad de acceder al mercado o usuarios regionales contra
los servicios de procesamientos más avanzados y automáticos de datos como los de
clasificación (ofrecidos por otros países a través de internet) en tanto que se apoyarán
investigaciones para desarrollar los propios en la medida que lo permita el costo.

¿Cómo asegura la compañía que los interesados son tratados con equidad?
Los interesados, establecidos en capítulos anteriores deben ser escuchados de la forma
más atenta y detallada posible, sus observaciones, sugerencias, demandas y opiniones
deben registrarse claramente en el sistema mediante herramientas tecnológicas que
permitan el seguimiento de sus necesidades, para que éstas puedan ser analizadas con el
fin de satisfacer las actuales y tratar de anticiparse a las futuras necesidades.

¿Cómo se estructura la compañía de forma que se sigan los principios y reglas de

negocio?
La estructura organizativa de roles asigna la toma de decisiones a los roles administrativos
y el jefe técnico exclusivamente (acompañados de una asesoría oportuna y de calidad),
los roles de clientes, desarrolladores y operadores deben tener herramientas que faciliten
la consulta y verificación de las reglas de negocio y el monitoreo de sus actividades, esto
también se puede entender como la aplicación de las políticas y reglas de negocio
diseñadas por la administración y la jefatura técnica.
Solo a partir del eventual crecimiento de procesos, aumento de servicios y por consiguiente
de necesidades de recursos, la estructura podrá enriquecerse con un grupo central de
expertos dedicados a la federación de SOA. Se prevé que este cambio será gradual para
lo cual deben escogerse las herramientas escalables y una organización bien definida.

¿Qué decisiones deben tomarse para realizar una administración y uso efectivos?
La calidad de las decisiones depende de la cantidad y calidad de la información acerca de
las posibles opciones de un caso en particular, bajo los lineamientos de las políticas y las
restricciones de las reglas de negocio, además la información de las capacidades o el
potencial del área de TI debe ser actualizada y fácil de consultar junto con el estado y

102
disponibilidad de los recursos (monitoreo). Solo en estas condiciones se garantiza que una
decisión tomada sea la mejor en función de una ponderación rastreable y documentada en
contraposición con otras posibles decisiones. Las primeras decisiones se han tomado ya
sobre las opciones del SMBD y los servidores, las decisiones sobre la capacidad de
almacenamiento, procesamiento y diseño para los diferentes dispositivos y herramientas
están principalmente atada al presupuesto.

¿Cómo se comunican estas decisiones?

La red empresarial debe proveer servicios de mensajería electrónica, aparte de la
mensajería electrónica personal de los empleados y al menos dos cuentas en redes
sociales. También se deben hacer mínimo dos reuniones mensuales para evaluar los
indicadores y el grado de alcance de las metas.

5.6. Objetivos Estratégicos.

Son los fines que se persiguen por medio de una actividad de una u otra índole.
Representan el punto terminal de la planeación y el fin que se persigue mediante la
organización, la integración de personal, la dirección y el control (Koontz & Weihrich, 2004).
La diferencia con los objetivos antes mencionados en el Capítulo 1 es que aquellos son
establecidos desde un punto de vista académico mientras que estos tienen un punto de
vista corporativo. Los objetivos estratégicos cuentan con las siguientes características:
- Cuantificables. - Estimulantes.
- Realizables en calidad. - Escritos en forma jerárquica. (Koontz
- Específicos en tiempo. & Weihrich, 2004)
- Comprensibles.

Objetivos Estratégicos:
- Equilibrar permanentemente la calidad de los productos y los costos de producción,
procesamiento y envío.
- Mantener un análisis actualizado de zonas potenciales de captura.
- Crear departamentos de investigación en aplicaciones de potenciales servicios de
procesamiento.
- Cualquier evento antrópico o fenómeno natural que afecte a población civil, debe ser
capturado aun sin la solicitud de un cliente.
- La situación jurídica y legal debe estar actualizada permanentemente.
- La publicidad debe estar enfocada en el ahorro de costos y los beneficios para los
clientes potenciales.

103
- Optimizar los procesos debe ser una actividad permanente para alcanzar eficiencia y
eficacia.
- Todas las decisiones deben examinarse bajo los criterios de interoperabilidad y bajo
acoplamiento con el fin de responder mejor a los cambios del mercado.

5.7. Modelo de Arquitectura de Referencia.

Se hace una aproximación de acuerdo a SOMA con el fin de adoptar una visión más amplia
del ecosistema, de los temas de más alto nivel de una arquitectura y de su estilo orientado
a servicios. Las capas de arquitectura que se presentan difieren del enfoque que presenta
el documento original de la metodología SOMA. Tal documento presenta un enfoque en
componentes tecnológicos implementados a partir de sistemas legados y en
funcionamiento. Los temas que aquí se presentan hacen un enfoque conceptual,
organizándolos dentro de cada capa de la arquitectura.

Las ilustraciones 27 a 31 son de naturaleza organizativa, por esta razón la información

presentada es de carácter visual y no informativo, puesto que la información ya ha sido
registrada en las unidades correspondientes, en esta sección se visualizan en conjunto los
aspectos más relevantes de la arquitectura y como se acoplan horizontal y verticalmente.

Ilustración 27 Capa de Gobierno.

CAPA DE GOBIERNO
Cuál es el núcleo de valores que define el negocio?
La empresa está dedicada a capturar y distribuir fotografías aéreas de un UAV también conocidos como Drones, así como los productos derivados de esta
información básica, todo en internet usando servicios web.

Cómo se negocia con los clientes?

El cliente realiza un pedido y debe recibir una respuesta del tiempo de ejecución (tiempo de entrega estimado a partir de la confirmación de la orden de
pedido) y costo de su pedido en menos de 6 horas.
Se ofrecen servicios gratuitos con el fin de registrar la información del cliente y ofrecerle servicios de análisis de datos.

Cómo se negocia con los socios?

La relación con los socios debe ser de carácter cooperativo y estratégico en función de los beneficios mutuos, se negocia la oportunidad de acceder al
mercado local con la de procesamientos más avanzados y automáticos de datos como los de clasificación (ofrecidos por otros países a través de internet) en
tanto que se apoyan investigaciones para desarrollar los propios en la medida que lo permita el costo.

Cómo asegura la compañía que los interesados son tratados con equidad?
Incluyéndolos en el sistema mediante herramientas tecnológicas que permitan en seguimiento de sus deseos o necesidades para analizarlas con el fin de
satisfacer las actuales y crear nuevas necesidades.

Cómo se estructura la compañía de forma que se sigan los principios y reglas de negocio?
La estructura organizativa de roles asigna la toma de decisiones a los roles administrativos y el jefe técnico exclusivamente (acompañados de una asesoría
oportuna y de calidad), los roles de clientes, desarrolladores y operadores deben tener herramientas que faciliten la consulta de reglas y verificación de sus
actividades que son la aplicación de las políticas y reglas de negocio diseñadas por la administración y la jefatura técnica.
Solo a partir del eventual crecimiento de procesos, aumento de servicios y por consiguiente de necesidades de recursos, la estructura podrá enriquecerse con
un grupo central de expertos dedicados a la SOA, se prevé que este cambio sea gradual para lo cual deben escogerse las herramientas y organización
adecuadas.

Que decisiones deben tomarse para realizar una administración y uso efectivos?
Como es obvio, las decisiones dependen de la información acerca de las posibles opciones de un caso en particular a la luz de las políticas y reglas de negocio,
además la información de las capacidades del área de Tecnologías de la Información debe ser actualizada y fácil de consultar junto con el estado y
disponibilidad de los recursos (monitoreo). Solo en estas condiciones se garantiza que una decisión tomada sea la mejor en función de una ponderación
rastreable y documentada en contraposición con otras posibles decisiones. Las primeras decisiones se toman sobre las opciones de SMBD, capacidades de
almacenamiento y procesamiento y diseño según el dispositivo.

Cómo se comunican estas decisiones?

La red empresarial debe proveer servicios de mensajería electrónica aparte de la mensajería electrónica personal de los empleados y al menos dos cuentas en
redes sociales. También se deben hacer mínimo dos reuniones mensuales para evaluar los indicadores y el grado de alcance de las metas.

104
Ilustración 28. Capa de Arquitectura de Información:
CAPA DE GOBIERNO
Cuál
CAPAesDE
el núcleo de valores que
ARQUITECTURA DEdefine el negocio?
INFORMACIÓN Modelo de datos corporativo
La organización está dedicada a capturar y distribuir fotografías aéreas de un UAV también conocidos como Drones, así como los productos derivados de esta
información básica, todo en internet usando servicios web.
Objetivos Estratégicos:
Cómo se negocia con los clientes?
El cliente realiza un pedido y debe recibir una respuesta del tiempo de ejecución (tiempo de entrega estimado a partir de la confirmación de la orden de
pedido) y costo de su pedido en menos de 6 horas.
Se ofrecen servicios gratuitos con el fin de registrar la información del cliente y ofrecerle servicios de análisis de datos .
•Equilibrar la calidad de los productos y los costos de producción, procesamiento y envío.
Cómo se negocia con los socios?
•Mantener
La relación undebe
con los socios análisis
ser deactualizado de zonas
carácter cooperativo potenciales
y estratégico de captura.
en función de los beneficios mutuos, se negocia la oportunidad de acceder al
mercado local con la de procesamientos más avanzados y automáticos de datos como los de clasificación (ofrecidos por otros países a través de internet) en
tanto que se apoyan investigaciones para desarrollar los propios en la medida
•Crear departamentos de investigación en aplicaciones de servicios que lo permita elde
costo.
procesamiento potenciales.
Cómo asegura la compañía que los interesados son tratados con equidad?
•Cualquier evento antrópico o fenómeno natural que afecte a población
de suscivil, debe ser capturado aun sinconla el
solicitud
Incluyéndolos
delasun cliente.
Modelo de datos SIG
en el sistema mediante herramientas tecnológicas que permitan en seguimiento deseos o necesidades para analizarlas fin de
satisfacer actuales y crear nuevas necesidades.

Cómo se estructura
•La situaciónla compañía
jurídica yde forma
legal queestar
debe se sigan los principios y reglas
permanentemente de negocio?
actualizada.
La estructura organizativa de roles asigna la toma de decisiones a los roles administrativos y el jefe técnico exclusivamente (acompañados de una asesoría
oportuna y de calidad), los roles de clientes, desarrolladores y operadores deben tener herramientas que faciliten la consulta de reglas y verificación de sus
•Laque
actividades publicidad debede
son la aplicación estar enfocada
las políticas ende
y reglas elnegocio
ahorrodiseñadas
de costos y los
por la beneficios
administración y lapara lostécnica.
jefatura clientes potenciales.
Solo a partir del eventual crecimiento de procesos, aumento de servicios y por consiguiente de necesidades de recursos, la estructura podrá enriquecerse con
un grupo central de expertos dedicados a la SOA, se prevé que este cambio sea gradual para lo cual deben escogerse las herramientas y organización
•Optimizar los procesos para alcanzar eficiencia y eficacia.
adecuadas.

•Tener cada
Que decisiones debenvez más flexibilidad
tomarse para realizar en
unalaadministración
respuesta a los cambios
y uso del mercado.
efectivos?
Como es obvio, las decisiones dependen de la información acerca de las posibles opciones de un caso en particular a la luz de las políticas y reglas de negocio,
además la información de las capacidades del área de Tecnologías de la Información debe ser actualizada y fácil de consultar junto con el estado y
disponibilidad de los recursos (monitoreo). Solo en estas condiciones se garantiza que una decisión tomada sea la mejor en función de una ponderación
rastreable y documentada en contraposición con otras posibles decisiones. Las primeras decisiones se toman sobre las opciones de SMBD, capacidades de
almacenamiento y procesamiento y diseño según el dispositivo.

Cómo se comunican estas decisiones?

La red empresarial debe proveer servicios de mensajería electrónica aparte de la mensajería electrónica personal de los empleados y al menos dos cuentas en
redes sociales. También se deben hacer mínimo dos reuniones mensuales para evaluar los indicadores y el grado de alcance de las metas.

La arquitectura de información es el modelo de datos junto con las especificaciones del

DBMS. Los modelos de datos especificados en el modelo de dominio del sistema y en el
modelo de datos geográfico. En cuanto al DBMS, es claro que el ingrediente espacial exige
una base de datos con soporte para procesamientos de datos geoespaciales, por esto se
han observado diferentes motores de datos espaciales pero la restricción inicial es que la
prioridad sea el software libre, lo cual reduce la lista y debido a la amplia aceptación y
esfuerzo de la comunidad de desarrolladores, la mejor opción para un DBMS objeto-
relacional es PostgreSQL, con la extensión espacial PostGIS. Como se ha observado
anteriormente, también se contempla MongoDB como opción de Base de Datos No
Relacional (NoSQL), la cual también tiene posibilidades de indexado espacial para hibridar
la base de datos y promover el bajo acoplamiento que exigen las SOA.
Un aspecto relevante de esta capa son los metadatos, para el caso de imágenes aéreas
ya están estandarizados por diferentes entidades, la referencia principal para el modelo de
metadatos es el ICONTEC por ser quien aconseja los aspectos relacionados con este tipo
de información para que sea usada y compatible en diferentes áreas mediante la norma
técnica colombiana NTC 4611 para el metadato mínimo.

105
Ilustración 29. Capa de Calidad del Servicio. (Requerimientos no funcionales)
CAPA DE GOBIERNO
CAPA DE ARQUITECTURA DE INFORMACION
CAPA DE CALIDAD DEL SERVICIO (REQUERIMIENTOS NO FUNCIONALES)
Requerimientos No Funcionales
El despliegue de la cartografía básica no debe superar los 2 segundos y el de las imágenes no debe superar los 3 segundos. (Teniendo en cuenta que éstas al ser pre-
Rendimiento visualizaciones de las originales deberán tener menor calidad y por lo tanto menor tamaño en bytes.)
El procesamiento de datos no debe superar los 4 segundos.
Se debe reducir al máximo la carga transaccional cuando se haga transferencia de imágenes aun cuando tengan una menor resolución.
Desempeño Se necesitan procesar imágenes en formato raster en extensiones PNG, JPG, GeoTIFF y SVG.
Se deben satisfacer la totalidad de los pedidos de los clientes.
La administración debe hacerse con herramientas tecnológicas que permitan operación a través de internet.
Portabilidad Las ubicaciones de las bases de datos deben estar distribuidas en la nube.
El sistema operativo debe estar basado en Linux con una distribución que permita el uso de un SMBD como Postgres o MySQL
Se aborda desde el punto de vista de las restricciones de acceso para los roles de acuerdo a las responsabilidades que cada rol tiene durante el proceso. Para esto se
diferencian distintos perfiles:
- Cliente: será a quien se le permite la visualización de imágenes capturadas por la organización, las cuales han sido procesadas para reducir la resolución espacial. El cliente
puede visualizar imágenes cargadas por él mismo, puede acceder a los datos de su cuenta de usuario y modificar su área de interés, puede leer los resultados de los
procesamientos o análisis solicitados por medio de la descarga o entrega del producto. Estos procesamientos y análisis solo pueden ser modificados por un operario
responsable del producto o el asesor.
Seguridad - Operario: tiene permiso de modificar y posprocesar y procesar la información producida por las fotografías aéreas digitales pero no la del usuario ni la de si mismo.
- Jefe técnico: tiene permiso de modificar la información de todos los usuarios y operadores pero no la de si mismo
- Administrador: tiente permisos totales
Los usuarios no registrados como clientes no podrán acceder a ninguna información diferente a la que se visualice en el Portal Web.
Para evitar recibir información inválida o que los datos sean alterados por agentes inescrupulosos, deben implementarse herramientas de metadatos y del bus de servicios.
Los clientes también deben tener garantizada la protección de su información personal.
La exactitud de posición de los productos de los productos debe ser como máximo de un metro, es decir, los datos no pueden tener errores de posición por encima de un metro.
En caso de perderse la conexión con el usuario durante la sesión de consulta, debe guardarse la información de la sesión y el historial de cambios hechos por el usuario en la
Fiabilidad solicitud de información o el área de interés para retomar la consulta cuando se reinicie la sesión.
Se deben implementar herramientas que permitan medir la integridad transaccional y las propiedades ACID, con la con el fin de que los servicios tengan la propiedad de la
Idempotencia.
Las herramientas ofrecidas por las interfaces de usuario y las mismas interfaces de usuario deber ser altamente intuitivas para que el sistema se pueda usar por personas con
Usabilidad bajo conocimiento de los mapas en internet y la información espacial.
Las interfaces graficas de usuario en el navegador deben ser manejables por dispositivos táctiles.
La disponibilidad no necesita ser 24/7 (24 horas al día / 7 días a la semana), aunque idealmente el sistema debería estar disponible la mayor parte del tiempo, la disponibilidad
Disponibilidad:
mínima diseñada debe ser de 18/7.
Los dispositivos de hardware así como los de software deben ser escogidos de forma que permitan escalabilidad vertical y horizontal, la primera con el fin de mantener
funcionalidades que se vayan enriqueciendo con el tiempo, y la segunda con el fin de soportar el aumento permanente de usuarios y datos.
Mantenibilidad
Las aplicaciones deben ser desarrolladas con estándares para servicios web geográficos y en lenguajes de programación empleados en el software libre.
Es necesario que el sistema cumpla con los conceptos de SOA como el bajo acoplamiento interoperabilidad.
Las funciones del proceso de negocio y en lo posible del procesamiento de datos, deben ser codificadas en forma de servicios de manera que el sistema permita una
Flexibilidad
independencia de la plataforma y de los proveedores de software.

Ilustración 30. Capa de Integración.

CAPA DE GOBIERNO
Cuál
CAPAesDEel núcleo de valores que
ARQUITECTURA DEdefine el negocio?
INFORMACIÓN
La organización está dedicada a capturar y distribuir fotografías aéreas de un UAV también conocidos como Drones, así como los productos derivados de esta
CAPA DE CALIDAD DEL SERVICIO (REQUERIMIENTOS
información básica, todo en internet usando servicios web. NO FUNCIONALES) Modelo de datos corporativo
CAPA DE INTEGRACION (BUS DE SERVICIOS EMPRESARIALES) Objetivos Estratégicos:
-CómoLas herramientas
se negocia ofrecidas
con los por las interfaces de usuario y las mismas interfaces de usuario deber ser altamente intuitivas para que el sistema se
clientes?
Modelo de datos SIG
pueda
El cliente usarun
realiza por personas
pedido conrecibir
y debe bajo conocimiento dedel
una respuesta lostiempo
mapas de
en ejecución
internet y (tiempo
la información espacial.
de entrega estimado a partir de la confirmación de la orden de
pedido) y costo de su pedido en menos de 6 horas.
- En caso de perderse la conexión con el usuario durante la sesión de consulta, debe guardarse la información de la sesión y el historial de cambios
Se ofrecen servicios gratuitos con el fin de registrar la información del cliente y ofrecerle servicios de análisis de datos .
•Equilibrar
hechos la calidad
por el usuario de losde
en la solicitud productos
informaciónyo los costos
el área de producción,
de interés para retomar laprocesamiento
consulta cuando seyreinicie
envío.la sesión.
Cómo
- Elsedespliegue
negocia con
de lalos socios? básica no debe superar los 2 segundos y el de las imágenes no debe superar los 3 segundos teniendo en cuenta que
cartografía
•Mantener
La relación undebe
análisis
ser deactualizado de zonas potenciales de captura.
estascon lospre-visualizaciones
al ser socios carácter
de cooperativo
las originales y estratégico
deberán en función
tener menor depor
calidad y loslobeneficios mutuos,
tanto menor se negocia
peso en bytes. la oportunidad de acceder al
mercado local con la de procesamientos más avanzados y automáticos de datos como los de clasificación (ofrecidos por otros países a través de internet) en
•Crear
-tanto que
Los se apoyan
dispositivosinvestigaciones
departamentos
de hardware asípara
decomodesarrollar
investigaciónlos propios
los de softwareendebenen la medida
aplicaciones
ser que lo
depermita
de servicios
escogidos forma queelde
costo.
procesamiento
permitan potenciales.
escalabilidad vertical y horizontal, la primera con
el fin de mantener funcionalidades que se vayan enriqueciendo con el tiempo, y la segunda con el fin de soportar el aumento permanente de usuarios
Cómoyasegura
datos. la compañía que los interesados son tratados con equidad?
SOA podría •Cualquier
Incluyéndolos funcionar
en evento
el sistema sin antrópico
ESB pero
mediante o fenómeno
esto
herramientas delegaría natural
tecnológicas más que afecte
quetrabajo
permitan al a población
enproveedor
seguimiento y al
de civil,
sus debe
consumidor
deseos serdecapturado
servicios
o necesidades aun sincon
en cuanto
para analizarlas la el
solicitud
alfin de
Lade
-satisfacer lasun
establecimiento cliente.
disponibilidad
actuales no
lasnecesita
y crear
de nuevasser 24/7,
y aunque
necesidades.
conexiones idealmente elcausando
comunicaciones sistema debería estar disponible
el aumento la mayor
del acople departe del tiempo, perdida
los servicios, la disponibilidad
de mínima
diseñada debe ser de 18/7.
escalabilidad y a la vez de interoperabilidad.
Cómo se estructura la compañía yde forma queestar
se sigan los principios y reglas de negocio?
La•La
-Ventajas: situación
Mapeo
administración jurídica
dedebe
datos, legal
ruteo
hacerse debe
con inteligente permanentemente
(balanceo de permitan
carga), actualizada.
administración deinternet.
servicios, monitoreo e incluso
La estructura organizativa de roles asigna laherramientas tecnológicas
toma de decisiones que
a los roles operación
administrativos y elajefe
través de
técnico exclusivamente (acompañados de una asesoría
seguridad.
oportuna y de calidad), los roles de clientes, desarrolladores y operadores deben tener herramientas que faciliten la consulta de reglas y verificación de sus
- Las ubicaciones de las bases de datos deben estar distribuidas en la nube.
•La
actividades publicidad
que son la debe
aplicación estar
de las enfocada
políticas y en
reglas deel ahorro
negocio de costos
diseñadas por y
la los beneficios
administración
Conexión punto a punto o través de un mediador, las conexiones punto a punto presentan un problema al aumentar la y para
la los
jefatura clientes
técnica. potenciales.
Solo a partir del eventual crecimiento de procesos, aumento de servicios y por consiguiente de necesidades de recursos, la estructura podrá enriquecerse con
-cantidad de acople
La seguridad en las conexiones
o restricciones de acceso a físicas
datos esyun la tema
tolerancia a fallos
controversial puestoes que
bastante baja,
la filosofía del aun cuando
software el ESBes
libre también provea solamente
la liberación de datos,
un grupo central de expertos dedicados a la SOA, se prevé que este cambio sea gradual para lo cual deben escogerse las herramientas y organización
de •Optimizar
conexiones
con punto
esta referencialoselprocesos
aproblema paraelalcanzar
punto también
sería ROI eficiencia
sey puede lograryeconómica
la sostenibilidad eficacia.
bajo acoplamiento pero
de los procesos. incrementando
Estos la complejidad
temas están enmarcados condel
en el aspecto elflujo
usode
adecuadas.
la informacióninterceptores
de middleware es decir; la industria de software
o proxies ha sidoen
adicional la mayor
tanto productora de capital en el
que las conexiones mundo de
a través dehoy,
un por encima del
mediador petróleo pero
o agente hacen no de la
Que •Tener
guerra
una decisiones
ni lacada
infraestructuradeben vez
de más
religión;
tomarse
acopleflexibilidad
Facebook,
para en
unalaadministración
Twiter, o Google
más realizar
holgado. respuesta
son buenos aejemplos.
los cambios
y uso del mercado.
Entendiendo
efectivos? la sostenibilidad financiera como la capacidad de conseguir
Como recursos
es obvio,alasser procesados y servidos, en general las aplicaciones en internet se mantienen en función de la cantidad de usuarios que las emplean,
decisiones dependen de la información acerca de las posibles opciones de un caso en particular a la luz de las políticas y reglas de negocio,
ademásósea al crear una
la información denecesidad importante
las capacidades como
del área lo es la información
de Tecnologías geográfica
de la Información debedeser mayor resolución
actualizada y fácily de
el consultar
acceso a junto
ésta,con
se el
puede garantizar
estado y la
En cuanto a la responsabilidad
sostenibilidad.
disponibilidad de los recursos delson
El detalle(monitoreo).
importante ESBlos
Solo endesde el punto
porcentajes
estas de vista
de beneficio
condiciones deque
losuna
económico;
se garantiza consumidores
inicialmente ysea
proveedores,
se plantea
decisión tomada que este
la mejor hay
sea dos
bajo
en función depara atraer usuarios,
una ponderación
aproximaciones;
aunque
rastreable un bajodirigido
y documentadabeneficio por
puedeeldegradar
protocolo
en contraposición o posibles
conlaotras dirigido
calidad por APIs,
y confiabilidad
decisiones. de laprimeras
Laslos conclusión
datos, este es que
aspecto
decisiones las mayores
sequedaría
toman cubierto
sobre ventajas
con de son
las poderosas
las opciones SMBD,ofrecidas por
herramientas
capacidades dede
metadatos
dirigidoque
almacenamiento
el ESB informaran
y por APIs enquien
procesamiento capturo
y diseño
cuanto el dato
según y a quien pertenece
el dispositivo.
a implementación cada cambio,en
y escalabilidad, loseste
datoscaso
serianelentonces
problema protegidos solamente
de mapear de la eliminación
llamadas de y
el acceso a datos de procesos ordenados por un usuario. Seguridad es un factor que afecta el escenario real de implementación y en caso de ser una
Un aspecto
servicios relevante de esta capa
e implementaciones son los ametadatos
de servicios mensajes que bienpara el casoque
formados de imágenes aéreas puedan
los participantes ya estánenviar
estandarizados por
sobre el ESB,
Cómonecesidad ineludible,
se comunican estastambién se puede efectuar a través de servicios de seguridad.
decisiones?
diferentes
es tarea delentidades,
grupo quelaprovee
referencia principal
el ESB . El ESBpara
se haeldesarrollado
modelo de metadatos
igual que las es el
SOAICONTEC
con lospor ser quien
sistemas aconseja los
distribuidos
La red empresarial debe proveer servicios de mensajería electrónica aparte de la mensajería electrónica personal de los empleados y al menos dos cuentas en
aspectos
redes relacionados
sociales. con hacer
También se deben este mínimo
tipo dedos
información para que
reuniones mensuales parasea usada
evaluar y compatible
los indicadores en diferentes
y el grado de alcance deáreas mediante la
las metas.
norma técnica colombiana NTC 4611 para el metadato mínimo.

106
Ilustración 31. Capas de Procesos de Negocio, Servicios, Componentes y S. Operativos

Una de las razones principales para la representación de la pila de soluciones SOA, es

ayudar a comunicar a las partes interesadas de negocio y a las TI, la evolución y la
realización de la empresa, la visión de SOA y la hoja de ruta mediante la aplicación
iterativa. La comunicación con los grupos de interés es clave para asegurar que el
compromiso de las empresas es un fenómeno generalizado en las distintas fases de una
iniciativa SOA. La metodología que se discute en este capítulo ayudará en la identificación,
especificación, la realización de las construcciones de primera clase de una SOA y su
colocación en las distintas capas de la pila de la arquitectura. Esta vista lógica de la
arquitectura de referencia SOA también se conoce como la pila de solución de SOA o
simplemente la pila de solución. Por lo tanto los términos, SOA arquitectura de referencia
y pila de soluciones SOA, se refieren al mismo concepto y por lo tanto pueden ser utilizados
indistintamente (IBM, 2008).
Las capas superiores de la arquitectura en su ejemplo tienen un visible sesgo hacia los
componentes comercializados por IBM, por esto en la especificación se expresan los
conceptos empleados para el presente trabajo.

107
Capítulo 6 Implementación del Prototipo.
Esta etapa también es comprendida por el RUP durante la fase de construcción y
codificación, en esta etapa se definen los detalles finales que dan forma al prototipo del
sistema y la estructura física y tecnológica que se emplea para la ejecución del código
generado por los modelos de negocio y la vista final.
De acuerdo a lo descrito en el alcance, por razones de capacidad técnica para un prototipo,
cronológicas debido al tiempo necesario para la codificación de todas las funciones y
servicios diseñados, y económicas entre otras; las funcionalidades diseñadas a partir de
una SOA exceden las capacidades de implementación del sistema completo,
funcionalidades como el motor de reglas de negocio, sistemas de comunicación, o
repositorio de servicios no pueden ser implementadas debido a diferentes restricciones
técnicas, de tiempo o presupuesto dada su complejidad, incluso la disponibilidad de
personal idóneo para llegar al prototipo ha sido una restricción importante. Este es el caso
de componentes de sistemas legados o para administración de comunicaciones, como el
ESB, los MEP o el repositorio de servicios donde son expuestos los servicios web de forma
que sean consumidos por otros usuarios u otros servicios.

6.1. Implementación de los Servicios.

Los servicios de Consulta de Información Geográfica, Planeación de Vuelo y Cargue de
Imágenes, no son implementados estrictamente como Servicios Web, es decir con contrato
e interface en WSDL y publicación en repositorio de servicios, sin embargo el prototipo
permite que sean utilizados por el usuario a través de formularios de ejemplo o
digitalizando el área de interés en el visor del navegador.
La implementación fue desplegada en una intranet de una sola máquina que es a la vez
cliente y servidor, es decir todas las aplicaciones que necesitan hacer peticiones a un
servidor lo hacen a localhost, este detalle meramente técnico no presenta ninguna
diferencia en funcionalidad. La API de Google Maps si necesita conexión a internet y el
cliente de mapas no puede hacer consultas sin conexión.
Los servicios implementados consumen servicios web de mapas base desde una dirección
local e imágenes de satélite desde internet, son ofrecidos de forma didáctica y menos
sofisticada que un Servicio Web pero implementando un WMS para la visualización de la
división política de Colombia y un WMS-T para la creación de polígonos y líneas.

108
6.1.1. Servicio de Consulta de Información Geográfica
La implementación del servicio de Consulta de Información Geográfica se hace a través
del browser, no como un Servicio Web en WSDL sino mediante un visor geográfico en el
navegador que es un componente que se describe técnicamente en la sección 6.4.3. Visor.
El visor despliega una imagen satelital global usando la API de Google Maps centrada en
Bogotá y con un acercamiento a Colombia, superponiendo las capas de división política a
nivel municipios y de departamentos identificados con colores en su respectiva leyenda.

6.1.1.1. Operación Ingresar Área de Interés.

Esta operación es efectuada por el usuario con herramientas geográficas que permiten
usar el visor como muestra el video anexo en el CD y la ilustración 32:

Ilustración 32 Paneles y herramientas del visor Heron MC.

El usuario selecciona la herramienta Dibujar Polígono y a continuación realiza un

acercamiento en el mapa a la zona que cubra su área de interés en el visor, al identificar
el área sobre la imagen de satélite, el usuario dibuja sobre el mapa el polígono que
satisfaga su necesidad haciendo un clic por cada vértice y doble clic para finalizar el

109
polígono. Inmediatamente se hace doble clic el código ejecuta la operación 6.1.1.3.
Identificación de Imágenes.

6.1.1.2. Operación Análisis de Cobertura.

Esta operación planteada en el diseño de los servicios en la sección 5.4.4. No es

implementada debido a que presenta un nivel superior en el desarrollo que no permite ser
realizado en términos del alcance del prototipo. Esta operación es de tipo estratégico en el
proceso de negocio y tiene el fin de informar al usuario que su área seleccionada puede
ser cubierta totalmente si solicita el servicio mediante la planeación y orden de vuelo. Como
se explicó en el diseño, la función permitiría hallar la diferencia entre el área que el usuario
ha creado y el área total cubierta por los productos ofrecidos por la organización.

6.1.1.3. Operación Identificación de Imágenes

La Operación Identificación de Imágenes inicia con una consulta espacial, realizada

automáticamente cuando el usuario hace doble clic para cerrar el polígono en la operación
6.1.1.1. Ingresar Área de Interés.

Ilustración 33 Resultado de la búsqueda.

110
La ilustración 33 es un ejemplo de consulta que arroja 5 registros en un área de extensión
aleatoria pero que afecta la información dispuesta para el prototipo al sur del departamento
de Bolívar, se visualizan los registros y los marcos afectados por el área de interés, que
son desplegados sobre el mapa en color naranja. Esta operación se efectúa a partir de una
función que es modificada para Heron MC en Javascript y es identificada dentro del código
con el nombre hr_searchbydrawpanel.

Ilustración 34 Visualización de Imagen.

Al momento de desplegar los registros en el panel izquierdo, se presentan en la parte

superior del mismo panel los botones “Ver Foto” y “Calcular Vuelo”, el usuario tiene la
posibilidad de resaltar alguno de los marcos haciendo clic en el registro deseado, al hacer
doble clic en el registro se hace un acercamiento automático al marco y se activa el botón
“Ver Foto”, haciendo clic en este botón se abre una ventana que muestra la imagen
seleccionada, ilustración 34.

6.1.2. Servicio Cargue de Imágenes.

Este servicio no ha sido implementado como Servicio Web, sin embargo las imágenes que
lee el visor están relacionadas en las bases de datos espaciales, es decir fueron cargadas

111
a carpetas del sistema de forma manual. La implementación en la secuencia sobre el
navegador en la intranet se hace de forma didáctica, debido a que aunque es un
requerimiento funcional, representa un detalle técnico. Este servicio se diseña con un
formulario de ejemplo en el prototipo, ya que su ejecución detallada dentro del proceso no
tiene un aporte significativo para los objetivos del proyecto ni para el alcance del prototipo,
además del conocimiento técnico. El servicio abre una ventana para seleccionar unas
imágenes como lo muestra la ilustración 35, imágenes que serían guardadas en una
carpeta del sistema para que el usuario pueda solicitar diferentes tratamientos sobre éstas.

6.1.2.1. Operación Cargue de Imágenes

Ilustración 35 Cargue de Imágenes

Esta operación ejemplo en el prototipo es una tarea realizada por el usuario mediante un
formulario sencillo, donde un botón abre una ventana de navegación por carpetas locales
que le permite al usuario hallar los archivos de imagen que habrían de ser cargados para
tratamientos digitales o espaciales, éstos tratamientos son seleccionados mediante
botones tipo Check button para que, con posteriores desarrollos el sistema pueda asignar
cada tarea a un operador técnico adecuado, que tenga rol y perfiles de usuario necesarios.

112
En la ilustración 35 se observa la tarea diseñada para la operación que realiza el usuario
y la ventana para hallar carpetas locales, que aparece luego de hacer clic en el botón junto
al campo de entrada titulado Cargar Archivos de Imagen, también se observa un campo
para reportar la cantidad de imágenes cargadas y la lista de procesos aplicables.

6.1.3. Servicio de Planeación de Vuelo

El servicio de Planeación de vuelo no ha sido implementado como un servicio web, este
servicio se ofrece en el diseño pero queda como ejemplo en el prototipo con el fin de
realizar una secuencia más completa, para el modelo de negocio y para el motor de
procesos de negocio.

6.1.3.1. Operación Calcular Líneas de Vuelo

La operación Calcular líneas de Vuelo ha sido desarrollada de forma parcial y simplificada,

generando las líneas de vuelo pero no los centros de las fotos, con el fin de mostrar cómo
podría ser una planeación de vuelo preliminar automática, que permita con posteriores
desarrollos hacer un cálculo muy aproximado del costo que genera un vuelo para el área
que el usuario creó en la base de datos. Esta operación realizada a partir del área de
interés se hace basándose en datos de altura de vuelo máxima permitida de un dron que
son 150m y un porcentaje de traslape entre fajas del 80%.

Ilustración 36 Generación de líneas de vuelo

113
La operación genera un archivo de tipo línea que no es entregado ni necesita ser utilizado
por el usuario, la creación de este archivo y su código asociado pueden ser utilizados en
posteriores desarrollos para la creación del archivo de puntos que sea una aproximación
a los foto centros de captura de vuelos planeados. En la ilustración 36 podemos observar
cómo al hacer clic sobre el botón “Calcular Líneas” se obtienen las líneas de vuelo y
automáticamente se puede visualizar la capa en el panel de capas.

6.2. Lenguajes.
Debido a que las aplicaciones geográficas presentan un alto grado de complejidad,
principalmente desde el punto de vista de las composiciones de servicios, el lenguaje más
apropiado para la codificación del componente relacionado con la Lógica de Negocio es
Java, puesto que al ser interpretado, la necesidad de depender de una máquina virtual
para su ejecución permite bajo acoplamiento aunque el consumo de recursos
computacionales sea elevado.
La posible degeneración de tiempos de respuesta a solicitudes complejas puede ser
manejada junto con las capacidades del servidor y un método de balanceo de carga
apropiado, esto último en un ambiente distribuido de producción y no en el prototipo.
La principal razón de escoger Java es la escalabilidad puesto que el elevado número de
usuarios de este lenguaje ha permitido amplia atención en la solución de problemas
redundando en interoperabilidad, además para el prototipo la plataforma que se emplea
para la ejecución de procesos de negocio es Bonita que usa un motor de flujo de trabajo
en código abierto conocido como jBPM.
La asesoría de un desarrollador y el concepto de curva de aprendizaje para este caso,
hacen que C++ sea una elección poco conveniente debido a que exige un mayor esfuerzo
en la implementación de la solución, además se debe tener en cuenta que requiere de gran
experiencia y conocimiento en las librerías concurrentes (API) para el acceso y envío de
datos por medio de protocolos; además las soluciones en este lenguaje de programación
implican una inversión en la definición de patrones de diseño válidos para desarrollar.
Por otro lado, a pesar de la facilidad de desarrollo de aplicaciones y mejoras en el
paradigma de Programación Orientada a Objetos, pilar fundamental para la definición de
soluciones orientadas a servicios, PHP tampoco ofrecería una alternativa elegible debido
a su bajo nivel de soporte en el paradigma de orientación a objetos. Sin embargo otras
ventajas como la portabilidad, gratuidad, alto rendimiento, la integración con diferentes
SMBD, los extensos desarrollos de librerías, factores cronológicos e incluso económicos,

114
pueden hacer que PHP sea una buena opción para la visualización en el browser y las
conexiones con la base de datos, sí la organización no es demasiado grande.

Para la implementación de la base de datos se emplea SQL que es el lenguaje estándar

para bases de datos relacionales, como se ve en la sección 6.3. Base de Datos, solo se
implementa la base de datos relacional, la base de datos NoSQL pertenece al diseño para
ambientes distribuidos.

El lenguaje utilizado para desarrollos en procesamiento de datos es JavaScript, dado que

se ha adoptado un cliente de mapas para el navegador basado en este lenguaje de amplio
uso para desarrollos web. Las librerías de OpenLayers también son escritas en JavaScript.

Las aplicaciones web en el lenguaje HTML son generadas por la suite de Bonita BPM y se
ejecutan en el navegador, sus archivos de estilos correspondientes CSS son también
creados a partir de los formularios diseñados en la aplicación de diseño UI Designer.

El lenguaje BPEL permite la ejecución del proceso de negocio y está basado en XML, las
ordenes son ingresadas mediante la lectura que el motor hace del proceso diseñado en la
notación BPMN.

6.3. Bases de Datos.

La base de datos implementada para el prototipo es la base de datos geográfica con las
propiedades y funciones que ofrece PostGIS, pero no la base de datos corporativa, puesto
que la implementación de la base de datos corporativa no presenta mayor relevancia para
los objetivos ni respecto al tema con el que se aborda la Geomática, pero si para los
procesos de negocio que eventualmente se relacionen espacialmente.

Los datos utilizados corresponden a fotografías donadas por el mismo usuario que hace la
evaluación en la sección 7.2.1. Evaluación con Actor, son imágenes capturadas por un
dron MD4000 de la industria alemana Microdrones, de cuatro motores equipado con una
IMU para la captura de las coordenadas del centro de la imagen a una altura promedio de
100 metros sobre el terreno, utilizando una cámara Sony Next 7 para fotogrametría vertical
con distancia focal de 16mm que proporciona un GSD de 10 cm.
Las imágenes presentan una condición para su uso que consiste en un acuerdo verbal de
confidencialidad acerca de la posición, las imágenes no presentan una georreferenciación
real sino que el archivo vectorial de marcos de las imágenes fueron creados
independientemente en QGIS con sistema de referencia MAGNA-SIRGAS, para poder

115
realizar un ejemplo con el prototipo. En cualquier caso éste detalle técnico no presenta un
factor relevante que impida la ejecución de los requerimientos funcionales del prototipo.
Los archivos que almacenan la información vectorial para departamentos y municipios
fueron obtenidos a través de una descarga gratuita de la página de SHAPE SERIES
GOOGLE SITES en https://sites.google.com/site/seriescol/shapes.
El archivo vectorial del área de interés se encuentra codificado como una entidad espacial
en PosgreSQL con las demás entidades mencionadas, según el diseño que se realizó en
la sección 5.3. Modelo de datos geográfico.

La base de datos es suministrada en los anexos en un archivo de texto con formato

generado por pgAdmin que es una interfaz gráfica para la administración de PostgreSQL,
este archivo carga todos los datos, campos y cardinalidad de las capas de ÁreaInterés,
CentroImagen, Marco, LineaVuelo y Vuelo que son empleados para traslaparse con la
información vectorial de Departamentos, Municipios y la imagen de satélite de Google
Maps para hacer la consulta gráfica. La capa de Área de Interés se carga con 0 registros
puesto que es la que se edita por parte del usuario. También en este archivo está registrada
la información correspondiente a las relaciones de cardinalidad de las entidades diseñadas
en la sección 5.3 Modelo de Datos.

Aunque la base de datos no relacional no es implementada en el prototipo, para la parte

de diseño se hace mención a MongoDB como la mejor elección principalmente en virtud
de su popularidad con datos geográficos en lenguajes NoSQL.

El prototipo no es un ambiente completamente habilitado de producción. En un ambiente

de producción, al momento de instalar Bonita Studio 7.2.3 se hace la configuración de la
conexión con la base de datos PostgreSQL donde quedarían tanto las bases de datos
geográfica como la corporativa que administrarían los datos espaciales, los usuarios y
otras entidades de negocio. Para el caso de este prototipo aparte de la base de datos
geográfica, se usa la base de datos h2 que es una base de datos instalada por defecto en
Bonita BPM para manejar usuarios, roles, instancias y monitoreo del proceso de negocio.

En un ambiente de producción se configuraría la base de datos creada en PostgreSQL en

lugar de la h2, como la base de datos de Bonita BPM, se actualizarían desde HeronMC y
desde Bonita BPM simultáneamente las bases de datos espacial y corporativa, de donde
se obtienen los datos para mostrar la información de monitoreo al usuario a través del
navegador.

116
Como se ha comentado anteriormente la base de datos del sistema se diseña hibrida; es
decir, según el tipo de lenguaje de consulta se reconocen dos tipos de bases de datos; las
relacionales basadas en el leguaje estructurado de consultas SQL y las bases de datos
NoSQL.

Ya se ha observado que las bases de datos NoSQL satisfacen las condiciones para la
implementación de una SOA principalmente en el campo del acoplamiento y a la vez de
interoperabilidad, además éstas bases de datos evitan las operaciones de unión (join) y
escalan horizontalmente (Schutzberg, 2011), los análisis de la base de datos también
fueron hechos adicionalmente en las secciones de requerimientos no funcionales y
metodología, donde se establece que las opciones de motor de bases de datos
relacionales son diversas, pero teniendo en cuenta la restricción inicial de usar software
libre la decisión es adoptar PostgreSQL para administrar el modelo de datos del sistema,
además la extensión PostGIS permite implementar la integración desde abajo, es decir
desde el nivel de datos. MySQL también cumple con las características ACID de
transaccionalidad (Mayer, 2014) y tiene capacidades de manejo de datos espaciales, sin
embargo la madurez de PostGIS, el hecho de poder conectarse con QuantumGIS y ser
código abierto son otros criterios de decisión para trabajar con PostgreSQL.
Aunque la base de datos no relacional no es implementada en el prototipo, para los datos
NoSQL MongoDB se perfila como una buena elección principalmente en virtud de su
popularidad con datos geográficos.

6.4. Componentes.
De acuerdo al marco teórico en la sección de arquitectura de referencia, los componentes
son
“los contratos definidos por los servicios en la capa de servicios. Un componente de
servicio puede comprender uno o más servicios y proporciona una fachada de
implementación que agrega la funcionalidad de los sistemas operativos múltiples y
posiblemente dispares...” (IBM, 2008).
Por lo anterior, un componente para el nivel del prototipo hace referencia a las
composiciones de servicios que permiten al usuario dibujar su área de interés en el
navegador, consultar visualizar y editar la información vectorial permitida y obtener
información solicitada de precios y especificaciones de productos. Estos aspectos hacen

117
referencia a servicios de mapas y servicios transaccionales WMS, WFS y WFS-T que son
configurados en el componente de servicios geográficos Geoserver.
La función para registrar reclamos no es implementada como un servicio web sino como
un formulario, desde este punto de vista las actividades de cálculos de valores o procesos
de ejecución de los diferentes servicios mencionados en el proceso de producción y el
proceso de entrega también son efectuados con tipos simples de formularios.

6.4.1. Sistema Operativo.

Se incluye dentro de los componentes el S.O. con el fin de describir la capa de sistemas
operativos de SOA, esta capa es la plataforma sobre la cual se configuraron componentes
descritos en esta sección; servidores, el SMBD, la suite Bonita BPM, navegador y visor.

Los archivos proporcionados en los anexos pueden ejecutar el proceso de negocio, las
bases de datos y el visor en el sistema operativo Windows, siempre y cuando la
configuración de las carpetas de los servidores y las claves, así como el direccionamiento
de puertos y de bases de datos sean los que proporciona el usuario durante la instalación,
sin embargo dentro de los requerimientos se contempla que todo sea en software libre,
entonces el prototipo opera sobre el SO Linux en su distribución Ubuntu 16.04.

6.4.2. Servidores
Como servidor web se instala Apache2 que es un servidor de páginas web HTTPD para
atender las peticiones que hace el navegador con las aplicaciones de mapas, el cliente de
mapas que hace estas peticiones se llama HeronMC versión 1.0.5 que se detallará en la
sección del visor.

Se emplea el contenedor de servlets de distribución gratuita Tomcat como servidor HTTP

de aplicaciones, en la carpeta de aplicaciones web de la instalación de Tomcat en el
sistema operativo se alojan los archivos .WAR que son las aplicaciones Java con sus
archivos y librerías necesarias para la ejecución en el navegador.

La aplicación Geoserver 2.4.0 es la que se usa para configurar los servicios OGC de
mapas y transacciones vectoriales (WMS y WFS-T), son implementados y desplegados
para ser consumidos por el visor HeronMC 1.0.5 detallado en la sección del visor.

La suite de Bonita BPM hace una instalación propia de Tomcat en un puerto alterno para
la ejecución de las aplicaciones conectadas al motor de procesos de negocio, el puerto por
defecto de Tomcat es 8080 que es donde funciona Geoserver con la instalación manual

118
de Tomcat pero el diseñador de interfaz de usuario UI Designer, la base de datos y el Portal
de usuarios funcionan por el puerto 50931. El servidor de bases de datos es controlado
por PostgreSQL y opera en el puerto 5432, todos estos puertos en localhost.

6.4.3. Visor

El visor de información geográfica se implementa a través de Heron MC 1.0.5 que es un

cliente de mapas código abierto escrito en JavaScript para la creación de aplicaciones web
de mapas en el navegador. Las descripciones de las herramientas que se usan de Heron
MC, y las modificaciones para que opere con el prototipo están con los detalles de
implementación en la sección 6.1.1. Servicio de Consulta de información Geográfica.
El framework Heron MC construye aplicaciones a partir de envolver librerías estándar
Javascript de mapas como OpenLayers y ExtJS, sobre las que se crean aplicaciones de
herramientas de mapas GeoExt. La característica única de Heron es que una aplicación
completa se crea con sólo una configuración (JSON). Heron tiene un back-end mínimo,
basándose principalmente en estándares OGC como WMS, WFS y similares” (Broecke,
2013).

El código de Heron MC 1.0.5 es descargado como librerías y carpetas locales de

configuración, incluidas las hojas de estilos CSS y archivos .js, todos los archivos se ubican
en la carpeta de publicación local del servidor Aapache2. Heron MC exige la configuración
de la carpeta CGI-bin para la ejecución de las aplicaciones en el navegador de internet.

Basado en las librerías de GeoExt y OpenLayers, Heron MC es configurado para

conectarse a las bases de datos relacionales en PostGIS a través de Geoserver
recuperando las capas de información y procesando los datos para desplegarlos sobre una
cobertura satelital gracias a la utilización de la API de Google Maps. Las adiciones de áreas
de interés como objetos espaciales son escritas desde HeronMC en el navegador
directamente a la base de datos espacial.
Son editados los archivos DefaultOptions.JS y Heron.JS para agregar las conexiones a
Geoserver, la conexión con la API de Google Maps y las funciones que permiten cubrir los
requerimientos funcionales como la consulta espacial y el diseño de líneas de vuelo. Las
líneas de vuelo generadas pueden usarse para una planeación del vuelo que es un proceso
más complejo y asistido por programas nativos de operación del UAV.

119
Existen tres paneles en el visor, la disposición original de los paneles de leyenda y
búsqueda ha sido modificada; el panel de búsqueda original es flotante, pero en la
visualización final el panel de búsqueda está embebido junto con el panel de leyenda y el
panel de resultados, en el panel central se observa el visor geográfico que muestra los
mapas y las capas, a la derecha se encuentra el panel de capas disponibles en forma de
leyenda con botones para prenderlas y apagarlas, como se observa en la ilustración 32.

6.4.4. Motor de Procesos de Negocio y Aplicación.

En cuanto al proceso de negocio, se emplea la suite código abierto Bonita BPM 7.2.3
Community, que es la versión gratuita y permite el diseño de los diagramas en BPMN
desarrollados en el componente Bonita Studio 7.2.3,
Ilustración 37 Interfaz de Bonita Studio.

Este componente proporciona herramientas para la ejecución del proceso de negocio

mediante el modulo motor de procesos Bonita BPM Engine, la ejecución del proceso es
una secuencia de formularios en el navegador de internet al presionar el botón ejecutar,
en la barra de herramientas de la ilustración 37.
La suite permite administración de roles y usuarios en la base de datos mediante el modulo
Portal, al cual también se accede desde la barra de herramientas de Bonita Studio.

120
Ilustración 38 Administrador en el Portal de Bonita BPM.

En el módulo Portal ingresa el usuario con contraseña para verificar las tareas pendientes,
si no hay ninguna el modulo Portal inicia como en la ilustración 60.
En la ilustración 38 se observa el modulo Portal pero accedido por un administrador para
quien las opciones y herramientas son diferentes a las de un usuario normal.

Existe un componente para el diseño de páginas web e interfaz de usuario llamado UI

Designer (ilustración 39), dispuesto para acceder a cuatro módulos, Paginas,
Formularios, Layouts y Widgets Personalizados.

Ilustración 39 Diseñador de Interfaz de Usuario.

Los módulos del UI Designer son presentados como pestañas en una página web y se
accede a ellos también desde el navegador, el primero llamado Páginas presenta tres
ejercicios en la ilustración 39 y se usa para el diseño de la página web (ilustración 40).

El segundo módulo en la ilustración 39 con 14 ítems, es para el diseño de formularios

llamado Formularios (ilustración 41), se crean de forma parecida a como lo hace Visual
Basic arrastrando los widgets predeterminados al panel central.

121
Ilustración 40 Interfaz para diseño de páginas web.

El módulo Formularios fue empleado para diseñar todos los formularios de instanciación
de actividades, éstos son ejemplos simplificados de la información que maneja cada
actividad de la secuencia del usuario con el sistema, aquí se puede observar cuáles
actividades procesos o tareas tienen mayor potencial de automatización. El módulo
Layouts no ha sido empleado en el prototipo.

Ilustración 41 Interfaz del Editor de Formularios.

122
Ilustración 42 Editor de Widgets Personalizados.

El modulo llamado Widgets Personalizados (ilustración 42) es una implementación

basada en el framework de Javascript AngularJS, que extiende atributos de HTML con
directivas y conecta a HTML con expresiones. Este módulo fue empleado para embeber la
aplicación Heron MC, creando un widget personalizado dentro del despliegue del proceso
de negocio que hace Bonita BPM en el navegador.

6.4.4.1. Secuencia del Prototipo.

A continuación se presentan imágenes de la secuencia seguida por el usuario para usar

los servicios implementados descritos en la sección 6.1. Implementación de los Servicios.

La página web es lanzada desde el modulo Portal, ingresando como usuario administrador
en la pestaña de aplicaciones (ilustración 38), la página web desarrollada en el módulo
Páginas llamada Servicios (Ilustración 43) es usada por la aplicación llamada Geo Ser
que es un ejemplo de una Living Application, o sea una aplicación que puede ser
modificada en tiempo real, el usuario accede a la página de servicios con usuario y
contraseña para seleccionar los que necesita haciendo clic en el botón Consultar Servicios.

Ilustración 43 Portal Corporativo.

123
La página de consulta de servicios muestra tres opciones tipo check box para que el
usuario seleccione cualquier combinación de estos, un proceso inicia y es instanciado
haciendo clic en el botón Iniciar Proceso (ilustración 44), la página permite acceder al portal
de toma de actividades y se pueden instanciar múltiples procesos de negocio.

Ilustración 44 Acceso a servicios.

Luego del clic en el botón Iniciar Proceso, el motor despliega la página donde el usuario
puede ver las tareas asignadas y el tiempo que tiene para realizarlas, en la ilustración 45
se observan tareas de Cargue y Consulta, aunque la de Diseño también fue seleccionada
el motor no la asigna hasta que el usuario la confirma en el formulario de Consulta.

Ilustración 45 Asignación de Actividades.

124
Al hacer clic en el botón TAKE es iniciada la actividad de Cargue, la cual aparece iluminada
en azul reportando el identificador de la tarea, el nombre de la tarea, un identificador de
caso, nombre del proceso, fecha de actualización y fecha de expiración, también puede
elegirse primero la de Consulta. La tarea Cargue es la siguiente en la secuencia,
corresponde a la operación que es descrita en la sección 6.1.2.

Ilustración 46. Actualización de Actividades.

Después que el usuario selecciona las imágenes, debe hacer un check en las casillas que
indican los diferentes tratamientos (ilustración 35) y finalmente en el botón Enviar Datos, a
continuación el motor regresa a la página del Portal actualizándola con la actividad
pendiente (ilustración 46).

Al tomar la tarea de Consulta con clic en TAKE, se despliega el formulario de consulta que
es la aplicación del visor Heron MC embebida en el formulario de Bonita BPM.

Ilustración 47 Formulario de Consulta Espacial.

125
La descripción del servicio realizada en la sección 6.1.1. Servicio de Consulta, es la que
se lleva a cabo en esta parte de la secuencia hasta que el usuario genere las líneas de
vuelo. Debemos activar la opción Diseño para continuar y clic en Enviar (imagen 47).

Ilustración 48 Asignación de la Actividad de Diseño.

Al hacer clic en Enviar el motor activa la siguiente tarea (ilustración 48), que es el proceso
asistido de diseñar un vuelo para un dron, tarea resumida a un formulario de un botón.

El usuario toma la actividad de diseño que es resumida con un clic en el botón Ejecutar
Diseño para continuar la ejecución del proceso (ilustración 49).

126
Ilustración 49 Resumen Actividad de Diseño

El proceso de cálculo (ilustración 50) es un proceso automático pero se necesita la

verificación de un operario y la autorización del cliente para poner en marcha los procesos
solicitados, por esto se asigna como una actividad dentro del proceso. Se hace clic en
TAKE para tomar la tarea que permite la autorización.

Ilustración 50 Asignación tarea de aprobación - calculo automático.

Los valores que aparecen en el reporte de cálculo (ilustración 51) son mostrados como un
ejemplo de cómo debería ser generado el reporte, sin embargo estos valores no
corresponden a cálculos reales puesto que existen factores principalmente climatológicos,
dificultad de acceso o topografía, que hacen los costos de un vuelo muy variables.

El usuario aprueba la ejecución activando la opción correspondiente mostrada en la

ilustración 51 y hace clic en Continuar para pasar al formulario de Pago, que es la siguiente
actividad y se toma haciendo clic en el botón TAKE (ilustración 52).

Ilustración 51 Ejemplo Reporte de Cotización.

127
Ilustración 52 Asignación Actividad de Pago.

La ilustración 53 presenta el formulario que permite escoger el tipo de pago para que la
actividad sea trabajo futuro en desarrollo de versiones más avanzadas del prototipo. Este
formulario es solo un ejemplo para la continuación del proceso.

Ilustración 53 Ejemplo de Formulario para escoger tipo de pago.

128
Luego de hacer clic en Continuar, el motor presenta la pantalla de asignación de la tarea
de Producción (ilustración 54) donde el usuario la selecciona con el botón TAKE.

Ilustración 54 Asignación de la actividad de producción.

Los procesos diseñados para ser prestados por una organización que maneja información
espacial e imágenes digitales, son en mayoría realizados por operarios humanos asistidos
por potentes herramientas de procesamiento de imágenes o geoprocesamientos de
información vectorial, por esto son simplificados para el desarrollo del prototipo como lo
muestra la figura 55, donde solo se requiere hacer clic en el botón Ejecutar Proceso.

Ilustración 55 Ejemplo de formulario para iniciar procesos de producción.

A continuación el motor asigna la tarea de Entrega que es tomada desde el Portal

mediante clic en el botón TAKE, ilustración 56.

129
Ilustración 56 Asignación Actividad de Entrega.

El formulario de entrega (ilustración 57) ofrece la posibilidad de hacer diferentes tipos de

entregas, en este ejemplo son dos tipos, esto no presenta cambios en el flujo, pero la
casilla de verificación activada en la opción Presentar Reclamo sí cambia el flujo.

Ilustración 57 Compuerta para Bucle de Reclamos.

La compuerta del modelo propuesto dirige el flujo hacia la asignación de la actividad

Reclamo (ilustración 58) y luego vuelve a la tarea de producción, repitiendo el bucle hasta
que el usuario deje sin verificar la casilla de Presentar Reclamo.
En la ilustración 59 se encuentra el ejemplo del formulario donde el usuario expresa su
problema en un campo de texto, el botón Enviar Reclamo es para continuar la secuencia
hacia la tarea de Producción.

130
Ilustración 58 Asignación Actividad de Reclamos.

Ilustración 59 Ejemplo Formulario de Descripción del Problema.

La siguiente actividad es de nuevo Producción, observada en las ilustraciones 54 y 55. Así

mismo las siguientes actividades son exactamente las mismas desde la ilustración 54
hasta la 57, cuando se evita activar Presentar Reclamo y el proceso termina. Finalmente
el motor muestra la página del Portal sin tareas pendientes ilustración 60.

Ilustración 60 Fin del Proceso.

131
 Capítulo 7 Evaluación del Prototipo.
Dentro de la metodología R.U.P. es necesario llevar a cabo la etapa de pruebas. En este
capítulo se presentan los resultados de la evaluación de los requerimientos funcionales y
no funcionales, así como de los casos de uso que fueron utilizados para la implementación
del prototipo. También se presentan formularios y encuestas que se diseñaron y
diligenciaron con el actor seleccionado para los casos y los motivos de selección del actor.
“R.U.P. propone un enfoque iterativo, lo que significa que se hacen pruebas a lo largo
del proyecto. Esto permite encontrar defectos tan pronto como sea posible, lo que
reduce radicalmente el costo de reparar el defecto. Las pruebas se llevaron a cabo
a lo largo de tres dimensiones de calidad, fiabilidad, funcionalidad, rendimiento de
las aplicaciones y rendimiento del sistema. Para cada una de estas dimensiones de
calidad, el proceso describe cómo ir a través del ciclo de vida de la prueba de la
planificación, diseño, implementación, ejecución y evaluación” (Rational Software
Corporation, 2011).
Para Rational el propósito de las pruebas es:
 Comprobar la interacción entre los objetos.
 Verificar la correcta integración de todos los componentes del software.
 Verificar que todos los requisitos se han aplicado correctamente.
 Identificar y asegurar que los defectos se tratan antes de la implementación.

En particular (Scriven, 1967), usó los términos ‘formativa’ y ‘acumulativa’ para describir dos
aproximaciones diferentes para la evaluación de currículos educativos (Chen, Osman,
Nunes, & Peng, 2011).

Tabla 31 Comparación de tipos de evaluación.

Dimensiones Formativa Acumulativa
Audiencia objetivo Los directores de programas, Tomadores de decisiones, donantes o el
profesionales público.
Enfoque de la Pruebas cualitativas para clarificar Medidas cuantitativas del resultado.
recolección de datos. los objetivos, contenido y estructura
del programa.
Papel del Evaluador. Interacción Bidireccional. Comunicación Independiente de una Sola Vía.
Metodología. Uso intensivo de diseño cualitativo. Diseño experimental y cuantitativo.
Frecuencia de la Monitoreo continuo. Limitada o una ronda de recogida de datos.
Recopilación de Datos.

132
 Procedimientos de Informal a través de la discusión en Informes formales.
Notificación grupo y reuniones.
Frecuencia de los Durante el proceso general de Después de la terminación de la evaluación.
informes. evaluación.
Fuente: (Chen, Osman, Nunes, & Peng, 2011)

La evaluación acumulativa es llevada a cabo cuando el proceso de desarrollo e

implementación ha finalizado, e intenta reunir información y retroalimentarla para evaluar
los efectos, efectividad, impacto y salidas del prototipo de sistema de información
desarrollado (Clarke, 1999), por estos motivos el prototipo ha sido evaluado con este estilo.

7.1. Formularios de Evaluación.

Se han diseñado formularios independientes para la evaluación de casos de uso y
requerimientos; los requerimientos funcionales mediante una comparación cualitativa, los
requerimientos no funcionales y los casos de uso mediante evaluación cuantitativa y
cualitativa.

7.1.1. Evaluación de Requerimientos Funcionales.

Los requerimientos funcionales se evalúan respecto a los criterios de si la función diseñada

fue implementada, forma en que fue implementada o si fue solo enunciada.

Tabla 32. Evaluación de Requerimientos Funcionales

REQUERIMIENTOS FUNCIÓN FUNCIÓN ENUNCIADA.
MÉTODO DE
FUNCIONALES DEL SISTEMA IMPLEMENTADA EN NO DESARROLLADA
IMPLEMENTACIÓN
DISEÑADO PROTOTIPO (FUERA DEL ALCANCE)
Permitir cargue de datos, compra  Consulta espacial  Función Heron.widgets.  Cargue de datos
on-line, análisis, consulta,
 Visualización ráster search.SpatialSearchPanel.  compra online
visualización ráster y edición de
 Edición de  WMS. WFS-T  análisis
información geográfica vectorial,
según permisos de roles y información  Botón visualización de
restricciones de acceso en internet.  Restricciones de imagen
acceso.  usuario se registra con
nombre y clave
Atributos de calidad y metadatos de  Visualización de  Visualización en navegador  Metadatos
los productos consultados son
Atributos de calidad de tabla de atributos.
desplegados junto con una pre-
 Visualización de  Ventana visualización de
visualización del producto.
Atributos de calidad imagen.
La entrega del producto final debe  Actividad nominal en  Botón entrega (ejemplo  Entrega
hacerse por medio digital o
proceso de negocio visual, no se consumen  Impresión
descarga, el usuario podrá contactar
servicios).
servicios de impresión y envío.

133
Todas las funciones del sistema  Visor de mapas.  WMS.  Análisis.
incluidas las de análisis, deben
 Cálculo de líneas  Botón Cálculo de Líneas  Cálculo de valor total
ofrecerse como servicios
(Función en Javascript).
reutilizables, su acceso dependerá
de la naturaleza interna o externa en
la que cumplan su ciclo los servicios.
El sistema debe ofrecer los servicios  Cuenta de usuario  Bonita BPM Portal (función  Pagos
de cuentas de usuario y pagos.
incorporada en software)
Las herramientas de administración  BAM.  Bonita BPM.
deben ser operadas por internet.
Se le debe proveer al usuario la  Reclamos.  Formulario de Reclamos.
forma de registrar insatisfacciones
(Ejemplo visual, no se
acerca del servicio o productos a
almacenan datos)
través de un cuadro de texto de 200
caracteres máximo

La tabla 32 es la tabla de requerimientos funcionales del sistema y los campos que

permiten la aclaración de las funciones que se han implementado en el prototipo. La
principal razón de que existan funciones no implementadas es la capacidad técnica, puesto
que se requieren desarrollos con mayor grado de complejidad que las funciones
implementadas. Sin embargo se estima que esta complejidad es simplemente técnica y a
la vez económica, puesto que los conceptos funcionales son ampliamente usados en los
sistemas bancarios o comerciales actuales.

7.1.2. Evaluación de Requerimientos no Funcionales.

Como se ha establecido mediante el marco teórico, los requerimientos no funcionales son
una medida de la calidad del sistema, en este caso se trata de una medida de la calidad
del prototipo. A continuación se hace una evaluación cualitativa de cada requerimiento
mediante la columna que describe la observación sobre el respectivo requerimiento y una
estimación cuantitativa del nivel de cumplimiento de cada requerimiento mediante la
columna llamada estimado de alcance; ésta última de carácter porcentual, con valores
entre 0 y 100 en un esfuerzo por hacerla más objetiva, a partir de la comparación de
diferencias con el diseño.

Tabla 33. Evaluación de Requerimientos no Funcionales.

OBSERVACIÓN SOBRE EL ESTIMADO DE
REQUERIMIENTOS NO FUNCIONALES
PROTOTIPO ALCANCE %

El despliegue de cartografía básica no debe Este requerimiento está inicialmente en función de

imien
Rend

to

superar los 2 segundos y el de imágenes los las capacidades del hardware o velocidad de 70
3 segundos. conexión a internet, no aplica totalmente al prototipo.

134
 El procesamiento de datos no debe superar
los 4 segundos.
Se debe reducir al máximo la carga
transaccional cuando se haga transferencia
de imágenes aun cuando tengan una menor
Desempeño
resolución.
Se necesitan procesar imágenes en formato
ráster en extensiones PNG, JPG, Geo TIFF y
SVG.
Se deben satisfacer la totalidad de los
pedidos de los clientes.
La administración debe hacerse con
herramientas tecnológicas que permitan
operación a través de internet.
Portabilidad
Las ubicaciones de las bases de datos deben
estar distribuidas en la nube.
El sistema operativo debe estar basado en
Linux con una distribución que permita el uso
de un SMBD como PostgreSQL o MySQL
Se aborda desde el punto de vista de las
restricciones de acceso para los roles de
acuerdo a las responsabilidades que cada rol
tiene durante el proceso.
Los usuarios no registrados como clientes no
podrán acceder a ninguna información
Seguridad
diferente a la que se visualice en el Portal
Web.
Para evitar recibir información inválida o
alteraciones indeseadas de datos, deben
implementarse herramientas de metadatos y el
bus de servicios.
Los clientes deben tener garantizada la
protección de su información personal.
La exactitud de posición de los productos debe
ser como máximo de un metro, es decir, los
datos no pueden tener errores de posición por
encima de un metro.
Fiabilidad
En caso de perderse la conexión con el
usuario durante la sesión de consulta, debe
guardarse la información de sesión e historial
de cambios del usuario en la solicitud y el área
de interés para retomar la consulta cuando se
reinicie la sesión.
Evaluación dependiente de recursos de hardware. 50
Asumiendo la carga transaccional en función de la
cantidad de datos consultada, para un prototipo no N/A
es un valor representativo.
El prototipo no procesa imágenes, los formatos son
manejados por ExtJS o transformados para su N/A
manejo. Las imágenes se despliegan en JP2
Se requiere un análisis de la relación producción -
10
demanda.
La implementación de Bonita BPM cuenta con
100
herramientas BAM.
No implementado en prototipo por necesitar elevada
0
capacidad técnica
El sistema operativo del prototipo es Linux en la
distribución Ubuntu 16.04 y el SMBD es 100
PostgreSQL.
Se implementan roles de usuario y administrador,
implementación de otros roles, perfiles y permisos 50
excede la capacidad técnica de un prototipo
Si no se ha registrado el usuario en la configuración
de la organización Bonita BPM, el acceso no está 100
permitido
El diseño de los formularios permite hacer
restricciones de entradas (dominio de las variables 100
que entra el usuario)
No implementado por capacidad técnica de un
0
prototipo.
Generalmente las imágenes de UAVs tienen una
precisión alta, las imágenes usadas en el prototipo
100
tienen un GSD = 15 cm y exactitud de posición de 5
cm
Las conexiones en el prototipo son permanentes, la
conexión con internet se usa para la API de Google
0
pero el resto de los servicios funciona con
servidores locales.
135
 Se deben implementar herramientas que
Para el prototipo, el SMBD escogido (PostgreSQL)
permitan medir la integridad transaccional y
garantiza las propiedades ACID. La Idempotencia es
las propiedades ACID, con la con el fin de que 0
una propiedad dependiente de la disponibilidad en
los servicios tengan la propiedad de la
servicios complejos, coreografía u orquestación.
Idempotencia

Las herramientas ofrecidas por las interfaces

de usuario y las mismas interfaces de usuario
Apoyándose en otras técnicas como el diseño
deben ser altamente intuitivas para que el
gráfico, este requerimiento tiene alcance en un 50
Usabilidad

sistema se pueda usar por personas con bajo

periodo de tiempo más amplio
conocimiento de mapas en internet e
información espacial.

Las interfaces graficas de usuario en el

No implementado por capacidad técnica de un
navegador deben ser manejables por 0
prototipo.
dispositivos táctiles.
Disponibilida

La disponibilidad no necesita ser 24/7 (24

horas al día / 7 días a la semana), aunque
Dada la simplicidad del escenario, la disponibilidad
idealmente el sistema debería estar disponible N/A
no es medible en un prototipo.
la mayor parte del tiempo, la disponibilidad
mínima diseñada es 18/7.
d

Prototipo desplegado en una laptop con RAM =

Los dispositivos de hardware así como los de 3GB. Disco Duro = 160GB. Procesador = Intel Dual
software deben ser escogidos de forma que Core 1.60GHz. Tarjeta de Gráficos = Intel® 50
permitan escalabilidad vertical y horizontal 945GME. El software es libre y código abierto por lo
Mantenibilidad

tanto escalable.

Las aplicaciones deben desarrollarse con
estándares para servicios web geográficos y
lenguajes de programación empleados en
software libre.
Los servicios configurados en Geoserver cumplen
estándares OGC.
100
SQL, JavaScript, HTML, BPEL, Java son empleados
en todas las plataformas libres y código abierto

Es necesario que el sistema cumpla con El prototipo se aproxima a ser interoperable

conceptos de SOA como el bajo acoplamiento mediante el uso de estándares pero el acoplamiento 50
e interoperabilidad. es elevado.

Las funciones del proceso de negocio y en lo

Flexibilidad

posible del procesamiento de datos, deben ser
codificadas en forma de servicios de manera
que el sistema permita una independencia de
la plataforma y de los proveedores de
software.
La flexibilidad es media debido al elevado
acoplamiento en motor de procesos de negocio.
30
Se implementaron servicios web WMS, WFS, WFS-
T.

Una estadística descriptiva arroja un promedio de 51% para los puntajes, aunque este
promedio presenta una alta dispersión, es decir una desviación estándar de 40.8, no tiene
sentido práctico hacer inferencias sobre esta medida pero permite tener una idea del
cumplimiento general de los requerimientos no funcionales.

136
 7.1.3. Evaluación de Casos de Uso.
Los formularios de evaluación para los casos de uso siguieron el mismo patrón de
evaluación de los requerimientos no funcionales, se adicionaron campos que permitieron
registrar las diferencias entre diseño y prototipo en columnas de evaluación adicionadas a
la tabla del caso de uso ejecutado.

El caso de uso de sistema Registro de Cliente no es evaluado en esta sección debido a

que se asume su implementación parcial automáticamente en la instalación de Bonita
BPM, puesto que bonita crea usuarios y roles por defecto que son los que se emplean para
actuar con el prototipo. Los casos de uso de sistema: Entrega de producto, Facturación y
Pago de Servicios tampoco son evaluados como los anteriores, puesto que en el prototipo
han sido implementados como ejemplos mediante formularios simples, usados para
efectuar una secuencia de tareas en el navegador de internet.

Tabla 34. Evaluación del Caso de Uso "Consultar Producto".

Nombre del % de
Consultar Producto Observación
Caso Alcance
Actores Cliente, Servicio Web de selección de productos Un servicio también puede ser un actor 100
El cliente es un usuario registrado Usuario por defecto de Bonita BPM 100
Apache y Tomcat activos en el
El sistema tiene el servicio web en operación 100
prototipo
Condiciones Existe información de calidad y parámetros de las imágenes Tablas de datos leídas desde la base
Iniciales 100
cargadas al sistema de almacenamiento. de datos del modelo relacional
Las pre visualizaciones de las imágenes existentes han sido
procesadas y están cargadas en el sistema de Válido para la imagen de prueba 100
almacenamiento.
1. En el sitio web empresarial el cliente hace clic en el link
del servicio de consulta de productos cartográficos y otros La página web está disponible para la
100
servicios, a continuación el sistema activa el caso de uso de dirección http://localhost:8080/
registro de cliente.
2. Con el registro exitoso el cliente hace clic en los servicios
La actividad Solicitar Vuelo fue
deseados opción “Consultar Imágenes” u opción “Cargar
renombrada por la actividad de Diseño 100
Flujo de Imágenes”, la opción “Solicitar Vuelo” es ofrecida luego de
de Vuelo
eventos la actividad de Consultar Imágenes.

3. Se despliega en el browser una ventana con un visor La cartografía básica nacional

donde están los límites departamentales nacionales y la corresponde a la división geo- 100
cartografía básica nacional. administrativa al nivel de municipios

4. Con herramientas de navegación el cliente hace un

Las herramientas son proporcionadas
acercamiento al departamento, luego al municipio y 100
de forma automática por Heron
finalmente al área de interés.

137
 5. Con la herramienta de trazado, el cliente dibuja un
polígono y el sistema despliega una lista de productos Implementado mediante el WFS-T 100
hallados en el área de interés del cliente
6. El servicio compara el área cubierta por las imágenes de
la base de datos con el área de interés suministrada por el La implementación cubre la
cliente e informa, el sistema ofrece la posibilidad de solicitar presentación de la tabla de atributos y
un vuelo ya sea para completar el área o para hacer una la actividad renombrada de “solicitar
nueva captura, y en una zona contigua al visor geográfico vuelo” a “diseñar vuelo” para el área 70
se presenta la información de las imágenes existentes en trazada por el usuario, la distinción de
forma tabular mientras las pre visualizaciones de las completar o hacer nueva captura no se
imágenes se despliegan en un visor auxiliar según la implementa
imagen que desee ver el usuario.
7. El cliente selecciona las imágenes que desea adquirir
Se hace selección para abrir la
junto con productos adicionales (desempeñados por la 50
ventana de visualización.
organización o contratados online) ofrecidos por el sistema.
8. Se solicita confirmar los productos y procesos a ordenar y Formularios ejemplo de Facturación y
80
se activa el servicio de facturación y pagos. Pagos.
9. Se activa el servicio Entrega de producto. Formularios ejemplo de Entrega. 80
1. del flujo Nº 1, si el cliente no es un usuario registrado, se La aplicación solo funciona con el
100
inicia el caso de uso Registro de Cliente. usuario por defecto de Bonita BPM.
2. del flujo Nº 6: si el cliente luego de "Consultar de
Imágenes" selecciona la opción "Solicitar Vuelo", el sistema
activa el caso de uso Solicitar Vuelo usando la misma área
"Solicitar Vuelo" renombrada a opción
de interés y envía notificación al cliente de que la solicitud
"Diseñar Vuelo" se resume en un 60
Subflujos está siendo atendida y será contactado en menos de 6
formulario de ejecución simplificado.
horas vía e-mail para consultar información adicional y
comunicar el tiempo que tardara la ejecución y el costo
adicional. Al terminar se continúa la secuencia
3. del flujo Nº 2: si además de " Consultar de Imágenes " o
Actividad de Cargar Imágenes
"solicitar vuelo" el cliente activa la opción "Cargar
implementada como ejemplo 60
Imágenes", el sistema activa el servicio de cargar imágenes
simplificado
digitales.
Luego de las consultas y el reporte de costos el cliente
Confirmación efectuada en checkbox
Condiciones confirma si desea adquirir los productos y procesos 100
del formulario de valor total.
de Salida seleccionados para activar el servicio de pago.
Todos los datos de la consulta quedan registrados y
No implementado 0
asociados al cliente.
Los servicios seleccionados deben ser independientes y La secuencia diseñada para el proceso
100
ejecutarse uno a la vez. permite cumplir este requerimiento
Las imágenes y la información deben desplegarse en un
Se cumple en prototipo 100
Requerimien lapso máximo de 5s.
tos de El sistema debe ofrecer un medio para que el cliente Implementado con formulario de
100
calidad comunique sus inconformidades o sugerencias. Reclamos

La interrupción del proceso por caída del servicio o del En el prototipo los servicios de Google
sistema debe generar un reporte y la opción de continuarlo Maps son necesarios para ejecutar la 0
en el punto donde se interrumpió. aplicación.

138
 En el caso de uso Consultar Producto el promedio de puntuación de la tabla 34 ha sido de
82.6% pero se observa una variabilidad menor ya que su desviación estándar es de 30.5,
lo que indica que el promedio es un valor más representativo de la puntuación general y
describe un ajuste mayor del caso de uso ejecutado en el prototipo al caso de uso
diseñado.

Tabla 35. Evaluación Caso de Uso de Sistema “Diseñar Vuelo”.

Nombre del % de
Solicitar Vuelo Observación
Caso Alcance
Actores Cliente, Jefe Técnico, Operador Cliente, 30
El cliente ha ingresado el área de interés. Implementado con WFS-T 100
El cliente ha sido informado si existe o no una diferencia
de cobertura entre el área total cubierta y el área de Redundante para el usuario -
Condiciones interés.
Iniciales Aun cuando no halla diferencia entre áreas se ofrece la Solicitar vuelo diseñar vuelo en
50
opción de Solicitar Vuelo. formulario simplificado
El cliente ha confirmado su interés en programar y Confirmación efectuada en checkbox
100
ejecutar un vuelo del formulario de valor total.
1. Enviar la solicitud al jefe técnico No implementado 0
2. El jefe técnico calcula los parámetros del vuelo (altura,
Los parámetros son fijos para el
recubrimientos, líneas de vuelo) haciendo las preguntas 100
prototipo
pertinentes al cliente acerca del nivel de detalle deseado.
3. El jefe técnico notifica al operador la información del
Flujo de eventos No implementado 0
vuelo y los parámetros para la ejecución.
4. El operador efectúa el vuelo, pos procesa las imágenes
No implementado 0
y extrae la información de calidad que se carga al sistema.
5. Se informa vía e-mail al cliente que las imágenes están
No implementado 0
listas para consulta a través de internet.
Subflujos -
Condiciones de Las imágenes y la totalidad de la información de calidad
No implementado 0
Salida deben quedar cargadas en el sistema al final del proceso.
Los procesos de ejecución de vuelo, pos procesamiento,
Requerimientos extracción de información de calidad y cargue de
No implementado 0
de calidad imágenes deben ser monitoreados para incrementar la
eficiencia

En el caso de uso Diseñar Vuelo las estadísticas descriptivas obtenidas revelan

información que difiere de los casos anteriores, un promedio de 34.5% y un coeficiente de
variación del 130% muestran una gran diferencia entre el diseño y la implementación. Esta
diferencia es debida a la falta de implementación de los eventos finales del caso de uso y
consecuentemente al incumplimiento de las condiciones de salida del caso de uso. Se
observa que una condición inicial resulta redundante para el usuario ya que fue diseñada
como un reporte para instar al usuario a ordenar un vuelo en las áreas de su área de interés

139
 no cubiertas por los productos hallados en la base de datos, pero sí el usuario ha
seleccionado activar el caso de uso Diseñar Vuelo luego de pasar por la actividad de
Consulta y la generación preliminar de líneas de vuelo, significa que está efectivamente
interesado en el vuelo sobre su área de interés sin importar el porcentaje de cobertura que
exista.

7.2. Pruebas Realizadas.

Las pruebas se efectuaron principalmente con respecto al proceso de negocio y la
secuencia que este debe exhibir en el navegador debido a los tipos de compuerta y la
forma como son manejados por Bonita BPM.
El diseño del proceso de negocio ser hizo inicialmente en Bizagi BPM Modeler, este
software presentó el inconveniente de no permitir el uso del motor de procesos Bizagi
Engine por ser parte del software comercial Bizagi BPM Suite. El modelo inicial concebido
en BPMN se puede observar en la ilustración 61, aunque las actividades son las mismas
del modelo final provisto en la sección 4.1, excepto la de Inscripción e Inicio de sesión así
como la de Subproceso de pago que en el modelo final se convierte en Pago, este modelo
varía sustancialmente en términos del uso de compuertas y la secuencia, puesto que en
Bonita BPM si se pudo hacer una verificación del flujo.

Ilustración 61 Modelo generado con Bizagi BPM.

Durante el proceso de codificación se necesitaron probar los valores de promedio de altura,

distancia focal, GSD para que la generación de las líneas de vuelo sea de una escala
acorde con las condiciones de vuelo de un dron y sus proporciones con respecto a las

140
imágenes de prueba, estas pruebas también tienen la finalidad de parametrizar en el
código las alturas de vuelo y porcentajes de traslape a partir de especificaciones de la
cámara, como se ve en el anexo del código, los valores son fijos para la distancia entre
líneas.

7.2.1. Evaluación con Actor.

De los actores diseñados para el sistema de información se ha seleccionado un sujeto de

prueba experimentado en el campo de fotogrametría y encargado de las decisiones en una
organización real, es un gerente de una empresa dedicada a ofrecer los servicios que
generan drones y aeromodelos para diferentes aplicaciones ambientales y comerciales,
por tanto su experiencia es de gran importancia para las futuras mejoras o adaptaciones a
un escenario real de producción. Este actor es quién responde las preguntas y es la
principal referencia en cuanto a captura de información para las decisiones de diseño.
La evaluación del sistema fue realizada únicamente con un actor debido al inconveniente
que presenta la consecución o disposición adicional de un actor objetivo como los descritos
en los casos de uso, es decir a quien van dirigidos los diseños de las interfaces que han
sido planteados en la sección 4.3 Casos de Uso. Este tipo de actores son de un nivel
administrativo elevado y con breve instrucción pueden realizar las mismas pruebas que ha
realizado el actor escogido para la evaluación, pero con la desventaja de no poder expresar
detalles técnicos relevantes para los avances de futuros desarrollos en el prototipo, como
sí lo hizo efectivamente el actor seleccionado.
De acuerdo con lo anterior, la cuestionable validez de la prueba hecha con un solo actor
es sustentada teniendo en cuenta las características técnicas, tanto del prototipo como del
usuario, necesarias para llevar a cabo una evaluación lo más ajustada posible a las
condiciones de implementación, es decir, un usuario que use el sistema no puede tener
desconocimiento de la información espacial.

Las siguientes preguntas y respuestas aportan más detalles acerca de las actuaciones del
usuario seleccionado frente al prototipo.

¿Qué fue exactamente lo que hizo el usuario?

El usuario fue primero brevemente instruido por el autor de la tesis con respecto a aspectos
generales del sistema, es decir; se le hizo una descripción rápida de las directrices de
diseño y las ventajas que puede tener la implantación de este sistema en su organización,

141
la cual se dedica esencialmente a la ejecución de vuelos fotogramétricos con drones. A
continuación el usuario ingresa al sistema mediante un usuario con un rol no administrativo
y luego inicia un proceso de negocio solicitando los tres servicios que sirven de ejemplo
para el prototipo, la secuencia exacta se encuentra detallada en la sección 6.4.4. Motor de
Procesos de Negocio y Aplicación.

¿Realizó todas las operaciones contempladas en cada servicio?

Las operaciones realizadas por el usuario con el prototipo del sistema fueron exactamente
descritas en la sección 6.1.1. Implementación de los Servicios, las operaciones fueron
hechas en su totalidad.

¿Cuáles datos utilizó?

Los datos utilizados por las aplicaciones y el usuario quedan detallados en la sección 6.3.
Bases de Datos.

¿Cuál es el volumen de los datos utilizados?

Se utilizaron para el prototipo un total de 11 imágenes, cada una capturada en el espectro
visible con un peso de 7.5 MB por imagen. Los archivos descargados para la información
de Departamentos y Municipios pesan 540KB y 1.91MB respectivamente. El archivo de
marcos de las imágenes así como los datos de las entidades del modelo que se
convirtieron en tablas pesan 22.163 MB cuando se crea el archivo de pgAdmin, este actúa
igual que un back-up restaurable en cualquier base de datos PostgreSQL.

¿Cuál fue el área de interés?

El usuario fue alertado de que teniendo en cuenta que se trata de un prototipo y de acuerdo
a la información utilizada, no sería útil para la prueba digitalizar un área de interés en
cualquier lugar del territorio nacional. Parte de la orientación durante el desarrollo de la
operación Ingresar Área de Interés fue señalar el único lugar donde tenía sentido hacer la
consulta, puesto que en cualquier otra parte el resultado de la búsqueda arrojaría cero
registros. De acuerdo a lo anterior el área de interés creada por el usuario es un polígono
aleatorio cuya única condición es que incluya la zona donde se encuentran los marcos de
las imágenes en la base de datos espacial, al sur del departamento de Bolívar.

¿Cuánto se demoró realizando esas operaciones?

El tiempo total empleado en la prueba no supera los 20 minutos incluyendo el tiempo que
fue empleado en la instrucción y ambientación del usuario a las particularidades del

142
prototipo, el tiempo empleado para cada actividad puede evidenciarse en el numeral 7.2.2.
Métricas en el Prototipo, correspondiente al presente capitulo.

Teniendo en cuenta la metodología de evaluación acumulativa, se diseñan siete preguntas

orientadas a sondear la experiencia del usuario, es decir se entrevista al profesional con
amplio conocimiento y experiencia acerca de las necesidades de los clientes.

Encuesta
1. ¿Cuáles eran las expectativas antes de usar la aplicación?
R: Gestión de grandes volúmenes de fotografías aéreas.
2. En una escala de 1 a 5 califique el proceso, 1 no se entiende, 5 se entiende.
R: 4.
3. Describa las confusiones.
R: No percibí diferencias para un cliente o un administrador interno.
4. ¿Considera necesario algún tipo de conocimiento técnico para hacer la Consulta?
R: No.
5. ¿Con que aspectos o características está de acuerdo?
 Selección de los procesos o procesamiento a realizar a las fotografías.
 Administración de procesos por parte del cliente como del proveedor.
 Consultas espaciales.
6. ¿Qué aspectos cambiaría?
R: Metadato de cada fotografía, debe incluir (Del centro de cada foto coordenadas X, Y, Z,
ángulos de giro Omega, Phi, Kappa, además de contar con los parámetros de la cámara
con la que fue tomada. Con esta información se conforman las 2 orientaciones necesarias
para procesos fotogramétricos Orientación Externa y Orientación Interna de la foto).
7. ¿Qué porcentaje de clientes cree Ud. que puede hacer una consulta dadas las
condiciones del prototipo?
R: 80%.

Las respuestas han sido registradas exactamente como el encuestado las resolvió, la
tendencia cualitativa de la encuesta podría mostrar una aceptación del prototipo de
acuerdo a la respuesta de las preguntas 4 y 7, y perfila los futuros cambios que deben
hacerse.
Un análisis de las respuestas permite observar que:

143
1. Las expectativas parecen elevadas en términos técnicos puesto que el manejo de un
gran volumen de fotografías aéreas no es viable para un prototipo instalado en una
laptop con las especificaciones técnicas de los requerimientos diseñados.
2. Las confusiones manifestadas en la tercera respuesta obedecen a que para el prototipo,
no fue necesaria una implementación de roles puesto que la instalación de Bonita BPM
incorpora roles de administrador y usuario.

7.2.2. Métricas en el Prototipo.

Bonita BPM habilita herramientas de monitoreo (BAM4) que permiten evaluar el tiempo que
se emplea en la ejecución de cada actividad con exactitud al minuto, en el caso del
prototipo existen unas actividades más representativas que otras en cuanto al tiempo de
interacción del usuario con la interfaz de cada actividad.
Bajo la premisa que las actividades del proceso son de un nivel de abstracción elevado y
que el diseño conceptual y real de la interfaz de usuario, exigen simplicidad para ser
manejado por usuarios menos familiarizados con la información o herramientas espaciales;
se considera que las actividades que tienen relación directa con el cliente son las
actividades críticas de evaluación, es decir la actividad de Consulta (ilustración 33).
Las actividades que llevan a cabo procesos demasiado complejos como por ejemplo las
actividades de Diseño de Vuelo (ilustración 36) y Producción (ilustraciones 21 y 55),
carecen de sentido práctico en la evaluación por su tiempo de ejecución en el prototipo,
puesto que estas actividades son abstraídas en el proceso de forma que son realizadas
haciendo un clic en el botón del formulario, como se puede observar en un video que se
adjunta en el disco compacto de anexos.
Otra actividad cuyo desarrollo carece de aporte para evaluación, en el caso del prototipo,
es la actividad de Cálculo (ilustración 51), debido a que se plantea que el cálculo de costos
de los productos seleccionados, sea una función semiautomática, basada en la selección
de productos hecha con el área de interés y los criterios de un operador. Las actividades
que han sido planteadas como un servicio externo, consumido según la necesidad del
usuario, son las actividades de Pago y Entrega que también son ejemplarizadas haciendo
clic en el botón de su correspondiente formulario.
En el caso de Pago, esta actividad presenta un tiempo que no es posible estimar con algún
rango de certeza puesto que una vez que el proceso contacta el servicio de pago online,

4 Business Activity Monitoring

144
el tiempo de ejecución depende de las condiciones de calidad o disponibilidad del servicio,
si la opción que selecciono el usuario fue generar una factura, es aún más difícil estimar el
tiempo que emplea el usuario en hacer una diligencia personal.
Por lo anterior se hace uso de los reportes de tiempos que registra Bonita BPM para
realizar mediciones que permitan evidenciar la realización de cada terea.

7.2.2.1. Reporte de Resultados.

En las ilustraciones siguientes de esta sección se observan las tareas listadas por las
herramientas de monitoreo, el orden del reporte es inverso al orden en que fueron
ejecutadas por el usuario.
La ilustración 62 presenta la primera parte del reporte general del proceso de negocio
ejecutado para evaluación, se puede observar el identificador que fue asignado al proceso
con el numero Case id: 15002 y el nombre del proceso: “Proceso Negocio”.

Ilustración 62 Reporte de resultados 1.

Se encuentran detalles del proceso como la versión correspondiente 1.0, fecha y hora de
inicio, nombre del usuario que realizo el proceso que para este caso es el usuario por
defecto llamado Walter Bates, fecha de actualización que hace la herramienta del proceso
y finalmente el estado del proceso en este caso es completed, es decir proceso finalizado.

145
La primera tarea en la ilustración 62 corresponde a la última tarea realizada por el usuario,
es decir la tarea llamada Reclamo?, como se puede observar la diferencia reportada entre
la primera y la segunda tarea con exactitud al minuto es cero, al igual que la diferencia
entre ésta y las predecesoras hasta la tarea de Pago en la ilustración 63. Esta diferencia
es debida a que las tareas finales luego de pasar el formulario de Pago se hacen en menos
de 1 minuto, ya que las actividades son simplificadas con un formulario de un botón y
ejecutadas con clic en tal botón.

Ilustración 63 Reporte de resultados 2.

Las ilustraciones 63 y 64 presentan la continuación del reporte de la ilustración 62, como

se puede comprobar la secuencia total no emplea más de 4 minutos para completar un
proceso que incluye un ciclo de reclamo.

Cada actividad de la lista esta especificada con el nombre de la actividad o compuerta, el

primer caso corresponde al nombre de la compuerta llamada Reclamo? y se identifica con
un icono parecido a una llave, los otros iconos identifican tareas humanas.

Se observa también que la tarea que más consume tiempo es la tarea de Consulta puesto
que tarda dos minutos, esta tarea es bastante dependiente de la velocidad de conexión a
internet ya que el uso de la API de Google Maps actualiza las imágenes en tiempo real
según el movimiento del usuario en el mapa, además por ser una tarea que usa el visor

146
también está conectándose a las bases de datos geográficas de PostgreSQL y las
corporativas de h2, consumiendo más recursos al hacer la petición de la imagen.
Ilustración 64 Reporte de resultados 3

Ilustración 65 Reporte de actividad Consulta.

147
La ilustración 65 hace una lista de comentarios de las actividades predecesoras a Consulta
en la parte inferior derecha, en la parte superior se presentan detalles de la ejecución de
la tarea; la fecha y hora de expiración, terminación y asignación, sin embargo no presenta
información acerca de la duración de la tarea, aunque esta información puede extraerse
de la ilustración 64.

En el caso de la actividad de Entrega, en el prototipo se plantean dos opciones de entrega;

(i) contactar servicio de Impresión y Envío o (ii) el de Descarga. El servicio de Impresión y
Envío tiene las mismas características del servicio de Pago, es decir son servicios
diseñados para contactarse o consumirse por internet pero no son implementados en el
prototipo, estos servicios externos a la organización tienen efectos directos en el tiempo
total de ejecución del proceso, pero solo en el caso en que fuesen consumidos realmente,
sobretodo el de impresión y envío.

7.3. Ajustes.
Debido al cambio de Bizagi Modeler a Bonita BPM, hubo necesidad de incluir una
compuerta paralela en la parte inicial de la secuencia como se observa en el diagrama del
proceso de negocio, esto con el fin de hacer el proceso de Consulta reutilizable desde el
punto de vista conceptual para el proceso de Diseño de Vuelo, puesto que de lo contrario
habría necesidad de utilizar 2 veces la tarea del usuario con el visor; una para la Consulta
y otra para el Diseño.
La secuencia ajustada permite que al momento de seleccionar la opción de Diseño, el
usuario tenga que pasar primero por consulta pero al seleccionar las dos al mismo tiempo,
se resuelvan ambas en el proceso de consulta mediante una casilla de verificación en el
formulario.

7.4. Evaluación de Objetivos y Discusión.

En cuanto a los objetivos, de acuerdo a la secuencia de estos se ha observado que el
objetivo general “Desarrollar un prototipo de Sistema de Información Geográfica que
soporte el proceso de negocio relacionado con el uso, administración y despliegue
de fotografías aéreas digitales, usando una arquitectura orientada a servicios”, ha
sido alcanzado con los detalles suficientes para el soporte del proceso de negocio a partir
de los objetivos específicos. La administración se remite principalmente a las capacidades
de modificar el modelo de acuerdo al conocimiento del ambiente legal y comercial, sin que

148
esto influya de ninguna manera en las aplicaciones desarrolladas para el prototipo, dentro
de las características administrativas también se incluyen las herramientas de monitoreo,
proporcionadas en la suite de Bonita BPM y usadas para las pruebas, aunque su utilidad
fue baja teniendo en cuenta que los indicadores diseñados para el monitoreo presentan
variables que tienen sentido en periodos de tiempo más largos que los de las pruebas del
prototipo.

El uso de SOA para el desarrollo de un prototipo es una condición que potencia la

implementación en un ambiente de producción principalmente en términos del diseño y
ejecución del proceso de negocio, y de forma secundaria en términos de las
comunicaciones con otros sistemas y de las posibilidades de sofisticación desarrollando
servicios web a partir de los diseños realizados.

Para el primer objetivo específico “Diseñar y modelar el proceso de negocio para la

administración de fotografías aéreas digitales desde el punto de vista de la
Geomática y los SIG.”
Se pudo evidenciar la teoría de SOA que permite a través de BPMN hacer procesos con
la mayor independencia de la plataforma de implementación tecnológica; teniendo en
cuenta que la primera aproximación intuitiva es crear un modelo grafico en papel, que
consiste en cuadrados con textos cortos que titulan la actividad y flechas como símbolos
de secuencia, la complejidad de las relaciones entre las actividades depende del
conocimiento y habilidad en la operación de compuertas de decisión que forman los
procesos propuestos, en el mercado y el ecosistema en términos de SOA.
Desde el punto de vista de Geomática, el modelado inicial del proceso tiene en cuenta que
se debe manejar información espacial y geográfica durante el proceso y que ésta
información necesita administrar detalles técnicos, como el hecho de que toda imagen
deba ser georreferenciada o el manejo de sistemas de referencia para implementar
servicios web de mapas, estos detalles inciden en las secuencias y duración real del
proceso, evidenciando el espectro y complejidad de aplicaciones en Geomática pero
principalmente la relación que tiene con los flujos de trabajo y Procesos de Negocio.
Los detalles mencionados van incrementando la complejidad del proceso, aunados a los
detalles de la creación del proceso de negocio con fines de prestar un servicio, ya que
SOMA declara que toda actividad es un servicio potencial.
Desde el punto de vista de los SIG se observó la utilidad que presentan los conceptos del
desarrollo de sistemas de información y las etapas del RUP para la información geográfica,

149
esta utilidad se evidencia en que desde el principio del diseño debe prestarse mucha
atención en la propuesta teórica de RUP; en cuanto a la intensidad del esfuerzo necesario
para el desarrollo de cada fase y etapa, puesto que la experiencia con este trabajo ha
demostrado que, por ejemplo la etapa de implementación puede ser subestimada
dependiendo de las características técnicas específicas de la codificación debido al tema
de la información geográfica.
Las herramientas de modelado inicialmente parecen simples de manejar puesto que el
conocimiento progresivo de BPMN permite conceptualizar las actividades y sus
secuencias, pero teniendo en cuenta la amplia gama de símbolos en BPMN para
conexiones a bases de datos, eventos, agrupaciones, mensajes, etc., se observa la
complejidad y potencial de la notación.

Se hizo un cambio de herramienta, de Bizagi a Bonita BPM, se observa que cada una
exhibe diferentes características que explotan diferentes aspectos de la teoría, por ejemplo
la forma en cómo se expresan las variables en las compuertas para las dos aplicaciones,
es distinta así como la configuración de la base de datos.
El concepto del cambio propuesto por SOA fue aplicado también al modelo y hace evidente
la facilidad de adaptar un proceso de negocio dentro de la misma herramienta de
modelado, sin embargo se presentan problemas de compatibilidad en las versiones del
lenguaje de intercambio entre diferentes proveedores de software para procesos de
negocio. En el caso específico de este trabajo, los archivos creados en Bizagi no fueron
aceptados por la función de importar en Bonita BPM.
Las restricciones de uso de la herramienta comercial presentan una desventaja en el precio
mientras que la de software libre potenció y permitió el desarrollo real evitando el costo de
adquisición de licencias, en cualquier caso las herramientas utilizadas y otros frameworks
de desarrollo consultados presentan la particularidad de que la complejidad de la aplicación
inicial con el tiempo se incrementa en función del número de usuarios o aplicaciones,
exigiendo herramientas más sofisticadas que solo existen como software propietario, esto
puede terminar en adquisiciones debido a la dificultad en el desarrollo para el área de la
IG, sin embargo si el desarrollo sigue simplificándose y con la proliferación de aplicaciones
SIG libres, eventualmente las herramientas se harán más intuitivas con interfaces
amigables, haciendo que la automatización de código ayude a expandir las fronteras de
las aplicaciones, pero también la dependencia de estas.

Para el segundo objetivo específico, “Analizar y determinar el gobierno, las reglas de

150
negocio, los stakeholders, los usuarios y los servicios de soporte del proceso para
el tratamiento de fotografías aéreas digitales utilizando una arquitectura orientada a
servicios.”
Ha sido necesaria la documentación y actualización en el área de fotogrametría de objeto
cercano para el análisis en el ambiente profesional, con el fin de poder usar UML para
identificar o diseñar entidades más descriptivas a través de los casos de uso. Esto permite
modelos más adaptables que mejoren o enriquezcan las relaciones en las actividades a lo
largo del proceso, estableciendo un cuadro más amplio y a la vez más detallado del
ecosistema como un concepto holístico, donde se descubre un medio para subsistir y
colaborar con otros sistemas, en función de apoyo o cooperación para el tratamiento de
fotografías aéreas digitales.
Sin embargo el empleo de UML también presenta dificultades debido a su larga trayectoria
de profundizaciones, investigaciones, aportes, puntos de vista de los diversos autores y la
inexperiencia del autor en el tema. Esto hace que su aplicación tenga que ser delimitada
por los conceptos que el investigador considere más relevantes sin poder entrar en
demasiados detalles que impidan el avance en otras áreas del desarrollo del prototipo.
En el mismo nivel de importancia está la documentación en SOA en el tema específico de
la determinación del gobierno, misión, políticas, y estrategias de intercambio de
información, puesto que los objetivos más elevados de la organización deben ser tenidos
en cuenta al momento de evaluar cualquier decisión de desarrollo, durante la codificación
de funciones o en la decisión acerca del empleo de alguna aplicación de software, lo
anterior se tiene en cuenta para poder elaborar un diseño dentro del concepto de auto
sostenibilidad, en un entorno que ofrece incontables oportunidades de implementación y
desarrollo.
El conocimiento de detalles acerca de los procesos fotogramétricos facilitó y ayudo al
diseño de las reglas de negocio, con la ayuda de estrategias comerciales diseñadas para
ofrecer beneficios, tanto a los clientes o socios como a la propia organización creando
vínculos que permitan continuidad.

La implementación o verificación de las reglas desde el punto de vista tecnológico hace

parte de un escenario más elaborado y difícil de implementar en un prototipo debido a la
necesidad del motor de reglas de negocio, lo que conlleva la implementación de software
para el bus de servicios empresariales ESB.

La determinación de los stakeholders o interesados también se ha realizado con la

151
visualización del ecosistema global del proyecto, estos interesados partieron de identificar
un usuario potencial de fotografías aéreas capturadas por drones, este usuario potencial
se pretendió inicialmente como un actor no instruido en el uso de información geográfica
con el fin de tener en cuenta la sencillez y usabilidad en los diseños, pero es claro que el
interés en fotografías aéreas capturadas por drones no corresponde a un usuario de mapas
común, es decir; el usuario visualizado es principalmente un individuo o entidad que
necesite información espacial de extensiones geográficas que apoyen la toma de
decisiones, por lo cual aunque éste usuario puede tener claridad acerca del producto que
necesita, también debe ser asesorado en cuanto a productos pero no necesariamente en
cuanto al uso de las herramientas de consulta según la implementación realizada.

Los servicios de soporte del proceso fueron identificados primero desde los servicios web
de mapas que apoyan la consulta y visualización de un producto, luego desde SOA como
paradigma de diseño, debido a que una implementación comercial del sistema propuesto
se asume con capacidad de consumir y ofrecer otros tipos de servicios web, como los
servicios basados en localización, no solo para la comunicación con usuarios y otros
sistemas de información distribuidos, sino también para aplicaciones al interior de la
organización que usan o encadenan servicios, ya que según la documentación consultada
cualquier actividad es un servicio potencial.

El tercer objetivo específico “Definir y organizar la ejecución del proceso de negocio

apoyándose en las tecnologías disponibles en el mercado para tal fin.”

Estuvo muy ligado al primer objetivo comprobando la ineludible dependencia de las

organizaciones y a la vez de los usuarios a los avances en tecnología, sin embargo se
observó una diferencia substancial, en que para éste objetivo se necesitaron habilidades
de organización y reorganización para diferentes capas entrelazadas de actividades, en la
medida en que el proceso se iba desenvolviendo en el ámbito de las tecnologías y
conceptos adquiridos. Además el cambio de la suite de Bizagi a la de Bonita mencionado
en el alcance del primer objetivo, permitió descubrir que existen grandes oportunidades en
el código abierto pero también inconvenientes al ser necesario un conocimiento o un
profesional que permitan el desarrollo en las herramientas libres. Esto fue causa de
desventaja en el proceso de desarrollo del prototipo, al tratar de desarrollar un visor de
mapas que cumpliera las características de los requerimientos funcionales y las exigencias
de las consultas, aunque se halló el cliente de mapas Heron MC, hubo necesidad de

152
adaptarlo y el bajo recurso técnico también condujo a búsqueda de profesionales
especializados en desarrollo en el área de información geográfica.
El cambio de suite mencionado exigió una mayor documentación en Bonita BPM y la forma
de manipular las compuertas, y de capturar las decisiones del usuario para que el proceso
tuviese la secuencia deseada, así como de los conceptos de HTML y formularios para
diseñar las interfaces y ejecutar cada actividad. Estas habilidades ejercitadas debieron ser
complementadas con las de instalación y puesta en funcionamiento del sistema operativo
(Linux Ubuntu 16.04), diseño montaje y administración de bases de datos (PostgreSQL),
configuración de servidores (Tomcat, Apache2 y Geoserver) y configuración de clientes
(Heron MC). Todo para ser desplegado en el browser y que pueda ser operado por internet
o por una intranet, sin que esto haga una diferencia técnica significativa.

El diagrama del proceso de negocio es útil para la visualización de las secuencias de las
actividades pero sobretodo del uso de las compuertas de decisión, sin embargo no es fácil
ver el caso de un servicio que es diseñado para ser usado en diferentes etapas de la
secuencia o por diferentes actores con el fin de que sea reutilizable, como sucede con el
servicio de Cargue de Imágenes el cual tiene la intensión de ser utilizado por un operador
como un proceso interno luego de la captura y como un servicio expuesto al usuario, así
también sucede con el proceso de cálculo de costo para un producto, lista de productos o
el costo preliminar de un vuelo, pudiendo ser reutilizados por operarios técnicos o
administrativos para hacer estimaciones económicas y también por los clientes.

Las tecnologías para la administración de bases de datos ofrecieron una ventaja al ser
empleado el SMBD PostgreSQL ya que permitió el manejo de datos espaciales mediante
la extensión PostGIS sin la necesidad de adquirir licencias, además es posible hacer una
conexión sencilla con el servidor de mapas Geoserver, para poder consumir en la
aplicación de Heron MC los mapas vectoriales Municipales, Departamentales y Marcos de
imágenes que se diseñaron para la implementación del prototipo así como la captura del
área de interés que es escrita directamente a la base de datos.

Durante el diseño de formularios se puede ver como todos los procesos muestran
posibilidades de automatización, haciendo la tarea de usuario y del desarrollador cada vez
más próxima; donde ambos analizan cada vez más cantidad de información, pero con la
necesidad de un enfoque que es proporcionado por la arquitectura orientada a servicios
utilizando tecnologías web.

153
El objetivo específico de “Exponer el proceso de negocio diseñado como un servicio
sobre internet con el fin de hacerlo visible para consumo de los usuarios.”, podría
parecer el más simple luego de una exhaustiva etapa de diseño, pero ha planteado las
mayores dificultades al comprobarse que es la etapa de más esfuerzo de la
implementación debido a las particularidades tecnológicas del proyecto. Tales dificultades
se encuentran no solo en el desarrollo de servicios web sino en el manejo de la información
geográfica, que exige profesionales en desarrollo especializado o con experiencia, además
de que ni el desarrollo de software ni la ingeniería de sistemas hacen parte de la formación
del autor de esta tesis. Si bien esto fue una desventaja en términos del tiempo, también
fué una ventaja en términos de la adquisición de conocimiento puesto que el autor pudo
tener un contacto directo y consciente con todos los componentes del prototipo, trabajando
con la mayor simplicidad dadas las dificultades mencionadas pero obteniendo los
resultados requeridos.
La exposición de los servicios diseñados no se hace con el nivel de sofisticación de los
Servicios Web puesto que demandan mayor capacidad técnica, tiempo y recursos
inalcanzables para éste prototipo, ya que también se debe disponer de un hosting no
gratuito que permita administrar una base de datos espacial, instalar la suite BPM para
ejecutar el proceso de negocio, además de la instalación y configuración de todo el sistema
operativo para la configuración de servidores, lo que difiere sustancialmente de un montaje
de una página web sencilla que muestre algunas imágenes y texto. Sin embargo la
exposición se realiza en el navegador de internet a través de la URL local
http://localhost:50931/bonita/apps/geoser/pagina/ para la máquina en la que el prototipo es
implementado tal y como se demuestra en el video anexo.
Si bien el prototipo no opera directamente desde internet, debido a las restricciones
mencionadas con anterioridad, este aspecto no es un impedimento relevante en cuanto a
la funcionalidad del prototipo o al hecho de que no pueda evidenciarse que el prototipo se
ejecuta, puesto que todas las tecnologías implementadas se han desarrollado a lo largo
del tiempo para funcionar con cualquier tipo de navegador que puede estar conectado bien
sea a internet o a una intranet, los archivos necesarios son suministrados sin que esto
represente una diferencia al momento de utilizar o probar las aplicaciones desarrolladas.

El conocimiento previo utilizado fue orientado desde los SIG y las herramientas de
geoprocesamiento para el análisis y visualización de datos espaciales. Los conocimientos
de fotogrametría análoga y digital fueron claves para manejar las funcionalidades relativas

154
a las líneas de vuelo, incluso los conceptos de percepción remota permitieron perfilar
servicios más complejos relativos al procesamiento de imágenes en el trabajo futuro.
Los conceptos en bases de datos relacionales y la investigación realizada para mejorar su
funcionamiento, permitió observar las bases de datos no relacionales como alternativa de
diseño; dado que SOA ayuda a plantear un sistema escalable, fue necesario observar las
propiedades ACID - BASE con el teorema CAP para proponer un SMBD NoSQL que pueda
implementarse al momento de escalar verticalmente, puesto que el escalamiento
horizontal parece relacionado a una demanda y complejidad muy elevados.

La ampliación de conocimientos en lenguajes de programación para la web como

JavaScript, HTML, CSS, GeoJSON y otros como SQL o XML, fue imprescindible así como
el manejo de ciertas librerías como OpenLayers y GeoExt para llegar a las condiciones
suficientes de funcionamiento en las que puede implantarse el desarrollo de un prototipo
que se adapte a necesidades particulares.

Se ha experimentado el aspecto técnico desde la puesta en funcionamiento y

mantenimiento de un sistema operativo, pasando por el montaje de las bases de datos, el
diseño mediante UML y BPMN, el desarrollo de aplicaciones web mediante APIs, el uso
de librerías JavaScript, los elementos HTML de una página o aplicación web, la
configuración de servidores, la publicación de servicios web OGC y aún más importante;
la conexión de todos estos elementos para alcanzar los objetivos propuestos.

El conocimiento adquirido está enmarcado principalmente, pero no restringido en términos

conceptuales, al tema de arquitectura de sistemas de información distribuidos y
modelamiento de procesos de negocio para Información Geográfica, entendiendo cómo
pueden ser diseñados los sistemas de información resilientes al cambio y operando con
Servicios Web para satisfacer diferentes tipos de demandas de usuarios potenciales, pero
más importante para comunicarse entre sí gracias a la interoperabilidad y los motores de
orquestación o coreografía. Se ha entendido que la importancia del servicio puede ir más
allá de su ámbito tecnológico, y el concepto de servicio aplicado a los sistemas de
información puede entrañar muchas más oportunidades de las que son visibles en primera
instancia, como llega a suceder en el ámbito social.

155
Capítulo 8 Conclusiones y Recomendaciones.

Se registran en este capítulo las respuestas a las preguntas de investigación y

conclusiones finales del trabajo, así como del trabajo futuro.

Los conceptos de SOA que se usaron para modelar tanto los procesos de negocio que se
han diseñado en BPMN, como el gobierno y la infraestructura tecnológica, han ayudado al
cumplimiento de los requerimientos no funcionales en un 51% y los casos de uso
implementados en un 83 y 35%, en tanto que los objetivos del estudio son alcanzados
satisfactoriamente.
De acuerdo con la prueba realizada por el profesional, el proceso de negocio satisface las
necesidades de organización y secuencia de actividades así como las de simplicidad de la
interfaz de usuario para la realización de una consulta espacial, aspectos que constituyen
el eje de desarrollo del prototipo en cuanto al modelo y la interacción con el usuario.
La utilización de lenguajes y protocolos estándar es un requisito obligatorio si se planea
interoperabilidad con otros sistemas o servicios.

8.1. Respuestas a las preguntas de la investigación.

La investigación realizada para el diseño del sistema y el desarrollo del prototipo, ha
permitido responder los interrogantes iniciales desde los conceptos adquiridos en
desarrollo y arquitectura de sistemas, sin olvidar que estos temas son de gran profundidad
pero no han sido el objeto directo de la investigación.

¿Cómo administrar eficiente y eficazmente las fotografías aéreas digitales en un

entorno web?
La conceptualización hecha a partir de SOA determina que una administración eficiente se
alcanza con la reutilización de los servicios de granularidad fina, pero principalmente con
el conocimiento cada vez más detallado de las actividades del proceso para poder
optimizarlas por medio de los diferentes tipos de herramientas, esto a la vez necesita una
documentación clara de actividades y casos de uso, que evite redundancias excesivas y
ambigüedades en los casos de uso, sin embargo las redundancias pueden llegar a ser
necesarias por claridad de ciertos detalles en la evaluación y visión general del trabajo.
Aun cuando SOA exige una granularidad gruesa en los servicios expuestos, este nivel de
granularidad solo se alcanza con funcionalidades de nivel superior en los servicios,

156
concepto que no presenta conflicto con la proposición que se hace para relacionar la
eficiencia con la granularidad fina, puesto que la práctica de reutilización aconsejada por
la literatura tanto para servicios como para la creación de código representa un mejor
aprovechamiento de los recursos de desarrollo.
La eficacia se logra obviamente mediante el alcance de las metas y el monitoreo de los
Indicadores Clave de Desempeño (KPI), para esto debe hacerse un seguimiento de la
“elocuencia” de cada indicador con herramientas BPM. Es pertinente mencionar que los
KPI han sido perfilados a partir de la actividad de Modelamiento de Metas de Servicios, su
objetivo es la medición de las actividades de negocios pero esta medición solo puede ser
efectuada a partir de un sistema implementado, con un tiempo de funcionamiento suficiente
para evaluar relaciones entre demanda, producción y las demás variables diseñadas para
las métricas.
Se observa que el diseño, principalmente en cuanto a la base de datos se refiere, también
está ligado al modelo de datos y al diseño de objetos y entidades, lo cual hace que el
sistema presente un acoplamiento inevitable, y que la eficiencia también dependa de la
pericia o experiencia del diseñador de la base de datos, esto en el caso de las bases de
datos relacionales. Por este motivo se propone una base de datos hibrida, puesto que SOA
necesita flexibilidad ante el cambio que pueda presentarse ya sea en el modelo de datos,
en los requerimientos o en el modelo de negocio.

¿Cómo ayudan los conceptos de SOA a los SIG para la administración de

Fotografías Aéreas Digitales?
Los conceptos de SOA varían según el campo de práctica y enfoque del autor, entidad o
corporación y sus objetivos académicos o comerciales, la ayuda más destacada a los SIG
es haciendo la información interoperable mediante el uso de estándares entre sistemas
distribuidos y legados, esto permite aproximarse a los mínimos en acoplamiento y
dependencia de la plataforma de hardware y software. Los Servicios Web y los buses de
servicios son una ventaja en cuanto al manejo de la complejidad del sistema, puesto que
la Notación para la Administración de Procesos de Negocio eleva el nivel de abstracción.
En el trabajo desarrollado los conceptos de SOA proporcionaron su mayor aporte al brindar
una metodología (SOMA) para el diseño y descubrimiento de servicios, y una notación
estándar para administración (BPMN) y diseño de un proceso de negocio que emplea
información geográfica, además los conceptos de bajo acoplamiento también influenciaron
las propuestas en bases de datos, dado que se visualiza un sistema escalable y los

157
aspectos convencionales de las bases de datos relacionales no ofrecen una escalabilidad
horizontal, a menos que pueda permitirse una inversión elevada pero que aumenta el
acoplamiento con el vendedor.
Aún cuando la comunicación es un aspecto muy importante en SOA, en el proceso de
documentación se ha podido entender que esta comunicación está enfocada hacia las
dificultades de integración que presentan los sistemas legados; es decir, el paradigma SOA
se ha desarrollado basándose en la profundización de técnicas y conceptos que fueron
empleados en el desarrollo de sistemas creados de forma independiente, en
organizaciones para el manejo de información comercial o gubernamental. Con las
tendencias globales del mercado, el desarrollo de la internet y los servicios web éstos
sistemas tuvieron necesidad de adaptarse a nuevas tecnologías para la comunicación de
subsistemas internos, comunicación con sistemas socios y con usuarios o clientes en
internet, sin embargo para los efectos del prototipo la sofisticación exigida por una SOA
para las comunicaciones no ha sido un aspecto de aplicación exhaustiva, debido a que el
prototipo no es un sistema legado y no se comunica con otros sistemas, por lo que han
sido innecesarias las implementaciones de middleware o el ESB .

El paradigma de diseño de SOA ha permitido el escalamiento de los SIG en ambientes

distribuidos no solo en capacidades de procesamiento, análisis y almacenamiento sino en
localización geográfica, esto aumenta la complejidad de los SIG y por lo tanto de las
tecnologías para su administración, demandando herramientas más sofisticadas y
profesionales con más habilidades para la multiplicidad de áreas en las que puede ser
implementado este tipo de sistema de información, incluida la propia actualización
cartográfica efectuada con drones.
Los SIG son una herramienta de apoyo espacial a las SOA; en el problema propuesto
sirven para el aprovechamiento de las capacidades de análisis de procesos, junto al
permanente rediseño o reingeniería que necesitan los modelos de negocio en sistemas
legados y distribuidos pero también innovadores y escalables.
Los SIG aunque están subordinados a los sistemas de información empresariales, juegan
un papel protagónico en la administración de la información, en función del análisis y
procesamiento de datos para la auto sostenibilidad de la organización y la creación de
nuevos servicios o tipos de servicios, como los servicios basados en localización (LBS), el
monitoreo de fenómenos culturales, naturales o incluso fenómenos subjetivos que pueden
tomar forma gracias al diseñador y su experiencia.

158
¿Qué especificaciones tecnológicas en hardware y software son necesarias para la
administración y control de las Fotografías Aéreas Digitales?
Las especificaciones tecnológicas son bastante variables, principalmente debido a que los
sistemas legados presentan amplia heterogeneidad en aplicaciones y desarrollos ad-hoc
que dificultan cualquier tipo de implementación de SOA, sin embargo para administrar
grandes volúmenes de datos como el caso de imágenes digitales, es fácil ver que las
necesidades se fundamentan en cuanto a hardware: en una infraestructura física
compuesta de servidores, procesadores, visualizadores, dispositivos de almacenamiento
de alta capacidad para ambientes distribuidos y redes, así como una conexión a internet
con especificaciones que cubran los requerimientos de la capacidad instalada. Todos estos
dispositivos obviamente necesitan la correcta instalación y configuración que permita su
operación en conjunto.

En cuanto a software: las especificaciones se encuentran en la instalación y configuración

de los SMBD sean relacionales o no relacionales, así como la utilización de un cliente web
de mapas que es la aplicación que consume los servicios WMS, WFS y WFS-T. Estos
servicios necesitan un software que permita configurar tanto las conexiones a las bases de
datos espaciales, como las propiedades de despliegue de capas que se aplican en la
visualización del visor a partir de archivos SLD, para el prototipo se usó Geoserver 2.4.0.
Para el funcionamiento de los servidores existe gran variedad de opciones en software
para servidores de aplicaciones, servidores web, servidores FTP, etc. que cubren
diferentes tipos de necesidades y son de distribución gratuita, en la mayoría de los casos
la selección depende de la relación entre costo y capacidad, pero el tipo de servidor si
depende del diseño arquitectónico.

La administración de la lógica de negocio y el motor de procesos de negocio están

incorporados en la suite BPM que sea escogida, este componente también presenta gran
diversidad de opciones. Industrias de software como Sun, Oracle, IBM, Microsoft, Rational,
WSO2 entre otras, ofrecen opciones que cubren las necesidades principales de la mayoría,
pero las necesidades particulares tienen un costo adicional.
Dentro de los aspectos cubiertos por estas corporaciones se encuentran las
comunicaciones entre aplicaciones, éstas son implementadas en diferentes tipos de
middleware que han sido desarrollados para la integración de sistemas legados, un ESB
es una característica fundamental en una SOA, dependiendo del tamaño del sistema y la
cantidad de servicios manejados es necesario emplear un motor de reglas de negocio y un

159
motor de orquestación o coreografía de servicios, además para descubrir los servicios es
necesario el repositorio de servicios, que es donde se pueden consultar los contratos de
los servicios y la forma de conexión.

¿Cómo ha de ser diseñado el proceso de negocio para monitorear y rastrear la

captura de fotografías y la actividad de los servicios?
El diseño del proceso inicialmente es independiente de los aspectos de monitoreo, al
momento de estar en ejecución un proceso se necesitan activas las herramientas de
Monitoreo de Actividades de Negocios – BAM, que presentan métricas estándar de
tiempos de ejecución y además pueden ser adecuadas a necesidades particulares según
las ofertas del vendedor, estas herramientas se encuentran incorporadas en las suites
BPM y pueden ser integradas con el ESB y con disparadores (trigers) para los indicadores
con el fin de verificar reglas de negocio, esto para un ambiente de implementación de
complejidad superior a la de un prototipo, ampliando la investigación hacia el campo de las
EDA y el potencial de automatizar totalmente la generación de código. Desde el punto de
vista administrativo y de diseño, el monitoreo es posible gracias al diseño de las metas de
la organización y a su vez de los indicadores KPI que permiten medir el alcance de las
metas así como el comportamiento del ecosistema, redundando en eventuales
modificaciones del proceso para adaptarse mejor al ecosistema.

También se concluye que existen diversas metodologías de aplicación de los conceptos

de SOA para infinidad de áreas de negocios, la selección de una u otra no es
necesariamente un criterio adecuado para la ejecución de un proyecto, el analista o grupo
de analistas deben esforzarse por conocer profundamente el ecosistema y hacer uso de la
mayor cantidad de información extraíble de los procesos, para ajustar los conceptos que
puedan parecer redundantes en cada metodología, sin embargo es conveniente para
iniciar adoptar algún método particular con el fin de aprovechar la experiencia de otros sin
perder la oportunidad de contrastarlo.
El amplio campo de acción y elevado nivel de abstracción de SOA hacen que su
aplicabilidad sea compleja y sus conceptos también puedan ser análogos con los de
arquitecturas dirigidas por modelos o por eventos (MDA o EDA respectivamente)
(Radhakrishnan, 2004), entre otras. Ante esto, lo primero en una organización es siempre
tener claras y actualizadas las políticas y metas, para luego enriquecer el conocimiento
acerca de la experiencia en teorías aplicadas a la industria, entre las posibilidades
existentes una de las más completas y disponibles es la propuesta de IBM con la

160
metodología SOMA (IBM, 2008), esta metodología ofrece una secuencia de actividades
para el descubrimiento y exposición de servicios de un sistema o ambiente específico.
Aunque la documentación y técnicas usadas en SOMA muestran una amplia
independencia de aplicaciones para el descubrimiento y exposición de servicios, y un uso
de conceptos sencillos que parten de las actividades de negocios y actividades del
proceso, es perceptible una tendencia natural al uso de aplicaciones más sofisticadas
ofrecidas por IBM, tal y como lo hacen otras metodologías con sus respectivas casas de
desarrollo y personalización de aplicaciones.

Las condiciones ACID que teóricamente deben cumplir las transacciones en una base de
datos, y el teorema CAP que describe propiedades de las bases de datos distribuidas, son
conceptos que también han sido la directriz para el desarrollo de la tecnología de Servicios
Web, se entiende esto debido a que ACID y CAP son mencionados en las descripciones
de las propiedades que deben tener los Servicios Web si entendemos la latencia análoga
a la disponibilidad, la atomicidad análoga al estado ya que el servicio al ser una función de
negocios, se realiza o no se realiza y a la vez debe mantener consistencia, lo que en los
Servicios Web sería idempotencia.

La Información Geográfica (IG) alberga insondables oportunidades de análisis para la

automatización de procesos productivos y de negocio en ambientes distribuidos, el
paradigma SOA permite que el uso de herramientas de desarrollo tenga un enfoque
innovador exigiendo nuevas herramientas basadas en generar código y manejar IG, esto
dado que los grupos de analistas y la gente de negocios siempre pueden encontrar nuevas
oportunidades, si las habilidades con el uso de estas herramientas mejoran.
Se observó que hace tiempo existen frameworks bastante completos que corren motores
de procesos, monitoreo, repositorios, middleware, buses de servicios y aspectos de
seguridad de manera cómoda pero costosa en términos económicos y de acoplamiento,
como ya se ha mencionado por diversos autores SOA no es un software que se compra y
se instala pero esta línea es bastante difícil de trazar sobre todo si se tiene en cuenta que
en el corto plazo es más económico comprar que desarrollar. El software libre puede ser
una solución que mantenga rezagada una organización en términos tecnológicos pero
ofrece cierta independencia.

Debido al tema de investigación en Tecnologías de la Información se ha tenido la

oportunidad de observar diversas tendencias, adelantos y teorías en las fronteras

161
tecnológicas y de la ciencia, resulta ineludible la observación acerca de la evolución y
capacidad incremental de los desarrollos tecnológicos en procesamiento, almacenamiento
de datos y en comunicaciones. Este aspecto global enmarcado en el desarrollo del
presente trabajo adopta el punto de vista de la Geomática y su relación con las SOA, la
sinergia entre estas disciplinas permite usar los servicios y sus composiciones, para crear
y mejorar procesos y comunicaciones entre diferentes tipos de recursos espaciales y
tecnológicos, apoyando la toma de decisiones en organizaciones comerciales,
gubernamentales e incluso académicas, ya que los drones y su variedad de aplicaciones
vienen popularizándose en diferentes ámbitos de la vida cotidiana y ya son profusamente
usados para aplicaciones militares.

Las tecnologías en lenguajes de programación y protocolos de comunicación han permitido

un hito de evolución importante en los servicios web y la forma en cómo las máquinas se
comunican entre sí gracias al WSDL, y con el hombre a través de formularios de contratos.
Los adelantos en las interfaces cerebro ordenador y los lenguajes de cuarta generación,
son el escenario en marcha en el ámbito de SOA e información geoespacial, es aquel
donde el acceso a bienes y servicios distantes geográficamente se ha incrementado y las
nuevas tecnologías se adquieren más rápido para ser empleadas con más eficiencia en
procesos locales por un mayor número de usuarios, por consiguiente el conocimiento de
recursos e información in situ, puede liberar el potencial de desarrollo de comunidades,
organizaciones o sociedades.
También es fácil observar cómo los avances mencionados en programación, apoyados en
otras áreas como la robótica o la realidad virtual y aumentada, están llamados a explotar
el potencial de la información geoespacial y la creatividad de diseñadores menos instruidos
en detalles técnicos, permitiendo reconocer el valor que tiene cada idea al ser desarrollada
con receptores e intérpretes que ordenadores y procesadores permitan administrar.
Desde sus inicios las funciones de la tecnología han sido claras, permitiría al hombre
liberarse del trabajo físico, dejando el tema en la intensión del diseñador como aspecto
fundamental de cualquier emprendimiento, en términos de un concepto tan importante
como lo es el servicio para los sistemas de información y a su vez para el hombre.

162
8.2. Conclusiones sobre el alcanzado realmente obtenido
con respecto a los objetivos.
A continuación se presentan las conclusiones puntuales relacionadas con el alcance del
objetivo general y de los objetivos específicos.

Para el objetivo general “Desarrollar un prototipo de Sistema de Información

Geográfica que soporte el proceso de negocio relacionado con el uso,
administración y despliegue de fotografías aéreas digitales, usando una arquitectura
orientada a servicios.”
El uso de SOA para el desarrollo de un prototipo es una condición que potencia la
implementación en un ambiente de producción, principalmente en términos del diseño y
ejecución del proceso de negocio, de forma secundaria en términos de las comunicaciones
con otros sistemas y de las posibilidades de sofisticación desarrollando servicios web a
partir de los diseños realizados.
El factor decisivo para el alcance del objetivo general ha sido la posibilidad de utilizar
herramientas BPM e implementar el proceso diseñado en un motor de distribución gratuita,
que se puede instalar en un sistema operativo libre sin la necesidad de aplicaciones
adicionales para la instalación o ejecución, aclarando que se necesita Tomcat pero esta
instalación también es gratuita e independiente del sistema operativo.
También fue decisivo el desarrollo de funciones en Javascript y la implementación del visor
para el despliegue, aunque es posible el desarrollo de un visor usando la librería
OpenLayers, el hallazgo del visor Heron MC proporciono una ventaja en términos de
presentación, uso de funciones y herramientas incorporadas.
En conclusión, se logró desarrollar una aproximación al prototipo, teniendo en cuenta que
no se desarrollaron todas las funciones mencionadas en el prototipo inicial. Sin embargo,
la aproximación desarrollada pone de manifiesto el hecho de que la idea de negocio
inicialmente planteada es completamente alcanzable y desarrollable.

Para el objetivo de “Diseñar y modelar el proceso de negocio para la administración

de fotografías aéreas digitales desde el punto de vista de la Geomática y los SIG”.
En la actualidad las herramientas de modelamiento de flujos en aplicaciones de escritorio
y web presentan menor complejidad debido al uso de la notación gráfica, en contraste
con los lenguajes de programación interpretados. Gracias a esto las tareas de diseño y

163
modelamiento tienen una proximidad mayor y un acercamiento más intuitivo, reduciendo
el costo de codificación.
El punto de vista de la Geomática y los SIG en el modelamiento hace referencia a las
actividades relacionadas con la manipulación de información geográfica bien sea para
captura, procesamiento o despliegue. En cuanto a la captura y el procesamiento, el modelo
del proceso de negocio no contempla los detalles de estas actividades de forma detallada,
pero respecto al despliegue; los servicios web realizados, la implementación del visor y las
funciones que operan con datos espaciales han permitido incluir la información geográfica
dentro del proceso de negocio, haciendo visibles las capacidades que ofrecen las
conexiones entre los servicios y las bases de datos a través de las suites BPM de
distribución gratuita y sus componentes.
En conclusión, se pudo desarrollar un prototipo de negocio que funciona de acuerdo con
el diseño planteado. Se usó la herramienta Bonita y su funcionamiento se puede apreciar
en el video adjunto a este documento.

En el objetivo “Analizar y determinar el gobierno, las reglas de negocio, los

stakeholders, los usuarios y los servicios de soporte del proceso para el tratamiento
de fotografías aéreas digitales utilizando una arquitectura orientada a servicios”.
El análisis del gobierno exige amplia experiencia en el mercado de imágenes digitales para
fotogrametría de objeto cercano y una concientización de las oportunidades que ofrecen
los servicios web, puesto que los cargos administrativos del tipo CEO deben ser los
primeros en propender por una cultura de SOA que permita un escenario federado y con
tendencia a la integración en una organización,
El análisis de las reglas de negocio según la literatura consultada, puede orientarse hacia
la relación con el cliente y las ventajas que se pueden ofrecer en términos estratégicos, sin
embargo estas ventajas deben ser evaluadas con una relación costo beneficio en una
ventana de tiempo razonable que también permita retornos de inversión. Es decir, se
evidencia la necesidad de que cada regla tenga una evaluación de viabilidad económica.
Aunque la diferencia entre stakeholders y actores o usuarios puede ser un tecnicismo, se
puedo establecer que los usuarios corresponden a actores primarios y secundarios
directos, dentro de los cuales se encuentran los clientes, operadores, administradores e
incluso codificadores, mientras que la agrupación de stakeholders comprende clientes
potenciales, proveedores de diferentes servicios de apoyo al proceso de negocio,
proveedores de software.

164
En conclusión, se realizó un análisis y un diseño completo para un Sistema de Información
que pudiera administrar fotografías aéreas, utilizando una arquitectura orientada a
servicios.

Para el tercer objetivo, “Definir y organizar la ejecución del proceso de negocio

apoyándose en las tecnologías disponibles en el mercado para tal fin”
Las definiciones en la ejecución hacen referencia a la nomenclatura de subprocesos,
actividades y especificación de servicios así como de compuertas de decisión en el flujo
de trabajo, mientras que la organización de la ejecución del proceso se halla en la
secuencia de las actividades y la reutilización desde el punto de vista de los servicios, esto
permitió el diseño dentro del concepto administrativo de eficiencia.
Las tecnologías disponibles no siempre son tecnologías utilizables dentro de la concepción
inicial del proyecto, debido a los inconvenientes hallados con licencias en Bizagi para la
utilización de componentes que permitieran la verificación y realización de las secuencias
del proceso en un navegador de internet. La disponibilidad de tecnologías no fue evaluada
y la opción de BonitaBPM fue elegida sin ser contrastada con otras suites, principalmente
por el aspecto de ser software libre.

En el cuarto objetivo, “Exponer el proceso de negocio diseñado como un servicio

sobre internet con el fin de hacerlo visible para consumo de los usuarios”.
La exposición del proceso se realizó en el navegador Mozilla-Firefox en una red local, no
como servicio web pero a nivel de localhost, en donde pueden apreciarse las
funcionalidades diseñadas. Con ajustes como las conexiones a bases de datos, el servicio
de hosting, los cálculos de precios y puntos, el prototipo propuesto podría ponerse en
producción completándolo con otras características menores.

La aproximación a este objetivo aclaró las implicaciones tecnológicas de un Sistema de

Información Geográfico que usa conceptos y herramientas de SOA. Estas implicaciones
se convirtieron en criterios de evaluación para el establecimiento definitivo del título de la
tesis de acuerdo al concepto del jurado evaluador.

8.3. Trabajo Futuro.

Los casos de uso seguirán siendo una herramienta poderosa en el diseño de sistemas de
información, su utilidad permanece y trasciende hasta la etapa de descubrimiento de

165
servicios y los matices como por ejemplo el caso de uso de negocio o el caso de uso de
sistema, ayudan en la identificación de áreas funcionales. Por esto queda siempre abierta
la posibilidad de refinar los casos de uso para futuras implementaciones del sistema.
La Inteligencia Artificial y el empleo de alguno de sus paradigmas como redes neuronales,
algoritmos genéticos, sistemas de lógica difusa, autómatas programables o varios a la vez
en un híbrido de éstos, aplicados a la inteligencia de negocios y más específicamente a la
Inteligencia de Negocios Geoespacial (Badard, y otros, 2012) para los procesos y eventos
de negocios, son las perspectivas obvias de continuación del trabajo iniciado. Además, los
adelantos en las interfaces holográficas o realidad virtual en los dispositivos móviles harán
de la información geográfica detallada un aspecto más de la realidad, lo que ya se conoce
como realidad aumentada.
Futuras mejoras exigen recurso suficiente para que el sistema pueda comunicarse con
otros sistemas a través de servicios que también usen información geográfica y datos
comerciales, para aprovechar las tecnologías en automatización de procesos y
orquestación de servicios. En estos términos el servicio y la profundización de sus alcances
es un tema en el que se debe ahondar en una futura implementación mejorada.

166
Referencias Bibliográficas.
Aerocivil. (2014). Reglamentos Aeronáuticos De Colombia. Rac4. Obtenido de Normas
De Aeronavegabilidad Y Operación De Aeronaves: http://www.aerocivil.gov.co/

Alameh, N. (2003). Service Chaining of Interoperable Geographic Information Web

Services. IEEE Internet Computing, Vol. 7, No. 5, 22-29.

Alameh, N. (2007). GIS Web Services Evolution and Impact on Urban and Regional
Information Systems. Global Science & Technology, 3.

Arsanjani, A., Ghosh, S., Allam, A., Abdollah, T., Ganapathy, S., & Holley, K. (2008).
SOMA: A Method For Developing Service-Oriented Solutions Vol 47. IBM
Systems Journal, 385.

Aydin, G. (2007). Service Oriented Architecture For Geographic Information Systems

Supporting Real Time Data Grids. Indiana: Indiana University.

Badard, T., Kadillak, M., Percivall, G., Ramage, S., Reed, C., Sanderson, M., . . .
Vaillancourt, V. (2012). Open Geospatial Consortium (OGC) White Paper
Geospatial Business Intelligence (GeoBI). OGC.

Broecke, J. (06 de 09 de 2013). Slideshare. Obtenido de The Heron Mapping Client -

Overview, Functions, Concepts: http://es.slideshare.net/justb4/the-heron.

Bruegge, B., & Dutoit, A. (2005). Object Oriented Software Engineering. Mexico: Pearson
Prentice Hall Education Inc.

Bussines Rules Group. (2016). Defining Business Rules... Obtenido de Bussines Rules
Group: http://www.businessrulesgroup.org/defnbrg.shtml.

Carrillo, G. (2012). Geotux Website:. Obtenido de Comparación de Clientes Web de

Servicios Web Geográficos V.6.: http://geotux.tuxfamily.org/index.php/geo-
blogs/item/291-comparacion-clientes-web-v6

Chen, S., Osman, M., Nunes, J., & Peng, G. (2011). Information Systems Evaluation
Methodologies. Information Systems Research Trends, Approaches And
Methodologies (ISRTAM), 5.

Clarke, A. H. (1999). Evaluation Research: An Introduction To Principles, Methods And

Practice. California.

Cobb, D., & Olivero, A. (1997). Online Gis Service. The Journal Of Academic
Librarianship. Harvard Map Collection, Harvard University, Cambridge,
Massachusetts, 485.

Cockburn, A. (2000). Writing Effective Use Cases. New Jersey: Pearson.

167
Codd, E. F. (1970). A Relational Model Of Data For Large Shared Data Banks.
Communications of the AMC, 385.

Colomina, I., & Molina, I. (2014). Unmanned aerial systems for photogrammetry and
remote sensing: A Review. ISPRS Journal of Photogrammetry and Remote
Sensing, 94.

Cotroneo, D., Di Flora, C., & Russo, S. (2002). An Enhanced Service Oriented
Architecture For Developing Web-Based Applications. Journal Of Web
Engineering, 128.

Davenport, T. (1993). Selecting Processes for Innovation. En T. Davenport, Process

Innovation: Reengineering Work Through Information Technology. (pág. 33).
Boston, Ma: Harvard Business School Press.

Dumas, M., Van Der Aalst , W., & H. M. ter Hofstede, A. (2005). Process-Aware
Information Systems. New Jersey: Wiley Interscience.

García Molina, J., Ortín, M., Moros Valle, B., & Toval Álvarez, J. (2007). De los Procesos
de Negocio a los Casos De Uso,. Técnica administrativa, ISSN-e 1666-1680, Vol.
6, Nº. 32.

Garlan, D., & Shaw, M. (1993). An Introduction to Software Architecture. New Jersey:
Publishing Company.

Gobierno en Línea. (2012). Guía Para La Apertura De Datos En Colombia. Colombia:

Ministerio de Tecnologías de La Información y las Comunicaciones.

Gonzáles , P., Gonzáles, A. A., & Gallud, J. A. (2011). Herramientas Case ¿Cómo
Incorporarlas con Éxito en Nuestra Organización? Revista de la Facultad de
Educación de Albacete, ISSN 0214-4824, Nº. 10.

Goodchild, M. (1989). Geographic information systems and market research. Papers and
Proceedings of Applied Geography Conferences (Vol. 12,)., 1-8.

Güner, S. (2005). Architectural Approaches, Concepts and Methodologies of Service

Oriented Architecture. Hamburgo, Alemania: Software System Institute.

Guo , L., Gong, J., Sun, J., & Wei, X. (2010). Study On Gis Architecture Based On Soa
And RIA. In Information Sciences and Interaction Sciences (ICIS), 620-625.

Holling, ,. C., Gunderson, L., & Ludwig, D. (2002). Panarchy: Understanding

transformations in human and natural systems. Washington, D.C.: Island press.

Hook, G. (2011). Business Process Modeling and Simulation. Proceedings of the 2011
Winter Simulation Conference, 774.

Hurwitz, J., Bloor, R., Baroudi, C., & Kaufman, M. (2007). Service Oriented Architecture
For Dummies. New Jersey: Wiley Publishing, Inc.

168
IBM. (06 de 09 de 2000). Web Services Architecture Overview . Obtenido de IBM
Developer Works: http://www.ibm.com/developerworks/library/w-ovr/

IBM. (2008). Chapter 4. A Methodology For Service Modeling And Design. En N.

Bieberstein, R. G. Laird, K. Jones, & T. Mitra, Executing SOA: A Practical Guide
For The Service-Oriented Architect. (págs. 3-66). New Jersey: IBM Press.

IBM. (2009). Business Process. Obtenido de IBM Knowledge Center:

Https://Www.Ibm.Com/Support/Knowledgecenter/Ssqqfk_6.2.0/Com.Ibm.Wbit.620
.Help.Bpel.Ui.Doc/Concepts/Cunder.Html

IBM. (2009). Business Rules. Obtenido de IBM Knowledge Center:

http://www.ibm.com/support/knowledgecenter/es/ssfpjs_8.5.7/com.ibm.wbpm.wid.
bpel.doc/busrules/topics/cundbus.html

IBM. (2010 ). Using Rosettanet Version 7.0. Sterling Standards Library, 2-10.

IBM. (29 de 07 de 2011). Modelado de SOA: Parte 1. Identificación del servicio. Obtenido
de IBM developerWorks:
http://www.ibm.com/developerworks/ssa/rational/library/07/1002_amsden/

IEEE. (2000). IEEE Recommended Practice for Architectural Description of Software-

Intensive Systems. New York, USA: Software Engineering Standards Committee.

Josuttis, N. (2007). SOA In Practice. Sebastopol: O’reilly Media.

Kim, J., & Lim, K. (2007). An Approach to Service-Oriented Architecture Using Web
Service and BPM in the Telecom-OSS Domain. Internet Research, Vol. 17 No. 1, ,
99-107.

Koontz, H., & Weihrich, H. (2004). Administración Una Perspectiva Global. México:
Mcgraw-Hill Interamericana.

Lo Chong, P., & Yeung, A. ((2007). Concepts and Techniques of Geographic Information
Systems. New Jersey: Prentice Hall.

Mangina, E. (2005). Intelligent Agent-Based Monitoring Platform for. International Journal

of Computer Science & Applications, 38-48.

Mayer, C. (09 de 05 de 2014). InnoDB and the ACID Model . Obtenido de 14.2 InnoDB
and the ACID Model: https://dev.mysql.com/doc/refman/5.6/en/mysql-acid.html

Montaldo, D. (2005). Tesis de Grado en Ingeniería en Informática. Patrones de Diseño

De Arquitecturas De Software Enterprise. Buenos Aires, Argentina: Departamento
De Computación Facultad De Ingeniería Universidad De Buenos Aires.

OASIS. (2003). Business-Centric Methodology Specification. Version 0.10. OASIS BCM

Technical Committee, 13.

169
OASIS. (2012). Reference Architecture Foundation for Service Oriented Architecture
Version 1.0. Committee Specification 01.

OMG. (2011). Business Process Model and Notation (BPMN). Standard document URL:
http://www.omg.org/spec/BPMN/2.0.

Oyola Lepe, N. (2009). Identificación de Humedales del Norte Grande de Chile Utilizando
Técnicas Geomáticas en Imágenes Satelitales Landsat. Santiago : Universidad de
Chile Facultad De Ciencias Forestales y Conservación de la Naturaleza.

Pascaul, M., Alves, E., De Almeida, T., Holanda, M., Sand de França, G., & Henrique, R.
(2012). An Architecture For Geographic Information Systems On The Web. The
Fourth International Conference on Advanced Geographic Information Systems,
Applications, and Services, 176.

Pavlovič, J. (2009). Process-Oriented Modeling and Infrastructure for Remedial Decision

Support System. Brno, R Checa: Masaryk University, Faculty of Informatics.

Pressman, R. (2010). Software Engineering: A Practitioner’s Approach 7th Ed. New York:
Mcgraw-Hill.

Radhakrishnan, R. (2004). Model Driven Architecture Enabling Service Oriented

Architecture. Sun Micro Systems.

Rational Software Corporation. (2011). Best Practices for Software Development Teams.
Rational Unified Process.

Reinhardt, W. (2000). Principles And Application Of Geographic Information Systems And

Internet/Intranet Technology. Neubiberg, Alemania: Institute For Geo Information
And Land Development Werner-Heisenberg-Weg.

Romagnano, M., Gomez, M., & De Luca, A. (2010). Contribución de la Ingeniería de

Software al Modelado de Procesos de Educación a Distancia. Workshop de
Investigadores en Ciencias de la Computación.

Ropero, J. (2006). Diseño de un Agente Inteligente Web basado en técnicas de

Inteligencia Artificial. Sevilla, España: Departamento de Tecnología Electrónica,
Universidad de Sevilla.

Saleh, M., Yaghoobi, T., & Faraahi, A. (2012). Suitability of Service Oriented Architecture
for Solving GIS Problems. International Journal Of Advanced Information
Technology (IJAIT) Vol. 2, 2.

Schutzberg, A. (17 de 02 de 2011). Nosql Databases: What Geospatial Users Need To

Know. Obtenido de Directrions Magazine:
http://www.directionsmag.com/entry/nosql-databases-what-geospatial-users-need-
to-know/164635

170
Scriven, M. (1967). The Methodology Of Evaluation. Chicago: AERA Monograph Series
on Curriculum Evaluation.

Smith, M., & Collock, P. (1999). Communities In Cyberspace. New York: Routledge
Press.

SOA Alliance Group of SOA Practitioners. (2006). SOA Blueprint - Reference Architecture
Version 1.1 . 15.

Sommervile, I. (2005). Ingenieria Del Software 7ª Edición. Madrid, España.: Pearson

Educación S.A.

Tiwari, S. (2011). Profesional Nosql. Indianapolis: John Wiley & Sons, Inc.

Tsou, M., Guo, L., & Stow, D. (2003). Web-Based Remote Sensing Applications And Java
Tools For Environmental Monitoring. Obtenido de Online Journal of Space
Communication: http://www.spacejournal.ohio.edu/pdf/tsou.pdf

UCONN. (6 de 06 de 2016). Map and Geographic Information Center. Obtenido de

University Libraries: magic.lib.uconn.edu/mash_up/aerial_index.html

UN/CEFACT. (2011). UN/CEFACT Modeling Methodology (UMM) User Guide. 13.

W3C. (14 de 02 de 2004). Web Services Architecture. Obtenido de W3C Working Draft :
https://www.w3.org/TR/ws-arch/#whatis

Weitzenfeld, A. (2005). Ingeniería de Software Orientada a Objetos con Java UML e

Internet. México.: International Thoso.

Xu, L. D. (2011). Enterprise Systems: State-Of-The-Art And Future Trends. IEEE

Transactions on Industrial Informatics, Vol. 7, 15.

171
 Anexos.
Ésta sección corresponde al código SQL generado para cargar la base de datos en
PostgreSQL y el código modificado de la aplicación del lado del cliente HeronMC, estos
archivos llamados “base_de_datos_prototipo” que es un archivo de texto restaurable en
PostgreSQL y una carpeta llamada “Visor HeronMC” que contiene los archivos del visor,
son incluidos en un disco compacto adjunto al documento impreso y en repositotios de la
biblioteca de la Universidad Nacional.

En cuanto al proceso de negocio, se suministra el archivo Proceso Prototipo-1.0.bos que

es la compresión de los archivos necesarios para cargar los diagramas proporcionados en
lenguaje estándar, el modelo de datos de negocio (bdm), la página web, los formularios, y
los widgets empleados por la aplicación Bonita BPM Community 7.2.3.

Adicionalmente es proporcionado un video descriptivo llamado “Video_Prototipo” que

evidencia la implementación en una intranet ad-hoc a través de los puertos mencionados
en el capítulo de implementación en localhost.

Para la correcta ejecución del prototipo en cualquier máquina, se necesitan instalados y

configurados: la base de datos instalada en PostgreSQL con las extensión PostGIS, las
instalaciones de Apache2, Tomcat, Bonita BPM, las librerías de HeronMC, Geoserver y su
conexión con las bases de datos .

172
 Glosario

2PC: (Two Phase Commit): Una aproximación para mantener la consistencia entre
múltiples sistemas. En la primera fase, se pide a todos los back-ends confirmar un cambio
solicitado de manera que en la segunda fase la comisión de las actualizaciones por lo
general tiene éxito. De conformidad con los principios de bajo acoplamiento, en SOA
compensación se utiliza generalmente en lugar de 2PC.

ACID: Atomicity, Consistency, Isolation, Durability: Atomicidad, Consistencia, Aislamiento,

Durabilidad. En bases de datos se denomina ACID a las características de los parámetros
que permiten clasificar las transacciones de los sistemas de gestión de bases de datos.
Cuando se dice que es ACID compliant se indica -en diversos grados- que éste permite
realizar transacciones.

ACORD: Association for Cooperative Operations Research and Development.Asociación

para el Desarrollo e Investigación de Operaciones Cooperativas, provee estándares de
datos para seguros junto con IAA.

Backend: Un sistema que mantiene los datos y/o reglas de negocio de un dominio
específico. Por lo general, proporciona un rol específico o tiene una responsabilidad
específica en un entorno de sistema. En SOA, un back-end normalmente está envuelto por
algunos servicios básicos.

BASE: Basically Available, Soft state, Eventual consistency. Básicamente Disponible,

Transigente, Consistencia eventual. Puede explicarse en contraste con otra filosofía de
diseño - ACID. El modelo ACID promueve la consistencia sobre la disponibilidad, mientras
que BASE promueve la disponibilidad sobre la consistencia.

BCM: Business-Centric Methodology. Metodología Centrada en el Negocio (OASIS)

desarrolla una especificación que proporcionará a los gerentes de negocios un conjunto
de métodos claramente definidos para adquirir sistemas de información e-business ágiles
e interoperables dentro de las comunidades de intereses.

BPM: Business Process Management. Administración de Procesos de Negocio. La

Gestión de Procesos de Negocio es una metodología corporativa y disciplina de gestión,
cuyo objetivo es mejorar el desempeño (eficiencia y eficacia) y la optimización de los
procesos de negocio de una organización, a través de la gestión de los procesos que se
deben diseñar, modelar, organizar, documentar y optimizar de forma continua. Por lo tanto,
puede ser descrito como un proceso de optimización de procesos.

BPMN: Business Process Modeling Notation. Ver sección 2.1.5. BPMN.

CAP: Consistency, Availability, Partition tolerance. Consistencia, Disponibilidad,

Tolerancia al particionado. En Ciencias de la computación, el teorema CAP, también

173
llamado Teorema de Brewer, enuncia que es imposible para un sistema de cómputo
distribuido garantizar simultáneamente:
 Consistencia, es decir, que todos los nodos vean la misma información al mismo tiempo.
 Disponibilidad, es decir, la garantía de que cada petición a un nodo reciba una
confirmación de si ha sido o no resuelta satisfactoriamente.
 Tolerancia al particionado (Partition Tolerance), es decir, el sistema sigue funcionado
incluso si algunos nodos fallan.

Compensación: Una aproximación para mantener la consistencia entre múltiples

sistemas. En contraste con 2PC, compensación no actualiza todos los back-ends de forma
síncrona, en vez de esto define actividades de compensación que son realizadas en el
evento de que no todas las actualizaciones correspondientes de diferentes sistemas sean
efectuadas

Comunicación asíncrona: Forma de comunicación en la que existe un intervalo de

tiempo medible entre el envío y la recepción del contenido de cualquier mensaje. El
middleware orientado a mensajes - MOM se implementa típicamente basándose en este
concepto introduciendo colas de mensajes que envían mensajes de cola (persistencia) por
un sistema hasta que son aceptados por el sistema o sistemas receptores. La
comunicación asíncrona es una forma de bajo acoplamiento porque evita el requisito de
que el remitente y el receptor de un mensaje deben estar disponibles al mismo tiempo.

CORBA: Common Object Request Broker Architecture. Es un estándar definido por Object
Management Group (OMG) que permite que diversos componentes de software escritos
en múltiples lenguajes de programación y que corren en diferentes computadoras, puedan
trabajar juntos; es decir, facilita el desarrollo de aplicaciones distribuidas en entornos
heterogéneos, permite acceso remoto a objetos de diferentes plataformas. Aunque su
propósito inicial era proveer acceso remoto a objetos distribuidos, CORBA puede ser usado
como una infraestructura de SOA enfocándose en su concepto de Objeto por Valor.

Coreografía: Una forma de agregar servicios en procesos de negocio, en contraste con la

orquestación la coreografía no hace una composición de servicios en uno nuevo que tiene
el control central sobre todo el proceso. En vez de esto define reglas y políticas que
habilitan la colaboración de diferentes servicios para formar un proceso de negocio.

CRUD: Create, Retrieve, Update, Delete. Es el acrónimo de "Crear, Leer, Actualizar y

Borrar" se usa para referirse a las funciones básicas en bases de datos o la capa de
persistencia en un software.

CSS: Cascading Style Sheets. Hoja de Estilos en Cascada es el lenguaje utilizado para
describir la presentación de documentos HTML o XML, esto incluye varios lenguajes
basados en XML como son XHTML o SVG. CSS describe como debe ser renderizado el
elemento estructurado en pantalla, en papel, hablado o en otros medios

DEM: (Digital Elevation Model) Modelo Digital de Elevación se refiere a la superficie de la

tierra e incluye todos los objetos que esta contiene.

174
DTM: (Digital Terrain Model) Modelo Digital de Terreno representa la superficie de suelo
desnudo y sin ningún objeto, como la vegetación o los edificios

EAI: Integración de aplicaciones empresariales, un enfoque para integrar sistemas

distribuidos de tal manera que usan una infraestructura común (middleware y/o protocolo).
Para cada sistema es suficiente proporcionar y mantener sólo un adaptador a la
infraestructura, en lugar de un adaptador específico para cada uno de los sistemas con los
que se comunica. La infraestructura podría usar un enfoque de bus o hub y spoke. SOA
puede describirse como una extensión de EAI donde EAI proporciona el aspecto técnico
de interoperabilidad. Por esta razón, los conceptos de EAI pueden considerarse como un
bus de servicios empresariales.

ESB: Enterprise Service Bus, es la infraestructura de una SOA que habilita la

interoperabilidad de servicios. Su principal tarea es proveer conectividad, transformaciones
de datos y ruteo inteligente de manera que los sistemas puedan comunicarse vía servicio.

Escalabilidad: Propiedad deseable de un sistema, una red o un proceso, que indica su

habilidad para reaccionar y adaptarse sin perder calidad, o bien manejar el crecimiento
continuo de trabajo de manera fluida, o bien para estar preparado para hacerse más
grande sin perder calidad en los servicios ofrecidos.

Front-End: Un sistema que inicia y controla los procesos de negocio llamando a los
servicios necesarios. Es decir, actúa como un consumidor de servicios. Puede ser un
sistema con interacción humana o un programa por lotes.

Granularidad: Representa la funcionalidad encapsulada por un servicio:

• Granularidad fina encapsula una pequeña pieza de funcionalidad básica.
• Granularidad gruesa normalmente encapsula una funcionalidad de nivel superior.

GSD: Ground Sample Data, distancia entre los centros de dos pixeles adyacentes

HTML: HiperText Mark-up Language. Lenguaje de Marcas de Hipertexto. Es el lenguaje

de marcado estándar para crear páginas web y aplicaciones web. Con CSS y JavaScript,
forma una tríada de tecnologías de piedra angular para la World Wide Web. Los
navegadores web reciben documentos HTML desde un servidor web o desde un
almacenamiento local y los convierten en páginas web multimedia. HTML describe la
estructura de una página web semánticamente y originalmente incluía indicaciones para la
apariencia del documento.

HTTP: Hypertext Transfer Protocol Protocolo de Transferencia de Hipertexto. Es un

protocolo de aplicación para sistemas de información distribuidos, colaborativos e
hipermedia. HTTP es la base de la comunicación de datos para la World Wide Web. El
hipertexto es un texto estructurado que utiliza enlaces lógicos (hipervínculos) entre nodos
que contienen texto. HTTP es el protocolo para intercambiar o transferir hipertexto.

HTTPD: HTTP Daemon es un programa de software que se ejecuta en el fondo

(background) de un servidor web y espera las solicitudes de servidor entrantes. El daemon

175
responde a la solicitud automáticamente y sirve los documentos de hipertexto y multimedia
a través de Internet mediante HTTP.

IAA: Insurance Application Architecture. Arquitectura de Aplicaciones de Seguros. Ver

ACORD.

IDEF: Integrated DEFinition Definición Integrada Se refiere a una familia de lenguajes de

modelado en el campo de los sistemas y la ingeniería de software. Cubren una amplia
gama de usos, desde modelado funcional hasta datos, simulación, análisis/diseño
orientado a objetos y adquisición de conocimiento. Estos "lenguajes de definición" se
desarrollaron bajo el patrocinio de la Fuerza Aérea de los Estados Unidos y aunque todavía
son los más usados por ellos, así como otras agencias militares y del Departamento de
Defensa de Estados Unidos (DoD), son de dominio público.

Idempotencia: Propiedad de realizar una acción varias veces y conseguir siempre el

mismo resultado, en el contexto de los servicios, esto significa que múltiples
entregas/procesamientos de llamadas de servicio idénticos causan el mismo resultado.

Interoperabilidad: Habilidad de diferentes sistemas de comunicarse entre sí.

IMU: (del inglés inertial measurement unit) unidad de medición inercial es el componente
principal de los sistemas de navegación inercial usados en aviones, naves espaciales,
buques y misiles guiados entre otros. En este uso, los datos recolectados por los sensores
de una IMU permiten a un computador seguir la posición del aparato, usando un método
conocido como navegación por estima.

IT: Information Technologies La tecnología de la información (TI) es la aplicación de

ordenadores para almacenar, estudiar, recuperar, transmitir y manipular datos o
información, a menudo en el contexto de una empresa u otra empresa. Se considera un
subconjunto de la tecnología de la información y las comunicaciones (TIC).

IVR: Interactive Voice Response. Respuesta de Voz Interactiva consiste en un sistema

telefónico que es capaz de recibir una llamada e interactuar con el humano a través de
grabaciones de voz y el reconocimiento de respuestas simples, como «sí», «no» u otras.

JXDD: Justice XML Data Dictionary. Diccionario de Datos XML de Justicia provee
estándares de datos para información judicial.

KML: Keyhole Mark-up Language. Es un lenguaje de marcado basado en XML para

representar datos geográficos en tres dimensiones. Fue desarrollado para ser manejado
con Keyhole LT, precursor de Google Earth (Google adquirió Keyhole LT en octubre de
2004 tras lanzar su versión LT 2). Su gramática contiene muchas similitudes con la de
GML.

Latencia: En los círculos de desempeño de la web, es la cantidad de tiempo que toma al

servidor recibir y procesar una solicitud de un objeto de página. La cantidad de latencia
depende en gran medida de lo lejos que el usuario se encuentra desde el servidor.

176
LBS: Localization Based Services. Servicios Basados en Localización buscan ofrecer un
servicio personalizado a los usuarios basándose en la mayoría de situaciones en
información de ubicación geográfica de estos. Estos servicios son capaces de entregar la
información geográfica y geoprocesamiento de los usuarios móviles con base en su
ubicación actual.

LIDAR: Laser Imaging Detection and Raging, Detección de Imágenes Laser y

Distanciómetro. Es un dispositivo que permite determinar la distancia desde un emisor
láser a un objeto o superficie utilizando un haz láser pulsado. La distancia al objeto se
determina midiendo el tiempo de retraso entre la emisión del pulso y su detección a través
de la señal reflejada. En general, la tecnología tiene aplicaciones en geología, sismología
y física de la atmósfera.

Middleware: Software que asiste a una aplicación para interactuar o comunicarse con
otras aplicaciones, o paquetes de programas, redes, hardware y/o sistemas operativos.
Éste simplifica el trabajo de los programadores en la compleja tarea de generar las
conexiones y sincronizaciones que son necesarias en los sistemas distribuidos.

MOM: Message Oriented Middleware. Middleware Orientado a Mensajes Es la

infraestructura de software o hardware que soporta enviar y recibir mensajes entre
sistemas distribuidos. MOM permite distribuir módulos de aplicación sobre plataformas
heterogéneas y reduce la complejidad de desarrollar aplicaciones que abarcan múltiples
sistemas operativos y protocolos de red.

NoSQL: Not Only SQL. No solo SQL es una amplia clase de sistemas de gestión de bases
de datos que difieren del modelo clásico de SGBDR (Sistema de Gestión de Bases de
Datos Relacionales) en aspectos importantes, siendo el más destacado que no usan SQL
como lenguaje principal de consultas

OGC: Open Geospatial Consortium. Consorcio Geoespacial Abierto es una organización

internacional sin fines de lucro comprometida con la creación de estándares abiertos de
calidad para la comunidad geoespacial global. Estos estándares se hacen a través de un
proceso de consenso y están disponibles libremente para que todos los usen para mejorar
el intercambio de los datos geoespaciales del mundo.

ORB: Agente de Peticiones a Objetos. En Computación distribuida, el nombre que recibe

una capa de software (también llamada middleware) que permite a los objetos realizar
llamadas a métodos situados en máquinas remotas, a través de una red. Maneja
transferencia de estructuras de datos, para que sean compatibles entre los dos objetos.

Orquestación: Una forma de agregar servicios en procesos de negocio, en contraste con

la coreografía la orquestación compone servicios en un nuevo servicio que tiene el control
sobre todo el proceso.

REST: Representational State Transfer. Transferencia de Estado Representacional es un

estilo de arquitectura software para sistemas hipermedia distribuidos como la World Wide
Web. Ha pasado a ser ampliamente utilizado por la comunidad de desarrollo. Forma de

177
proporcionar interoperabilidad entre los sistemas informáticos en Internet. Los servicios
Web compatibles con REST permiten a los sistemas solicitantes acceder y manipular
representaciones textuales de recursos Web utilizando un conjunto uniforme y predefinido
de operaciones sin estado.

RMI: Remote Method Invocation: Método de Invocación Remota es un mecanismo ofrecido

por Java para invocar un método de manera remota. Forma parte del entorno estándar de
ejecución de Java y proporciona un mecanismo simple para la comunicación de servidores
en aplicaciones distribuidas basadas exclusivamente en Java. Si se requiere comunicación
entre otras tecnologías debe utilizarse CORBA o SOAP en lugar de RMI.

RPC: Remote Procedure Call. Llamada a Procedimiento Remoto es un programa que

utiliza una computadora para ejecutar código en otra máquina remota sin tener que
preocuparse por las comunicaciones entre ambas. El protocolo que se utiliza para esta
llamada es un gran avance sobre los sockets de Internet usados hasta el momento. De
esta manera el programador no tenía que estar pendiente de las comunicaciones, estando
estas encapsuladas dentro de las RPC.

RUP: Rational Unified Process. Proceso Unificado de la compañía Rational es un proceso

de desarrollo de software desarrollado por la empresa Rational Software, actualmente
propiedad de IBM.1 Junto con el Lenguaje Unificado de Modelado (UML), constituye la
metodología estándar más utilizada para el análisis, diseño, implementación y
documentación de sistemas orientados a objetos.

SDLC: Software Development Life Cycle. Ciclo de Vida del Desarrollo de Software. Ver
sección 2.1.3 Metodologías Empleadas

SIG: Sistema de Información Geográfica es un conjunto de herramientas que integra y

relaciona diversos componentes (usuarios, hardware, software, procesos) que permiten la
organización, almacenamiento, manipulación, análisis y modelización de grandes
cantidades de datos procedentes del mundo real que están vinculados a una referencia
espacial, facilitando la incorporación de aspectos sociales-culturales, económicos y
ambientales que conducen a la toma de decisiones de una manera más eficaz.

SLD: Style Layer Descriptor. Descriptor de Estilos de Capas. Define una codificación que
extiende el estándar WMS para permitir la simbolización y coloración definida por el usuario
de la característica geográfica y la cobertura [http://www.opengeospatial.org/ogc / Glossary
/ c] datos. SLD aborda la necesidad de que los usuarios y el software sean capaces de
controlar la representación visual de los datos geoespaciales. La capacidad de definir
reglas de estilo requiere un lenguaje de estilo que el cliente y el servidor puedan entender.

SLT: Services Litmus Tests. Pruebas de Tornasol para Servicios. Ver sección 5.4.1.2.
Especificación de Servicios.

SOA: Service Oriented Architecture Arquitectura Orientada a Servicios. Ver sección 2.1.1.
Arquitectura Orientada a Servicios.

178
SOAP: Simple Object Access Protocol. Protocolo de Acceso a Objeto Simple Es una
especificación de protocolo para el intercambio de información estructurada en la
implementación de servicios web en redes informáticas. Su propósito es inducir
extensibilidad, neutralidad e independencia. Utiliza el conjunto de información XML para
su formato de mensaje y se basa en protocolos de capa de aplicación, generalmente
Protocolo de transferencia de hipertexto (HTTP) o Protocolo simple de transferencia de
correo (SMTP), para la negociación y transmisión de mensajes.

SOMA: Service Oriented Modelling and Architecture Modelado y Arquitectura Orientados

a Servicios. Ver sección 2.1.3 Metodologías Empleadas.

SQL: Structured Query Language. Lenguaje Estructurado de Consultas. SQL es un

lenguaje estándar para acceder a bases de datos y gestionar bases de datos relacionales
que permite especificar diversos tipos de operaciones en ellos.

Stateless: (carencia de estado). Conceptualmente un servicio sin estado es un servicio

que no mantiene ningún estado entre diferentes llamadas de servicio. Es decir, después
de la llamada de servicio termina, todas las variables locales y los objetos que se han
creado temporalmente para ejecutar el servicio se eliminan. Estamos hablando de los
datos del servicio en sí, que no son ni el proceso o aplicación que llama al servicio, ni
sistema(s) de operación del servicio. El servicio es sin estado cuando todos los datos de
la instancia de servicio (proceso o subproceso) que realiza la llamada se desechan
después de la llamada.

UAV: Unmanned Aerial Vehicle (Drone). Vehículo Aéreo no Tripulado (Dron) es una
aeronave que vuela sin tripulación. Aunque hay VANT de uso civil, también son usados en
aplicaciones militares, donde son denominados vehículo aéreo de combate no tripulado.

UDDI: Universal Description, Discovery and Integration. Descripción, Descubrimiento e

Integración Universal. Siglas del catálogo de negocios de Internet que se hace en XML.
UDDI es una iniciativa industrial abierta de OASIS, entroncada en el contexto de los
servicios Web. El registro de un negocio en UDDI tiene tres partes: (i) Páginas blancas -
dirección, contacto y otros identificadores conocidos. (ii) Páginas amarillas - categorización
industrial basada en taxonomías. (iii) Páginas verdes - información técnica sobre los
servicios que aportan las propias empresas. UDDI es uno de los estándares básicos de los
servicios Web cuyo objetivo es ser accedido por los mensajes SOAP y dar paso a
documentos WSDL, en los que se describen los requisitos del protocolo y los formatos del
mensaje solicitado para interactuar con los servicios Web del catálogo de registros.

UML: Unified Modelling Language. Lenguaje Modelamiento Unificado es un lenguaje

gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un
estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales
tales como procesos, funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

179
WCS: Web Coverage Service. Servicio Web de Coberturas. Interfaz estándar que permite
realizar peticiones de cobertura geográfica a través de la web utilizando llamadas
independientes de la plataforma. Las coberturas son objetos (o imágenes) en un área
geográfica mientras que la interfaz WMS o portales de mapas online como Google Maps
devuelven sólo una imagen, que los usuarios no pueden editar o analizar espacialmente.

WFS-T: Web Feature Service - Transactional. Servicio Web de Capa Vectorial

Transaccional. El Servicio Web básico de objetos espaciales permite la consulta y
recuperación de elementos espaciales. Un servicio de objetos espaciales Web
transaccional (WFS-T) permite la creación, eliminación y actualización de funciones.

WML: Wireless Mark-up Language. Lenguaje de Etiquetas para dispositivos Inalámbricos.

Es un lenguaje de marcado destinado a dispositivos que implementan la especificación
WAP (Wireless Application Protocol), como los teléfonos móviles.

WMS: Web Map Service. Servicio Web de Mapas. Este estándar internacional define un
"mapa" como una representación de la información geográfica en forma de un archivo de
imagen digital conveniente para la exhibición en una pantalla de ordenador. Los mapas
producidos por WMS se generan normalmente en un formato de imagen como PNG, GIF
o JPEG, y opcionalmente como gráficos vectoriales en formato SVG (Scalable Vector
Graphics) o WebCGM (Web Computer Graphics Metafile). El estándar define tres
operaciones: Devolver metadatos del nivel de servicio, devolver un mapa con parámetros
geográficos y dimensionales bien definidos, devolver información de características
particulares mostradas en el mapa (opcionales).

Workflow: Flujo de trabajo. Similar a un proceso de negocio, una descripción de

actividades o tareas que tienen que hacerse para satisfacer una determinada necesidad
de negocio. Algunas personas diferencian flujos de trabajo y procesos de negocio al afirmar
que procesos de negocio describen de manera más general lo que se debe hacer mientras
los flujos de trabajo describen cómo se deben llevar a cabo las actividades o las tareas.

WSDL: Lenguaje de Descripción de Servicios Web es un formato XML que se utiliza para
describir servicios web (WS), recomendado por el W3C. WSDL describe la interfaz pública
a los servicios Web y la forma de comunicación, es decir, los requisitos del protocolo y los
formatos de los mensajes necesarios para interactuar con los servicios listados en su
catálogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan
después al protocolo concreto de red y al formato del mensaje.

XML: eXtensible Mark-up Language Lenguaje de Marcas Extensible es un meta-lenguaje

que permite definir lenguajes de marcas desarrollado por el World Wide Web Consortium
(W3C) utilizado para almacenar datos en forma legible. Proviene del lenguaje SGML y
permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a
su vez un lenguaje definido por SGML) para estructurar documentos grandes. A diferencia
de otros lenguajes, XML da soporte a bases de datos, siendo útil cuando varias
aplicaciones deben comunicarse entre sí o integrar información.

180