TRABAJO FIN DE GRADO. Web Application for Device Cloud Explorer

Tamaño: px
Comenzar la demostración a partir de la página:

Download "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

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 https://devicecloudexplorer.appspot.com/ 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 1 https://developers.google.com/appengine/docs/java/config/appconfig 34

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 https://devicecloudexplorer.appspot.com. 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. 4. 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

TRABAJO FIN DE GRADO. Desktop Application for Device Cloud Explorer

TRABAJO FIN DE GRADO. Desktop Application for Device Cloud Explorer TRABAJO FIN DE GRADO Título Desktop Application for Device Cloud Explorer Autor/es Jesús Nieto Cuartero Director/es Juan José Olarte Larrea Facultad Facultad de Ciencias, Estudios Agroalimentarios e Informática

Más detalles

TFM Comunicación, Redes y Gestión de Contenidos

TFM Comunicación, Redes y Gestión de Contenidos TFM Comunicación, Redes y Gestión de Contenidos Aplicación móvil hibrida para control de asistencia y servicio técnico a domicilio y gestión de partes de trabajo Autor: Patricia Paguay Lara Tutorizado

Más detalles

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 4: Servicios de Internet. FTP

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 4: Servicios de Internet. FTP Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows Módulo 4: Servicios de Internet. FTP Aulas en red. Aplicaciones y servicios. Windows Servicio FTP Con anterioridad, en este mismo módulo

Más detalles

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012 TFC J2EE Aplicación Web para la gestión de facturación de una empresa de cerrajería Sara Gutiérrez Melero ITIG Junio de 2012 Consultor: Jose Juan Rodriguez Índice 1. Introducción Objetivos Planificación

Más detalles

PROYECTO FINAL DE CARRERA: RESERVA DE VEHÍCULOS MEDIANTE INTERFAZ WEB

PROYECTO FINAL DE CARRERA: RESERVA DE VEHÍCULOS MEDIANTE INTERFAZ WEB PROYECTO FINAL DE CARRERA: RESERVA DE VEHÍCULOS MEDIANTE INTERFAZ WEB Ingeniería Técnica Informática de Gestión Alumno: Jorge Bou Ramón Director: Sergio Sáez Barona Junio 2012 ÍNDICE 1. INTRODUCCIÓN...4

Más detalles

Prácticas de Programación Multimedia.

Prácticas de Programación Multimedia. Prácticas de Programación Multimedia. Las prácticas de la asignatura Programación Multimedia van a consistir en el diseño de un sitio web con distintos contenidos multimedia sobre el que se irán añadiendo

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 6. Actualización

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC297_2 Versión 6 Situación Contraste externo Actualización

Más detalles

- MANUAL TÉCNICO - Software de diagnóstico de la seguridad de la información y autoimplantación de LOPD. Rev. 01- FEBRERO 2013

- MANUAL TÉCNICO - Software de diagnóstico de la seguridad de la información y autoimplantación de LOPD. Rev. 01- FEBRERO 2013 - MANUAL TÉCNICO - Software de diagnóstico de la seguridad de la información y autoimplantación de LOPD Rev. 01- FEBRERO 2013 Software de diagnóstico de la seguridad de la información y autoimplantación

Más detalles

Especialista en Creación de Portales Web con Joomla 3.3

Especialista en Creación de Portales Web con Joomla 3.3 Especialista en Creación de Portales Web con Joomla 3.3 TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Especialista en Creación de Portales Web

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

IVista: es la interfaz con la que el Presentador se comunica con la vista.

IVista: es la interfaz con la que el Presentador se comunica con la vista. Capítulo 3 MODELO DE DISEÑO 3.1 Arquitectura Modelo-Vista-Presentador La arquitectura Modelo-Vista-Presentador (MVP) [11] separa el modelo, la presentación y las acciones basadas en la interacción con

Más detalles

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 18 CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC297_2 Versión 5 Situación RD 1201/2007 Actualización

Más detalles

Trabajo Final de Grado

Trabajo Final de Grado Grado en Ingeniería Informática Trabajo Final de Grado Desarrollo de una aplicación para mostrar gráficamente datos de uso del producto de realidad aumentada DOING3D Autor: Xavier Cano Ebrí Supervisor:

Más detalles

Framework para el desarrollo ágil de aplicaciones

Framework para el desarrollo ágil de aplicaciones Framework para el desarrollo ágil de aplicaciones 1 Índice INTRODUCCIÓN... 3 QUÉ ES UN FRAMEWORK?... 3 VENTAJAS DE UTILIZAR UN FRAMEWORK... 4 DESVENTAJAS DE UTILIZAR UN FRAMEWORK... 5 CARACTERÍSTICAS DE

Más detalles

Desarrollo de Aplicaciones con Tecnologías Web

Desarrollo de Aplicaciones con Tecnologías Web Desarrollo de Aplicaciones con Tecnologías Web Código: Modalidad: Distancia Duración: 100 Horas. Objetivos: La presente formación se ajusta al itinerario formativo del Certificado de Profesionalidad IFCD0210

Más detalles

Módulo Profesional 01: Bases de datos (código: 0484).

Módulo Profesional 01: Bases de datos (código: 0484). Módulo Profesional 01: Bases de datos (código: 0484). Actividades de enseñanza-aprendizaje que permiten alcanzar los objetivos del módulo. Interpretar diseños lógicos de bases de datos. Realizar el diseño

Más detalles

Gestionando Agile/Scrum con Sciforma

Gestionando Agile/Scrum con Sciforma agile Gestionando Agile/Scrum con Sciforma El desarrollo ágil de software son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones

Más detalles

CURSOS DE VERANO 2014

CURSOS DE VERANO 2014 CURSOS DE VERANO 2014 CLOUD COMPUTING: LA INFORMÁTICA COMO SERVICIO EN INTERNET LA PLATAFORMA GOOGLE CLOUD PLATFORM. GOOGLE APP ENGINE Pedro A. Castillo Valdivieso Universidad de Granada http://bit.ly/unia2014

Más detalles

MANUAL DE AYUDA INFORMATIVAS MAC/OSX

MANUAL DE AYUDA INFORMATIVAS MAC/OSX MANUAL DE AYUDA INFORMATIVAS MAC/OSX Agencia Tributaria CENTRO DE ATENCIÓN TELEFÓNICA DEPARTAMENTO DE INFORMÁTICA TRIBUTARIA ÍNDICE PLATAFORMA DE INFORMATIVAS INTRODUCCIÓN... 4 Requisitos mínimos... 4

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Sage CRM. 7.2 Guía de autoservicio

Sage CRM. 7.2 Guía de autoservicio Sage CRM 7.2 Guía de autoservicio Copyright 2013 Sage Technologies Limited, editor de este trabajo. Todos los derechos reservados. Quedan prohibidos la copia, el fotocopiado, la reproducción, la traducción,

Más detalles

ACCESS 2013 EN PROFUNDIDAD

ACCESS 2013 EN PROFUNDIDAD ACCESS 2013 EN PROFUNDIDAD María Pérez Marqués Access 2013 en profundidad María Pérez Marqués ISBN: 978-84-941801-2-5 EAN: 9788494180125 IBIC: UNSC Copyright 2014 RC Libros RC Libros es un sello y marca

Más detalles

Confección y publicación de páginas Web

Confección y publicación de páginas Web 2014 Confección y publicación de páginas Web Docente: Manuel Fernández Catalán 0 ÍNDICE 1 Presentación... 2 2 Objetivos... 2 3 Tecnología... 2 4 Metodología y evaluación... 3 5 Material didáctico... 3

Más detalles

CA ARCserve Backup Patch Manager para Windows

CA ARCserve Backup Patch Manager para Windows CA ARCserve Backup Patch Manager para Windows Guía del usuario r16 Esta documentación, que incluye sistemas incrustados de ayuda y materiales distribuidos por medios electrónicos (en adelante, referidos

Más detalles

PFC- Aplicaciones Web para trabajo colaborativo:

PFC- Aplicaciones Web para trabajo colaborativo: PFC- Aplicaciones Web para trabajo colaborativo: Aplicación para Control de una Integración de S.I. 2º Ciclo Ingeniería Informática Curso 2011-2012 Consultor : Fatos Xhafa Autor : Miguel Angel Pineda Cruz

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

DIRECCIÓN DE SISTEMAS DE INFORMACIÓN DEPARTAMENTO CERES

DIRECCIÓN DE SISTEMAS DE INFORMACIÓN DEPARTAMENTO CERES DIRECCIÓN DE SISTEMAS DE INFORMACIÓN DEPARTAMENTO CERES SERVICIO DE NOTIFICACIONES ELECTRÓNICAS Y DIRECCIÓN ELECTRÓNICA HABILITADA MANUAL DE CONFIGURACIÓN PARA SISTEMAS WINDOWS NOMBRE FECHA Elaborado por:

Más detalles

Desarrollo de Aplicaciones con Tecnologías Web (Online) (Dirigida a la Acreditación de las Competencias Profesionales R.D.

Desarrollo de Aplicaciones con Tecnologías Web (Online) (Dirigida a la Acreditación de las Competencias Profesionales R.D. Desarrollo de Aplicaciones con Tecnologías Web (Online) (Dirigida a la Acreditación de las Competencias Profesionales R.D. 1224/2009) Titulación certificada por EUROINNOVA BUSINESS SCHOOL Desarrollo de

Más detalles

BOLETÍN DE NOVEDADES Barcelona, junio de 2006

BOLETÍN DE NOVEDADES Barcelona, junio de 2006 BOLETÍN DE NOVEDADES Barcelona, junio de 2006 Introducción El objeto de este documento es presentar y describir brevemente las principales actuaciones en los últimos meses de Carver en algunos de sus clientes,

Más detalles

Introducción a AJAX y visión global de la práctica

Introducción a AJAX y visión global de la práctica Introducción a AJAX y visión global de la práctica Modelo de aplicaciones Web clásico (1) La mayor parte de las interacciones del usuario causan una petición HTTP al servidor Web El servidor Web procesa

Más detalles

DESCRIPCIONES TÉCNICAS 17 DISEÑO WEB

DESCRIPCIONES TÉCNICAS 17 DISEÑO WEB 2015 DESCRIPCIONES TÉCNICAS 17 DISEÑO WEB INTRODUCCIÓN AMETIC y Microsoft asumen la coordinación y el patrocinio de la Competición Nacional de Formación Profesional, Spainskills 2015, en lo concerniente

Más detalles

Introducción a WebMathematica

Introducción a WebMathematica Introducción a WebMathematica WebMathematica es una nueva tecnología que permite la generación de contenido web dinámico con Mathematica. Se integra en Mathematica a través de un servidor web. WebMathematica

Más detalles

Nombre. El nombre corto del recurso. Éste será mostrado en la página principal de curso.

Nombre. El nombre corto del recurso. Éste será mostrado en la página principal de curso. 4.4. ENLAZAR UN ARCHIVO O UNA PÁGINA WEB 4.4.1. Características El contenido de un curso no sólo se limita a los creados mediante los editores de Moodle, puesto que este tipo de recursos permite enlazar

Más detalles

IFCD0210 Desarrollo de Aplicaciones con Tecnologías Web (Dirigida a la Acreditación de las Comptencias Profesionales R.D.

IFCD0210 Desarrollo de Aplicaciones con Tecnologías Web (Dirigida a la Acreditación de las Comptencias Profesionales R.D. IFCD0210 Desarrollo de Aplicaciones con Tecnologías Web (Dirigida a la Acreditación de las Comptencias Profesionales R.D. 1224/2009) IFCD0210 Desarrollo de Aplicaciones con Tecnologías Web (Dirigida a

Más detalles

Manual de usuario v.3.2.2. Noviembre 2014 MINISTERIO DE ECONOMÍA Y HACIENDA SECRETARÍA DE ESTADO DE PRESUPUESTOS Y GASTOS

Manual de usuario v.3.2.2. Noviembre 2014 MINISTERIO DE ECONOMÍA Y HACIENDA SECRETARÍA DE ESTADO DE PRESUPUESTOS Y GASTOS MINISTERIO DE ECONOMÍA Y HACIENDA DE PRESUPUESTOS Y GASTOS Subdirección General de Aplicaciones de Contabilidad y Control Manual de usuario v.3.2.2 Noviembre 2014 CORREO ELECTRÓNICO CSC@igae.meh.es ÍNDICE

Más detalles

ACCIÓN FORMATIVA FINANCIADA POR EL SERVICIO PÚBLICO DE EMPLEO ESTATAL

ACCIÓN FORMATIVA FINANCIADA POR EL SERVICIO PÚBLICO DE EMPLEO ESTATAL MF0491_3: PROGRAMACIÓN WEB EN EL ENTORNO CLIENTE. (IFCD0210: DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB) 180 HORAS PRESENCIALES Nº DE EXPEDIENTE: FC/2013/0064 ACCION 141 GRUPO 1 ACCIÓN FORMATIVA FINANCIADA

Más detalles

MAESTRO DE PHP PHP NIVEL 1

MAESTRO DE PHP PHP NIVEL 1 MAESTRO DE PHP MAESTRO DE PHP es el curso más completo diseñado para que aprendas desde 0 hasta poder desarrollar aplicaciones robustas utilizando Frameworks. Incluye los Cursos PHP Nivel 1 y PHP Avanzado

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

Historia de revisiones

Historia de revisiones Herbert Game Descripción de la Arquitectura Versión 1.8 Historia de revisiones Fecha Versión Descripción Autor 29/08/2011 1.0 Creación del documento Juan Pablo Balarini Máximo Mussini 30/08/2011 1.1 Actualización

Más detalles

Joomla! 3.3 Cree y administre sus sitios Web

Joomla! 3.3 Cree y administre sus sitios Web Capítulo 1: Descubrir Joomla! A. Razones para crear un sitio con Joomla! 9 B. Documentarse sobre Joomla! 9 C. La hoja de ruta de Joomla! 10 D. Qué es un CMS? 12 E. HTML y XHTML 12 F. Diferenciar el contenido

Más detalles

Capítulo I. Marco Teórico

Capítulo I. Marco Teórico 1 Capítulo I. Marco Teórico 1. Justificación Hoy en día existe una gran diversidad de aplicaciones que corren sobre la World Wide Web (WWW o Web), y cada una orientada a un fin en particular, el cuál depende

Más detalles

- MANUAL TÉCNICO - Implantación de software de Marketing Online

- MANUAL TÉCNICO - Implantación de software de Marketing Online - MANUAL TÉCNICO - Implantación de software de Marketing Online Rev. 01- MAYO 2013 Implantación de software de Marketing Online Teléfono Adeada: 945 253 388 Email Adeada: adeada@adeada.com REALIZADO POR:

Más detalles

Adobe Dreamweaver CS3 - Curso online Creación profesional de sitios web

Adobe Dreamweaver CS3 - Curso online Creación profesional de sitios web Adobe Dreamweaver CS3 - Curso online Creación profesional de sitios web Índice Conceptos básicos En este capítulo se enseñan los conceptos básicos de trabajo en Adobe Dreamveaver CS3. También se describen

Más detalles

MS_20488 Developing Microsoft SharePoint Server 2013 Core Solutions

MS_20488 Developing Microsoft SharePoint Server 2013 Core Solutions S MS_20488 Developing Microsoft SharePoint Server 2013 Core Solutions www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción En este

Más detalles

Ministerio de Educación,Cultura y Deporte. Aulas en Red.Aplicaciones y servicios Windows. Módulo 3: Gestión de equipos.

Ministerio de Educación,Cultura y Deporte. Aulas en Red.Aplicaciones y servicios Windows. Módulo 3: Gestión de equipos. Ministerio de Educación,Cultura y Deporte. Aulas en Red.Aplicaciones y servicios Windows Módulo 3: Gestión de equipos. Escritorio Remoto Aulas en red. Aplicaciones y servicios. Windows Escritorio Remoto

Más detalles

DESCRIPCIÓN ESPECÍFICA NÚCLEO: COMERCIO Y SERVICIOS SUBSECTOR: INFORMÁTICA

DESCRIPCIÓN ESPECÍFICA NÚCLEO: COMERCIO Y SERVICIOS SUBSECTOR: INFORMÁTICA DESCRIPCIÓN ESPECÍFICA NÚCLEO: COMERCIO Y SERVICIOS SUBSECTOR: INFORMÁTICA Nombre del Módulo: DISEÑO DE PAGINAS WEB CON HTML Código: CSTI0085 total: 3 Horas Objetivo General: Construir páginas Web en base

Más detalles

Versión 4.0 BOLETÍN (ABRIL 2010) a2 Herramienta Administrativa Configurable (Arquitectura Cliente Servidor) a2 softway C. A.

Versión 4.0 BOLETÍN (ABRIL 2010) a2 Herramienta Administrativa Configurable (Arquitectura Cliente Servidor) a2 softway C. A. Versión 4.0 BOLETÍN (ABRIL 2010) a2 Herramienta Administrativa Configurable (Arquitectura Cliente Servidor) a2 softway C. A. VERSIÓN 4.0 a2 Herramienta Administrativa Configurable e-mail a2softway@cantv.net

Más detalles

Guía de instalación de los complementos de integración de Python y R en SPSS Statistics

Guía de instalación de los complementos de integración de Python y R en SPSS Statistics www.metodo.uab.cat Estudios de postgrado en Metodología de la investigación en Ciencias de la Salud Guía de instalación de los complementos de integración de Python y R en SPSS Statistics Tabla de contenidos

Más detalles

TRABAJO FIN DE ESTUDIOS

TRABAJO FIN DE ESTUDIOS TRABAJO FIN DE ESTUDIOS PROYECTO FIN DECARRERA Sitio web y aplicación para la gestión de una tienda de bellas artes Tania De Pedro Sáenz Tutor: Beatriz Pérez Valle Curso 2011-2012 Sitio web y aplicación

Más detalles

Desarrollo de Aplicaciones Móviles. Java

Desarrollo de Aplicaciones Móviles. Java Java Java es la base para prácticamente todos los tipos de aplicaciones de red, además del estándar global para desarrollar y distribuir aplicaciones móviles y embebidas, juegos, contenido basado en web

Más detalles

UNIVERSIDAD TECNOLÓGICA PRIVADA DE SANTA CRUZ FACULTAD DE CIENCIAS Y TECNOLOGIA. CARRERA: Ingeniería en Sistemas

UNIVERSIDAD TECNOLÓGICA PRIVADA DE SANTA CRUZ FACULTAD DE CIENCIAS Y TECNOLOGIA. CARRERA: Ingeniería en Sistemas UNIVERSIDAD TECNOLÓGICA PRIVADA DE SANTA CRUZ FACULTAD DE CIENCIAS Y TECNOLOGIA CARRERA: Ingeniería en Sistemas Perfil de Tesis para Proyecto Empresarial Aplicación para mejorar la evaluación del desempeño

Más detalles

Integración de Metodologías Ágiles en el Desarrollo de un Sistema de Monitoreo Inalámbrico para Medir la Contaminación del Aire en Tiempo Real.

Integración de Metodologías Ágiles en el Desarrollo de un Sistema de Monitoreo Inalámbrico para Medir la Contaminación del Aire en Tiempo Real. Integración de Metodologías Ágiles en el Desarrollo de un Sistema de Monitoreo Inalámbrico para Medir la Contaminación del Aire en Tiempo Real. Walter Fuertes, Diego Carrera, César Villacís, Fernando Galárraga,

Más detalles

Sage CRM. Sage CRM 7.3 Guía de Mobile

Sage CRM. Sage CRM 7.3 Guía de Mobile Sage CRM Sage CRM 7.3 Guía de Mobile Copyright 2014 Sage Technologies Limited, editor de este trabajo. Todos los derechos reservados. Quedan prohibidos la copia, el fotocopiado, la reproducción, la traducción,

Más detalles

MANUAL DE AYUDA INFORMATIVAS MAC/OSX

MANUAL DE AYUDA INFORMATIVAS MAC/OSX MANUAL DE AYUDA INFORMATIVAS MAC/OSX Agencia Tributaria Centro de Atención Telefónica Departamento de INFORMÁTICA TRIBUTARIA ÍNDICE PLATAFORMA DE INFORMATIVAS INTRODUCCIÓN... 4 Requisitos mínimos... 4

Más detalles

online Master Programación Java SE y Java EE

online Master Programación Java SE y Java EE online Master Programación Java SE y Java EE Objetivos Mejorar las competencias en todo lo relacionado con Visual studio.net y su framework para trabajar con componentes Windows y Web, crear aplicaciones

Más detalles

CL_50466 Windows Azure Solutions with Microsoft Visual Studio 2010

CL_50466 Windows Azure Solutions with Microsoft Visual Studio 2010 Windows Azure Solutions with Microsoft Visual Studio 2010 www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción Este curso es una introducción

Más detalles

Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web

Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web Proyecto Propio de Ampliación con Programación de Dispositivos Móviles e Inteligentes Paseo de la Puerta del Ángel, s/n 28011 Madrid www.iesellago.net

Más detalles

INTRODUCCIÓN AL WEB. Pag. 1 de 10

INTRODUCCIÓN AL WEB. Pag. 1 de 10 INTRODUCCIÓN AL WEB La World Wide Web o simplemente WWW o Web es uno de los métodos más importantes de comunicación que existe en Internet. Consiste en un sistema de información basado en Hipertexto (texto

Más detalles

Bienvenidos a la presentación: Introducción a conceptos básicos de programación.

Bienvenidos a la presentación: Introducción a conceptos básicos de programación. Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los

Más detalles

ESCUELA SUPERIOR DE INGENIERÍA

ESCUELA SUPERIOR DE INGENIERÍA ESCUELA SUPERIOR DE INGENIERÍA INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN Sistema móvil para la gestión de vehículos David Borrego Gutiérrez Manuel Palomo Duarte Lorena Gutiérrez Madroñal 2 Índice general

Más detalles

MANUAL DE AYUDA INFORMATIVAS WINDOWS

MANUAL DE AYUDA INFORMATIVAS WINDOWS MANUAL DE AYUDA INFORMATIVAS WINDOWS Agencia Tributaria CENTRO DE ATENCIÓN TELEFÓNICA DEPARTAMENTO DE INFORMÁTICA TRIBUTARIA ÍNDICE PLATAFORMA DE INFORMATIVAS INTRODUCCIÓN... 4 Requisitos mínimos... 4

Más detalles

Cookbook Creando un Proyecto Android (ADT-Eclipse)

Cookbook Creando un Proyecto Android (ADT-Eclipse) Cookbook Creando un Proyecto Android (ADT-Eclipse) ALONSO PARRA CESAR VIELMA FREDDY RONDON JOSE MARQUEZ Alienx9889 * cesarvielma * spantons * joseangel2212 * * @gmail.com Universidad de Los Andes Escuela

Más detalles

Curso de Técnico Superior Diseño Web Profesional con Dreamweaver CS6

Curso de Técnico Superior Diseño Web Profesional con Dreamweaver CS6 Modalidad Curso de Técnico Superior Diseño Web Profesional con Dreamweaver CS6 cod / EU 0518 A Distancia Duración 300 Horas Objetivos Aportar al alumno todas las competencias y conocimientos necesarios

Más detalles

TÉCNICO PROFESIONAL EN DISEÑO WEB PROFESIONAL CON DREAMWEAVER CS6

TÉCNICO PROFESIONAL EN DISEÑO WEB PROFESIONAL CON DREAMWEAVER CS6 Modalidad: Distancia Duración: 77 Horas Objetivos: En la actualidad Dreamweaver es uno de los principales programas utilizados por los profesionales para el diseño y maquetación de páginas web. Estos materiales

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

Gestión Web De Alojamiento Vacacional

Gestión Web De Alojamiento Vacacional Escola Tècnica Superior d Enginyeria Informàtica Universitat Politècnica de València Gestión Web De Alojamiento Vacacional Proyecto Final de Carrera Ingeniería Técnica en Informática de Sistemas Autor:

Más detalles

Entregable 1 INGENIERÍA DEL SOFTWARE II

Entregable 1 INGENIERÍA DEL SOFTWARE II Entregable 1 INGENIERÍA DEL SOFTWARE II Pablo Azaña Sánchez Alicia García Yébenes Javier Matas de Haro Roberto Pozuelo Domínguez José Carlos Rodríguez del Salado EQUIPO FÍSICO El equipo físico de la empresa

Más detalles

Mejora en la compartición de recursos basada en Cloud Computing para el Grado en Informática en Sistemas de Información (Proyecto ID2012/099)

Mejora en la compartición de recursos basada en Cloud Computing para el Grado en Informática en Sistemas de Información (Proyecto ID2012/099) Memoria del Proyecto de Innovación Docente Titulado: Mejora en la compartición de recursos basada en Cloud Computing para el Grado en Informática en Sistemas de Información (Proyecto ID2012/099) Profesor

Más detalles

Reproductor Multimedia Streaming v0.1

Reproductor Multimedia Streaming v0.1 Reproductor Multimedia Streaming v0.1 Joaquín Gutiérrez Gil Universidad Pablo de Olavide Ingeniería Técnica en Informática de Gestión Asignatura Proyecto Introducción El presente documento trata sobre

Más detalles

Proyecto Final de Carrera

Proyecto Final de Carrera Aplicación de gestión de proyectos informáticos Memoria del Proyecto Consultor: Jairo Sarrias Guzmán Ingeniería Técnica Informática de Gestión P á g i n a 2 CONTENIDO 1. Introducción... 6 1.1. Resumen...

Más detalles

SELENIUM MANUAL DE INSTALACIÓN Y USO

SELENIUM MANUAL DE INSTALACIÓN Y USO UNIVERSIDAD DEL VALLE FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN PROGRAMA DE INGENIERÍA DE SISTEMAS SELENIUM MANUAL DE INSTALACIÓN Y USO Desarrollado por: JAIR HERNANDO VIDAL

Más detalles

MANUAL DE AYUDA INFORMATIVAS WINDOWS

MANUAL DE AYUDA INFORMATIVAS WINDOWS MANUAL DE AYUDA INFORMATIVAS WINDOWS Agencia Tributaria CENTRO DE ATENCIÓN TELEFÓNICA DEPARTAMENTO DE INFORMÁTICA TRIBUTARIA ÍNDICE PLATAFORMA DE INFORMATIVAS INTRODUCCIÓN... 4 Requisitos mínimos... 4

Más detalles

Plantilla para las VIII Jornadas de SIG libre.

Plantilla para las VIII Jornadas de SIG libre. VIII JORNADAS DE SIG LIBRE Plantilla para las VIII Jornadas de SIG libre. M. Arias de Reyna Domínguez (1) (1) Ingeniera Informática, GeoCat bv, Bennekom, Países Bajos, maria.arias@geocat.net RESUMEN GeoCat

Más detalles

Especialidad en Programación de Sistemas con Visual C# y Objective-C

Especialidad en Programación de Sistemas con Visual C# y Objective-C Especialidad en Programación de Sistemas con Visual C# y Objective-C Carga Lectiva: 700 horas Formación técnica y certificación: 200 horas El alumno realiza la formación técnica utilizando las últimas

Más detalles

MANUAL DE AYUDA INFORMATIVAS WINDOWS

MANUAL DE AYUDA INFORMATIVAS WINDOWS MANUAL DE AYUDA INFORMATIVAS WINDOWS Agencia Tributaria Centro de Atención Telefónica Departamento de INFORMÁTICA TRIBUTARIA ÍNDICE PLATAFORMA DE INFORMATIVAS INTRODUCCIÓN...4 Requisitos mínimos... 4 Requisitos

Más detalles

DISEÑO DEL SISTEMA INSTITUCIONAL DE PRÁCTICAS LABORALES

DISEÑO DEL SISTEMA INSTITUCIONAL DE PRÁCTICAS LABORALES DISEÑO DEL SISTEMA INSTITUCIONAL DE PRÁCTICAS LABORALES ETAPA: SISTEMA DE INFORMACIÓN PARA LA GESTIÓN DEL PROCESO DE PRÁCTICAS PROFESIONALES ENTORNO VIRTUAL DE PRÁCTICAS PROFESIONALES Esta Publicación

Más detalles

Soluciones de Cartografía, GIS y Teledetección www.tycgis.com CURSO DE CREACIÓN DE APLICACIONES API DE JAVASCRIPT Y ARCGIS SERVER

Soluciones de Cartografía, GIS y Teledetección www.tycgis.com CURSO DE CREACIÓN DE APLICACIONES API DE JAVASCRIPT Y ARCGIS SERVER CURSO DE CREACIÓN DE APLICACIONES API DE JAVASCRIPT Y ARCGIS SERVER MODALIDAD PRESENCIAL Profesionales formando a Profesionales 2015 formacion@tycgis.com Calle Rodríguez San Pedro 13, 3ª Planta, Oficina

Más detalles

Servicio de Notificaciones Electrónicas y Dirección Electrónica Habilitada

Servicio de Notificaciones Electrónicas y Dirección Electrónica Habilitada Servicio de Notificaciones Electrónicas y Dirección Electrónica Habilitada Apartado Postal Electrónico Manual de Configuración de Navegadores Abril 2011 Versión: Abril 2011 Página 1 de 28 Índice de Contenidos

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

Content Manager. IriScene Public Media versión 3.8 FRACTALIA Software

Content Manager. IriScene Public Media versión 3.8 FRACTALIA Software Content Manager IriScene Public Media versión 3.8 FRACTALIA Software 2 A. INTRODUCCIÓN... 3 B. DESCRIPCIÓN DEL FUNCIONAMIENTO... 3 C. MANUAL DE LA PLATAFORMA... 3 1. ACCESO A LA PLATAFORMA... 3 2. MÓDULOS...

Más detalles

DESARROLLO DE APLICACIÓN MÓVIL PARA EMPRESA DE BIENES RAÍCES, VERSIÓN ANDROID

DESARROLLO DE APLICACIÓN MÓVIL PARA EMPRESA DE BIENES RAÍCES, VERSIÓN ANDROID DESARROLLO DE APLICACIÓN MÓVIL PARA EMPRESA DE BIENES RAÍCES, VERSIÓN ANDROID Vicente Moya Murillo (1) Ing. Patricia Chávez Burbano (2) Facultad de Ingeniería en Electricidad y Computación Escuela Superior

Más detalles

GATOCREM. Gestión de Tareas y flujos. Registro de Entradas y Salidas

GATOCREM. Gestión de Tareas y flujos. Registro de Entradas y Salidas Ponentes: ---- angel.cifuentes2@carm.es CENTRO REGIONAL DE ESTADÍSTICA DE MURCIA - CREM Resumen: Sistema Informático denominado GATOCREM permite una gestión automatizada de todas las tareas estadísticas

Más detalles

RIA. http://goo.gl/zhfj7. Desarrollo con Tecnologías Open Source. Diego F. Quiroga diegoq@unsl.edu.ar

RIA. http://goo.gl/zhfj7. Desarrollo con Tecnologías Open Source. Diego F. Quiroga diegoq@unsl.edu.ar http://goo.gl/zhfj7 Desarrollo con Tecnologías Open Source Diego F. Quiroga diegoq@unsl.edu.ar Tecnologías de la Información Universidad Nacional de San Luis Introducción Las nuevas tecnologías y estándares

Más detalles

Análisis y Diseño del Sistema Integrado de Información (SII)

Análisis y Diseño del Sistema Integrado de Información (SII) Análisis y Diseño del Sistema Integrado de Información (SII) Para el proyecto Manejo integrado y sostenible de los recursos hídricos transfronterizos en la cuenca del Amazonas El presente documento permite

Más detalles

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA EL SERVICIO DE CREACIÓN DE MAPA DE CONOCIMIENTO DE LA UNIVERSIDAD DE GRANADA

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA EL SERVICIO DE CREACIÓN DE MAPA DE CONOCIMIENTO DE LA UNIVERSIDAD DE GRANADA PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA EL SERVICIO DE CREACIÓN DE MAPA DE CONOCIMIENTO DE LA UNIVERSIDAD DE GRANADA Expte. EXCEL. CEI 04/11 1. OBJETO DEL CONTRATO Actualmente, la información presentada

Más detalles

McAfee Web Gateway 7.4.0

McAfee Web Gateway 7.4.0 Notas de la versión Revisión A McAfee Web Gateway 7.4.0 Contenido Acerca de esta versión Nuevas funciones y mejoras Problemas resueltos Instrucciones de instalación Problemas conocidos Documentación del

Más detalles

CIF-KM. GUÍA DE LOS PRIMEROS PASOS

CIF-KM. GUÍA DE LOS PRIMEROS PASOS CIF-KM. GUÍA DE LOS PRIMEROS PASOS Secciones 1. CONCEPTOS PREVIOS. 2. INSTALAR CIF-KM. 2.1 Descargar e instalar CIF-KM. 2.2 Configuración de CIF-KM. 2.3 Acceso externo al servidor de CIF-KM. 3. PRIMERA

Más detalles

Simulador de Protocolos de Red a tráves de WEB

Simulador de Protocolos de Red a tráves de WEB Simulador de Protocolos de Red a tráves de WEB Propuesta de Estudio 20071608 Director Ing. Francisco Antonio Polanco Montelongo Resumen Introducción Actualmente, el desarrollo tecnológico a alcanzado niveles

Más detalles

SOFTWARE PROJECT MANAGEMENT PLAN

SOFTWARE PROJECT MANAGEMENT PLAN SOFTWARE PROJECT MANAGEMENT PLAN HERRAMIENTA PARA LA ADMINISTRACIÓN DE REQUERIMIENTOS DE LOS PROYECTOS DE LAS ASIGNATURAS DE INGENIERÍA Y ARQUITECTURA DE SOFTWARE DE LA PONTIFICIA UNIVERSIDAD JAVERIANA.

Más detalles

BackflipSD Modelo de Diseño

BackflipSD Modelo de Diseño BackflipSD Modelo de Diseño Historia de revisiones: Fecha Versión Descripción Autor 04/09/2012 1.0 Rodrigo Stecanella 16/09/2012 1.1 Rodrigo Stecanella 1 Contenido Historia de revisiones:...1 Introducción...3

Más detalles

CURSO DE ESPECIALISTA EN DESARROLLO DE APLICACIONES WEB

CURSO DE ESPECIALISTA EN DESARROLLO DE APLICACIONES WEB CURSO DE ESPECIALISTA EN DESARROLLO DE APLICACIONES WEB Objetivos Generales: Al término de esta acción formativa los participantes alcanzarán los siguientes objetivos: Preparar profesionales para el desarrollo

Más detalles

LX8_022 Requisitos técnicos de. instalación para el usuario

LX8_022 Requisitos técnicos de. instalación para el usuario LX8_022 Requisitos técnicos de instalación para el usuario FECHA NOMBRE FORMATO COMENTARIO AUTOR 28/04/2011 LX8_019 Requisitos técnicos de instalación para el usuario Grupo de desarrollo LexNet 24/04/2012

Más detalles

SOLUCIONES DE DESARROLLO JAVA PARA LAS APLICACIONES DE LA COMUNIDAD DE MADRID

SOLUCIONES DE DESARROLLO JAVA PARA LAS APLICACIONES DE LA COMUNIDAD DE MADRID SOLUCIONES DE DESARROLLO JAVA PARA LAS APLICACIONES DE LA COMUNIDAD DE MADRID Versión 1.2 Julio 2010 Página: 1 CONTROL DE CAMBIOS Fecha Versión Cambios 01/01/2006 1.0 Primera versión 11/09/2008 1.1 Se

Más detalles

Especialista en Creación de Portales Web con Joomla 3.3

Especialista en Creación de Portales Web con Joomla 3.3 Especialista en Creación de Portales Web con Joomla 3.3 Titulación certificada por EUROINNOVA BUSINESS SCHOOL Especialista en Creación de Portales Web con Joomla 3.3 Especialista en Creación de Portales

Más detalles

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA DESARROLLO DE UN SISTEMA DE CONSTRUCCIÓN DE WEBS 2.0 E INTEGRACIÓN CON UN SISTEMA DE VENTA DE DOMINIOS Tesis para optar por el

Más detalles