FACULTADE DE INFORMÁTICA

Transcripción

1 UNIVERSIDADE DA CORUÑA Departamento de Computación FACULTADE DE INFORMÁTICA PROYECTO FIN DE CARRERA INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN Herramienta de análisis de redes en un sistema de información geográfica Autor: Miguel Álvarez Úbeda Director: Carlos Gómez Rodríguez Tutor: Miguel Ángel Rodríguez Luaces Fecha: A Coruña, 17 de Enero de 2008

2

3 Título del Proyecto: Herramienta de análisis de redes en un sistema de información geográfica Clase del Proyecto: Proyecto Clásico de Ingeniería Autor: Miguel Álvarez Úbeda Director: Carlos Gómez Rodríguez Tutor: Miguel Ángel Rodríguez Luaces Fecha: A Coruña, 17 de Enero de 2008 Tribunal Miembros del tribunal: Calificación:

4

5 Resumen Cada día están más en auge los Sistemas de Información Geográfica (GIS) debido al avance de las tecnologías. Una herramienta GIS que esta adquiriendo muchos adeptos en los últimos años es gvsig por ser multiplataforma y desarrollado como software libre por iniciativa de la Generalitat Valenciana, a través de la Consellería de Infraestructuras y en él participan la Universidad Jaume I realizando las tareas de supervisión, con el objetivo de que el desarrollo siga todos los estándares internacionales (Open GIS Consortium), e IVER Tecnologías de la Información S.A, empresa que lleva el peso del desarrollo. En este contexto, y motivado por la ausencia de la importante funcionalidad de análisis de redes y cálculo de rutas, se plantea el objetivo de realizar una extensión para la aplicación de visualización de información geográfica gvsig. La extensión deberá ser capaz de hallar un camino continuo entre dos puntos (si existe) y pintarlo sobre el mapa junto con un informe detallado de la ruta seguida (por ejemplo, un desglose de las carreteras por las que pasa). Para realizar el calculo de la ruta se implementarán en la extensión varios algoritmos (A*, IDA*, Dijkstra, Uniform Cost, Greedy Search, Hill Climbing, Beam Search, Depth First Search, Breadth First Search) que pueden ser utilizados con fines didácticos pudiendo el usuario crear, jugar y resolver sus propios grafos de manera visual. A mayores se ha realizado un comparador de algoritmos con el que valorar los diferentes algoritmos en tiempo, bondad del resultado, y porcentaje de éxito obtenido visualizables de forma gráfica, con el que se ha realizado un estudio estadístico exhaustivo a nivel teórico y empírico. i

6 ii Se hará un especial énfasis en que la aplicación sea fácil de usar (por medio de un asistente y un manual con el que resolver todo tipo de dudas), rápida y manejable y cuidando otros aspectos relevantes como la calidad de las numerosas imágenes utilizadas. Sobre la tecnología empleada en este proyecto, ha sido Eclipse y Java para el desarrollo, PostgreSQL como motor de base de datos sobre la cual se emplea un módulo PostGIS que añade soporte para objetos geográficos y WinEdt y L A TEX para la redacción de la memoria. Además se han empleado programas específicos cómo es JProfiler para optimizar el rendimiento de la extensión y Photoshop para la edición de imágenes. Palabras clave GvSIG, Rutas, Grafo, Análisis de redes, Inteligencia Artificial, Geografía, Algoritmos de búsqueda. ii

7 Agradecimientos A mi padre, por enseñarme cómo llegar hasta aquí. A mi madre, por mostrarme cómo llegar aún más lejos. A mi tutor Miguel Ángel Rodríguez Luaces y a Carlos Gómez Rodríguez, director de este proyecto, por resolverme dudas y prestarme parte de su valioso tiempo. Ambos me han hecho disfrutar del trabajo bien hecho y motivarme cuando me quedaba estancado. A Ana, por hacerme tan feliz. A Susana, Héctor, Alberto, Manuel, Tamara, Quique, Berto, Silvia, Paulo, Adriana, Marta, compañeros de prácticas, y un largo etcétera (perdonarme si me olvido de alguien) por hacerme pasar tantos buenos ratos, dentro y fuera de la Facultad, con esas cenas y fiestas coruñesas. A Ángel Rodríguez Fernández que desarrollo un fantástico trabajo previamente, que me facilitó documentación muy útil para entender el dominio. Además no me puedo olvidar de Nacho y Héctor que colaboraron dándome ideas desde el principio e interesarse por el proyecto aportando así su granito de arena. Mil gracias! A tantas personas que trabajan en la facultad que nos hacen la vida más fácil como los profesores, bibliotecarios, técnicos, limpiadoras... Sin ellos sería más complicada nuestra tarea de aprender y casi nunca se les suele valorar lo suficiente. A la máquina de café, que me he debido haber tomado haciendo este proyecto. iii

8

9 Índice general 1. Introducción Motivación Objetivos Estructura de la memoria Conceptos previos y herramientas utilizadas Sistemas de información geográfica (SIG) Modelos de representación Flujo de trabajo en un SIG Fuentes de error en los SIG Aplicaciones generales de los SIG Bases de datos en un SIG PostgreSQL PostGIS GvSIG Paradigma de la orientación a objetos Características de la POO Grafos Definiciones Caracterización de los Grafos Rutas Herramientas de desarrollo Aplicaciones similares Proyecto Sextante Piloto de redes de gvsig Google Earth & Google Maps Planificación y evaluación de costes Consideraciones previas Planificación inicial Estimación de costes Estimación previa Seguimiento Metodología 51 v

10 ÍNDICE GENERAL vi 5.1. Definición de MPR Representación gráfica de MPR Descripción detallada de las fases Análisis Captura de requisitos Prototipado Definición de especificaciones Casos de uso Diseño Contexto Diseño conceptual Patrón Model-View-Controller DAO (Data Access Object) TO (Transfer Object) Patrón Factory Patrón Singleton Estructura de la aplicación Controlador Modelo Vista Implementación Eclipse Algoritmos A* IDA* Dijkstra Uniform Cost (Búsqueda de coste uniforme) Greedy Search (Búsqueda voraz) Hill Climbing 1 (Búsqueda ascensión de colinas) Hill Climbing Beam Search Depth First Search (DFS) Breadth First Search (BFS) Librerías empleadas JTS Topology Suite itext JFreeChart JSearchDemo Datos de entrada Fichero XML de gvsig Fichero properties Tablas generadas en la base de datos vi

11 ÍNDICE GENERAL 9. Pruebas Pruebas unitarias Pruebas de integración Pruebas de rendimiento Pruebas de stress Pruebas de aceptación Resultados y rendimiento Cómo funciona Consultas SQL El proceso de troceado El proceso de resolución El proceso de comparación algoritmos Resultados obtenidos Rendimiento Síntesis del trabajo Conclusiones Líneas de trabajo futuras Bibliografía 175 A. Manual de usuario 177 A.1. Requisitos del sistema A.2. Instalación A.2.1. PostgreSQL & PostGis A.2.2. GvSIG A.3. Extensión análisis de redes A.4. Ejecución A.5. Utilización A.5.1. GvSIG A.5.2. Menú developer A.5.3. Consultas SQL A.5.4. Configurar A.5.5. Crear Red A.5.6. Listar Redes A.5.7. Añadir Arcos A.5.8. Añadir Nodos A.5.9. Trocear Grafo A.5.10.Paradas A.5.11.Añadir Paradas A.5.12.Calcular Ruta A.5.13.Informe A.5.14.Capa sobre gvsig A.5.15.Comparador Algoritmos A.5.16.Mensajes vii

12 ÍNDICE GENERAL viii A.5.17.Guardar PDF A.5.18.Estadísticas A.5.19.Estadísticas comparación A.5.20.Estadísticas ruta A.5.21.Asistente B. The GNU General Public License 243 C. Glosario 245 D. Contenido del DVD 253 viii

13 Índice de figuras 1.1. Mapamundo de Delisle (versión de 1707) Mapa-mundi en la actualidad Mapa GIS 3D Definición SIG SIG como sistema Diferencias entre raster y vectorial Flujo de trabajo Aplicaciones de un GIS Tipos de geometrías OGC Menú principal de gvsig Tipos de aristas de grafos Diferencias entre grafo conexo y no conexo Grafos completos Ejemplo de grafo Red ejemplo Árbol de la red ejemplo: Notación sin costes Árbol de la red ejemplo: Notación costes Árbol de la red ejemplo: Heurística Google Earth Google Maps Diagrama de Gantt: Estimación inicial Diagrama de Gantt: Estimación real Metodología Prototipado Rápido El paradigma de construcción de prototipos Prototipo Consultas SQL Requisitos usuario Diagrama de casos de uso Estructura interna de gvsig Estructura de GvSig desde el punto de vista del desarrollador Diagrama de clases: FLyrVect Diagrama de clases: Capas Diagrama de clases: IGeometry ix

14 ÍNDICE DE FIGURAS x 7.6. Diagrama MVC: Clases Alto Nivel Patrón Factory Diagrama de clases: GeometriaFactory Diagrama de clases: Algoritmos de Inteligencia Artificial Diagrama de clases: Valor Diagrama de estados: Troceador de la red Diagrama de secuencia: Resolución Grafo de Ruta Diseño de interfaz: Ejemplo edición con Visual Editor Entorno de desarrollo Eclipse Parámetros complejidad árbol Similitud A* con breadth-first Explicación funcionamiento A* A* búsqueda en el árbol A* ejemplo de finalización Recorrido del algoritmo de Dijkstra Greedy Search Hill climbing Hill climbing Beam search Beam search Beam search Beam search Bread First Search Operaciones básicas JTS Diagrama de clases de las geometrías OGC Tabla paradas en la Base de Datos Tabla redes index en la Base de Datos Tabla que mantiene la red troceada JProfiler Consultas SQL Proceso troceado 1: Red vacía Proceso troceado 2: Configuración puntos Proceso troceado 3: Configuración líneas Proceso troceado 4: Troceador Proceso troceado 5: Fusión nodos y líneas Proceso troceado 6: Intersecciones Proceso troceado 7: Líneas Proceso troceado 8: Puntos con tolerancia de error Proceso troceado 9: Tramos Proceso troceado 10: Relaciones entre tramos Proceso troceado 11: Relaciones entre líneas Proceso resolución 1: Estado inicial Proceso resolución 2: Fijar paradas x

15 ÍNDICE DE FIGURAS Proceso resolución 3: Línea virtual Proceso resolución 4: Optimización Proceso resolución 5: Recuperar red almacenada Proceso resolución 6: Grafo Proceso resolución 7: Aplicar algoritmo Proceso resolución 8: Resultado final Proceso resolución 9: Informe Estadísticas distancia Estadísticas grafo Estadísticas tiempo Comparador Ejemplo de grafo aleatorio: 12 nodos, 25 % de densidad TEST 1 - Resultados comparativos de tiempo con densidad 3 % TEST 1 - Resultados comparativos de pasos con densidad 3 % TEST 1 - Resultados comparativos de éxitos con densidad 3 % TEST 1 - Resultados comparativos de coste con densidad 3 % TEST 2 -Resultados comparativos de tiempo con densidad 10 % TEST 2 - Resultados comparativos de pasos con densidad 10 % TEST 2 - Resultados comparativos de éxitos con densidad 10 % TEST 2 - Resultados comparativos de coste con densidad 10 % TEST 3 - Resultados comparativos de tiempo con densidad 25 % TEST 3 - Resultados comparativos de pasos con densidad 25 % TEST 3 - Resultados comparativos de éxitos con densidad 25 % TEST 3 - Resultados comparativos de coste con densidad 25 % TEST 4 - Resultados comparativos de tiempo con densidad 50 % TEST 4 - Resultados comparativos de pasos con densidad 50 % TEST 4 - Resultados comparativos de éxitos con densidad 50 % TEST 4 - Resultados comparativos de coste con densidad 50 % TEST 5 - Resultados comparativos de tiempo con densidad 100 % TEST 5 - Resultados comparativos de pasos con densidad 100 % TEST 5 - Resultados comparativos de éxitos con densidad 100 % TEST 5 - Resultados comparativos de coste con densidad 100 % TEST 6 - Resultados comparativos de tiempo con densidad 1 % TEST 6 - Resultados comparativos de pasos con densidad 1 % TEST 6 - Resultados comparativos de éxitos con densidad 1 % TEST 6 - Resultados comparativos de coste con densidad 1 % TEST 7 - Resultados comparativos de tiempo con densidad 5 % TEST 7 - Resultados comparativos de pasos con densidad 5 % TEST 7 - Resultados comparativos de éxitos con densidad 5 % TEST 7 - Resultados comparativos de coste con densidad 5 % TEST 8 - Resultados comparativos de tiempo con densidad 3 % TEST 8 - Resultados comparativos de pasos con densidad 3 % TEST 8 - Resultados comparativos de éxitos con densidad 3 % TEST 8 - Resultados comparativos de coste con densidad 3 % xi

16 ÍNDICE DE FIGURAS xii A.1. Instalación de PostgreSQL A.2. Instalación de PostgreSQL A.3. Instalación de PostgreSQL A.4. Instalación de PostgreSQL A.5. Instalación de PostgreSQL A.6. Instalación de PostgreSQL A.7. Instalación de PostgreSQL A.8. Instalación de PostgreSQL A.9. Instalación de PostgreSQL A.10. Instalación de PostgreSQL A.11. Instalación de PostgreSQL A.12. Instalación de PostgreSQL A.13. Instalación de PostgreSQL A.14. Postgresql desde Linux: Pgadmin A.15. Instalación gvsig en Windows A.16. Instalación gvsig en Windows A.17. Instalación gvsig en Windows A.18. Instalación gvsig en Windows A.19. Instalación gvsig en Windows A.20. Instalación gvsig en Windows A.21. Instalación gvsig en Windows A.22. Instalación GvSig en Windows A.23. Instalación gvsig en Windows A.24. Instalación GvSig en Windows A.25. Instalación GvSig en Windows A.26. Instalación gvsig en Windows A.27. Instalación gvsig en Linux A.28. Asistente Instalación gvsig A.29. Asistente Instalación gvsig A.30. Asistente Instalación gvsig A.31. Asistente Instalación gvsig A.32. Asistente Instalación gvsig A.33. Asistente Instalación gvsig A.34. Asistente Instalación gvsig A.35. Asistente Instalación gvsig A.36. Asistente Instalación gvsig A.37. Asistente Instalación gvsig A.38. Menú extensión en gvsig A.39. Menú about en gvsig A.40. Menú developer A.41. Consulta SQL A.42. Configurar A.43. Crear red A.44. Menú listar redes A.45. Añadir arcos xii

17 ÍNDICE DE FIGURAS A.46. Añadir nodos A.47. Menú trocear Grafo A.48. Menú paradas A.49. Añadir paradas A.50. Calculador de ruta A.51. Calculador de ruta en formato barra A.52. Menú informe A.53. Menú informe exportado a PDF A.54. Capas añadidas en el ToC sobre de gvsig A.55. Comparador A.56. Tipos de mensajes A.57. Guardar PDF A.58. Menú JFreeChart A.59. Comparador tiempos A.60. Comparador pasos A.61. Comparador éxitos A.62. Comparador costes A.63. Consumo memoria A.64. Estadísticas ruta tiempos A.65. Estadísticas ruta grafo A.66. Estadísticas ruta distancia A.67. Asistente: Presentación A.68. Asistente: Configurar A.69. Asistente: Añadir capa puntos A.70. Asistente: Añadir capa líneas A.71. Asistente: Crear Red A.72. Asistente: Paradas A.73. Asistente: Listar Redes A.74. Asistente: Trocear Grafo A.75. Asistente: Finalizar xiii

18

19 Capítulo 1 Introducción 1.1. Motivación Un mapa es una representación gráfica y métrica de una porción de territorio sobre una superficie bidimensional, generalmente plana, pero que puede ser también esférica como ocurre en los globos terráqueos. El que el mapa tenga propiedades métricas significa que ha de ser posible tomar medidas de distancias, ángulos o superficies sobre él y obtener un resultado lo más exacto posible. Iniciados por el hombre con el propósito de conocer su mundo, y apoyados primero sobre teorías filosóficas, los mapas constituyen hoy una fuente importantísima de información, y una gran parte de la actividad humana está relacionada de una u otra forma con la cartografía. La historia de la cartografía abarca desde los primeros trazos en la arena o nieve hasta el uso de técnicas geodésicas, fotogramétricas y de fotointerpretación. Los errores geométricos de un mapa suelen mantenerse por debajo de lo que el ojo humano puede percibir. Actualmente se tiene la inquietud y la necesidad de proseguir con la nunca acabada labor cartográfica. El Universo en general y el Sistema Solar en particular ofrecerá, sin duda, nuevos terrenos para esta labor que tiene orígenes inmemoriales. El uso de las técnicas basadas en la fotografía por satélite ha hecho posible no sólo conocer el contorno exacto de un país, de un continente o del mundo, sino también aspectos etnológicos, históricos, estadísticos, hidrográficos, orográficos, geo- 1

20 1.1. MOTIVACIÓN 2 morfológicos, geológicos y económicos que llevan al hombre a un conocimiento más amplio de su medio, del planeta en el que vive. La cuestión esencial en la elaboración de un mapa es que la expresión gráfica debe ser clara, sin sacrificar por ello la precisión. El mapa es un documento que tiene que ser entendido según los propósitos que intervinieron en su preparación. Todo mapa tiene un orden jerárquico de valores y los primarios deben destacarse por encima de los secundarios. Para poder cumplir con estas exigencias, el cartógrafo debe crear varios planos de lectura. En todo momento debe tener presentes las técnicas de simplificación, a base de colores o simbología, sin perder de vista que en un plano de lectura más profundo se pueden obtener elementos informativos detallados. La cantidad de información debe estar relacionada en forma proporcional a la escala. Cuanto mayor sea el espacio dedicado a una región, mayor será también el número de elementos informativos que se puedan aportar acerca de ellos. En definitiva, todo mapa tiene que incluir una síntesis de conjunto al igual que un detalle analítico que permita una lectura más profunda. El nivel en que se cumplan estas condiciones será igualmente el nivel de calidad cartográfica de un determinado mapa. 2

21 CAPÍTULO 1. INTRODUCCIÓN Figura 1.1: Mapamundo de Delisle (versión de 1707). En el siglo XX, la cartografía ha experimentado una serie de importantes innovaciones técnicas. La fotografía área, denominada también ortofotomapa, se desarrolló durante la I Guerra Mundial y se utilizó, de forma más generalizada, en la elaboración de mapas durante la II Guerra Mundial. Era de vital importancia puesto que la supervivencia dependía en gran medida de la estrategia 1 y la topografía del terreno adoptadas pudiendo decantar la victoria hacia uno u otro bando. Hacia el año 1966 se lanzan los primeros satélites (Pageous y Landsat) para hacer estudios geodésicos completos de la superficie terrestre por medio de equipos de alta resolución. Para la fotogrametría moderna se emplean instrumentos de alta precisión que permiten relacionar las fotografías aéreas y de satélite con las medidas reales del terreno. De ello resulta una información gráfica que hace posible conocer las distancias y los desniveles de una región determinada. La fotointerpretación, a través de la visión estereoscópica de la fotogrametría o aerotopografía, da un elevado nivel de detalle, que hace posible llegar a conclusiones verdaderas acerca de las condiciones de los suelos, sus usos actuales y potenciales. 1 estrategia: proveniente de la etimología del griego strategos, se fundamenta en el estudio del planeamiento, dirección, movimiento y dispersión de tropas de una forma coordinada. 3

22 1.1. MOTIVACIÓN 4 Figura 1.2: Mapa-mundi en la actualidad. Por otra parte, la aparición de los Sistemas de Información Geográfica (GIS) en los años 70 y su popularización en los 90 han revolucionado la forma de crear y manejar cartografía a través de estas herramientas informáticas que asocian elementos espaciales con bases de datos. Los GIS permiten el análisis y la gestión del territorio a través de cartografía digital de una manera rápida y efectiva y sus fines soy muy diversos. Un ejemplo cotidiano de este avance son los GPS. En la actualidad la elaboración de mapas es una operación compleja en la que participan grupos de más de 50 diferentes disciplinas: fotonavegantes, mecánicos, químicos de laboratorio, geodestas, matemáticos, topógrafos, geólogos, biólogos, geógrafos, físicos, agrónomos, edafólogos, ingenieros civiles, economistas y arquitectos, entre otros. En el futuro existen planes serios de hacer mapas de los planetas vecinos del Sistema Solar, de manera que los mapas, que fueron la forma inicial de conocer la Tierra, muy pronto servirán para llevar las fronteras del conocimiento más allá del planeta en el que vivimos, incluso en 3 dimensiones. 4

23 CAPÍTULO 1. INTRODUCCIÓN Figura 1.3: Mapa GIS 3D. Sabiendo que encontrar el camino es un problema fundamental para el ser humano se plantea la posibilidad de desarrollar una extensión para calcular rutas sobre un sistema GIS con la que poder desarrollar y aumentar los conocimientos y habilidades adquiridas durante la carrera. El sistema GIS elegido en este caso fue gvsig (que se detallará en la página 24) por los siguientes motivos: 1. Por ser código abierto. 2. Disponer de una comunidad con la que la que resolver dudas técnicas. 3. Estar desarrollado en Java, simplificando lo más posible el desarrollo con el fin de alcanzar objetivos de más alto nivel. 5

24 1.2. OBJETIVOS Objetivos El objetivo de este proyecto es múltiple, el principal es el desarrollo de una herramienta completa que extienda la funcionalidad de análisis de gvsig. El cometido de dicha extensión es el cálculo de rutas. Para que se entienda mejor vamos a explicarlo con un ejemplo: si suponemos que tenemos información acerca de poblaciones (puntos) y carreteras (líneas) y un conjunto de paradas (subconjunto de poblaciones y por tanto subconjunto de puntos) lo que debería proporcionar esta nueva herramienta, aplicando unos sencillos pasos, sería la traza (también llamada ruta) de tramos de carreteras que se pueden atravesar para recorrer todas las paradas en el orden estipulado, pintándolo sobre el plano, proporcionando informes y datos estadísticos acerca del proceso. Además tiene otro objetivo secundario y no por ello menos importante, que es el desarrollo de un comparador de algoritmos para el estudio empírico-analítico con el fin de determinar cuál es el mejor algoritmo en tiempo, cuál proporciona un camino más corto, en cuántos pasos lo resuelve y qué éxito ha logrado dicho algoritmo. Para llevarlo a cabo es preciso aprender, entender y dominar diferentes teorías y dominios en mayor o menor medida para su posterior aplicación como pueden ser la geografía, estadística, algoritmia de inteligencia artificial, matemáticas, bases de datos... Se pondrá un especial énfasis en que sea una herramienta fácil de utilizar para que usuarios inexpertos puedan emplearla y a la par que los usuarios expertos puedan sacarle las mayores prestaciones, lo que añade más complejidad al proyecto. Se intentará que tenga un equilibrio entre rendimiento óptimo y que sea una aplicación tan didáctica como útil para ayudar de forma altruista a los nuevos desarrolladores que comiencen Estructura de la memoria La memoria se estructura en varios capítulos que se detallan a continuación Introducción: Capítulo en el que se explica la motivación y los objetivos que persigue el proyecto, además de definir la estructura de la memoria. 6

25 CAPÍTULO 1. INTRODUCCIÓN Conceptos previos y herramientas utilizadas: Este capítulo hace referencia a todo lo que debe conocerse, así como todo lo que concierne a la elección de las herramientas utilizadas para afrontar la realización del proyecto. Aplicaciones similares: En este capítulo se hará un pequeño repaso de otras aplicaciones similares que están disponibles en Internet, haciendo un breve análisis de la funcionalidad que proporcionan. Planificación: En este capítulo se verá la planificación llevada a cabo para la realización del proyecto, así como una evaluación de los costes. Metodología: Trata de las distintas técnicas utilizadas para el desarrollo del proyecto, con sus correspondientes diagramas. Análisis: En este capítulo se habla de qué se va a construir, y cómo se obtuvieron las especificaciones. Diseño: Aquí es donde se describe el cómo se construyó y los diferentes patrones empleados. Implementación: Se explican aspectos relevantes de implementación, el entorno de desarrollo y algoritmos a bajo nivel. Pruebas: Este capítulo pretende reflejar las distintas pruebas que se han realizado a la hora de validar la aplicación. Resultados y rendimiento: Se trata cómo funciona la aplicación por dentro, las funcionalidades que proporciona y los resultados obtenidos en detalle. Síntesis del trabajo: Se dará una exposición de las conclusiones que se alcanzaron después de la realización del proyecto además de contemplar diversas mejoras y ampliaciones que se pueden realizar, pero que de alguna forma quedaron fuera de los objetivos marcados. Bibliografía: En este capítulo se hace referencia a las fuentes consultadas más relevantes para la obtención de información para la ejecución del proyecto. Apéndice A - Manual de usuario: Describe la instalación de los elementos necesarios para el funcionamiento, configuración y puesta a punto intentando evitar resolver las dudas típicas que pueden surgir en su utilización basándose en capturas de pantalla autoexplicativas. Apéndice B - Licencia: Normas GPL 2 por las cuales puede ser distribuida la aplicación realizada al ser publicada. Apéndice C - Glosario: Definición de términos específicos del dominio de la geografía. 2 GPL: General Public License 7

26 1.3. ESTRUCTURA DE LA MEMORIA 8 Apéndice D - Contenido del DVD: Explicación de la estructura y el contenido de las carpetas incluidas en el medio digital anexo. 8

27 Capítulo 2 Conceptos previos y herramientas utilizadas 2.1. Sistemas de información geográfica (SIG) La cartografía tiene como objetivo la producción de mapas y su interpretación. En la última década, con el avance tecnológico y su incorporación a esta ciencia, ha pasado a ser un elemento fundamental en la sociedad de la información. Desde el punto de vista de la ingeniería cartográfica, es el soporte básico para la planificación y diseño de obras, infraestructuras, análisis físico del territorio, económico o ambiental. Las herramientas que se han establecido para el análisis de la cartografía son los denominados Sistemas de Información Geográfica (SIG). Los SIG se definen como sistemas compuestos por hardware, software y procedimientos para capturar, manipular, analizar, modelar y representar datos georreferenciados 1, con el objetivo de resolver problemas de gestión y planificación. Ante todo son herramientas de ayuda a la resolución de problemas; el concepto de herramienta indica que los SIG no son el fin, sino el medio. 1 georreferenciación: establecimiento de relaciones entre las imágenes de raster o vector sobre una proyección geográfica o sistema de coordenadas. 9

28 2.1. SISTEMAS DE INFORMACIÓN GEOGRÁFICA (SIG) 10 Figura 2.1: Definición SIG Los SIG tienen las siguientes características: Son sistemas diseñados para la visualización de información geográfica expresada en forma de mapas. El eje central de su funcionamiento se encuentra en la posición de un elemento geográfico representado por elementos gráficos (como puntos, líneas, polígonos) y su información temática asociada. Disponen de un gran número de funciones de análisis y consulta para explotar la información geográfica enfocada a resolver un problema o necesidad. Son el resultado de la aportación de múltiples disciplinas (geográfica, matemática, cartográfica) de las que se han extraído capacidades para el manejo de información geográfica. Almacenan las relaciones espaciales entre los distintos elementos, lo que permite interrogar al sistema sobre estas relaciones. 10

29 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS Figura 2.2: SIG como sistema Un sistema de información geográfica, por ser sistema, tiene una serie de elementos relacionados entre sí. Elementos que interrelaciona Hardware: Equipos informáticos formados por ordenadores y sus periféricos; monitor, escáner, dispositivos de almacenamiento, impresoras, etc. Software: Programas informáticos con funciones para visualizar, consultar y analizar los datos geográficos. Liveware: Es el componente vivo del sistema. Comprende a los usuarios del sistema y a los datos que han de recogerse y mantenerse vivos (actualizados). Las principales funciones de un SIG son: Captura de la información: Funciones que permiten adquirir y depurar errores tanto de información geográfica espacial como temática. Funciones de gestión: Funciones de estructuración de la información original en diferentes capas de información coherente. Funciones de análisis: Son las que confieren a un SIG su mayor potencialidad. Permiten extraer información no presente a simple vista, generar nuevos datos y realizar simulaciones de comportamientos basados en modelos de territorio. Funciones de salida: Permiten mostrar al usuario tanto los propios datos incluidos en el sistema como el resultado de las consultas y análisis sobre ellos. 11

30 2.1. SISTEMAS DE INFORMACIÓN GEOGRÁFICA (SIG) Modelos de representación Los SIG deben ser capaces de representar y almacenar las entidades geográficas reales mediante la representación y almacenamiento de las entidades gráficas. Existen básicamente dos formas en los que se puede representar la información en los sistemas informáticos; son el modelo raster y el modelo vectorial. La diferencia de los modelos está en el modo en el que guardan la información. El modelo raster guarda una matriz de posiciones donde cada posición representa una fracción del objeto a representar y tomará el valor que tenga ese objeto real en ese punto. El modelo vectorial almacena las coordenadas de la geometría. Un ejemplo de utilización de ambos modelos son las aplicaciones CAD que usan el modelo vectorial, y las aplicaciones de retoque fotográfico que usan el modelo raster. Figura 2.3: Diferencias entre raster y vectorial Cada modelo se usará en un contexto determinado, ya que dependiendo de la situación puede ser mejor usar un modelo que el otro. Modelo vectorial Ocupa menos espacio de memoria Precisión elevada en la definición de entidades geométricas VENTAJAS Modelo raster Facilidad de captura Estructura de datos simple 12

31 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS Modelo vectorial Modelo raster Representación adecuada de las relaciones topológicas tión de la información Sencillez en la manipulación y ges- Mejores salidas gráficas INCONVENIENTES Captura de datos más costosa Menor precisión en el cálculo de áreas y longitudes Estructura de datos más compleja Ocupan mayor espacio de memoria Mayor dificultad a la hora de realizar ciertas operaciones (Comparalaciones topológicas Dificultad de representar ciertas reción de mapas) Cuadro 2.1: Ventajas e inconvenientes entre vectorial y raster De forma general diremos que recomendaremos el trabajo con información raster cuando: Trabajemos con grandes extensiones de terreno y a pequeñas escalas. No requiramos precisiones muy altas para nuestros cálculos. Requiramos análisis rápidos de estudios de variabilidad temporal. Estas condiciones se pueden dar en casos de estudios sobre recursos naturales, impacto medioambiental, estudios regionales y globales sobre climatología, cálculo de superficies afectadas por incendios, etc. Por el contrario, se recomendará trabajar con información vectorial cuando: Trabajemos con extensiones pequeñas y a medianas o grandes escalas. Necesitemos altas precisiones en cálculos y definición de entidades. Necesitemos tener reflejadas complejas relaciones topológicas. Estos criterios se dan en casos como la gestión catastral, planificación urbana local, arqueología, etc. 13

32 2.1. SISTEMAS DE INFORMACIÓN GEOGRÁFICA (SIG) Flujo de trabajo en un SIG Para entender y obtener el máximo beneficio de un SIG, el usuario debe saber cuál es la secuencia de fases que ha de aplicar para llegar a solucionar un problema que se le ha planteado. Las fases que se deben seguir son las siguientes: Captura de la información: la información necesaria será función del problema planteado. La calidad de los datos originales influirá en la bondad del resultado final. Los métodos de captura de la información espacial son múltiples y variados: tableta digitalizadora, escáner, levantamiento topográfico o fotogramétrico, plataformas de satélite, etc. Así mismo los datos temáticos serán capturados a partir de bases de datos existentes, fichas, encuestas, entrevistas, trabajos de campo, etc. Preparación de la información: es necesario que la información esté limpia de errores (cometidos en la captura) y dotada de una estructura que permita una consulta y un análisis eficiente por parte del sistema. En el caso de información vectorial, hacer que los polígonos estén cerrados o que las líneas conecten entre sí permitirá estructurar la información guardando sus relaciones topológicas. Esto hará que el sistema pueda contestar a preguntas como qué es lo más cercano a...?, cuál es el mejor camino para...?, cuántos elementos hay dentro de...?, etc. En el caso de la información raster, será necesario georreferenciar la información y corregirla de posibles deformaciones y valores erróneos debidos al proceso de adquisición. Fusión de la información espacial y temática: es el proceso por el cual se asocia a cada elemento geográfico información temática externa de naturaleza diferente a la espacial. Cada elemento geográfico tiene un enlace biunívoco con su información temática asociada de forma que es posible interrogar a un elemento espacial y obtener el resultado en forma de información temática y viceversa, interrogar a la información temática y obtener como resultado un elemento espacial. Análisis de la información: una vez fusionados los datos, se los puede some- 14

33 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS ter a operaciones de análisis que sigan los criterios de resolución del problema. Los análisis pueden ser sobre datos de una única naturaleza (datos espaciales o temáticos por separado) o analizar ambos tipos de datos a la vez. Figura 2.4: Flujo de trabajo Fuentes de error en los SIG Cuando trabajamos con SIG, el coste más alto, en tiempo y dinero, recae sobre la captura y el mantenimiento (actualización) de la información geográfica. Los datos son materia viva y deben ser mantenidos en estado de óptima calidad, tanto desde el punto de vista geométrico (adecuada exactitud posicional, exentos de errores topológicos, etc.), temático (fiabilidad de la información temática, asociación adecuada con los datos gráficos, etc.) como temporal (los datos han de ser lo más recientes posible). Por lo tanto, debemos ser capaces de conocer de qué tecnologías y metodologías disponemos para capturar la información geográfica y qué errores podemos cometer en este proceso. Esto será un indicador fundamental de la calidad de nuestros datos y, por extensión, de la calidad de nuestros análisis y resultados al trabajar sobre el SIG. Los tipos de errores que podemos encontrarnos al trabajar con información geográfica dentro del entorno de los SIG pueden ser de dos tipos: 15

34 2.1. SISTEMAS DE INFORMACIÓN GEOGRÁFICA (SIG) 16 Los errores propios debidos al método de captura de los datos. Errores debidos a la manipulación de la información original por aplicación de sucesivos procesos de análisis y transformación dentro del propio SIG. Ambos tipos de errores pueden aplicarse tanto a la información gráfica como a la información temática e influir directamente sobre la calidad final de los datos Aplicaciones generales de los SIG Varios factores hacen posible que los SIG sean aplicables a casi cualquier actividad humana. Son aptos para resolver cualquier problema que dependa de una variable espacial (que sea o esté asociada a una posición de un elemento geográfico). La popularización de la información visual en general y de los mapas en particular en los últimos años hace que cada vez más personas apoyen sus argumentos con documentos cartográficos y sean estos usados como instrumentos de comunicación cotidianos. La entrada en el mundo laboral y personal de la informática hace que los usuarios se encuentren cómodos usando herramientas de este tipo. El intercambio masivo y libre de información geográfica a través de Internet hace que nos habituemos a referenciar cualquier tipo de idea a una posición en el planeta. La gestión y planificación del territorio y la explotación de los recursos naturales se han convertido en una necesidad imperante para el hombre. Estas factores nos dan una idea de la importancia que tiene para nosotros no sólo saber cómo es nuestro territorio y dónde estamos (función que ya cumple desde muy antiguo el mapa), sino saber explotar la información implícita que podemos extraer de ese territorio en nuestro propio beneficio. A continuación, se citan algunos campos de aplicación usuales dentro de los SIG: Planificación urbana y regional: En la planificación de usos del suelo o espacios protegidos, licencias de obras, registros de la propiedad, catastro de rústica y urbana, etc. Ingeniería de transportes: En la gestión del tráfico rodado o aéreo, el análisis de rutas óptimas para distribución de mercancías, gestión de transporte público, etc. 16

35 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS Explotación de recursos: En la evaluación de zonas de yacimientos minerales, la gestión de redes de alcantarillado, gas y electricidad, etc. Análisis de nuevos mercados: En la ubicación de nuevos centros comerciales, análisis demográficos para nuevos productos, mejora de las redes de distribución, gestión inmobiliaria, etc. Aplicaciones de seguridad pública: En aplicaciones para el control de la criminalidad por parte de la policía, aplicaciones militares para el control de armamento, etc. Aplicaciones de salud pública: En la mejora de la rapidez en la atención de las ambulancias, gestión de emergencias sanitarias, lucha contra epidemias, etc. Turismo: En el desarrollo turístico de zonas deprimidas, la generación de callejeros interactivos vía Internet, medio ambiente. En análisis de impactos ambientales, inventarios de recursos medioambientales, ubicación de nuevas plantas de procesado de residuos y vertederos, etc. Prevención de riesgos naturales: En la lucha contra incendios, desertización, inundaciones, terremotos, deslizamientos de terreno, etc. 17

36 2.2. BASES DE DATOS EN UN SIG 18 Figura 2.5: Aplicaciones de un GIS 2.2. Bases de datos en un SIG Una base de datos (abreviado como BD) es una colección de archivos interrelacionados, son creados con un sistema gestor de bases de datos. El contenido de una base de datos engloba la información concerniente (almacenada en archivos) a una organización, de tal manera que los datos estén disponibles para los usuarios; una finalidad de la base de datos es eliminar la redundancia o al menos minimizarla. Tabla de datos: La tabla es la unidad lógica de almacenamiento de información en una base de datos. Una tabla está formada por muchas filas (también llamadas registros o tuplas) con el mismo patrón de información. Cada registro está formado por una o varias columnas -también llamados campos o atributos-, que son los datos que nos interesan conocer. Así pues, de manera resumida podemos decir que una base de datos está formada por una o varias tablas que representan las ideas lógicas de las cuales queremos obtener información. En cada una de estas tablas habrá cero o muchas filas con 18

37 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS información diferente. Por cada fila tendremos un detalle de sus datos más relevantes que nos interesan representar, es decir, los campos de la tabla. El sistema gestor de bases de datos es la porción más importante del software de un sistema de base de datos. Es una colección de numerosas rutinas de software interrelacionadas, cada una de las cuales es responsable de alguna tarea específica. El objetivo primordial de un sistema gestor de base de datos es proporcionar un contorno que sea a la vez conveniente y eficiente para ser utilizado al extraer, almacenar y manipular la información de la base de datos. Todas las peticiones de acceso a la base se manejan centralizadamente por medio del sistema, por lo que este paquete funciona como interfaz entre los usuarios y la base de datos. Las funciones principales de un sistema gestor de base de datos son: Crear y organizar la base de datos. Establecer y mantener las trayectorias de acceso a la base de datos de tal forma que el acceso a los datos sea rápido. Manejar los datos de acuerdo a las peticiones de los usuarios. Registrar el uso de las bases de datos. Interacción con el manejador de archivos. Respaldo y recuperación. Consiste en contar con mecanismos implantados que permitan la recuperación fácilmente de los datos en caso de ocurrir fallos en el sistema de base de datos. Control de concurrencia. Consiste en controlar la interacción entre los usuarios concurrentes para no afectar a la inconsistencia de los datos. Seguridad e integridad. Consiste en contar con mecanismos que permitan el control de la consistencia de los datos evitando que estos se vean perjudicados por cambios no autorizados o previstos. 19

38 2.2. BASES DE DATOS EN UN SIG 20 Una base de datos espacial es una colección de datos espacialmente referenciados que actúan como modelo de la realidad. Las bases de datos espaciales son sistemas donde se almacena la información espacial. Estos sistemas necesitan representar información de dos tipos: espacial y nominal (sin representación espacial). Los datos espaciales serán referentes a las dimensiones, posición, forma,... y los nominales son datos que puedan ser de interés como nombre, habitantes... El método de representación digital varía con la escala, por ejemplo una ciudad puede representarse geográficamente como un punto considerando una escala continental, en cambio, en escalas más locales se representa como una superficie. Por esta razón la representación digital de los diferentes tipos de entidades en una base de datos espacial requiere una previa elección de los apropiados objetos espaciales. También se debe tener en cuenta para esta elección las operaciones de análisis y consultas posteriores, así como la información geográfica de partida. Por ejemplo, las vías de comunicación pueden ser representadas como elementos lineales o superficiales. La información espacial se guardará de una de las siguientes formas: Datos puntuales: Es el tipo de objeto espacial más simple. En la tabla de la base de datos, cada punto será una fila, toda la información sobre el punto estará en esa fila. Cada columna será un atributo. Cada punto es independiente de cualquier otro punto. Datos lineales: Algunas entidades representables mediante objetos lineales son las redes de infraestructuras, vías de comunicación, redes de recursos ó redes de transporte. Datos superficiales: Los objetos espaciales superficiales representan áreas. Pueden representar fenómenos naturales como lagos o fenómenos artificiales como zonas de censo, ajardinadas, etc. 20

39 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS Figura 2.6: Tipos de geometrías OGC Hay varios tipos de superficies que pueden ser representadas: Zonas de recursos naturales o medioambientales. Por ejemplo: datos geológicos (tipos de material), usos del suelo (bosques, urbano), tipos de suelo (industrial, urbanizable). Zonas socio-económicas. Por ejemplo: códigos postales, distritos, barrios. 21

40 2.2. BASES DE DATOS EN UN SIG 22 Zonas con carácter tributario. Por ejemplo: parcelas, uso del suelo, información de tasas. En los objetos espaciales que representan superficies pueden aparecer huecos o islas o áreas de diferentes atributos encerradas íntegramente dentro de ellas. La utilización de una base de datos para almacenar la información cartográfica se vuelve casi imprescindible para acceder a un inmenso volumen de información de forma eficiente. En este sentido la restricción proveniente de los requisitos fue PostgreSQL con la extensión PostGIS que de forma estandarizada proporciona funciones típicas para manejarla de la que se hablará a continuación. La herramienta gvsig, no es un sistema de información geográfica por sí sola, ya que según la definición de SIG deben capturar, manipular, analizar, modelar y representar datos georreferenciados y gvsig se centra en la representación y un poco en el proceso de los datos, le falta el almacenamiento de los datos que le aporta una base de datos como PostgreSQL PostgreSQL PostgreSQL es un motor de base de datos liberado bajo licencia BSD 2, significa que el autor permite su modificación y distribución, pero se reserva el derecho de atribución sobre posibles modificaciones. Aparte de los típicos datos de una base de datos como INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTER- VAL y TIMESTAMP también soporta el almacenamiento de grandes ficheros binarios incluyendo sonidos, imágenes, o video. Incluye interfaces nativas para C/C++, Java,.Net, Perl, Python, Ruby, Tcl, ODBC y otros lenguajes. 2 BSD: Berkeley Software Distribution 22

41 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS PostGIS PostGIS es un módulo para PostgreSQL que añade soporte para objetos geográficos. Las bases de datos espaciales permiten el almacenamiento y manipulación de datos geográficos usando SQL extendido. PostGIS implementa metadatos y funciones geométricas y topológicas para el tratamiento de los datos espaciales basándose en el estándar Open Geospatial Consortium a partir de ahora abreviado como OGC, pero con la ventaja de ser de distribución libre por lo que es ampliamente usado en todo el mundo. Algunas de las funciones más importantes son: AsText: Muestra una geometría en su representación textual. GeomFromText: Traduce una geometría de su formato binario a su representación textual. GeometryFromText: convierte un objeto de la representación textual a un objeto geometría. AddGeometryColumn: Añade una columna a una tabla de la base de datos que contendrá los datos espaciales. Contains: Establece si una geometría dada contiene en su interior otra geometría dada. Difference: Devuelve la diferencia geométrica entre dos geometrías. Intersects: Establece si dos geometrías se intersecan. Buffer: Devuelve una geometría que representa el buffer de una geometría dada. Perimeter: Devuelve el perímetro de una geometría POLYGON dada. Area: Devuelve el área de una geometría POLIGON dada. 23

42 2.3. GVSIG 24 Length: Devuelve la longitud de una geometría LINESTRING dada. Within: Establece si una geometría se encuentra en el interior de otra dada. Distance: Devuelve la distancia mínima entre dos geometrías dadas. Touches: Establece si dos geometrías dadas son adyacentes. Intersection: Devuelve una geometría resultante de la intersección de dos geometrías dadas. PostGis tiene una API 3 muy bien documentada en su página web, consultar la bibliografía para más información (página 175) GvSIG Es una herramienta para la visualización de información geográfica en un SIG, multiplataforma y desarrollado como software libre. GvSIG es una potente herramienta de gestión de información geográfica destinado a satisfacer las nuevas necesidades y demandas del mercado potencial de usuarios, desarrollado bajo los estándares internacionales y que garantiza su interoperabilidad. El proyecto de gvsig surge por iniciativa de la Generalitat Valenciana (gobierno local), a través de la Consellería de Infraestructuras y en él participan la Universidad Jaume I realizando las tareas de supervisión, con el objetivo de que el desarrollo siga todos los estándares internacionales (Open GIS Consortium), e IVER Tecnologías de la Información S.A, empresa que lleva el peso del desarrollo. La aplicación es de código abierto, tiene licencia GPL. Además se ha hecho un especial esfuerzo en la extensibilidad del proyecto, de forma que los posibles desarrolladores puedan ampliar las funcionalidades de la aplicación fácilmente, así como desarrollar aplicaciones totalmente nuevas a partir de las librerías utilizadas en gv- SIG. 3 API: Interfaz de Programación de Aplicaciones 24

43 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS Existe documentación de usuario y casos prácticos bastante completa y extensa (más de 400 páginas) en la página web oficial [17] (en el apartado documentación ) que explica todas las funcionalidades y ejemplos prácticos. Por el contrario la documentación técnica es bastante reducida y limitada aunque este problema se anda solventando mediante el esfuerzo de la comunidad haciendo ingeniería inversa (análisis de fuentes). Figura 2.7: Menú principal de gvsig La interfaz de gvsig consta de: 1. Barra de título: Se encuentra en la parte superior de la ventana de gvsig y contiene el nombre del programa y del proyecto. 2. Botones con las que poder maximizar o minimizar la ventana activa del programa, o bien cerrarlo completamente. 25

44 2.4. PARADIGMA DE LA ORIENTACIÓN A OBJETOS Ventana principal: Espacio de trabajo donde encontramos las distintas ventanas que nos muestra el Gestor de proyectos y los distintos documentos propios de gvsig. 4. Barra de menús: Aquí podemos encontrar agrupadas en forma de menús y submenús las funciones que gvsig puede realizar. 5. Barra de herramientas: Contiene los iconos de los comandos más usuales y constituyen la forma más fácil de acceder a estos. Haciendo click y arrastrando, podemos mover de su posición inicial las barras de herramientas. No es necesario memorizar el significado de cada uno de los iconos, con situar el puntero sobre ellos, aparecerá inmediatamente una casilla con la descripción de su función. 6. Barra de estado: Proporciona información sobre coordenadas, distancias, etc. Se volverá hablar recurrentemente sobre la aplicación, sobre todo en temas de análisis y diseño disponibles en las páginas 57 y Paradigma de la orientación a objetos La Programación Orientada a Objetos (a partir de ahora abreviado con el acrónimo POO) es un paradigma de programación que define los programas en términos de clases de objetos, objetos que son entidades que combinan estado (es decir, datos), comportamiento (esto es, procedimientos o métodos) e identidad (propiedad del objeto que lo diferencia del resto). La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar. De esta forma, un objeto contiene toda la información, (los denominados atributos) que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases (e incluso entre objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos). A su vez, dispone de mecanismos de interacción -los llamados métodos- que favorecen la comunicación entre objetos -de una misma clase 26

45 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS o de distintas-, y en consecuencia, el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separan -ni deben separarse- información (datos) y procesamiento (métodos). Dada esta propiedad de conjunto de una clase de objetos, que al contar con una serie de atributos definitorios requiere de unos métodos para poder tratarlos (lo que hace que ambos conceptos están íntimamente entrelazados), el programador debe pensar indistintamente en ambos términos, ya que no debe nunca separar o dar mayor importancia a los atributos en favor de los métodos, ni viceversa. Esto difiere de los lenguajes imperativos tradicionales, en los que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. Los programadores que emplean lenguajes orientados a objetos definen objetos con datos y métodos y después envían mensajes a los objetos diciendo que realicen esos métodos en sí mismos. Como conceptos importantes podemos destacar los siguientes: Objeto: entidad provista de un conjunto de propiedades o atributos ( datos ) y de comportamiento o funcionalidad ( métodos ). Corresponden a los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas. Método: algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un mensaje. Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un evento con un nuevo mensaje para otro objeto del sistema. Evento: un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento 27

46 2.4. PARADIGMA DE LA ORIENTACIÓN A OBJETOS 28 enviando el mensaje adecuado al objeto pertinente. Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó. Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto, y cuyo valor puede ser alterado por la ejecución de algún método. Estado interno: es una propiedad invisible de los objetos, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos) Características de la POO Las características siguientes son las más importantes: Abstracción: Cada objeto en el sistema sirve como modelo de un agente abstracto que puede realizar trabajo, informar y cambiar su estado, y comunicarse con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y, cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. Encapsulamiento: también llamado ocultación de la información. Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas; solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos. 28

47 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. Dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en tiempo de ejecución, esta última característica se llama ligadura dinámica. Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que reimplementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto pertenece a más de una clase se dice que hay herencia múltiple. Esta característica no está soportada por algunos lenguajes (como Java). Para la realización de este proyecto es fundamental tener conocimientos respecto a este paradigma y sus características. Un gran libro de cabecera en este ámbito es Piensa En Java [2]. Teniendo en cuenta las características mencionadas podemos introducir el concepto de patrón, que no es más que una solución a un problema conocido que por su asidua repetición ha sido resuelto de forma óptima. Se hablará de manera más extensa sobre ello en el tema de Patrones de diseño que se encuentra en el capítulo 7 (página 65). 29

48 2.5. GRAFOS Grafos La teoría de grafos estudia las propiedades de los grafos, que son colecciones de objetos llamados vértices (o nodos) conectados por líneas llamadas aristas (o arcos) que pueden tener orientación (dirección asignada). Típicamente, un grafo está compuesto de una serie de puntos (los vértices) conectados por líneas (las aristas). Existen diferentes formas de almacenar grafos en una computadora. La estructura de datos usada depende de las características del grafo y el algoritmo usado para manipularlo. Teóricamente se pueden distinguir las estructuras de listas y las de matrices, pero usualmente, lo mejor es una combinación de ambas. Las listas son preferidas en grafos dispersos porque tienen un eficiente uso de la memoria. Por otro lado, las matrices proveen acceso rápido, pero pueden consumir grandes cantidades de memoria Definiciones Vértice Un vértice es la unidad fundamental de la que están formados los grafos. Los vértices son tratados como un objeto indivisible y sin propiedades, aunque puedan tener una estructura adicional dependiendo de la aplicación por la cual se usa el grafo; por ejemplo, una red semántica es un grafo en donde los vértices representan conceptos o clases de objetos. Grafo Un grafo es una pareja de conjuntos G = (V, A), donde V es el conjunto de vértices, y A es el conjunto de aristas, este último es un conjunto de subconjuntos de la forma (u,v) tal que (u,v) V 2, donde u v. Para simplificar, notaremos la arista (a,b) como ab. En teoría de grafos, sólo queda lo esencial del dibujo: la forma de las aristas no son relevantes, sólo importa a qué vértices están unidas. La posición de los vértices tampoco importa, y se puede variar para obtener un grafo más claro. Generalmente, 30

49 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS se considera que colocar los vértices en forma de polígono regular da grafos muy legibles. Prácticamente cualquier red puede ser modelada con un grafo: una red de carreteras que conecta ciudades, una red eléctrica o un alcantarillado... Subgrafo Un subgrafo de un grafo G es un grafo cuyos conjuntos de vértices y aristas son subconjuntos de los de G. Se dice que un grafo G contiene a otro grafo H es subgrafo de G. Aristas dirigidas y no dirigidas En algunos casos es necesario asignar un sentido a las aristas, por ejemplo, si se quiere representar la red de las calles de una ciudad con sus inevitables direcciones únicas. El conjunto de aristas será ahora un subconjunto de todos los posibles pares ordenados de vértices, con (a, b) (b, a). Las aristas no orientadas se consideran bidireccionales para efectos prácticos (equivale a decir que existen dos aristas orientadas entre los nodos, cada una en un sentido). Las aristas orientadas suelen representarse con forma de flecha en función de la dirección permitida. Figura 2.8: Tipos de aristas de grafos Se considera la característica de grado (positivo o negativo) de un vértice v (y se indica como d(v)), como la cantidad de aristas que llegan o salen de él; para el caso de grafos no orientados, el grado de un vértice es simplemente la cantidad de aristas que tocan este vértice. 31

50 2.5. GRAFOS 32 Según la terminología seguida en algunos problemas clásicos de Investigación Operativa (p.ej.: el Problema del flujo máximo), a un vértice del que sólo salen aristas se le denomina fuente. Por el contrario, a aquellos en los que sólo entran aristas se les denomina pozo o sumidero Caracterización de los Grafos Grafos Simples Un grafo es simple si a lo sumo sólo una arista une dos vértices cualesquiera. Esto es equivalente a decir que una arista cualquiera es la única que une dos vértices específicos. Si no es simple se denomina complejo. Grafos Conexos Un grafo es conexo si cada par de vértices está conectado por un camino; es decir, si para cualquier par de vértices (a, b), existe al menos un camino posible desde a hacia b. Un grafo es fuertemente conexo si cada par de vértices está conectado por al menos dos caminos disjuntos; es decir, es conexo y no existe un vértice tal que al sacarlo el grafo resultante sea disconexo. Es posible determinar si un grafo es conexo: se usa un algoritmo búsqueda de grafos que asegure que, si existe una ruta, la encuentre; como pueden ser Búsqueda en anchura (BFS) o Búsqueda en profundidad (DFS). En términos matemáticos la propiedad de un grafo de ser (fuertemente) conexo permite establecer en base a él una relación de equivalencia para sus vértices, la cual lleva a una partición de éstos en componentes (fuertemente) conexas, es decir, porciones del grafo, que son (fuertemente) conexas cuando se consideran como grafos aislados. Esta propiedad es importante para muchas demostraciones en teoría de grafos. 32

51 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS Figura 2.9: Diferencias entre grafo conexo y no conexo Grafos Completos Un grafo simple es completo si existen aristas uniendo todos los pares posibles de vértices. Es decir, todo par de vértices (a, b) debe tener una arista e que los une. El conjunto de los grafos completos es denominado usualmente K, siendo K n el grafo completo de n vértices el cual tiene exactamente las aristas dadas por la siguiente fórmula: n(n-1) 2 La representación gráfica de los K n como los vértices de un polígono regular da cuenta de su peculiar estructura. Los grafos completos de n vértices, para n entre 1 y 8 son estos: Figura 2.10: Grafos completos 33

52 2.6. RUTAS 34 Grafos ponderados En muchos casos, es preciso atribuir a cada arista un número específico, llamado valuación, ponderación o coste según el contexto, y se obtiene así un grafo valuado. Formalmente, es un grafo con una función v: A R +. Por ejemplo, un representante comercial tiene que visitar n ciudades conectadas entre sí por carreteras; su interés previsible será minimizar la distancia recorrida (o el tiempo, si se pueden prever atascos). El grafo correspondiente tendrá como vértices las ciudades, como aristas las carreteras y la valuación será la distancia entre ellas. Figura 2.11: Ejemplo de grafo 2.6. Rutas Fijemonos en la siguiente imagen que valdrá de ejemplo la red en la que se utilizará de ejemplo para explicar cómo funcionan los algoritmos: Figura 2.12: Red ejemplo 34

53 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS Se puede transformar en formato árbol y dependiendo si el algoritmo emplea costes se puede representar de las siguientes formas, siendo ésta la notación utilizada: Figura 2.13: Árbol de la red ejemplo: Notación sin costes Figura 2.14: Árbol de la red ejemplo: Notación costes Conceptos de rutas Nodo: Serían en el grafo ejemplo S,A,B,C,D,E,F,G. Arco o link: Las uniones entre los nodos. 35

54 2.6. RUTAS 36 Árbol: Grafo conexo que no contiene ciclos. Camino, Rama y Ruta: Secuencia ordenada de nodos de un árbol. Padres, hijos, hermanos, ascendientes y descendientes: Entre los nodos de un grafo se pueden dar relaciones de parentesco dependiendo de cómo estén unidos mediante arcos. Nodo inicio, Nodo raíz: nodo desde que se comienza a buscar una ruta. S en el ejemplo. Nodo final, Nodo destino: Nodo objetivo que se debe buscar. G sería en el ejemplo. Expandir: generar todos los hijos de un nodo. Nodo abierto: Nodo que tiene posibles hijos. Nodo cerrado, Nodo Hoja, Nodo terminal: Nodo que no tiene posibles hijos. Ciclo: Pasar por el mismo nodo más de una vez. Podar: Eliminar una o más ramas de un árbol. Factor de rama: Es el número de hijos que se pueden expandir una rama. Coste: Valor asignado a la arista. Heurística: Para minimizar problemas de coste es muy interesante conocer una aproximación del coste total desde el nodo actual T hasta el nodo destino G dado por una función f(t) que la aproxima, aunque esto no siempre es posible. Figura 2.15: Árbol de la red ejemplo: Heurística 36

55 CAPÍTULO 2. CONCEPTOS PREVIOS Y HERRAMIENTAS UTILIZADAS 2.7. Herramientas de desarrollo GvSIG: gvsig 1.1 gvsig gvsig Compiladores: Java jre + jdk Java jre + jdk Java jre + jdk pdfetex, versión (MiKTeX 2.5) pdflatex 3 Plugins Java necesarios: Java Advanced Imaging Binary Builds Java Advanced Imaging Image I/O Tools Binary Builds Base de datos: PostgreSQL PostGis pgadmin III - PostGreSQL Tools Entorno de trabajo: Eclipse Visual Editor Project (VE) WinEdt v 5.5 UltraEdit 12.20a Adobe Acrobat Professional

56 2.7. HERRAMIENTAS DE DESARROLLO 38 Planificadores: Microsoft Project 2003 Optimizadores: JProfiler 5.0 Gráficos: MagicDraw 12.1 Personal Edition StartUML Dia 0.96 Adobe Photoshop CS2 AcdSee 8.0 Sistemas Operativos: Linux Ubuntu Edgy Eft 6.10 (kernel generic) Linux Ubuntu Feisty Fawn 7.04 (kernel generic) Linux Ubuntu Gusty Gibbon 7.10 (kernel generic) Microsoft Windows XP Professional SP2 (versión ) Presentación: Microsoft PowerPoint 2003 El uso de diferentes versiones puede chocar a primera vista, esto es debido a que durante el transcurso del ciclo de desarrollo, se fuese comprobando la compatibilidad de las nuevas versiones liberadas de gvsig y Java. 38

57 Capítulo 3 Aplicaciones similares 3.1. Proyecto Sextante Sistema EXTremeño de ANálisis TErritorial (SEXTANTE) es el Sistema de Información Geográfica desarrollado por la Junta de Extremadura para satisfacer sus propias necesidades y continuar la línea de avance tecnológico que se viene siguiendo en la Comunidad en los últimos tiempos. SEXTANTE es software libre y se distribuye bajo licencia GPL y persigue estos tres objetivos principalmente: El énfasis principal del sistema es el análisis de información geográfica y con su desarrollo se pretende facilitar tanto el uso como la implementación de algoritmos de análisis. En segundo lugar, se pretende crear un SIG adaptado a las particularidades del campo de la gestión forestal, tratando con detalle áreas como el análisis hidrológico, la ordenación de montes o la simulación incendios forestales, aportando herramientas útiles en todos ellos. Por último, el desarrollo desde la Universidad obliga a buscar un producto con 39

58 3.2. PILOTO DE REDES DE GVSIG 40 marcado carácter didáctico que sirva para la iniciación en el mundo de los SIG y el aprendizaje riguroso de los mismos. Dispone de un conjunto de extensiones (+170) para gvsig, que dotan a éste de todas las capacidades de análisis de la versión 1.0 de SEXTANTE, además de algunas otras nuevas. Se trata de una versión aún en desarrollo, que además se ejecuta sobre un software cuyas capacidades de manejo de datos raster también se encuentran en fase de desarrollo. Por eso, el software puede presentar limitaciones derivadas de ambos componentes, que deben siempre considerarse Piloto de redes de gvsig Es una extensión de los desarrolladores de gvsig (por lo tanto también de código libre) que proporciona herramientas de análisis de cálculo de rutas como la extensión a realizar. Incluye un asistente sobre el cual se intentó imitar, al igual que implementa el algoritmo A* para la resolución. Fue publicada el día cuando este proyecto estaba ya en plena realización, después de una reunión con el tutor se decidió proseguir el plan establecido puesto que el objetivo primordial es aprender; no obstante este hecho produjo un aumento de requisitos (el comparador de algoritmos) con el fin de añadir más valor didáctico al software. Quizás en un futuro, después de liberarlo al público, estos dos proyectos converjan y se fusionen en uno solo adoptando lo mejor de cada uno de ellos Google Earth & Google Maps Sin lugar a dudas es el SIG en la actualidad más popular por la difusión web y sobre todo su facilidad de uso. Google Maps es la versión por entorno web que está desarrollado casi por entero con JavaScript y XML, mientras que Google Earth es la versión desde aplicación software para Windows/Mac/Linux que ofrece vistas 40

59 CAPÍTULO 3. APLICACIONES SIMILARES del Globo terráqueo impactantes aunque ambos necesitan el acceso a una potente base de datos residente en un servidor compartido. Figura 3.1: Google Earth La gran ventaja que incorpora es la comodidad de que se integre con el buscador de la misma empresa Google Inc. indexando mucha información adicional. Paralelamente se están creando múltiples plugins con diferentes utilidades (Capas o Layers) sobre el mapa, entornos 3D, incluso existe ya la cartografía de la Luna y otros planetas. Sobre el tema del que trata este proyecto, el cálculo de rutas, ya lo integra esta aplicación destacando su velocidad y facilidad de uso, puesto que ya incorpora en sus gigantescos servidores los mapas y la mayor parte de las rutas cacheadas (resueltas). En este sentido no pretende competir, ni siquiera es comparable, puesto que para Google hay un gran grupo de ingenieros expertos trabajando desde antes de 2005, año en que fue publicado por primera vez. 41

60 3.3. GOOGLE EARTH & GOOGLE MAPS 42 Figura 3.2: Google Maps La gran desventaja es que en la actualidad es un sistema propietario y por tanto el código cerrado, aunque ya hubo intentos de algunos usuarios, haciendo ingeniería inversa, de desarrollar códigos para aumentar las capacidades de la interfaz de Google Maps. Aunque en 2005 Google lanzó su API de Google Maps, pudiendo modificar casi cualquier aspecto de la interfaz original, no está permitido modificar los algoritmos para resolución de rutas y esto podría ser muy interesante para adaptarlo al caso que se pretende solucionar. Por ejemplo, la elección de rutas óptimas en líneas de autobuses supondría un ahorro grande en muchos términos, como pueden ser la cantidad de carburante, dinero, tiempos de retraso para los pasajeros etc. por lo que la inversión en este sentido está más que justificada. Añadir que Google Earth dispone de diferentes versiones. Una de ella es gratuita y el resto de pago: la versión Plus (20 USD), la versión Pro (400 USD), y la versión Enterprise (precio indeterminado), no siendo posible interaccionar con un sistema GIS si no se adquiere la versión Pro o superior. 42

61 Capítulo 4 Planificación y evaluación de costes Este capítulo hace referencia a cómo se ha planificado la realización del proyecto, y cómo el coste asociado a su elaboración Consideraciones previas En todo proyecto real en el que participen varias personas o que sea crítico hay tres variables que siempre se deben controlar: Tiempo Coste Esfuerzo Un buen analista y futuro ingeniero debe controlarlos, ajustarlos y minimizarlos. Una buena planificación es una condición sine qua non, es decir, para poder tener éxito es imprescindible realizarla correctamente. Además permite ganar en eficiencia, calidad, y saber en todo momento el estado del proyecto. 43

62 4.2. PLANIFICACIÓN INICIAL 44 La planificación de un proyecto muestra sus mejores frutos al coordinar a un grupo significativo de personas. Este proyecto fin de carrera consta de 3 recursos humanos que, como es el caso del autor, pueden desempeñar múltiples roles: programador, analista, diseñador, etc. El tutor interpreta el rol de usuario y consultor interno y el director realiza el papel de consultor externo. La escala temporal de los diagrama de Gantt está en días. Y se supone que el calendario de trabajo es el estándar, es decir, 5 días trabajando 8 horas diarias Planificación inicial La fecha de comienzo es el día , con la primera reunión en la que el tutor explicó a grandes rasgos como iba a ser el desarrollo de la aplicación, de qué constaba, que era gvsig, además de mostrar un especial interés en llevar un diario log que se fuese registrando en él esta información: día, tiempo dedicado en ese día, qué tareas se habían realizado. Atendiendo a la primera norma de la planificación consistente en ser pragmático, que entraña a un proyecto (excepto si es crítico) no puede llevar más tiempo que el desarrollo del mismo sin planificar, se decidió llevarlo de manera informal, realizando un estudio previo y registrando en el log mencionado qué ocurrió en realidad para, una vez concluido, poder comparar. Se hizo un estudio previo con el que alcanzar la consecución de los objetivos marcados, consistente en realizar las siguientes etapas: Identificar los núcleos básicos del proceso: Análisis, Diseño, Programación, Pruebas... Desgranar los núcleos en actividades: Dividir los núcleos de proceso básicos en tareas independientes de tamaño manejable. Cuantificar cada actividad: Consiste en asignar un valor numérico (tiempo o esfuerzo) para que sea realizado. Relacionar las tareas: Cuáles son las dependencias entre las tareas. 44

63 CAPÍTULO 4. PLANIFICACIÓN Y EVALUACIÓN DE COSTES Identificar Recursos: Hay de dos tipos, recursos humanos y recursos materiales. Son actores o roles de los que disponemos (una misma persona puede desempeñar varios roles) donde se debe fijar el horario en el que trabajarán y materiales que disponemos para la consecución de los objetivos. Asignar recursos a las tareas: En qué tarea es preciso cada recurso. Sin lugar a dudas, lo más complicado de una planificación en proyectos de este tipo es la estimación, ya que la variación está sujeta a múltiples factores. Existen métricas que intentan valorar cuánto tiempo, coste y esfuerzo supone un proyecto e incluso estimar cuántas miles de líneas de código (KLOC) o como de complejo será (Puntos Función) el proyecto antes de implementarlo. Todos ellos se basan en estudios estadísticos interpolando historiales de proyectos similares. Como cabe esperar, las planificaciones iniciales suelen ser un poco utópicas, sobre todo si se carece de historiales basados en la experiencia de proyectos similares a pesar de dejar holguras de sobra para intentar neutralizar posibles eventualidades imprevistas Estimación de costes Los costes han valorado a precio de mercado, reflejado en la siguiente tabla: Nombre Recurso Capacidad Máxima Coste Recurso Director 20 % 25 e/h Tutor 10 % 25 e/h Analista 60 % 20 e/h Diseñador 100 % 18 e/h Programador 100 % 15 e/h 45

64 4.2. PLANIFICACIÓN INICIAL Estimación previa El resultado de la planificación inicial, después de identificar los núcleos básicos del proceso, dividirlo en un número de tareas, cuantificar cada actividad, asignar los recursos a las tareas implicadas y calcular las dependencias, es el siguiente: Cabe destacar que la fecha prevista de exposición estaba planteada a día de , es decir aproximadamente 6 meses y medio desde la primera reunión inicial. La primera estimación es de horas de trabajo, 720 horas de tiempo y un coste asociado de e, y que aunque 4 recursos (Analista, Programador, Diseñador, Tutor) estaban sobreasignados en tiempo, era asumible, teniendo en cuenta la holgura final antes de la exposición, y en el peor de los casos se utilizarían horas extras. Figura 4.1: Diagrama de Gantt: Estimación inicial 46

65 Planificacion PFC_2 FIC desde jue 15/03/07 CAPÍTULO 4. PLANIFICACIÓN Y EVALUACIÓN DE COSTES Fechas Comienzo: jue 15/03/07 Fin: mar 02/10/07 Comienzo previsto: NA Fin previsto: NA Comienzo real: NA Fin real: NA Variación de comienzo: 0 horas Variación de fin: 0 horas Duración Programada: 720 horas Restante: 720 horas Prevista: 0 horas? Real: 0 horas Variación: 720 horas Porcentaje completado: 0% Trabajo Programado: 1.113,1 horas Restante: 1.113,1 horas Previsto: 0 horas Real: 0 horas Variación: 1.113,1 horas Porcentaje completado: 0% Costos Programados: ,25 Restantes: ,25 Previstos: 0,00 Reales: 0,00 Variación: ,25 Estado de las tareas Estado de los recursos Tareas aún no comenzadas: 50 Recursos de trabajo: 1 Tareas en curso: 0 Recursos de trabajo sobreasignados: 4 Tareas finalizadas: 0 Recursos materiales: 0 Total de tareas: 50 Total de recursos: Seguimiento El objetivo del seguimiento final es comparar la previsión inicial y contrastarla con la real para aprender de la experiencia, buscando las desviaciones e interpretando el suceso que las originó. Se ha producido una serie de sucesos que han variado la primera estimación, causados principalmente por: Problemas con la comprensión del dominio. Problemas con la herramienta Eclipse. Problemas de implementación en funciones muy complejas (Por ejemplo la de TrocearAction). Recursos sobrecargados. Incompatibilidad de horarios. 47

66 4.3. SEGUIMIENTO 48 Alguna dependencia no planificada. Mala estimación de tiempo de Recopilar Documentación. Mala estimación de tiempo de Redacción de la Memoria. Mala estimación de tiempo de Implementar Interfaces. Cambio de fecha de entrega del a Aumento de requisitos, análisis, diseño y pruebas para añadir más valor al software. Este ha sido el resultado final, después de una minuciosa reconstrucción a partir del registro, que a fecha de proporciona la siguiente información: Figura 4.2: Diagrama de Gantt: Estimación real 48

67 Planificacion PFC_2 FIC desde sáb 12/01/08 CAPÍTULO 4. PLANIFICACIÓN Y EVALUACIÓN DE COSTES Fechas Comienzo: jue 15/03/07 Fin: jue 17/01/08 Comienzo previsto: jue 15/03/07 Fin previsto: mar 02/10/07 Comienzo real: jue 15/03/07 Fin real: NA Variación de comienzo: 0 horas Variación de fin: 382 horas Duración Programada: 1102 horas Restante: 30,44 horas Prevista: 720 horas Real: 1071,56 horas Variación: 382 horas Porcentaje completado: 97% Trabajo Programado: horas Restante: 17,5 horas Previsto: 1.113,1 horas Real: 1.498,5 horas Variación: 402,9 horas Porcentaje completado: 99% Costos Programados: ,56 Restantes: 381,00 Previstos: ,25 Reales: ,56 Variación: 8.792,31 Estado de las tareas Estado de los recursos Tareas aún no comenzadas: 1 Recursos de trabajo: 3 Tareas en curso: 5 Recursos de trabajo sobreasignados: 2 Tareas finalizadas: 44 Recursos materiales: 0 Total de tareas: 50 Total de recursos: 5 El coste total real del proyecto asciende a e, la duración a 1102 horas reales, y el trabajo real total a 1516 horas. Si lo comparamos con respecto a la línea base supone aproximadamente un 31 % más de coste, un 26 % más de trabajo y un 53 % más de tiempo, debido a las causas antes mencionadas y principalmente por el aumento de requisitos. Ahora veamos lo que le correspondería el desglose de horas y coste por perfil: Nombre Recurso Trabajo Real Coste Recurso Coste Real Director 209 horas 25 e/h e Tutor 73 horas 25 e/h e Analista 339 horas 20 e/h e Diseñador 166 horas 18 e/h e Programador 734 horas 15 e/h e TOTAL horas e 49

68

69 Capítulo 5 Metodología La metodología empleada para la realización de este proyecto es una Metodología de Prototipado Rápido (MPR) Definición de MPR La Metodología de Prototipado Rápido, MPR, está orientada al desarrollo de prototipos y fuertemente apoyada en tecnología de Bases de Datos y herramientas visuales para Desarrollo Orientado a Objetos. En MPR se concentra un gran esfuerzo en la involucración del Usuario en dos fases fundamentales: la definición del problema que se va a abordar y en la ejecución de las pruebas, donde además se potencia el uso de lenguajes de cuarta generación utilizados como lenguajes de consulta para verificar la estructura y funcionalidad del prototipo desarrollado, asegurándose de que su diseño responde a las definiciones especificadas. Como se ha expuesto, la idea fundamental de MPR es el desarrollo de prototipos. Un prototipo es un modelo inicial de lo que al final se corresponderá con la Base de Datos definitiva y sus procedimientos asociados. Este prototipo se someterá a pruebas para comprobar su funcionalidad, de las que surgirán modificaciones que darán origen a un segundo prototipo, versión mejorada y posiblemente ampliada del primero, el cual se volverá a probar, repitiéndose sucesivamente el proceso hasta alcanzar el prototipo definitivo. 51

70 5.2. REPRESENTACIÓN GRÁFICA DE MPR 52 La responsabilidad y ejecución de estas pruebas fundamentalmente recae, como ya se ha mencionado, en el propio usuario, quien deberá de comprobar que el prototipo resultante es capaz de resolver todos los problemas planteados en el momento de la definición de las especificaciones del proyecto Representación gráfica de MPR Para representar MPR en su mayor grado de abstracción, se hace uso de un diagrama SADT 1 en el que se muestran las seis fases de las que se compone. Planes de trabajo Aplicaciones existentes Definición de Especificaciones Macromodelo de actividades Especificaciones detalladas y documentación Detalle de las especificaciones Diseño Conceptual Descripción de Entradas / salidas Herramientas de modelado Modelo de datos Desarrollo del Prototipo Prototipo normalizado Prototipo normalizado Lenguajes de desarrollo Pruebas del Usuario Datos resultantes Lenguajes no procedimentales y de consultas Implantación Resultados analizados Resultados analizados Auditoría y Seguimiento Informes Figura 5.1: Metodología Prototipado Rápido La simbología empleada en el diagrama es la siguiente: cada una de las cajas representa algo que hay que hacer, en este caso una fase de la Metodología. A una caja pueden llegar flechas por su lado izquierdo (entradas necesarias para ejecutar la fase), por su parte superior (causas por las que se realiza una fase) y por su parte inferior (herramientas y técnicas con las que se hace lo indicado en la fase). Asimismo, por su parte derecha salen flechas que muestran algo que se ha obtenido 1 SADT: Structured Analysis And Design Technique 52

71 CAPÍTULO 5. METODOLOGÍA en la fase y que pasa normalmente a la fase siguiente o sale directamente fuera del sistema, indicando un producto ya terminado y que no necesita más procesos. Desde cada fase de la Metodología se puede volver a cualquiera de las fases anteriores. En el diagrama SADT se han omitido voluntariamente estas conexiones para facilitar su estudio Descripción detallada de las fases [Fase 1] Definición de especificaciones: Esta primera fase tiene por objeto auditar la información relativa al problema, con el fin de recabar todos los datos necesarios para su resolución. Como primera tarea podrá ser necesario realizar un estudio de la viabilidad del proyecto, para determinar y justificar la necesidad del mismo. A continuación se hará un análisis previo con el fin de establecer la amplitud y el calendario del proyecto, estimándose el esfuerzo necesario y el tiempo de desarrollo, e identificando los procesos involucrados en el mismo. A continuación se construirá un prototipo inicial, no necesariamente operativo, construyéndose macromodelos de actividad para cada uno de los procesos identificados en la actividad anterior. La intención es disponer de la información necesaria para recabar la aprobación necesaria para comenzar el desarrollo. Se trata, en suma, de obtener la mayor cantidad de información posible sobre el problema que se intenta resolver, para obtener un tiempo estimado de desarrollo del proyecto y sus costes asociados, con el fin de obtener la aprobación necesaria para llevarlo a cabo. Como final de esta fase, y de todas las demás fases, se emitirá un informe para la Dirección del Proyecto. [Fase 2] Diseño conceptual: El objetivo de esta fase es construir un modelo de información que refleje el esquema conceptual del prototipo. Es muy importante que este modelo esté lo más ajustado posible a la realidad para que el diseño posterior de la Base de Datos pueda cumplir con sus objetivos. 53

72 5.3. DESCRIPCIÓN DETALLADA DE LAS FASES 54 Se realizarán entrevistas a los Usuarios y se estudiará y diseñará el primer prototipo operativo, determinando sus puntos fuertes y sus puntos débiles, y se documentarán todas sus funcionalidades. También en esta fase se prepararán los planes de implantación, formación y pruebas, y se desarrollará el Manual del Usuario y el Manual Técnico. [Fase 3] Desarrollo del prototipo: Como su nombre indica, esta fase tiene por objeto la construcción del primer prototipo operativo de la Aplicación. Esta fase consta de dos actividades principales, una de desarrollo técnico propiamente dicho y otra para desarrollar la documentación asociada. Al finalizar esta fase se dispondrá de un prototipo totalmente funcional y operativo, que será sometido a múltiples pruebas en la siguiente fase para comprobar su validez. [Fase 4] Pruebas del Usuario: En esta fase se realizarán todas las pruebas necesarias para validar el prototipo desarrollado en la fase anterior. Si como resultado de estas pruebas se detectara la necesidad de modificar el prototipo, para corregir defectos o para añadirle funcionalidad, se volverá a la fase anterior y se realizarán todas las iteraciones necesarias hasta que el Usuario se sienta satisfecho con el prototipo y compruebe que responde a las especificaciones que se habían alcanzado inicialmente. Las pruebas en esta fase pueden ser de dos tipos: pruebas dirigidas, donde los desarrolladores guían y asesoran al usuario durante las mismas, y pruebas no dirigidas, donde el Usuario actúa libremente y sin la presencia del desarrollador/es. [Fase 5] Implantación: En esta fase se ejecutará el Plan de Formación de los Usuarios y se llevará a cabo el proceso de migración al entorno de ejecución real de la aplicación. Una vez completada la migración, se realizarán las pruebas finales y se llevarán a cabo las actividades correctoras finales, revisándose de paso toda la documentación del proyecto. Como final de esta fase se deberá de obtener la aceptación del Usuario y se emitirá un informe para la Dirección del Proyecto. 54

73 CAPÍTULO 5. METODOLOGÍA [Fase 6] Auditoría y Seguimiento: La última de las fases de MPR consiste en realizar una Auditoría del rendimiento y la calidad de la Aplicación, y de determinar y canalizar los mecanismos necesarios para realizar peticiones de modificación y para que estas sean llevadas a cabo por los Equipos de Mantenimiento. Se deberán de identificar parámetros de rendimiento, compromisos de uso / respuesta, verificar la calidad global de la aplicación y efectuar las medidas correctoras oportunas. Como fin de fase, se comprobará que toda la documentación es la adecuada, y se obtendrá la aprobación definitiva del Usuario. 55

74

75 Capítulo 6 Análisis 6.1. Captura de requisitos La captura de requisitos es un proceso crítico para la elaboración de software, porque la gran mayoría de problemas del desarrollo software son causados por pobre la comprensión de lo que realmente quiere el usuario. Partimos de la siguiente descripción inicial del proyecto: Uno de los tipos de información más importantes en los sistemas de información geográfica son las redes, por ejemplo la red de carreteras, la red eléctrica o la red de abastecimiento de agua. Una de las funcionalidades más necesarias es el cálculo de determinadas características de la red. Sin embargo, las herramientas de software libre existentes en la actualidad no incorporan esta funcionalidad. El objetivo del proyecto es un diseño e implementación de una herramienta que permita el cálculo de estas características para cualquier red. Entre las características a calcular podemos mencionar la longitud y ancho de los tramos, la sinuosidad y las pendientes, o cálculos específicos de un tipo de red como pueden ser el cálculo de puntos kilométricos en una red de carreteras. 57

76 6.1. CAPTURA DE REQUISITOS Prototipado Un prototipo consiste según Pressman [8] en una aproximación hecha con chicles y alambres adecuado cuando no se sabe exactamente lo que se quiere construir, generalmente debido a que: el cliente/usuario no sabe exactamente lo que quiere. el analista no está seguro de la eficiencia de una aproximación o tiene dudas del dominio. existen dudas en la interfaz hombre-máquina, etc. Figura 6.1: El paradigma de construcción de prototipos El paradigma de construcción de requisitos comienza escuchando al usuario/cliente: se corresponde con la recolección de requisitos. se definen los objetivos globales del sistema. se identifican los requisitos conocidos y las áreas donde se precisa una mayor definición. Esto lleva a construir y revisar el prototipo: se realiza un desarrollo rápido centrado en los aspectos del software visibles para el usuario/cliente: formatos de entrada, formatos de salida, pantallas, etc. 58

77 CAPÍTULO 6. ANÁLISIS este desarrollo rápido conforma el prototipo elaborado en este ciclo. Una vez construido, el usuario/cliente prueba el prototipo: el prototipo es evaluado por el cliente/usuario. esta evaluación permite refinar los requisitos del software. este refinamiento es la entrada al siguiente ciclo del modelo de prototipado. En la mayoría de los casos el prototipo será demasiado lento, demasiado grande o demasiado torpe en su uso o las tres a la vez. Idealmente, se debe desechar el prototipo y empezar de nuevo. El prototipo sólo debe servir para identificar los requisitos del software cuando estos no estén claros. Para este proyecto se realizaron dos prototipos para extraer requisitos cuando estos no están claros: En el primero de ellos su único cometido era entender el desarrollo de una extensión simple que mostrase al usuario un Hola mundo. Podría parecer a simple vista muy sencillo una vez que comprendiese el interior de cómo funciona, pero supuso problemas de compilación, de fuentes, ajustar parámetros del Eclipse, entender cómo funciona el automatizador de tareas Ant, definir como realizar un repositorio de fuentes. Una vez logrado, el siguiente paso fue realizar un prototipo más avanzado para entender cómo funcionaban las interfaces en un entorno como Java el cual no se desconocía y su cometido sería hacer de interfaz SQL con el que acceder a la BD de forma manual. Al realizar este experimento se vio preciso integrar un entorno visual para desarrollar interfaces de forma que fuera más simple y fueran más uniformes; también quedó claro la necesidad de usar patrones para interaccionar con la BD para que fuera fácilmente adaptable a otros gestores. Como curiosidad este fue el resultado del prototipo, que al final fue desechado a excepción de alguna pequeña función reutilizable. 59

78 6.2. DEFINICIÓN DE ESPECIFICACIONES 60 Figura 6.2: Prototipo Consultas SQL 6.2. Definición de especificaciones Después de varias reuniones y los prototipos mencionados, se modificaron las especificaciones iniciales entrándose en el cálculo de rutas. Se trata de implementar en gvsig herramientas que resuelvan los problemas con redes. Por red se entiende un sistema interconectado de elementos lineales (carreteras, líneas telefónicas, líneas eléctricas, etc.). Modo desarrollador <<component>> Análisis de redes <<use>> <<use>> Usuario gvsig <<database>> PostgreSQL + PostGIS Figura 6.3: Requisitos usuario 60

79 CAPÍTULO 6. ANÁLISIS Cálculo de rutas óptimas El objetivo de esta función es encontrar la ruta más rápida o la más corta entre un punto de partida y uno de llegada. La selección de la capa de puntos empleados se realizará a través de un interfaz, análogamente con la capa de líneas. Mediante esta herramienta el usuario ha de poder seleccionar el número de paradas o puntos intermedios de la ruta, en caso de haberlos. Las paradas seleccionadas deben marcarse como gráficos en pantalla, de modo que sea fácil su localización visual. Debe existir un orden de paradas a visitar de todos los nodos (punto de partida, punto intermedio 1, punto intermedio 2,..., punto final) Debe existir la posibilidad de guardar las rutas como nuevos temas. Su forma de funcionamiento debería ser iterativa, donde a modo gráfico va realizando preguntas al usuario para poderse ejecutar. Sería deseable realizar procesos por lotes si hay que realizar la misma tarea repetitivamente utilizando gran cantidad de información. Debe proporcionar informes de rutas, que podamos visualizar y exportar la información deseada en diferentes formatos como pueden ser: PDF, tabla e Imagen. Implícitamente se sobreentiende al usuario que las interfaces, deben ser útiles, homogéneas y fáciles de manejar. Comparativa entre algoritmos. [Añadido] Aprovechando lo implementado, desarrollar un comparador de algoritmos que cuantifique, valore y represente qué algoritmo proporciona mejores prestaciones en tiempo, número de iteraciones, éxito de resolución. Asistente. [Añadido] Con el fin de facilitar la labor al usuario, sería deseable una interfaz guiada con la que después de unos sencillos pasos se obtenga el resultado. 61

80 6.3. CASOS DE USO Casos de uso <<include>> System <<include>> Añadir Nodos Añadir Arcos Configurar <<include>> <<include>> <<include>> Ver Asistente <<include>> <<extend>> Configuración <<include>> Guardar Configuración <<extend>> <<include>> Recuperar Configuración <<include>> <<include>> <<include>> Consultar SQL Usuario Trocear Grafo <<include>> <<extend>> <<extend>> <<extend>> <<extend>> Crear Informe Crear Capa Gvsig <<include>> Ver Memoria Grafo <<extend>> Resolver Ruta Cargar Grafo de Ruta <<include>> <<extend>> <<extend>> Ver Controlador Grafo <<extend>> Cargar Grafo Ejemplo Estadisticas <<include>> <<extend>> Monitoriza Grafo Seleccionar Algoritmo <<include>> Crear Grafo Nuevo <<include>> Ver Estadisticas <<include>> Comparar Algoritmos Generar Grafo Aleatorio <<include>> <<extend>> <<extend>> Paradas Redes <<extend>> Seleccionar Paradas Parada Mover Arriba Listar Redes Crear Red <<extend>> <<extend>> <<extend>> <<extend>> Añadir Parada Cambiar Orden Parada Cargar Red <<extend>> Borrar Parada Parada Mover Abajo Borrar Red Figura 6.4: Diagrama de casos de uso 62

81 CAPÍTULO 6. ANÁLISIS Descripción de lo que debe realizar cada caso de uso: Ver Asistente: Este caso de uso es una interfaz que de forma guiada ayuda al usuario novel para hacer un cálculo de rutas sin apenas conocimientos. Configurar: Lanza la interfaz gráfica para que el usuario pueda seleccionar los parámetros que utilizará la aplicación. Añadir Nodos: Selecciona los puntos cartográficos que el usuario quiere utilizar. Añadir Arcos: Selecciona las líneas que el usuario quiere emplear. Guardar Configuración: Es el caso de uso encargado de almacenar las configuraciones de forma estática y de cifrar la información sensible (como es el caso de la clave) para que no sea legible a simple vista. Recuperar Configuración: Es el caso de uso encargado de recuperar la información estática y descifrar la información confidencial. Consulta SQL: Permite interacionar sobre una base de datos, realizando consultas en formato SQL desde una interfaz amigable. En algunos modos permite realizar operaciones de creación, actualización e inserción. Crear Capa GvSig: Añade a la tabla de contenidos (ToC) de GvSig una capa de Geometrías. Trocear Grafo: Es la interfaz encargada de segmentar y opcionalmente salvar sobre la base de datos las geometrías calculadas con que crear un grafo de ruta. Ver Memoria: Lanza este documento en formato PDF con la aplicación asociada a la extensión. Ver Controlador de Grafo: Visualiza el grafo generado. Seleccionar algoritmo: Elección del método de resolución de grafos el usuario quiere emplear para ese caso particular. Resolver Ruta: Ejecuta sobre el grafo cargado previamente un algoritmo. 63

82 6.3. CASOS DE USO 64 Comparar algoritmo: Configura una muestra de casos de grafos aleatorios, que aplica sobre los diferentes algoritmos seleccionados sobre el mismo grafo proporciona una información estadística. Cargar Grafo de Ruta: Recupera parte o toda la red guardada en la base de datos dependiendo de la configuración. Cargar Grafo ejemplo: Carga un grafo con él que realizar pruebas y jugar con el. Generar Grafo aleatorio: Crea un nuevo grafo aleatorio dependiendo de unos parámetros conocidos como es el número de nodos y densidad del grafo. Seleccionar Paradas: Gestiona las paradas. Añadir Parada: Crea una parada nueva, añadiéndola a la lista de paradas y marcándola sobre GvSig si se ha arrancado desde él. Borrar Parada: Suprime una parada de la lista, actualizando si es preciso. Cambiar Orden de Parada: Modifica el orden existente de ruta. Se especializa en dos tipos: Parada Mover Arriba y Parada Mover Abajo. Parada Mover Arriba: Modifica el orden de una parada hacia la cabeza de la lista en una posición. Si ya es la cabeza de la lista no hace nada. Parada Mover Abajo: Modifica el orden de una parada hacia el final de la lista. Si es el último no hace nada. Listar Redes: Gestiona las redes existentes consultando a la base de datos. Crear Red: Añade una nueva red vacía a la Lista de Redes. Borrar Red: Suprime una red de la lista de redes. Cargar Red: Recupera el contenido de la red. 64

83 Capítulo 7 Diseño 7.1. Contexto Para diseñar la extensión a realizar primero hay que conocer la estructura interna de gvsig. Figura 7.1: Estructura interna de gvsig 65

84 7.1. CONTEXTO 66 Tiene tres partes claramente diferenciadas: ANDAMI: Aplicación base extensible mediante plugins. Se encarga de crear las ventanas, cargar y gestionar las extensiones, seleccionar el look & feel adecuado, habilitar el inicio de la aplicación mediante Java Web Start, inicializar el idioma de la aplicación, etc. Workbench extensible utilizable para cualquier tipo de aplicación MDI (esté o no relacionada con el GIS). FMAP: Biblioteca de clases que permite crear aplicaciones GIS a medida. Incluye un núcleo interno ( core ) con los objetos de bajo nivel necesarios para su funcionamiento y entidades Java2D modificadas junto con los conversores adecuados y un conjunto de objetos para trabajar con esas entidades. Dentro de esta biblioteca encontramos clases para leer y escribir los formatos soportados, dibujar los mapas a las escalas adecuadas, asignar leyendas, definir simbologías, realizar búsquedas, consultas, análisis, etc. Los drivers (lectores/escritores) de formatos se incluyen dentro de este apartado. También es el encargado de: Dibujar las capas (raster y vectoriales), asignando la simbología adecuada. Realizar consultas alfanuméricas y gráficas. Realizar análisis del tipo buffer a una entidad, recortes de temas, etc. Transformación de coordenadas entre los distintos sistemas de referencia. GUI: Extensiones a la aplicación base que contienen además todo lo necesario para interactuar con el usuario. En esta librería de clases encontraremos la mayor parte de cuadros de diálogo que utiliza la aplicación final, así como las clases de soporte a esos cuadros de diálogo. Por ejemplo, aquí se encuentran los formularios para asignar leyendas, crear mapas, definir escalas, etc. Implementa las funcionalidades de los menús, botones y herramientas, pasando por todo tipo de cuadros de diálogo. El motivo de separarlo por completo es facilitar el desarrollo de otras aplicaciones con una apariencia totalmente distinta a la original. 66

85 CAPÍTULO 7. DISEÑO Arquitectura Interna gvsig PLUGINS LIBRERÍAS Workbench ANDAMI gvsig 3D DEM FMap Cresques JTS Geotools Batik ermapper, Castor, JEP, Log4java and Others Figura 7.2: Estructura de GvSig desde el punto de vista del desarrollador Los drivers vectoriales entregan las entidades GIS como objetos del modelo interno de datos (core), y con estos objetos trabaja el resto de módulos. Dentro de este módulo existen también funciones de conversión entre entidades adecuadas al dibujado rápido y entidades JTS, adecuadas para crear topología, realizar análisis complicados, etc. El núcleo o Core de gvsig contiene los objetos básicos necesarios para construir aplicaciones geográficas, proporciona interfaces, métodos y objetos para facilitar el trabajo del desarrollador. Los datos geográficos se organizan en capas, cuando se trabaja con un proyecto se puede ver un listado de estas en el TOC. Dispone de librerías compartidas como pueden ser las librerías genéricas que pueden ser empleadas en cualquier otro proyecto GIS: FMap, Cresques, WMSClient... Existe un plugin de igual nombre que la aplicación, que usa las librerías y que convierte al Workbench en la aplicación gvsig. 67

86 7.1. CONTEXTO 68 Un desarrollador puede hacer modificaciones a la aplicación, añadir nuevas funcionalidades en forma de nuevos plugins, o crear una aplicación totalmente distinta que no use ANDAMI. En el código fuente, en el directorio de DEMO se incluye una demostración de una aplicación simple que se usa para hacer pruebas. En un gran trabajo realizado por Ángel Rodríguez Fernández [9], tras realizar ingeniería inversa sobre las fuentes de gvsig, describe perfectamente el funcionamiento de creación de capas, que vamos a citar a continuación. querybypoint(), querybyrect(), querybyshape() FLyrVect <<Interfaz>> Selectable getselecction() FBitSet getsource() getrecordset() +clearselection() +boolean isselected( int ) +setselection( FBitSet ) implements BitSet +and( BitSet set ) +int cardinality()... <<Interfaz>> ReadableVectorial getdriver() getrecordset() SlectableDataSource +String[] getfieldnames() +Value[] getrow() +int getfieldcount() +getrowcount() getdatasourcefactory() <<Implements>> DataSourceFactory... <<Interfaz>> VectorialDriver +DriverAtributes getdriveratributes() +IGeometry getshape( int ) +int getshapecount() +int getshapetype() <<Interfaz>> Driver +String getname() <<Interfaz>> DataSource getdriver()... Figura 7.3: Diagrama de clases: FLyrVect El diagrama de clases está representada por la clase View, hija de BaseView que a su vez implementa a la interfaz IWindow. La interfaz IWindow debe ser implementada por las ventanas internas que se quieran crear y que Andami maneje. Otra condición que debe cumplir una ventana de gvsig es ser descendiente de JPanel, en este caso View cumple estas dos condiciones ya que hereda de BaseView que a su vez hereda de JPanel. A partir de la clase View se puede obtener su MapControl que representa la ventana de visualización, por eso hereda de JComponent. 68

87 CAPÍTULO 7. DISEÑO Las capas se organizan en una estructura recursiva análoga a la de las carpetas y ficheros. La interfaz FLayer es implementada por la clase abstracta FLyrDefault, sus hijos serán FLyrVect representando a una capa vectorial, y FLayers representando a una capa contenedor que en su interior tendrá una serie de clases FLayer, y como estas pueden ser otra vez FLayers y FLyrVect se pueden organizar en distintos niveles jerárquicos. JComponent JPanel View TOC MapControl getmapcontrol() BaseView gettoc() getiprojection() <<Interfaz>> IProjection getprojection() getmodel() implements <<Interfaz>> IWindow +WindowInfo getwindowinfo() getprojection() <<Interfaz>> IProjectView getmapcontext() getlayers() MapContext +selectbyshape( IGeometry g, int relationship ) +selectfromselection() getmapcontext() FLayers +addlayer( FLayer ) FLyrDefault FLyrVect getvisibles(), getactives() getparent() implements <<Interfaz>> FLayer +String getname() +txmlentity getxmlentity() +boolean isactive() +boolean isavailable() +boolean isintoc() +setactive( boolean ) +setavailable( boolean ) +setvisible( boolean ) Figura 7.4: Diagrama de clases: Capas 69

88 7.1. CONTEXTO 70 Las capas vectoriales lógicamente tendrán una información guardada sobre las formas y datos que albergan. En el diagrama de clases de la figura se puede ver cómo cada capa vectorial tiene asociado un driver vectorial que es representado por la clase VectorialDriver, este proporciona métodos para acceder a las geometrías que albergan, y que gvsig representa con la interfaz IGeometry. GeneralPathX +append( PathIterator, boolean connect ) +append( java.awt.shape, boolean connect ) +curveto(... ) +boolean isclosed() +lineto( double x, double y ) +moveto( double x, double y ) +quadto(... ) +reset() <<Interfaz>> Handler +Point2D getpoint() +move( double x, double y ) +set( double x, double y ) * gethandlers() * getselecthandlers() getstretchinghandlers() <<Implements>> <<Interfaz>> java.awt.shape +boolean contains( double x, double y ) +boolean contains( Rectangle2D ) +PathIterator getpathiterator( AffineTransform ) +boolean intersects( Rectangle2D r ) getpathiterator() PathIterator +int currentsegment( double[] coords ) +boolean isdone() +next() * 1 <<Interfaz>> IGeometry +int getgeometrytype() +Handler[] gethandlers( int type ) +Shape getinternalshape() getgeometries() 1 FGeometryCollection implements <<Implements>> FMultiPoint2D implements FGeometry 1 1 <<Interfaz>> FShape +Handler[] getselecthandlers() +Handler[] getstretchinghandlers() +int getshapetype() <<Implements>> 1 +IGeometry getgeometries() * <<Implements>> FPoint2D FPolyLine2D FPolygon2D Figura 7.5: Diagrama de clases: IGeometry Las geometrías de gvsig son todas implementaciones de la interfaz IGeometry y esta a su vez es hija de Shape, por lo que también puede ser descrita por un PathIterator. Las dos implementaciones de IGeometry son FGeometry y FMultiPoint. FGeometry se construye a partir de la interfaz FShape, esta interfaz es implementada por la clase FPoint2D y FPolyLine2D que representan un punto y una red respectivamente. FPolygon2D surge de la especialización de la clase FPolyLine2D de la cual es hijo directo, y se puede considerar como una polilínea con relleno (polígonos). FMultipoint representa un conjunto de puntos, es decir contiene un número de puntos FPoint2D. 70

89 CAPÍTULO 7. DISEÑO 7.2. Diseño conceptual El diseño del sistema es la estrategia de alto nivel para resolver problemas y construir una solución. Éste incluye decisiones acerca de la organización del sistema en subsistemas, la asignación de subsistemas a componentes hardware y software, y decisiones fundamentales conceptuales y de política que son las que constituyen un marco de trabajo para el diseño detallado. La organización global del sistema es lo que se denomina la arquitectura del sistema. Existe un cierto número de estilos frecuentes de arquitectura, cada uno de los cuales es adecuado para ciertas clases de aplicaciones. El diseño de sistemas es la primera fase de diseño en la cual se selecciona la aproximación básica para resolver el problema. Durante el diseño del sistema, se decide la estructura y el estilo global. La arquitectura del sistema es la organización global del mismo en componentes llamados subsistemas. La arquitectura proporciona el contexto en el cual se toman decisiones más detalladas en una fase posterior del diseño. Al tomar decisiones de alto nivel que se apliquen a todo el sistema, el diseñador desglosa el problema en subsistemas, de tal manera que sea posible realizar más trabajo por parte de varios diseñadores que trabajarán independientemente en distintos subsistemas. Los Patrones de Diseño (Design Patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Los patrones del diseño tratan los problemas del diseño que se repiten y que se presentan en situaciones particulares del diseño, con el fin de proponer soluciones a ellas. Por lo tanto, los patrones de diseño son soluciones exitosas a problemas comunes. Existen muchas formas de implementar patrones de diseño. Los detalles de las implementaciones son llamados estrategias. Un patrón de diseño es una solución a un problema de diseño no trivial que es efectiva (ya se resolvió el problema satisfactoriamente en ocasiones anteriores) y reusable (se puede aplicar a diferentes problemas de diseño en distintas circunstancias). Durante el análisis hemos analizado el dominio del problema para construir un modelo del mundo real utilizando objetos. Hemos investigado para llegar a conseguir una descripción del problema y obtención de los requerimientos. El diseño consiste 71

90 7.2. DISEÑO CONCEPTUAL 72 en el refinamiento de los modelos de análisis para crear especificaciones adicionales que enriquecen el modelo de análisis con detalles próximos a la implementación. Una solución lógica, de forma que se cumplan los requerimientos (asignación de responsabilidades, interacciones entre objetos, etc.) Para nuestra fase de diseño hemos empleado una serie de patrones. El patrón arquitectónico MVC(Model View Controller), y los patrones de datos: DAO (Data Access Object), VO (Value Object), Factory y el Patrón Singleton Patrón Model-View-Controller En el patrón Model-View-Controller (Modelo-Vista-Controlador, en adelante MVC), el flujo de la aplicación está dirigido por un Controlador central. El Controlador delega solicitudes a un manejador apropiado. Los manejadores están unidos a un Modelo, y cada manejador actúa como un adaptador entre la solicitud y el Modelo. El Modelo representa, o encapsula, un estado o lógica de negocio de la aplicación. Luego el control normalmente es devuelto a través del Controlador hacia la Vista apropiada. El reenvío puede determinarse consultando los conjuntos de mapeos, normalmente cargados desde una base de datos o un fichero de configuración. Esto proporciona un acoplamiento cercano entre la Vista y el Modelo, que puede hacer las aplicaciones significativamente más fáciles de crear y de mantener. MVC divide una aplicación interactiva en 3 áreas: procesamiento, salida y entrada. Para esto, utiliza las siguientes abstracciones: Modelo (Model): Encapsula los datos y las funcionalidades. El modelo es independiente de cualquier representación de salida y/o comportamiento de entrada. Vista (View): Muestra la información al usuario. Obtiene los datos del modelo. Pueden existir múltiples vistas del modelo. Cada vista tiene asociado un componente controlador. Controlador (Controller): Reciben las entradas, usualmente como eventos que codifican los movimientos o pulsación de botones del ratón, pulsaciones de teclas, etc. Los eventos son traducidos a solicitudes de servicio ( service request en el texto original) para el modelo o la vista. El usuario interactúa con el sistema a través de 72

91 CAPÍTULO 7. DISEÑO los controladores. Las Vistas y los Controladores conforman la interfaz de usuario. Un mecanismo de propagación de cambios asegura la consistencia entre la interfaz y el modelo. La separación del modelo de los componentes vista y del controlador permite tener múltiples vistas del mismo modelo. Si el usuario cambia el modelo a través del controlador de una vista, todas las otras vistas dependientes deben reflejar los cambios. Por lo tanto, el modelo notifica a todas las vistas siempre que sus datos cambien. Las vistas, en cambio, recuperan los nuevos datos del modelo y actualizan la información que muestran al usuario. El MVC es un patrón ampliamente utilizado en múltiples plataformas y lenguajes. Algunos de sus principales beneficios son: Menor acoplamiento - Desacopla las vistas de los modelos. - Desacopla los modelos de la forma en que se muestran e ingresan los datos. Mayor cohesión - Cada elemento del patrón esta altamente especializado en su tarea (la vista en mostrar datos al usuario, el controlador en las entradas y el modelo en su objetivo de negocio) Las vistas proveen mayor flexibilidad y agilidad - Se puede crear múltiples vistas de un modelo. - Se puede crear, añadir, modificar y eliminar nuevas vistas dinámicamente. - Las vistas pueden anidarse. - Se puede cambiar el modo en que una vista responde al usuario sin cambiar su representación visual. - Se puede sincronizar las vistas. - Las vistas pueden concentrarse en diferentes aspectos del modelo. Mayor facilidad para el desarrollo de clientes ricos en múltiples dispositivos y canales - Una vista para cada dispositivo que puede variar según sus capacidades. 73

92 7.2. DISEÑO CONCEPTUAL 74 Más claridad de diseño Facilita el mantenimiento Mayor escalabilidad Un patrón de arquitectura puede contener varios patrones de diseño. Vamos a citar para el patrón arquitectónico Model-View-Controller qué patrones de diseño contiene contiene en nuestro caso. package Data [ Clases Alto Nivel ] mau.extanalisisred.* mau.extanalisisred.controller Librerias externas com.iver.andami.* com.iver.cit.gvsig.fmap.* com.iver.utiles.* <<use>> mau.extanalisisred.model DAO DTO FACHADAS <<use>> mau.extanalisisred.view <<import>> org.postgresql.* org.postgis.* com.vividsolutions.jts.* org.geotools.* org.cresques.* org.jfree.chart.* com.lowagie.text.* <<use>> Figura 7.6: Diagrama MVC: Clases Alto Nivel DAO (Data Access Object) El acceso a datos varía dependiendo de la fuente de los datos. El acceso al almacenamiento persistente, como una base de datos, varía en gran medida dependiendo del tipo de almacenamiento (bases de datos relacionales, bases de datos orientadas a objetos, ficheros planos, etc.) Como solución: Utilizar un Data Access Object (DAO) para abstraer y encapsular todos los accesos a la fuente de datos. El DAO maneja la conexión con la fuente de datos para obtener y almacenar datos. El DAO implementa el mecanismo de acceso requerido para trabajar con la fuente de datos. Los componentes de negocio que tratan con el DAO utilizan una interfaz 74

93 CAPÍTULO 7. DISEÑO simple expuesta por el DAO para sus clientes. El DAO oculta completamente los detalles de implementación de la fuente de datos a sus clientes. Como la interfaz expuesta por el DAO no cambia cuando cambia la implementación de la fuente de datos subyacente, este patrón permite al DAO adaptarse a diferentes esquemas de almacenamiento sin que esto afecte a sus clientes o componentes de negocio. Esencialmente, el DAO actúa como un adaptador entre el componente y la fuente de datos. Como ventajas del uso del patrón DAO destacamos: Permite la transparencia: Los objetos de negocio pueden utilizar la fuente de datos sin conocer los detalles específicos de su implementación. El acceso es transparente porque los detalles de la implementación se ocultan dentro del DAO. Permite una migración más fácil: Una capa de DAOs hace más fácil que una aplicación pueda migrar a una implementación de base de datos diferente. Los objetos de negocio no conocen la implementación de datos subyacente, la migración implica cambios sólo en la capa DAO. Reduce la complejidad del código de los objetos de negocio: Como los DAOs manejan todas las complejidades del acceso a los datos, se simplifica el código de los objetos de negocio y de otros clientes que utilizan los DAOs. Todo el código relacionado con la implementación (como las sentencias SQL) está dentro del DAO y no en el objeto. Esto mejora la lectura del código y la productividad del desarrollo. Centraliza todos los accesos a datos en una capa independiente: Como todas las operaciones de acceso a los datos se han delegado en los DAOs, esto se puede ver como una capa que aísla el resto de la aplicación de la implementación de acceso a los datos. Esta centralización hace que la aplicación sea más sencilla de mantener y de manejar. Añade una capa extra: Los DAOs crean una capa de objetos adicional entre el cliente y la fuente de datos que necesitamos diseñar e implementar para obtener los beneficios de este patrón. 75

94 7.2. DISEÑO CONCEPTUAL TO (Transfer Object) Un Transfer Object no es más que un objeto que empaqueta datos para que puedan viajar entre las capas. Dicho objeto contendrá todos los datos que nos interesen accesibles mediante getters y setters. Nótese que aunque los transfer objects están directamente relacionados con los objetos del modelo de objetos del dominio, no se trata de los mismos objetos. Los objetos del dominio pueden contener lógica mientras que los transfer objects son meros almacenes de datos. Además no tiene por qué haber una relación uno-a-uno entre objetos del dominio y transfer objects, como se discutirá a continuación. Un problema importante es el de la sincronización entre los valores del transfer object y los del objeto del dominio que representa. Hay que asegurarse de que dichos valores están actualizados o que una falta de actualización de los mismos no conlleve consecuencias graves (caso típico de las operaciones de solo lectura). En caso de usar los TO tanto para mostrar datos como para almacenarlos (TOs actualizables) habrá que llevar sumo cuidado para sincronizar la información de los TOs que hayan cambiado. Este tipo de patrón se ha utilizado en concreto para almacenar la información procedente de la monitorización en el caso de uso de estadísticas Patrón Factory El patrón Factory crea una instancia concreta de múltiples tipos, normalmente con el mismo padre, pero que se diferencian en algún aspecto. El objeto Factory tendrá un método para crear los objetos, este decidirá de qué tipo crear en función del parámetro que se le pase. Figura 7.7: Patrón Factory 76

95 CAPÍTULO 7. DISEÑO Este patrón es muy útil ya que proporciona una manera transparente y fiable de construir objetos en función de algún criterio. En el proyecto se usa para: La creación de objetos Geometria usando su factory GeometriaFactory. En función del parámetro que se le pasa (la naturaleza de la geometría), creará una GeometriaLinea, GeometriaPunto... La creación de objetos Capa usando el factory CapaFactory. Que creará una CapaContenedor, una CapaPunto, una CapaRed o una CapaPoligono en función del parámetro pasado. Creación de objetos Valor usando el factory ValorFactory utilizado para transformar los valores recuperados de la BD e interpretarlos según del tipo que sean Patrón Singleton Como características básicas podemos decir que este patrón está diseñado para restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un único objeto. Su intención consiste en garantizar que una clase sólo tenga una instancia y proporcionar un punto de acceso global a ella. El patrón Singleton se implementa creando en la clase un método que crea una instancia del objeto sólo si todavía no existe alguna. Para asegurar que la clase no puede ser instanciada nuevamente se regula el alcance del constructor. Una implementación sencilla sería contener un objeto dentro de una variable estática, proporcionar un método que devuelva esa instancia. 77

96 7.3. ESTRUCTURA DE LA APLICACIÓN Estructura de la aplicación Controlador La capa de control esta formada por un único paquete que contiene la clase Controller que lleva a cabo la función de comunicar vista y modelo. Almacena información global del estado de la aplicación imprescindible para el funcionamiento. Gestiona los grandes núcleos de información relevante: listas de redes, paradas, resolución del grafo y todo tipo de mensajes Modelo El Modelo es, sin lugar a dudas, la parte más compleja de la aplicación pues maneja las geometrías, resuelve los grafos, contiene las acciones etc. Está a su vez subdividido en varios paquetes según sea su cometido: action: Están las clases encargas de realizar acciones de las interfaces. capa: Contiene las CapaFactory para crear las capas vectoriales. estadisticas: Se encuentran las clases plantillas resultantes que emplean la biblioteca JFreeChart -ver página exception: Están los nuevos tipos de excepciones. funciones: Incluye algunas clases con funciones típicas muy empleadas en la aplicación. geometria: Se encuentra la GeometriaFactory usada para crear como capa vectorial sobre el TOC de gvsig el resultado del análisis y así poderlo visualizar sobre gvsig realizando llamadas a FLayers. 78

97 CAPÍTULO 7. DISEÑO GeometriaFactory +Geometria creargeometria( IGeometry ) +Geometria creargeometria( Geometry ) Shape Fabrica * Geometria GeometriaNula IGeometry 1 1 +int NULL +int PUNTO +int LINEA +int POLIGONO int MULTIPUNTO... GeometriaMulti +int gettipo() +int elementos() +Geometria[] getgeometrias() GeometriaPunto GeometriaLinea GeometriaPoligono * GeometriaMultipuntos GeometriaMultiLinea GeometriaMultiPoligono * 1 CapaPunto CapaRed 1 CapaPoligonos FLyrVect CapaVectorial +GeometriaCapaVectorial gettabla() +Geometria[] getgeometria() +Valor[] getfila( long fila ) +Atributo[] getcabecera()... * * Atributo Valor Figura 7.8: Diagrama de clases: GeometriaFactory grafos: Paquete que trata todo lo que se refiere a crearlos y resolverlos. Cabe destacar que la clase núcleo de generación de grafos radica en GraphRenderer encargada de reproducir la ruta, crear grafos aleatorios, etc. En esta clase es donde se encuentran los diferentes algoritmos de inteligencia artificial. 79

98 7.3. ESTRUCTURA DE LA APLICACIÓN 80 package Data[ Algorithms ] Algorithm _graph : Graph _queue : Queue <<constructor>>+algorithm( graph : Graph ) +step() : void #dostep() : void +finished() : boolean <<getter>>+getgraph() : Graph <<getter>>+getqueue() : Queue <<getter>>+getstatestring() : String UniformCostAlgorithm GreedySearchAlgorithm DijkstraAlgorithm BeamSearchAlgorithm IDAStarAlgorithm AStarAlgorithm BreadthFirstAlgorithm DepthFirstAlgorithm HillClimbing1Algorithm HillClimbing2Algorithm Figura 7.9: Diagrama de clases: Algoritmos de Inteligencia Artificial gvsig: Contiene una clase denominada GvFlag que se usa para pintar sobre el mapa las diferentes paradas: banderilla verde parada inicial, banderilla roja la final y chinchetas sobre las paradas intermedias. sql: Incluye los DAO s y las clases necesarias para conectarse y desconectarse de la base de datos y realizar consultas, inserciones, crear nuevas tablas o alterar las existentes. tipo: Contiene las clases de nuevos tipos empleados y también las clases que puede crear el ValorFactory si es preciso. Valor * 1 ValorFactory ValorBooleano ValorNumero ValorCadena ValorNulo ValorNumeroEntero ValorNumeroDefault ValorInfinito ValorPorcentaje ValorDistanciaKm ValorSuperficieKm2 Figura 7.10: Diagrama de clases: Valor 80

99 CAPÍTULO 7. DISEÑO util: Paquete común a toda la aplicación. Debido a que se querían alcanzar resultados de mayor nivel de aplicación, y la utilidad de los patrones es precisamente la reutilización de los mismos se han importado las GeometryFactory junto con el ValorFactory, con el fin de centrarse con más dedicación en los procesos troceado y análisis. En el proceso de troceado contenido en la clase TroceadorAction es el encargado de cortar las geometrías (permitiendo una tolerancia asumible de error) y guardar la información necesaria para operar. En la figura 7.11 se puede ver los estados por los que transcurre dicho proceso. state machine Estados[ Estados del troceado ] Inicialización Limpiar Basura Generar Intersecciones Generar Nodos Generar Lineas Generar Lineas Union Generar Lineas Union 2 Generar Tramos Union Generar Tramos Figura 7.11: Diagrama de estados: Troceador de la red 81

100 7.3. ESTRUCTURA DE LA APLICACIÓN 82 El diagrama de secuencia de la figura 7.12 intenta aclarar como se comunican las clases en el tiempo -eje vertical- con el fin de resolver las rutas. interaction Secuencia resolución [ Secuencia resolución Ruta ] GraphPanelGui GraphAlgorithmChoicePanel Controller Algorithm TablesAction loop [WHILE existan paradas ruta] 1: Ejecutar 3: reset 2: new StatisticsGatherer StatisticsGatherer 4: run 5: new AlmacenEstadisticas AlmacenEstadisticas 6: selectalgorithm 7: new AStarAlgorithm(graph.getModel()); AStarAlgorithm loop [WHILE algoritmo no finalice] 8: selectionstep 10: log 9: step 11: showlog 12: setresolvergrafostat 13: anhaderesolvergrafostat 14: resultadomanager 15: setadelanteparada 16: setrutaresultado 17: reload 18: InformeResultado 19: TablaResultado 20: get EstadisticasString 21: return estadisticasstring 22: new MensajeExito MensajeGui 23: reload Figura 7.12: Diagrama de secuencia: Resolución Grafo de Ruta Se puede visualizar el diseño completo de todas las clases, en el fichero Diseño.mdzip adjuntado en el DVD, dentro de la carpeta UML. 82

101 CAPÍTULO 7. DISEÑO Vista Diseño de las interfaces En este aspecto se ha realizado un especial hincapié, puesto que es la parte visible de un programa. Incluye un único paquete fachadas que contiene todas las interfaces de la aplicación. Primeramente se ha realizado por simplicidad un boceto en papel, para luego utilizar un plugin de Eclipse denominado Visual Editor cuando era posible. Visual Editor proporciona la comodidad de realizar de una manera visual las interfaces agregando los componentes de Java disponibles (JPanel, JCombobox, JCheckBox, JSlider) arrastrando desde una Paleta a su ubicación con el ratón. Figura 7.13: Diseño de interfaz: Ejemplo edición con Visual Editor 83

102

103 Capítulo 8 Implementación 8.1. Eclipse Eclipse es una plataforma de software de código abierto independiente de plataforma pensada, desarrollada originalmente por IBM como sucesor de su familia de herramientas para VisualAge y ahora por la Fundación Eclipse, una organización independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un conjunto de productos complementarios y servicios. La definición que da el proyecto Eclipse acerca de su software es: una especie de herramienta universal - un IDE 1 abierto y extensible para todo y nada en particular En cuanto a las aplicaciones clientes, Eclipse provee al programador con frameworks muy ricos para el desarrollo de aplicaciones gráficas, definición y manipulación de modelos de software, aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing Framework - Framework para la edición gráfica) es un plugin de Eclipse para el desarrollo de editores visuales que pueden ir desde procesadores de texto WYSIWYG hasta editores de diagramas UML, interfaces gráficas para el usuario (GUI), etc. Dado que los editores realizados con GEF viven dentro de Eclipse, además de poder ser usados conjuntamente con otros plugins, hacen uso de su interfaz gráfica personalizable y profesional. El SDK de Eclipse incluye las herramientas de desarrollo de Java, ofreciendo un 1 IDE: entorno de desarrollo integrado 85

104 8.1. ECLIPSE 86 IDE con un compilador de Java interno y un modelo completo de los archivos fuente de Java. Esto permite técnicas avanzadas de refactorización y análisis de código. El IDE también hace uso de un espacio de trabajo, en este caso un grupo de metadatos en un espacio para archivos plano, permitiendo modificaciones externas a los archivos en tanto se refresque el espacio de trabajo correspondiente. Figura 8.1: Entorno de desarrollo Eclipse Eclipse es la plataforma elegida para el desarrollo del código fuente, decisión condicionada por el entorno (gvsig), y aun existiendo otras alternativas similares (como puede ser NetBeans) su velocidad y su agradable interfaz, una vez más, inclinó la decisión a su favor. En nuestro caso, además, se empleó el plugin de Edición Visual (VE) que es una plataforma para crear constructores de interfaces gráficas (GUI s). 86

105 CAPÍTULO 8. IMPLEMENTACIÓN 8.2. Algoritmos Consultar las páginas 30 y 34 que introducen los conceptos previos sobre grafos y rutas respectivamente. Suponemos estos parámetros d = profundidad del árbol. b = (media) factor de ramificación del árbol. m = Profundidad de la solución menos profunda. n = Número de nodos. a = Número de aristas. Figura 8.2: Parámetros complejidad árbol 87

106 8.2. ALGORITMOS A* Es el algoritmo heurístico basado en el de Dijkstra que da los resultados, por lo general más eficientes en la actualidad, y sencillo de implementar. Se caracteriza por su velocidad y porque da la mejor relación entre coste mínimo y tiempo de cálculo para buscarlo; además es un algoritmo completo, es decir, siempre encuentra la solución óptima en el caso de existir y está demostrado que es óptimamente eficiente en tiempo de ejecución en igualdad de condiciones. Figura 8.3: Similitud A* con breadth-first Algorithm 8.2.1: A*(Graf o) COLA la ruta solo contiene al nodo inicio; while COLA no esta vacía and nodo destino no encontrado borrar la primera ruta de la COLA; crear nuevas rutas (todas sus hijas); rechazar las nuevas rutas que forman bucles; añadir las nuevas rutas; do ordenar la COLA entera por f = coste + heurística; if COLA contiene ruta P terminado en I con COSTE P and ruta Q contiene I con COSTE Q and COSTE P COSTE Q then borrar P; if nodo destino encontrado then return (éxito); else return (fracaso); 88

107 CAPÍTULO 8. IMPLEMENTACIÓN Figura 8.4: Explicación funcionamiento A* Propiedad 1: Para cada subruta p de B: f(p) = cost(p) + h(end(p)) } {{ } estimador por debajo del coste restante cost(b). Propiedad 2: Para cada test de bucle durante A*, la COLA contiene la subruta de B que es una solución. Corolario: Para cada ruta p, tal que f(p) > cost(b) p nunca es seleccionada durante A* y (nunca llega primero en la COLA). Figura 8.5: A* búsqueda en el árbol 89

108 8.2. ALGORITMOS 90 Figura 8.6: A* ejemplo de finalización Exhaustividad: Completo, asegura encontrar una ruta y que esta sea la óptima si existe y es óptimamente eficiente. Tiempo: La complejidad computacional del algoritmo está íntimamente relacionada con la calidad de la heurística que se utilice en el problema. En el caso peor, con una heurística de pésima calidad, la complejidad será exponencial, mientras que en el caso mejor, con una buena o(h(n)), el algoritmo se ejecutará en tiempo lineal si cumple que h(n) f(y)-f(n)+h(y) siendo f la función de coste y h la de la heurística. Depende mucho del contorno de f que tenga. En el peor caso O(b m ) Memoria: El espacio requerido por A* para ser ejecutado es su mayor problema. Dado que tiene que almacenar todos los posibles siguientes nodos de cada estado, la cantidad de memoria que requerirá será exponencial con respecto al tamaño del problema. En el peor caso En el peor caso O(b m ). Para solucionar esta cuestión en casos muy complejos, se han propuesto diversas variaciones de este algoritmo, como pueden ser IDA*, RTA* o SMA*. 90

109 CAPÍTULO 8. IMPLEMENTACIÓN IDA* Algorithm 8.2.2: IDA*(Graf o) COLA la ruta solo contiene al nodo inicio; f-bound <algún número natural>; f-new ; while COLA no esta vacía and nodo destino no encontrado borrar la primera ruta de la COLA; crear nuevas rutas (todas sus hijas); rechazar las nuevas rutas que forman bucles; añadir las nuevas rutas con f(ruta) f-bound do al principio de la COLA; f-new mínimo entre el actual f-new y el mínimos de los otros nuevos f-values los cuales son mayores que f-bound; if nodo destino encontrado then return (éxito); else return (fracaso); Exhaustividad: Completo, asegura encontrar una ruta y ser la óptima si esta existe. Tiempo: Depende mucho del contorno de f que tenga En el peor caso O(n 2 ) Memoria: Si δ es el coste mínimo de un arco: O(b (cost(d))/δ) 91

110 8.2. ALGORITMOS Dijkstra La idea subyacente en este algoritmo consiste en ir explorando todos los caminos más cortos que parten del vértice origen y que llevan a todos los demás vértices; cuando se obtiene el camino más corto desde el vértice origen al resto de vértices que componen el grafo, el algoritmo se detiene. El algoritmo es una especialización de la búsqueda de costo uniforme, y como tal, no funciona en grafos con aristas de costo negativo (al elegir siempre el nodo con distancia menor, pueden quedar excluidos de la búsqueda nodos que en próximas iteraciones bajarían el costo general del camino al pasar por una arista con costo negativo). Figura 8.7: Recorrido del algoritmo de Dijkstra 92

111 CAPÍTULO 8. IMPLEMENTACIÓN Algorithm 8.2.3: Dijkstra(Graf o) COLA la ruta solo contiene al nodo inicio; while COLA no esta vacía and primera ruta nodo destino no encontrado; borrar la primera ruta de la COLA; crear nuevas rutas (todas sus hijas); rechazar las nuevas rutas que forman bucles; if nodos finales han sido visitados do then if ruta mejora coste then actualizar visitados y marca como nueva ruta; else marcar ruta como visitada y como nueva ruta; añadir las nuevas rutas; ordenar la COLA entera por el coste real; if nodo destino encontrado then return (éxito); else return (fracaso); Exhaustividad: Completo, asegura encontrar una ruta y ser la óptima si esta existe. Tiempo: O((n+a) log n) Memoria: En el peor caso O(n 2 ) 93

112 8.2. ALGORITMOS Uniform Cost (Búsqueda de coste uniforme) Algorithm 8.2.4: Uniform Cost(Graf o) COLA la ruta solo contiene al padre; while COLA no esta vacía and nodo destino no encontrado borrar la primera ruta de la COLA; crear nuevas rutas (todas sus hijas); rechazar las nuevas rutas que forman bucles; do añadir las nuevas rutas; ordenar la COLA entera por el valor de la función f = coste(ruta) + heurística(nodo final de la ruta); if nodo destino encontrado then return (éxito); else return (fracaso); Exhaustividad: Completo, siempre y cuando la función heurística sea subestimada del coste restante hasta el final (se produce este hecho aplicado a la cartografía por aplicar el cálculo en línea recta). Tiempo: O(b m ) Memoria: O(b m ) 94

113 CAPÍTULO 8. IMPLEMENTACIÓN Greedy Search (Búsqueda voraz) Siempre expande la heurística de los primeros mejores nodos. En cada paso, selecciona el nodo con el mejor (en este caso: más bajo) valor de la heurística. Figura 8.8: Greedy Search Algorithm 8.2.5: Greedy Search(Graf o) COLA la ruta solo contiene al padre; while COLA no esta vacía and nodo destino no encontrado borrar la primera ruta de la COLA; crear nuevas rutas (todas sus hijas); do rechazar las nuevas rutas que forman bucles; añadir las nuevas rutas; ordenar la COLA entera por el valor de la heurística; if nodo destino encontrado then return (éxito); else return (fracaso); Exhaustividad: No es completo, no asegura dar el óptimo. Tiempo: En el peor caso O(b m ) Memoria: En el peor caso O(b m ) 95

114 8.2. ALGORITMOS Hill Climbing 1 (Búsqueda ascensión de colinas) Mejor rendimiento que DFS -ver página 100-, en lugar de seleccionar de izquierda a derecha primero selecciona al hijo con mejor valor de la heurística. Tiene backtracking. Figura 8.9: Hill climbing 1 Algorithm 8.2.6: Hill Climbing 1(Graf o) COLA la ruta solo contiene al padre; while COLA no esta vacía and nodo destino no encontrado borrar la primera ruta de la COLA; crear nuevas rutas (todas sus hijas); do rechazar las nuevas rutas que forman bucles; ordenar las nuevas rutas por la valor de la heurística; añadir las nuevas rutas al frente de la COLA; if nodo destino encontrado then return (éxito); else return (fracaso); Exhaustividad: NO asegura encontrar una ruta si esta existe. Tiempo: Peor complejidad de tiempo. Depende del más alto número de nodos que pueden ser creados. En el peor caso O(b d ) Memoria: En el peor caso O(b d) 96

115 CAPÍTULO 8. IMPLEMENTACIÓN Hill Climbing 2 Es una especialización al algoritmo Beam Search -página 98- con salto o beam de 1 unidad, se verá posteriormente. Función heurística: comprobar el cambio de altura en 4 direcciones; el mayor aumento es la dirección en la que moverse a la próxima. Es idéntica a Hill Climbing 1, a excepción del backtracking. Figura 8.10: Hill climbing 2 Produce una serie de problemas clásicos: El Foothills es una mínimas locales y este algoritmo no puede notar la diferencia. Las Mesetas no le permiten decir hacia donde avanzar por lo que avanza según una decisión arbitraria o aleatoria en cualquier dirección. Las cordilleras requieren nuevas normas, más directamente dirigidas a la meta que se presentó (nuevas direcciones para moverse). En la búsqueda local mantiene la ruta de la primera ruta (p) y la usa para calcular la nueva ruta en el siguiente paso. No asegura encontrar el resultado ni tampoco que sea el óptimo. 97

116 8.2. ALGORITMOS Beam Search Se basa en estrechar la anchura del BFS asumiendo una prefijada anchura (por ejemplo 2). Rendimiento como el BFS pero sólo mantiene la anchura de los mejores nodos dependiendo del valor de la heurística de cada nivel. No tiene backtracking. Optimización: hacer caso omiso de hojas que no son objetivo de los nodos como es en el ejemplo C. Figura 8.11: Beam search 1 Figura 8.12: Beam search 2 Figura 8.13: Beam search 3 98

117 CAPÍTULO 8. IMPLEMENTACIÓN Figura 8.14: Beam search 4 Algorithm 8.2.7: Beam Search(Graf o, beam) COLA la ruta solo contiene al padre; while COLA no esta vacía and nodo destino no encontrado borrar todos las rutas contenidas en la COLA; crear nuevas rutas de todos sus hijos; do ordena nueva lista de menor a mayor según los valores heurística del último nodo; añadir las nuevas beam rutas al final de la COLA; if nodo destino encontrado then return (éxito); else return (fracaso); Exhaustividad: NO asegura encontrar una ruta si esta existe. Tiempo: Es una constante O(beam*m) si existe una solución o O(beam*d) si la solución no la encuentra. Memoria: Es una constante O(beam) 99

118 8.2. ALGORITMOS Depth First Search (DFS) Expande el grafo en forma de árbol y lo recorre en rutas tan profundas como sea posible, devolviendo por lo general niveles más altos que los necesarios. Cuando ya no quedan más nodos que visitar en dicho camino, regresa (Backtracking) de forma cronológica, de modo que repite el mismo proceso con cada uno de los hermanos del nodo ya procesado, por convenio de izquierda a derecha, y regresa a las alternativas izquierda-superior sólo cuando necesita. Algorithm 8.2.8: Depth First Search(Graf o) COLA la ruta solo contiene al padre; while COLA no esta vacía and nodo destino no encontrado borrar la primera ruta de la COLA; crear nuevas rutas (todas sus hijas); do rechazar las nuevas rutas que forman bucles; añadir las nuevas rutas al frente de la COLA; if nodo destino encontrado then return (éxito); else return (fracaso); El análisis de complejidad no tiene en cuenta detecciones de ciclos puesto que el coste es superior y no compensa en relación a la reducción del tamaño del árbol. Exhaustividad: Asegura encontrar una ruta si esta existe pero no es la óptima y si tiene bucles podría quedarse haciendo bucles infinitos. Tiempo: Depende del más alto número de nodos que pueden ser creados. En el peor caso O(b d ) Memoria: En el peor caso O(b d) 100

119 CAPÍTULO 8. IMPLEMENTACIÓN Breadth First Search (BFS) Consiste básicamente en un recorrido del árbol, nivel por nivel, hasta encontrar el nodo destino. Por lo general tiene que recorrer muchos más nodos que el DFS. Figura 8.15: Bread First Search Algorithm 8.2.9: Breadth first Search(Graf o) COLA la ruta solo contiene al nodo inicio; while COLA no esta vacía and nodo destino no encontrado borrar la primera ruta de la COLA; crear nuevas rutas (todas sus hijas); do rechazar las nuevas rutas que forman bucles; añadir las nuevas rutas al final de la COLA; if nodo destino encontrado then return (éxito); else return (fracaso); Exhaustividad: Asegura encontrar una ruta si esta existe pero no es la óptima; no tiene el problema de bucles infinitos. Tiempo: En el peor caso O(b m ) Memoria: En el peor caso O(b m ). Consume muchísima memoria más que DFS! 101

120 8.3. LIBRERÍAS EMPLEADAS Librerías empleadas JTS Topology Suite JTS es un API que proporciona predicados y funciones para modelos espaciales 2D. Está desarrollado por la empresa Vivid Solutions y de código Open Source con licencia LGPL e implementado totalmente en Java. Se amolda perfectamente a los estándares definidos en la especificación del OpenGIS. Su objetivo principal es proporcionar una arquitectura para representar y operar con objetos espaciales proporcionando una serie de funcionalidades para el análisis de datos geográficos. Su máxima es proporcionar métodos robustos y fiables manteniendo los tiempos de computación aptos para su uso. Para aclarar la filosofía de JTS se explican una serie de conceptos: Un punto es distinto que una coordenada, el primero es un punto arbitrario en R 3, en general no es finito ni representable ya que computacionalmente no se puede representar un punto con precisión infinita. En cambio una coordenada es un punto en el espacio que si es representable bajo un modelo de precisión determinado. Punto: Es un punto arbitrario en R 3, en general no es representable ya que computacionalmente no se puede representar un punto con precisión infinita. Coordenada: Es un punto en el espacio que si es representable bajo un modelo de precisión determinado. Computación exacta: Es una computación numérica que mantiene todos los dígitos de los números a través de todas las operaciones. Normalmente conlleva un gasto excesivo de recursos computacionales. Nodo: Un punto donde dos líneas de la misma o diferente geometría intersecan. No necesariamente ha de ser representable mediante coordenadas ya que normalmente la precisión que requieren las geometrías a la salida de los algoritmos es mayor que la de las geometrías de la entrada. Noding (Noded): Búsqueda de los nodos donde intersecan las geometrías. No-Coordenada: Un punto que no se puede representar mediante una coordenada. 102

121 CAPÍTULO 8. IMPLEMENTACIÓN Estabilidad numérica: La estabilidad de un algoritmo es determinada por el máximo error que pueda tener la salida. Un algoritmo es estable si el máximo error es pequeño. Intersección apropiada (Proper intersection): Intersección entre dos segmentos cuyo punto de intersección es un punto interno para ambos segmentos. Computación robusta: Computación numérica que garantiza el resultado correcto independientemente de la entrada. Normalmente requiere algoritmos que manejen el error de redondeo. Unidad de resolución: La unidad representable más pequeña para un modelo de precisión determinado. Vértice: Una esquina del objeto. Son las coordenadas guardadas para representar la geometría del objeto. Figura 8.16: Operaciones básicas JTS 103

122 8.3. LIBRERÍAS EMPLEADAS 104 Figura 8.17: Diagrama de clases de las geometrías OGC itext itext es una biblioteca Open Source para crear y manipular archivos PDF, RTF, y HTML en Java. Fue escrita por Bruno Lowagie y Paulo Soares. En este proyecto se utiliza para exportar los informes generados a PDF al igual que se emplea por la JFreeChart para exportar las imágenes a dicho formato. Para más información de esta librería con ejemplos y plantillas de uso visitar 104

123 CAPÍTULO 8. IMPLEMENTACIÓN JFreeChart JFreeChart es una biblioteca para Java para realizar gráficos de forma sencilla. Es muy cómodo, usando plantillas, para obtener grandes resultados con menor esfuerzo. Se empleará para visualizar todos los resultados estadísticos integrados en las herramientas, permitiendo incorporar funcionalidades muy útiles como la navegación por los gráficos, aplicar zoom a una sección del gráfico, etc. Es igualmente gratuita y de libre difusión, pero la documentación es previo pago. Para mas información JSearchDemo Es un applet destinado para la docencia de Inteligencia Artificial escrita por Joost Vennekens y Remko Tronçon que trabajan en la Katholieke Universiteit Leuven. Es una librería empleada de base tanto de motor gráfico, para dibujar los grafos, como para mover nodos con drag-and-drop ; que implementaba algunos algoritmos de búsqueda. No obstante se tuvo que mejorar, arreglar casi todos los algoritmos para que realmente funcionaran, y añadir alguno más (Dijkstra). Además se tuvo que sustituir todas estructuras de datos internas para mejorar el rendimiento sustancialmente, puesto que su rendimiento inicial era muy tosco para el cometido que debía desempeñar. También se tuvo que remodelar la interfaz para adaptarla a las necesidades típicas de un sistema GIS (zoom, moverse por la pantalla, etc.) y modelarla de acuerdo los estándares de la aplicación general. Se puede ver cómo era originalmente en el siguiente link 105

124 8.4. DATOS DE ENTRADA Datos de entrada Fichero XML de gvsig Es el fichero principal que carga el gvsig situado en el directorio de la raíz de la extensión llamado config.xml que hace integrar la extensión al menú y a la barra del gvsig. Determina qué clases llama, con qué parámetros y alguna información adicional como puede ser el icono o la descripción. El último párrafo se corresponde con agregar el menú about en el menú Ayuda Acerca de... <?xml version="1.0" encoding="iso "?> <plugin-config> <libraries library-dir="."/> <depends plugin-name="com.iver.cit.gvsig" /> <depends plugin-name="com.iver.cit.gvsig.jdbc_spatial" /> <resourcebundle name="text"/> <extensions> <extension class-name="mau.extanalisisred.controller.controller" description="menu developer" active="true" priority="1"> <menu text="analisis Red/Avanzado/Menu developer" action-command="developer_main" icon="images/menu_developer.gif" /> </extension> <extension class-name="mau.extanalisisred.controller.controller" description="ejecuta Sentencias SQL" active="true" priority="1"> <menu text="analisis Red/Avanzado/Sentencias SQL" action-command="consulta_sql" icon="images/menu_consultasql.gif" /> </extension> <extension class-name="mau.extanalisisred.controller.controller" description="configurar extension" active="true" priority="1"> <menu text="analisis Red/Configurar" action-command="configurar" icon="images/menu_configurar.gif" /> </extension> 106

125 CAPÍTULO 8. IMPLEMENTACIÓN <extension class-name="mau.extanalisisred.controller.controller" description="crear la red" active="true" priority="1"> <menu text="analisis Red/Crear Red" action-command="crear_red" icon="images/menu_crearred.gif" /> </extension> <extension class-name="mau.extanalisisred.controller.controller" description="listar Redes" active="true" priority="1"> <menu text="analisis Red/Listar Redes" action-command="listar_redes" icon="images/menu_listarredes.gif" /> </extension> <extension class-name="mau.extanalisisred.controller.controller" description="a~nadir Arcos" active="true" priority="1"> <menu text="analisis Red/A~nadir Arcos" action-command="add_arcos" icon="images/menu_addarcos.gif" /> </extension> <extension class-name="mau.extanalisisred.controller.controller" description="a~nadir Nodos" active="true" priority="1"> <menu text="analisis Red/A~nadir Nodos" action-command="add_nodos" icon="images/menu_addnodos.gif" /> </extension> <extension class-name="mau.extanalisisred.controller.controller" description="trocear el grafo de la Red" active="true" priority="1"> <menu text="analisis Red/Trocear Grafo" action-command="trocear_grafo" icon="images/menu_trocear_grafo.gif" /> </extension> <extension class-name="mau.extanalisisred.controller.controller" description="paradas" active="true" priority="1"> <menu text="analisis Red/Paradas" action-command="paradas" icon="images/menu_paradas.gif" /> </extension> 107

126 8.4. DATOS DE ENTRADA 108 <extension class-name="mau.extanalisisred.controller.controller" description="calculo de la ruta Optima" active="true" priority="1"> <menu text="analisis Red/Calculo Ruta Optima" action-command="calculo_ruta" icon="images/menu_calculoruta.gif" /> <tool-bar name="calcular Rutas"> <action-tool icon="images/menu_calculoruta.gif" action-command="calculo_ruta" tooltip="muestra el gestor de Calcular Rutas" /> </tool-bar> </extension> <extension class-name="mau.extanalisisred.controller.controller" description="estadisticas" active="true" priority="1"> <menu text="analisis Red/Comparador" action-command="comparador" icon="images/comparador.gif" /> </extension> <extension class-name="mau.extanalisisred.controller.controller" description="estadisticas" active="true" priority="1"> <menu text="analisis Red/Estadisticas" action-command="estadisticas" icon="images/menu_estadisticas.gif" /> </extension> <extension class-name="mau.extanalisisred.controller.controller" description="asistente" active="true" priority="1"> <menu text="analisis Red/Asistente" action-command="wizard" icon="images/menu_wizard.gif" /> </extension> <extension class-name="mau.extanalisisred.controller.controller" description="abre la memoria del Proyecto" active="true" priority="1"> <menu text="analisis Red/Memoria" action-command="memoria" icon="images/menu_memoria.gif" /> </extension> <extension class-name="mau.extanalisisred.view.aboutgraphextension" description="extension to add about panel." active="true"/> </extensions> </plugin-config> 108

127 CAPÍTULO 8. IMPLEMENTACIÓN Fichero properties En este apartado se pretende analizar cómo se guardan las configuraciones en el fichero properties ubicado por defecto en la ruta conf/confextanalisisred.properties. Las clases que las manejan son ConfigurationFunction y ConfigurationManager. ######################################################################################### <-+ # # # PROYECTO FIN DE CARRERA # # INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN # # # # Autor: Miguel Álvarez Úbeda # CABECERA # # FICHERO # Herramienta de análisis de redes en un sistema de información geográfica # PROPERTIES # # # # # confextanalisisred.properties: Fichero de configuracion de la extension # # # ######################################################################################### <-+ #Mon Dec 24 01:03:53 CET 2007 < Ultima actualización consultasql_capa_checkbox = false < Crear capa en gvsig consultas SQL <-+ CONSULTAS SQL consultasql_informe_checkbox = true < Crear informe de las consultas SQL <-/ configurar_gestor_bd = jdbc:postgresql < Gestor de Base de Datos - Postgresql <-\ configurar_host = < Localización de la Base de Datos configurar_usuario = root < Usuario que se conecta a la BD configurar_password=0godqvgf0xy\= < Clave del usuario CIFRADA configurar_bd = galicia < Nombre de la BD a utilizar CONFIGURACIÓN configurar_puerto = 5432 < Puerto de conexión a la BD BASE DE DATOS Y configurar_formato_defecto = A4 Horizontal < Tipo de informes OPCIONES GENERALES configurar_unidades_defecto = Kilometros < Unidad métrica de los informes configurar_srid_value = < Valor SRID (Ver manual usuario) configurar_margen_tolerancia = 3000 < Metros de tolerancia separación puntos configurar_seleccion_corte = 50 < Porcentaje sección de corte <-/ add_nodos_table_nodo_default = poboacions < Tabla de puntos seleccionada <-\ add_nodos_columna_nodo_name_default = nome < Nombre de la columna de puntos CONFIGURACIÓN add_nodos_columna_nodo_geom_default = the_geom < Columna geometría de puntos NODOS add_nodos_heuristica_default = Distancia_en_linea_Recta < Tipo de heurística <-/ add_arcos_table_arco_default = estradas < Tabla de líneas seleccionada <-\ add_arcos_columna_arco_name_default = nome < Nombre de la columna de líneas CONFIGURACIÓN add_arcos_columna_arco_geom_default = the_geom < Columna geometría de líneas ARCOS add_arcos_coste_default = Longitud_del_tramo < Tipo de coste <-/ generargrafo_clean = true < Opción de limpiar la red activa <-+ TROCEADOR generargrafo_save = true < Opción guardar los tramos red activa <-/ GRAFO comparador_iters = 1 < Número de muestras comparador <-\ comparador_start = 1 < Desde cuántos nodos COMPARADOR comparador_end = 30 < Hasta cuántos nodos ALGORITMOS comparador_jump = 5 < Saltos de cuanto comparador_density = 20 < Porcentaje de la densidad <-/ Para más información consultar el manual de usuario adjuntado en este documento en el capítulo A, página

128 8.4. DATOS DE ENTRADA Tablas generadas en la base de datos Paradas Esta tabla es la encargada de almacenar la lista de paradas por la que debe pasar la ruta. Figura 8.18: Tabla paradas en la Base de Datos Consta de las siguientes columnas: key: es la clave primaria de paradas, se genera automáticamente al insertar una tupla permitiendo así valores repetidos (por ejemplo para rutas que forman un ciclo). orden: posición que ocupa esa parada en el recorrido global, va del 1 al n, siendo n el numero total de paradas. parada: nombre de la parada. the geom: corresponde con la localización geométrica de la parada en formato binario, por comodidad repetida evitando así utilizar JOIN s. 110

129 CAPÍTULO 8. IMPLEMENTACIÓN Está definido de esta forma: -- Table: paradas -- DROP TABLE paradas; CREATE TABLE paradas ( "key" serial NOT NULL, orden numeric(20), parada character varying(100) NOT NULL, the_geom geometry, CONSTRAINT paradas_pkey PRIMARY KEY ("key"), CONSTRAINT enforce_dims_the_geom CHECK (ndims(the_geom) = 2), CONSTRAINT enforce_geotype_the_geom CHECK (geometrytype(the_geom) = POINT ::text OR the_geom IS NULL), CONSTRAINT enforce_srid_the_geom CHECK (srid(the_geom) = 23029) ) WITHOUT OIDS; ALTER TABLE paradas OWNER TO root; -- Index: paradas_the_geom_gist -- DROP INDEX paradas_the_geom_gist; CREATE INDEX paradas_the_geom_gist ON paradas USING gist (the_geom); Lista redes index Es la encargada de indexar las redes existentes creadas. Figura 8.19: Tabla redes index en la Base de Datos 111

130 8.4. DATOS DE ENTRADA 112 Consta de las siguientes columnas: gid: es la clave primaria de paradas, se genera automáticamente al insertar una tupla. red: nombre de la red creada, debe existir una tabla con idéntico nombre por cada red creada -ver página descripción: descripción de la red. uso: columna deprecated, se usaba para mantener la red activa. Está definido de esta forma: -- Table: index_mau -- DROP TABLE index_mau; CREATE TABLE index_mau ( gid serial NOT NULL, red character varying(100) NOT NULL, descripcion character varying(256), uso boolean, CONSTRAINT index_mau_pkey PRIMARY KEY (gid) ) WITHOUT OIDS; ALTER TABLE index_mau OWNER TO root; 112

131 CAPÍTULO 8. IMPLEMENTACIÓN Tabla red creada Esta tabla mantiene el resultado de una red troceada. Figura 8.20: Tabla que mantiene la red troceada Consta de las siguientes columnas: gid: es la clave primaria de la tabla creada, se genera automáticamente al insertar una tupla. origen: Dependiendo del tipo, tiene el nombre que lo identifica el origen de la geometría. destino: Si son relaciones de tipo UNION o INTERSECCION se usa para identificar a qué se une. Si es de tipo RESULTADO identifica la parada destino, que llega esa ruta. 113

132 8.4. DATOS DE ENTRADA 114 num tramo: Número identificativo para diferenciar los tramos que componen una línea. heuristic: Valor de la heurística a la siguiente parada (útil para debuggear ), por defecto es la línea recta que las une. coste1: Es el coste de la geometría origen coste2: Es el coste de la geometría destino, se usa en LINEAS UNION 2 y TRA- MOS UNION, si no se usa esta a 0. tipo: Campo para debuggear, especifica en qué parte del proceso de creación fue creada. Puede ser de estos tipos: NODO, INTERSECCION, LINEAS, LI- NEAS UNION, LINEAS UNION 2, TRAMOS, TRAMOS UNION, RESULTADO. tipo geom: Campo para debuggear, especifica el tipo de geometría que contiene, pueden ser punto, linea, multilinea. marcado: Se utiliza para diferenciar qué red de tipo RESULTADO se va a pintar sobre gvsig. the geom: Contiene la geometría en formato binario del OGC correspondiente. 114

133 CAPÍTULO 8. IMPLEMENTACIÓN Está definido de esta forma: -- Table: nueva_red_4 -- DROP TABLE nueva_red_4; CREATE TABLE nueva_red_4 ( gid serial NOT NULL, origen character varying(256) NOT NULL, destino character varying(256), num_tramo numeric(20), heuristic numeric(10,3), coste1 numeric(10,3), coste2 numeric(10,3), tipo character varying(40) NOT NULL, tipo_geom character varying(40), marcado boolean, the_geom geometry, CONSTRAINT nueva_red_4_pkey PRIMARY KEY (gid), CONSTRAINT enforce_dims_the_geom CHECK (ndims(the_geom) = 2), CONSTRAINT enforce_srid_the_geom CHECK (srid(the_geom) = 23029) ) WITHOUT OIDS; ALTER TABLE nueva_red_4 OWNER TO root; -- Index: nueva_red_4_the_geom_gist -- DROP INDEX nueva_red_4_the_geom_gist; CREATE INDEX nueva_red_4_the_geom_gist ON nueva_red_4 USING gist (the_geom); 115

134

135 Capítulo 9 Pruebas 9.1. Pruebas unitarias En programación, una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos: Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continua. Completas: deben cubrir la mayor cantidad de código. Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua. Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra. Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc. Aunque estos requisitos no tienen que ser cumplidos a rajatabla, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función. 117

136 9.1. PRUEBAS UNITARIAS 118 El objetivo de las pruebas unitarias es aislar, cada parte del programa y mostrar que las partes individuales son correctas. Proporcionan un contrato escrito que el trozo de código debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas básicas: 1. Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se ha dado en llamar refactorización), puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores. 2. Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración. 3. Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo. 4. Separación de la interfaz y la implementación. 5. Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos. Es importante darse cuenta de que las pruebas unitarias no descubrirán todos los errores del código. Por definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán errores de integración, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Además, puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias sólo son efectivas si se usan en conjunto con otras pruebas de software. Existe software dedicado a automatizar estas pruebas unitarias, el más conocido en el entorno Java es JUnit. 118

137 CAPÍTULO 9. PRUEBAS 9.2. Pruebas de integración Las pruebas de integración (algunas veces llamadas Integración y Testeo I&t) son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez. Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos Pruebas de rendimiento El rendimiento en las primeras fases que se disponía un software operativo, su funcionamiento era muy tosco. Para localizar que ocurría se optó por usar un software especializados para monitorizar programas en Java (JProfiler) que en tiempo de ejecución iba informando en que se usaba la CPU y así se detectan fácilmente los cuellos de botella. Figura 9.1: JProfiler En este caso esta prueba fue positiva (las pruebas informáticas al ser de carácter destructiva, se dice que es positiva si se detecta uno o más errores) localizándose los 119

138 9.3. PRUEBAS DE RENDIMIENTO 120 cuellos de botella principalmente en la visualización del grafo, en algunas funciones que realizaban cálculos muchas veces redundantemente y unas estructuras de datos no optimizadas para el cometido que debían desempeñar. Se implementaron varias soluciones: El grafo como dibujo tardaba proporcionalmente mucho más tiempo el dibujarlo que en realizar un paso del algoritmo. Se comprobó que era debido al número de links por lo que se opto primeramente en refrescar los cambios cada cierto tiempo arbitrariamente (cada 1 segundo por ejemplo) no obstante la versión 5 de java producía problemas de trozos de pantalla en blanco que en la versión 6 no sucedía. Sabiendo que actualmente gvsig solo soporta la versión 5 se decidió por suprimir el resfresco de ventana y decantarse por proporcionar al usuario la decisión de desactivar el visionado manualmente (El JCheckBox de Ver Ruta denominado Ver Grafo ) y convertir el menú en una barra desplegable. Las estructuras de datos se sustituyeron todas y algunos casos se decidió mantener incluso estructuras duplicadas. Esta decisión fue debatida y tomada teniendo en cuenta las operaciones que se usan asiduamente a la hora de resolver el grafo como es el caso con el HashMap y LinkedHashSet para la función contains y para muchas inserciones y borrados respectivamente, a la hora de comparar que nodos están contenidos en el path y el clonar al la ruta para calcular los rutas candidatas hijas. Sobre los cálculos redundantes se optimizó el código para evitar lo más posible las repeticiones. En este caso podría ponerse de ejemplo las transformaciones geográficas de texto a JTS 1 optando por cachear esta información en memoria y así las geometrías sólo procesarlas una única vez en el momento de cargar la red. Como mejora adicional previa a la resolución del grafo de geometrías se hace una poda recursiva de aquellos nodos sumidero que no sean el inicio o el destino, dicho de otra forma, se suprimen aquellos caminos que no llevan a ningún lado puesto que son caminos sin salida. Los resultados de estos cambios fueron altamente satisfactorios. Hablando con cifras, si antes de efectuar los cambios la misma ruta ejecutada en el mismo ordenador 1 JTS: Java Topology Suite. API de java que proporciona un modelo de objetos espaciales y funciones fundamentales geométricas 2D desarrollado por Vivid Solutions 120

139 CAPÍTULO 9. PRUEBAS con idénticos parámetros y el mejor algoritmo disponible A* tardaba cerca de 90 segundos, después de los cambios tardaba sólo 3 segundos Pruebas de stress Con el fin de encontrar fallos graves sobre todo en temas de algoritmos y la resolución de las rutas, se realizaron cientos de miles de iteraciones en diversos ordenadores en paralelo con el fin de detectar y depurar fallos de implementación a la hora de comparar los algoritmos. Un ejemplo de lo que aportaron estas pruebas fue el detectar pequeños fallos de implementación. Por ejemplo el A* como se explicaba en el capítulo de implementación -página 88- es óptimamente eficiente y los primeros resultados analíticos no decían lo mismo en comparación con los demás algoritmos. También proporciono información acerca de fugas de memoria, después de que estubiera mucho tiempo ejecutándose, sobrepasando los límites de memoria asignados produciéndose un error conocido como Java heap size, en las etapas tempranas de desarrollo, consumiendo grandes cantidades de memoria RAM. Se arregló a la vez que se solucionaban los problemas de cálculos redundantes de las pruebas de rendimiento junto con problemas relacionados a no matar correctamente los procesos hijos al finalizar la aplicación. Se consiguió una mejora apreciable pasando de 112Mb a 65Mb lo que supone casi la mitad de consumo menos en tiempo de ejecución Pruebas de aceptación Consisten en que el usuario, en este caso mi tutor, Miguel Ángel Rodríguez Luaces, que desempeñaba ese rol diera su visto bueno con resultados de la aplicación desarrollada, documentación, en definitiva que todos sus requisitos han sido satisfechos. Como se comentó en el capítulo 5 de Metodología el seguimiento continuado junto con el prototipado, hacen que las desviaciones en este sentido se minimicen. 121

140

141 Capítulo 10 Resultados y rendimiento Cómo funciona Consultas SQL Las consultas de SQL, integradas en la extensión, permiten interactuar con la base de datos por medio del protocolo JDBC 1 que permite la ejecución de operaciones sobre bases de datos desde el lenguaje de programación Java, independientemente del sistema operativo donde se ejecute o de la base de datos a la cual se accede utilizando el dialecto SQL del modelo de base de datos que se utilice. El API JDBC se presenta como una colección de interfaces Java y métodos de gestión de manejadores de conexión hacia cada modelo específico de base de datos. Un manejador de conexiones hacia un modelo de base de datos en particular es un conjunto de clases que implementan las interfaces Java y que utilizan los métodos de registro para declarar los tipos de localizadores de base de datos (URL) que pueden manejar. 1 JDBC: Java Database Connectivity 123

142 10.1. CÓMO FUNCIONA 124 Figura 10.1: Consultas SQL Para utilizar una base de datos particular, el usuario ejecuta su programa junto con la librería de conexión apropiada al modelo de su base de datos, y accede a ella estableciendo una conexión; para ello provee el localizador a la base de datos y los parámetros de conexión específicos -Ver páginas 207 que explica las posibilidades que proporciona esta interfaz, y 208 que explica el menú Configurar-. Esta interfaz permite realizar consultas directamente a la base de datos y crear capas sobre gvsig, entre otras cosas, se ha utilizado para crear las explicaciones sobre el mapa que se verán a continuación El proceso de troceado El proceso de troceado consiste en dividir las líneas y los puntos hasta la unidad más pequeña que se requiere manejar, que en nuestro caso es el tramo y saber cómo se relacionan entre ellos. Un tramo es un conjunto de coordenadas conexas (incluso podría ser un punto) que no tiene bifurcaciones, por tanto una línea tiene de 1 hasta n tramos, cada una de longitud variable. 124

143 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO Para que quede todo lo más claro posible, se va a explicar la analogía sobre el mapa. El primer paso previo es crear una red vacía: Figura 10.2: Proceso troceado 1: Red vacía 125

144 10.1. CÓMO FUNCIONA 126 El segundo paso previo es configurar la red de puntos, en nuestro caso son las poblaciones de Galicia. Figura 10.3: Proceso troceado 2: Configuración puntos 126

145 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO El tercer paso previo es configurar la red de líneas, en nuestro caso son las carreteras -capa estradas- de Galicia. Figura 10.4: Proceso troceado 3: Configuración líneas 127

146 10.1. CÓMO FUNCIONA 128 El cuarto paso es lanzar el proceso de troceado, que es lo que trata este punto de la explicación, que realiza este proceso. Es un proceso costoso computacionalmente; para hacerse una idea, en un portátil Intel Centrino 1.5GHz con 1Gb de Ram tarda unos 7 minutos de cálculos, y unos 25 minutos guardar los resultados en la Base de Datos. Figura 10.5: Proceso troceado 4: Troceador 128

147 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO El troceador primero obtiene tanto la capa de NODOS poboaciones como la capa de LINEAS estradas. Figura 10.6: Proceso troceado 5: Fusión nodos y líneas 129

148 10.1. CÓMO FUNCIONA 130 Calcula las intersecciones entre LINEAS y a su vez con LINEAS -las estradas que intersecan con las otras estradas - obteniendo los puntos o líneas marcados en rojo. La equivalencia con la realidad serían las rotondas Sí se interpretan con un punto. Figura 10.7: Proceso troceado 6: Intersecciones 130

149 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO Para evitar problemas, las LINEAS se procesan convirtiendo a varios LineString si son MultiLineString. Esto es necesario porque por la existencia de LINEAS no conexas -por ejemplo carreteras en construcción- que darían problemas si no están unificadas. Figura 10.8: Proceso troceado 7: Líneas 131

150 10.1. CÓMO FUNCIONA 132 Como a las bases de datos, en concreto la del ejemplo, los PUNTOS no intersecan (intersects) con las LINEAS exactamente; hay que añadir un margen de error de tolerancia desde el PUNTO, configurable en forma de radio desde el panel Configurar. En el ejemplo, tiene un error de 3 Km. a la redonda. Se puede ver representado como los lunares en amarillo (buffered). Si está a una distancia inferior que la estipulada generará una recta que una al PUNTO a la LINEA por la separación más corta. Haciendo de nuevo analogía con el mundo real, sería la distancia que separa desde el centro de Coruña, recorriendo Alfonso Molina hasta llegar a la AP-9. Si fuera un callejero con más precisión, la tolerancia se debería disminuir. r tol Figura 10.9: Proceso troceado 8: Puntos con tolerancia de error 132

151 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO Sabiendo las salidas de los PUNTOS -capa de poboaciones -, las LINEAS conexas -capa de estradas - y sus intersecciones, se calculan todos los TRAMOS, que en el mapa corresponden a lo representado en rosa. Se puede apreciar que solapa a las LINEAS y a las salidas de los PUNTOS, lo que es una buena señal de que ha detectado todos los TRAMOS. Figura 10.10: Proceso troceado 9: Tramos 133

152 10.1. CÓMO FUNCIONA 134 Se calculan las relaciones entre los TRAMOS que se toquen (touches) entre sí, y se almacenan. Por ejemplo, el tramo 6 con el tramo 7 de la Autopista AP-9. En el mapa corresponden a los puntos en color marrón. Figura 10.11: Proceso troceado 10: Relaciones entre tramos 134

153 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO Por último, hay que almacenar las relaciones de las LINEAS conexas entre sí. Por ejemplo que la carretera A-6 se toca (touches) con la E-70. Figura 10.12: Proceso troceado 11: Relaciones entre líneas 135

154 10.1. CÓMO FUNCIONA El proceso de resolución El proceso de resolución intenta reconstruir matemáticamente los TRAMOS, los PUNTOS -poboaciones- y sus relaciones (proporcionadas por el troceado) y fijando un origen y un destino paradas determinar cuál es el mejor camino por el que ir. Partimos de la misma configuración: Figura 10.13: Proceso resolución 1: Estado inicial 136

155 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO Fijamos dos paradas, Coruña y Lugo, representadas con bandera verde el origen y bandera roja el destino. Figura 10.14: Proceso resolución 2: Fijar paradas 137

156 10.1. CÓMO FUNCIONA 138 Calculamos la línea recta virtual que las une. Sería la carretera ideal y óptima si existiera. Figura 10.15: Proceso resolución 3: Línea virtual 138

157 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO Para optimizar el proceso de resolución, inflamos la linea ideal proporcionalmente (α) a la distancia que los separa (l en el mapa), y que es configurable. Si lo ponemos al máximo equivale a desactivar esta optimización. αxl l Figura 10.16: Proceso resolución 4: Optimización 139

158 10.1. CÓMO FUNCIONA 140 Se usa con el fin de recuperar sólo una proporción de la red almacenada y no tener que procesar todas las carreteras. Las carreteras en rojo serían las que tendría en cuenta, las demás para el sistema no existirían. Figura 10.17: Proceso resolución 5: Recuperar red almacenada 140

159 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO Estas carreteras se transforman en un grafo matemático, con sus costes y su función heurística. Figura 10.18: Proceso resolución 6: Grafo 141

160 10.1. CÓMO FUNCIONA 142 Se le aplica un algoritmo, que es simplemente una forma de resolución, para que una vez haya finalizado exitosamente nos devuelva un conjunto de tramos RESUL- TADO, también llamado ruta o traza. Figura 10.19: Proceso resolución 7: Aplicar algoritmo 142

161 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO Simplemente resta fusionar los tramos formando una línea, insertarla como tupla en la base de datos y dibujarla sobre el mapa para poder ver el resultado. Figura 10.20: Proceso resolución 8: Resultado final Y la traza, representada en formato de informe donde se puede ver por donde iría el camino. ORDEN PARADA RUTA KILOMETROS 1 1 A Coruña 2,732 km. 2 N-550 3,702 km. 3 N-VI 26,081 km. 4 A-9 9,681 km. 5 Betanzos 2,819 km. 6 A-6 36,244 km. 7 Guitiriz 1,321 km. 8 N-634 7,816 km. 9 Begonte 0,704 km. 10 Rábade 1,523 km. 11 Outeiro de Rei 2,335 km Lugo 2,187 km. ############## SUBTOTAL ### A Coruña => Lugo 97,145 km. T O T A L ===== ============= A Coruña => Lugo 97,145 km. Figura 10.21: Proceso resolución 9: Informe 143

162 10.1. CÓMO FUNCIONA 144 Este proceso se puede repetir sucesivamente con varias paradas [1,2,3,..., n] y se resolverían la 1 con la 2, la 2 con la 3, y así sucesivamente hasta llegar a n. Si no nos importa el orden estricto de paradas con el que se recorra, con tal de que sea el camino óptimo el camino global, es otro problema diferente conocido como problema del viajante, que se podría implementar, pero que quedó fuera de los requisitos marcados. El sistema almacena datos interesantes sobre el proceso y el resultado como pueden ser los tiempos de carga, de resolución, cuantos nodos tuvo el grafo, cuál es la distancia comparativa de las paradas, la media, el total... -ir a la página 235 del manual donde se explica cada gráfica-. Para después representarlos sobre gráficas como las siguientes: Figura 10.22: Estadísticas distancia 144

163 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO Figura 10.23: Estadísticas grafo Figura 10.24: Estadísticas tiempo 145

164 10.1. CÓMO FUNCIONA El proceso de comparación algoritmos Figura 10.25: Comparador El cometido de esta aplicación es hacer un estudio análitico, verificando que coincide con la teoría explicada en el capítulo de implementación -página 85-. Para que los resultados sean lo más exactos posibles se necesita un generador aleatorio de grafos y ejecutarlo varias veces para tener una muestra representativa. El generador de grafos aleatorio funciona de la siguiente manera: Se parte con el número de nodos desde haciendo incrementos de salto hasta alcanzar inferiormente el valor de hasta. Se repite tantas veces como sea la muestra de i iteraciones. Por ejemplo, si tenemos desde 1 hasta 32 con incrementos de 5 y 3 iteraciones de muestra, la secuencia de número de nodos sería 1,1, 1, 6,6,6, 11,11,11, 16,16,16, 21,21,21, 26,26,26, 31,31,31. Para cada n nodos se crean y se posicionan con coordenadas aleatorias (random) comprendidas entre las dimensiones visibles del panel del grafo -página 146

165 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO 217-, fijando un nodo origen y uno destino aleatoriamente y calculando su heurística. La heurística se calcula para todos los nodos como la distancia euclídea entre las coordenadas del nodo que se procesa y las coordenadas del nodo destino. Si el nodo procesado tiene coordenadas (x procesado, y procesado ) y el nodo destino (x destino, y destino ) la heurística vendría dada por: h = (x destino x procesado ) 2 + (y destino y procesado ) 2 Si d es el porcentaje de densidad elegido, y K n el grafo completo de n nodos -ver página 33- contiene el siguiente número de aristas f aristas (K n ) = n(n-1) 2 Se crearían las siguientes aristas, elegidas aleatoriamente que une un nodo 1 con nodo 2, y no repetidas. aristas crear = f aristas (K n ) (d/100) Se le asigna el coste a la arista distancia euclídea en píxeles qué separan los dos nodos. Si el nodo 1 tiene coordenadas (x 1, y 1 ) y el nodo 2 (x 2, y 2 ) el coste vendría dado por: c = (x 2 x 1 ) 2 + (y 2 y 1 ) 2 Se ejecutan los algoritmos marcados resolviendo el mismo grafo generado aleatoriamente, mientras se monitorizan, los tiempos; si ha obtenido éxito, en cuantos pasos lo resolvió. Una vez concluida la monitorización de todas las mediciones se procesan los datos individuales (calculando la media de las iteraciones por cada grafo) y generando finalmente las estadísticas. 147

166 10.1. CÓMO FUNCIONA 148 Figura 10.26: Ejemplo de grafo aleatorio: 12 nodos, 25 % de densidad 148

167 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO Resultados obtenidos Se va a realizar un estudio para averiguar empíricamente cuál de los diferentes algoritmos implementados proporciona mejores resultados para su aplicación cartográfica. La selección del mejor algoritmo consistirá en ejecutar varios tests utilizando el comparador de algoritmos desarrollado -ver página 225-, sobre un ordenador AMD Athlon 2600 Ghz con 1,5 Gb de RAM en un sistema operativo Windows XP. Se realizarán varios tests y cada uno de ellos se ejecutará múltiples veces según las configuraciones de densidad. Cada test consta de 4 gráficas asociadas: tiempo, pasos, éxitos y coste. Representan la evolución según la complejidad del grafo, ir a la página 230 donde se describe cada uno de ellos en detalle. Los primeros tests, para tener una perspectiva global, se realizarán con un rango de nodos definido para diversas configuraciones. Los sucesivos tests irán aumentando los requerimientos para ir filtrando los algoritmos considerados mejores. Se realizará tantas veces como sea necesario hasta quedarnos con un vencedor, usando para ello criterios de selección que se irán mencionando en el transcurso del análisis. Se considerará el mejor algoritmo aquel que proporcione siempre una ruta si ésta existe (el que obtenga el mayor porcentaje de éxito a nivel global), que proporcione un menor coste total, y se tendrá muy en cuenta el tiempo de respuesta empleado por el algoritmo. El primer conjunto de tests consistirá en ejecutar los algoritmos con las siguientes configuraciones: Muestra: 5 iteraciones de muestra. Rango de nodos: desde 1 hasta 501 nodos con saltos de 10. Densidades: 3 %; 10 %; 10 %; 25 %; 50 %; 100 %. 149

168 10.2. RESULTADOS OBTENIDOS 150 Tiempo (segundos) Comparador Tiempos Algoritmos Densidad: 3 %, Muestra: 5 iteraciones Numero Nodos A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Figura 10.27: TEST 1 - Resultados comparativos de tiempo con densidad 3 % Comparador Pasos Algoritmos Densidad: 3 %, Muestra: 5 iteraciones Pasos (Unidades) Numero Nodos A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Figura 10.28: TEST 1 - Resultados comparativos de pasos con densidad 3 % 150

169 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO 100 Comparador Exitos Algoritmos Densidad: 3 %, Muestra: 5 iteraciones Porcentaje (%) A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Algoritmos Exito Fracaso Figura 10.29: TEST 1 - Resultados comparativos de éxitos con densidad 3 % Comparador Costes Algoritmos Densidad: 3 %, Muestra: 5 iteraciones Coste Total (Unidades) A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Algoritmos Coste Total Figura 10.30: TEST 1 - Resultados comparativos de coste con densidad 3 % 151

170 10.2. RESULTADOS OBTENIDOS Comparador Tiempos Algoritmos Densidad: 10 %, Muestra: 5 iteraciones Tiempo (segundos) Numero Nodos A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Figura 10.31: TEST 2 -Resultados comparativos de tiempo con densidad 10 % Comparador Pasos Algoritmos Densidad: 10 %, Muestra: 5 iteraciones Pasos (Unidades) Numero Nodos A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Figura 10.32: TEST 2 - Resultados comparativos de pasos con densidad 10 % 152

171 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO 100 Comparador Exitos Algoritmos Densidad: 10 %, Muestra: 5 iteraciones Porcentaje (%) A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Algoritmos Exito Fracaso Figura 10.33: TEST 2 - Resultados comparativos de éxitos con densidad 10 % Comparador Costes Algoritmos Densidad: 10 %, Muestra: 5 iteraciones Coste Total (Unidades) A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Algoritmos Coste Total Figura 10.34: TEST 2 - Resultados comparativos de coste con densidad 10 % 153

172 10.2. RESULTADOS OBTENIDOS 154 Tiempo (segundos) Comparador Tiempos Algoritmos Densidad: 25 %, Muestra: 5 iteraciones Numero Nodos A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Figura 10.35: TEST 3 - Resultados comparativos de tiempo con densidad 25 % 350 Comparador Pasos Algoritmos Densidad: 25 %, Muestra: 5 iteraciones Pasos (Unidades) Numero Nodos A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Figura 10.36: TEST 3 - Resultados comparativos de pasos con densidad 25 % 154

173 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO 100 Comparador Exitos Algoritmos Densidad: 25 %, Muestra: 5 iteraciones Porcentaje (%) A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Algoritmos Exito Fracaso Figura 10.37: TEST 3 - Resultados comparativos de éxitos con densidad 25 % Comparador Costes Algoritmos Densidad: 25 %, Muestra: 5 iteraciones Coste Total (Unidades) A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Algoritmos Coste Total Figura 10.38: TEST 3 - Resultados comparativos de coste con densidad 25 % 155

174 10.2. RESULTADOS OBTENIDOS 156 Comparador Tiempos Algoritmos Densidad: 50 %, Muestra: 5 iteraciones Tiempo (segundos) Numero Nodos A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Figura 10.39: TEST 4 - Resultados comparativos de tiempo con densidad 50 % Comparador Pasos Algoritmos Densidad: 50 %, Muestra: 5 iteraciones Pasos (Unidades) Numero Nodos A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Figura 10.40: TEST 4 - Resultados comparativos de pasos con densidad 50 % 156

175 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO 100 Comparador Exitos Algoritmos Densidad: 50 %, Muestra: 5 iteraciones Porcentaje (%) A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Algoritmos Exito Fracaso Figura 10.41: TEST 4 - Resultados comparativos de éxitos con densidad 50 % Comparador Costes Algoritmos Densidad: 50 %, Muestra: 5 iteraciones Coste Total (Unidades) A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Algoritmos Coste Total Figura 10.42: TEST 4 - Resultados comparativos de coste con densidad 50 % 157

176 10.2. RESULTADOS OBTENIDOS Comparador Tiempos Algoritmos Densidad: 100 %, Muestra: 5 iteraciones Tiempo (segundos) Numero Nodos A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Figura 10.43: TEST 5 - Resultados comparativos de tiempo con densidad 100 % Pasos (Unidades) Comparador Pasos Algoritmos Densidad: 100 %, Muestra: 5 iteraciones Numero Nodos A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Figura 10.44: TEST 5 - Resultados comparativos de pasos con densidad 100 % 158

177 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO 100 Comparador Exitos Algoritmos Densidad: 100 %, Muestra: 5 iteraciones Porcentaje (%) A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Algoritmos Exito Fracaso Figura 10.45: TEST 5 - Resultados comparativos de éxitos con densidad 100 % Comparador Costes Algoritmos Densidad: 100 %, Muestra: 5 iteraciones Coste Total (Unidades) A* IDA* Dijkstra Uniform Cost Greedy Search Hill Climbing 1 Hill Climbing 2 Beam Search 1 Beam Search 2 Beam Search 3 Beam Search 4 Beam Search 5 Depth first Breadth first Algoritmos Coste Total Figura 10.46: TEST 5 - Resultados comparativos de coste con densidad 100 % 159

178 10.2. RESULTADOS OBTENIDOS 160 Conclusiones de los primeros resultados: El algoritmo A* por lo general dio buenos resultados a nivel global en todos los sentidos, por tanto sí pasa el test sin problemas. En los resultados de IDA* se puede apreciar un posible problema con el algoritmo por los picos de tiempo, pero tras analizar este caso, se determinó que no es debido a un problema oculto en la implementación. Se explica este suceso si conocemos el funcionamiento del algoritmo: si el camino tiene que dar algún rodeo, la estimación que hace del coste no le vale, y tiene que hacer muchas iteraciones de A* subiendo cada vez esa estimación muy poco hasta que llega al coste real. En definitiva, es óptimo pero su rendimiento es muy variable. No pasa el test. Dijkstra destaca porque proporciona el coste óptimo, pero requiere de mucho más tiempo que otros, por este motivo se descarta. No pasa el test. Uniform Cost proporciona el coste óptimo sin problemas aparentes en el tiempo de respuesta. Sí pasa el test. Greedy Search consigue pasar el test aunque da unos costes algo superiores a otros. Sí pasa el test. Hill Climbing 1 tiene algo elevados sus costes. Sí pasa test. Hill Climbing 2 tiene un porcentaje de éxitos bastante malo. No pasa el test. 160

179 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO En los Beam Search se aprecia que, por lo general, al aumentar el parámetro beam mejoran levemente los resultados en bajas densidades, por lo tanto sí pasa, pero nos quedamos tan sólo con el Beam Search 5. Depth First Search (DFS) tiene un porcentaje de éxito óptimo, no obstante da un coste muy superior a los otros (porque la ruta elegida puede dar muchos rodeos antes de llegar al nodo final), por lo que se descarta. No pasa el test. Breadth First Search (BFS) tiene un porcentaje de éxito óptimo, y da unos costes aceptables. Sí pasa el test. En resumen, de la primera criba pasaron el test: A*, Uniform Cost, Greedy Search, Hill Climbing 1, Beam Search 5, Breadth First. Los segundos conjuntos de tests consistirán en ejecutar los algoritmos, sabiendo por la experiencia que la densidad de la cartografía empleada suele rondar entre el 1 % y como mucho un 5 %, y se emplea la siguiente configuración: Muestra: 3 iteraciones de muestra. Rango de nodos: desde 1 hasta nodos con saltos de 25. Densidades: 1 %; 5 %. Tras un total de 738 ejecuciones por cada gráfica, estos han sido los resultados obtenidos: 161

180 10.2. RESULTADOS OBTENIDOS Comparador Tiempos Algoritmos Densidad: 1 %, Muestra: 3 iteraciones Tiempo (segundos) Numero Nodos A* Uniform Cost Greedy Search Hill Climbing 1 Beam Search 5 Breadth first Figura 10.47: TEST 6 - Resultados comparativos de tiempo con densidad 1 % Comparador Pasos Algoritmos Densidad: 1 %, Muestra: 3 iteraciones Pasos (Unidades) Numero Nodos A* Uniform Cost Greedy Search Hill Climbing 1 Beam Search 5 Breadth first Figura 10.48: TEST 6 - Resultados comparativos de pasos con densidad 1 % 162

181 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO 100 Comparador Exitos Algoritmos Densidad: 1 %, Muestra: 3 iteraciones Porcentaje (%) A* Uniform Cost Greedy Search Hill Climbing 1 Beam Search 5 Breadth first Algoritmos Exito Fracaso Figura 10.49: TEST 6 - Resultados comparativos de éxitos con densidad 1 % Comparador Costes Algoritmos Densidad: 1 %, Muestra: 3 iteraciones Coste Total (Unidades) A* Uniform Cost Greedy Search Hill Climbing 1 Beam Search 5 Breadth first Algoritmos Coste Total Figura 10.50: TEST 6 - Resultados comparativos de coste con densidad 1 % 163

182 10.2. RESULTADOS OBTENIDOS Comparador Tiempos Algoritmos Densidad: 5 %, Muestra: 3 iteraciones Tiempo (segundos) Numero Nodos A* Uniform Cost Greedy Search Hill Climbing 1 Beam Search 5 Breadth first Figura 10.51: TEST 7 - Resultados comparativos de tiempo con densidad 5 % Comparador Pasos Algoritmos Densidad: 5 %, Muestra: 3 iteraciones. Pasos (Unidades) Numero Nodos A* Uniform Cost Greedy Search Hill Climbing 1 Beam Search 5 Breadth first Figura 10.52: TEST 7 - Resultados comparativos de pasos con densidad 5 % 164

183 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO 100 Comparador Exitos Algoritmos Densidad: 5 %, Muestra: 3 iteraciones Porcentaje (%) A* Uniform Cost Greedy Search Hill Climbing 1 Beam Search 5 Breadth first Algoritmos Exito Fracaso Figura 10.53: TEST 7 - Resultados comparativos de éxitos con densidad 5 % Comparador Costes Algoritmos Densidad: 5 %, Muestra: 3 iteraciones Coste Total (Unidades) A* Uniform Cost Greedy Search Hill Climbing 1 Beam Search 5 Breadth first Algoritmos Coste Total Figura 10.54: TEST 7 - Resultados comparativos de coste con densidad 5 % 165

184 10.2. RESULTADOS OBTENIDOS 166 Conclusiones de la segunda selección: A* parece destacar como líder, obtiene el coste óptimo sin dificultades y en tiempo suele ser bastante constante. Sí pasa el test. Uniform Cost proporciona igualmente el óptimo, pero con peor tiempo. Motivo por el cual no pasa el test. Greedy Search no proporciona el óptimo pero si una aproximación de coste aceptable en un buen tiempo. Sí pasa el test. Hill Climbing 1 descalificado por proporcionar un coste demasiado alto. No pasa el test. Beam Search 5 proporciona un coste algo excesivo. No pasa el test. Breadth First proporciona un coste aproximado al óptimo, en un tiempo algo superior. Sí pasa el test. En resumen, han superado el filtro: A*, Greedy Search, y Breadth First. La tercera y última ronda de tests se realizará con la siguiente configuración: Muestra: 5 iteraciones de muestra. Rango de nodos: desde 1 hasta nodos con saltos de 100. Densidades: 3 %. Después de 765 ejecuciones de algoritmos por cada test éste ha sido el resultado: 166

185 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO Comparador Tiempos Algoritmos Densidad: 3 %, Muestra: 5 iteraciones Tiempo (segundos) Numero Nodos A* Greedy Search Breadth first Figura 10.55: TEST 8 - Resultados comparativos de tiempo con densidad 3 % Comparador Pasos Algoritmos Densidad: 3 %, Muestra: 5 iteraciones Pasos (Unidades) Numero Nodos A* Greedy Search Breadth first Figura 10.56: TEST 8 - Resultados comparativos de pasos con densidad 3 % 167

186 10.2. RESULTADOS OBTENIDOS Comparador Exitos Algoritmos Densidad: 3 %, Muestra: 5 iteraciones Porcentaje (%) A* Greedy Search Breadth first Algoritmos Exito Fracaso Figura 10.57: TEST 8 - Resultados comparativos de éxitos con densidad 3 % Comparador Costes Algoritmos Densidad: 3 %, Muestra: 5 iteraciones Coste Total (Unidades) A* Greedy Search Breadth first Algoritmos Coste Total Figura 10.58: TEST 8 - Resultados comparativos de coste con densidad 3 % 168

187 CAPÍTULO 10. RESULTADOS Y RENDIMIENTO A* es el claro vencedor en relación al coste del resultado y el que proporciona siempre el óptimo, siendo el tiempo empleado algo superior a los otros. Greedy Search se queda con el segundo puesto siendo una buena aproximación en coste y en tiempo, pero no nos proporciona la mejor ruta. Breadth First se queda con una tercera posición por el coste obtenido, no obstante gana al resto en tiempo, por lo que sería el mejor algoritmo para determinar si una red es conexa. De los resultados obtenidos empíricamente y contrastados de forma teórica se concluye que el más adecuado para aplicar a la cartografía buscando la ruta óptima es el algoritmo A* Rendimiento El rendimiento hace referencia al resultado deseado en relación con el tiempo empleado para obtenerlo. Una aplicación de este tipo requiere una cierta cantidad de recursos limitados (como puede ser de CPU y memoria). La eficiencia de los cálculos y de los procesos determinan en gran medida la utilidad de la aplicación, incluso que la información obtenida deje de tener valor por la demora en su obtención. Para llegar a ese objetivo de rendimiento óptimo, se ha monitorizado la aplicación para detectar los cuellos de botella, se han implementado técnicas de poda, se ha gestionado, testado y evitado la redundancia de cálculos, minimizando la necesidad de recursos utilizados. 169

188

189 Capítulo 11 Síntesis del trabajo En este capítulo se explican las conclusiones obtenidas una vez finalizado el proyecto, así como posibles mejoras que puedan realizarse Conclusiones En este proyecto se han alcanzado todos los objetivos marcados: se ha realizado una extensión de análisis de redes sobre la herramienta de información geográfica gvsig, que implementa diferentes algoritmos de inteligencia artificial para resolver el problema de búsqueda de rutas óptimas sobre grafos, y cuyos resultados son visualizables sobre el mapa y a modo de informe detallado exportable a PDF. Este tipo de análisis requiere de una gran cantidad de recursos computacionales por lo que los algoritmos, para poder desempeñar su cometido en un tiempo razonable, han tenido que ser comprobados y optimizados obteniendo enormes mejoras de rendimiento. Con el fin de añadir más valor a la aplicación a nivel didáctico se proporciona un comparador de algoritmos con el que obtener resultados reales de tiempo, coste y eficiencia de los algoritmos, visualizables en diagramas de líneas y barras, con el que se ha realizado un estudio exhaustivo. Pensando en los usuarios inexpertos se ha desarrollado interfaces amigables, realizado un asistente con el que guiarles por la aplicación e integrado un manual de 171

190 11.1. CONCLUSIONES 172 usuario con el que resolver dudas (anexado en el apéndice A en la página 177). A nivel personal, después de casi un año de trabajo, me supone una gran satisfacción y reto personal el desarrollo de un software siguiendo la filosofía Open Source con el que ayudar a la comunidad. Se han tenido todo tipo de problemas durante el desarrollo, pero como futuro ingeniero se han buscado soluciones, o bien alternativas, preguntando a personas más experimentadas en el dominio del problema, que en definitiva es lo que considero que se persigue: la habilidad de resolver problemas no estructurados. Sobre este proyecto, decir que ha sido muy trabajoso, por la ambición de superación y mejora constante, con la que he adquirido, ampliado y mejorado conocimientos de muchísimos temas que desconocía por lo que sin lugar a dudas volvería a elegir este proyecto. Entrando un poco más en detalle, las herramientas integradas como Eclipse me han facilitado el trabajo de desarrollo y la potencia de Photoshop es inigualable para la edición de imágenes; GvSIG cada día tiene más adeptos, aunque si se dispusiera de más documentación técnica, la cantidad y calidad de los proyectos de este tipo aumentaría notablemente. Sobre la redacción de la memoria, la fama que tiene L A TEX de profesionalidad es bien merecida. Una buena planificación de proyectos intenta minimizar el coste, el tiempo y el esfuerzo aunque en proyectos unipersonales, como es el caso, ha llegado con llevarlo de manera informal realizando un registro, marcándose unos hitos y realizando revisiones continuas para saber en todo momento cómo va el proyecto, para evitar al final desagradables sorpresas. La ley de Murphy 1 siempre está presente. La Metodología de Prototipado Rápido se adaptó perfectamente a mi estilo de trabajo y al tipo de desarrollo de las cuales la tarea de análisis es sobre la que recae el mayor peso del esfuerzo para evitar desviaciones causadas por la mala comprensión. Se han realizado dos prototipos para ayudar a detectar la mayor cantidad de requisitos iniciales del usuario a la vez que el analista se introduce en el dominio de la aplicación. Sobre la diagramación con UML 2.0 comentar que su gran baza es su flexibilidad y su semántica extensa. 1 Ley de Murphy: si algo tiene la posibilidad de salir mal, saldrá mal 172

191 CAPÍTULO 11. SÍNTESIS DEL TRABAJO El empleo de estándares permite mayor facilidad de programación y comprensión a la hora de revisar el código, en la que en este aspecto Java se merece un sobresaliente por su gran potencia y la inmensa comunidad de desarrollo y apoyo que lo rodea. De los resultados obtenidos concluir que se ha realizado un software útil, potente y con aplicación didáctica con la que después de realizar un estudio sobre diversos algoritmos de búsqueda de rutas de forma exhaustivo a nivel teórico y verificarlo empíricamente, de los resultados obtenidos se concluye que el más adecuado para aplicar a la cartografía buscando la ruta óptima es el algoritmo A* Líneas de trabajo futuras Toda aplicación siempre es mejorable, algunas de las posibles mejoras opcionales que se han quedado fuera de los objetivos y por falta de tiempo no han sido implementadas han sido: Aunque se investigó el algoritmo metaheurístico Ant Colony Optimization (ACO), cuyo funcionamiento se basa en probabilidades, imitando a las hormigas y a sus feromonas, y dado el limitado tiempo disponible se prefirió hacer más énfasis en el análisis de algoritmos porque los resultados serían más significativos. En la vida real existen restricciones que se pueden considerar, cómo puede ser el sentido de la vía. Se podría resolver usando grafos dirigidos complicándose la implementación y seguramente simplificando la resolución al tener menos caminos que considerar. Sería muy interesante realizar cálculos en función del tiempo en vez de distancias, ponderando la distancia por la velocidad permitida según sea tipo de vía por la que se transita. Ej. autopistas, carretera comarcal, núcleo urbano... Otra posible mejora son las penalizaciones por giros que consisten en castigar aquellas soluciones cuyos giros produzcan cambios de velocidad añadiendo un tiempo de retraso, incluso diferentes valores si son giros hacia la izquierda o hacia la derecha. 173

192

193 Bibliografía [1] Brisaboa, N. R., Cotelo, J. A., Fariña, A., Luaces, M. R., Paramá, J. R., Viqueira, J. R. COLLECTING AND PUBLISHING MASSIVE GEOGRAPHIC DATA [2] Bruce Eckel. PIENSA EN JAVA (Segunda edición). Pearson Education. ISBN: Madrid, [3] Geschwinde, Ewald. POSTGRESQL DEVELOPER S HANDBOOK. Indianapolis, Indiana: Sam s [4] G. Booch, J. Rumbaugh, I. Jacobson. EL LENGUAJE UNIFICADO DE MO- DELADO Addison Westley Iberoamericana. Madrid, [5] James R.Groff, Paul N.Weinberg. GUIA DE SQL. McGrawHill, [6] Larman, C. UML Y PATRONES. Una introducción a objetos y al proceso unificado. (Segunda edición) Pearson educación S.A. Matrid, [7] Mittelbach, Frank. THE LATEX COMPANION. (2nd edition). Pearson Education. ISBN Boston, [8] Pressman, Roger S. PRÁCTICO. McGraw-Hill. 6a edición INGENIERÍA DEL SOFTWARE. UN ENFOQUE [9] Rodríguez Fernández, Ángel. Rodríguez Luaces, Miguel Ángel. ANÁLISIS DE REDES EN UN SISTEMA DE INFORMACIÓN GEOGRÁFICA. Universidade da Coruña

194 BIBLIOGRAFÍA 176 [10] Algoritmos Inteligencia Artificial. dannyd/ai Kortrijk. [11] Computational Geometry Algorithms Library (CGAL). [12] Definiciones glosario GIS. [13] Documentación LaTeX. [14] Documentación patrones. fbellas/teaching/is [15] Eclipse (plataforma de desarollo). [16] Gómez Rodríguez, Carlos. FAQ Java [17] GvSIG. Consellería de Infraestructuras y Transporte e IVER Tecnologías de la información S.A. [18] Java Plugins. [19] javasoft) Java Software [20] Java Technology. [21] JTS Topology Suite. [22] Libreria itext. [23] Libreria JFreeChart. [24] Libreria JSearchDemo. [25] OGC Open Geospatial Consortium [26] PostGIS. [27] PostgreSQL. [28] Sistema EXTremeño de ANálisis TErritorial (SEXTANTE)

195 Apéndice A Manual de usuario 177

196 A.1. REQUISITOS DEL SISTEMA 178 A.1. Requisitos del sistema Debe estar instalado un entorno de ejecución Java (JRE) que implemente la versión 1.4 o superior de las APIs de Java 2 Standard Edition (J2SE) siendo bastante recomendable usar la misma versión que emplee gvsig (actualmente v.5) con sus mismas dependencias (los plugins instalados de JAI 1 e image I/O sobre la máquina virtual que gvsig utilice en su ejecución [18] para que tenga toda su funcionalidad operativa). La manera más fácil para cumplir los requisitos es descargarse el gvsig con los prerrequisitos de su página oficial [17]. Al funcionar sobre la máquina virtual Java, el sistema podrá ejecutarse en cualquier plataforma que disponga de dicho JRE, aunque para utilizar gvsig se recomienda Windows 98/XP, Linux Ubuntu/Debian/Suse. El programa requiere de una CPU algo potente, tipo Pentium 4 y un mínimo de memoria RAM de 512Mb, siendo muy recomendable de 1Gb de RAM para que los cálculos sean más rápidos, ya que dependiendo del tipo de algoritmo variará la complejidad de tiempo y memoria. Si se desea desarrollar o modificar la aplicación, es recomendable usar Eclipse y para mayor comodidad tener instalado el sistema de construcción Apache Ant, que permitirá compilar fácilmente usando el fichero build.xml, adjuntado en el directorio raíz del proyecto. A.2. Instalación Obtenemos el software desde el DVD adjunto, en el apartado Software -ver página 253-, o descargándolos de las páginas web oficiales, ver bibliografía -página JAI: Java Advanced Imaging 178

197 APÉNDICE A. MANUAL DE USUARIO A.2.1. PostgreSQL & PostGis Windows 1. Elegimos el fichero postgresql zip y lo descomprimimos. 2. Ejecutamos el fichero postgresql-8.2.msi. 3. Elegimos el idioma deseado, seleccionamos Next. Figura A.1: Instalación de PostgreSQL Aceptamos la recomendación de cerrar todos los programos, seleccionamos Next. Figura A.2: Instalación de PostgreSQL

198 A.2. INSTALACIÓN Después de terminar de leer las notas de instalación que nos advierte que no corramos el servidor como administrador, continuamos con Next. Figura A.3: Instalación de PostgreSQL Marcamos PostGIS Spatial Extensions seleccionando el icono con el secundario y seleccionamos que la instale en el Disco Duro para que quede como en la imagen. Pulsamos Next. Figura A.4: Instalación de PostgreSQL

199 APÉNDICE A. MANUAL DE USUARIO 7. Elegimos instalar la base de datos como un servicio (por comodidad) y establecemos un usuario y contraseña. Pulsamos Next. Figura A.5: Instalación de PostgreSQL Si no existe se creará y respondemos Si. Si existe, no debe estar en el grupo de administradores. Figura A.6: Instalación de PostgreSQL Si la contraseña es muy fácil de piratear, nos sugiere una aleatoria. No hay problema porque es la que se pone en el administrador de servicios y no la tenemos ni que conocer. Respondemos según el gusto del usuario lo que queramos. Figura A.7: Instalación de PostgreSQL

200 A.2. INSTALACIÓN Definimos parámetros de configuración (sobre todo el super-usuario y contraseña). Pulsamos Next. Figura A.8: Instalación de PostgreSQL Elegimos el nombre usado como lenguaje de Script para los procedimientos almacenados. Pulsamos Next. Figura A.9: Instalación de PostgreSQL

201 APÉNDICE A. MANUAL DE USUARIO 12. Seleccionamos los módulos opcionales (dejamos la configuración por defecto de momento). Pulsamos Next. Figura A.10: Instalación de PostgreSQL Por último después de pulsar Next esperamos que se copien los ficheros e inicialice la Base de datos. De producirse algún error seguramente es debido a que no tiene concedido permisos o que ya existe la cuenta, en este caso se recomienda ir pulsando con el secundario del ratón sobre Mi PC seleccionar Administración de equipos y en el apartado de Usuarios locales comprobar los permisos-. Figura A.11: Instalación de PostgreSQL

202 A.2. INSTALACIÓN 184 Figura A.12: Instalación de PostgreSQL Cuando salga la ventana final pulsamos Finish significando que todo ha salido bien. Podemos verificarlo desde el Menú Inicio ha creado una carpeta denominada PostgreSQL que contiene iconos de los servicios y arrancamos el administrador pgadmin (que ya se ha instalado). Figura A.13: Instalación de PostgreSQL

203 APÉNDICE A. MANUAL DE USUARIO Linux Como ejemplo se pone la instalación sobre Ubuntu Gusty Gibbon, en los demás SO s la instalación debe ser muy parecida, quizás solo teniendo que configurar previamente los repositorios por defecto en /etc/apt/sources.list), se instalará la versión 8.2 de PostgreSQL. 1. Abrimos un terminal. 2. ingmau00@maquina:$ sudo apt-get install postgresql-8.2 postgresql-8.2-postgis postgis Escribimos la contraseña del root, y se instalará desde los repositorios que tengamos -en nuestro caso, Ubuntu - los paquetes: libpq5 postgresql-8.2 postgresqlclient-8.2 postgresql-client-common postgresql-common postgis postgresql-8.2- postgis, si es que no lo tenemos instalados. 3. Una vez instalado postgresql con la extensión PostGis, necesitamos acceder a la cuenta postgres. ingmau00@maquina:$ sudo bash root@maquina:# su postgres Hecho esto, nos aparecerá un nuevo prompt: postgres@maquina:$ Ahora crearemos un usuario para las Bases de Datos, usando el comando createuser seguido del nombre de usuario que necesitemos; en mi caso crearé el usuario ingmau00: postgres@maquina:$ createuser ingmau00 Será el nuevo rol un superusuario? (s/n) s CREATE ROLE 185

204 A.2. INSTALACIÓN Procedemos a crear una Base de Datos para experimentar, en mi caso crearé la BD mibd: postgres@maquina:$ createdb mibd CREATE DATABASE Una vez hecho esto, volvemos a la consola de nuestra cuenta de usuario, haciendo: postgres@maquina:$ exit root@maquina:\# exit ingmau00@maquina:$ 5. Arrancamos postgres: ingmau00@maquina:$ psql mibd Dicho comando nos mostrará una salida como ésta: Bienvenido a psql 8.2.3, la terminal interactiva de PostgreSQL Digite: \copyright para ver los términos de distribución \h para ayuda de comandos SQL \? para ayuda de comandos psql \g o or termine con punto y coma para ejecutar una consulta \q para salir mibd=# Esto nos indica que hemos entrado a la Base de Datos. En este punto, podremos ejecutar todos los comandos en SQL que necesitemos. 186

205 APÉNDICE A. MANUAL DE USUARIO Como último paso, por cuestiones de seguridad, podremos cambiar la contraseña de nuestro usuario de la Base de Datos. mibd=# alter user ingmau00 with password password ; ALTER ROLE 6. Para salir de la Base de Datos hacemos: mibd=# \q Finalmente, para conectarnos desde la consola a la Base de Datos que acabamos de crear, cada vez que así lo necesitemos, bastará con ejecutar el comando: ingmau00@maquina:$ psql -h localhost mibd Contrase~na: password 7. Eso es todo en cuanto al manejo de postgres desde la consola, ahora veamos la instalación y manejo de pgadmin. ingmau00@maquina:$ sudo apt-get install pgadmin3 El comando anterior nos permitirá instalar los paquetes: libpq4 pgadmin3 pgadmin3-data Bien, ahora ejecutemos el programa que acabamos de instalar: ingmau00@maquina:\$ pgadmin3 & Hecho esto, procedemos a añadir un servidor para nuestro programa, siguiendo el menú: Archivo -> A~nadir Servidor

206 A.2. INSTALACIÓN 188 Ingresemos la información solicitada en el diálogo presentado: Dirección: localhost Descripción: Conexion con localhost BD de mantenimiento: mibd Nombre de Usuario: ingmau00 Contrase~na: password En Dirección debemos ingresar la ubicación de nuestra Base de Datos, en nuestro caso será localhost puesto que estamos trabajando con una Base de Datos local. En Descripción preferentemente describiremos la conexión con el servidor que estamos creando. BD de mantenimiento, en dicho campo ingresaremos el nombre de la Base de Datos que vamos a manejar. Nombre de usuario, ingresamos el nombre de usuario que creamos como cuenta en el DBMS. ingmau00 en nuestro ejemplo. Contraseña, ingresamos el password que asignamos al nombre de usuario que hemos creado. Le damos a aceptar. Luego, hacemos doble click en la nueva conexión creada y observaremos algo como esto: 188

207 APÉNDICE A. MANUAL DE USUARIO Figura A.14: Postgresql desde Linux: Pgadmin3 Cabe rescatar que la interfaz provista por pgadmin es bastante amigable, se puede hacer todo, desde crear una tabla hasta crear más Bases de Datos, simplemente a base de un click derecho en el elemento deseado del panel izquierdo. Por ejemplo, si deseamos crear una tabla debemos hacer click derecho en el item Tablas(n) y luego en nueva tabla (donde n es el número de tablas que tenemos actualmente), para llenar el nombre y el propietario. En síntesis, es cuestión de explorar un poco las opciones y menús del programa, de acuerdo a nuestras necesidades, claro está. 189

208 A.2. INSTALACIÓN 190 A.2.2. GvSIG Windows La primera ventana que se muestra le pregunta si desea instalar gvsig, pulse Sí, a continuación se prepara la instalación de los componentes. Figura A.15: Instalación gvsig en Windows -1- La siguiente ventana permite comprobar que los requisitos previos están disponibles, si selecciona Sí el propio instalador buscará en el sistema los requisitos previos e intentará instalar aquellos que no encuentra. Si selecciona No deberá establecer manualmente cuál es la máquina virtual que debe utilizarse. Figura A.16: Instalación gvsig en Windows -2- Instalación de la máquina virtual de java Si el instalador detecta que no hay una máquina virtual instalada compatible con gvsig intentará instalarla ya sea desde el propio instalador o desde Internet. Acepte los términos de la licencia de Sun si está de acuerdo y pulse siguiente. 190

209 APÉNDICE A. MANUAL DE USUARIO Seleccione el modo de instalación típica (recomendada) o personalizada, pulse siguiente. Figura A.17: Instalación gvsig en Windows -3- Cuando finalice la instalación de la máquina virtual pulse finalizar. Figura A.18: Instalación gvsig en Windows

210 A.2. INSTALACIÓN 192 Instalación java advanced image Figura A.19: Instalación gvsig en Windows -5- Pulse next y acepte la licencia. Figura A.20: Instalación gvsig en Windows

211 APÉNDICE A. MANUAL DE USUARIO Seleccione donde desea instalar la librería (recomendado opción por defecto), pulse next. Figura A.21: Instalación gvsig en Windows -7- Instalación java advanced image IO. Figura A.22: Instalación GvSig en Windows

212 A.2. INSTALACIÓN 194 Pulse next y acepte la licencia. Figura A.23: Instalación gvsig en Windows -9- Seleccione donde desea instalar la librería (recomendado opción por defecto), pulse next. Figura A.24: Instalación GvSig en Windows

213 APÉNDICE A. MANUAL DE USUARIO Seleccione el modo de instalación típica (recomendada) o personalizada, pulse next. Figura A.25: Instalación GvSig en Windows -11- Pulse finalizar. Figura A.26: Instalación gvsig en Windows

214 A.2. INSTALACIÓN 196 Linux En la primera ventana de la instalación puede optar entre varias opciones. Cuando seleccione una opción el instalador comprobará que la máquina virtual que se ha establecido es válida, y en caso contrario mostrará un mensaje de error y le permitirá escoger otra forma de instalar. Figura A.27: Instalación gvsig en Linux Use a JRE used by a previous gvsig version. (Recomendado si ha instalado una versión de gvsig anteriormente) Si selecciona esta opción el instalador comprobará los requisitos previos. 2. install a JRE version ready to run in the user home directory. (Recomendado si nunca ha instalado gvsig) Si selecciona esta opción se instalará los requisitos previos en el directorio del usario, dentro de la carpeta gvsig/jre/ /. Si está instalando desde el instalador con los requisitos previos incluidos (el más grande), se instalarán desde el instalador, si por el contrario está instalando desde otro instalador intentará descargar desde internet una máquina virtual con las librerías; si no puede descargar la máquina virtual mostrará un mensaje de error y le permitirá escoger otra opción de instalación. 3. select JRE manualy. (Avanzado) Esta opción le permite indicar manualmente una máquina virtual para que la utilice gvsig. 4. use the defined in JAVE HOME enviromenrt variable or finded in the shell execution path. (Avanzado) Indica al instalador que debe utilizar la máquina virtual definida en el JAVE HOME o en el path. 196

215 APÉNDICE A. MANUAL DE USUARIO Instalación de gvsig pasos comunes Windows y Linux Seleccione el idioma con el que desea se realice la instalación y pulse el botón Ok. Figura A.28: Asistente Instalación gvsig -1- Se le mostrará a continuación una ventana de presentación, pulse siguiente Figura A.29: Asistente Instalación gvsig

216 A.2. INSTALACIÓN 198 Lea atentamente la licencia de gvsig y seleccione Acepto los términos de la licencia ; si acepta la licencia y desea continuar la instalación pulse el botón siguiente. Figura A.30: Asistente Instalación gvsig -3- Seleccione las extensiones de gvsig que desea instalar y pulse siguiente. Figura A.31: Asistente Instalación gvsig

217 APÉNDICE A. MANUAL DE USUARIO Seleccione el directorio donde desea instalar gvsig y pulse siguiente. Figura A.32: Asistente Instalación gvsig -5- Si el directorio no existe se le mostrará la siguiente ventana: Figura A.33: Asistente Instalación gvsig -6- Si no existe se le mostrará esta otra ventana: Figura A.34: Asistente Instalación gvsig

218 A.2. INSTALACIÓN 200 A continuación se mostrará una ventana mostrando el progreso de la instalación. Figura A.35: Asistente Instalación gvsig -8- Cuando la instalación de los componentes haya finalizado se mostrará una ventana para indicar donde crear los accesos rápidos a gvsig. Figura A.36: Asistente Instalación gvsig

219 APÉNDICE A. MANUAL DE USUARIO Si todo ha sido correcto se mostrará la siguiente ventana. Figura A.37: Asistente Instalación gvsig -10- A.3. Extensión análisis de redes Hay varias formas para conseguir ejecutar la extensión Copiando la carpeta de la extensión compilada del proyecto, carpeta dist, a la ruta HOME_GVSIG\gvSIG\extensiones\ donde HOME_GVSIG sería la ruta donde fue instalada la aplicación. Desde Eclipse, cargando el fichero Apache Ant, llamado build.xml, hacer dobleclick sobre PFC -> GVSIG y lo copiará a las fuentes compiladas a _fwandami\gvsig\extensiones 201

220 A.4. EJECUCIÓN 202 A.4. Ejecución Hay dos formas de ejecución Independiente: Consiste en cargar la extensión sin gvsig, es tan simple como en Windows ejecutar el fichero run.bat que está en los binarios compilados -la carpeta dist-. En Linux sería lo equivalente, desde un terminal, situándose en el directorio de los binarios de la extensión y ejecutar el comando sh run.bat. Dependiente: Arrancar gvsig, y el programa se encarga de cargarlo reconociendo las extensiones situadas en la carpeta extensiones. De igual modo se puede cargar directamente desde el eclipse (modo debugger ). 202

221 APÉNDICE A. MANUAL DE USUARIO A.5. Utilización A.5.1. GvSIG Menú sobre gvsig... Figura A.38: Menú extensión en gvsig Es el menú desplegable un acceso directo a toda la funcionalidad que aporta esta extensión; esta configurado en el fichero xml -ver página 106 para detalles de implementación-. AVANZADO: Carpeta que contiene menús adicionales. Modo developer: Consultar la página 206. Sentencias SQL: Consultar la página 210. Configurar: Consultar la página

222 A.5. UTILIZACIÓN 204 Crear Red: Consultar la página 210. Listar Redes: Consultar la página 211. Capa Arcos: Consultar la página 212. Capa Nodos: Consultar la página 213. Trocear Red: Consultar la página 214. Paradas: Consultar la página 215. Calculo Ruta Optima: Consultar página 238. Comparador: Consultar la página 225. Estadísticas: Consultar la página 229. Asistente: Consultar la página 238. Memoria: Lanza esta memoria en formato pdf con el programa asociado a dicha extensión. En la barra de herramientas de gvsig se incorpora el acceso directo de calculador de rutas modo barra, que es muy útil de manejar, ver página

223 APÉNDICE A. MANUAL DE USUARIO Menú acerca de... Figura A.39: Menú about en gvsig Es el menú que se carga en gvsig en Ayuda > Acerca de... > Pestaña PFC. Muestra información acerca de las extensiones instaladas e información adicional como es la versión de Java, información de contacto con los desarrolladores etc. 205

224 A.5. UTILIZACIÓN 206 A.5.2. Menú developer Figura A.40: Menú developer Es el menú principal de la aplicación cuando se ejecuta de forma independiente, es decir, sin la necesidad de que se arranque gvsig detectando esta situación e inhabilitando la funcionalidad de crear capa sobre gvsig. Se lanza ese modo ejecutando el fichero run.bat que se encuentra en la carpeta raíz de la extensión o bien en el Menú Avanzado > Modo developer dentro de gvsig. Su utilidad es precisamente, por dicha independencia, la de debuggear sin tener que esperar a arrancar todo el programa para hacer las primeras pruebas. En la parte derecha se encuentra la información básica del proyecto y los nombres de las personas que han participado en el proyecto a la que corresponden los derechos intelectuales del mismo junto el anagrama de la Universidad. 206

225 APÉNDICE A. MANUAL DE USUARIO Su funcionamiento es muy simple, se marca la/s ventana/s que se quieren visualizar y al pulsar Aceptar se lanzan. Al pulsar Cancelar finaliza la ejecución de la extensión. A.5.3. Consultas SQL Figura A.41: Consulta SQL Resultado: mostraría la respuesta de la consulta SQL, mensajes de error, si es muy larga la respuesta es recomendable activar la opción Crear Tabla Informe. Consulta SQL: aquí es donde se escribía la consulta SQL aprovechando la potencia que esto tiene. Al ser de consulta no permite ejecutar por seguridad sentencias UPDATE, CREATE, UPDATE, ALTER, DROP por lo que no permite modificar tablas o crear tablas, alterarlas borrarlas, en definitiva solo sentencias SELECT. Crear Capa en GvSig: Si la consulta SQL tiene geometrías y está activa esta opción y se ha arrancado la aplicación desde el gvsig permite interpretarlo sobre el mapa generando una Capa o layer y añadiéndolo al ToC de gvsig. Ver página

226 A.5. UTILIZACIÓN 208 Crear Tabla informe: Interpreta la consulta como una tabla y muestra el resultado de forma más legible pudiéndolo exportar como PDF. Ver la página 222 para ampliar esta información. Configurar: Lanza la ventana de Configurar para ajustar los parámetros de conexión a la Base de Datos. Aceptar: Ejecuta la Consulta y guardar las opciones Crear Capa en gvsig y Crear tabla informe actualizando el fichero properties (mirar página 109 ampliar la información). Cancelar: Cierra la ventana. A.5.4. Configurar Figura A.42: Configurar Configurar Base de datos: Permite configurar los parámetros necesarios para acceder a una base de datos, la información contenida es la siguiente: Host: determina donde está la base de datos normalmente es en la propia máquina por lo que es localhost = a no ser que la base de datos sea distribuida entonces sería la IP 2 que de la máquina donde se encuentra la base de datos. 2 IP: Internet Protocol 208

227 APÉNDICE A. MANUAL DE USUARIO Usuario: login del propietario y/o usuario con permisos para acceder a la base de datos. Password: clave correspondiente al Usuario antes mencionado. Añadir que esta clave se mantiene cifrada por lo que no habría problemas en ese sentido de seguridad. BD: nombre de la Base de Datos que contiene las tablas con geometrías. Puerto: dirección del puerto asignado a la base de datos desde la que acceder. Opciones: Permite configurar otros parámetros relativos a diferentes aspectos de la aplicación. Unidad Informe: la magnitud empleada para redactar los informes. El OGC define la magnitud en el Sistema Internacional (S.I.) en metros, no obstante para medir grandes distancias es muy típico emplear Kilómetros de ahí la utilidad de esta opción. Formato: Permite elegir el formato de hoja para el informe en que sentido estará la hoja. Tolerancia: Es la distancia en metros permitida de separación entre un punto y una carretera para considerar esa conexa. Corte: Es la medida proporcional a la distancia entre dos paradas si suponemos que la separación es de 100 Km. según el porcentaje elegido en el regulador ocuparía la siguiente amplitud de radio el óvalo en Kilómetros: 0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 80 % 90 % 100 % Si es un porcentaje intermedio se calcula linealmente entre esos porcentajes. Fijarse que cuando se encuentra en el 50 % (que viene por defecto) se corresponde con el diámetro en anchura. Ver el apartado de funcionamiento para más información en la página

228 A.5. UTILIZACIÓN 210 SRID: JTS soporta el sistema de referencia de la sencilla manera que se propone en el SFS. Cada geometría tendrá su ID del Sistema de Referencia Espacial representado mediante un entero y proporciona métodos para manejarlo. Aceptar: Guarda la configuración actualizando el fichero properties (mirar página 109 ampliar la información) y sale de la ventana de Configuración. Cancelar: Sale de la ventana sin guardar los cambios posibles realizados. A.5.5. Crear Red Figura A.43: Crear red Nombre: El nombre de la red que se desea crear. Se puede dejar en blanco y genera un nombre automático de la forma nueva red XX siendo XX un número correlativo. Si tiene espacios en blanco los transforma en barra baja y si tiene Mayúsculas las transforma a minúsculas por limitaciones del PostgreSQL. Descripción: Texto arbitrario que se quiera guardar para reconocer la red. Este campo es opcional pero si se deja en blanco generará la fecha de creación del estilo [Día de la semana] [Fecha] [Hora]. Aceptar: Al aceptar agrega esta red a un índice de redes almacenando. Al ejecutar este botón crea si no existe la tabla index y agrega la información 210

229 APÉNDICE A. MANUAL DE USUARIO Nombre y Descripción y una nueva tabla llamada de la misma forma que nombre de contenido vacía (mirar página 110 para ampliar la información). Cancelar: Cierra la ventana sin efectuar ninguna creación. A.5.6. Listar Redes Figura A.44: Menú listar redes Tabla de redes: Muestra la información de las redes creadas, dispone de tres columnas: uso: Si tiene una marca -X- indica la cuál es la red cargada que está activa. Si no tiene ninguna una marca es que están todas inactivas. Si se sale de la aplicación establece todas a inactivas. red: Nombre de la red al crear una red. descripción: Información adicional añadida al crear una red. Nueva: Lanza la ventana de creación de una red, ver página

230 A.5. UTILIZACIÓN 212 Cargar: Recupera la información de la Base de Datos. Borrar: Permite borrar una o varias redes seleccionadas las elimina de las tablas que indexan y la tabla que contiene la información. Salir: Cierra la ventana manteniendo la Red cargada en memoria. A.5.7. Añadir Arcos Figura A.45: Añadir arcos Tabla de líneas: Es el nombre de la tabla origen que contiene LineString o MultiLineString en la lista que se despliega se puede visualizar todas las tablas (previa configuración) pero no verifica que realmente se corresponda. Columna líneas: Nombre de la columna que identifica los nombres de las línea (se usan para los informes). Columna Geom: Nombre de la columna que contiene las geometrías de líneas en formato OGC. 212

231 APÉNDICE A. MANUAL DE USUARIO Coste: Por defecto viene que es la longitud de la línea. En posteriores versiones podría calcularse en función del tiempo por lo que ese coste estaría ponderado por la velocidad. Aceptar: Al ejecutar este botón actualiza el fichero properties (mirar página 109 ampliar la información). Cancelar: Sale de la ventana sin guardar la configuración. A.5.8. Añadir Nodos Figura A.46: Añadir nodos Tabla de puntos: Es el nombre de la tabla origen que contiene Points. En la lista que se despliega se puede visualizar todas las tablas (previa configuración) pero NO verifica que realmente se corresponda. Columna puntos: Nombre de la columna que identifica los nombres de las línea (se usan para los informes). Columna Geom: Nombre de la columna que contiene las geometrías de Puntos en formato OGC. 213

232 A.5. UTILIZACIÓN 214 Coste: Por defecto viene que es la longitud de la línea. En posteriores versiones podría calcularse en función del tiempo por lo que ese coste estaría ponderado por la velocidad. Aceptar: Al ejecutar este botón actualiza el fichero properties (mirar página 109 ampliar la información). Cancelar: Sale de la ventana sin guardar la configuración. A.5.9. Trocear Grafo Figura A.47: Menú trocear Grafo Ventana de Estado: Muestra información sobre el proceso de troceado para ver como funciona mirar la página 124. En la primera línea muestra información acerca la tolerancia permisible de error que se puede configurar (página 208) una vez que comienza el proceso. En tiempo de ejecución va informando el estado en el que se encuentra. Una vez completado una fase del proceso muestra [OK] si todo ha salido bien o [ERROR] si ese proceso ha sido anómalo (por ejemplo la posible caída de la BD a mitad de proceso). 214

233 APÉNDICE A. MANUAL DE USUARIO Limpiar <nombre red>: Si esta opción ha sido marcada significa que antes del proceso haga una limpieza del posible contenido que pudiera haber anteriormente. El <nombre red> nos vale para evitar cometer errores. Guardar en BD: Si esta opción esta marcada (muy recomendable) es para salvar el proceso de troceado y no tenerlo que repetir cada vez que se pretenda usar esa configuración. Si no se marca esta opción el proceso es idéntico solo que gana en velocidad debido a que son datos temporales. NOTAS ADICIONALES: Aunque no se marque sigue siendo preciso usar la BD para pintar el resultado sobre gvsig. Trocear: lanza el evento de comenzar el troceado, tenga paciencia, es un proceso largo dependiendo del número de geometrías. Actualiza el fichero properties (mirar la página 109 para ampliar la información) con las opciones seleccionadas. Cancelar: Cierra la ventana actual. No se recomienda cerrar la ventana mientras se ejecuta el proceso. A Paradas Figura A.48: Menú paradas 215

234 A.5. UTILIZACIÓN 216 Tabla paradas: Muestra el orden estricto de las paradas a recorrer y el nombre que identifica dicha parada. Si se ejecuta sobre gvsig lo representa sobre el mapa con esta simbología: Bandera Verde: Parada inicial desde la que se parte. Chincheta: misma manera. Parada intermedia, importa el orden pero se marcan de la Bandera Roja: Parada final de todas las rutas. Subir/Bajar: Permiten cambiar el orden establecido de las paradas seleccionando una o varias paradas de la tabla de paradas y pulsando el botón. Actualiza la tabla paradas comprendidas en la Base de Datos, para ver cómo está implementado consultar la página 110. Añadir: Lanza la ventana para añadir paradas. Ver página 216. Borrar: Permite borrar una o varias paradas seleccionadas en la Tabla de paradas. Actualiza la tabla de paradas de la Base de Datos para ver como está implementado consultar la página 110. Refrescar: Actualiza la lista en caso de ser necesario de forma manual. Por defecto los cambios hechos deberían refrescarse de forma automática pero en caso de errores anómalos pudiera ser necesario. Salir: Cierra la ventana. A Añadir Paradas Figura A.49: Añadir paradas 216

235 APÉNDICE A. MANUAL DE USUARIO En la lista desplegable se muestra las posibles paradas para ir agregándolas al itinerario de de paradas de la ruta. Añadir: Agrega la parada a la lista de paradas. Cancelar: Cierra la ventana sin realizar ningún cambio. A Calcular Ruta Figura A.50: Calculador de ruta Es el motor donde se resuelven los grafos y a la vez simplifica las tareas integrándose modo barra con el gvsig. 217

236 A.5. UTILIZACIÓN 218 Se pueden distinguir las siguientes botones: Algoritmo: A*, IDA*, Dijkstra, Uniform Cost, Greedy search, Hill climbing (1, 2), Beam search (1-5), Depth first, Breadth first: son los diferentes algoritmos implementados para resolver grafos. Para ver como funciona cada algoritmo y en qué se diferencian mirar la página 87. Paso: ejecuta una única iteración del algoritmo. Ejecutar: hace una secuencia de pasos a la velocidad determinada por el Regulador de Velocidad hasta que finaliza el algoritmo (bien sea porque finalizó satisfactoriamente o porque no pudo). Si esta resolviendo una Ruta sería en la página 136, se puede ver cómo actuaría y crea un informe de ruta (página 222) y capas sobre gvsig (página 224). Regulador de Velocidad por defecto está al máximo. Lo que hace reduciendolo el regulador hacia Lento es añadir retardos entre los pasos, útil para poder visualizar de forma visual y didáctica las diferentes búsquedas de la ruta. Reiniciar: vuelve al grafo a su estado origen y dependiendo del modo en el que esté y restablece los contadores de estadísticas. Botones de Barra: Proporcionan un acceso directo a las utilidades integradas en la extensión facilitando la dinámica de pantallas. Grafo de Ruta: Carga el grafo previamente troceado y seleccionado para ser resuelto. Si no esta cargado presenta al usuario la ventana de Listar Redes. Comparador: Consultar la página 225. Capa Nodos: Consultar la página 213. Capa Arcos: Consultar la página 212. Listar Redes: Consultar la página 211. Paradas: Consultar la página 215. Crear Red: Consultar la página

237 APÉNDICE A. MANUAL DE USUARIO Trocear Red: Consultar la página 214. Estadísticas: Consultar la página 229. Configurar: Consultar la página 208. Asistente: Consultar la página 238. Memoria: Lanza esta memoria en formato pdf con el programa asociado a dicha extensión. Estado del grafo: Muestra información sobre qué parada esta ejecutándose, o si esta modo comparador, modo grafo ejemplo... se visualiza sólo mientras se esta ejecutándola a la vez que se mueve la barra. Ver Grafo: Si esta marcado se visualiza el panel entero, si esta desmarcado se convierte en modo barra desactivando la visualización del grafo se mejora mucho en rendimiento. Panel del grafo: Se puede jugar con el grafo puesto que implementa un sistema drag-and-drop pudiendo desplazar los nodos, y con el botón secundario del ratón poder suprimir links, añadir nuevos nodos tal y como se efectúan las operaciones pero desde el menú desplegable. Operaciones: Añadir Nodo crea un nuevo nodo Añadir Arco crea un nuevo link entre el nodo seleccionado hasta el siguiente en el que se haga click. Borrar válido para tanto links como nodos con tal de que estén seleccionados se suprimen. La única diferencia es que si es un nodo suprime también los links que se relacionen. Fijar Destino Marca el nodo al que debe alcanzar la ruta. Grafo Ejemplo Proporciona un grafo con el que hacer pruebas. Nuevo Grafo Crea un grafo vacío en el que solo esta en Nodo origen. Control: Proporciona de izquierda a derecha, y de arriba-abajo estas funcionalidades: Zoom de acercamiento. 219

238 A.5. UTILIZACIÓN 220 Movimiento por el grafo hacia arriba. Zoom de alejamiento. Movimiento por el grafo hacia la izquierda. Movimiento por el grafo hacia abajo. Movimiento por el grafo hacia la derecha. Info Grafo: Da información acerca el nodo (Nombre y Heurística) o el link seleccionado como es el (Nombre o coordenadas en caso de Geometrías), el Coste del tramo (en metros). Se puede modificar estos valores del grafo introduciendo unos nuevos no siendo recomendado para geometrías (no afecta ese cambio a la Base de datos pero si sobre los algoritmos), y muy útil para modificar el grafo de ejemplo o crear nuevos grafos. Leyenda: Da información de qué representa cada color sobre el grafo. ROJO : Selección de nodo o arco en ese momento. AZUL : Nodo inicio. VERDE : Nodo destino. NARANJA : Ruta candidata de la Queue o COLA. AMARILLO: Ruta elegida como primera opción. Información de estado sobre el Grafo: en la parte inferior de la ventana cuando el menú principal esta desplegado. 220

239 APÉNDICE A. MANUAL DE USUARIO Figura A.51: Calculador de ruta en formato barra 221

240 A.5. UTILIZACIÓN 222 A Informe Figura A.52: Menú informe Existen dos tipos, de informe de Ruta (al acabar de resolver las rutas después de la ejecución modo ruta -ver página 217- o bien mediante el asistente -ver página 238-) y de Consulta SQL (ver página 207) ambas disponen de la misma interfaz de la que se puede distinguir las siguientes partes: Tabla informe: es una tabla dinámica que muestra la información de forma organizada en filas y columnas. Cabeceras columnas: muestra el nombre de la columna del campo, es variable según las consultas y la configuración. Permite modificar la anchura de dichas columnas y se refleja proporcionalmente al exportarlo a PDF. 222

241 APÉNDICE A. MANUAL DE USUARIO Guardar en PDF: Lanza la ventana para guardar -ver página 228- y después de asignar la ruta de localización traduce la tabla a formato PDF ajustándolo a la hoja. Es configurable el formato Horizontal/Vertical y las Unidades en caso de informe de ruta Metros/Kilómetros en Configuración (Consultar la página 208). Salir: Cierra la ventana de informe. NOTAS ADICIONALES: En caso de Informe de ruta se organiza por orden de paradas, mostrando el orden correlativo de la traza, desglosando la ruta total en rutas parciales SUBTOTAL y al final de toda una fila TOTAL de la forma que se visualiza en la imagen de ejemplo. ORDEN PARADA RUTA KILOMETROS 1 1 A Coruña 2,732 km. 2 N-550 3,702 km. 3 N-VI 24,044 km. 4 A-9 9,681 km. 5 Betanzos 2,819 km. 6 A-6 36,244 km. 7 Guitiriz 1,321 km. 8 N-634 9,854 km. 9 Begonte 0,704 km. 10 Rábade 1,523 km. 11 Outeiro de Rei 2,335 km Lugo 2,187 km. ############## SUBTOTAL ### A Coruña => Lugo 97,145 km Lugo 2,187 km. 14 N ,421 km. 15 LU-612 2,228 km. 16 LU-232 1,069 km. 17 Guntín 1,813 km. 18 N ,867 km. 19 C ,992 km. 20 AC-VP ,395 km Arzúa 0,160 km. ############## SUBTOTAL ### Lugo => Arzúa 63,130 km. T O T A L ===== ============= A Coruña => Lugo => Arzúa 160,275 km. Figura A.53: Menú informe exportado a PDF 223

242 A.5. UTILIZACIÓN 224 A Capa sobre gvsig Crea capas sobre la tabla de contenidos a partir de ahora llamada ToC que se encuentra en la parte izquierda de la ventana. En el ToC se enumeran todas las capas que contiene y los símbolos empleados para la representación de los elementos que componen la capa. Ver imagen: Figura A.54: Capas añadidas en el ToC sobre de gvsig 224

243 APÉNDICE A. MANUAL DE USUARIO A Comparador Algoritmos Figura A.55: Comparador Dispone de las siguientes funcionalidades: En el apartado de los algoritmos se pueden seleccionar aquellos que queremos comparar marcándolo simplemente con su casilla correspondiente. Deseleccionar: Desmarca todos los algoritmos Casilla número de iteraciones: es el número de muestras que se tomaran por cada punto calculando la media de estas. Casilla Desde: Con qué cantidad de nodos empieza a generar los grafos. Casilla Hasta: Con qué cantidad de nodos finalizará la comparativa. Salto: Las muestras de nodos con cuántos nodos difieren, si es continuo con poner 1 serían nodos correlativos. 225

244 A.5. UTILIZACIÓN 226 Densidad de enlaces: La generación de enlaces viene dado en proporcional al número de nodos generados. El 100 % de densidad significa un grafo completo (ver la página 33 para más información), es decir, todos los nodos están unidos directamente entre sí. el 0 % significa que no hay ninguna unión por lo que todos los grafos generados serían disconexos. Un porcentaje intermedio es proporcional al número de links posibles para ser un grafo completo. Usar Generador aleatorio: se puede hacer desmarcando esta opción poder resolver el mismo grafo que nosotros queramos sin el generador. Iniciar/Parar: Empieza la ejecución o parada de la comparativa. En ese momento se podrá visualizar sobre la pantalla el tanto por cierto que lleva completado. Al ejecutar este botón actualiza el fichero properties (mirar página 109 ampliar la información). Salir: Sale del menú del Comparador, aunque prosigue la ejecución si estaba ejecutándose por lo que debe ser parado explícitamente. Para más información consultar las páginas (proceso de comparación) 146 y (resultados obtenidos)

245 APÉNDICE A. MANUAL DE USUARIO A Mensajes Figura A.56: Tipos de mensajes MENSAJE ÉXITO: Es una ventana para informar al usuario que todo fue realizado según los planes incluso información adicional. Se utiliza por ejemplo cuando se resuelven todas las paradas correctamente. MENSAJE ERROR: Es una ventana de información para advertir al usuario que se produjo algún suceso no esperado, como podría ser el cierre de conexión el con la Base de datos. En modo debugger puede proporcionar información acerca el trazado del fallo. MENSAJE ALERTA: Informa que se ha detectado un error pero que puede ser solucionado y en el mensaje hay alguna información por lo que sucede. Por 227

246 A.5. UTILIZACIÓN 228 ejemplo resolver una ruta donde hay sólo una parada y debe haber mínimo dos o más. MENSAJE AYUDA: Detecta una situación y proporciona información al usuario. Por ejemplo después de crear una red (sin el asistente) lanza el Troceador porque detecta que posiblemente será el paso siguiente y avisa al usuario de esta situación. Aceptar: Cierra la ventana del mensaje. A Guardar PDF Figura A.57: Guardar PDF Subir nivel: Sube al directorio padre con respecto al actual. Escritorio: Va al directorio del escritorio. Crear carpeta nueva: Crea un directorio vacío. Lista: Ve los ficheros existentes en formato de lista. Detalles: Muestra más información sobre los ficheros como es Tamaño, Tipo, Atributos, Fecha de modificación. 228

247 APÉNDICE A. MANUAL DE USUARIO Guardar en: Directorio donde se almacenará. Barra de desplazamiento: Para visualizar el resto de los ficheros. Nombre de archivo: Nombre de fichero que tendrá Guardar: Ejecuta la orden de guardar. Cancelar: Cierra la ventana actual. A Estadísticas Para todos los menús de estadísticas tienen estas opciones posibles. Zoom acercamiento/alejamiento: seleccionando una parte del gráfico amplia esa zona. Click izquierdo sobre el gráfico: se despliega un menú Figura A.58: Menú JFreeChart Propiedades: Permite personalizar el gráfico, colores, tipos de letra, etc. Grabar como: Lanza la ventana de Guardar para guardar la ventana en formato imagen png. Imprimir: Saca el resultado a una impresora. Acercar: Aleja el zoom de la gráfica. Alejar: Acerca el zoom de la gráfica. 229

248 A.5. UTILIZACIÓN 230 Escala Automática: Ajusta la pantalla a las dimensiones óptimas de la gráfica. Guardar PDF: Ejecuta el menú guardar -ver página 228- para salvar el gráfico que se está visualizando en formato vectorial. Cancelar: Cierra la ventana. A Estadísticas comparación Figura A.59: Comparador tiempos Esta gráfica muestra la información de tiempo en segundos en el eje vertical y el número de nodos en el horizontal. Se puede ver en la leyenda el código de colores de algoritmos. 230

249 APÉNDICE A. MANUAL DE USUARIO Figura A.60: Comparador pasos Esta gráfica compara el número de pasos medio para encontrar una solución en relación con número de nodos. 231

250 A.5. UTILIZACIÓN 232 Figura A.61: Comparador éxitos El porcentaje de éxitos pretende representar y diferenciar los casos que existiendo solución, si un algoritmo no es completo, puede llegar a la conclusión errónea de que no existe. Si no encuentra solución asume por defecto coste = 0 (aunque técnicamente debería ser infinito ) pero sería inviable representarlo sobre el gráfico por lo que si solo se compara el coste, podría dar a resultados absurdos por contradicción como por ejemplo que Hill Climbing da menor coste que A*. 232

251 APÉNDICE A. MANUAL DE USUARIO Figura A.62: Comparador costes Este gráfico pretende comparar qué resultado devuelve menor coste, atendiendo al porcentaje de éxitos para que realmente sea comparable. En el eje vertical es el sumatorio de todos los costes individuales de todas las interacciones de ese algoritmos. Para ver detalles de implementación ir a la página

252 A.5. UTILIZACIÓN 234 Figura A.63: Consumo memoria Esta ventana pretendía usarse para hacer un estudio empírico-analítico comparando que memoria consumía cada algoritmo análogo al de tiempo. No fue posible puesto que las primeras intentos daban resultados distorsionados debido al recolector de basura de Java. Se dejo la ventana a modo de curiosidad para ver los movimientos de memoria Total y Libre de la aplicación. 234

253 APÉNDICE A. MANUAL DE USUARIO A Estadísticas ruta Después de la ejecución exitosa de rutas se puede ver información acerca del tiempo, el grafo utilizado y la distancia de las paradas. Figura A.64: Estadísticas ruta tiempos En el eje de horizontal se pueden ver las diferentes rutas entre paradas, mostrando en el eje vertical el tiempo en segundos analizando cuánto tardó en generar el grafo, cuánto en resolverlo y el total de esa ruta (generar+resolver). Las dos últimos grupos son la Media entre las diferentes rutas y el Total la suma de todos los tiempos desglosados. 235

254 A.5. UTILIZACIÓN 236 Figura A.65: Estadísticas ruta grafo Este gráfico pretende analizar la complejidad del grafo mostrando cuantos nodos se utilizaron y cuantas uniones fueron precisas. La columna de Pasos pretende ver a golpe de vista cuántas de estas uniones se tuvieron que recorrer hasta encontrar el camino. Por último añade los grupos Media y Total. 236

255 APÉNDICE A. MANUAL DE USUARIO Figura A.66: Estadísticas ruta distancia Este gráfico pretende representar la distancia de las diferentes rutas entre dos paradas pudiendo así comparar entre ellas. Además incorpora la Media y el Total de las distancias. 237

256 A.5. UTILIZACIÓN 238 A Asistente Con el fin de guiar al usuario inexperto a construir rutas sobre el mapa se ha realizado a mayores un asistente. Se hará una referencia a las ventanas que se correspondería puesto que su funcionamiento es análogo al explicado anteriormente en las ventanas individuales. Figura A.67: Asistente: Presentación Presentación del asistente. 238

257 APÉNDICE A. MANUAL DE USUARIO Figura A.68: Asistente: Configurar Equivale a la ventana Configurar correspondiente a la página 208. Figura A.69: Asistente: Añadir capa puntos Equivale a la ventana Añadir nodos correspondiente a la página

258 A.5. UTILIZACIÓN 240 Figura A.70: Asistente: Añadir capa líneas Equivale a la ventana Añadir arcos correspondiente a la página 212. Figura A.71: Asistente: Crear Red Equivale a la ventana Crear Red correspondiente a la página

259 APÉNDICE A. MANUAL DE USUARIO Figura A.72: Asistente: Paradas Equivale a la ventana Paradas correspondiente a la página 215. Figura A.73: Asistente: Listar Redes Equivale a la ventana Listar Redes correspondiente a la página

260 A.5. UTILIZACIÓN 242 Figura A.74: Asistente: Trocear Grafo Equivale a la ventana Trocear Grafo correspondiente a la página 214. Figura A.75: Asistente: Finalizar Es la finalización del asistente, cuando se ejecute empezará el Calculador de Rutas modo barra, cargando la red, y resolviéndolo automáticamente con el algoritmo A*. El usuario sólo debe esperar a que acabe el proceso, momento en que tendrá creado una capa sobre el ToC de gvsig (página 224) y un informe de ruta (página 222). 242