Servidor de mapas para publicación de rutas senderistas e interfaz web cliente

UNIVERSIDAD DE MÁLAGA ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA INGENIERO TÉCNICO EN INFORMÁTICA DE SISTEMAS SERVIDOR DE MAPAS PARA PUBLICACIÓN DE RUTAS SENDERISTAS E INTERFAZ WEB CLIENTE Realizado por JOSÉ ROLLAND LÓPEZ DE COCA Dirigido por SEBASTIÁN CASTILLO CARRIÓN JESÚS VÍAS MARTÍNEZ Director Académico JOSÉ DEL CAMPO ÁVILA Departamento LENGUAJE Y CIENCIAS DE LA COMPUTACIÓN MÁLAGA, Julio de 2011 A mi familia, a mis amigos y a todos los que me han ayudado a llegar hasta aquí. _______________________________________________________________________________________________________________________________________________________________ José Rolland López de Coca 1 Índice BLOQUE 1: INTRODUCCIÓN AL PROYECTO! ! 5 ..........................................................................................1!Introducción! !7 ..........................................................................2!Definición del proyecto! !9 !.....................................................................................................2.1!Descripción del proyecto! !9 ...............................................................................................................................!2.2!Entorno! !10 .....................................................................................................................!2.3!Vida esperada! !11 .......................................................................................................!2.4!Ciclo de mantenimiento! !12 ................................................................................................................................!2.5!Ámbito! !12 ....................................................................................................................!2.6!Aspecto visual ! !12 ..................................................................................................................!2.7!Estandarización! !13 .............................................................................................................!2.8!Calidad y fiabilidad! !13 .............................................................................................................!2.9 !Programa de tareas! !14 ...............................................................................................................................!2.10!Pruebas! !15 ............................................................................................................................!2.11!Seguridad! !15 ............................................................3!Antecedentes y estado del arte ! !16 .........................................................................................................................!3.1!Cartografía ! !16 ........................................................................!3.2!Sistemas de Información Geográfica (SIG) ! !19 ........................................................................!3.3!Infraestructuras de Datos Espaciales (IDE)! !20 ......................................................................................................................!3.4!Web mapping! !20 ...............................................................................................4!Objetivos! !21 ...............................................................................................................!4.1!Objetivo principal! !21 ...........................................................................................................!4.2!Objetivos específicos! !21 .........................................................................................5!Restricciones! !23 !......................................................................................................................5.1!Factores dato! !23 ...........................................................................................................!5.2!Factores estratégicos! !24 _______________________________________________________________________________________________________________________________________________________________ José Rolland López de Coca 2 .................................................................................................6 Recursos! !25 !...............................................................................................................6.1!Recursos humanos! !25 .............................................................................................................!6.2!Recursos materiales! !26 BLOQUE 2: ESPECIFICACIÓN Y ANÁLISIS DEL SISTEMA!27 .............................................7!Análisis de la especificación de requisitos! !29 !..............................................................................................................7.1!Tipos de requisitos! !30 .......................................................................................................................!7.2!Casos de uso! !33 ..................................................................................8!Análisis funcional! !43 !...........................................................................................8.1!Arquitectura lógica del sistema! !43 ....................................................................................................!8.2!Componentes del sistema! !44 ......................................................................!8.3!Descripción del comportamiento del sistema! !49 ...........................................9!Análisis de la estructura de la información! !60 ....................................................................................................................!9.1!Tipos de datos! !60 ..............................................................................................!9.2!Estructura de la información! !61 .......................................................................10!Análisis del interfaz web! !64 !...............................................................................................................10.1!Perfiles de usuario! !64 .......................................................!10.2!Consideraciones previas al diseño de la aplicación web! !65 BLOQUE 3: DISEÑO E IMPLEMENTACIÓN DEL SISTEMA!71 ............................................................................11!Instalación de la IDE! !73 !..........................................................................11.1!Instalación de componentes en el servidor! !73 .............................................................................................................!11.2!Datos geoespaciales! !73 .....................................................................................!11.3!Configuración de UMN MapServer! !74 ..................................................................12!Diseño de la aplicación web! !76 !......................................................................................................................12.1!Web modular! !76 ..................................................................................................................!12.2!Modelo de datos! !81 ......................................................................!12.3!Interacción entre la aplicación web y la IDE! !84 .....................................................................................................!12.4!Módulos de la aplicación! !86 ..............................................................................................!12.5!Gestión y control de usuarios! !94 ..............................................................13!Diseño del interfaz del usuario! !96 !..............................................................................................................13.1!Diseño del interfaz! !96 ........................................................................................................!13.2!Usabilidad del interfaz! !100 _______________________________________________________________________________________________________________________________________________________________ José Rolland López de Coca 3 BLOQUE 4: PRUEBAS! !103 ..................................................................................14!Pruebas unitarias! !105 ...............................................................................15!Pruebas funcionales! !107 BLOQUE 5: CONCLUSIONES! !109 ..........................................................................................16!Conclusiones! !111 !.........................................................................................16.1!Conclusiones sobre los objetivos! !111 ...........................................................................................!16.2!Conclusiones sobre las pruebas! !112 ..................................................................................!16.3!Conclusiones personales del proyecto! !112 ........................................................................................17!Líneas futuras! !113 ANEXO I: MANUAL DE INSTALACIÓN! !115 .........................................................................18!Instalación del servidor! !117 ....................................................................19!Instalación de la aplicación! !120 ANEXO II: MANUAL DE CÓDIGO! !131 .....................................................................................................Glosario! !139 ................................................................................................Bibliografía! !141 ........................................................................................Índice de figuras! !143 _______________________________________________________________________________________________________________________________________________________________ José Rolland López de Coca 4 BLOQUE 1: INTRODUCCIÓN AL PROYECTO CAPÍTULO ______________________________________________________________________________________ Introducción La información geográfica y el uso de herramientas y sistemas que permitan hacer uso de ella para extraer nueva información y ponerla a disposición de la sociedad es una tarea que engloba diferentes áreas de conocimiento, como la Geografía o la Informática. Desde el departamento de Geografía de la Universidad de Málaga se está trabajando en la creación de nuevos contenidos y en su difusión en el ámbito de diferentes proyectos de investigación, como son: • el proyecto de excelencia P07-HUM-03049: “Desarrollo metodológico sobre la evaluación de la capacidad para usos recreativos de espacios protegidos” financiado por la Consejería de Innovación, Ciencia y Empresa de la Junta de Andalucía. • el proyecto del Plan Nacional de Investigación SEJ2007-67690: “Desarrollo metodológico sobre la evaluación de la capacidad para usos recreativos de espacios protegidos” financiado por la Dirección General de Investigación del Ministerio de Ciencia e Innovación. Los anteriores proyectos pretenden desarrollar métodos de evaluación de la aptitud y de la capacidad de carga del territorio con relación al conjunto de las actividades recreativas ligadas a los caminos o senderos, que son las contempladas más frecuentemente en las figuras de planeamiento (Plan de ordenación de los recursos naturales y Plan de Uso Público) de estos espacios. Con esta perspectiva se aborda, entre otros objetivos, la evaluación de los caminos-senderos para el disfrute recreativo, con atención a sus caracteres intrínsecos, como soporte de las actividades y dando cabida a la valoración del entorno y el paisaje. Para ello proponen un sistema que combine técnicas multicriterio y los modelos de capacidad de acogida, configuradas como una aplicación en un Sistema de Información Geográfica (SIG), que no es más que un sistema que auna tanto capacidades de cálculo geográfico (el llamado procesamiento geográfico) como de manipulación gráfica y de imágenes, consulta y gestión de bases de datos. Esta aplicación será presentada a usuarios finales para poner a prueba el sistema, de forma que pueda servir de modelo para procesos de 1 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!7 ejecute la mayoría de funciones (JavaScript), aprovechando el poder de computación del dispositivo del cliente. • Que no se produzcan errores inesperados que bloqueen el sistema o la aplicación. La fiabilidad, por su parte, hace referencia a la capacidad de la aplicación para proporcionar siempre datos reales y correctos, es decir, asegurar su correcto y óptimo funcionamiento. En esta aplicación la fiabilidad es un punto fundamental, ya que las rutas que le ofrezcamos deben estar referenciadas geográficamente de la forma más exacta posible, y cuando las cargue en su GPS transcurran por senderos que existen y se adecuan a lo que pidió. 2.9 Programa de tareas El programa de tareas se define como las diferentes fases de desarrollo por las que pasa la aplicación, que se pueden resumir en los siguientes puntos: • Fase de preparación: reunir toda la información y adquirir la base teórica necesaria para poder afrontar la posterior realización del proyecto: ‣ Documentación sobre IDEs (Infraestructuras de Datos Espaciales), sobre SIGs (Sistemas de Información Geográfica), proyecciones cartográficas, sistemas de coordenadas y todo el software relacionado con una IDE. ‣ Documentación, estudio y elección del software y las tecnologías que se utilizarán para la realización de la aplicación web. • Fase de especificación de requisitos: el principal objetivo de esta etapa consiste en describir el comportamiento del sistema y los componentes que lo forman, de acuerdo a los requisitos solicitados por el cliente final. Para ello se analizarán las principales condiciones que debe reunir el sistema para que realice su función de manera correcta. ‣ Descripción detallada del proyecto: reunirá los objetivos, requisitos y restricciones presentes en la aplicación a desarrollar. Exponer de forma que se facilite su posterior validación. ‣ Especificación y diseño de la IDE. Estudio de las diferentes soluciones que existen y que mejor se adaptan a la IDE proyectada. • Fase de implementación: el objetivo será implementar el diseño especificado en la fase anterior, centrándose en las siguientes tareas: ‣ Instalación en un servidor de todo el software necesario para la IDE. Esto proporcionará la infraestructura necesaria para poder hacer pruebas durante el desarrollo de la aplicación web. ‣ Desarrollo de la aplicación web y la interfaz cliente para el cálculo de rutas. • Fase de pruebas: en esta fase se verificará el correcto funcionamiento del sistema, mediante unos casos de prueba que intentarán cubrir el máximo número de posibilidades. Se hacen pruebas de rendimiento del servidor y comparativas, y depuración en los casos necesarios. • Fase de documentación: organizar toda la información recopilada durante el desarrollo del proyecto en la presente memoria. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!14 2.10 Pruebas Este proyecto incluirá la realización de pruebas para comprobar su correcto funcionamiento. Dichas pruebas consistirán fundamentalmente en comprobaciones y correcciones durante la implementación del sistema, así como validación de los requisitos principales desarrollados (los casos de uso). Esta parte se describirá detalladamente en el bloque 4 dedicado a las pruebas de la aplicación. 2.11 Seguridad La seguridad es otro de los componentes esenciales de la aplicación web, que por su propia naturaleza está expuesta a ataques de toda índole a través de las redes. Hay algunos aspectos que dependen del servidor, como los ataques de denegación de servicios (DoS). Para dotar de seguridad a la aplicación se implementarán las siguientes directrices: • Los datos de acceso a la base de datos residirán en el servidor, y nunca se podrá acceder directamente a la base de datos desde un script en el navegador del usuario. Esto se traduce en que el código encargado de negociar con la base de datos será visible sólo por el servidor. • Las contraseñas de los usuarios serán guardadas en la base de datos de forma segura. • Los archivos pertenecientes a la IDE y a la aplicación a los que el usuario no necesita acceder directamente, estarán fuera del dominio del servidor. • Se otorgarán los permisos pertinentes en los directorios de la aplicación dentro del dominio web para que los usuarios no puedan acceder al árbol del directorio y ver qué archivos hay en él. • Se incluirán mecanismos para ocultar la ruta y el nombre de los archivos implicados en la aplicación web, sin afectar al funcionamiento ni al rendimiento de la misma. • Se implementará un control de usuarios, dado que habrá tres perfiles de usuario (administrador, usuario autenticado y usuario anónimo), para evitar por ejemplo que un usuario anónimo pueda acceder al panel del administrador. Con estos puntos se pretenderá dotar de seguridad y proteger a la aplicación web de posibles ataques maliciosos a través de Internet. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!15 CAPÍTULO ______________________________________________________________________________________ Antecedentes, estado del !arte En este capítulo se profundizará en los conceptos asociados a la tecnología de los Sistemas de Información Geográfica (SIG) y las Infraestructuras de Datos Espaciales (IDE) definidos en el capítulo de introducción, así como en toda la terminología relacionada con la cartografía, para poner en contexto el proyecto que se pretender realizar. 3.1 Cartografía La Cartografía se puede definir como el arte y la técnica que, con la ayuda de las ciencias geográficas tiene por objeto el levantamiento, la redacción y la publicación de un mapa. Es decir, es la ciencia encargada de la elaboración y estudio de mapas. Con el avance tecnológico del último siglo, concretamente en el área de la Informática, la Cartografía ha vivido una revolución a todos los niveles. La digitalización de mapas, visualización y análisis espacial por medio de ordenadores facilitó las actividades comunes de la Cartografía y amplió la capacidad de generación de información cartográfica. El objetivo final de la Cartografía consiste en representar en un plano una zona más o menos extensa, o la totalidad, de la superficie terrestre. Dado que la superficie de la Tierra es casi esférica, en concreto un geoide (está achatada por los polos, debido a la fuerzas de la gravedad y centrífuga), se hace imprescindible aplicar alguna transformación para lograr la representación en el plano. En este apartado se van a definir una serie de conceptos de Cartografía que están directamente relacionados con este proyecto [10]. 3 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!16 3.1.1 Proyecciones cartográficas La Cartografía estudia los sistemas de proyección más convenientes para definir de forma biunívoca una relación matemática entre los puntos de la superficie terrestre (considerada casi esférica, un geoide) y sus transformados en el plano. Son las llamadas proyecciones cartográficas. Por tanto, la proyección cartográfica (o proyección geográfica) es un sistema de representación gráfica que establece una relación ordenada entre los puntos de la superficie curva de la Tierra y los de una superficie plana (representada en un mapa). El proceso seguido hasta llegar a la representación plana de una porción de la superficie de la Tierra comienza con la toma de medidas en la superficie terrestre. A continuación se realizan una serie de correcciones para referir esas medidas al geoide que representa la Tierra, y sobre esos datos se vuelve a hacer correcciones para modelar los datos respecto a un elipsoide de referencia previamente adoptado (una aproximación del geoide terrestre más fácil de manejar y de realizar cálculos sobre él). Tras este proceso, se aplican las relaciones matemáticas definidas por el sistema de proyección elegido a los datos, y el resultado se proyecta en un plano. Todas las proyecciones cartográficas siempre producen alguna deformación en la superficie representada (es lo que se conoce como anamorfosis). Las proyecciones cartográficas se pueden clasificar en: • Proyecciones cilíndricas: se proyecta la superficie de la Tierra sobre un cilindro. Hay varios tipos de proyecciones cilíndricas, según la colocación del cilíndro tangente al globo terráqueo, como la cilíndrica regular (tangente en el Ecuador), o cilíndrica transversa (tangente al meridiano central). Dentro de esta última se encuentra la famosa proyección transversa de Mercator (1772), que tras sufrir algunos ajustes por parte de Gauss (1822) y Kruger (1912), ha dado origen al actual sistema de proyección UTM (Universal Transversal de Mercator). • Proyecciones cónicas: se proyecta sobre un cono tangente (o secante) a la Tierra alrededor de un paralelo (que suele estar situado en una latitud media). No son tan utilizadas como las cilíndricas, dado que la zona de precisión suele ser muy restringida, y las deformaciones fuera de ella son muy notables. Algunos ejemplos de proyecciones cónicas son la cónica simple, la conforme de Lambert, o la equiárea de Albers. • Proyecciones acimutales (o planares): se sitúa un plano tangente a la Tierra, y se proyecta respecto a un punto seleccionado que hace de fuente de luz que generará la proyección, ya sea en el interior de el Globo (gnomónica) o en el exterior (ortográfica). Figura 3.1. Proyección cilíndrica, cónica, y acimutal gnomónica. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!17 Para un sistema de proyección como UTM, se debe partir y acordar tres premisas: • Elección de un elipsoide de referencia: es el patrón matemático que interviene en la transformación de los datos en el plano. Algunos ejemplos son el elipsoide de Hayford, o el WGS84. • Elección de unos puntos de referencia del elipsoide (datum): un conjunto de parámetros usados para determinar la posición del elipsoide de referencia con respecto a la superficie real de la Tierra. Los datum clásicos están definidos por 8 parámetros: 6 que definen la posición en el espacio de un elipsoide de referencia y 2 para la forma o tamaño del mismo, fueron concebidos para ajustarse a una porción determinada de la Tierra. • Elección de un sistema de representación plano conforme: es decir, que conserva los ángulos. Para evitar grandes deformaciones se divide la superficie terrestre en 60 husos (secciones). Figura 3.2. Zonas (husos) UTM. 3.1.2 Sistemas de coordenadas Un sistema de coordenadas es un conjunto de valores que definen la posición de cualquier punto de un espacio vectorial. Existen varios sistemas coordenadas, como las cartesianas, las polares, o las esféricas. En cartografía se usan las coordenadas geográficas, que son un tipo de sistema de coordenadas esféricas que se usa para definir puntos sobre una parte o la totalidad de la superficie terrestre. El sistema más conocido es el que emplea la longitud y la latitud, cuyos valores se expresan en grados. Por otra parte, también se pueden definir dichas coordenadas mediante proyecciones cartográficas: por ejemplo, el sistema de coordenadas Universal Transversal de Mercator (UTM), una de las más utilizadas. Estas coordenadas cartesianas (x,y), expresadas en metros, hacen referencia al plano transformado, resultado de la proyección del elipsoide de referencia (cuyas coordenadas son geográficas, longitud y latitud). _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!18 3.1.3 Escalas Los mapas, para ser manejables por seres humanos, son más pequeños que las áreas que representan, y por tanto debe haber una forma de señalar la razón entre magnitudes (la representada y la real). Esta razón se llama escala numérica del mapa, que se indica en el mapa mediante una relación numérica. Por ejemplo, una escala 1:5000 indica que 1 cm del mapa equivale a 50 m en la realidad. La escala numérica será completamente válida sólo en ciertos puntos o a lo largo de determinadas líneas (llamadas automecoicas), en el resto será un valor aproximado. El factor de escala se define como el cociente entre la escala numérica y el valor real de la escala. 3.1.4 European Petroleum Survey Group (EPSG) En el ámbito de los Sistemas de Información Geográfica existe desde hace tiempo y de forma normalizada (en concreto con la norma ISO 1911) una base de datos que ha codificado en una serie parámetros geodésicos, que definen un sistema de referencia concreto (definido por un código numérico) para su uso informático, datos de sistemas de proyección, sistema de coordenadas, elipsoides, datums y otros datos relacionados con la Cartografía. De esta forma, queda expresado en un sólo número, de manera unívoca y universal, toda la información relativa al sistema de referencia en el que esté representado un conjunto de datos geoespaciales. Por ejemplo, el código EPSG:25830 hace referencia al sistema con el datum ETRS89, sistema de coordenadas UTM y huso 30 Norte. El European Petroleum Survey Group (EPSG) fue el impulsor de este modelo, y desde 2005 la OGP (International Association of Oil and Gas Producers) se encarga de mantener actualizada la base de datos, en colaboración con el consorcio OGC [11]. 3.2 Sistemas de Información Geográfica (SIG) Un Sistema de Información Geográfica (SIG) se puede definir como el conjunto integrado de hardware, software y datos geográficos diseñado con objeto de visualizar, almacenar, editar y analizar información geográfica espacial referenciada con la finalidad de afrontar y resolver problemas de gestión, descripción, ordenación y planificación del territorio. En un sentido más genérico, los SIG son herramientas que permiten a los usuarios realizar consultas geográficas de forma interactiva, analizar la información espacial, manipular datos y mapas y presentar los resultados de todas estas operaciones. Los Sistemas de Información Geográfica se han convertido de una herramienta muy difundida, debido a la cantidad y variedad de actividades en las que pueden tomar parte y ser de utilidad, que se pueden clasificar en los siguientes grupos [2, 3]: • Gestión y descripción del territorio: trata de referenciar geográficamente la ubicación física de los objetos de estudio, útil por ejemplo para el mantenimiento y control de grandes infraestructuras (red hidrográfica, red telefónica, etc.), la gestión de datos catastrales o la gestión municipal. • Ordenación y planificación del territorio: trata de estudiar e inferir estrategias que lleguen a describir dónde hay que ubicar los objetos de estudio de acuerdo a unos objetivos. Por ejemplo, la planificación urbana y ambiental, o el análisis y puesta en marcha de políticas relacionadas con el transporte (flujo de tráfico, cálculo de rutas óptimas). _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!19 Los datos geoespaciales que puede manejar un SIG se dividen en dos tipos: • Datos raster: son imágenes digitales, dividas normalmente en celdas regulares organizadas, y se suelen utilizar para representar fotografías aéreas o gráficos representativos del terreno (mapas topográficos, por ejemplo). • Datos vectoriales: los datos están representados como vectores o puntos con un determinado conjunto de valores, de forma que sobre ellos se podrán realizar operaciones matemáticas complejas. 3.3 Infraestructuras de Datos Espaciales (IDE) En el capítulo de introducción se definió qué era una IDE y se comentó un punto importante: la interoperabildiad con otras IDEs. Los objetivos que se buscan con la implantación de las IDEs son principalmente facilitar el acceso a todos los niveles (organizaciones estatales, empresas, particulares) y la integración de la información espacial, que permitirá generalizar el uso de la información geográfica y planificar de forma óptima determinadas actividades que involucren características geográficas, o de localización. Los avances tecnológicos y la cotidianidad del componente geoespacial en multitud de actividades, han multiplicado el volumen de información geográfica. Las IDEs pretenden organizar, catalogar y poner al alcance de todo el mundo esta información, y dotarla de la máxima utilidad. En España existe una organización estatal (el Consejo Superior Geográfico) que está llevando a cabo un proyecto (llamado IDEE, Infraestructura de Datos Espaciales de España) coordinado con el resto de países europeos, para integrar ordenadamente y siguiendo unas normas estándar toda la información espacial recopilada del territorio nacional, integrando nodos IDE locales y regionales para construir una gran red IDE nacional [4]. 3.4 Web Mapping El auge de Internet ha alcanzado al ámbito de los Sistemas de Información Geográfica, que se han adaptado para ofrecer aplicaciones con objeto de visualizar y editar información geográfica en entornos web, como por ejemplo Google Maps, OpenStreetMap o Bing Maps. Estas aplicaciones proveen servicios en forma de mapas interactivos, con algunas funciones de enrutamiento. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!20 CAPÍTULO ______________________________________________________________________________________ Objetivos Tras haber descrito el proyecto y todo su entorno en el capítulo anterior, a continuación se exponen los objetivos del mismo. 4.1 Objetivo principal El objetivo principal del proyecto es proporcionar al usuario, mediante el uso de una aplicación web, la ruta más afín a sus preferencias dentro de las posibilidades contempladas en la Infraestructura de Datos Espaciales (IDE) que se utilizará. Más concretamente, la herramienta deberá recoger diferentes características (capacidades físicas, intereses, etc.) del usuario y emplearlas para ofrecer las rutas que le sean más apropiadas. Para ello utilizará diversos métodos de búsqueda (camino más corto, optimización multicriterio, etc) que ya están disponibles en la IDE. 4.2 Objetivos específicos Los objetivos específicos que se pretenden alcanzar con el desarrollo de dicho proyecto: • Diseñar e instalar una Infraestructura de Datos Espaciales (IDE) que gestione datos de rutas o recorridos para senderismo a partir de la cartografía de la Junta de Andalucía. • Especificación, diseño y desarrollo de una aplicación web que presente los datos más apropiados para un usuario según su aptitud. Para ello: 4 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!21 ‣ El sistema recogerá los datos necesarios del usuario y los integrará con parámetros calculados y otros posibles criterios específicos ‣ Consultará en la IDE cuáles son las rutas más apropiadas. Ese cálculo se realizará mediante métodos de búsqueda ya disponibles en la IDE. ‣ Devolverá y mostrará dichas rutas de forma que sean útiles al usuario. • Se gestionarán los usuarios que hagan uso del sistema para poder realizar tareas más avanzadas que complementen la búsqueda de rutas de forma anónima (controlar rutas ya realizadas, recuperar información sobre capacidades físicas del usuario, etc.). Se permitirá el acceso a usuarios no registrados, pero al no haber perfil no se guardarán las rutas consultadas. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!22 CAPÍTULO ______________________________________________________________________________________ Restricciones En este capítulo se pondrán de relieve las restricciones o limitaciones que afectan al desarrollo del proyecto, y que consecuentemente influirán en la toma de decisiones. Los factores restrictivos se pueden clasificar en dos grupos: • Factores dato: son aquellos que sobrevienen de forma ajena al desarrollador de la aplicación software, y que deben cumplirse sin posibilidad de ser modificados. • Factores estratégicos: son aquellas decisiones iniciales tenidas en cuenta únicamente por parte del desarrollador, y que por tanto no vienen impuestas externamente. 5.1 Factores dato En el desarrollo del presente proyecto se identifican los siguientes factores dato: • Debido a que la aplicación se encuentra relacionada directamente con otro proyecto, deberá adaptarse para dar cabida a ese otro proyecto (algoritmo de búsqueda multicriterio). • Los datos proporcionados se limitarán a la zona del Parque Natural de la Sierra de las Nieves. • Los recursos software usados durante el desarrollo del proyecto deberán ser libres y gratuitos, dada la libertad de uso y redistribución, por el soporte y compatibilidad a largo plazo, o por el uso de formatos estándar que proporciona el software libre, y por el que muchas administraciones están apostando. En caso de necesitar el uso de software propietario, se intentará utilizar los que disponga el autor del proyecto o los que suministre el Departamento de Lenguajes y Ciencias de la Computación de la Universidad de Málaga. 5 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!23 Los objetivos ya comentados son crear un nodo IDE y una aplicación web de cálculo de rutas que se conectará a ese nodo cada vez que manipulen datos geoespaciales. Las actividades relativas a la especificación de requisitos suelen pasar por cinco fases: • Obtención de requisitos: charlas o entrevistas con el cliente, para conocer sus peticiones. • Análisis: transformar los deseos del cliente en condiciones apropiadas para ser tratados por el diseño. • Documentación: los requisitos deben ser documentados. • Verificación: comprobar el correcto funcionamiento de un requisito en la aplicación. • Validación: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía. La especificación de requisitos software aspira a describir el comportamiento del sistema que se va a desarrollar, y vamos diferenciar entre los siguientes tipos de requisitos: • Requisitos funcionales: definen el comportamiento interno del software, manipulación de datos y otras funcionalidades que describen las interacciones que tendrán los usuarios con el software (los casos de uso). • Requisitos no funcionales: son los que juzgan e imponen restricciones al diseño o implementación del sistema (como por ejemplo los estándares de calidad, estabilidad, eficiencia, portabilidad o coste). • Usabilidad: es un aspecto que ha ido cogiendo fuerza en los últimos tiempos, y se ha extendido su definición más allá de relacionarlo con la interfaz gráfica. Tradicionalmente la usabilidad ha sido vista como un requisito no funcional, pero recientemente se ha considerado el impacto que tiene en la funcionalidad del sistema, así que dado ese carácter dual será tratada por separado en un nuevo apartado. Además, para facilitar la tarea se van a estudiar los casos de uso del comportamiento del sistema, tal y como se expone a continuación. 7.1 Tipos de requisitos 7.1.1 Requisitos funcionales Tal y como se acaba de comentar, los requisitos funcionales describen cómo debe actuar el sistema. Los diagramas de casos de uso del Lenguaje de Modelado Unificado (UML) son precisamente diagramas de comportamiento del sistema al afrontar un requisito, sin especificar cómo se implementará (es decir, explica qué hace, no cómo lo hace), y nos ayudarán en la tarea de describir los requisitos funcionales [12]. 7.1.2 Requisitos no funcionales Los requisitos no funcionales añaden ciertas propiedades adicionales a la solución (a veces se dice que estos requisitos provienen del mundo real, fuera del mundo virtual que genera el ordenador), independientes del _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!30 correcto funcionamiento de la aplicación. No describen funciones específicas ni información a manipular por parte del sistema, sino características que analicen y juzguen cómo opera el sistema. A continuación se describen los principales requisitos no funcionales de la aplicación: • Eficiencia y rapidez: el sistema debe ser eficiente, consumir los mínimos recursos posibles, y responder a las peticiones del usuario de la forma más rápida posible, para una mayor agilidad en la comunicación entre usuario y sistema informático. • Fiabilidad y disponibilidad: el sistema también debe ser robusto e interactuar con el usuario de la forma más rápida pero estable posible. Además, siempre deberá estar disponible de cara al usuario. • Tolerancia a fallos: el sistema debe responder frente a posibles errores por parte suya o del usuario, y recuperarse continuando el flujo de ejecución. • Estándares: el sistema cumplirá con todos los estándares relativos a su ámbito, para asegurar la calidad. • Portabilidad: el sistema deberá poder adaptarse a nuevos entornos y circunstancias. Por ejemplo, el uso de direcciones URL relativas dentro del código facilita pasar de un dominio web a otro sin tener que modificar el código fuente. • Seguridad: el sistema deberá ser mínimamente seguro, y salvaguardar la información sensible. • Mantenimiento: el sistema deberá ser fácil de mantener, para poder ser actualizado en el futuro. • Coste: no se podrá sobrepasar el presupuesto destinado al proyecto. 7.1.3 Usabilidad La usabilidad se define formalmente como la eficacia, eficiencia y satisfacción con la que un producto permite alcanzar objetivos específicos a usuarios concretos utilizando un determinado sistema (ISO 9241, 1998). En un sistema interactivo la usabilidad se presenta como la característica esencial del interfaz entre usuario y máquina para que aquél lo use de la forma más rápida y fácil, y hay que tenerla en cuenta desde el principio, en las primeras fases de desarrollo de una aplicación software. Tal importancia ha adquirido la usabilidad que se habla de una Ingeniería de Usabilidad, una práctica que agrupa todas las técnicas necesarias referentes a leyes de usabilidad, heurísticas y desarrollo de pruebas de usabilidad. La definición anterior puede resultar muy teórica, así que algunos autores han añadido a esa definición algunos indicadores de usabilidad más concretos que ayuden a evaluar el interfaz, destacando los siguientes: • Eficiencia: es deseable que el sistema sea lo más eficiente posible, y así pueda repercutir en una mayor productividad por parte del usuario. • Facilidad para memorizar el interfaz (memorability): un interfaz fácil de manejar y sencillo de recordar por parte del usuario mejora la usabilidad del sistema, permitiendo al usuario utilizarlo con mayor agilidad, incluso después de un tiempo sin haberlo usado. • Facilidad para aprender a usar el sistema (learnability): lograr que el usuario aprenda a usar el sistema de forma fácil y rápida, y pueda comenzar a usarlo lo antes posible, aumenta la usabilidad. • Satisfacción: un sistema usable debe proporcionar a los usuarios un grado de satisfacción alto. • Ausencia de errores: evitar algunos errores del usuario es tarea imposible (como por ejemplo introducir mal la contraseña), pero la usabilidad del sistema aumentará si se pueden evitar incluir acciones en la interfaz que puedan provocar errores. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!31 Para un sitio web es importante tener en cuenta estos otros puntos: • Consistencia: es deseable que el sistema muestre un diseño consistente (que todas las áreas tengan el mismo diseño), para facilitar al usuario el uso del sitio web. • Reversibilidad: un sitio web debe permitir deshacer las acciones realizadas, siempre que sea posible. Aunque otros autores proponen agrupar los conceptos que rodean a la usabilidad en tres tipos: facilidad para aprender (learnability, ya comentado), flexibilidad (un sistema que deja varias posibilidades al usuario de poder manejarlo, será más flexible) y robustez. Para medir el grado de usabilidad de una aplicación hay que diferenciar entre medidas cualitativas y cuantitativas. A lo largo de los años, las cuantitivas han resultado ser las más útiles para definir diseños de interfaces usables, mientras que las cualitativas, por su propia naturaleza (percepciones, preferencias, opiniones de los usuarios), son más subjetivas y difíciles de estructurar. En el caso de una aplicación web, las medidas cuantitativas suelen ser de dos tipos: • Relativas a la composición de la página: tamaño de la página, número de palabras, número de enlaces, proporción entre imágenes y texto, scroll, resoluciones, etc. • Relativas al formato de la página: paleta de colores, tipos de letra, número de párrafos, etc. Con estas leyes de usabilidad presentes en la fase de especificación, se podrán afrontar futuras pruebas de usabilidad durante las fases de diseño e implementación de la aplicación. Esta evaluación de la usabilidad se puede hacer usando diferentes métodos, dependiendo del tiempo y presupuesto disponibles: • Métodos de inspección: normalmente guiados por un experto en usabilidad, examinan todos los aspectos relacionados con la usabilidad y emiten un informe con los errores encontrados. Algunos de estos métodos son la evaluación heurística, inspección formal, o inspección de consistencia y estándares. • Métodos de investigación: recogen opiniones de usuarios relativos a la interfaz, como su claridad o su utilidad. Dependiendo de la manera en la que se produzca la aproximación al usuario para conocer su opinión, se pueden agrupar en: aproximaciones de campo, en grupo o individuales. • Pruebas de usabilidad: conjunto de experimentos que se realizan sobre usuarios finales para obtener información sobre la interfaz y su usabilidad. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!32 7.2 Casos de uso Cabe diferenciar entre casos de uso y diagramas de casos de uso: los diagramas son un resumen gráfico general de los casos de uso o un subconjunto de ellos (algo especialmente útil cuando hay demasiados casos de uso y resulta difícil situarlos y relacionarlos), mientras que los casos de uso deben ser descritos en detalle uno a uno mediante un documento o tabla que explique la forma de interactuar entre el sistema y el usuario. Como el lenguaje de modelado UML no define ningún modelo de tabla o documento a este respecto, se procede a definir el modelo de tabla que describa cada caso de uso: C a s o d e u s o <nº> Nombre del caso de uso. Actores Usuarios que intervienen en el caso de uso. Objetivo Breve descripción del objetivo que se desea alcanzar. Precondiciones Condiciones previas que debe cumplir para el flujo pueda ser llevado a cabo. Flujo general Secuencia de pasos que debe realizar. Postcondiciones Condiciones que debe cumplir si el flujo se ha ejecutado correctamente. Con los casos de uso que vienen a continuación se pretende comenzar a entender cómo funciona el sistema, sin llegar a describirlo absolutamente, ya que nos estamos ciñendo a los aspectos funcionales del mismo. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!33 Figura 7.2. Esquema general de los casos de uso. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!34 Caso de uso 1 Registrarse en el sistema. Actores Usuario anónimo. Objetivo Permite que un usuario se registre en el sistema, y pueda acceder a las ventajas de pertenecer a la comunidad. Precondiciones El usuario debe ser anónimo, es decir, que no haya iniciado sesión. Flujo general El usuario accederá a la página de registro e introducirá los datos requeridos. El sistema registrará al usuario en la base de datos, e iniciará la sesión del usuario automáticamente. Postcondiciones El usuario ha sido registrado en el sistema y con sesión iniciada, y aparecerá un mensaje de confirmación. Caso de uso 2 Iniciar sesión. Actores Usuario anónimo. Objetivo Permite a un usuario autenticarse en el sistema. Precondiciones El usuario debe estar registrado para poder iniciar sesión. Flujo general El usuario introducirá y su nombre y contraseña y procederá a iniciar sesión. El sistema comprobará que los datos son correctos y el usuario está registrado en el sistema: 1-Si son correctos, iniciará la sesión del usuario. 2-Si no, mostrará un mensaje de error. Postcondiciones 1El usuario está autenticado. 2El sistema muestra un mensaje de error. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!35 Caso de uso 3 Editar perfil. Actores Usuario autenticado. Objetivo Permite recalcular el perfil físico del usuario si éste considera que sus condiciones y aptitudes físicas han cambiado. Precondiciones El usuario debe haber iniciado sesión. Flujo general El usuario entrará en el panel de control, y a continuación en la página de edición de perfil, e introducirá los datos requeridos. El sistema calculará el nuevo perfil y lo guardará en la base de datos. Postcondiciones El nuevo perfil se guardará en la base de datos, y aparecerá un mensaje de confirmación. Para calcular el perfil del usuario (casos de uso 1 y 3), se tienen en cuenta varios parámetros: si el usuario entrena (realiza ejercicio físico) regularmente o no, su número de pulsaciones por minuto, su edad, su peso, y su altura. De esos parámetros se obtienen el índice de masa corporal (IMC) y el porcentaje de pulsaciones, de acuerdo las siguientes fórmulas matemáticas: Las unidades son las siguientes: • La unidad del peso es el Kilogramo. • La unidad de la altura es el centímetro. • La unidad de la edad son los años. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!36 Después de un proceso de extracción de características, se extrajeron las siguientes reglas: Figura 7.3. Diagrama de cálculo de perfil. También se puede expresar como una tabla: Entrenamiento % pulsaciones Perfil del usuario IMC Perfil del usuario IMC Perfil del usuario IMC < 25 25-30 > 30 Sí < 35 % A A A Sí 35 - 45 % B B B Sí > 45 % C C C No < 35 % B B baja o C C baja No 35 - 45 % C C baja o D D baja No > 45 % D D baja E Los distintos perfiles significan lo siguiente (el perfil E es igual que D, pero sólo para motivación de paseo): • A: rutas de hasta 9,5 horas, con 2700 m. de desnivel, y recorrido máximo de 42 km. • B: rutas de hasta 9 horas, con 1900 m. de desnivel, y recorrido máximo de 32 km. • C: rutas de hasta 8,5 horas, con 800 m. de desnivel, y recorrido máximo de 23 km. • D: rutas de hasta 6 horas, con 500 m. de desnivel, y recorrido máximo de 12 km. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!37 Caso de uso 4 Editar datos personales. Actores Usuario autenticado. Objetivo Permite editar el correo electrónico y/o la contraseña actuales. Precondiciones El usuario debe haber iniciado sesión. Flujo general El usuario entrará en el panel de control, y a continuación en la edición de datos personales, e introducirá los datos requeridos. El sistema guardará la nueva información en la base de datos. Postcondiciones El nuevo correo electrónico y/o contraseña se guardará en la base de datos, y aparecerá un mensaje de confirmación. Caso de uso 5 Buscar rutas recomendadas. Actores Usuario anónimo, usuario autenticado. Objetivo Pregunta al usuario qué ruta desea buscar de acuerdo al perfil, motivaciones y horas disponibles indicados. Precondiciones Ninguna. Flujo general El usuario accederá desde “Buscador de rutas” a la página de rutas recomendadas. El sistema le preguntará por el perfil, la motivación y opcionalmente las horas disponibles y el fecha prevista para hacer la ruta. El usuario introducirá los datos deseados, el sistema calculará la ruta o las rutas y mostrará los resultados en un mapa y una tabla con las rutas obtenidas. Postcondiciones El sistema muestra la página con el mapa y las rutas obtenidas en el cálculo. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!38 El cálculo de rutas recomendadas tendrá en cuenta el perfil del usuario, las motivaciones, y opcionalmente el tiempo disponible. Figura 7.4. Diagrama de las variables que participan en el cálculo de rutas recomendadas. Existen cuatro posibles motivaciones: deporte, paisaje, ecológico, y paseo. La motivaciones “Deporte” y “Paseo” son excluyentes, es decir, un usuario no podrá buscar una ruta que tenga como motivación ser deportiva y de paseo. Caso de uso 6 Buscar ruta más corta. Actores Usuario anónimo, usuario autenticado. Objetivo Ofrecer al usuario la ruta más corta entre dos puntos indicados en el mapa por el usuario. Precondiciones Ninguna. Flujo general El usuario accederá desde “Buscador de rutas” a la página de ruta más corta. El sistema le mostrará una nueva página con un menú y un mapa donde podrá seleccionar el punto de origen y destino. El sistema calculará la ruta más corta cuando lo indique el usuario y la mostrará en el mapa, suministrando información adicional sobre la misma. Postcondiciones El sistema muestra el resultado en el mapa. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!39 La aplicación MapServer funciona básicamente como un programa CGI (Common Gateway Interface, o interfaz de entrada común) que reside en el servidor, y se ejecuta (en el servidor) cuando un cliente (navegador web) así lo solicita. El funcionamiento de MapServer está configurado en un fichero de texto con extensión “.map” llamado Map File. En este archivo, los datos del mapa están organizados en capas, cada una de las cuales puede ser personalizada mediante ciertos parámetros definidos en el lenguaje de configuración propio que usa MapServer (nombre de la capa, escalas, resolución, tipo de datos, proyección), y dentro de ellas se pueden crear clases para definir el aspecto visual. Esta estructura proporciona una personalización de estilos visuales muy flexible. Además, MapServer facilita una API llamada MapScript que a su vez proporciona un nivel de abstracción mayor hacia otros lenguajes de programación como PHP, Perl, Ruby, Java o C#, de forma que por ejemplo desde una aplicación web escrita en PHP podamos añadir una nueva capa o editar los parámetros de alguna existente, sin tener que acceder directamente al Mapfile. Las características que apoyan la elección de UMN MapServer y lo distinguen sobre otras opciones, como pueden ser GeoServer o Degree, son las siguientes: • Salida cartográfica avanzada. • Alta velocidad de acceso a datos. • Alta capacidad de personalización. • Soporte a entornos de desarrollo y scripting (PHP, Python, Ruby, Java, Perl, C#). • Soporte a varios estándares OGC (WMS, WFS, GML, entre otros). • Variedad de formatos vectoriales soportados: ESRI Shapefiles, PostGIS, MySQL, Oracle Spatial, y otros usando la librería OGR. • Variedad de formatos raster soportados: PNG, TIF/GeoTIFF, JPEG, EPPL7, y otros usando la librería GDAL. • Soporte a proyección de mapas (proyección al vuelo de mapas con más de 1000 proyecciones distintas, mediante la librería Proj.4). • Funciona bajo plataformas Linux, Windows, MacOS X, Solaris, y otros. 8.2.3 Base de datos: PostgreSQL y PostGIS Existe una gran oferta de base de datos, tanto comerciales como gratuitas y de código abierto. Dado que en este proyecto se va a optar por la segunda vía, quedan dos grandes candidatos: MySQL y PostgreSQL. MySQL es la base de datos más popular dentro del ámbito del software libre, especialmente en combinación con el servidor web Apache y el lenguaje de programación PHP. En el ámbito geoespacial es mucho menos utilizada ya que no cumple con todos los estándares internacionales de la OGC, ni incorpora toda la funcionalidad y potencia que ofrece PostGIS. Esto último es el principal motivo de haber escogido PostgreSQL con su extensión PostGIS, dada la naturaleza del proyecto. La base de datos PostgreSQL (versión 8.4), pese a no ser tan popular, está ganando fuerza poco a poco entre la comunidad del software libre y cuenta con un importante equipo de desarrolladores. En algunos estudios ha demostrado ser más robusta que MySQL, mientras que las virtudes de MySQL han residido tradicionalmente en ser más veloz y fácil de usar. No obstante, estos juicios de valor dependen de muchos _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!46 factores (como la cantidad de datos y de relaciones, o el entorno tecnológico en el que estén desplegadas las bases de datos), y con cada actualización se han ido corrigiendo esas “debilidades” hasta converger hacia un rendimiento similar entre ambas bases de datos. El módulo PostGIS (versión 1.5.1), desarrollado principalmente por Refractions Research Inc. bajo la licencia GPL, proporciona a PostgreSQL la capacidad de almacenar información geoespacial (cumpliendo el estándar SFSS, certificado en 2006 por el OGC, lo que garantiza la interoperabilidad con otros sistemas estándar de información geográfica) y de realizar operaciones de análisis geográfico, convirtiéndola en una base de datos espacial para su utilización en Sistemas de Información Geográfica. 8.2.4 La librería pgRouting Esta librería reside dentro de la base de datos como un conjunto de funciones que pueden ser invocadas en cualquier consulta SQL, y tiene como objetivo proveer a PostgreSQL y PostGIS con funcionalidades avanzadas de enrutamiento. De esta forma, se podrán realizar cálculos de rutas entre dos puntos, usando los datos geoespaciales almacenados en la base de datos. La librería pgRouting es capaz de transformar un conjunto de datos geoespaciales vectoriales, y construir una topología en forma de grafo de los mismos, con unos nodos que se corresponderán con las interesecciones de líneas unidos por arista, que serán esas líneas y cuyo peso será normalmente la distancia. PgRouting incorpora tres algoritmos para el cálculo de la ruta más corta (o económica): • Algoritmo de Dijkstra: diseñado por Edsger Dijkstra en 1959, se trata del algoritmo clásico para este tipo de problemas. Explora todos los caminos más cortos de un grafo desde un nodo origen a un nodo destino, hasta obtener el más corto de todos ellos. • Algoritmo A*: es una extensión del algoritmo de Dijkstra. Incluye una serie de funciones heurísticas (que estiman el coste del camino más corto) que mejoran la velocidad de cálculo, a costa de perder un poco de precisión, aunque si delimitan bien la zona de cálculo (mediante un cuadro o caja bidimensional) puede obtener resultados similares a Dijkstra. Aplicaciones como Google Maps utilizan este algoritmo. • El algoritmo Shooting Star: calcula la ruta más corta entre dos aristas, en vez de entre dos nodos, como los anteriores algoritmos. Además, permite añadir restricciones a la búsqueda, como dificultades que puede haber en el camino (tipo de vía, semáforo, obras, etc.). 8.2.5 OpenLayers Hasta ahora se han visto las herramientas necesarias para publicar un mapa en el nodo IDE, gracias al servidor de mapas y la base de datos. El siguiente paso es poder trabajar con ese mapa, de solicitar información del mismo, visualizarlo, en definitiva de interactuar con él. Existen dos formas de acceder a estos propósitos: • Mediante una aplicación SIG de escritorio, como gvSIG, Quantum GIS o ArcInfo. • Mediante alguna herramienta que se pueda incluir en la aplicación web para poder mostrar mapas interactivos en un navegador, que es lo que se conoce como cliente Web-GIS ligero. Entre otros ejemplos, está OpenLayers [18]. OpenLayers es una librería de código abierto escrita en JavaScript para cargar, renderizar y mostrar datos de mapas en navegadores webs modernos, sin depender del lado del servidor (es decir, todo el trabajo de _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!47 renderizado lo hace el cliente por medio de su navegador), similar a las APIs de Google Maps o Microsoft Bing, con la diferencia de que OpenLayers es software totalmente libre, y además pertenece al proyecto OSGeo. OpenLayers ha sido desarrollado para poder usar numerosos tipos y formatos de información geográfica, soportando los estándares OGC como WMS o WFS. Figura 9.3 Aspecto visual de OpenLayers en un navegador web. Son muchas las ventajas que ofrece este cliente Web-GIS sobre otros de su estilo, como Ka-Map o Mapbender, y que lo han convertido en el más usado y popular de la comunidad web (es entre otros el visor de OpenStreetMap.org, una especie de versión abierta y colaborativa de Google Maps): • Simplicidad de uso. • Soporte de teselas (tiles) y cacheado de mapas, que permiten cachear peticiones a servidores de mapas de forma que los clientes reciben teselas para ser visualizadas sin tener que ir directamente al origen de los datos. Esto incrementa notablemente el rendimiento. • Soporte de estándares OGC. • Acceso de los mapas de Google Maps, Bing Maps o Yahoo Maps. • Comunidad de desarrolladores muy activa, con constantes actualizaciones y mejoras. Por tanto, esta librería se encargará de la tarea fundamental de mostrar mapas y también las rutas ofrecidas al usuario en distintas capas, para que puedan ser manejadas de forma independiente. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!48 8.3 Descripción del comportamiento del sistema A continuación se explicará el funcionamiento y las operaciones del sistema, y para ello se hará uso principalmente de los diagramas de secuencia. Se obtienen de forma casi automática a partir de los casos de uso expuestos anteriormente, así que cada uno de estos tendrá un diagrama de secuencia asociado. 8.3.1 Diagrama de secuencia 1: registrarse como usuario Esta función tiene como finalidad crear una cuenta de usuario. La secuencia temporal de la acción transcurre de la siguiente forma: Figura 8.4 Diagrama de secuencia 1: registrarse como usuario. El diagrama anterior muestra cómo transcurre el proceso de registro del usuario en el sistema. Un usuario anónimo accede a la página de registro, rellena un formulario con los datos solicitados y lo envía a la aplicación, que comprueba la disponibilidad del nombre de usuario introducido y en caso afirmativo lo registra en la base de datos del sistema, e inicia la sesión del nuevo usuario automáticamente. En caso de que ya existiera un usuario registrado con el mismo nombre, se avisará de tal circunstancia. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!49 8.3.2 Diagrama de secuencia 2: iniciar sesión La siguiente secuencia muestra cómo un usuario inicia sesión. Figura 8.5 Diagrama de secuencia 2: iniciar sesión. En este caso, un usuario anónimo previamente registrado que quiera iniciar sesión debe acudir al menú de usuario (accesible desde cualquier módulo), introducir su nombre de usuario y su contraseña, y enviar esos datos a la aplicación. la aplicación comprobará que el usuario se encuentra registrado en el sistema, que los datos introducidos son correctos. En caso afirmativo, iniciará la sesión del usuario y mostrará un mensaje. En caso contrario, mostrará un mensaje informando de que no ha podido iniciar dicha sesión. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!50 8.3.3 Diagrama de secuencia 3: editar perfil Cuando un usuario se registra, la aplicación calcula su perfil físico de acuerdo a los datos que ha introducido durante el proceso de registro. En cualquier momento, el usuario podrá volver calcular ese perfil si entiende que sus características y/o capacidades físicas han cambiado con el tiempo, tal y como se muestra en el siguiente diagrama: Figura 8.6 Diagrama de secuencia 3: editar perfil. El usuario, que debe estar autenticado, accede al módulo de edición del perfil, rellena un formulario y envía los datos a la aplicación, que calculará el nuevo perfil, lo actualizará en la base de datos, y mostrará un mensaje al usuario confirmando la operación. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!51 8.3.4 Diagrama de secuencia 4: editar datos personales Esta operación es similar a la edición del perfil, y consiste en actualizar los datos personales del usuario, en concreto la contraseña y el correo electrónico. Figura 8.7 Diagrama de secuencia 4: editar datos personales. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!52 8.3.5 Diagrama de secuencia 5: búsqueda de rutas recomendadas (usuario anónimo) Los dos siguientes diagramas realizan la misma operación, pero los actores son distintos y no producen los mismos resultados. En este primer caso (Diagrama de secuencia 5), se trata de un usuario anónimo. Figura 8.8. Diagrama de secuencia 5: búsqueda de rutas recomendadas (usuario anónimo). El usuario accede en primer lugar al módulo de rutas recomendadas donde por medio de un formulario expresará qué rutas desea realizar. Cuando envía los datos del formulario a la aplicación, ésta calcula las rutas de acuerdo a esos datos y dirige al usuario al módulo donde se muestra el resultado de dicho cálculo. En este caso, por ser un usuario anónimo, sólo se mostrará un ruta, la primera que haya calculado la aplicación. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!53 8.3.6 Diagrama de secuencia 6: búsqueda de rutas recomendadas (usuario autenticado) Esta operación es prácticamente similar al diagrama de secuencia 5. El actor aquí es un usuario autenticado. Figura 8.9. Diagrama de secuencia 6: búsqueda de rutas recomendadas (usuario autenticado). El proceso es igual al descrito en el apartado anterior, salvo que en la página de resultados se muestran todas las rutas encontradas. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!54 8.3.7 Diagrama de secuencia 7: búsqueda de la ruta más corta El siguiente diagrama muestra el flujo de acontecimientos que suceden durante la acción de buscar la ruta más corta por parte de un usuario, ya sea anónimo o esté autenticado. Figura 8.10. Diagrama de secuencia 7: búsqueda de la ruta más corta. En este caso, el usuario accede al módulo de cálculo de ruta más corta, donde la aplicación muestra el mapa y unos controles para que el usuario pueda indicar los puntos de origen y destino de la ruta. El usuario envía los datos relativos a esos puntos y la aplicación trata de buscar la ruta más corta mediante los algoritmos implementados en la base de datos con pgRouting. Llegados a este punto pueden suceder dos cosas, tal y como queda reflejado en el diagrama: • La aplicación ha encontrado la ruta más corta, y la muestra al usuario en el mapa del módulo de cálculo de ruta más corta. • La aplicación no ha encontrado ninguna ruta entre esos dos puntos, y notifica al usuario de dicho suceso. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!55 9.2.4 GeoJSON El formato GeoJSON es una extesión del formato JSON, que proporciona un método ligero de intercambio de datos. La ventaja de GeoJSON sobre otros formatos es su simplicidad, rapidez e integración con la sintaxis de JavaScript, y permite especificar información relativa al sistema de referencia de los datos geoespaciales que acompaña de este formato. Un ejemplo de objeto GeoJSON es el siguiente, donde guarda la información geográfica en un array “coordinates”, indicando el tipo de geometría (“type”:”MultiLineString”), o el sistema de referencia (“crs”): {"longitud":1799.32429278, "type":"FeatureCollection", "features":[{"type":"Feature", !! "geometry":{"type":"MultiLineString", !!!!!"coordinates":[[[-4.97458978313,36.6789033882], [-4.97569687544,36.6787719756],[-4.97662395803,36.67887116], [-4.97719120286,36.6788044587],[-4.97786654575,36.6787932436], [-4.97828941133,36.6786430082],[-4.9790068963,36.6788888661], [-4.97936674125,36.679054738],[-4.97938361229,36.6797132277], [-4.97942649191,36.6799989361],[-4.97975153127,36.6801940278], [-4.97996039903,36.6800187024],[-4.98052691353,36.6799233547], [-4.98062137858,36.6799577548],[-4.98066053572,36.68003567], [-4.98060607806,36.6802371017],[-4.98086003026,36.6804333727], [-4.98132872476,36.6806833545],[-4.98161528838,36.6807645128], [-4.98190332157,36.6809029302],[-4.98215434192,36.6809846779], [-4.98251567266,36.6812078003],[-4.98262671659,36.6813778041], [-4.98341900741,36.6817656001],[-4.98413138928,36.6818110162], [-4.98519554825,36.6817073531],[-4.98586649732,36.681524313], [-4.98636413323,36.6815160128],[-4.98675807767,36.681624009], [-4.98705054138,36.6819341922],[-4.98706158802,36.6823636393], [-4.98699565161,36.6825652345],[-4.98686451421,36.6829970551], [-4.98701185337,36.6831950905],[-4.98783972964,36.6835822626], [-4.98834253581,36.6837743625],[-4.98880099116,36.6842756401]]]}, !!!!!"crs":{"type":"EPSG", !!!!!! "properties":{"code":"4326"}}, !!!"properties":{"id":null,"length":"0.0179932429277887"}}]} _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!62 9.2.5 KML El formato KML define, con una sintaxis similar a XML, un título, una descripción textual básica de los datos, el tipo de datos (punto, linea, multilinea, etc.), las coordenadas (expresadas en longitud y latitud, y con el datum WGS84), e información adicional (como el estilo visual). Un ejemplo de KML es el siguiente: <?xml version='1.0' encoding='UTF-8'?> <kml xmlns='http://earth.google.com/kml/2.1'> <Document> <name>'Caucón - Peña de los enamorados'</name> <description>'Ruta por la Sierra de las Nieves'</description> <Style id='defaultStyle'> <LineStyle> <color>55148EFF</color> <width>4</width> </LineStyle> <PolyStyle> <color>281400FF</color> </PolyStyle> </Style> <Placemark> <styleUrl>#defaultStyle</styleUrl> <MultiGeometry> !<LineString><coordinates>--4.967813858280883,36.701864561555738 -4.967327827037412,36.701967985677626 -4.966827904876978,36.702107407585665 -4.966209528304873,36.704340236755407 -4.966142484891201,36.704498740015552 -4.966091504990966,36.704590203672517 -4.966029773003041,36.704724769907145 -4.965918488943328,36.704774304322001 !</coordinates></LineString> !<LineString><coordinates>-4.965918488943328,36.704774304322001 -4.965771557526046,36.704819655602414 -4.965696405989121,36.70489244062415 -4.965650496749422,36.704950433231495 -4.965670079732863,36.705021652220303 -4.965765788154576,36.705058228897144 -4.965944753118094,36.705107738398446 -4.966093263714632, !</coordinates></LineString> </MultiGeometry> </Placemark> </Document> </kml> _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!63 CAPÍTULO ______________________________________________________________________________________ Análisis del interfaz web En el presente capítulo se analizará la conexión entre el sistema y el usuario final, es decir, el interfaz de usuario. En primer lugar se definirá qué tipos o perfiles de usuario interactuarán mediante dicho interfaz con la aplicación, y a continuación se realizarán unas consideraciones previas al diseño del interfaz. 10.1 Perfiles de usuario La aplicación a desarrollar ofrecerá la posibilidad de crear una cuenta de usuario en ella. Diferenciará entre tres perfiles de usuario: • Anónimo: es el usuario por defecto, que no ha iniciado sesión y tiene el acceso limitado a algunas funciones de la aplicación, como por ejemplo descargar rutas o gestionar una lista personal de rutas. • Autenticado: usuario que previamente se ha registrado en la aplicación y ha iniciado sesión, tiene acceso completo a todas las funciones de la aplicación, salvo las referentes al siguiente perfil, el administrador. • Administrador: usuario autenticado que además puede realizar tareas adicionales de administración del sitio, como gestionar los usuarios registrados. 10 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!64 10.2 Consideraciones previas al diseño de la aplicación La aplicación web se desarrollará como un portal web, y en esta fase hay que tener definida la estructura de programación y la estructura visual de la web, para abordar con garantías el posterior desarrollo de la misma. 10.2.1 El modelo de las tres capas Para implementar el código de la aplicación web se seguirá el modelo de separación en tres capas diferenciadas según su significado [23], muy similar al Modelo Vista Controlador (MVC), y cada una de ellas hará uso de un lenguaje de programación: • Capa de estructura o contenido: “qué significa”, describe el contenido de la página. Esta capa estará escrita en XHTML (eXtensible HyperText Markup Language) 1.0, la versión semántica del tradicional HTML. Con semántico, quiere decir que no definimos el aspecto de las cosas, sino lo que significan. • Capa de presentación: “cómo se muestra”, especifica la presentación de ese contenido. Se programará en CSS (Cascading Style Sheets) en su versión 2, con algunas funcionalidades de la versión 3. • Capa de comportamiento: “qué hace”, controla el comportamiento de ese contenido. Estará escrita en JavaScript (también conocido como ECMAScript). Figura 10.1. Modelo de las tres capas. De esta forma, el proceso de desarrollo también fluye por estas tres capas a modo de etapas, ya que: • Se empieza produciendo el contenido en formato XHTML. Esta es la capa base, y cualquier usuario con cualquier navegador web deberá poder visualizarla. • Con esta capa definida, los esfuerzos se pueden centrar a continuación en dotar a la página web de un estilo visual más atractivo, añadiendo una capa de presentación con información escrita en CSS. El sitio web lucirá mejor para los usuarios cuyos navegadores puedan mostrar estilos CSS. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!65 • Por último, se puede usar JavaScript para introducir una nueva capa de interactividad y comportamiento dinámico, que dotará al sitio web de nuevas funcionalidades y una mayor sencillez en el manejo en los navegadores que sean capaces de ejecutar JavaScript. Con esto no sólo se ofrece una forma ordenada de diseño y posterior mantenimiento al desarrollador, sino que abarca el mayor rango posible de visitantes del sitio web, ya que se ejecutará (aunque de forma limitada) en aquellos navegadores que no soporten las capas superiores (la capa base la podrán leer todos los navegadores). En este sentido, atendiendo a los lenguajes de programación y tecnologías que vamos a usar, hay que considerar lo siguiente: • El lenguaje XHTML y HTML 4.01 están establecidos actualmente. En el horizonte asoman HTML5 y XHTML5, que todavía se encuentran en desarrollo y por esa razón no se usan en este proyecto, aunque los navegadores más modernos ya lo soportan. • El lenguaje CSS 2 también avanza (la versión actual es 2.1) y ya casi está CSS 3, cuyo camino empezó en 1999 y que se encuentra en fase de borrador final por parte del consorcio W3C (organismo encargado de desarrollar especificaciones estándar de la Web), aunque la mayoría de navegadores son compatibles con esta nueva versión. Añade nuevas funcionalidades manteniendo todo lo anterior, así que en futuras actualizaciones se podrán modificar o añadir diferentes características de forma sencilla sin alterar todo lo que hay hecho. • JavaScript (o ECMAScript) ha ido evolucionando de forma tortuosa desde que fuera creado allá en 1995. Netscape delegó en la ECMA (European Computer Manufacturers Association) la normalización del lenguaje, y lo desarrolló bajo el nombre de JavaScript, mientras que Microsoft decidió crear su propia versión, denominada jscript. Las sucesivas actualizaciones de estos lenguajes han ido convergiendo poco a poco hacia el estándar ECMAScript, aunque no de forma uniforme en todos los casos. Pero en las nuevas versiones de los navegadores, incluido el de Microsoft, se puede afirmar que ECMAScript ha superado casi al completo esta fase de incompatibilidades y su funcionamiento es independiente del navegador que estemos usando. • La librería de JavaScript jQuery está muy extendida y apoya la filosofía de cross-browser, por lo que es compatible con todos los navegadores. • El lenguaje del lado del servidor será PHP, que goza de mucha popularidad en el desarrollo web, es multiplataforma, es libre y está en continua evolución. También es muy flexible en cuanto a la metodología de programación que se desee seguir, por lo que se puede adaptar facilmente a nuevos escenarios. Las principales directrices que hay que seguir a la hora de programar en XHTML (y que en algunos casos lo diferencia de HTML) son las siguientes: • La primera línea de un documento XHTML debe marca la codificación de caracteres (formato en el que se guardan). De acuerdo con las recomendaciones del consorcio W3C, se usará la codificación Unicode UTF-8, que soporta caracteres de todas las lenguas, y permite traducir la página a cualquier idioma. • También es conveniente indicar el tipo de documento con la directiva DOCTYPE, en este caso va a ser XHTML 1.0 Transitional. • La estructura guardará un cierto orden, y así por ejemplo en la cabecera (etiqueta <head>) se incluirá los vínculos a hojas de estilo CSS, scripts, información para robots de búsqueda, o el título del documento, por ejemplo. En el cuerpo del documento (etiqueta <body>) no habrá ningún script (etiqueta <script>). _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!66 • Las etiquetas pueden tener la forma <etiqueta>Contenido</etiqueta>, o funcionar con una sola parte, <etiqueta />. En cualquier caso siempre hay que cerrarlas con la barra ‘/’, y en el segundo caso es conveniente dejar una espacio en blanco antes de la barra, para que los navegadores antiguos lo entiendan. • Las etiquetas deben ir siempre en minúsculas, y además pueden llevar atributos, que siempre deben ir entre comillas dobles. Ejemplo: <etiqueta atributo=”valor”>...</etiqueta> . • Todas las imágenes (etiqueta <img>) incluirán el atributo ‘alt’, que contiene una descripción de la imagen, necesaria cuando por algún motivo no se haya podido cargar la imagen, y también por motivos de accesibilidad. • No se usarán tablas para maquetar las páginas web. Antes de la llegada de CSS no había otra forma de maquetar webs (salvo usar frames, algo poco aconsejable). Pero con CSS se hará por medio de capas, cuyo aspecto, tamaño y ubicación se definen en la hoja de estilos, y así no habrá necesidad de modificar código HTML. • Las etiquetas de los campos de los formularios (etiqueta <form>) llevarán un texto asociado mediante la etiqueta <label>, por razones de accesibilidad. Y en CSS: • Se evitará el uso de hacks (trucos para visualizar características de CSS en navegadores poco “exigentes” con los estándares W3C), siempre que no se entre en conflicto con el objetivo de ser crossbrowser. • Se añadirá al principio una hoja de estilo que reinicie todos los valores que suelen llevar por defecto (y no siempre coincidiendo) todos los navegadores, para que la página se visualice igual en cualquier navegador. 10.2.2 Diseño modular de la aplicación De forma complementaria al diseño de las tres capas, la implementación de la aplicación web se abordará mediante este paradigma de la programación, que consiste en dividir el programa en módulos con el fin de distribuir la complejidad en varios problemas (subprogramas) más sencillos, hacerlo más legible, aumentar la escalabilidad y facilitar el posterior mantenimiento del mismo. El lenguaje PHP facilitará enormemente esta tarea [24], ya que permite incluir una serie de mecanismos enfocados a un diseño modular estándar, como por ejemplo añadir código que resida en un archivo separado directamente en documentos HTML (mediante el procedimiento include(“nombre_archivo”)), algo parecido a lo que realizan lenguajes como C++. Los objetivos que se desean alcanzar con el uso de este modelo en PHP, aparte de los ya comentados, son: • Diseñar y centralizar el proceso de creación y configuración de los módulos. Por ejemplo, con un archivo de configuración que defina los módulos existentes en el sitio web, junto a unos parámetros básicos (como el directorio donde se encuentra el archivo, o el nombre del mismo). Esto será la clave de la escalabilidad, ya que para añadir un nuevo módulo sólo habrá que editar este archivo de configuración. • Diseñar y centralizar el proceso de carga de módulos, dado que el navegador cada vez que necesite solicitar una página va a realizar una petición basada en un sólo dato: la dirección URL. A esa dirección se le pueden añadir unos parámetros que especifiquen el módulo que se desea cargar, entre otras cosas. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!67 • Flexibilizar la estructura de la web (XHTML), mediante el uso de plantillas. Esto facilitará cambios en el diseño, si el cliente así lo desea. • Organizar los archivos en directorios. • Reducir el acoplamiento y aumentar la independencia del código, para facilitar su modificación. En el capítulo de implementación de la aplicación web se explicará más a fondo cómo se han llevado a cabo estos objetivos. 10.2.3 Diseño de la interfaz web cliente Con el modelo de las tres capas y el diseño modular en mente, la tarea de diseñar la interfaz de la aplicación web se puede afrontar, partiendo de unos requisitos básicos solicitados por el cliente, con cierta libertad por parte del desarrollador, y garantías de rediseño en caso de que el cliente crea necesario modificar algo del diseño original. Las posibilidades que ofrecen tanto CSS como algunas librerías de JavaScript (jQuery) son enormes, y permiten dotar a la aplicación web de un gran atractivo visual. La misión del desarrollador deber ser encontrar el equilibrio entre todos los aspectos que están en juego, es decir, crear un aspecto visual que sea atractivo pero no excesivamente recargado para no entorpecer la claridad y legibilidad del contenido. La aplicación tendrá una primera página de presentación con un estilo visual diferenciado, con enlaces a la página principal, al buscador de rutas y a la información general de la Sierra de las Nieves, así como una sección “Acerca de la web” que comentará brevemente el propósito y la utilidad de la misma. La página principal tendrá el siguiente diseño, que seguirá un patrón similar en el resto de secciones (menú superior del usuario, menú horizontal de navegación justo antes del contenido de la sección, etc.): Figura 10.2. Diseño del interfaz de la página principal. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!68 Esta será la plantilla general para el resto de páginas. La página que muestre los resultados de la búsqueda de rutas, por ejemplo, tendrá el siguiente aspecto: Figura 10.3. Diseño del interfaz de la página de resultado de rutas. La plantilla para la página de presentación difiere de esta estructura y es más simple. Mostrará el siguiente diseño: Figura 10.4. Diseño del interfaz de la página de presentación. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!69 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!70 BLOQUE 3: DISEÑO E IMPLEMENTACIÓN DEL SISTEMA 12.1.3 Plantillas Las plantillas nos permiten definir la estructura del documento y están escritas en XHTML. Todas comenzarán definiendo el tipo de documento (mediante la directiva <!DOCTYPE), en este caso va a ser un documento XHTML 1.0 Transitional, y a continuación se estructurarán siguiendo la síntaxis definida por XHTML: Figura 12.1. Estructura básica de XHTML. En la cabecera (<head>) se ubicarán el título de documento, los vínculos a hojas de estilo CSS y documentos JavaScript, y metainformación dirigida al navegador web y a los robots de búsqueda (programas que rastrean las páginas web para indexar el contenido de las mismas en su buscador, por ejemplo Google). Las plantillas incluirán parte de esa información a través un archivo externo (mediante la función de PHP include()). En el cuerpo del documento (<body>) se incluirá todo el contenido que se mostrará en la ventana del navegador web. Una manera de poder controlar el aspecto visual es dotar al documento de una estructura de capas (mediante el uso de cajas, con etiqueta <div>), y definir en CSS el aspecto y la ubicación de las mismas. De esta forma, si posteriormente se quiere añadir un elemento nuevo a la página web, tan sólo hay que introducir una nueva capa en la plantilla y definir sus características de presentación en la hoja de estilos CSS. Hay varias plantillas, que se usarán: • Para página de presentación: dada la simplicidad deseada para esta parte, el cuerpo (<body>) no tendrá ninguna capa, y en él se cargará el módulo correspondiente a la presentación. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!78 • Para el resto de páginas sin mapas: el cuerpo estará compuesto de las siguientes capas: Figura 12.2. Capas de la plantilla general de la web. La capa “main” contendrá el módulo cargado, mientras que las capas inferiores se encargarán de ofrecer distintos elementos visuales. • Para el resto de páginas con un mapa interactivo: tiene una estructura similar a la anterior, con la de diferencia de que incluye una llamada a la función JavaScript que carga el mapa interactivo. 12.1.4 Organización en directorios El diseño modular de la aplicación implicará separarla en varios archivos, que se organizarán en varias carpetas o directorios según su función, para facilitar su posterior manejo. Figura 12.3. Organización en directorios de la aplicación web. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!79 A continuación se describe el contenido de cada directorio: • css/ : incluye las hojas de estilo CSS de la aplicación web. • images/ : incluye todas las imágenes utilizadas por la aplicación web. • includes/ : incluye los archivos PHP que se incluye en la estructura de la página, como la cabecera, el menú del usuario, o el pie de página. • js/ : incluye todos los archivos JavaScript utilizados por la aplicación web. • layouts/ : incluye las plantillas web, y también las distintas cabeceras XHTML (etiqueta <head>). • modulos/ : incluye los módulos de la web. En apartados posteriores se describirán cada uno de ellos. • OpenLayers/ : incluye la API OpenLayers. • / (directorio raíz) : incluye los principales archivos (index.php y conf.php), así como los archivos utilizados por el servidor para gestionar sesiones de usuario y todo lo relacionado con la gestión de rutas. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!80 12.2 Modelo de datos En el modelo de datos se explicarán el modelo relacional de la base de datos y el modelo de clases implementadas en la aplicación. 12.2.1 Modelo relacional de la base de datos El modelo relacional de una base de datos es el más actualizado actualmente. Fue creado por Edgar Frank Codd en la década de los setenta, y se trata un paradigma basado en la teoría de conjuntos y lógica de predicados de primer orden que proporciona una forma sencilla de representar los datos: mediante tablas bidimensionales, llamadas relaciones. Como se ha visto en apartados anteriores, la aplicación web hace uso de la base de datos PostgreSQL (con la extensión PostGIS) tanto para la manipulación de datos espaciales como para la gestión de usuarios. El esquema de la base de datos es el siguiente: Figura 12.4. Esquema de la base de datos. El papel de cada una de las tablas se resume en los siguientes puntos: • La tabla usuarios guarda la información de los usuarios registrados en el sistema. • La tabla senderos_usuarios almacena las rutas guardadas por los usuarios. La relación definida con la tabla usuarios establece que cada registros de senderos_usuarios pertenecerá a un sólo usuario, mientras que éste puede tener cualquier número (o cero) de registros en senderos_usuarios. • La tabla senderos guarda las rutas senderistas más típicas y tradicionales de la zona. Se trata por tanto de rutas prefijadas. Cada una de ellas almacena una serie de atributos que definen sus _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!81 características, necesarias a la hora de realizar el cálculo de rutas recomendadas (motivación, horas, perfil, etc.). • La tabla viariopn guarda todo el viario de rutas recopilado de la Sierra de las Nieves, y sobre estos datos se realizarán los cálculos de rutas recomendadas y ruta más corta. • La tabla hitos guarda los puntos de interés de la Sierra de las Nieves, con objeto de aportar información adicional al usuario. • La tabla vertices_tmp se guarda información relativa al cálculo de la topología del viario (realizado por pgRouting), en concreto los nodos del grafo generados y su posición geográfica. Se trata por tanto de una tabla temporal que no interviene en el funcionamiento de la aplicación, pero que puede resultar de utilidad al desarrollador, como se explica en el ANEXO I. • Las tablas spatial_ref_sys y geometry_columns se generan al crear la base de datos en PostGIS, y guardan información relativa a los sistema de referencia espaciales y al tipo de datos geométricos de cada una de las tablas de la base de datos que incluya información geográfica (atributo “the_geom”). 12.2.2 Modelo de clases El modelo de clases se aplica a los scripts escrito en JavaScript. En realidad este lenguaje no maneja clases de una forma estricta (como Java), aunque implementa un modelo parecido, que a veces recibe el nombre de modelo de pseudoclases. En cualquier caso, se van a mostrar los métodos y las clases (o pseudoclases) más importante de la aplicación. El modelo de clases de la aplicación se apoya en la librería OpenLayers, que contiene las clases que se muestran a continuación en el siguiente diagrama: _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!82 Figura 12.5. Diagrama de clases de OpenLayers. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!83 Las clases de OpenLayers más utilizadas serán: • OpenLayers.Map: para la definición del mapa. • OpenLayers.Layer: para las capas del mapa. • OpenLayers.Projection: para la proyección de los mapas. • OpenLayers.Control: para los controles del mapa. • OpenLayers.Bounds: para definir las coordenadas que delimiten la visualización del mapa. 12.3 Interacción entre la aplicación web y la IDE En este apartado se abordará cómo interactúa la aplicación web con la IDE, destacando aspectos como la comunicación entre el navegador web y el servidor, o las operaciones relacionadas con rutas. 12.3.1 Mapas interactivos con OpenLayers OpenLayers será el encargado de generar y hacer visibles los mapas interactivos con las rutas. Esta aplicación se ejecutará en el navegador del usuario mediante código escrito en JavaScript, y se le añadirán una serie de controles para poder navegar por el mapa, realizar zoom sobre el mismo, etc. El primer paso será crear una instancia de mapa (mediante el constructor new OpenLayers.Map), y a continuación se añaden las capas base (ortofotos, topográfico, etc.). Para esto es necesario que OpenLayers se comunique vía WMS con la IDE (mediante el constructor new OpenLayers.Layer.WMS) y haga de ventana por la que el servidor de mapas (UMN MapServer) responda a la petición mostrando la capa y la zona deseadas. Figura 12.6. Comunicación entre OpenLayers y UMN MapServer. Existe otro tipo de capas, que no van a ser generadas por MapServer, sino por el propio OpenLayers (y por tanto el procesamiento va a recaer en el navegador web): las rutas obtenidas como resultado de una búsqueda, o las rutas guardadas por el usuario en su lista personal. Para ello también necesita comunicarse con la IDE, y lo hará a través de una petición asíncrona XMLHTTPRequest (por medio de AJAX) a un módulo PHP del servidor que se encargará de dialogar con la base de datos PostGIS, y obtener los datos de las rutas. Este módulo responderá a OpenLayers a través de un objeto GeoJSON con todos datos referenciados de las rutas requeridas. OpenLayers se encargará de almacenar, manipular y dibujar la ruta en el mapa (mediante el constructor new OpenLayers.Layer.Vector). En el ANEXO II se adjunta una parte del código que ilustra todo este proceso. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!84 Figura 12.7. Comunicación entre OpenLayers y la IDE. 12.3.2 Tabla con rutas La tabla con las rutas del usuario o las rutas resultado se generará dinámicamente, mediante el uso del interfaz DOM (Document Object Model), que proporciona una serie de funciones en JavaScript para acceder e interactuar con cualquier objeto del documento XHTML. Como se acaba de comentar, el cliente (navegador), por medio de OpenLayers, realiza una petición mediante AJAX al servidor y recibe como respuesta datos en formato GeoJSON que el visor se encarga de manipular y transformar visualmente en rutas. Paralelamente, se va generando una tabla a partir del objeto GeoJSON recibido, que incluye datos relativos a la longitud de la ruta, el duración estimada del recorrido de la misma, o la motivación principal de la misma. Y se añaden una serie de opciones, en caso de que el usuario esté autenticado, como bajar la ruta, agregarla a la lista personal, o borrarla. Cada fila se crea con la función del DOM insertRow(), y cada campo se va insertando en una celda. Para iluestrar esto último, el siguiente ejemplo de código inserta una celda en la fila (variable nuevaFila) con la información de la longitud de la ruta: //insertamos celda en la posición 2 de la fila var celda = nuevaFila.insertCell(2); //añadimos un texto con la longitud de la ruta i (dato almacenado //en el objeto GeoJSON ‘JSONrutas’ celda.appendChild(document.createTextNode(JSONrutas.ruta[i].longitud)); Este tipo de comunicación asíncrona permite realizar cambios en la página web mostrada sin necesidad de recargarla por completo. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!85 12.3.3 Cálculo de rutas recomendadas La aplicación tiene prevista la incorporación de un algoritmo que calcula las rutas recomendadas, en función de las características suministradas por el usuario: perfil, motivación o motivaciones, y opcionalmente el tiempo disponible para realizar la ruta. Además, incorporará el cálculo de rutas típicas prefijadas que se ajusten a esas características. La comunicación con la IDE se hace nuevamente en OpenLayers por medio de AJAX, a través de una petición XMLHTTPRequest, a un módulo PHP del servidor que recogerá los parámetros que le pasa OpenLayers (el perfil, las motivaciones y el tiempo disponible) y realizará los cálculos necesarios, apoyándose en la base de datos PostGIS, para obtener las rutas que mejor se ajusten al usuario. Este módulo, igualmente, responderá a OpenLayers a través de un objeto GeoJSON con todos datos geoespaciales y otras características de las rutas. 12.3.4 Cálculo de la ruta más corta El modo de comunicarse con la IDE es similar al apartado anterior. Cuando el usuario señala en el mapa los puntos de origen y destino y realiza la petición de cálculo de la ruta, OpenLayers se comunica mediante AJAX con un módulo que conecta con PostGIS, y éste realice los cálculos con las funciones suministradas por pgRouting. La respuesta, nuevamente, se produce en forma de objeto GeoJSON, que OpenLayers se encargará de pintar en el mapa. 12.3.5 Descargar, agregar o borrar ruta Cuando un usuario pulsa el botón de descarga la ruta, el evento que escucha y controla a ese botón reacciona y se ejecuta una función asociada a ese evento. Dicha función llamará a un módulo PHP (mediante AJAX) para que dialogue con PostGIS y éste convierta los datos de la ruta a formato KML. Agregar una ruta funciona exactamente igual que descargar una ruta, sólo que los datos de la ruta se guardan en la lista del usuario en la base de datos. Y lo mismo ocurre a la hora de borrar una ruta, con el resultado de que PostGIS elimina la ruta de la lista personal de rutas del usuario que está almacenada en la base de datos. 12.4 Módulos de la aplicación 12.4.1 Página de presentación La página de presentación es más una presentación visual de la web. Contiene un menú con los enlaces a la página principal, búsqueda de rutas, información sobre la Sierra de las Nieves, y un enlace "acerca de" que al pulsar sobre él muestra una ventana emergente explicando brevemente en qué consiste la web. El fondo _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!86 contiene una imagen de la Sierra de las Nieves, que se reescala según el tamaño de la ventana del navegador (por medio de CSS). Figura 12.8. Página de presentación. 12.4.2 Página principal Aquí se explica más a fondo, en un recuadro con pestañas (programado con las librería jQuery) las características de la aplicación web, en qué consiste el buscador de rutas y a modo de tutorial se indica cómo usar las diferentes herramientas que ofrece, con objeto de que el usuario se familiarice lo antes posible con la web. También se invita al usuario a registrarse. Figura 12.9. Página principal. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!87 12.4.14 Panel de administrador El panel del administrador permite consultar todos los usuarios que están registrados en la web, y borrar cualquiera de ellos (menos al propio administrador). Figura 12.21. Página de panel del administrador. 12.4 Gestión y control de usuarios La aplicación ofrece la posibilidad de gestionar una comunidad de usuarios. Cada usuario registrado tendrá acceso a nuevas funcionalidades de la aplicación, como pueden ser el cálculo de su perfil, el guardado de rutas o la descarga de las mismas. Para ello, se creará una tabla concreta (usuarios) en la base de datos PostgreSQL que guardará en cada registro todos los datos del usuario, como su nombre, su contraseña, o su correo electrónico. Las contraseñas de los usuarios serán guardadas en la base de datos mediante una huella digital, usando el algoritmo MD5. Básicamente, MD5 es una función hash unidireccional. De esta forma, cuando el usuario inicie sesión enviando su usuario y contraseña, el sistema calculará el código MD5 de esa contraseña y comprobará si coincide con el código guardado en la base de datos. Así, nadie, incluido el administrador, podrá saber las contraseñas mirando en dicha base de datos. Por otra parte, las rutas guardadas por cada usuario se guardarán en otra tabla (senderos_usuarios) con toda la información geoespacial de las rutas, así, como información adicional como la longitud, la dificultad, el perfil, o el tiempo estimado. La aplicación gestionará distintos perfiles de usuario, controlando el acceso de los usuarios a los distintos módulos. Como se ha comentado anteriormente, los archivos principal (index.php) y de configuración (conf.php) de la aplicación serán los encargados de ello. Cuando un usuario inicia sesión en la aplicación, el servidor crea una serie de variables de sesión de PHP vinculadas a ese usuario, y cuando cierra sesión, el servidor las destruye. Para controlar que un usuario ha iniciado sesión, el servidor, mediante PHP, comprobará que existen las variables de sesión correspondientes, de la siguiente forma: _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!94 • El primer paso es iniciando una sesión en PHP: session_start(); • Después comprueba que la variable de sesión del usuario $_SESSION['SESSION_UNAME'] está creada: if (isset($_SESSION['SESSION_UNAME'])) { !//el usuario está autenticado } else { !//el usuario no está autenticado } En caso de que un usuario intente acceder a un módulo en el que no tenga permiso para ello, se mostrará una nueva página con un mensaje informando de la imposibilidad de entrar a dicho módulo. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!95 CAPÍTULO ______________________________________________________________________________________ Diseño del interfaz de !usuario Tras haber realizado una primera aproximación en el capítulo 10 analizando cómo iba a ser la interfaz, en el presente capítulo se describirá el aspecto final de la interfaz de usuario. 13.1 Diseño del interfaz El diseño del interfaz va a ser desarrollado mediante las hojas de estilo CSS y la librería jQuery (escrita en JavaScript, y compatible con la gran mayoría de navegadores web). La hoja de estilos CSS es la herramienta fundamental para definir dónde y de qué forma se ubicarán las capas incluidas en las plantillas así como cualquier tipo de objeto del documento, y también especificará el tipo de letra, el tamaño, los márgenes, los párrafos, los botones, etc. En definitiva, especificará la presentación visual de la web en los aspectos más básicos. La librería jQuery complementa el trabajo de CSS con operaciones más complejas que por el momento no es capaz de hacer CSS, como por ejemplo la transición animada de color cuando se pasa el cursor del ratón por encima de un botón del menú principal de navegación. Se trata por tanto de un aditivo que aporta un mayor atractivo visual y dinamismo a la navegación. Los dos formatos de imagen escogidos para los gráficos e imágenes incluidas en la web son JPEG (Joint Photographic Experts Group) y PNG (Portable Networks Graphics), muy extendidos en la Web. El primero sirve para guardar imágenes de gran tamaño (como los fondos) ocupando muy poco espacio (debido a su gran capacidad de compresión), a costa de una ligera pérdida de calidad. El segundo no tiene tal capacidad de compresión, pero es útil para mostrar pequeños gráficos sin pérdida alguna de calidad y además soporta el uso de transparencias. 13 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!96 Para la creación y edición de gráficos, imágenes, iconos y botones del interfaz se va a hacer uso del editor de imágenes Gimp 2. Las principales operaciones realizadas son redimensionar imágenes, corregir los niveles de color, crear los botones del interfaz, y aplicar reflejos y degradados. A continuación se describen los principales elementos del interfaz de usuario de la aplicación web. 13.1.1 Menú de la página de presentación El principal elemento de la página de presentación es su menú, cuyo diseño está apoyado en unas funciones de jQuery (Interface Elements for jQuery, bajo licencia GPL), que mediante una animación aumenta el tamaño del icono por el que pasa el cursor. La motivación de este diseño se basa en intentar captar la atención del usuario, con enlaces a las principales funcionalidades de la aplicación web. Figura 13.1. Menú de la página de presentación. 13.1.2 Menú de usuario El menú de usuario acompaña durante toda la navegación por la web. Se trata de un menú desplegable que se encuentra en la parte superior derecha de la pantalla, y en él se puede iniciar o finalizar sesión, o acceder directamente a las páginas personales del usuario, tanto en el menú desplegable como a la izquierda del menú: • Acceso directo al panel de control del usuario (“Panel de Control”). • Acceso directo a la lista de rutas del usuario (“Tus rutas”). Figura 13.2. Menú de usuario. También incluye un enlace para registrarse en la web, si el usuario es anónimo. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!97 13.1.3 Menú de navegación El menú de navegación también se encuentra en todos los módulos de la aplicación web, a excepción de la presentación. Su objetivo es ofrecer un menú con los enlaces a los principales módulos de la aplicación: • Presentación. • Página principal. • Buscador de rutas. • Sierra de las Nieves. • Contacto. El diseño de este menú incluye una animación que hace cambiar de color al botón seleccionado por el cursor, y también incluye un código escrito en JavaScript para cambiar el estado de un botón (en concreto añade una clase al botón, “activo”, que en CSS define un color distinto que el resto de botones) cuando está en la página a la que apunta ese botón: $(document).ready(function() { jQuery !('#menua a[href$="'+window.location.search+'"]') !.parent() !.addClass("activo"); }); Figura 13.3. Menú de navegación (visto desde el módulo de la página principal). 13.1.4 Controles del mapa Los controles del mapa permiten interactuar con él y aportar información adicional a lo que se está visualizando. La mayoría están incluidos en OpenLayers (como la barra de zoom), aunque esta librería suministra herramientas para personalizar sus controles o crear otros nuevos. Estos son los controles incluídos: • Control de navegación: en realidad incluye dos tipos de navegación, usando los controles (las cuatro flechas situadas en la parte superior izquierda del mapa) o arrastrando el mapa con el ratón. • Barra de zoom: permite realizar distintos grados de zoom sobre el centro del mapa. • Caja de zoom: está situado en la parte superior izquierda (una lupa sobre un cuadrado), y permite realizar un zoom sobre el recuadro que dibuje el usuario con el ratón. La forma de dibujar el recuadro consiste en pulsar el botón principal del ratón sobre un punto del mapa, y moverlo hacia otro punto, trazando la diagonal del rectángulo sobre el que se realizará el zoom. • Barra de escala: indica la escala a la que está el mapa mostrado (se indica en kilómetros y en millas). _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!98 • Coordenadas: indican la longitud y latitud geográficas del punto sobre el que está situado el cursor, de acuerdo al datum WGS84. Este control ha sido editado para mostrar claramente la información. • Cambio de capa base: situado en la parte superior izquierda, permite cambiar la capa base entre un mapa topográfico y un mapa con fotografías tomadas desde al aire (ortofoto). Se trata de un control creado desde cero, que incluye unos botones con el nombre de la capa. Figura 13.4. Controles del mapa. 13.1.5 Tabla de rutas La tabla de rutas ofrece un listado con información de las mismas (nombre, longitud, etc.), y una serie de controles para mostrarlas en el mapa, descargarlas, borrarlas o agregarlas a la lista personal. Además, incluye una función de jQuery llamada Tablasorter (bajo licencia GPL) que permite ordenar la tabla de acuerdo a cualquier campo, pulsando sobre la cabecera de la columna que se desee ordenar. Figura 13.5. Tabla de rutas. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!99 13.1.6 Mensajes de información Algunos botones y formularios incluyen pequeños mensajes de información para explicar qué hacen o en qué consisten algunos campos de esos formularios. Los mensajes están programados con unas funciones de la librería jQuery (Tiptip, bajo licencia GPL). Figura 13.6. Mensaje de información. 13.1.7 Fechas Cuando la aplicación pide introducir una fecha, incluye una pequeña utilidad programada con la librería jQuery UI (una versión de jQuery especializada en interfaces de usuario, bajo licencia GPL) llamada Datepicker, que muestra un calendario gráfico donde se selecciona la fecha pulsando sobre el día del mes y año deseados. Esto evita por ejemplo que el usuario pueda introducir una fecha con un formato erróneo al esperado por la aplicación. Figura 13.7. Cuadro de calendario para seleccionar fecha. 13.2 Usabilidad del interfaz En el capítulo 7 se definió el concepto de usabilidad, y también se citaron una serie de características contempladas para mejorar la usabilidad de un interfaz. En este punto se van a enumerar las medidas adoptadas para cumplir los requisitos de usabilidad marcados. El objetivo principal de la usabilidad se centra en la rapidez y facilidad de uso de la aplicación. Durante el desarrollo del interfaz se han tenido presentes estos dos puntos: • Rapidez: se ha evitado el uso de imágenes de gran tamaño o en gran número en una misma página, así como de scripts no programados en JavaScript (como applets de Java, videos, o animaciones Adobe Flash) que puedan ralentizar la carga y la navegación por las páginas, optando por un diseño lo más minimalista posible. • Facilidad de uso: en la página principal se explica brevemente cómo usar la aplicación con objeto de que el usuario comience a usarla correctamente lo antes posible (learnability), y se han intentado implementar menús intuitivos y claros, con accesos directos adicionales que ayuden a una navegación sin dificultades y fácil de aprender por parte del usuario (memorability). _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!100 Otros puntos que había que tener en cuenta son: • Consistencia: la aplicación muestra un diseño consistente, ya que todos los módulos tienen el mismo diseño, salvo la página de presentación, que realmente no participa en las principales funciones de la aplicación. • Reversibilidad: la aplicación web permite retroceder en el historial de navegación en la mayoría de los casos. • Ausencia de errores: gran parte de las pruebas de la aplicación han ido dirigidas a comprobar el correcto funcionamiento del interfaz, y la ausencia de errores que entorpezcan la navegación. • Composición de la página (medidas cualitativas): en cada página se ha optado por un diseño minimalista. Esto implica un tamaño limitado de la página, evitando en la medida de lo posible hacer uso del scroll (deslizamiento) vertical, con el mínimo texto necesario, en definitiva, evitar que esté excesivamente recargada y penalice la facilidad de uso y aprendizaje del usuario. • Formato de la página (medidas cualitativas): la elección de la paleta de colores es importante para el aspecto visual de la web. En este caso se ha evitado el uso de colores excesivamente llamativos, y se han usado degradados y transparencias para suavizar los contrastes. También se ha elegido un tipo de letra estándar lo más sencilla posible, sin bordeados. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!101 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!102 BLOQUE 4: PRUEBAS ! CAPÍTULO ______________________________________________________________________________________ Conclusiones Tras la finalización de todas las fases de desarrollo del proyecto, se expondrán una serie de conclusiones relativas a los objetivos planteados, a las pruebas realizadas, y por último una valoración personal de todo el proceso. 16.1 Conclusiones sobre objetivos planteados En los primeros capítulos de la presente memoria se han expuesto los pasos a seguir para la realización de este proyecto y los objetivos marcados. Tras haber finalizado el proyecto creo que esos objetivos se han cumplido con creces: • Se ha realizado un estudio previo del ámbito de los Sistemas de Información Geográfica y las Infraestructuras de Datos Espaciales, se han estudiado algunos conceptos necesarios de Cartografía; en definitiva, he adquirido una base teórica imprescindible para llevar a cabo el proyecto. • Se han estudiado las opciones existentes para llevar a cabo el diseño de un nodo IDE. • Se han estudiado y analizado paradigmas de desarrollo web y los lenguajes de programación necesarios para poder afrontar el desarrollo de la aplicación. • Se ha implementado un nodo IDE totalmente operativo. • Se ha creado una aplicación web que ofrece búsquedas personalizadas de rutas en base a unos parámetros proporcionados por el usuario (sus capacidades físicas, su motivación, etc.). • Se ha logrado implementar un sistema de gestión de usuarios en la aplicación. • Se ha logrado que la aplicación muestre las rutas de forma que sean útiles al usuario, ofreciendo la posibilidad de descargarlas, o almacenarlas en una lista personal dentro de la web. 16 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!111 • Se ha dotado a la aplicación de un interfaz de usuario lo más amigable, atractivo y sencillo posible. • Se ha logrado interconectar la aplicación web con el nodo IDE implementado. 16.2 Conclusiones de la fase de pruebas La fase de pruebas se ha realizado paralelamente a la fase de implementación del nodo IDE y la aplicación, intentando abarcar los principales casos de uso y posibles ejecuciones de la aplicación, y se ha comprobado que la aplicación funciona correctamente, mostrándose muy estable en todo momento. Sin duda ha podido quedar alguna posible ejecución sin estudiar, y no se puede asegurar por completo que la aplicación esté libre de errores, pero se ha intentado en todo momento estudiar los casos más importantes con multitud de variantes, poniendo especial atención en todo lo relacionado con el cálculo y manejo de rutas. También se ha puesto énfasis en la compatibilidad de la aplicación con los principales navegadores web, repitiendo pruebas en los distintos navegadores. En ocasiones algún navegador se ha comportado de manera distinta a lo esperado (principalmente procesando código JavaScript y CSS), pero se ha logrado subsanar con ayuda de una nueva función o definición. 16.3 Conclusiones personales del proyecto Mis sensaciones tras finalizar este proyecto son muy positivas. Ha sido un largo y duro camino, pero creo que ha merecido la pena. He tomado contacto y aprendido un ámbito de la Informática, el de los Sistemas de Información Geográfica, que desconocía por completo. La Geografía, la Cartografía y todo lo relacionado con el estudio de mapas son cuestiones que me han apasionado desde pequeño, y me alegra haber podido satisfacer mi curiosidad por estos temas y haberlos podido incluir en un proyecto de Informática. Además, siempre tuve inquietud por saber cómo funcionaban por dentro aplicaciones como Google Maps. Tras la realización de este proyecto, al menos ya empiezo a intuir cómo lo hace, y me parece todavía más apasionante y admirable que antes. Por otra, he aprendido desde cero varios lenguajes de programación actuales y paradigmas de desarrollo web, así como en la puesta a punto y manejo de un servidor web y toda la tecnología relacionada con los SIG y las IDE. También he podido experimentar de primera mano los problemas que surgen cuando cierto navegador no cumple los estándares web. He de admitir que al principio no veía cómo iba a ser capaz de aprender de forma autodidacta todos esos lenguajes (como HTML, CSS, PHP, y especialmente JavaScript), me parecía una tarea enorme. Pero a medida que los he ido estudiando, he notado varias cosas que me han aportado el estudio de esta Ingeniería Técnica: pese a no ver visto ni una línea de código de esos lenguajes durante los tres años de carrera, he reconocido patrones, similitudes en la sintaxis y en la forma con otros lenguajes (PHP es parecido a C y C+ +, JavaScript usa algo parecido a los objetos y las clases de Java, etc.), que me han facilitado su aprendizaje y posterior desarrollo; o la capacidad de afrontar un problema, planteándome de qué forma lo programaría. Es decir, me han aportado una serie de herramientas básicas para afrontar nuevos paradigmas de desarrollo de software. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!112 CAPÍTULO ______________________________________________________________________________________ Líneas futuras Aunque se han cumplido todos los objetivos planteados al inicio, durante el desarrollo del proyecto han surgido una serie de posibles funcionalidades no contempladas que pueden enriquecer las posibilidades de comunicación entre el usuario y la aplicación (por ejemplo: opción para recuperar la contraseña, envíos de emails informativos, recordar el inicio de sesión, ). Por otro lado, se deja abierta la posibilidad de poder incluir información de cualquier otra zona que no sea la Sierra de las Nieves, de forma que se pueda trasladar a cualquier escenario, lo que sin duda puede ayudar a alcanzar una mayor difusión y una posible viabilidad y rentabilidad económica. En cualquier caso, el desarrollo del proyecto ha tenido en cuenta otros escenarios, y se ha diseñado de forma que sea fácil incorporar otras zonas. Así mismo, el siguiente paso será añadir el algoritmo de cálculo de rutas recomendadas desarrollado por el otro proyecto vinculado a éste. 17 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!113 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!114 ANEXO I: MANUAL DE INSTALACIÓN CAPÍTULO ______________________________________________________________________________________ Instalación del servidor En cuanto a los recursos software empleados para el proyecto caben destacar los siguientes: • Sistema Operativo Linux Ubuntu 10.04. • Editores de texto Gedit, Kompozer y Geany como entorno de desarrollo para la creación y edición del código fuente. • Servidor web Apache 2, bajo licencia Apache License. • Servidor de mapas UMN MapServer, bajo licencia X/MIT. • Gestor de bases de datos PostgreSQL 8.4 (bajo licencia BSD) con las extensiones PostGIS 1.5.1 (licencia GPL) y pgrouting 1.01 (licencia GPL v2). Además, para facilitar las tareas de administración se han usado los entornos gráficos pgAdmin 3 y phpPgAdmin (web). • Aplicación SIG de escritorio gvSIG, bajo licencia GPL v2. • Librería OpenLayers, bajo licencia FreeBSD. • Herramienta para creación de diagramas de flujo DIA, bajo licencia GPL. • Editor de imágenes Gimp 2, para los gráficos presentes en la página web, bajo licencia GPL. Sistema Operativo El Sistema Operativo utilizado ha sido Linux Ubuntu 10.04, de la rama Debian, una distribución que goza de un gran soporte por parte de la comunidad de software libre. Este Sistema Operativo es libre y gratuito, y se puede descargar desde la página oficial (www.ubuntu.com). 18 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!117 Servidor web Para dotar al servidor de la capacidad de atender y dispensar páginas web mediante el protocolo estándar HTTP, se ha instalado Apache 2, el servidor más popular usado en Internet. La aplicación se encuentra en los repositorios oficiales de Ubuntu, y para instalarla hay que introducir el siguiente comando en un terminal: sudo apt-get install apache2 Además, dado que la aplicación web se basará en contenido dinámico, se optará por usar el módulo de PHP como lenguaje del lado del servidor para dotar a Apache de la capacidad de tratar con contenido dinámico. Para ello hay instalar el modulo PHP para Apache. Tras terminar la instalación, hay que reiniciar el servidor web. sudo apt-get install php5 libapache2-mod-php5 sudo /etc/init.d/apache2 restart Base de Datos El siguiente paso es instalar la base de datos PostgreSQL (versión 8.4), junto con la extensión PostGIS y la librería pgRouting. Éste no se encuentra en los repositorios oficiales de Ubuntu, pero existe una comunidad llamada UbuntuGIS que ofrece unos repositorios actualizados de software geoespacial, entre las que se encuentra pgRouting. Por tanto, lo primero que hay que hacer es añadir el repositorio en Ubuntu, con los siguientes comandos: sudo add-apt-repository ppa:georepublic/pgrouting sudo apt-get update sudo add-apt-repository ppa:ubuntugis/ppa sudo add-apt-repository ppa:ubuntugis/ppa Y después proceder a la instalación conjunta de PostgreSQL, PostGIS y pgRouting: sudo apt-get install gaul-devel \ postgresql-8.4-pgrouting \ postgresql-8.4-pgrouting-dd \ postgresql-8.4-pgrouting-tsp El gestor de base de datos quedará instalado, aunque el modo de acceder e interactuar con él será a través de la línea de comandos del terminal. Si se desea utilizar una interfaz gráfica, el centro de software de Ubuntu ofrece la aplicación pgAdmin3. Si se desea una interfaz web, se puede instalar phpPgAdmin: sudo apt-get install phppgadmin _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!118 Y a continuación reiniciar Apache: sudo /etc/init.d/apache2 restart Comunicando la aplicación con la base de datos Cuando la aplicación web necesite dialogar con la base de datos utilizará el lenguaje PHP, y para ello se instalará el modulo de PHP para PostgreSQL. Tras ello, reiniciar el servidor web: sudo apt-get install php5-pgsql sudo /etc/init.d/apache2 restart Servidor de mapas. UMN MapServer. Un servidor de mapas de Internet (IMS las siglas en inglés) es un servicio que provee mapas a través de la red, normalmente como imágenes. Una especificación estándar para este tipo de servidores es el OGC Web Map Service (WMS). sudo apt-get install mapserver sudo /etc/init.d/apache2 restart Esto instalará también las librerías espaciales GDAL/OGR y PROJ.4. Para comprobar que MapServer funciona correctamente, introducir en el navegador la siguiente dirección: http://localhost/cgi-bin/mapserv _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!119 POSITION cr MINSIZE 8 MAXSIZE 12 BUFFER 2 END END END END Aquí se puede apreciar los puntos inconexos, en rojo: Figura A-I.1. Mapa con inconexiones (I). _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!126 Si hacemos zoom sobre una zona, apreciamos con más detalle dónde se producen: Figura A-I.2. Mapa con inconexiones (II). Figura A-I.3. Mapa con inconexiones (III). _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!127 Una cantidad excesiva de inconexiones provocará una funcionamiento deficiente del cálculo de rutas: Figura A-I.4. Mapa con inconexiones (IV). _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!128 Gestión de usuarios La gestión de usuarios se va a llevar a cabo a través de la base de datos, por lo que hay que crear una tabla que almacene los datos de las cuentas de usuario. --Crear tabla usuarios CREATE TABLE usuarios (user_id integer NOT NULL, username character varying(11) NOT NULL, password character varying(32) NOT NULL, email character varying(40) NOT NULL, perfil integer ); CREATE SEQUENCE usuarios_user_id_seq START WITH 1 INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; ALTER SEQUENCE usuarios_user_id_seq OWNED BY usuarios.user_id; ALTER TABLE usuarios ALTER COLUMN user_id SET DEFAULT nextval ('usuarios_user_id_seq'::regclass); _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!129 Adicionalmente, también hay que incluir una tabla que almacena las rutas guardadas por los usuarios. --Tablas de rutas de usuarios (senderos_usuarios) CREATE TABLE senderos_usuarios ( id integer NOT NULL, usuario character varying(11) NOT NULL, gid integer NOT NULL, nombre character varying(35), length integer, perfil character varying(1), dificultad character varying(10), horas double precision, fecha date, motivacion character varying(50), the_geom geometry, CONSTRAINT enforce_dims_the_geom CHECK ((st_ndims(the_geom) = 2)), CONSTRAINT enforce_geotype_the_geom CHECK (((geometrytype(the_geom) = 'MULTILINESTRING'::text) OR (the_geom IS NULL))), CONSTRAINT enforce_srid_the_geom CHECK ((st_srid(the_geom) = 4326)) ); Estructura en directorios Como se ha comentado en capítulso anteriores, la aplicación quedará estructurada en lo siguientes directorios, que se incluyen en el CD que acompaña a la memoria. css/ images/ includes/ js/ layouts/ modulos/ OpenLayers/ _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!130 ANEXO II: MANUAL DE CÓDIGO ______________________________________________________________________________________ Manual de código En esta sección se muestra el código o parte del código de algunos de los archivos más importantes de la aplicación que son mencionados a lo largo de la memoria, por si el lector quiere profundizar más en ellos. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!133 Mapfile MAP NAME mapasnieves IMAGETYPE png SYMBOLSET "mapa23.sym" FONTSET "fonts.txt" SHAPEPATH "/home/user/shp/" CONFIG "PROJ_LIB" "/home/user" LEGEND IMAGECOLOR -1 -1 -1 LABEL FONT "vera" ANGLE FOLLOW COLOR 0 0 0 ENCODING "UTF-8" TYPE truetype SIZE 8 END STATUS ON TRANSPARENT ON END WEB METADATA "wms_title" "Mapserver Sierra de las Nieves" "wms_srs" "EPSG:4326 EPSG:900913" "wms_onlineresource" "http://localhost/cgi-bin/mapserv?map=/ home/user/01aptwms.map" END END PROJECTION "init=epsg:900913" END OUTPUTFORMAT ! NAME png ! DRIVER "GD/PNG" ! MIMETYPE "image/png" ! IMAGEMODE RGBA ! EXTENSION "png" TRANSPARENT ON END LAYER NAME "viariopn5" STATUS ON TYPE LINE DATA "viario_pn_5_4326.shp" MAXSCALE -1.0 MINSCALE -1.0 SIZEUNITS pixels PROJECTION "init=epsg:4326" END CLASS STYLE COLOR 210 105 30 WIDTH 2 END NAME "default" END _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!134 METADATA "wms_title" "viariopn5" ! "wms_srs" "EPSG:4326 EPSG:900913" "wms_abstract" "generated by gvSIG" "gml_include_items" "all" END END # Layer LAYER NAME "hitos" STATUS ON TYPE POINT OFFSITE 255 255 255 TOLERANCE 20 DATA "hitos_4326.shp" MAXSCALE -1.0 MINSCALE -1.0 SIZEUNITS pixels PROJECTION "init=epsg:4326" END CLASS STYLE COLOR 100 149 237 WIDTH 3 END NAME "default" END METADATA "wms_title" "hitos" ! "wms_srs" "EPSG:4326 EPSG:900913" "wms_abstract" "generated by gvSIG" "gml_include_items" "all" END END # Layer END # Map File _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!135 [16]: PostGIS: postgis.refractions.net. [17]: PgRouting: www.pgrouting.org. [18]: OpenLayers: www.openlayers.org. [19]: ESRI Shapefile: www.esri.com/library/whitepapers/pdfs/shapefile.pdf. [20]: GeoTIFF: geotiff.osgeo.org. [21]: GeoJSON: www.geojson.org. [22]: KML: code.google.com/apis/kml/documentation/. [23]: Modelo de las tres capas: http://www.cristalab.com/tutoriales/javascript-no-intrusivo-css-y-phpc31507l/ [24]: Diseño modular: http://www.zonaphp.com/creando-webs-modulares/ Otras obras consultadas: GÓMEZ CASTAÑO, JOSÉ (2010) : "Desarrollo de una IDE ferroviaria basada en software libre". Art. IV Jornadas de SIG libre, Gerona. SANZ SALINA, J. GASPAR y MONTESINOS LAJARA, MIGUEL (2006): "Panorama actual del ecosistema de SIG libre". Art. Prodevelop. JOLY, FERNAND (1982): "La cartografía". Ariel, Barcelona. BASELGA MORENO, SERGIO (2006): "Fundamentos de cartografía matemática". Universidad Politécnica de Valencia. COMAS, DAVID y RUIZ, ERNESTO (1993): "Fundamentos de los Sistemas de Información Geográfica". Edit. Ariel, Barcelona. LAURINI, ROBERT y THOMPSON, DEREK (1992): "Fundamentals of Spatial Information Systems". Academic Press, London. LUQUE RUIZ, I. y GÓMEZ-NIETO, M.A. (1997): "Diseño y uso de bases de datos relacionales". Ediciones Ra-Ma Madrid. SAMET, HANAN (1990): "Applications of Spatial Data Structures". Addison-Wesley Publishing Company, New York. _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!142 Índice de figuras .............................................................................................Figura 2.1. Esquema básico del proyecto.! !9 .........................................................Figura 3.1. Proyección cilíndrica, cónica, y acimutal gnomónica.! !17 ..........................................................................................................Figura 3.2. Zonas (husos) UTM.! !18 ...............................................................................................Figura 7.1 Primer esquema del sistema.! !29 .................................................................................Figura 7.2. Esquema general de los casos de uso.! !34 ............................................................................................Figura 7.3. Diagrama de cálculo de perfil.! !37 ................Figura 7.4. Diagrama de las variables que participan en el cálculo de rutas recomendadas.! !39 ............................................................................................Figura 8.1: Estructura lógica del sistema.! !43 .......................................................................Figura 8.2: Esquema de funcionamiento de MapServer.! !45 .........................................................Figura 8.3 Aspecto visual de OpenLayers en un navegador web.! !48 ............................................................Figura 8.4 Diagrama de secuencia 1: registrarse como usuario.! !49 ..............................................................................Figura 8.5 Diagrama de secuencia 2: iniciar sesión.! !50 ................................................................................Figura 8.6 Diagrama de secuencia 3: editar perfil.! !51 ..............................................................Figura 8.7 Diagrama de secuencia 4: editar datos personales.! !52 ...............Figura 8.8. Diagrama de secuencia 5: búsqueda de rutas recomendadas (usuario anónimo).! !53 ..........Figura 8.9. Diagrama de secuencia 6: búsqueda de rutas recomendadas (usuario autenticado).! !54 ...............................................Figura 8.10. Diagrama de secuencia 7: búsqueda de la ruta más corta.! !55 ............................................................................Figura 8.11. Diagrama de secuencia 8: agregar ruta.! !56 .........................................................................Figura 8.12. Diagrama de secuencia 9: descargar ruta.! !57 ............................................................................Figura 8.13. Diagrama de secuencia 10: borrar ruta.! !58 ..............................................Figura 8.14. Diagrama de secuencia 11: consultar usuarios del sistema.! !58 ....................................................Figura 8.15. Diagrama de secuencia 12: borrar usuario del sistema.! !59 ..................................................................................................Figura 10.1. Modelo de las tres capas.! !65 ........................................................................Figura 10.2. Diseño del interfaz de la página principal.! !68 ....................................................Figura 10.3. Diseño del interfaz de la página de resultado de rutas.! !69 .............................................................Figura 10.4. Diseño del interfaz de la página de presentación.! !69 .........................................................................................Figura 12.1. Estructura básica de XHTML.! !78 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!143 ............................................................................Figura 12.2. Capas de la plantilla general de la web.! !79 ............................................................Figura 12.3. Organización en directorios de la aplicación web.! !79 ...........................................................................................Figura 12.4. Esquema de la base de datos.! !81 ..................................................................................Figura 12.5. Diagrama de clases de OpenLayers.! !83 ......................................................Figura 12.6. Comunicación entre OpenLayers y UMN MapServer.! !84 .......................................................................Figura 12.7. Comunicación entre OpenLayers y la IDE.! !85 ....................................................................................................Figura 12.8. Página de presentación.! !87 ...............................................................................................................Figura 12.9. Página principal.! !87 ..........................................................................................................Figura 12.10. Buscador de rutas.! !88 .......................................................................................Figura 12.11. Página de rutas recomendadas.! !89 .................................................................Figura 12.12. Página de resultados de rutas recomendadas.! !89 ...............................................................................................Figura 12.13. Página de ruta más corta.! !90 ...........................................................Figura 12.14. Página de información de la Sierra de las Nieves.! !90 ............................................................................................Figura 12.15. Página de panel de control.! !91 .............................................................................................Figura 12.16. Página de gestión de rutas.! !91 .............................................................................................Figura 12.17. Página de edición de perfil.! !92 ...........................................................................Figura 12.18. Página de edición de datos personales.! !92 .........................................................................................................Figura 12.19. Página de contacto.! !93 ..........................................................................................................Figura 12.20. Página de registro.! !93 .................................................................................Figura 12.21. Página de panel del administrador.! !94 ..................................................................................Figura 13.1. Menú de la página de presentación.! !97 ..............................................................................................................Figura 13.2. Menú de usuario.! !97 ...............................Figura 13.3. Menú de navegación (visto desde el módulo de la página principal).! !98 ..........................................................................................................Figura 13.4. Controles del mapa.! ! 99 .................................................................................................................Figura 13.5. Tabla de rutas.! !99 ...................................................................................................Figura 13.6. Mensaje de información.! !100 ...................................................................Figura 13.7. Cuadro de calendario para seleccionar fecha.! !100 .............................................................................................Figura A-I.1. Mapa con inconexiones (I).! !126 ............................................................................................Figura A-I.2. Mapa con inconexiones (II).! !127 ..........................................................................................Figura A-I.3. Mapa con inconexiones (III).! !127 ..........................................................................................Figura A-I.4. Mapa con inconexiones (IV).! !128 _______________________________________________________________________________________________________________________________________________________________ Jose Rolland López de Coca!144