Repositorio Institucional de Documentos

UNIVERSIDAD DE ZARAGOZA Escuela de Ingeniería y Arquitectura Departamento de Informática e Ingeniería de Sistemas Proyecto de Fin de Carrera Ingeniería de Telecomunicaciones Agosto 2011 VISUALIZACIÓN Y SEGUIMIENTO VÍA WEB DE SENSORES EN MEDIOS ACUÁTICOS MEMORIA 1/2 Autor: Bárbara Pérez Felices Director: Éric Renault Télécom SudParis Ponente: Javier Nogueras Iso Escuela de Ingeniería y Arquitectura Bárbara Pérez Felices Bárbara Pérez Felices Agradecimientos En primer lugar quiero dar las gracias a Eric por brindarme la posibilidad de participar en el proyecto Mobesens y por hacerme muy grata mi segunda parte de la estancia en Télécom SudParis. En segundo lugar, a Javier por su paciencia y buenos consejos. Por último quiero agradecer a mis padres y a mi hermana el aguantarme y apoyarme incondicionalmente; a todos mis amigos por estar ahí cuando los necesito y a Mau por su positivismo y ánimos constantes. Bárbara Pérez Felices Bárbara Pérez Felices RESUMEN Este proyecto se ha desarrollado en la universidad francesa Telecom SudParis, formando parte del proyecto de la Unión Europea MOBESENS (Mobility for Long Term Water Quality Monitoring) cuyo objetivo es la creación de una infraestructura completa que permita vigilar y monitorizar una zona acuática dada, mediante sensores, con fines medioambientales. El objetivo del presente proyecto ha sido diseñar, desarrollar e implementar una aplicación de monitorización ergonómica y eficaz a fin de vigilar la actividad de los sensores y las medidas efectuadas por ellos vía web. Ofreciendo la posibilidad al operador de reaccionar frente a los problemas eventuales que puedan sobrevenir en este tipo de medio acuático. Las líneas principales de trabajo en este proyecto han sido las siguientes: - Definición de un modelo de datos que permita representar toda la información recogida por los sensores acuáticos. Como formato de intercambio de la información de los sensores se propone la utilización de XML. - Gestión y almacenamiento de los documentos XML (que guardan la información de los sensores) a través de una base de datos nativa XML que soporta xQuery como lenguaje de consulta. - Creación de un simulador que genere la información de los sensores y los almacene en la base de datos nativa. En las primeras fases del proyecto MOBESENS no se dispone todavía de todos los dispositivos físicos de los sensores, y se hace necesario simular un entorno real que permita avanzar en el desarrollo de la infraestructura. - Desarrollo de una aplicación de monitorización, mediante tecnologías web, que llevará a cabo las siguientes funciones: determinación geográfica de la posición de los sensores, así como de su movimiento en tiempo real; especificación de los valores de las medidas realizadas por los sensores; y análisis de dichas medidas mediante un sistema de creación de gráficos históricos. Para la realización del proyecto, se han utilizado las siguientes herramientas: ICEfaces y SDK Eclipse como entornos de programación para Java y aplicaciones web dinámicas; el API de Google Maps para la integración del dispositivo de localización geográfica de los sensores; el API de Google Charts para la creación del sistema de gráficos; y eXistDB y Tahoe LAFs para la gestión de la base de datos nativa. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos i Bárbara Pérez Felices Índice de contenidos Capítulo 1. Introducción.............................................................................................................................3 1.1. ALCANCE DEL PROYECTO Y MOTIVACIÓN......................................................................3 1.2. ANTECEDENTES.............................................................................................................................4 1.3. OBJETIVOS.........................................................................................................................................4 1.4. MATERIALES Y HERRAMIENTAS UTILIZADAS.................................................................6 1.5. ESTRUCTURA DE LA MEMORIA...............................................................................................7 Capítulo 2. Arquitectura del sistema..........................................................................................................8 2.1. VISIÓN GENERAL...........................................................................................................................8 2.2. SITUACIÓN INICIAL.......................................................................................................................8 2.2.1. Cliente ...........................................................................................................................................................................10 2.2.2. Servidor.........................................................................................................................................................................11 2.2.3. Base de datos................................................................................................................................................................11 2.3. SITUACIÓN FINAL ........................................................................................................................12 Capítulo 3. Base de datos nativa XML....................................................................................................14 3.1. INTRODUCCIÓN............................................................................................................................14 3.2. ESTRUCTURA ..................................................................................................................................14 3.3. FORMATO DE LA INFORMACIÓN: XML .............................................................................15 3.4. LENGUAJE DE CONSULTA .......................................................................................................17 Capítulo 4. Aplicación de la parte del servidor......................................................................................19 4.1. SIMULADOR.....................................................................................................................................19 4.2. GESTOR DE DATOS......................................................................................................................20 Capítulo 5. Descripción de la aplicación de monitorización................................................................23 5.1. MAPA Y MEDIDAS.........................................................................................................................23 5.2. GRÁFICOS.........................................................................................................................................25 Capítulo 6. Conclusiones y líneas futuras ...............................................................................................29 6.1. CONCLUSIONES.............................................................................................................................29 6.2. TRABAJOS FUTUROS....................................................................................................................30 Bibliografía ..................................................................................................................................................31 Siglas y acrónimos......................................................................................................................................33 Visualización y seguimiento vía web de sensores en medios acuáticos ii Bárbara Pérez Felices Índice de figuras Figura 1: Diagrama de la arquitectura del sistema inicial.........................................................9 Figura 2: Diagrama de la arquitectura del sistema final.........................................................13 Figura 3: Esquema de la base de datos........................................................................................15 Figura 4: Esquema del documento XML........................................................................................17 Figura 5: Diagrama de flujo de datos del simulador.................................................................19 Figura 6: Esquema explicativo del RandomWalk........................................................................20 Figura 7: Estructura de datos de los sensores............................................................................21 Figura 8: Diagrama de flujo de datos del gestor.......................................................................22 Figura 9: Mapa y cuadro de medidas.............................................................................................24 Figura 10: Comportamiento del mapa y cuadro de medidas................................................25 Figura 11: Gráfico histórico................................................................................................................26 Figura 12: Gráfico de perfil.................................................................................................................27 Figura 13: Diagrama de flujo de datos de los gráficos............................................................27 Visualización y seguimiento vía web de sensores en medios acuáticos 3 Capítulo 1. Introducción 1.1. Alcance del proyecto y motivación Los ambientes acuáticos como los ríos, los lagos o los océanos son lugares frágiles en los que una ínfima variación del medio puede tener consecuencias dramáticas sobre la fauna, la flora o los seres humanos que viven en las proximidades. Así pues, a fin de poder reaccionar eficazmente a los problemas eventuales que puedan sobrevenir en este tipo de medio acuático, la comunidad europea ha favorecido estos últimos años la financiación de diversos proyectos con el objetivo de desarrollar infraestructuras ligadas a la vigilancia y prevención de riesgos ecológicos. Es en este contexto en el que se inició el proyecto FP7 STREP MOBESENS [1]. El proyecto MOBESENS tiene como objetivo el desarrollo de una infraestructura completa que permita vigilar y monitorizar una zona acuática dada. Para ello, el proyecto debe, en particular: - Desarrollar sensores capaces de almacenar los parámetros físicoquímicos del agua (como el pH, la conductividad, la temperatura) ya sea en la superficie o en el fondo. - Determinar y gestionar la posición de dichos sensores, por una parte a fin de localizar la región en la que se aplican las medidas hechas por el sensor, y por otra parte a fin de desplazar los sensores de forma remota y poder situarlos según las necesidades en las regiones más apropiadas. - Poner en funcionamiento una red de comunicaciones sin infraestructura previa a fin de enviar las informaciones medidas por los sensores hasta el corazón del sistema. - Salvaguardar de manera permanente los datos generados por los sensores y proporcionar las herramientas que permitan acceder a dichos datos y tratarlos rápidamente. - Desarrollar una interfaz de visualización ergonómica y eficaz a fin de vigilar la actividad de los sensores y las medidas efectuadas por ellos, ofreciendo la posibilidad al operador de reaccionar retroactivamente sobre los sensores mediante la consola de visualización. En la realización del proyecto Mobesens toman parte varias empresas y universidades que trabajan en colaboración. En este marco Telecom SudParis aporta su experiencia en lo que concierne a la salvaguarda perenne y el tratamiento de la información, así como de la interfaz de visualización de los datos. El presente proyecto ha sido realizado en la universidad Telecom SudParis, dentro del departamento RS2M (Réseaux et Services Multimédia Mobiles) y ha consistido en dar los primeros pasos en la creación de la Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 10 referimos al navegador, que puede estar situado en cualquier lugar del mundo, desde el cual un usuario accede a la aplicación vía Internet. Por otra parte, tanto el servidor o aplicación del lado del servidor como la base de datos (que incluye el espacio de almacenamiento físico y la interfaz de gestión y administración) se encontrarán situados en un conjunto de equipos destinado a esa finalidad en la universidad Telecom SudParis. A continuación describimos brevemente cada una de estas tres entidades por separado y las comunicaciones que existen entre ellas. 2.2.1. Cliente En la parte del cliente tenemos la aplicación de monitorización en sí misma, de la cual hablaremos con más detalle en el Capítulo 5 de la memoria. Por ahora baste decir que está construida como una aplicación web dinámica, usando un conjunto de tecnologías que incluyen: JSP (Java Server Pages) como tecnología Java que nos permite generar contenido dinámico para web y Ajax (Asynchronous JavaScript And XML) que es una técnica de desarrollo web que nos permite realizar cambios sobre las páginas sin necesidad de recargarlas, lo cual es muy importante en este proyecto, ya que necesitamos proveer al usuario de información en tiempo real. El usuario dispone de tres herramientas principales en la aplicación de monitorización: - Un mapa del medio acuático, en el que puede localizar los sensores en cualquier instante de tiempo. Dicho mapa es creado e integrado en la aplicación por medio del API de Google Maps. - Un cuadro de medidas, en el que el usuario puede visualizar en tiempo real las medidas realizadas, así como otras informaciones proporcionadas por los sensores. Este cuadro de medidas ha sido creado mediante el marco de trabajo ICEfaces y obtiene los datos del simulador, situado en el servidor, mediante una conjunción de las tecnologías JSP y Ajax. - Un conjunto de gráficos que el usuario puede utilizar para tener una visión histórica de los parámetros del agua. Estos gráficos se crean e integran en la aplicación mediante el API de Google Charts. Los datos que nutren los gráficos son recuperados directamente de la base de datos, enviando consultas xQuery a la misma mediante el objeto XMLHttpRequest. Además está el Simulador en la parte de cliente que es desde donde se pone en marcha la simulación. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 11 2.2.2. Servidor En la parte de la aplicación correspondiente al servidor, programada en lenguaje Java, se identifican dos módulos principales: - Simulador: se trata de las clases Java que imprimen movimiento a los sensores simulando el movimiento real que tendrán éstos en el medio acuático en el que se sitúen. A su vez tiene la tarea de crear documentos XML con los datos que genera y enviarlos a la base de datos vía HTTP. - Gestor de datos: consiste en la estructura de clases Java que se va a utilizar para almacenar la información de los sensores y para proporcionársela a la aplicación web de monitorización en el cliente. Es en esta estructura donde se inicia la comunicación con la base de datos vía el servicio de mensajes de Java (JMS), configurando este extremo de la comunicación como el consumidor de los mensajes. Para poder invocar al gestor de datos y al simulador desde la aplicación de monitorización se usa una funcionalidad de la tecnología JSF, los Managed Beans. Éstos nos dan la posibilidad de trabajar con datos dinámicos en la aplicación web, ya que podemos acceder a los atributos y métodos de las clases Java así definidas desde nuestras páginas JSPX. Además de los módulos pertenecientes a la aplicación propiamente dicha, en la Figura 1 podemos observar otra entidad que ha de estar corriendo para que la aplicación funcione. Se trata del ActiveMQ que es el proveedor del servicio de mensajes Java (JMS), que utilizamos para que la base de datos envíe los documentos XML que contienen la información de los sensores en cuanto los recibe del simulador. Una instancia de ActiveMQ ha de estar corriendo tanto en el servidor como en la base de datos (si se encuentran en equipos diferentes) para que la aplicación funcione correctamente. El servidor en el que corre la aplicación es Apache Tomcat, se trata de un servidor web que tiene soporte para servlets y JSPs. Esto entre otras características y cualidades lo hacen propicio para ser usado en el proyecto. 2.2.3. Base de datos Como sistema de almacenamiento para los datos del proyecto Mobesens se utiliza una base de datos nativa XML, la interfaz de comunicación con esta base de datos ha sido creada en el departamento RS2M de la universidad Telecom SudParis, ha sido programada en el lenguaje Java y se le ha dado el nombre de NetInf. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 12 NetInf hace uso de la herramienta eXistDB, que facilita la gestión y administración de bases de datos nativas XML; asimismo se utiliza un sistema de almacenamiento en nube (cloud), que proporciona privacidad y seguridad en la distribución de la información hacia múltiples servidores, llamado Tahoe- LAFS. Además NetInf toma parte en la comunicación JMS de la que hemos hablado entre servidor y base de datos, en la que se configura como el extremo Publicador de la comunicación. Información más detallada sobre el funcionamiento de la base de datos se encuentra en el Capítulo 3 de la memoria. 2.3. Situación final En la fase final del proyecto, habrá varios cambios en lo que se refiere a la arquitectura del sistema. Principalmente en las partes del servidor y de la base de datos. En la Figura 2, tenemos un diagrama de la arquitectura de la aplicación en lo que sería la fase final del proyecto Mobesens. En ella podemos observar las diferencias con respecto al esquema anterior. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 13 Figura 2: Diagrama de la arquitectura del sistema final Dado que en ese momento del proyecto ya estarán situados los sensores en el medio acuático a monitorizar, aparece un nuevo componente al que llamamos Sensores, que se refiere a la información que estos envían a través de la red de comunicaciones hasta la base de datos. Con este nuevo componente no serán necesarios, por tanto, ni el módulo del simulador presente en el servidor ni su comunicación vía HTTP con la base de datos, ni el módulo del simulador en la parte del cliente. El resto de bloques de la estructura del sistema se mantendrán iguales a no ser que en el desarrollo de las últimas fases del proyecto sea necesario cambiar algo o hacer algún añadido. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 14 Capítulo 3. Base de datos nativa XML 3.1. Introducción Uno de los objetivos clave en el proyecto Mobesens es la integración del mismo con futuros trabajos o proyectos de la Unión Europea en el ámbito de vigilancia y prevención de riesgos ecológicos. En especial se desea que el sistema de almacenamiento de la información sea lo más genérico y escalable posible para que futuros proyectos puedan hacer uso del mismo. En vista de esto, queda claro que una base de datos relacional no es una buena elección, ya que su estructura tabular dificulta que una expansión sea llevada a cabo de manera sencilla. Se pensó por tanto en otro tipo de base de datos, llamada base de datos nativa XML, que brinda la escalabilidad y potencia necesarias para el proyecto Mobesens. La característica principal de una base de datos nativa, es que no almacena datos como tales, sino documentos enteros en formato XML o cualquier tipo de documento en otro formato que pueda ser convertido a XML. Además nos permite el procesamiento de los datos contenidos en los documentos XML (aunque de una forma quizá más complicada de lo que nos resultaría en una base de datos relacional, dado que la información en los documentos XML tiene una estructura jerárquica); así como el almacenamiento y posterior recuperación de la información y obviamente la posibilidad de realizar búsquedas en la base de datos, mediante un lenguaje de consulta. 3.2. Estructura Como podemos ver en el esquema de la base de datos de la Figura 3, NetInf es toda una aplicación que se ocupa de gestionar la base de datos, aislando a los usuarios del funcionamiento interno de la misma. Consta de una interfaz de comunicación en desarrollo, mediante la cual se podrá realizar la carga y recuperación de documentos y otras múltiples acciones sobre los datos almacenados. Además NetInf crea lo que llamamos espacio de indexación. Es una parte fundamental de la base de datos, ya que nos permite la elaboración de un índice que contenga la información de forma ordenada, de tal manera que las búsquedas en la base de datos se realicen más rápida y eficientemente y obtengamos los resultados en menos tiempo. Lo que en nuestro caso es muy importante, dado que la aplicación web cuenta con funcionalidades en tiempo real que se nutren de la información contenida en la base de datos y por tanto un sencillo y rápido acceso a ellos es crucial. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 15 Tahoe Cluster NetInf eXist-DB Figura 3: Esquema de la base de datos Como espacio físico de almacenamiento de los datos, se usa un “cluster” o conjunto de ordenadores conectados en red que ha sido construido en la universidad Telecom SudParis. Para la gestión y administración de dicho cluster se hace uso de un sistema de almacenamiento en nube, abierto y gratuito, llamado Tahoe-LAFS [2]. Este sistema distribuye los datos a través de múltiples servidores, de tal forma que en caso de que los servidores fallen o sean víctima de un ataque, el sistema de ficheros al completo continúe funcionando correctamente. Además preserva la seguridad y privacidad de los datos. Para la gestión de la base de datos, se cuenta con eXist-DB [3]. Se trata de una herramienta de administración de bases de datos open source, que hace uso de la tecnología XML y utiliza como lenguaje de consulta xQuery. Además soporta muchas tecnologías web, que le convierten en el entorno idóneo para el desarrollo de aplicaciones web, como la que se ha desarrollado en este PFC. 3.3. Formato de la información: XML La información almacenada en nuestra base de datos, estará disponible en formato XML. XML es en realidad un metalenguaje extensible de etiquetas desarrollado por el W3C, que nos permite el intercambio de información estructurada entre diferentes plataformas. Esto nos viene muy bien, dada nuestra futura necesidad de integrar diferentes proyectos. Para ello XML intenta estructurar la información de la manera más abstracta y reutilizable posible. Esto no quita para que todo documento XML deba estar “bien formado”, es decir, que cumpla con todas las definiciones básicas y reglas de formato y así Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 16 pueda ser correctamente analizado por cualquier analizador sintáctico (parser) que cumpla la norma. A la hora de estructurar y dar forma a los documentos XML que almacenan la información de los sensores, se han tenido en cuenta los estándares del OGC (Open GeoSpatial Consortium) [4]. Se trata de un consorcio de empresas, agencias gubernamentales y universidades; que desarrolla en consenso todo tipo de estándares abiertos e interoperables en el marco de los sistemas de información geográfica y de la worl wide web. En concreto el esquema de los documentos XML que contienen la información de los sensores está basado y sigue las especificaciones de los estándares OM (Observations and Measurements) [5] y SWE (Sensor Web Enablement) Common Data Model [6], que nos proporcionan modelos de documentos para el intercambio de información sobre las observaciones y sus resultados; así como para el intercambio de datos relacionados con sensores. De esta forma diferentes aplicaciones y/o servidores pueden estructurar, codificar y transmitir conjuntos de datos de los sensores de una manera autodescriptiva y permitida semánticamente. En la Figura 4 podemos observar una muestra de la estructura y forma del documento XML definido a lo largo del proyecto. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 17 Figura 4: Esquema del documento XML Hay que decir que, en su momento, se planteó la opción de utilizar también el formato JSON (JavaScript Object Notation). JSON es un formato ligero para el intercambio de datos cuyo uso se ha generalizado debido a que resulta una alternativa muy atractiva a XML en el uso de la tecnología Ajax. Para nosotros resultaba una opción atrayente dado que hacemos uso de dicha tecnología y sobretodo porque es el formato que usa Google en su Google Charts API y nosotros nos servimos de dicha aplicación a la hora de crear los gráficos. En cualquier caso esta opción no queda descartada y se podría incorporar en cualquier momento, ya que en la base de datos se pueden almacenar documentos que no sean de tipo XML. 3.4. Lenguaje de consulta Dado que eXist-DB utiliza como lenguaje de consulta para interrogar a la base de datos xQuery[3], es este lenguaje el que hemos aprendido a manejar y usado a lo largo del proyecto para recuperar los datos necesarios para la aplicación web. xQuery nos proporciona los medios para extraer y manipular información de documentos XML. Se trata de un lenguaje de consulta muy completo, ya que incluye algunas capacidades de programación como la creación de funciones propias del usuario (también tiene funciones predefinidas) que pueden ser muy útiles; y utiliza expresiones XPath que nos permiten buscar y seleccionar datos teniendo en cuenta la estructura jerárquica de los documentos XML, así como unas expresiones parecidas a las usadas en SQL, conocidas como expresiones Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 18 FLWOR. Estas expresiones toman su nombre de los 5 tipos de sentencias de las que pueden estar compuestas: FOR, LET, WHERE, ORDER BY y RETURN. Además, xQuery nos permite construir o reconstruir nuevos documentos XML a partir de los resultados de la consulta. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 19 Capítulo 4. Aplicación de la parte del servidor En este capítulo de la memoria vamos a describir más detalladamente la arquitectura de la aplicación, en lo que se refiere a la parte del servidor. Como ya hemos comentado en el Capítulo 2, tenemos dos módulos principales: el Simulador y el Gestor de Datos ambos programados en lenguaje Java [7]. A continuación vamos a explicar las distintas funciones y tareas que llevan a cabo cada uno de ellos. 4.1. Simulador A pesar de que a la finalización del proyecto Mobesens, no formará parte de la aplicación web, el simulador es en estos momentos una de las partes fundamentales del proyecto. Como su nombre indica, realiza una simulación, en la que crea un cierto número de sensores, les asigna unas medidas y hace que esos sensores se muevan por la superficie del lago (en lo que llamamos “paseo”) y modifica los valores de las medidas. De esta manera, a efectos de la visualización, tenemos un sistema real, en el que podemos observar los sensores, ver como se mueven por el mapa y acceder a las medidas que realizan. En la Figura 5, se observa el diagrama de flujo de datos del simulador, que explicamos a continuación: CREACIÓN DE LOS SENSORES INICIO FIN CALCULO NUEVA POSICIÓN Y MEDIDAS CREACIÓN DOCUMENTO XML ENVIO DEL DOCUMENTO A NETINF STOP? SI NO 2 3 1 4 5 6 Figura 5: Diagrama de flujo de datos del simulador 1º. El simulador se pone en marcha mediante un botón en la aplicación de monitorización que dispara un evento manejado desde las clases java. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 26 AnnotatedTimeLine que nos permite realizar un gráfico interactivo, en el que aparecerán una serie de líneas (cada una de estas líneas representará una medida diferente del sensor) dibujadas en función del tiempo. El término interactivo se usa en referencia a una serie de propiedades que tiene este tipo de gráfico que permiten al usuario realizar ciertas acciones que aumentan la usabilidad del mismo, estas acciones incluyen la posibilidad de hacer zoom in y zoom out en el gráfico (puede ser de mucha utilidad cuando los gráficos históricos abarcan largos períodos de tiempo) y la visualización de los datos concretos del gráfico dependiendo de donde se encuentre situado el puntero del ratón del usuario, lo que nos permite obtener información exacta de las medidas en cualquier instante concreto del intervalo de tiempo representado. En la Figura 11 podemos ver la parte de la aplicación de visualización correspondiente a los gráficos históricos. Figura 11: Gráfico histórico Por otra parte, el gráfico de perfil es muy parecido al gráfico histórico, se trata de representar las medidas que realizan los sensores en función de la profundidad a la que han sido hechas, en vez de en función del tiempo como en el gráfico histórico. Para su creación e integración en la aplicación se ha utilizado la visualización scatterChart del API de Google Charts. En la Figura 12, se presenta la parte de la aplicación correspondiente a los gráficos de perfil. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 27 Figura 12: Gráfico de perfil El proceso de creación de los gráficos es el mismo para los dos tipos, lo vemos ilustrado en la Figura 13 y lo detallamos a continuación: Figura 13: Diagrama de flujo de datos de los gráficos Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 28 1º. En la carga inicial de la página sólo podemos ver los menús mediante los que el usuario decide que parámetros quiere ver en el gráfico y un botón para dibujarlos una vez dichos parámetros hayan sido seleccionados. 2º y 3º. Se validan los parámetros seleccionados y se envía la consulta xQuery a la base de datos en función de ellos mediante el objeto XMLHttpRequest [11](forma básica de la tecnología Ajax). 4º y 5º. Se espera a que llegue la respuesta de la base de datos para construir el gráfico y cargarlo en la página. Esto se hace así porque si se intentara cargar el gráfico antes de tener los datos habría un error y no se cargaría el gráfico. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 29 Capítulo 6. Conclusiones y líneas futuras 6.1. Conclusiones A lo largo de este proyecto se ha desarrollado la primera fase de una aplicación web para la visualización y seguimiento de sensores en medios acuáticos. En esta primera fase, se han creado las partes principales que constituirán la aplicación web final y que incluyen: ● Un gestor de datos que forma parte de la aplicación del lado del servidor y que contiene una estructura de datos creada mediante clases Java para describir la información de los sensores y que hace de puente entre la base de datos y la aplicación de la parte del cliente. ● Un simulador programado en Java que suple la carencia, en esta primera fase del proyecto Mobesens, de datos reales para mostrar en la aplicación de monitorización. ● Un mapa, realizado mediante el API de Google Maps, de la zona donde están situados los sensores, sobre el que se visualizan dichos sensores y en el que se ve reflejado el movimiento de éstos en tiempo real. Incluyendo algunas funcionalidades como aumentar o disminuir la resolución del mapa, o la visualización de las medidas realizadas por los sensores mediante ventanas de información que se activan al hacer click sobre cualquiera de los sensores. ● Un cuadro de medidas, realizado mediante el marco de trabajo ICEfaces, en el que se visualizan en tiempo real todos los parámetros del agua medidos por sensores; así como información del propio sensor, como son su identificador y su tipo. ● Una serie de gráficos, realizados mediante el API de Google Charts, que nos permitirán representar las medidas de los sensores en función del tiempo (gráficos históricos) y en función de la profundidad a la que han sido realizadas dichas medidas (gráficos de perfil). Esta aplicación web va a resultar muy útil para la monitorización y visualización de sensores en medios acuáticos en general y en particular dentro del marco del proyecto Mobesens. Permitirá a los usuarios disponer de una interfaz de fácil manejo y alta usabilidad para el estudio de medios acuáticos, ya sea para fines medioambientales o para otros fines. Como experiencia profesional, este proyecto me ha enseñado las distintas fases de desarrollo que tiene un proyecto tan grande como es Mobesens, así como las dificultades que entraña coordinar a distintos grupos de gente que trabajan en paralelo. También me llevo conmigo muchos conocimientos técnicos que he ido aprendiendo en su realización: distintos lenguajes de programación que antes no conocía, conocimientos sobre bases de datos y manejo de algunas herramientas y entornos de trabajo. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 30 Como experiencia personal, me ha servido sobretodo para aprender a resolver problemas sin la ayuda de nadie y a ser un poco autodidacta, pero también a trabajar en equipo. 6.2. Trabajos futuros Dado que este proyecto sólo abarca la primera fase de la creación de la aplicación web, hay varias líneas de trabajo que se pueden seguir para mejorarla: ● Construcción de sistemas de filtrado de información para el mapa y el cuadro de medidas, de tal manera que el usuario pueda decidir que datos visualizar. ● Ampliación de los gráficos con un gráfico tipo isobárico, que nos permita ver en un mapa zonas con distintos colores representando distintos valores de una misma medida. ● Implementación de gráficos en tiempo real tanto para la modalidad de gráfico histórico como para la de gráficos de perfil. ● Realizar un diseño personalizado de la aplicación para cada usuario de manera que aumente la usabilidad de la aplicación web. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 31 Bibliografía [1] “Portal Web del proyecto MOBESENS (Mobility for Long Term Water Quality Monitoring)”. http://www.mobesens.eu/ (Última actualización: Agosto 2011). [2] “Portal Web del proyecto Tahoe-LAFS”. http://tahoe-lafs.org (Última actualización: Agosto 2011). [3] Wolfang M.Meier, 2009. “Exist, Open Source Native XML Database Documentation”. http://exist.sourceforge.net/documentation.html (Último acceso: Agosto 2011). [4] “Portal Web del Open Geospatial Consortium”. http://www.opengeospatial.org/standards (Última actualización: Marzo 2011). [5] Simon Cox. “Observations and Measurements-XML Implementation”. http://www.opengeospatial.org/standards/om Marzo 2011. [6] Alexandre Robin. “SWE Common Data Model Encoding Standard”. http://www.opengeospatial.org/standards/swecommon . Enero 2011. [7] Javier Nogueras Iso. Apuntes de la asignatura “Ampliación de Informática”. Centro Politécnico Superior (2009). [8] Google,2010. “API de Google Maps”. http://code.google.com/intl/es- ES/apis/maps/documentation/javascript/v2/introduction.html (Último acceso: Agosto 2011). [9] ICEsoft Technologies, 2011. “ICEfaces 2 Docummentation”. http://wiki.icefaces.org/display/ICE/ICEfaces+2+Documentation (Último acceso: Agosto 2011). [10] Google, 2011. “Google Chart Tools”. http://code.google.com/intl/es- ES/apis/chart/interactive/docs/reference.html (Último acceso: Agosto 2011). [11] “Tutorial sobre XMLHttpRequest”. http://www.toutjavascript.com/savoir/xmlhttprequest.php3 (Último acceso: Agosto 2011). [12] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Hedí y William Lorensen, 1996. “Modelado y diseño orientados a objetos, Metodología OMT”. Prentice Hall. [13] James Rumbaugh, Ivar Jacobson, Grady Booch. “El lenguaje unificado de modelado. Manual de referencia”. Adisson Wesley (1999). [14] Google, 2011. “Gmaps4jsf: The complete integration of Google Maps with the Java Server Faces”. http://code.google.com/p/gmaps4jsf/ (Último acceso: Agosto 2011). [15] “Manuales de desarrollo web y programación”. http://www.desarrolloweb.com/manuales/ (Último acceso: Agosto 2011). [16] “Introducción a JMS (Java Message Service)”. Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 32 http://www.programacion.com/articulo/introduccion_a_jms_java_messa ge_service_142 (Último acceso: Agosto 2011). Bárbara Pérez Felices Visualización y seguimiento vía web de sensores en medios acuáticos 33 Bárbara Pérez Felices Siglas y acrónimos AJAX: Asynchronous Javascript And XML API: Application Programming Interface DOM: Document Object Model HTML: HyperText Markup Language HTTP: HyperText Transfer Protocol JMS: Java Message Service JSF : Java Sever Faces JSON: JavaScript Object Notation JSP: Java Server Pages OGC: Open Geospatial Consortium OM: Observations and Measurements OMT: Object Modeling Technique PFC: Proyecto Fin de Carrera RF: Requerimiento Funcional RIA: Rich Internet Application RNF: Requerimiento No Funcional RS2M: Réseaux et Services Multimédia Mobiles SQL: Structured Query Language SWE: Sensor Web Enablement UML: Unified Modeling Language URL: Uniform Resource Locator W3C: World Wide Web Consortium XML: Extensible Markup Language