Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
Magister en Geomática
Directora:
Ph.D. Helga Duarte Amaya
Línea de Investigación:
Tecnologías Geoespaciales
Bogotá, Colombia
2017
2
(Dedicatoria o lema)
3
Agradecimientos.
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.
Palabras clave:
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 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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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
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:
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:
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).
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.
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.
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.
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.
Tomado de: Government's Adoption of SOA and SOA Examples Presented by: Ajay Budhraja,
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 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).
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).
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).
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.
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).
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.
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.
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.
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).
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.
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.
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.
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.
Desempeño Se necesitan procesar imágenes en formato ráster en extensiones PNG, JPG, Geo
TIFF y SVG.
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.
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.
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.
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.
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.
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).
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:
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):
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
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).
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.
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ó.
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.
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.
66
Ilustración 5 Diagrama de casos de uso en ArgoUML
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.
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.
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
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).
crea Operador
técnico
Cliente asesora
Jefe técnico
tiene Cuenta
Área
Área Idarea ID Prod
procesa
Área de Producto
contiene
Interés Geográfico
Operador
técnico
crea
cedula nombre
Cliente cargo
asesora
especialidad
fecha ID Cuenta
NumFactura
70
Ilustración 8 Modelo Físico del Sistema Empresarial:
71
Ilustración 10 Diagrama de estado del Planeación de Vuelo.
72
Ilustración 12 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.
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.
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.
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.
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.
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.
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.
80
- Crear cuenta.
- Registrar Datos (ingresar datos del cliente).
- Actualizar cuenta.
- Iniciar sesión.
81
- Porcentuar área de interés con área de cobertura.
- Generar Reporte.
82
Ilustración 21 Subproceso Producción.
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.
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).
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 22. Operación Ingresar área de interés del Servicio de Consulta de Información
Geográfica (WFS-T):
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.
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.
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).
(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.
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.
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.
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.
94
ServicioTareaImpl: componente de implementación de interfaces de servicios tareas de
procesos.
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.
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.
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.
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).
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 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.
¿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.
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.
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.
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.
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.
106
Ilustración 31. Capas de Procesos de Negocio, Servicios, Componentes y S. Operativos
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.
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.
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:
109
polígono. Inmediatamente se hace doble clic el código ejecuta la operación 6.1.1.3.
Identificación de Imágenes.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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).
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.
122
Ilustración 42 Editor de Widgets Personalizados.
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.
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
129
Ilustración 56 Asignación Actividad de Entrega.
130
Ilustración 58 Asignación Actividad de Reclamos.
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).
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)
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
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
Evaluación dependiente de recursos de hardware. 50
los 4 segundos.
resolución.
Se necesitan procesar imágenes en formato El prototipo no procesa imágenes, los formatos son
ráster en extensiones PNG, JPG, Geo TIFF y manejados por ExtJS o transformados para su N/A
SVG. manejo. Las imágenes se despliegan en JP2
Las ubicaciones de las bases de datos deben No implementado en prototipo por necesitar elevada
0
estar distribuidas en la nube. capacidad técnica
El sistema operativo debe estar basado en El sistema operativo del prototipo es Linux en la
Linux con una distribución que permita el uso distribución Ubuntu 16.04 y el SMBD es 100
de un SMBD como PostgreSQL o MySQL PostgreSQL.
La exactitud de posición de los productos debe Generalmente las imágenes de UAVs tienen una
ser como máximo de un metro, es decir, los precisión alta, las imágenes usadas en el prototipo
100
datos no pueden tener errores de posición por tienen un GSD = 15 cm y exactitud de posición de 5
encima de un metro. cm
Fiabilidad
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
tanto escalable.
Las aplicaciones deben desarrollarse con Los servicios configurados en Geoserver cumplen
estándares para servicios web geográficos y estándares OGC.
100
lenguajes de programación empleados en SQL, JavaScript, HTML, BPEL, Java son empleados
software libre. en todas las plataformas libres y código abierto
posible del procesamiento de datos, deben ser La flexibilidad es media debido al elevado
codificadas en forma de servicios de manera acoplamiento en motor de procesos de negocio.
30
que el sistema permita una independencia de Se implementaron servicios web WMS, WFS, WFS-
la plataforma y de los proveedores de T.
software.
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.
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.
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.
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.
Las siguientes preguntas y respuestas aportan más detalles acerca de las actuaciones del
usuario seleccionado frente al prototipo.
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.
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.
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.
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.
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”.
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.
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
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.
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.
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.
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.
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.
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.
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.
155
Capítulo 8 Conclusiones y Recomendaciones.
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.
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.
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 .
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.
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.
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.
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.
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.
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.
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.
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. (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.
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.
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.
Chen, S., Osman, M., Nunes, J., & Peng, G. (2011). Information Systems Evaluation
Methodologies. Information Systems Research Trends, Approaches And
Methodologies (ISRTAM), 5.
Cobb, D., & Olivero, A. (1997). Online Gis Service. The Journal Of Academic
Librarianship. Harvard Map Collection, Harvard University, Cambridge,
Massachusetts, 485.
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.
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.
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.
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.
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. (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/
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.
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
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.
Pressman, R. (2010). Software Engineering: A Practitioner’s Approach 7th Ed. New York:
Mcgraw-Hill.
Rational Software Corporation. (2011). Best Practices for Software Development Teams.
Rational Unified Process.
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.
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.
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
W3C. (14 de 02 de 2004). Web Services Architecture. Obtenido de W3C Working Draft :
https://www.w3.org/TR/ws-arch/#whatis
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.
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.
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.
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.
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.
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
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
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.
GSD: Ground Sample Data, distancia entre los centros de dos pixeles adyacentes
175
responde a la solicitud automáticamente y sirve los documentos de hipertexto y multimedia
a través de Internet mediante HTTP.
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.
JXDD: Justice XML Data Dictionary. Diccionario de Datos XML de Justicia provee
estándares de datos para información judicial.
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.
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.
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
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.
SDLC: Software Development Life Cycle. Ciclo de Vida del Desarrollo de Software. Ver
sección 2.1.3 Metodologías Empleadas
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.
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.
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.
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).
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.
180