TRABAJO FIN DE GRADO. Web Application for Device Cloud Explorer

Transcripción

1 TRABAJO FIN DE GRADO Título Web Application for Device Cloud Explorer Autor/es Alejandro Vaquero Blanco Director/es Juan José Olarte Larrea Facultad Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación Grado en Ingeniería Informática Departamento Curso Académico

2 Web Application for Device Cloud Explorer, trabajo fin de grado de Alejandro Vaquero Blanco, dirigido por Juan José Olarte Larrea (publicado por la Universidad de La Rioja), se difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright. El autor Universidad de La Rioja, Servicio de Publicaciones, 2014 publicaciones.unirioja.es publicaciones@unirioja.es

3 Facultad Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación Grado en Ingeniería Informática Título Web application for Device Cloud Explorer Autor/es Alejandro Vaquero Blanco Tutor/es Juan José Olarte Larrea Departamento Matemáticas y Computación Curso académico

4 Resumen Vivimos en un mundo en el que cada vez más Internet se encuentra en todo aquello que nos rodea. Es lo que conocemos como Internet of Everything. El objetivo de Digi International es vincular cualquier tipo de dispositivo cotidiano a la red de redes, pudiendo tener en todo momento un control directo sobre él. Esto resulta especialmente útil a las empresas, las cuales pueden monitorizar de forma completa, por ejemplo, una flota de camiones o el estado de un silo. El objetivo de este proyecto es poder acercar las soluciones de Digi International a las empresas de forma barata y sencilla. Se trata un sistema de simulación de dispositivos conectados a la nube, a través del cual cualquier persona pueda experimentar su funcionamiento sin necesidad de adquirir previamente un sistema embebido. Palabras clave: Internet of Everything, monitorizar, sistema embebido. Abstract We live in a world where increasingly Internet is in everything around us. It s what we know as Internet of Everything. The goal of Digi International is to link up any everyday device to the wide web, being able to have direct control over it in at all times. This is especially useful for companies, who can monitor completely, for example, a fleet of trucks or the state of a silo. The goal of the project is to be able to bring the Digi International solutions to the companies cheaply and easily. It consists in a simulation system of devices connected to the cloud, through which everyone will be able to experiment its behavior without purchasing previously an embedded system. Keywords: Internet of Everything, monitor, embedded system. 2

5 Tabla de contenido Capítulo 1. Introducción Antecedentes Objetivos Planificación Seguimiento del proyecto Capítulo 2. Desarrollo Análisis Identificación de los usuarios participantes Catálogo de requisitos del sistema Casos de uso Diseño Diseño de la interfaz de usuario Diagrama de navegación Arquitectura del sistema Almacenamiento de datos Patrones de diseño Diseño de clases Diseño del plan de pruebas Implementación Tecnologías usadas Recursos externos Estructura del proyecto Desarrollo de la aplicación FASE 1: Vistas de detalles FASE 2: Notificaciones FASE 3: Página de entrada (entry point) FASE 4: Mejoras FASE 5: Guía de usuario Pruebas

6 Capítulo 3: Conclusiones Evaluación de objetivos Problemas planteados y resolución Conocimientos adquiridos Mejoras del proyecto Capítulo 4. Bibliografía

7 Índice de figuras Figura 1. Esquema básico del sistema... 7 Figura 2. Tareas creadas vs tareas completadas en JIRA Figura 3. Diagrama de casos de uso Figura 4. Diagrama de actividad del caso de uso [Petición SCI] Figura 5. Prototipo de la vista general de dispositivos Figura 6. Vista general de dispositivos Figura 8. Vista de detalles Figura 9. Diagrama de navegación de la aplicación Figura 10. Esquema del patrón MVC Figura 11. Diagrama de clases del modelo de dispositivos Figura 12. Diagrama del modelo de eventos Figura 13. Tecnologías web en aplicaciones modernas Figura 14. Contenido de la carpeta /src Figura 15. Contenido de la carpeta /war Figura 16. Botón de peticiones SCI

8 Capítulo 1. Introducción Esta memoria recoge en detalle los aspectos más importantes del trabajo realizado por Alejandro Vaquero como Proyecto de Fin de Grado, titulado Web Application for Device Cloud Explorer y realizado para Digi Internation Span S.A.U. Tras su conclusión fue puesto en funcionamiento con éxito, siendo accesible desde Antecedentes ACERCA DE DIGI Digi International es una empresa norteamericana que ofrece productos y servicios M2M (máquina a máquina) para la gestión de las empresas. Su principal vía de desarrollo es el hardware, diseñando sistemas embebidos que se conecten a Internet y permitan el acceso al estado de los dispositivos de forma remota. El verdadero potencial de Digi reside en su nube para la gestión de redes de dispositivos, Etherios Device Cloud. Los dispositivos quedan vinculados de forma que podemos acceder a sus características e incluso operar en ellos a través de órdenes desde la misma nube. Disponemos de mensajería segura entre aplicaciones, almacenamiento de datos y gestión de dispositivos para redes cableadas y dispositivos celulares. Una red de dispositivos permite que sistemas cableados o inalámbricos se comuniquen con otros dispositivos o aplicaciones a través de diferentes tipos de red. Esto nos permite, por ejemplo, monitorizar las características de un dispositivo y detectar cambios a través de sensores. Cuando un evento se produce, se envía a través de una red a una aplicación, la cual podrá interpretar el mismo como información útil (un aviso, cambiar el estado de un widget, etc.). MOTIVACIÓN Una vez explicadas las características principales de Digi debemos entender la razón por la cual se plantea el siguiente proyecto. Digi International es una empresa multinacional que ofrece servicios a otras empresas, a las cuales debe convencer de que sus soluciones son las adecuadas a su modelo de negocio. Sin embargo no dispone de ningún sistema que les permita mostrar de forma barata el funcionamiento de sus dispositivos y su nube. La única alternativa posible es que potenciales clientes se acerquen a sus sedes para probarlos in situ. Esto no es cómodo ni rentable, tanto para Digi como para los clientes. A mediados del mes de noviembre, durante la realización de las prácticas, la empresa propuso al proyectante la realización de un sistema de simulación de dispositivos conectados a la nube, de modo que sus clientes pudieran experimentar con el uso de la nube directamente desde sus equipos, sin 6

9 necesidad de manipular el hardware de Digi. Dado que el sistema completo abarcaba una cantidad de trabajo inviable para una sola persona, se decide dividirlo en dos secciones. Por una parte, una aplicación de escritorio que se encargaría de crear los dispositivos simulados y manipularlos. Esta parte quedaría a cargo de Jesús Nieto Cuartero. Por otra parte, se debía realizar una aplicación web que sirviera como punto de monitorización de la aplicación de escritorio, además de ofrecer ciertas operaciones sobre los dispositivos. Al haberse ocupado parte del periodo de prácticas en el desarrollo web, el proyectante se decantó por esta opción. Esto incluye el desarrollo de un pequeño portal que sirva como punto de entrada al sistema y contenga los manuales de las dos partes. El proyecto se comenzó a realizar desde ese mismo momento, ocupando aproximadamente mes y medio del periodo de prácticas. Su duración se extendería hasta la conclusión del Trabajo de Fin de Grado. Durante el periodo de prácticas, el proyectante se ocupó de la definición de los requisitos del sistema, así como de un análisis y diseño general del mismo. Además, se realizaron las vistas.jsp necesarias para la aplicación e implementaron algunos servlet de funcionamiento básico: login; actualización de dispositivos y su carga en vistas; javascript de la vista principal para la visualización de dispositivos en el mapa. FUNCIONAMIENTO Inicialmente, el usuario creará una sesión en la aplicación de escritorio, permitiéndole generar dispositivos simulados que quedarán automáticamente conectados a Etherios Device Cloud (se pueden desconectar a petición del usuario). Estos dispositivos, en una primera versión del sistema, serán un tanque y un camión. El usuario podrá manipular su estado de diversas formas, en función de las posibilidades que le ofrezca el dispositivo. La aplicación enviará de forma continua los posibles cambios que registre a la nube de dispositivos, quedando toda la actividad almacenada en la misma. Por su parte, el usuario podrá acceder a la aplicación web por medio de sus credenciales para tener una visión completa del estado de su sesión en la aplicación de escritorio. La aplicación reflejará en tiempo real el estado de los dispositivos. Además, le permitirá realizar ciertas acciones sobre ellos, como actualizaciones de firmware, accesos al log de incidencias o envío de peticiones (por ejemplo, desconexión). Figura 1. Esquema básico del sistema 7

10 1.2. Objetivos El objetivo principal del proyecto es el desarrollo de un sistema completo y sencillo de utilizar que permita la exploración de Etherios Device Cloud. Con ello, la empresa Digi podrá mostrar sus servicios a sus potenciales clientes de forma cómoda y gratuita. Además, entre otros objetivos relativos al sistema global: Creación de dos subsistemas componentes del sistema global: una aplicación de escritorio que cree dispositivos simulados y una aplicación web que se encargue de su monitorización. Conseguir una comunicación completa bidireccional entre las dos plataformas (Escritorio y Web), ya sea de forma directa o a través de Etherios Device Cloud. Testeo del sistema para la corrección de posibles errores, tanto por parte de los dos alumnos como por personal de la empresa Digi. En cuanto a los objetivos concretos de la parte web: Realizar una monitorización correcta de los dispositivos simulados por la aplicación de escritorio. Del mismo modo, ser capaz de diferenciar entre dispositivos simulados y otros dispositivos reales contenidos en la nube del usuario. Desarrollar una serie de animaciones que permitan ver al usuario de forma intuitiva el estado de los dispositivos. Enviar peticiones a los dispositivos. Crear un punto de entrada a los usuarios desde el que puedan descargar la aplicación de escritorio, acceder a la aplicación web y ver los manuales de uso Planificación Hay que tener en cuenta que la planificación viene sujeta al trabajo realizado anteriormente, como ya se ha explicado en la sección Antecedentes. Por lo tanto, las horas planificadas correspondientes al Trabajo de Fin de Grado se corresponden en gran medida con la parte de implementación. Concretamente, la fecha de inicio del mismo es el 3 de febrero de Se acuerda seguir la metodología ágil Scrum para realizar el correcto seguimiento del desarrollo del proyecto, realizando sprints de dos semanas de duración. Scrum es un proceso iterativo e incremental, que se centra en el desarrollo del software dejando un poco más de lado la documentación. Nos permite obtener pronto versiones parciales del producto. Esto es especialmente útil en entornos cambiantes o poco definidos. 8

11 Para el caso que nos compete esta metodología se adapta muy bien, puesto que las fases de análisis y diseño estaban ya previamente realizadas prácticamente en su totalidad, pudiendo centrar la mayor parte de los esfuerzos en la implementación del software. Los roles para el proyecto son los siguientes: ScrumMaster (director del proyecto): Rubén Moral (desarrollador en Digi). ProductOwner (dueño del producto): Pedro Pérez (responsable de Digi International Spain). Team (equipo de trabajo): Jesús Nieto y Alejandro Vaquero. La descomposición de tareas del proyecto es la siguiente: Tarea Corrección de bug en Google App Engine Peticiones RCI Animaciones SSL Descripción Testeo del estado actual de la aplicación para solucionar un bug en GAE que lanza errores en los.jsp. En caso de no encontrar solución, buscar servidores alternativos. Realización de peticiones a los dispositivos vía RCI. Mostrar los cambios en el dispositivo mediante animaciones. Establecer conexiones seguras en la aplicación. Tiempo estimado (h) Eventos recientes Gestión de conexiones Gestión de errores Modificación del plugin para la vista en tabla Corrección de bugs en la vista de mosaico Notificaciones de cambios recientes en dispositivos. Implementar distintos comportamientos de la aplicación en función de la conectividad de la aplicación de escritorio. 15 Establecer comportamientos adecuados de la aplicación ante la aparición de errores. 5 Cambios en el plugin JQuery de la tabla para evitar fallos en la visualización tras modificaciones de filas mediante javascript. 15 Modificación del CSS y Javascript del plugin de "scroll" para solucionar pequeños fallos de visualización en determinadas circunstancias Testeo Documentación Punto de entrada Manual de usuario Pruebas de errores en la aplicación y correcciones. Documentación del código. Punto de entrada a las aplicaciones. Elaboración de un manual de uso de la aplicación web TOTAL 199 9

12 A estas horas hay que sumar: Planificación del proyecto (20 horas): o Definición de las tareas a realizar del proyecto y su extensión. Análisis (7 horas): o Verificación de la documentación y diagramas de casos de uso, funcionalidades y navegabilidad. Diseño (4 horas): o Comprobación de los aspectos de diseño, diagramas y prototipos de interfaces. Reuniones (20 horas): o Tiempo dedicado a reuniones. En él se engloban tanto aquellas necesarias para el seguimiento de la metodología Scrum como las realizadas con el director del proyecto. Memoria (50 horas): o Redacción de la memoria del proyecto. Total de horas del proyecto: Seguimiento del proyecto Para el correcto seguimiento del proyecto se ha utilizado el software JIRA. Es una aplicación web para el seguimiento de las tareas, incidencias y posibles errores que surjan. En definitiva, para la gestión operativa de proyectos. Permite el uso de la metodología Scrum, mencionada anteriormente, por lo que encaja con las necesidades del proyecto. Las primeras semanas se dedican a la planificación del proyecto. Esto es, la definición de la pila del producto y las tareas seleccionadas para cada sprint. Además, por recomendación del ScrumMaster y del director del proyecto se comienza con la redacción de aquellas partes de la memoria para las que ya existe trabajo avanzado (Introducción, análisis y diseño). A partir del día 24 de febrero comienza la fase de implementación. Se detallan seguidamente los progresos realizados en cada sprint: Primer sprint ( ) 30 horas o Actualización continua del estado de camiones y tanques en sus detalles. o Envío de órdenes desde los detalles a el dispositivo: Abrir/cerrar válvulas en el caso de un tanque. Detención temporal, apertura/cierre de puerta en un camión. o Desconexión de un dispositivo en su vista de detalles. o Visualización del archivo de configuración y log de eventos de un dispositivo. o Primera versión de petición de actualización de firmware. 10

13 o Animaciones: Nivel de un tanque y estado de las válvulas de un tanque. Velocímetro, estado de la puerta y ruta en el mapa de un camión. Segundo sprint ( ) 40 horas o Finalización de las animaciones en las vistas de detalles. o Corrección del bug en Google App Engine. o Implementación del protocolo SSL en toda la aplicación. o Creación de excepciones. o Notificaciones de cambios recientes en dispositivos. Tercer sprint ( ) 30 horas o Inclusión de gráficas en los detalles de los dispositivos. o Subida de archivos binarios para la actualización de firmware. o Creación de una página de error con mensajes personalizados en función de la situación. o Adaptación de las hojas CSS para conseguir un diseño adaptable a todas las resoluciones. o Testeo y corrección de errores en las notificaciones. Cuarto sprint ( ) 35 horas o Mejoras en las gráficas históricas para mostrar los datos en periodos de tiempo (última hora, último día, última semana, histórico completo). o Arreglo de problemas de visualización en el mosaico y la tabla de la vista general. o Reorganización del código javascript en archivos separados y generalización de algunos métodos en las vistas de detalles para evitar la redundancia de código. o Documentación del código java y javascript. o Implementación de alertas no intrusivas en la vista general. Se trata de informar al usuario de los posibles errores producidos durante una actualización vía AJAX evitando que interrumpan sus acciones. o Corrección de pequeños errores y adición de características que mejoran la experiencia del usuario con la web. Quinto sprint ( ) 25 horas o Implementación de alertas no intrusivas en las vistas de detalles de un dispositivo, del mismo modo que las añadidas en la vista general. o Añadidos contadores para las actualizaciones AJAX. Informan al usuario del tiempo que queda para que se produzca la próxima actualización. o Elección entre varias sesiones de la aplicación de escritorio. El usuario puede alternar entre las distintas sesiones que ha creado (aunque sólo una puede estar activa). Se dispone de un checkbox que actúa como filtro de dispositivos (permite decidir si visualizar todos los dispositivos de la cuenta o sólo los de la sesión). La lista de sesiones 11

14 o o o se actualiza automáticamente cada vez que el usuario entra en el diálogo correspondiente. Cuadro de notificaciones sustituido por iconos, de forma que resulta más intuitivo al usuario. Creación del punto de entrada del sistema. Permite acceder a la descarga de la aplicación de escritorio, a la aplicación web y a la guía de usuario. Otras pequeñas correcciones gráficas y de errores. Sexto sprint ( ) 25 horas o Depuración de pequeños errores o Testeo general de la aplicación: Pruebas unitarias. Pruebas de integración del sistema completo. Elaboración del manual de usuario: 10 horas La siguiente imagen refleja una comparativa entre las tareas creadas en JIRA y el momento en el que se fueron completando. Hay que tener en cuenta que Jira devuelve una gráfica con todas las tareas creadas para el proyecto, por lo que en este caso aparece el volumen de tareas correspondiente a los dos miembros del equipo de trabajo. Como puede apreciarse, un gran volumen de tareas fue incluido al inicio de proyecto, añadiéndose otras secundarias conforme se avanzaba en la implementación (aparición de errores, mejoras, etc.). Figura 2. Tareas creadas vs tareas completadas en JIRA 12

15 Se puede afirmar que las estimaciones iniciales fueron bastante acertadas una vez concluido el proyecto. En general, el proyectante realizó con cierto adelanto sobre la estimación la implementación, mientras que en los demás aspectos los tiempos fueron algo superiores. En total, una desviación algo superior al 3%. Tarea Horas estimadas Horas reales Desviación Planificación horas Análisis horas Diseño horas Reuniones horas Implementación horas Memoria horas TOTAL horas 13

16 Capítulo 2. Desarrollo 2.1. Análisis En el siguiente apartado se incluye toda la documentación relativa al análisis realizado para la correcta definición del sistema a desarrollar. Previamente se expondrán los usuarios participantes y algunas definiciones necesarias para la correcta comprensión de las funcionalidades. Más adelante, se mostrará una definición de requisitos lo más exhaustiva posible, dando paso finalmente a los casos de uso del sistema Identificación de los usuarios participantes A pesar de la complejidad del sistema, la idea del mismo es que sea usado por un solo tipo de agente, en este caso los usuarios del simulador. Es decir, en ningún momento existe otra persona con la que el usuario pueda o necesite comunicarse Catálogo de requisitos del sistema i. Definiciones, acrónimos y abreviaturas Dispositivo simulado Representación abstracta de un dispositivo físico que contiene todas sus características y funcionalidades. Se crean a petición del usuario desde la aplicación de escritorio. Quedan vinculados a Device Cloud del mismo modo que un dispositivo real. Sesión de la aplicación Conjunto de dispositivos simulados y sus estados dentro del marco de trabajo del usuario en la aplicación de escritorio. Un usuario puede tener múltiples sesiones creadas pero solamente una activa. Cada dispositivo simulado únicamente puede pertenecer a una sesión. Desconexión Estado de un dispositivo en el que no existe vínculo directo con Device Cloud y le impide enviar datos. Un dispositivo puede estar en funcionamiento pero desconectado de la nube por diversas razones (petición del usuario, falta de conexión a Internet, errores en la conexión, etc.). 14

17 SCI (Server Command Interface) Servicio web que permite a los usuarios acceder a la información de sus dispositivos o enviarles diversos tipos de comandos. Entre las peticiones ofrecidas por SCI se encuentran: Obtener información en vivo o en caché de nuestros dispositivos. Cambiar la configuración de los dispositivos. Leer o escribir en el sistema de archivos de nuestros dispositivos. Actualizar el firmware. Reiniciar o desconectar nuestros dispositivos. ii. Descripción general En este punto se definen las características generales de la aplicación web. El objetivo es recopilar las necesidades de la misma y toda funcionalidad que deba contener, así como cualquier tipo de restricción que nos afecte de cara a su desarrollo. Podemos agrupar las funciones que debe realizar el sistema en: Visualización del estado de la sesión de la aplicación: La aplicación mostrará al usuario el estado en tiempo real de su sesión de dispositivos simulados. Detalles individuales de cada dispositivo: Podremos acceder a cada uno de los dispositivos simulados de forma aislada, pudiendo obtener información más detallada de los mismos. Envío de peticiones SCI: La aplicación permitirá realizar cierto tipo de peticiones sobre los dispositivos simulados. Notificación de eventos: Se informará al usuario cada vez que ocurra un hecho relevante en un dispositivo simulado. iii. Requisitos funcionales A continuación se enumeran los requisitos funcionales de la aplicación: A. Autenticación Los usuarios deberán validar sus credenciales de Device Cloud para poder acceder a su sesión de dispositivos simulados. B. Tiempo real La aplicación debe mostrar al usuario todos los dispositivos simulados alojados en Device Cloud, independientemente de que formen parte de la sesión activa (en el caso de que haya una). Del mismo modo, su estado ha de actualizarse en tiempo real. 15

18 C. Dispositivos simulados en detalle La aplicación se encarga de monitorizar dispositivos simulados. Inicialmente se tratarán de dos tipos, tanques y camiones. Cada uno de ellos poseerá unas características concretas tratando de asemejarse a su equivalente real. En detalle, estas características serán: Tanque: nivel, estado de las válvulas de entrada/salida, temperatura. Camión: estado de la puerta, ruta, velocidad, temperatura. En la aplicación web, cada dispositivo simulado: Tendrá una representación gráfica que mostrará su estado actual. Permitirá cambiar ciertos estados del mismo y/o enviarles peticiones. Permitirá acceder tanto a un log con su actividad y como al archivo de configuración del dispositivo. D. Eventos Como los dispositivos simulados pueden estar cambiando de estado mientras el usuario navega por la aplicación, la misma hará saber al usuario que se ha producido alguna situación importante. Concretamente cuando: Se creen/eliminen dispositivos. Se abra/cierre una sesión de la aplicación de escritorio. Un tanque se llene/vacíe. Se conecte/desconecte un dispositivo. Un camión llegue al final de su ruta. iv. Requisitos de usuario y tecnológicos Requisitos de usuario: La aplicación está orientada a usuarios que quieran experimentar la funcionalidad de Device Cloud de una forma cómoda y sencilla, de modo que la interfaz ha de ser lo más agradable posible al usuario. Con apenas unos pocos clics se debe poder acceder a cualquier función de la aplicación. Requisitos tecnológicos: Al tratarse de una aplicación web, la necesidad de una conexión a Internet es evidente. Además, sería recomendable que tuviera unos tiempos de respuesta reducidos, dado que la cantidad de peticiones que tendrá que soportar puede ser alta. La aplicación debe adaptarse a una amplia gama de resoluciones existentes, como mínimo 1024x768 píxeles. El sistema deberá visualizarse de forma correcta, al menos, en los navegadores de uso más extendido (Chrome, Firefox e Internet Explorer). 16

19 Se debe disponer de un ordenador con una cierta potencia computacional, puesto que el sistema ejecutará una gran cantidad de código javascript de forma continua. v. Requisitos de interfaces externas Interfaces de usuario: La interfaz debe ser similar a la de la aplicación de escritorio, usando las mismas representaciones gráficas para los dispositivos simulados. Del mismo modo, el sistema completo debe ofrecer un aspecto corporativo conforme a la estética de Digi International. Interfaces hardware: Cualquier dispositivo computacional que disponga de navegador web. vi. Requisitos de rendimiento El servidor web debe proporcionar al usuario la página requerida en un tiempo inferior a 10 segundos. Como la actualización continua de javascript es inviable, la aplicación debe actualizar su estado en un tiempo lo suficientemente rápido como para no quedar desactualizada pero sin afectar al rendimiento. Un margen de segundos será lo aconsejable. vii. Requisitos de desarrollo y restricciones de diseño La metodología de trabajo utilizada para el desarrollo del software será Scrum, un proceso que permite trabajar colaborativamente de forma iterativa e incremental, obteniendo entregas parciales y regulares del producto final. Para la gestión operativa del proyecto el proyectante utilizará JIRA. 17

20 Casos de uso A continuación se adjunta el diagrama de casos de uso del sistema. Al tratarse de una aplicación web de monitorización, las acciones que puede realizar el usuario frente al sistema son bastante limitadas. Estamos hablando de una aplicación en un sentido más autónomo, con mucha funcionalidad interna a la que el usuario es ajeno (observa los cambios pero no forma parte de ellos). Se incluye la especificación del caso de uso más importante, puesto que los restantes resultan bastante triviales. Quedan incluidos en el anexo 1. Figura 3. Diagrama de casos de uso 18

21 Caso de uso Petición SCI Descripción Realiza una petición a un dispositivo. Actores Usuario. Precondiciones El usuario debe haber iniciado sesión. El usuario debe encontrarse en la vista de detalles. El dispositivo está conectado. Postcondiciones El dispositivo recibe la orden y actúa en consecuencia. Flujo básico 1. El usuario realiza una petición al dispositivo. 2. El sistema recoge la petición y la envía a través de Device Cloud al dispositivo. Flujos alternativos y excepciones Durante la espera de respuesta de una petición, esa función queda deshabilitada hasta recibir la misma. Si la petición no se procesa de forma correcta por cualquier tipo de error, el sistema debe notificar al usuario del suceso de forma clara. Anotaciones El dispositivo debe ser simulado. Aunque en la vista general también aparezcan los dispositivos reales, no disponen de acceso a la vista de detalles. Figura 4. Diagrama de actividad del caso de uso [Petición SCI] 19

22 2.2. Diseño A continuación se exponen todas las decisiones tomadas durante el desarrollo del proyecto en cuanto al diseño de las interfaces de usuario, a la arquitectura del sistema y al almacenamiento de datos Diseño de la interfaz de usuario Los primeros prototipos de la aplicación web fueron de bajo nivel, buscando un diseño que cumpliera con las necesidades expuestas en los requisitos del sistema. La vista de login no se menciona puesto que es una copia de la de Device Cloud. El aspecto inicial de la vista general de dispositivos era el siguiente: Figura 5. Prototipo de la vista general de dispositiv os La apariencia global no diferiría mucho de la final. Sin embargo, se tomaron algunas decisiones en cuanto a algunos detalles a tener en cuenta: Eliminar una de las vistas por sobrecarga de opciones. Con la vista de mosaico y en tabla de los dispositivos era suficiente. En la vista de mosaico, las flechas que pueden observarse en la parte superior e inferior de la lista de dispositivos se sustituyen por una barra de desplazamiento en el lateral derecho. Esto se debe a que usar elementos de este tipo supondría el desarrollo completo de los mismos (al no existir ningún plugin similar). 20

23 La apariencia final de la vista general de dispositivos es la siguiente: Figura 6. Vista general de dispositivos En cuanto a la vista de dispositivos en detalle, el prototipo inicial se ideó de la siguiente forma: Figura 7. Prototipo de la vista de detalles 21

24 En este caso, las diferencias entre el prototipo y la vista final son bastante notables, especialmente en cuanto a su visión respecto a la vista general. Inicialmente, la idea era sobreponer los detalles a la vista general (puede observarse la X en la esquina superior derecha). Al ProductOwner no le gustaba la idea de sólo poder interactuar con un dispositivo a la vez, así que se decidió abrir nuevas pestañas cada vez que se quisiera acceder a los detalles. La disposición de los elementos no varía respecto al prototipo. Sin embargo, se opta por crear distintas secciones en las características del dispositivo (indicadas en la mitad izquierda). De este modo, el usuario alerta más fácilmente grupos de características (genéricas, valores concretos del tipo de dispositivo e incluso dimensiones). Figura 8. Vista de detalles 22

25 Diagrama de navegación Figura 9. Diagrama de navegación de la aplicación 23

26 Arquitectura del sistema El sistema se basa en el Modelo Vista Controlador (MVC), puesto que es el tipo de arquitectura más adecuado para los propósitos de una aplicación web. Figura 10. Esquema del patrón MVC El modelo es la representación de la información con la cual el sistema opera, gestionando todos los accesos a dicha información. Envía a la vista la información que en cada momento se le solicita para ser mostrada. Estas peticiones llegan a través del controlador. El controlador responde a eventos (por lo general, acciones del usuario) y envía peticiones al modelo cuando se requiere algún tipo de información. Actúa como intermediario entre la vista y el modelo (middleware). La vista se encarga de presentar el modelo ante el usuario, de modo que la información queda accesible de forma más fácil para el mismo Almacenamiento de datos Se trata de un sistema distribuido, donde el almacenamiento de datos se produce en distintas partes del sistema: 1. Device Cloud de Etherios. La nube de Digi es el principal punto de almacenamiento y distribución de la información que maneja el sistema. En el momento en el que se produce un 24

27 cambio en la aplicación de escritorio, Device Cloud lo almacena mediante su sistema de Data Streams. Los Data Streams son contenedores diseñados para recoger información durante grandes periodos de tiempo, permitiéndonos posteriormente obtener la evolución de cierto valor. Cada muestra individual se denomina Data Point. Estas muestras son enviadas por la aplicación de escritorio a su correspondiente Data Stream cada vez que existe un cambio significativo. En el momento de la creación de un dispositivo, se vinculan automáticamente una serie de Data Streams (determinados por las características del dispositivo). La aplicación web tendrá acceso a éstos para actualizar su información. En cuanto a las sesiones de dispositivos creadas por la aplicación de escritorio, existirá un archivo que contenga los IDs de los dispositivos pertenecientes a la sesión activa. Si no hay ninguna sesión activa el fichero no existirá. 2. Aplicación de escritorio. Se encarga de almacenar las sesiones de dispositivos creados por el usuario. 3. App Engine. La aplicación web como tal no se encarga de almacenar información persistente, pero sí maneja datos que se mantienen vivos durante la sesión de un usuario. La sesión contendrá los datos del usuario conectado, así como los dispositivos del mismo de forma actualizada y los eventos ocurridos. Estos datos desaparecerán en el momento en el que el usuario cierre la sesión web Patrones de diseño Tal y como se ha descrito en el punto Arquitectura del sistema, se ha seguido el patrón MVC para conseguir una separación entre los datos y la lógica de negocio respecto de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. De este modo, se definen por una parte los componentes para representar la información y por otra las interacciones del usuario. Utilizando este patrón obtenemos dos ventajas muy importantes de cara a facilitar el desarrollo y mantenimiento de la aplicación. La primera, la separación de conceptos, ya se ha mencionado en el párrafo anterior. La segunda es la reutilización de código. Con MVC podemos desarrollar componentes de forma que sean útiles en más de una ocasión. 25

28 Diseño de clases Modelo para los dispositivos Como la parte que nos ocupa esta memoria es relativa a la aplicación web del sistema, y la cantidad de información que se maneja es relativamente pequeña (muchos dispositivos pero siempre los mismos tipos), el modelo de objetos ofrece un diagrama de clases reducido: Figura 11. Diagrama de clases del modelo de dispositivos 26

29 Con un simple vistazo se puede observar que la clase GenericDevice es el punto principal del modelo. Su objetivo es actuar como clase genérica ante cualquier dispositivo devuelto por Device Cloud. Posee las características generales de cualquier dispositivo: Identificadores únicos del dispositivo en la nube. Uno completo (deviceid) y uno corto, que es el más comúnmente utilizado por Device Cloud al manejar la información (shortid). Un nombre asignado por el usuario desde la aplicación de escritorio. Un estado conectado, que indique si está en ese momento conectado a Device Cloud. Una variable sesión, para saber si el dispositivo pertenece a la sesión activa. Una variable Tipo, que indique qué clase de dispositivo simulado es. Como la aplicación mostrará todos los dispositivos en la nube de usuario, es posible que existan dispositivos reales. Para ese caso, el tipo será REAL. Impedirá acceder a detalles del mismo y tendrá una representación gráfica genérica. Tendrán una representación en el mapa, mediante coordenadas. Una versión de firmware. De la clase GenericDevice podrán heredar tanto dispositivos reales como simulados. El método issimulated() sirve para diferenciar de forma simple qué tipo estamos manejando. Inicialmente, como ya se explicó en la etapa de Análisis, entre los dispositivos simulados dispondremos de tanques y camiones. Los reales, por su parte, tendrán una funcionalidad muy limitada (meramente informativa). Modelo para los eventos Por otra parte, la aplicación necesita recoger información de los eventos más significativos que ocurran en los dispositivos o en la sesión de la aplicación de escritorio. Para ello, la aplicación web consultará a Device Cloud un fichero que contendrá la información con los eventos ocurridos. Estos eventos serán manejados por medio del siguiente modelo: 27

30 Figura 12. Diagrama del modelo de eventos Contendrá un tipo de notificación action, un mensaje que variará en función de esta notificación y una fecha del suceso. Además, el atributo name servirá para identificar la raíz del suceso (en el caso de un evento global, el nombre de la sesión; en el caso de un dispositivo, su nombre). El objetivo de la clase Event y sus derivadas es meramente informativo y organizativo (sirve de puente entre Device Cloud y javascript a través de un servlet). En ningún momento estarán vinculadas a un Device en el caso de los eventos de dispositivos. Se debe a una cuestión de eficiencia, puesto que los eventos solamente serán consultados por una única vía y de forma temporal (no quedan almacenados de forma persistente). Vincularlos a los dispositivos exigiría un aumento indeseado en los costes computacionales en una aplicación que busca mantener al usuario actualizado en la mayor brevedad posible. 28

31 Diseño del plan de pruebas A continuación se definen las pruebas que se llevarán a cabo una vez se ponga fin a la implementación de la aplicación. Esto servirá como pautas de testeo y comprobación para asegurarnos de que todas las partes del sistema funcionan de la forma adecuada y se cumplen los requisitos iniciales con los suficientes niveles de calidad. Las pruebas a realizar serán de los siguientes tipos: Pruebas unitarias: comprueban que cada módulo funciona de la forma correcta. Pruebas de integración: aseguran la validez de varios módulos trabajando en conjunto. Pruebas de aceptación: comprueban si se han cumplido o no los requisitos iniciales. Las pruebas se documentarán según la siguiente tabla: Test Case ID Group Test Name Commands / Description Result Siendo: Test Case ID: identificador único para cada caso de test. Group: grupo en el que se engloba el caso de test (por ejemplo, navegación). Test Name: nombre del test a realizar. Commands/Description: pasos a seguir para realizar la prueba al completo con éxito. Result: resultado exitoso o no de la prueba. No se contempla la posibilidad de realizar pruebas de estrés a la aplicación. El uso de App Engine en su versión gratuita ya limita de por sí el tráfico que la aplicación puede soportar. Además, inicialmente la aplicación está ideada para funcionar de forma interna, de modo que el número de usuarios será en cualquier caso muy limitado. 29

32 2.3. Implementación La fase de implementación trata de ejecutar de la manera más fiel posible las reglas y características establecidas durante las dos fases anteriores. A continuación, se detallan las tecnologías utilizadas para llevarla a cabo, la estructura del proyecto, los recursos externos necesitados y los problemas surgidos durante su transcurso, así como las soluciones a los mismos Tecnologías usadas Como ya se ha ido detallando a lo largo de esta memoria, el objetivo de este proyecto es el desarrollo de una aplicación web alojada en Google App Engine. App Engine queda englobado dentro de lo que se conoce como Platform as a Service (PaaS). Es un modelo de Cloud Computng que ofrece a sus usuarios la posibilidad de desarrollar aplicaciones de forma más fácil y barata que teniendo que administrar todo el hardware y software subyacente. App Engine permite crear aplicaciones web en varios lenguajes, concretamente: Java, Python, PHP y Go. Dado que el proyectante tenía experiencia previa en Java y así lo acordó con el Product Owner, ésa sería la tecnología escogida para implementar la aplicación. Como se acaba de indicar, un PaaS trata de facilitar al usuario el desarrollo de la aplicación. En este caso, Google aporta un SDK muy completo que incluye un servidor de aplicaciones para hacer pruebas en local, de nombre Yetty. Además, existe un plugin que integra este SDK con Eclipse. La principal ventaja reside en que al crear un nuevo proyecto lo prepara para que la estructura de carpetas sea acorde con la requerida por los servidores de App Engine. Incluso permite la subida del proyecto desde el propio Eclipse, en lugar de desde la línea de comandos. Detallado el entorno de desarrollo y el lenguaje del servidor de aplicaciones, es el turno de las tecnologías necesarias para la creación de un sitio web al completo. Lo primero que nos viene a la mente al hablar de web es el lenguaje HTML. Más concretamente, en este proyecto se ha usado HTML5. Se entiende comúnmente por HTML5 a la propia versión 5 de HTML, pero la definición más completa que usan los desarrolladores es la combinación de HTML5 + CSS3 + JavaScript. El uso de estas tres tecnologías ofrece webs mucho más dinámicas e interactivas con el usuario. Incorpora el proyectante también el uso de JQuery, al tratase de una tecnología que facilita en gran medida la escritura de código JavaScript. 30

33 Figura 13. Tecnologías web en aplicaciones modernas En cuanto a la comunicación de la aplicación con la nube de Digi, toda petición realizada a la misma devuelve información encapsulada en formato XML. Por otra parte, la aplicación requiere de actualizaciones constantes de cierta información, que se realizan por medio de llamadas AJAX. En determinados casos, esta información debe enviarse de forma organizada, puesto que puede tratarse de grandes cantidades de datos (por ejemplo, los dispositivos de la nube actualizados). Para ello, el servidor devuelve en ciertas llamadas AJAX los datos en formato JSON. Se eligió este formato al ser ligero, muy fácil de generar en Java y muy fácil de interpretar desde JavaScript Recursos externos El desarrollo de ciertas partes de la aplicación ha requerido del uso de recursos externos, los cuales han servido para facilitar ciertas tareas. Librerías externas Java Su propósito es el de ahorrar tiempo de programación y aumentar la eficiencia. 1. Gson: es una librería Java desarrollada por Google que permite convertir objetos Java en su representación en JSON. Se usa para devolver listados de objetos del modelo explicado en el DISEÑO DE CLASES en llamadas AJAX. 2. Joda Time: esta librería reemplaza las clases Java Date y Time, cuyo uso está desaconsejado. Se considera una librería más eficiente, sencilla y potente que éstas. Se ha empleado en el modelo de Eventos. 31

34 3. Commons-IO: librería de utilidades para facilitar el trabajo con operaciones de entrada/salida. Utilizada para lectura y escritura de streams entre Device Cloud y la aplicación. 4. Commons-Codec: librería de utilidades para codificar y descodificar información. Necesaria para ciertas operaciones de este tipo en Base64. Plugins JQuery Se trata de plugins desarrollados en JQuery que ofrecen una funcionalidad muy potente a cambio de muy poco esfuerzo. En general se ha requerido de su modificación para obtener el funcionamiento deseado. 1. Flexigrid: este plugin procesa la tabla que deseemos aportándole una apariencia más agradable de cara al usuario. Dispone de varias implementaciones, aunque en este caso se optó por la más básica. Se ha usado en la vista de tabla de dispositivos y en la vista con el listado completo de notificaciones. 2. JqPlot: permite crear múltiples tipos de gráficos, que se muestran en elementos canvas de HTML5. Los datos deben enviarse como un vector de vectores, donde cada uno de éstos contiene una dupla timestamp-valor. Se utiliza en las vistas de detalles de los dispositivos simulados. 3. Moment: este plugin actúa como una librería que facilita el manejo de fechas en JavaScript. Se emplea para transformaciones de fechas al mostrarlas en las gráficas de JqPlot. 4. Fileupload: ofrece funcionalidad de subida de archivos vía AJAX. Al igual que Flexigrid, este plugin dispone de múltiples implementaciones. Del mismo modo se ha optado por la más básica. Se ha empleado en las actualizaciones de firmware de dispositivos simulados. 5. Transit: permite crear de forma rápida y sencilla transiciones y rotaciones en CSS3. Empleado en la animación del velocímetro en la vista de detalles de camiones. 6. Google Maps: esta conocida API nos da la posibilidad de incrustar mapas en nuestro código HTML. Al igual que JqPlot, lo hace por medio de un elemento canvas. En el proyecto se ha empleado tanto en la vista general de dispositivos como en los detalles. 7. JQuery Media: este plugin permite la reproducción de múltiples tipos de contenido multimedia. Ha sido aplicado como visor de documentos pdf en la guía de usuario. 32

35 Frameworks front-end Se trata de entornos de trabajo que facilitan al programador las tareas de diseño de ciertos elementos de la vista HTML, así como de ciertas funcionalidades JavaScript. 1. Bootstrap: uno de los frameworks más conocidos y completos para el desarrollo de interfaces agradables e intuitivas. En este proyecto se ha empleado en múltiples ocasiones y diferentes funcionalidades: plantillas (el puto de entrada de la aplicación), botones, modales, tooltips, barras de progreso, etc. 2. JQuery UI: similar a Bootstrap, ofrece una amplia variedad de elementos gráficos manejados vía JavaScript. Se ha empleado para los botones que se encuentran en la parte inferior de las gráficas en las vistas de detalles, para alternar entre distintos lapsos de tiempo. 3. Dojo: es un framework que contiene APIs y controles que facilitan el desarrollo de aplicaciones web que utilicen tecnología AJAX. Su uso en este proyecto se ha limitado a la implementación de alertas no intrusivas con el usuario (denominadas Toasters) Estructura del proyecto Como se ha comentado anteriormente en esta sección, Google proporciona un plugin para desarrollar proyectos para App Engine desde Eclipse. Este plugin se encarga de generar el árbol de directorios y las dependencias necesarias en el proyecto para comenzar a trabajar. Los proyectos web para App Engine constan de tan sólo 3 carpetas en su raíz:.settings, src y war. La primera carpeta no es necesario detallarla, puesto que se genera automáticamente. /src: en esta carpeta se almacenan todas las clases Java necesrias para las tareas de back-end. Podemos diferenciar 5 subdirectorios principales, que separan las clases en función de su propósito: o /com.digi.ajax: servlets usados en llamadas AJAX desde JavaScript. o /com.digi.exception: excepciones personalizadas para manejar más fácilmente las respuestas de Device Cloud. o /com.digi.model: contiene los modelos de dispositivos y eventos. o /com.digi.ser: servlets de navegación. o /com.digi.utils: clases con métodos estáticos que facilitan las operaciones (tratamientos de cadenas XML, llamadas a Device Cloud y otros). 33

36 Figura 14. Contenido de la carpeta /src /war: contiene todos los elementos directamente relacionados con el front-end. La propia raíz de esta carpeta contiene algunas páginas.jsp. Además: o /css: ficheros de estilo CSS. o /devices: ficheros.jsp relativos a los detalles de los dispositivos. o /img: imágenes. o /js: ficheros JavaScript (tanto propios como plugins externos). o /WEB-INF: librerías externas y archivos de configuración, incluyéndose web.xml, que contiene la información de mapeos de servlets, páginas de error y duración de las sesiones de usuario, entre otros. También contiene appengine-web.xml, con configuraciones propias para App Engine 1 Figura 15. Contenido de la carpeta /war

37 Desarrollo de la aplicación Antes de comenzar a describir el proceso seguido hasta completar la aplicación, se debe tener en cuenta que el proyecto no abarca el 100% del desarrollo de la misma. Las fases de análisis y diseño se encontraban prácticamente terminadas y se había avanzado una pequeña parte de la implementación. En concreto: Análisis de requisitos y diseño: prácticamente completados. Se incluyeron algunas horas en el proyecto al existir la posibilidad de cambios conforme la implementación avanzaba, como así fue finalmente. Contenido web estático: las páginas de login, la vista general de dispositivos y las vistas de detalles se encontraban ya realizadas. Es decir, no poseían funcionalidad pero el esqueleto de la web estaba listo para trabajar en él. También sufrieron pequeños cambios durante la implementación que se detallarán más adelante. Navegabilidad básica: la aplicación realizaba operaciones de navegabilidad simples: login de usuarios, acceso a los detalles de un dispositivo simulado, logout. Funcionalidad JavaScript: la página general de dispositivos actualizaba los mismos en las tres vistas disponibles: mosaico, tabla y mapa. El hecho de que el análisis y diseño se encontraran en un nivel de definición bastante definitivo dio lugar al empleo de una metodología Scrum más orientada a completar fases de implementación. Al no tratarse de un entorno poco definido, cada sprint buscaba completar progresivamente distintas secciones de la web. FASE 1: Vistas de detalles Como ya se ha mencionado anteriormente, las vistas (archivos.jsp) se encontraban ya creadas pero carentes de funcionalidad. Actualizaciones y animaciones El primer objetivo fue el de recabar datos actualizados de Device Cloud. Primeramente hay que tener encuenta que los datos relacionados con el dispositivo en cuestión (su ID, especialmente) son mostrados en la página mediante lenguaje EL, a través de un atributo del objeto Request. Este objeto no es accesible por JavaScript, por lo tanto es necesario algún mecanismo que recoja esta información para poder hacer llamadas AJAX que actualicen la información temporalmente. La solución aportada fue usar 35

38 el método $(window).load() de JQuery, que se ejecuta en el instante que la página ha cargado todo el contenido estático. Dentro de este método se accede a todos los valores alojados en el HTML, guardándolos en un objeto JavaScript. Es importante mencionar la obtención del valor shortid, necesario en varios tipos de llamadas a Device Cloud. A simple vista el usuario no lo ve, porque es totalmente innecesario para él, aunque está dentro del código HTML, concretamente junto al Device ID. El estilo dado a su etiqueta <span> es display=none, por lo tanto aunque no se vea el valor, existe. La aplicación de escritorio envía constantemente valores actualizados de todas sus características, que se almacenan en Device Cloud en los llamados DataStreams. Cada 20 segundos JavaScript realiza una llamada AJAX al servlet GetTankData o GetTruckData (en función del tipo de dispositivo concreto) con el ID y shortid pertinente. Estos servlets recogen el último valor (DataPoint) de cada uno de estos DataStreams y los devuelve en formato JSON, que se comparan con los almacenados en el objeto device. Si el valor de la característica ha variado, se actúa en consecuencia (tanto en los valores de texto como en las imágenes). En general, las animaciones constan de cambios de imágenes, pero cabe destacar la animación del velocímetro del camión, en la que se ha usado el plugin Transit. Con él se ha podido simular el comportamiento de la aguja aplicando la siguiente transformación: Destacar también la existencia de un método manageconnection(status) en JavaScript, que se encarga de habilitar/deshabilitar las funciones de la página en función de si el dispositivo está o no conectado. 36

39 Peticiones Una de las características más interesantes de las vistas de detalles es la posibilidad de interactuar con los dispositivos simulados desde la propia web. A excepción de las peticiones del archivo de configuración y del log, que se detallarán un poco más adelante, el resto de llamadas se realizan mediante AJAX. De este modo, el usuario no necesita actualizar la página para visualizar los cambios producidos. Tanques y camiones comparten una serie de peticiones, de naturalezas muy distintas entre ellas: Cambio de temperatura: se diseñó un widget de temperatura, consistente en un termostato que informa de la temperatura y unos botones que permiten hacer la llamada al dispositivo. El usuario puede introducir un valor en la caja de texto o usar los botones (+) y (-) para dar con el valor deseado. Una vez decidido, pulsando el botón Change Temperature la petición se enviará, que será procesada en el servlet ChangeTemperature. El usuario será notificado al instante de si la petición ha sido realizada con éxito (el dispositivo comenzará al cambiar la temperatura paulatinamente hasta alcanzar el valor objetivo). Desconexión: el usuario puede decidir desconectar el dispositivo. Pulsando en el botón de la imagen a la derecha de estas líneas aparecerá un modal con diferentes opciones. La petición de desconexión es manejada por el servlet DisconnectDevice. Si es exitosa el dispositivo se desconectará al instante. Del mismo modo, la página notificará al usuario y deshabilitará las funciones pertinentes. Figura 16. Botón de peticiones SCI Actualización de firmware: esta característica tuvo una implementación inicial, que variaría más tarde por requerimiento del Product Owner. Device Cloud permite realizar peticiones de firmware de forma transparente al dispositivo, característica que no era del agrado del proyectante. Por ello, inicialmente, la actualización de firmware se realizaba como una petición SCI normal. Esto no convenció al Product Owner, que solicitó realizarla del indicado inicialmente (transparente para el dispositivo). El servlet UpdateFirmware se encarga de procesar la petición. Sin embargo, el grueso de esta sección viene marcado por el uso del plugin FileUpload (mencionado en la sección ). Este plugin permite realizar subidas de archivos mediante AJAX, ofreciendo una serie de funciones de callback muy útiles para conocer y cambiar el estado de la petición. En concreto, en esta aplicación se limitó a la subida de archivos binarios menores de 2MB. 37

40 Archivo de configuración y log: Device Cloud también permite realizar peticiones directamente al sistema de archivos de los dispositivos. Esta característica se aprovechó para obtener estos dos archivos. El primero contiene la configuración del Cloud Connector en el dispositivo. El segundo, el log de incidencias que recopila este mismo conector. Al contrario que en las otras peticiones, estos servlet (GetDeviceConfig y ViewLog) recogen la petición pero muestran el contenido de los archivos en una nueva pestaña. Además de estas peticiones, los tanques tienen una petición exclusiva: Cambiar el estado de una válvula: en los detalles de un tanque disponemos de una imagen que nos informa del estado del mismo. Posee dos válvulas, las cuales son interactuables cuando el dispositivo está conectado. Cuando el usuario pulsa en una, la petición llega al servlet ChangeValve. Si la petición es correcta, la válvula cambia inmediatamente en la página, de modo que el usuario advierte que se ha efectuado la misma. Si no, se mantiene como está. Los detalles de un camión también dispusieron inicialmente de un par de peticiones, detener el camión y abrir la puerta (pueden apreciarse los servlets StopTruck y ChangeGate en la figura X). El Product Owner consideró finalmente que esta funcionalidad no resultaba práctica para los propósitos de la aplicación, por lo que quedó descartada. FASE 2: Notificaciones La aplicación consta de un sistema de notificaciones de eventos ocurridos en los dispositivos. El modelo de eventos definido en el punto da una idea de los posibles avisos que ofrece la aplicación. Inicialmente sólo se manejaba la posibilidad de que en la aplicación de escritorio existiera una única sesión de dispositivos simulados por cuenta. Por lo tanto, en una primera implementación, los eventos se activaban automáticamente al realizar el login en la aplicación. Conforme el proyecto avanzó, la aplicación de escritorio permitió la posibilidad de crear múltiples sesiones de dispositivos (aunque sólo se puede tener una activa). Esto obligó a realizar un pequeño rediseño, añadiendo la posibilidad de escoger la sesión a monitorizar en la vista de dispositivos. Cuando el usuario realiza el login, se abre un modal con todas las sesiones que ha creado. Se le da la opción de escoger una o por el contrario no controlar ninguna. Este listado es accesible en cualquier momento desde la esquina superior derecha de la página. Cuando el usuario solicita el listado de sesiones, automáticamente es actualizado antes de mostrárselo vía AJAX, mediante el servlet UpdateSessions. Una vez existe una sesión seleccionada, JavaScript comienza a llamar al serlet UpdateEvents tras el método UpdateDevices (que se encarga de actualizar los dispositivos). Este servlet actualiza 38

41 mediante AJAX las notificaciones de la sesión. El funcionamiento es complejo, por lo que se pasa a detallarlo a continuación. El servlet UpdateEvents (back-end) Cuando UpdateEvents comienza a recibir llamadas, establece una variable en la sesión de usuario llamada lastupdate, que controla la fecha de la última actualización. Esto es muy importante, dado que el archivo alojado en Device Cloud se va sobrescribiendo conforme van ocurriendo eventos. Cada evento se dispone en una línea, con la estructura: [Timestamp] [Tipo de dispositivo] [Nombre] [Evento] La variable lastupdate de encarga de verificar que se recogen sólo los eventos ocurridos tras la última actualización. El archivo de notificaciones se borra cada vez que la sesión se cierra, de modo que es relativamente sencillo detectar y notificar cuándo una sesión se ha cerrado. El problema surge al existir la posibilidad de que la sesión seleccionada por el usuario previamente fuera otra. Se dispone de otra variable de sesión de nombre session, que almacena la sesión actual seleccionada por el usuario. Si ésta no se corresponde con el parámetro llegado al servlet, es fácil detectar que el usuario ha cambiado la sesión a monitorizar. Si el archivo de notificaciones existe, devuelve el resultado de recoger los eventos correspondientes en un listado en formato JSON. Si no, devuelve un entero que se corresponde con un tipo de mensaje. 39

42 El método updatenotifications(data) (front-end) Cuando el servlet UpdateEvents devuelve un listado de eventos, el método JavaScript updatenotifications(data) se encarga de procesar este listado y actuar en consecuencia. Si la sesión está abierta, el listado de notificaciones debe contener en su parte inferior un botón que permita visualizar el listado completo de eventos desde que la sesión ha sido abierta. Al pulsar en él, se abre una nueva pestaña que llama al servlet SessionLog. Éste recoge el archivo de notificaciones al completo y lo muestra en la vista sessionlog.jsp. La complejidad reside en el límite de eventos que se puede mostrar en el listado (un máximo de cinco). Por lo tanto, hay que controlar varios estados: - El número de eventos nuevos, que es el número que aparece en rojo sobre el icono de eventos. - El número de eventos en el listado (un máximo de cinco). - El número n de eventos nuevos que quedan sin visualizar una vez se muestra el listado (indicado en el botón View all notifications (n more) ). Los JSON de eventos se leen desde el más antiguo al más reciente. El listado actúa como una cola FIFO, donde los eventos más recientes aparecen en la parte superior y van siendo relegados hasta desaparecer. Cada evento en el listado del HTML es un contenedor <div> con el atributo class= eventlistcomponent. Este contenedor posee una imagen que representa el evento ocurrido, un texto que informa del mismo, la hora del suceso y el nombre del dispositivo que lo ha provocado. Para diferenciar los eventos recientes de los ya leídos, se añade el atributo class= new, que interpretado desde CSS posee un color de fondo distinto. Por lo tanto, un evento reciente tendrá como atributo class= eventlistcomponent new. Cuando el usuario pulse en el icono para mostrar el listado, diferenciará fácilmente los nuevos eventos de los ya leídos. En el instante que el listado se cierre, la clase new desaparecerá. 40

43 FASE 3: Página de entrada (entry point) Una vez completada la funcionalidad más importante, quedaba por realizar el punto de entrada a la aplicación (hasta entonces se accedía directamente al login). El propósito de esta página es que el usuario se encuentre con una web amigable la primera vez que acceda desde el navegador. Además, es importante remarcar que es el primer sitio al que accederá del sistema completo, ya que desde este punto podrá descargar la aplicación de escritorio. Buscando un diseño acorde con la estética de Device Cloud y a la vez ligero, se optó por modificar una plantilla de Bootstrap. En la siguiente imagen se puede apreciar la adaptación de la misma para obtener el resultado deseado: Una vez creada la página, se vinculó en el archivo web.xml como <welcome-page>, para así acceder a ella al introducir la url raíz Como se puede observar en la imagen anterior, la parte inferior de la página contiene tres secciones: La primera permite la descarga directa de la aplicación de escritorio en formato.zip. La segunda contiene el acceso al path /Home, procesado por el servlet con ese mismo nombre. Si el usuario ya está logueado, le redirige directamente a la vista de dispositivos. Si no, le enviará al login. La tercera abre la guía de usuario en una pestaña nueva. A continuación se detallará su funcionamiento. Visor pdf Cuando el usuario accede a la guía de usuario, ésta se abre en una pestaña nueva. Se encuentra contenida en la vista guide.jsp. Esta vista simplemente contiene una barra superior con el logotipo de Device Cloud y un contenedor que ocupa el resto del espacio. El encargado de mostrar el contenido de la guía pdf es el plugin JQuery Media. El funcionamiento del mismo es bastante sencillo: 1. Se incluye un elemento <a> de la clase media, que contenga como referencia el documento.pdf: <a class="media" href="guide.pdf">pdf File</a> 2. Tras la carga de la página, se llama al plugin de la siguiente forma, donde w y h son la anchura y la altura del contenedor, respectivamente: $('a.media').media({width: w, height: h}); 41

44 FASE 4: Mejoras Tras la finalización de la funcionalidad básica de la web, los integrantes del proyecto mantuvieron una reunión centrada en aspectos de diseño. Se sugirieron pequeños cambios relativos a la experiencia de usuario y la adición de ciertos extras en la web. A continuación se explicarán las modificaciones más importantes. Gráficas históricas Como ya se ha mencionado anteriormente, los dispositivos simulados envían datos actualizados de su estado a Device Cloud, que se recogen en DataStreams. Los servicios web de la nube permiten la obtención no sólo del último valor de éstos, sino también de todo el histórico. Esta funcionalidad se aprovechó para elaborar gráficas que reflejaran el progreso de cada característica a lo largo del tiempo. El plugin JqPlot es invocado de la siguiente forma: Donde: $.jqplot('chartdiv'+feature, [line1],{options}); 1. El primer parámetro es un div contenedor donde se mostrará la gráfica. JqPlot crea un elemento canvas para dibujarla. 2. El segundo parámetro es una matriz nx2 que aloja los valores a mostrar. Debe contener n filas y siempre 2 columnas, con la propiedad timestamp-valor. Por ejemplo, un DataStream con 3 valores debería utilizar una matriz de acuerdo a: [timestamp_1] [valor_1] [timestamp_2] [valor_2] [timestamp_3] [valor_3] 3. El tercer parámetro es una lista completa de opciones de visualización de la gráfica 1. Para obtener los valores de cada característica, el servlet GetDataStreamValues es llamado vía AJAX con dos parámetros: el ID del dispositivo y la característica a recoger. Uno de los problemas encontrados a la hora de acceder a los valores de un DataStream es que Device Cloud limita a 1000 el número de valores a devolver mediante web services. Por lo tanto, el servlet debe realizar todas las llamadas necesarias hasta almacenar todos los valores (de mil en mil valores, hasta completar el proceso). Una vez recopilada toda la información, la matriz resultante se envía en formato JSON

45 Desde JavaScript, se procesa la petición del siguiente modo. Existen dos objetos contenedores: Uno para las gráficas. Sirve para comprobar si ya se ha creado una gráfica con una característica determinada (útil cuando hay que redibujarla, para llamar al método destroy() de JqPlot). Otro para los valores divididos en lapsos de tiempo. Existe un método savedatabytimespan(feature, data), que almacena en distintos vectores los datos según el margen de tiempo en el que se encuentran. Una vez almacenados los valores, se procede a dibujar las gráficas. Los contenedores para cada característica se encuentran en la misma posición de la página, con la propiedad position: absolute de CSS. Lo que define cuál se muestra es el atributo z-index, con valor 1 por defecto. Si el usuario decide cambiar de característica, el contenedor añade a su atributo class el valor chartselected, que en CSS le otorga el valor z-index=2, colocándose por encima del resto de contenedores. En cuanto a los lapsos de tiempo, el usuario puede decidir visualizar sólo los datos recogidos en la última hora, día o semana. Mediante el objeto JavaScript definido anteriormente podemos acceder rápidamente a los datos relativos al espacio de tiempo solicitado. Tan sólo es cuestión de redibujar la gráfica conforme a los requerimientos del usuario. Finalmente, se consideró interesante la inclusión de un botón de refresco de las gráficas. No se actualizan temporalmente como el resto de datos por limitaciones propias de Device Cloud, al requerir un volumen de datos muy grande. Su funcionamiento se basa en volver a recoger los datos vía AJAX. 43

46 Para que sea más cómodo para el usuario, si en el momento de solicitar la actualización tiene seleccionado un lapso de tiempo, la nueva gráfica queda mostrada en ese mismo espacio de tiempo. Esto se consigue provocando el evento click en el botón correspondiente: $('#'+inputid).trigger('click'); (Donde inputid es el botón seleccionado) Diseño web adaptativo Como ya se ha mencionado anteriormente, las páginas con las que partía el proyectante al comienzo del proyecto sólo poseían contenido estático. Además, su diseño era bastante rígido, puesto que no se había probado en distintas resoluciones. Esto provocaba que al hacer pruebas en monitores con menor resolución ciertos elementos (especialmente algunos contenedores y textos) quedarán fuera de lugar. CSS3 ofrece nuevas propiedades que permiten adaptar el tamaño de los elementos al tamaño de la pantalla del usuario. Son las conocidas como viewport height y viewport width. Poniendo un ejemplo simple: width = 1vw El tamaño del contenedor será de un 1% respecto al ancho de la pantalla. height = 1vh El tamaño del contenedor será de un 1% respecto al alto de la pantalla. Aplicado a este proyecto, resulta especialmente útil en el caso de los tamaños de las fuentes. Por ejemplo, en las vistas de detalles, el Device ID es un número muy grande, que dependiendo de la resolución puede salirse de su contenedor. Aplicando la siguiente regla: El tamaño del texto será de un 0.9% sobre el total del ancho de la pantalla. Esto evitará que sobresalga del contenedor en resoluciones reducidas. También puede observarse la aplicación de este tipo de reglas en los contenedores de la vista de mosaico de la vista general de dispositivos o en el widget de temperatura. Destacar también el uso de la con la cual se pueden elegir las reglas CSS en función de la pantalla del usuario. Por ejemplo, la hoja de estilos para la guía de usuario contiene lo siguiente: 44

47 #pdfcontent y #logologin son contenedores <div> presentes en guide.jsp. Como puede intuirse en la imagen, su anchura dependerá de la anchura de la pantalla del usuario. Así, si es superior a 768px tendrán una anchura de 750px. Pero, si además es superior a 992px, su anchura será de 970px. Y así sucesivamente con todas las reglas que queramos. Hay que tener en cuenta que las reglas CSS son leídas en el orden que están escritas en la hoja. De modo que en orden inverso no producirían el efecto deseado en una pantalla superior a 992px, puesto que la última condición sería minwidth: 768px, que también la cumpliría. Alertas no intrusivas (Toasters) Dado que la aplicación web contiene mucha funcionalidad JavaScript es propensa a que ocurran errores. Especialmente con las llamadas AJAX que efectúan servicios web sobre Device Cloud. Por ello, nos interesa que el usuario sea consciente de los posibles problemas surgidos durante las actualizaciones o interacciones que se realicen. Por desgracia, el mecanismo de alertas de JavaScript resulta muy rudimentario y molesto, puesto que obliga a pulsar en el botón Aceptar de la caja para poder continuar navegando. Si una simple alerta es de por sí molesta, imaginemos en una aplicación en la que pueden ocurrir múltiples errores continuamente. Dojo Toolkit ofrece un sistema de alertas no invasivas, que se muestran en la parte superior de la pantalla pero no impiden continuar trabajando. Incluso si ocurren varios sucesos, cada alerta se coloca debajo de la anterior. Transcurrido un tiempo, las alertas desaparecen. Además, el propio usuario puede eliminarlas pulsando sobre ellas. Su funcionamiento es relativamente sencillo. Requiere la inclusión de un contenedor de estas características en nuestro código HTML: Y de la inicialización de Dojo (requiere parsear el documento): Tras esto, declaramos una variable global que nos sirva para crear las alertas desde cualquier otra función y la inicializamos: 45

48 Una vez listo nuestro código, simplemente llamaremos a la variable global con el método call() de la siguiente forma: Existen varios motivos por los que una alerta puede mostrarse. La imagen anterior es un ejemplo de una alerta porque el usuario no está logueado. La lógica que define el tipo de mensaje se explicará más adelante, en la sección de resolución de problemas. Filtro de dispositivos Como último detalle, el Product Owner decidió la inclusión de un checkbox que actuara como filtro de dispositivos al tener una sesión seleccionada. Su objetivo es que el usuario pueda alternar en la vista de dispositivos cómodamente entre ver todos los dispositivos que tiene alojados en la nube o sólo aquellos que pertenecen a la sesión seleccionada. El comportamiento por defecto es el de activarse en el momento que el usuario cambia de sesión a monitorizar (excepto si no hay sesión seleccionada, que entonces desaparece). En ese instante, el usuario sólo verá los dispositivos de la sesión. Esto se aplica a las tres vistas disponibles: mosaico, tabla y mapa. El código es relativamente sencillo: 46

49 La función JavaScript filterdevices() comprueba el estado del checkbox. Si está seleccionado, recorre el objeto que almacena todos los dispositivos del usuario (este objeto se actualiza vía AJAX cada 20 segundos). Como los contenedores de las vistas de mosaico y tabla poseen un atributo id= mid e id= tid respectivamente, resulta sencillo aplicarles la propiedad display= none si no pertenecen a la sesión seleccionada. Para el caso opuesto, se actúa del mismo modo pero aplicando display= block o display= table-row, en función de si es mosaico o tabla. Para el caso de los marcadores del mapa disponemos de otro objeto que los almacena. La tarea consistirá en llamar al método setvisible() con true o false según proceda. FASE 5: Guía de usuario Aunque el sistema completo no tenga una cantidad de funcionalidades excesivamente grande, sí que exige que los usuarios tengan conocimiento de cómo funciona. El Product Owner solicitó a los desarrolladores una guía de usuario en inglés. Al existir aplicación de escritorio y web, cada uno de los miembros del equipo se encargó de su parte. Puede encontrarse la parte correspondiente al proyectante en el anexo 3, así como es accesible la guía completa del sistema desde la propia aplicación web Pruebas En el punto de esta memoria se establecieron los tres tipos de pruebas a realizar para comprobar el correcto funcionamiento del sistema. El hecho de aplicar una metodología ágil en la implementación obligó a realizar pruebas unitarias conforme se iban desarrollando partes de la aplicación, especialmente al completar las distintas fases. El principal escollo a superar eran las pruebas de integración, al depender directamente del progreso de implementación de la aplicación de escritorio. Ciertas partes de la aplicación web eran programadas pero quedaban sin testear hasta cierto tiempo después por este mismo motivo. A continuación se exponen a modo de ejemplo algunas de las pruebas realizadas. El resto se pueden consultar en el Anexo 2: plan de pruebas. 1. Pruebas unitarias: Test Case ID 17 Group Test Name Commands / Description Result Details updates Device's updates Go to the details of a simulted devices from main view. The information about the device must be updated correctly according to the data requested from Device Cloud, both text information and graphic elements. Passed 47

50 2. Pruebas de integración: Test Case ID Group Test Name Commands / Description Result 17 Details requests View device log Open the details of a connected simulated device. Push on the "make a SCI request" button. Select "view log" in the dropdown list and submit. A new tab must be displayed with the device log. Passed 3. Pruebas de aceptación: Durante todo el desarrollo del proyecto se realizaron reuniones cada dos semanas, haciendo un repaso completo del progreso de la aplicación y comentando posibles mejoras (las más importantes comentadas en la fase 4 del punto 2.3.). El último mes, una vez el sistema se consideraba completado (aplicación de escritorio y web), fue sometido a un testeo por parte del equipo de test de Digi. Tras aportar varias mejoras y realizarse una revisión definitiva, el sistema se dio por completado y el desarrollo finalizado. 48

51 Capítulo 3: Conclusiones Una vez finalizado el desarrollo de la aplicación es el momento de exponer un balance con los resultados obtenidos. En este capítulo se detalla el grado de cumplimiento de los objetivos propuestos inicialmente, los problemas planteados y la forma de resolverlos. Además, se hace una valoración de los conocimientos adquiridos durante el desarrollo del proyecto y las posibles mejoras a futuro de la aplicación Evaluación de objetivos En el punto 1.2. de esta memoria se expusieron una serie de objetivos a completar. El cumplimiento de éstos determinaría si el proyecto había sido completado de forma exitosa. A continuación se detalla el grado de cumplimiento de los mismos, desde los más específicos de la propia aplicación web hasta los más generales. En cuanto a la aplicación web, su implementación se desarrolló con una buena correspondencia con respecto a la planificación. Incluso el ahorro de tiempo en ciertos puntos permitió la adición de características inicialmente no planteadas (como las gráficas históricas). La aplicación monitoriza de forma correcta el estado de la nube, los detalles de un dispositivo y notifica de forma acertada las incidencias de una sesión. Además, posee una interfaz bastante intuitiva para el usuario y que se adapta a un amplio rango de resoluciones. Del mismo modo es compatible con las versiones más recientes de los principales navegadores. En cuanto al punto de entrada, se realizó conforme a los requerimientos del sistema, así como la guía de usuario. Por parte del sistema global (la combinación de las aplicaciones de los dos alumnos), ambas aplicaciones son capaces de establecer conexión entre ellas a través de Device Cloud en ambas direcciones (la web es capaz de monitorizar los datos enviados por la aplicación de escritorio pero también puede enviarle peticiones). El sistema cuenta con la aprobación de varios miembros de la empresa, así como con el beneplácito del Product Owner, que se ha mostrado satisfecho de los resultados obtenidos. Para finalizar, el objetivo general del proyecto se ha cumplido de forma exitosa: la realización de un sistema que permita a los potenciales clientes de Digi experimentar con su nube de dispositivos sin la necesidad de disponer de un sistema emebedido. El sistema inicialmente podrá ser usado de forma inmediata internamente por los empleados de Digi como zona de testeo. Funcionalmente es muy completo, pero requeriría de mejoras en la parte gráfica (que se escapan a las competencias del proyectante) para que estuviera disponible al público. 49

52 3.2. Problemas planteados y resolución Algunas de las soluciones aportadas para el correcto desarrollo de la aplicación se han ido planteando a lo largo del punto En esta sección se detallarán los principales problemas surgidos durante la implementación y la forma de resolverlos por parte del proyectante. Bug en App Engine Como se ha explicado en la sección de implementación, el SDK proporcionado por App Engine contiene un servidor local que permite al desarrollador hacer pruebas de la aplicación en su propio ordenador. De vez en cuando la aplicación era subida al servidor de Google para comprobar que todo funcionaba correctamente siendo accesible desde cualquier equipo. Tras un cierto nivel de desarrollo, el proyectante se encontró con que la aplicación una vez subida a App Engine no funcionaba correctamente (a pesar de sí hacerlo en local). El log de errores en App Engine aportaba muy poca información: A serious problem was encountered with the process that handled this request, causing it to exit. This is likely to cause a new process to be used for the next request to your application. If you see this message frequently, you should contact the App Engine team. (Error code 203) Por desgracia no había una solución clara en Internet y nadie en la empresa tenía excesiva experiencia en App Engine. Además, resultaba curioso cómo los recursos estáticos no devolvían este error pero todo aquello dinámico (.jsp y servlets) sí. Tras un largo periodo de pruebas de todo tipo, se intentó ir eliminando las librerías externas importadas al proyecto. Esta fue la solución, puesto que una de las librerías (que, de hecho, ni siquiera era utilizada) era la causante del conflicto. Una vez eliminada, la aplicación se mostró de forma correcta. Se intuye que al ser App Engine un entorno limitado (hay ciertas librerías Java que no permite usar) es posible que la librería eliminada contuviese algún elemento que no era de su agrado. Manejo de errores El problema más serio con el que enfrentarse a la hora de comunicarse con Device Cloud vía servicios web es el manejo de las respuestas. Todas son devueltas en formato XML, pero cuando hay un error (sea cual sea) devuelve una etiqueta <error> con el problema surgido dentro de ella. Etherios dispone de una librería propia privada para realizar peticiones a la nube, pero desafortunadamente cuando hay algún error simplemente devuelve null, siendo imposible conocer el porqué. 50

53 Esto obligó al proyectante a crear una clase Request, que contiene los métodos estáticos que necesita la aplicación para enviar peticiones. En el siguiente ejemplo se observa cómo los métodos requieren de los datos de usuario para realizarlas, así como el dominio (existen varios servidores): Inicialmente devolvían el resultado XML sin tratar, pero esto no resultaba eficaz, por lo que el siguiente paso fue la creación de tres excepciones personalizadas, contenidas en la carpeta /com.digi.exception. El objetivo de esto fue interpretar de forma mucho más sencilla el resultado de los servicios web. Los métodos de Request procesan el XML y, en caso de existir algún error, lanzan la excepción correspondiente. Esto se traduce en, por ejemplo, si se alcanza el límite de peticiones del usuario, el servlet que envía a los detalles de un dispositivo cargará la página de error en lugar de la vista de detalles. Pero el ejemplo más claro lo tenemos en los servlets que recogen información vía AJAX. Pongamos que surge algún error al actualizar el listado de dispositivos. El servlet UpdateDevices devolverá lo siguiente: Cada excepción enviará un código numérico distinto a JavaScript, de modo que será sencillo de interpretar y mostrar posteriormente la alerta adecuada al usuario: 51

54 3.3. Conocimientos adquiridos Es evidente que el desarrollo de una aplicación web ha servido al proyectante para profundizar en el desarrollo web. Aunque ya se tenían conocimientos previos del desarrollo con Java y JavaScript, este proyecto ha ayudado a ofrecer una versión mucho más extensa de estos campos. Hay que tener en cuenta que la web ha sido desarrollada por completo por el proyectante, por lo tanto también se ha adquirido una experiencia muy rica y valiosa en la parte correspondiente al diseño. Un buen diseño ayuda al programador a su posterior manipulación (y viceversa). Trabajar con frameworks como Bootstrap o Dojo permite apreciar la gran cantidad de tecnologías por conocer, lo que anima a continuar aprendiendo. En cuanto a las competencias transversales, la realización de un proyecto de cierta envergadura de forma individual ha permitido al proyectante ser capaz de resolver problemas y tomar decisiones de forma independiente. Trabajar en equipo con otro alumno también ha servido de experiencia, donde ambas partes deben llegar a acuerdos para el correcto desarrollo del sistema. También el trabajo dentro de una empresa ha resultado enriquecedor y una experiencia positiva. Por otra parte, las reuniones de planificación y de revisión con un Scrum Master han ayudado a apreciar la importancia de un buen seguimiento y comunicación de los integrantes del equipo durante el desarrollo de un proyecto. Además, se ha aprendido que el solicitante del producto (Product Owner) puede requerir cualquier cambio en cualquier momento, teniendo que estar preparado para afrontar las oportunas modificaciones. Finalmente, el trabajo en una multinacional requiere del manejo del inglés de forma escrita en ciertos momentos. Aunque para este proyecto no ha sido necesaria la comunicación oral, toda la documentación y programación se ha realizado en este idioma. El proyectante se ha acostumbrado a establecer nombres de métodos y variables en la lengua inglesa, así como los comentarios. Destacar también la escritura de la guía de usuario. Así pues, en cierto modo el proyecto ha ayudado a la adquisición de soltura en la lectura y escritura en inglés. 52

55 3.4. Mejoras del proyecto Como ya se ha indicado a lo largo de esta memoria, los objetivos del proyecto se han cumplido exitosamente, incluso añadiendo funcionalidades inicialmente no planteadas. La aplicación no queda cerrada por completo en este punto, sino que se proponen una serie de mejoras a añadir en un futuro: Mejoras en la interfaz gráfica: realizar cambios en los elementos gráficos, de forma que resulten más intuitivos y agradables al usuario que los actuales. Se necesitaría la colaboración con un diseñador gráfico para llevarlo a cabo. Adición de nuevos tipos de dispositivos simulados: la aplicación se ha diseñado de la forma más genérica posible, lo que permitiría la inclusión de nuevos tipos de dispositivos simulados si la empresa así lo solicitara. Programación de eventos: durante el proyecto, uno de los objetivos fue el envío de peticiones simples a los dispositivos simulados. La idea sería permitir al usuario enviar al dispositivo una serie de eventos encadenados, cada uno con una hora de ejecución. Creación de un diseño personalizado para dispositivos móviles: los requisitos del proyecto contemplaban la correcta visualización de la web en los navegadores principales, siempre desde un ordenador. Con esta mejora, la aplicación escogería el diseño más adecuado en función del dispositivo desde el que estuviera accediendo el usuario. 53

56 Capítulo 4. Bibliografía 1. Guía para programadores de Device Cloud: 2. Stack Overflow 3. Rebecca Murphey: Fundamentos de JQuery. Libro gratuito Documentación Bootstrap 5. W3Schools 6. Apuntes y trabajos realizados durante el Grado. 54

57 Anexos Anexo 1. Casos de uso Caso de uso Descripción Actores Precondiciones Postcondiciones Iniciar sesión Validar las credenciales de usuario en Device Cloud. Usuario. No hay. El usuario puede acceder a las funcionalidades de la aplicación. Flujo básico 1. El usuario introduce sus credenciales y pulsa el botón Login. 2. El sistema recibe los datos y los comprueba con Device Cloud. 3. Si los datos son correctos, el sistema dirige al usuario a la página visión general de sus dispositivos, Flujos alternativos y excepciones 1. Si los datos introducidos son incorrectos el sistema devolverá al usuario a la página de login. 2. Si el usuario intenta iniciar sesión de forma incorrecta en tres ocasiones, deberá completar un captcha en sucesivos intentos. Anotaciones No hay. Caso de uso Cerrar sesión Descripción Finaliza la sesión abierta en el caso de uso Iniciar sesión. Actores Usuario. Precondiciones La sesión de usuario debe estar abierta. Postcondiciones La sesión de usuario queda cerrada. Flujo básico 1. El usuario pulsa en el botón Logout de la esquina superior derecha. 2. El sistema elimina la cookie de sesión y devuelve al usuario a la página de login. Flujos alternativos y excepciones No hay. Anotaciones En referencia a la palabra sesión, hablaremos de sesión de usuario cuando nos refiramos a la sesión temporal en la aplicación web y de sesión de aplicación cuando se trate de la sesión de la aplicación de escritorio. 1

58 Caso de uso Ver sesiones creadas Descripción Muestra al usuario la sesiones creadas en la aplicación de escritorio Actores Usuario. Precondiciones La sesión de usuario debe estar abierta. El usuario se encuentra en la vista general. Postcondiciones Se muestra un modal con la lista de sesiones. Flujo básico 1. El usuario pulsa en el botón User sessions en la esquina superior derecha. 2. El sistema abre un modal con las sesiones disponibles. Las sesiones se obtienen actualizadas cada vez que el usuario realiza esta acción. Flujos alternativos y excepciones Si no existen sesiones creadas, el modal no se despliega y el usuario es informado. Anotaciones No hay. Caso de uso Descripción Actores Precondiciones Cambiar sesión El usuario cambia de sesión de aplicación a monitorizar. Usuario. La sesión de usuario debe estar abierta. El usuario se encuentra en la vista general. Postcondiciones La aplicación pasa a monitorizar la nueva sesión seleccionada. Flujo básico 1. Partimos del caso de uso Ver sesiones creadas. 2. El usuario selecciona una de las sesiones disponibles. 3. El usuario acepta la nueva sesión seleccionada. 4. El sistema cierra el modal y cambia la sesión a monitorizar. Flujos alternativos y excepciones Si el usuario deselecciona la sesión existente seleccionada, la aplicación pasará a monitorizar ninguna sesión. Anotaciones No hay. 2

59 Caso de uso Descripción Actores Precondiciones Postcondiciones Desplegar notificaciones Muestra al usuario los eventos recientes en los dispositivos. Usuario. El usuario debe haber iniciado sesión. El usuario se encuentra en la vista general. Se muestra un listado de un máximo de 10 eventos recientes. Flujo básico 1. El usuario pulsa en la barra de notificaciones de la parte superior de la vista general de dispositivos. 2. El sistema muestra un listado ordenado con los últimos eventos ocurridos en todos los dispositivos. Flujos alternativos y excepciones No hay. Anotaciones Los eventos recogidos son relativos a la sesión de usuario actual. Al cerrar la sesión el listado se borra. Caso de uso Ver historial de eventos Descripción Muestra todo el historial de eventos de los dispositivos en una página aparte. Actores Usuario. Precondiciones El usuario debe haber iniciado sesión. El usuario se encuentra en la vista general. Postcondiciones Se muestra un listado completo de eventos. Flujo básico 1. Partimos de la situación del caso de uso Desplegar notificaciones. 2. En la parte inferior del listado, el sistema muestra el botón View all events. 3. El usuario pulsa el botón View all events. 4. El sistema abre una nueva pestaña con un listado completo de todos los eventos ocurridos durante la duración de la sesión de usuario. Flujos alternativos y excepciones No hay. Anotaciones Los eventos recogidos son relativos a la sesión de usuario actual. Al cerrar la sesión el listado se borra. 3

60 Caso de uso Ver detalles de dispositivo Descripción Muestra en detalle el estado y características de un dispositivo simulado. Actores Usuario. Precondiciones El usuario debe haber iniciado sesión. El usuario debe encontrarse en la vista general. El dispositivo debe ser simulado Postcondiciones Se muestran los detalles del dispositivo. Flujo básico 1. Dentro de la vista general, el usuario pulsa en un dispositivo simulado. El usuario puede pulsar tanto en el dispositivo en la vista en mosaico como en la botón Details en la vista en tabla. 2. El sistema valida el dispositivo, recoge sus datos y abre una pestaña nueva con los detalles del mismo. En función del tipo de dispositivo simulado se abrirá una u otra vista (inicialmente, un tanque o un camión). Flujos alternativos y excepciones Si el usuario intenta acceder a la vista de detalles con un ID inexistente o de un dispositivo real visualizará una página de error. Anotaciones El dispositivo debe ser simulado. Aunque en la vista general también aparezcan los dispositivos reales, no disponen de acceso a la vista de detalles. 4

61 Anexo 2. Plan de test completo Device Cloud Explorer Web Application Tests Date: 12/05/2014 Description: Tests we run in the web application of Device Cloud Explorer Test Case ID Group Test Name Commands / Description Result 1 Downloads Desktop application Click on the download button and obtain the desktop application correctly Passed 2 Documentation User guide Review the user guide Passed 3 Navigation Show user guide Show the user guide in a new tab when the user click on the corresponding button in the entry point Passed 4 Navigation Web application access Open the login page in a new tab when the user pushes the corresponding button in the entry point. If the user is already logged, it must be redirected to the devices' view Passed 5 Navigation Login Allow the user to access if his credentials are correct. Test all the domains. Passed 6 Navigation Device details Click on a device (in mosaic, table or map view). If the device is simulated, its details must be displayed in a new tab. Passed 5

62 7 Navigation View all notifications Select an open session in devices' view. Click on the notifications icon. Click on the "view all notifications" button. The notifications log must be displayed in a new tab. Passed 8 Navigation View device configuration Open the details of a connected simulated device. Click on the "view device configuration" button. The device configuration must be displayed in a new tab. Passed 9 Navigation View device log 10 Navigation Logout Open the details of a connected simulated device. Click on the "make a SCI request" button. Select the "view device's log" option and submit. The device's log must be displayed in a new tab. Push the "Welcome, USER" link in the upper right corner. Select "logout". The web application must redirect to the login page. Passed Passed 11 Main view updates Devices' updates The list of devices must be updated according to the status of Device Cloud and the desktop application. It's included here mosaic, table and map view. Passed 11 Main view updates Coincident information The data displayed in mosaic and table view must be the same Passed 13 Main view updates Updates in notifications Select a session. Trigger different events. The web application must notify about them: - Session opened/closed. - Simulated device added/removed. - Simulated device connected/disconnected. - Tank filled/emptied. - Truck finish its route. Passed Main view updates Main view graphics Errors in updates Stand out a device When an error occurs, a non intrusive message must be displayed on the top of the page with the corresponding problem: - Request limit. - Connection error. - Parser error. - User not logged. - Put the mouse over a simulated device in table or mosaic view. The corresponding marker must increase its size temporarily. - Put the mouse over a marker in the map. The corresponding device in mosaic or table view must be stood out. Passed Passed 6

63 16 Main view graphics Show only devices in session 17 Details updates Device's updates 18 Details updates Disconnection Select a session By default, only devices in the selected session must be displayed. Click on the "show only devices in session" checkbox. All devices must be displayed. Go to the details of a simulted devices from main view. The information about the device must be updated correctly according to the data requested from Device Cloud, both text information and graphic elements. The web application must disable some actions in the details of a simulated device when it's disconnected. Specifically: - Open the device configuration. - Make SCI requests. - Change a component. Likewise, when the device connects this features must be allowed again. Passed Passed Passed 19 Details requests Open device configuration Open the details of a connected simulated device. Push on the "view device config" button. A new tab must be displayed with the device configuration. Passed 20 Details requests Disconnect device Open the details of a connected simulated device. Push on the "make a SCI request" button. Select "disconnect device" in the dropdown list and submit. The device must disconnect immediately. Passed 21 Details requests View device log Open the details of a connected simulated device. Push on the "make a SCI request" button. Select "view log" in the dropdown list and submit. A new tab must be displayed with the device log. Passed 22 Details requests Update firmware Open the details of a connected simulated device. Push on the "make a SCI request" button. Select "update firmware" in the dropdown list. Select a binary file lower than 2MB and accept. If the upload is successful, the page must be reloaded immediately Passed 23 Details requests Change temperature Open the details of a connected simulated device. Introduce a different temperature than current in the input under the thermostate. The value must be between -20 and 200. Click on "change temperature". If the request is successful, the device temperature must start to achieve the target value. Passed 24 Details requests Change valves Open the details of a connected tank. Push on a valve. If the request is successful, the valve must change immediately. Passed 7

64 25 Charts Change between charts Open the details of a simulated device. Click on the features which changes the mouse to a pointer in the left middle. The corresponding chart must be displayed in the right of the page. Passed 26 Charts Change between time lapses Open the details of a simulated device. Click on the buttons below the chart displayed. The chart must change according to the time lapse selected. Passed 27 Graphics Responsive design Test the application in different resolutions. All the elements must appear correctly independently on the resolution Passed 8

65 Anexo 3. Guía de usuario de la aplicación web Web Application Requirements You can access to the web from any computer with a recent version of one of those browsers: Google Chrome, Mozilla Firefox or Internet Explorer. We also recommend visualizing the web with a minimum resolution of 1280x1024. There may not be a problem to navigate with an inferior resolution, but you will probably have little visualization problems. Login To monitor and control the simulated devices created in the desktop application is recommended to access to the Device Cloud Explorer. Simply clicking in this image you will access to the login page. The login credentials must be the same as the used for the desktop application (because the simulated devices are related to the account). 9

66 The main view Once logged into the web, you will have a general view of all the devices registered in your Device Cloud account. If it s the first time you log into the web and you haven t created any session in the desktop application, a welcome page will be displayed, inviting you to create sessions from the application. Otherwise, a popup will be displayed with all the simulated sessions created. You can select one of them or explore the page without selecting any. Parts of the main view In the middle left of the page you will have a list of all your devices, by default in a mosaic view. You can alternate between the mosaic and the table view clicking on this buttons. In the middle right of the page, each marker represents the position of a simulated device in the world map. 10

67 In the upper right corner, clicking on your name, a dropdown list will appear. Here, you will be able to select another session of the desktop application or logout from the web page. Finally, this icon notifies about new events occurred in a desktop application session. To make it work, you will need to have a session selected. Otherwise, it won't alert about anything. Monitoring a session Once you have selected a session, the box in the top bar will change its state. If the selected session is opened in the desktop application, the notifications icon will start to announce any event that occurs from this moment. In addition, clicking on the icon, this button will appear in the bottom of the events list. Clicking on this button, a new tab will be opened in the browser, showing you a complete list of all events that has occurred from the moment that the selected session has been opened (when the session is closed, this list is cleared from the desktop application). Devices filter When you have a session selected, this checkbox appears: Clicking on it will allow the user to alternate between see all the registered devices or only those which pertain to the selected session (this is applied both mosaic view, table view and map view). 11

68 Updates If you have already logged in to the page, it s probably that you have noticed this in the top bar: This counter tells the user how many seconds are left until the next update. Because of the limitation of Device Cloud, this time span is set to 20 seconds. So the information displayed about the devices isn t in real time, it might have a little delay. Details view Access to the details view is as simple as click on one of those options: 1. Clicking on the container in the mosaic view. 2. Clicking on the details image in the table view. 3. Clicking on the marker in the map view. As soon as you click, a new tab will be opened with the details of the selected simulated device. NOTE: You cannot access to the details of a device that hasn't been created with the "Device Cloud Simulator". NOTE: The updates, the same way as in main view, will be produced each 20 seconds. 12

69 Common parts of the details view Generic data Tank and truck views have some similarities. They can be divided in two sections: The middle left of the page shows information about the concrete device selected by the user. In the upper part you can see generic data of the device (Name, ID, Location and Connection). Also you can see the firmware level, below the image. Relative data The data displayed below the generic information is relative to each simulated device. If you put the mouse over some of this features, you will notice that the cursor changes to a pointer. Clicking on those features will change the chart in the bottom right corner to the corresponding feature. Charts The charts display all the data collected in Device Cloud from a simulated device. By default, the page shows a chart including from the first value collected to the present. To facilitate the user to understand the chart, it has some buttons to select a certain time span. 13

70 Configuration file If the device is connected, you will be able to click on this button. A new tab will be displayed, which shows the configuration file of the device without format. SCI Requests The same way as in Configuration file button, you will need to have the device connected to access to this feature. Clicking on it this popup will be displayed: You can choose the request in the dropdown list. The available options are: Disconnection: sends a request to disconnect the device immediately. If the request is successful, you will be advised at the moment. View log: similar to configuration file, shows the events log of the device. Update firmware: sending a less than 2MB binary file will produce a firmware update in the device. If the checkbox is selected, all the devices of the same type will be updated. If the update is completed successfully, the page will be reloaded immediately. 14