Desktop Application for Device Cloud Explorer

Transcripción

TRABAJO FIN DE GRADO
Título
Autor/es
Jesús Nieto Cuartero
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
2013-2014
Desktop Application for Device Cloud Explorer, trabajo fin de grado
de Jesús Nieto Cuartero, 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
E-mail: [email protected]
Facultad
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Titulación
Grado en Ingeniería Informática
Título
Autor/es
Jesús Nieto Cuartero
Tutor/es
Juan José Olarte Larrea
Departamento
Curso académico
2013-2014
Resumen
Hoy en día, podemos utilizar múltiples dispositivos conectados para comunicarnos además de
equipos de mesa, portátiles, tabletas, etc. Digi Internation Spain, empresa en la cual se realiza
el proyecto, se encarga de ofrecer este tipo de soluciones M2M (Machine to Machine)
permitiendo la comunicación directa entre máquinas para optimizar múltiples áreas.
El proyecto consiste en la simulación de estas soluciones, creando una aplicación de escritorio
que permita simular dispositivos conectados a la nube y su comportamiento, de tal forma que
los clientes de Digi puedan comprender las características y beneficios de una solución M2M
sin la necesidad de llevar a cabo su instalación y despliegue, la cual es compleja y costosa.
Abstract
Nowadays, we can use multiple connected devices in order to communicate us each other
besides computers, laptops, tablets, etc. Digi International Spain, enterprise in which the
project is developed, puts in charge of this type of M2M (Machine to Machine) solutions,
allowing direct communication between machines in order to optimize multiple areas.
The project consists of a simulation of these solutions, developing a desktop application that
can simulate devices connected to the cloud and their behavior, so that Digi clients could
understand the features and advantages of an M2M solution without the need of installing
and
deploying
it,
which
is
a
complex
and
expensive
task.
1
Índice general
1. Introducción .. .............................................. ...................................................
1.1. Antecedentes ....................................................................................................
1.2. Objetivos ...........................................................................................................
1.3. Planificación ......................................................................................................
1.4. Seguimiento del proyecto .................................................................................
2. Desarrollo ..... .............................................. ...................................................
2.1. Análisis .. ...........................................................................................................
2.1.1.Identificación de usuarios participantes ...................................................
2.1.2.Catálogo de requisitos del sistema ...........................................................
2.1.3.Casos de uso ..............................................................................................
2.2. Diseño ... ...........................................................................................................
2.2.1.Diseño de la interfaz de usuario ................................................................
2.2.2.Diagrama de navegación ............................................................................
2.2.3.Arquitectura del sistema ...........................................................................
2.2.4.Almacenamiento de datos ........................................................................
2.2.5.Diseño de clases ........................................................................................
2.2.6.Diseño del plan de pruebas .......................................................................
2.3. Implementación ................................................................................................
2.3.1.Tecnologías usadas ....................................................................................
2.3.2.Librerías empleadas ..................................................................................
2.3.3.Desarrollo de la aplicación ........................................................................
2.4. Pruebas . ...........................................................................................................
3. Conclusiones .............................................. ...................................................
4. Bibliografía ... .............................................. ...................................................
3
3
5
5
8
12
12
12
12
17
25
25
30
30
31
32
34
35
35
36
36
44
47
49
2
Capítulo 1. Introducción
En esta memoria quedan recogidos los aspectos más relevantes del trabajo de fin de grado
realizado por Jesús Nieto Cuartero titulado “Desktop Application for Device Cloud Explorer”.
Este proyecto ha sido desarrollado en el ámbito de la empresa Digi International Spain S.A.U.
1.1. Antecedentes
En la actualidad el mundo está conectado, podemos acceder a internet y comunicarnos desde
multitud de lugares. Desde el tradicional ordenador hasta el teléfono móvil que llevamos
siempre encima, pasando por las tabletas u otros dispositivos. Hasta hace pocos años, el
paradigma de computación correspondía fundamentalmente al de persona-ordenador, es
decir, una persona sentada frente a un ordenador interactuando con él. Esto está
evolucionando, añadiendo conectividad a dispositivos que en principio no habían sido
diseñados para ello y permitiendo comunicación entre máquinas. De tal forma que hoy en día
disponemos de comunicación entre agentes no humanos, como podría ser un dispositivo
embebido con diferentes sensores que recogen información sobre su entorno y se comunican
con
un
servidor
para
enviar
estos
datos.
Digi International es una empresa norteamericana especializada en el desarrollo de soluciones
M2M (Machine to Machine) para el manejo más eficiente de diferentes negocios. Digi ofrece
soluciones específicas para mercados como el energético (energía alternativa, automatización
de la distribución, etc), el de activos móviles (como ferrocarriles), el médico o el mercado de
tanques, entre otros. Estas soluciones consisten en la comunicación de diferentes máquinas
utilizando dispositivos embebidos encargados de realizar la comunicación y servidores
encargados de organizar el envío, recepción y gestión de la información de las máquinas
utilizadas.
Actualmente, Digi ofrece varias soluciones para optimizar y mejorar el funcionamiento de
empresas de diferente tipo. El objetivo principal de estos sistemas es la monitorización y
manipulación del comportamiento de dispositivos conectados de diferente índole. Así, una
empresa podría controlar su red de tanques con una solución M2M, monitorizando las
características básicas de cada tanque como el nivel o el estado de las válvulas y permitiendo
modificar
otros
aspectos
como
la
temperatura.
Entre sus productos, Digi cuenta con una nube, denominada Etherios Device Cloud, que
permite conectar dispositivos para disponer de un control en tiempo real sobre los mismos.
Etherios Device Cloud fue desarrollado con el objetivo de llevar a cabo soluciones
denominadas “Internet of Anything”. De esta forma, Digi ofrece una herramienta para
desarrollar soluciones M2M, proporcionando conectividad entre dispositivos y
almacenamiento de datos.
El problema a resolver con este proyecto surge cuando un potencial cliente de Digi está
evaluando las posibilidades de instalar un sistema M2M para gestionar de manera más
eficiente su actividad. Este problema deriva de la complejidad de estos sistemas, ya que su
instalación y puesta a punto es costosa en tiempo y recursos, lo que hace que no sea factible
una prueba del mismo. Esto es lo que ha motivado este proyecto, cuyo objetivo principal será
el de ofrecer una simulación de un sistema M2M. De esta forma, nuestro proyecto permitirá la
creación de dispositivos simulados en una aplicación de escritorio. Estos dispositivos tendrán
un comportamiento similar al de un dispositivo real y estarán conectados a la nube para poder
monitorizar y manipular su comportamiento desde una aplicación web. Así, un futuro cliente
3
de Digi que esté sopesando la posibilidad de contratar una solución M2M podrá hacerse una
idea de las ventajas y posibilidades que ofrece el uso de sistemas embebidos combinados con
el Cloud para la mejora de su negocio.
Este proyecto fue propuesto por la empresa Digi International Spain durante los periodos de
Prácticas I y Prácticas II. Durante los meses de Noviembre y Diciembre se comenzó a definir el
proyecto, pensando los diferentes dispositivos que sería más recomendable simular,
realizando una especificación con los principales requisitos que debería cumplir el proyecto,
así como un principio de diseño, llevando a cabo unos prototipos de la interfaz gráfica tanto de
la aplicación de escritorio como de la aplicación web. También se comenzó con la
implementación de pruebas para comprender el funcionamiento de la nube y comenzar con la
simulación de dispositivos. Estos aspectos serán integrados en el proyecto.
Fundamentalmente, el sistema a desarrollar estará compuesto de una aplicación de escritorio
funcionando en un ordenador, el Device Cloud y un servidor de aplicaciones donde se
encontrará alojada una aplicación web. La aplicación de escritorio será la encargada de crear
los dispositivos y simular su comportamiento, a la vez que conectarlos con la nube y enviar
datos sobre su estado. Por otro lado, la aplicación web alojada permitirá acceder a los datos de
la nube sobre los dispositivos simulados. Esta aplicación será la encargada de monitorizar el
comportamiento de dichos dispositivos y de enviar peticiones a los mismos, permitiendo así
comunicación en ambas direcciones. En la Figura 1 se ilustra la arquitectura básica del sistema
a desarrollar.
Figura 1. Arquitectura del sistema
También se manejó la posibilidad de realizar todo el proyecto en una o varias aplicaciones
web. La decisión de realizar una aplicación de escritorio y una aplicación web viene de la idea
de poder simular al máximo el comportamiento de los sistemas M2M. Por ello, se decidió que
el hecho de tener un dispositivo real (ordenador) en el que simulamos los dispositivos y los
conectamos a la nube se acerca más a las soluciones M2M ofrecidas por Digi, ya que si se
desarrollara todo mediante aplicaciones web aumentaría la abstracción del sistema y se
difuminaría la separación entre dispositivos simulados y nube.
Debido a la magnitud del sistema que se pretende desarrollar, la empresa sugirió la división del
mismo entre dos de los alumnos que se encontraban de prácticas. De esta forma, Alejandro
Vaquero Blanco será el autor de la aplicación web encargada de la monitorización de los
4
dispositivos simulados mientras que el proyectante realizará la aplicación de escritorio, con la
simulación y conexión de dispositivos.
1.2. Objetivos
El principal objetivo del proyecto es crear un sistema que permita a los futuros clientes de Digi
comprobar el potencial de las soluciones M2M. De esta forma, el usuario podrá ver cómo será
el sistema sin la necesidad de comprar dispositivos reales o de instalar software en dichos
dispositivos.
Como objetivos generales, destacamos los siguientes:



El sistema estará compuesto por dos partes diferenciadas: aplicación de escritorio en
la que se producirá la simulación de dispositivos y aplicación web en la que se
monitorizarán los datos de los mismos.
El sistema debe proporcionar una comunicación bidireccional, de tal forma que desde
la aplicación web se puedan recoger datos enviados por los dispositivos simulados y,
del mismo modo, se puedan enviar peticiones a los mismos para modificar su
comportamiento.
Realización de test por parte de los alumnos para comprobar el correcto
funcionamiento del sistema.
Objetivos concretos de la aplicación de escritorio son:




Crear una aplicación que permita simular dispositivos reales y simular su
comportamiento. Estos dispositivos serán aquellos más comunes entre las soluciones
M2M que genera Digi. De esta forma, se abarcará un mayor rango de clientes a los que
les sea útil probar el sistema para evaluar las mejoras de una solución M2M.
El sistema ha de ser lo más realista posible y el usuario podrá interactuar con ella para
modificar parámetros de la simulación.
La aplicación deberá poder ejecutarse en diferentes sistemas operativos de
ordenadores.
Desarrollo de un manual para el correcto uso del sistema por parte de los clientes. El
manual estará accesible desde la página web y desde la aplicación de escritorio.
1.3. Planificación
Este proyecto se comenzó a desarrollar al inicio del segundo cuatrimestre es decir, el 3 de
febrero de 2014. A pesar de esto, como se ha comentado, no se partió de cero ya que se
comenzó con la especificación, diseño y algo de implementación durante el periodo de
prácticas del primer cuatrimestre.
Para llevar a cabo la planificación, se dividió el proyecto en las tareas necesarias para su
realización. Al hacer esto, se intentó no dividir en tareas muy grandes para poder realizar un
mejor seguimiento y control de las mismas y localizar y corregir más fácilmente posibles
desviaciones. Por ello, las tareas definidas tienen una duración media de 8 horas.
Se va a utilizar Scrum como marco de trabajo para la gestión y desarrollo del software. A pesar
de esto, no se seguirá Scrum de un modo exhaustivo, sino que se hará un uso más libre del
5
mismo para adaptarlo a las necesidades del proyecto. De esta forma, no se llevarán a cabo
reuniones diarias sino que se realizarán 3 reuniones semanales, además de las reuniones de
evaluación y control de cada sprint.
Los roles durante el desarrollo del proyecto serán los siguientes:



Product Owner (dueño del producto): Pedro Pérez, Manager Engineering en Digi
International Spain.
Scrum Master (director del proyecto): Rubén Moral, desarrollador en Digi International
Spain.
Development Team (equipo de desarrollo): Alejandro Vaquero y Jesús Nieto.
Se ha realizado el Product Backlog (Pila del Producto) con los requisitos y tareas a integrar en
el producto. Estas tareas, ordenadas según prioridad y especificando el número de horas
estimadas de trabajo para cada una, se muestran en la Figura 2.
ID Tarea
1
Análisis
Diseño
2
Sesión
3
Simulación del
tanque
4
Simulación del
camión
5
Copiar
6 dispositivos
Conectar7 desconectar
Programación
8 de eventos
Modo offline
9
Conexión
10
Peticiones
11
Logger
12
Gestión de
13 errores
Descripción
Llevar a cabo un análisis del proyecto a desarrollar
Diseño de la aplicación, incluyendo un diagrama con las
clases principales de la aplicación.
Crear, guardar y cargar una sesión con dispositivos
simulados.
Realización de las tareas necesarias para llevar a cabo la
simulación de un tanque conectado a la nube (simulación
automática y manual)
Realización de las tareas necesarias para llevar a cabo la
simulación de un camión conectado a la nube (simulación
automática y manual)
Tareas básicas de copiar, pegar, eliminar y cortar
dispositivos.
Permitir al usuario conectar y desconectar los dispositivos
ya creados.
Formulario que permita al usuario la programación de
determinados eventos para tanques y camiones.
Implementar el funcionamiento de un dispositivo cuando
está desconectado. El dispositivo deberá continuar la
simulación y almacenar los datos en un fichero para
enviarlos posteriormente cuando se restablezca la
conexión.
Gestionar aspectos de la conexión como timeouts o
cuentas del cloud llenas (la cuenta básica sólo permite 5
dispositivos)
Manejar peticiones procedentes de la WA como
desconexión de dispositivos, firmware updates,
abrir/cerrar válvulas, etc.
Creación de un log que almacene información sobre los
cambios producidos en la aplicación.
Manejar adecuadamente las excepciones que se puedan
generar durante el uso de la aplicación, mostrando
Tiempo
estimado
7
7
5
3
5
5
3
8
8
8
8
7
6
6
Vista detalle
14 tanque
Vista detalle
15 camión
Vista mosaico
16
Vista tabla
17
18
19
20
21
22
23
24
Configuración
de tanque
Configuración
de camión
Memory leak
Google Maps
Mejoras de
Google Maps
Mejoras en la
interfaz gráfica
Test
Documentar
código
Guía de usuario
25
mensajes al usuario cuando sea oportuno.
Creación de la interfaz gráfica para ver la vista de detalles
de un tanque.
Creación de la interfaz gráfica para ver la vista de detalles
de un camión.
Creación de los aspectos gráficos para ver la sesión actual
en vista de mosaico.
Creación de los aspectos gráficos para ver la sesión actual
en vista de tabla.
Formulario para la configuración de las características de
un tanque.
Formulario para la configuración de las características de
un tanque.
Solucionar el problema del uso excesivo que hace google
maps de la memoria.
Realización de mejoras como permitir al usuario cambiar
el punto de inicio o de final y definir paradas en la ruta.
Añadir mejoras a la interfaz como drag&drop, barra de
loading, redimensionar la ventana, etc.
Realizar las pruebas necesarias en la aplicación.
Documentación de los métodos y clases del código.
Crear una pequeña página de welcome con ayuda para un
usuario que entra por primera vez en la aplicación.
Total
10
10
10
6
3
3
10
15
8
25
15
20
215
Figura 2. Tareas a desarrollar y su estimación
Cabe destacar que hay aspectos que no se han introducido en la lista de tareas debido a que ya
se realizaron durante el periodo de prácticas del primer cuatrimestre. Estos son los siguientes:




Especificación: se realizó una descripción del alcance del proyecto, tanto de la
aplicación de escritorio como de la aplicación web.
Dispositivos simulados: creación de dispositivos simulados (tanques y camiones) que
se conectan a la nube y son vistos como dispositivos reales.
Eventos: diseño e implementación de las clases necesarias para la realización de
eventos en los dispositivos simulados (por ejemplo, abrir una válvula de un tanque).
Login: ventana para iniciar una sesión en la aplicación de escritorio. Se conecta con el
Cloud y comprueba las credenciales del usuario.
Como vemos en la tabla, se estiman un total de 215 horas, a las que hay que sumarle el tiempo
dedicado a la planificación (con una duración de 15 horas), redacción de la memoria (estimado
en 50 horas, que se llevarán a cabo a lo largo de todo el proyecto) y el tiempo dedicado a la
gestión del proyecto, entre lo que destacamos las reuniones tanto con miembros del equipo
como con el tutor (estimadas en 20 horas), lo que hacen un total de 300 horas de trabajo
planificadas.
Siguiendo la metodología Scrum, se realizarán Sprints de dos semanas de duración. Al principio
de cada Sprint, se llevará a cabo una reunión de planificación del mismo en el que se decidirán
7
qué tareas se realizarán y qué funcionalidad se incluirá al producto. Estas tareas, se escogerán
de la pila por orden de prioridad. Del mismo modo, al finalizar el Sprint se concertará otra
reunión para validar el incremento añadido al producto y para observar y corregir posibles
desviaciones con respecto a la planificación inicial del sprint.
Durante las dos primeras semanas del proyecto, se llevó a cabo la planificación del proyecto y
la redacción de los primeros apartados de esta memoria. De este modo, el primer sprint
comenzó el día 17 de febrero de 2014.
1.4. Seguimiento del proyecto
Para llevar a cabo el seguimiento y control del proyecto se va a utilizar la herramienta software
JIRA. Se trata de una aplicación basada en web para el seguimiento de errores, de incidentes y
para la gestión operativa de proyectos.
Como se ha comentado, hemos utilizado Scrum para el desarrollo del proyecto. A continuación
se especifican los sprints realizados, así como las tareas que se han incluido en cada uno de
ellos, el tiempo estimado, el tiempo real y la desviación con respecto a la planificación.
Sprint 1: 17/02/2014 – 24/02/2014)
ID Tarea Nombre Horas estimadas
1
Análisis
7
2
Diseño
7
Total 14
Horas reales
7
6
13
Sprint 2: 24/02/2014 – 10/03/2014)
ID Tarea Nombre tarea Horas estimadas
3
Sesión
5
4
Simulación
3
tanque
11
Peticiones
8
Total 16
Sprint 3: 10/03/2014 – 24/03/2014)
6
Copiar
5
dispositivos
5
Simulación
5
camión
7
Connectar
3
desconectar
13
Gestión
6
errores
8
Programación 8
eventos
12
Logger
7
17
Vista tabla
6
Total 40
Desviación
0
-1
-1
Fecha inicio
17/02/2014
19/02/2014
Fecha fin
19/02/2014
20/02/2014
Horas reales
11
3
Desviación
+6
0
Fecha inicio
24/02/2014
27/02/2014
Fecha fin
27/02/2014
27/02/2014
6
20
-2
+4
03/03/2014
06/03/2014
Horas reales
7
Desviación
+2
Fecha inicio
10/03/2014
Fecha fin
12/03/2014
8
+3
13/03/2014
14/03/2014
1.5
-1.5
14/03/2014
14/03/2014
3
-3
17/03/2014
17/03/2014
6.5
-1.5
17/03/2014
19/03/2014
3.5
9
38.5
-3.5
+3
-1.5
19/03/2014
20/03/2014
20/03/2014
21/03/2014
8
Tras la revisión de este sprint, se decidieron incluir las siguientes tareas en la pila del producto:
ID
Tarea
Descripción
26
Eliminar dataStreams
27
Termostato
28
Archivo notificaciones
29
Otro servidor URL
30
Estado por defecto
31
Actualización de
firmware
Tras la eliminación de un dispositivo simulado de
la sesión, es necesario eliminar todos sus
dataStreams almacenados en la nube para evitar
la sobrecarga de información innecesaria.
Crear un elemento gráfico que permita mostrar y
modificar la temperatura de un dispositivo
simulado
Crear un archivo en el que se registren las
notificaciones de una sesión y actualizarlo en la
nube.
Permitir elegir el servidor al que se quiere
conectar una sesión (puede ser UK, USA u otro)
Cambiar el estado por defecto de un dispositivo
a “No conectado”. De esta forma, será necesario
conectarlo manualmente y establecer
determinados parámetros de configuración.
Implementar las actualizaciones de firmware
utilizando la funcionalidad específica del API de
Etherios Cloud.
Tiempo
estimado
2
Prioridad
3
Alta
4
Alta
1
Media
8
Media
5
Media
Alta
Hay que tener en cuenta que el hecho de que se añadan estas tareas a la pila del producto no
implica necesariamente que se vayan a realizar. Se trata de mejoras o nueva funcionalidad que
podría ser interesante y que su inclusión en el proyecto dependerá del tiempo del que se
disponga y de la prioridad de cada nueva tarea.
Sprint 4: 24/03/2014 – 07/04/2014)
26
Eliminar
2
dataStreams
9
Modo Offline 8
27
Termostato
3
28
Archivo
4
notificaciones
16
Vista de
10
mosaico
10
Conexión
8
Total 35
Sprint 5: 07/04/2014 – 21/04/2014)
14
Vista detalle
10
tanque
15
Vista detalle
10
Horas reales
4
Desviación
+2
Fecha inicio
24/03/2014
Fecha fin
24/03/2014
6
4,5
3,5
-2
+1,5
-0,5
26/03/2014
27/03/2014
31/03/2014
27/03/2014
27/03/2014
31/03/2014
8
-2
2/04/2014
3/04/2014
7
33
-1
-2
4/04/2014
4/04/2014
Horas reales
14
Desviación
+4
Fecha inicio
07/04/2014
Fecha fin
09/04/2014
8
-2
09/04/2014
10/04/2014
9
camión
Configuración
tanque
Configuración
camión
Actualización
de firmware
Estado por
defecto
Otro servidor
URL
Total
18
19
31
30
29
3
6
+3
10/04/2014
12/04/2014
3
0*
-3
-
-
5
5
+0
14/04/2014
15/04/2014
8
7
-1
15/04/2014
16/04/2014
1
1
+0
17/04/2014
17/04/2014
40
41
+1
*La tarea con ID 19, Configuración del camión, ha tenido una duración de 0 horas debido a que
se tomó la decisión de que la configuración del tanque y la del camión serían la misma. Por
ello, no ha sido necesaria la realización de esta tarea ya que se aprovechó lo realizado en la
tarea 18.
Tras este sprint, se añadieron las siguientes tareas a la pila:
ID
Tarea
Descripción
32
Barra de Progreso
33
Puntos de parada
Implementar una barra de progreso para
observar los diferentes procesos que pueden
ocurrir en paralelo en la aplicación.
Permitir al usuario añadir puntos de parada a la
ruta del camión
Sprint 5: 24/04/2014 – 08/05/2014)
20
Memory leak 8
Google Maps
21
Mejoras de
15
Google Maps
32
Barra de
3
Progreso
33
Puntos de
4
parada*
NO
Corrección de
bugs
Total 30
Tiempo
estimado
3
Prioridad
4
Baja
Alta
Horas reales
10
Desviación
+2
Fecha inicio
24/04/2014
Fecha fin
25/04/2014
10
-5
28/04/2014
30/04/2014
7
+4
01/05/2014
05/05/2014
1
-3
06/05/2014
06/05/2014
10
38
+8
*Esta tarea no llegó a completarse debido a su complejidad. Se hizo un análisis sobre la misma
y se llegó a la conclusión de que su realización supondría un elevado número de horas, por lo
que se desechó.
10
Sprint 5: 12/05/2014 – 23/05/2014)
22
Mejoras en la 8
interfaz
gráfica
24
Documentar
15
código
25
Guía de
20
usuario
23
Test
25
Total 68
Horas reales
10
Desviación
+2
Fecha inicio
12/05/2014
Fecha fin
13/05/2014
9
-6
13/05/2014
15/05/2014
10
-10
16/05/2014
20/05/2014
40
69
+15
+1
21/05/2014
04/06/2014
En la figura 3 se muestra un gráfico de Jira que representa el número de tareas planificadas
frente a las realizadas. Los puntos rojos son las tareas que se han ido creando y los verdes las
que se han resuelto. También están marcados como tareas los bugs que se han ido
encontrando durante el proyecto, por eso la línea roja también va creciendo a lo largo del
tiempo. Como vemos, al final la línea verde alcanza a la línea roja, lo que implica el final del
proyecto.
Figura 3. Seguimiento de las tareas durante el proyecto
11
Capítulo 2. Desarrollo
2.1. Análisis
En este apartado se muestran los aspectos más importantes del análisis realizado para el
desarrollo del proyecto. A partir de este punto de la memoria, todos lo que se comenta se
refiere a la aplicación de escritorio, que es la que se desarrolla como Trabajo de Fin de Grado.
2.1.1. Identificación de los usuarios participantes
Para esta aplicación se hará una distinción muy básica de usuarios, teniendo usuarios
logueados y usuarios no logueados.


Usuario no logueado: es todo usuario cuando accede a la aplicación. La funcionalidad
que puede ejecutar es muy limitada, ya que sólo puede consultar la documentación.
También tiene acceso a la funcionalidad de crear un dispositivo, pero cuando vaya a
realizar esto, será necesaria la creación de una sesión de trabajo nueva, lo que hará
que se le solicite que introduzca sus credenciales, pasando de esta forma a ser un
usuario logueado.
Usuario logueado: es el usuario que puede utilizar la aplicación en su totalidad. Ya ha
realizado el LogIn y, por lo tanto, puede modificar sesiones añadiendo y eliminando
dispositivos, modificándolos, etc.
Un usuario no logueado pasará a ser un usuario logueado en el momento en el que introduzca
correctamente sus credenciales de Etherios Cloud.
2.2.2. Catálogo de requisitos del sistema
i.
Definiciones:
Loguearse
Entendemos que un usuario se ha logueado desde la aplicación de escritorio cuando ha
introducido sus credenciales de usuario, contraseña y servidor al que desea conectarse. Estas
credenciales son las de Etherios Cloud de Digi. No será posible registrarse desde la aplicación,
sino que se proporciona un enlace a la web del Cloud de Digi para poder realizar el registro en
el servidor que se desee (UK o USA). La aplicación a desarrollar no accederá directamente a las
bases de datos de Digi, sino que intentará realizar una petición al Cloud con las credenciales
introducidas y, a partir de la respuesta, se comprobará si los datos del usuario son correctos.
Dispositivo simulado
Consistirá en una simulación en la aplicación de escritorio de uno de los dispositivos típicos a
los que Digi les aplica una solución M2M para la aumentar la eficiencia de la gestión y
funcionamiento de los mismos. Un dispositivo real se conectaría con la nube a través de un
dispositivo embebido y enviaría datos sobre su comportamiento. De esta forma, un dispositivo
simulado realizará las mismas operaciones pero desde un equipo de escritorio en el que se
12
ejecuta la aplicación. Desde el punto de vista de la nube, no habrá ninguna diferencia entre un
dispositivo real y uno simulado.
Simulación
Entendemos por simulación la imitación del comportamiento normal de un dispositivo real.
Por ejemplo, un tanque tendrá un nivel que cambiará según el estado de su válvula de entrada
y de salida. Esta simulación se ejecutará en la aplicación de escritorio y enviará los datos de la
misma a la nube.
Se distinguirán dos tipos de simulación en la aplicación de escritorio:
1. Simulación automática: será la simulación inicial, el comportamiento por defecto de un
dispositivo. Esta simulación será de la siguiente forma:
 Tanque: su temperatura oscilará aleatoriamente entre dos valores
predefinidos.
 Camión:
i. Ruta: el sistema generará una ruta aleatoria y el camión viajará por
ella.
ii. Puerta: la puerta permanecerá cerrada.
iii. Temperatura: oscilará aleatoriamente entre dos valores predefinidos.
iv. Velocidad: oscilará aleatoriamente entre dos valores predefinidos.
En este tipo de simulación también se podrán programar eventos como se menciona
en el siguiente punto.
2. Manual: el usuario podrá interactuar con los dispositivos simulados para cambiar su
comportamiento.
Evento
Un evento será la programación de la ejecución de un cambio en el estado de un dispositivo
simulado. Habrá diferentes tipos de eventos dependiendo de la característica del dispositivo
que se quiera modificar. Un ejemplo de evento será la apertura de una válvula de un tanque
en un determinado momento.
Sesión
Una sesión consiste en un marco de trabajo de un usuario logueado. Así, una sesión
corresponderá a un único usuario y tendrá una serie de dispositivos simulados. Un usuario
podrá tener varias sesiones de trabajo, aunque en la aplicación sólo se permitirá una sesión
cargada en cada momento.
Notificación
Se entiende por notificación la información mostrada a un usuario a raíz de un determinado
suceso ocurrido en la simulación. Por ejemplo, una notificación correspondería con el informe
de que se ha añadido o eliminado un dispositivo a la sesión de trabajo.
13
ii.
Requisitos funcionales:
En la aplicación de escritorio se especifican los siguientes requisitos funcionales
A. Dispositivos.
 Se crearán dispositivos simulados que podrán conectarse a la nube para enviar datos
sobre su estado.
 Los dispositivos tendrán un comportamiento determinado mediante una simulación.
Existirá una simulación por defecto para cada dispositivo.
 Un dispositivo simulado podrá encontrarse como conectado o como desconectado a la
nube. Siempre que un dispositivo esté conectado enviará información a la nube sobre
su estado. Cuando un dispositivo no esté conectado, su simulación continuará de
forma normal pero estos datos no se enviarán a la nube, sino que se almacenarán y
serán enviados una vez se reestablezca la conexión. Es necesario que la nube sepa la
fecha y hora en la que se han generado esos datos, independientemente del momento
en el que se envíen a la nube.
 Cada dispositivo podrá ser configurado para modificar parámetros de la conexión. Los
parámetros que se permitirá modificar son los siguientes:
o Permitir conexión segura
o Permitir compresión de los datos
o Permitir reconexión cuando se desconecta un dispositivo remotamente
 Los dispositivos simulados serán vistos como dispositivos reales desde el Cloud.
 Se permitirá crear dos tipos de dispositivos: tanques y camiones.
 Un tanque constará de nivel, radio, altura, estado de las válvulas, temperatura,
localización, versión de firmware, sistema de ficheros (log y fichero de configuración)
 Un camión constará de velocidad, estado de la puerta, ruta, temperatura, versión de
firmware y un sistema de ficheros equivalente al del tanque.
 La versión de firmware se representará con una cadena de texto formada por 4
números enteros entre 0 y 127 separados por puntos.
 La ruta de un camión tendrá un inicio y un final, que podrán ser modificadas por el
usuario. Además, se mostrará un mapa en la aplicación que permita ver la posición del
camión en todo momento.
B. Eventos y simulación
 Podrán programarse eventos que permitan modificar el estado de los dispositivos en
un determinado momento. También se podrán especificar los valores de las
características que se desean alcanzar. Dos ejemplos de eventos serían vaciar o llenar
el tanque hasta un nivel determinado y alcanzar una temperatura concreta en un
momento predefinido.
 El usuario también podrá modificar la simulación de un dispositivo manualmente. De
esta forma, cada dispositivo simulado tendrá una representación gráfica que permita
al usuario interactuar con ella y modificar determinadas características de dichos
dispositivos. Por ejemplo, el usuario podrá pulsar en una válvula de un tanque para
cambiar su estado.
14
C. Peticiones
 La aplicación de escritorio permitirá la recepción de peticiones desde la aplicación
web. Estas peticiones serán las siguientes:
o Desconexión: petición que permite desconectar un determinado dispositivo
simulado. Los dispositivos podrán ser configurados para que se reconecten
automáticamente en un tiempo determinado o si no, una vez desconectado,
sólo se puede volver a conectar desde la aplicación de escritorio.
o Firmware: esta petición permitirá la actualización del firmware de uno o varios
dispositivos. El firmware será representado por un número de versión en el
dispositivo y esta petición actualizará dicho número.
o Sistema de ficheros: la aplicación web podrá enviar una petición para ver el
sistema de ficheros de un dispositivo. Este sistema de ficheros consistirá
únicamente en un fichero de log y otro de configuración.
o Operaciones de tanque: se podrán enviar peticiones para abrir/cerrar las
válvulas o cambiar la temperatura de un tanque.
o Operaciones de camión: se podrán enviar peticiones para cambiar la
temperatura de un camión.
D. Sesiones
 Se permitirán guardar las sesiones de tal forma que se pueda seguir trabajando con
ellas en un futuro.
 La aplicación permitirá añadir tantos dispositivos simulados a una sesión como se
desee. Esto se verá limitado por el tipo de cuenta de Etherios Cloud, ya que las cuentas
gratuitas permiten hasta un máximo de 5 dispositivos, mientras que una cuenta
Premium te ofrece un número ilimitado de ellos.
 Dentro de una sesión se permitirá copiar, cortar y pegar dispositivos.
E. Documentación
 La aplicación dispondrá de una documentación que servirá de ayuda al usuario para
conocer el funcionamiento básico de la misma. Esta documentación estará accesible al
usuario desde la aplicación web y también tendrá un breve manual de bienvenida en la
aplicación de escritorio.
iii.
Requisitos no funcionales
A. Requisitos de usuarios:
Para poder acceder a la totalidad de la funcionalidad de la aplicación, será necesario el registro
en Etherios Device Cloud, la nube de Digi.
B. Requisitos tecnológicos:
 La aplicación está dirigida a equipos de sobremesa o portátiles.
 La aplicación debe funcionar en los sistemas operativos más extendidos de equipos
(Windows, Mac, Linux).
15



Es necesario disponer de conexión a internet para el correcto funcionamiento de la
aplicación.
La aplicación ha de adaptarse a diferentes tamaños y configuraciones de pantallas.
El rendimiento de la aplicación dependerá de la capacidad computacional del equipo
en el que se ejecute y de la velocidad de la conexión a internet del mismo.
C. Requisitos de interfaces externas:
 La interfaz de usuario ha de mantener la estética corporativa de la empresa Digi
International.
 La interfaz y todos sus elementos han de ser equivalentes a los utilizados en la
aplicación web. De esta forma, dará más sensación de unidad del sistema.
D. Requisitos de desarrollo:
 El marco de trabajo para el desarrollo del proyecto ha de ser Scrum, cuya principal
característica es que se realiza de forma iterativa e incremental.
 Se utilizará el software JIRA para la gestión del proyecto.
16
2.2.3. Casos de uso
En esta sección se incluyen los casos de uso más relevantes del sistema así como algunos
diagramas de actividad. El resto de los casos de uso se encuentran en el Anexo 1: Casos de uso.
El diagrama de casos de uso de la aplicación es el siguiente:
Figura 4. Diagrama de casos de uso.
17
Caso de uso
Guardar sesión
Descripción
El sistema guardará la sesión activa del usuario.
Actor
Usuario
Precondición
El usuario tiene una sesión activa sobre la que está trabajando.
Secuencia
Paso
Acción
Normal
1
El usuario pulsa el botón de guardar sesión
2
El sistema comprueba que la sesión ha sido
modificada desde la última vez que se guardó.
3
El sistema guarda los datos de la sesión.
Postcondición
La sesión del usuario ha sido guardada.
Flujos alternativos y
excepciones
Si la sesión del usuario no ha sido modificada desde la última
vez que se guardó, el sistema no hace nada.
Caso de uso
Cerrar sesión
Descripción
El sistema cerrará la sesión activa del usuario.
Actor
Usuario
Precondición
Secuencia
Paso
Acción
Normal
1
El usuario pulsa el botón de cerrar sesión en el menú
o cierra la pestaña de la sesión.
2
El sistema comprueba si la sesión no ha sido
3
El sistema cierra la sesión.
Postcondición
La sesión del usuario ha sido cerrada.
excepciones
Si la sesión del usuario ha sido modificada desde la última vez
que se guardó, el sistema pregunta al usuario si desea guardar.
En caso afirmativo se procede al caso de uso Guardar sesión.
18
Figura 5. Diagrama de actividad del caso de uso Cerrar sesión.
19
Caso de uso
Crear dispositivo
Descripción
El sistema creará un nuevo dispositivo, comenzará su
simulación y lo añadirá a la sesión activa.
Actor
Usuario
Precondición
Secuencia
Paso
Acción
Normal
1
El usuario arrastra un dispositivo desde la barra de
herramientas hasta un hueco libre en la vista de
mosaico de la sesión.
2
El sistema comprueba si el usuario tiene una sesión
activa.
3
El sistema mostrará al usuario un formulario en el
que deberá introducir los valores de cada uno de los
parámetros del dispositivo.
4
El usuario elige el tipo de dispositivo
5
El sistema crea el dispositivo, lo conecta a la nube y
comienza su simulación.
6
El sistema añade el dispositivo a la sesión del usuario.
7
El sistema marca la sesión como modificada.
Postcondición
excepciones
En el punto 1, el usuario puede hacer clic sobre uno de los
dispositivos en la barra de herramientas y arrastrar hasta la
vista principal para añadir el dispositivo.
Si el usuario no tiene una sesión activa, se mostrará un
mensaje preguntando si desea crear una nueva sesión. En caso
afirmativo, se pasa al caso de uso Crear Sesión.
20
Figura 6. Diagrama de actividad del caso de uso Crear Dispositivo.
21
Caso de uso
Cargar sesión
Descripción
El sistema cargará la sesión del usuario previamente guardada
para trabajar con ella.
Actor
Usuario
Precondición
El usuario ha guardado previamente una sesión.
Secuencia
Paso
Acción
Normal
1
El usuario pulsa el botón de cargar sesión.
2
El sistema muestra al usuario las sesiones guardadas.
3
El usuario elige la sesión que desea cargar.
4
El sistema comprueba si el usuario está logueado.
5
Si el usuario logueado es el mismo que el usuario de
la sesión que desea cargar, ésta se carga.
6
El sistema conecta todos los dispositivos de esa
sesión a la nube y continúa con su simulación.
Postcondición
La sesión del usuario ha sido cargada para poder trabajar con
ella.
excepciones
Si el usuario no está logueado, se pasa al caso de uso LogIn.
Si el usuario logueado es distinto al de la sesión que se desea
cargar, se muestra un mensaje advirtiéndolo y se pregunta al
usuario si desea loguearse con la otra cuenta. En caso
afirmativo, se pasa el caso de uso LogIn.
22
Figura 7. Diagrama de actividad del caso de uso Cargar Sesión.
23
Caso de uso
Programar evento
Descripción
El sistema programa un evento determinado para uno o varios
dispositivos.
Actor
Usuario
Precondición
El usuario ha seleccionado uno o varios dispositivos.
Secuencia
Paso
Acción
Normal
1
El usuario selecciona uno o varios dispositivos y pulsa
el botón programar evento.
2
El sistema muestra un formulario con los datos del
evento.
3
El usuario introduce el tipo de evento y la fecha.
4
El evento queda programado.
Postcondición
El evento queda programado y se ejecutará en la fecha
determinada.
excepciones
Si llegado el momento de ejecución del evento, la aplicación
no está funcionando, el evento no se llevará a cabo.
Comentarios
Hay eventos que son específicos de un determinado tipo de
dispositivo. Por ejemplo, un camión no puede tener un evento
de apertura/cierre de válvulas. Por ello, si se seleccionan
dispositivos de diferente tipo sólo estarán disponibles los
eventos comunes a ellos.
24
2.2. Diseño
En este bloque se desarrollan los aspectos más importantes relacionados con el diseño de la
aplicación de escritorio, tanto la interfaz gráfica como la arquitectura del sistema y el
almacenamiento de datos.
2.2.1. Diseño de la interfaz de usuario
En este apartado se muestran los prototipos más importantes y su funcionamiento. Para llevar
a cabo el diseño de la interfaz de usuario, se optó por realizar prototipos de baja fidelidad en
las pizarras de la empresa. Esta es una de las técnicas más usadas en Digi y se decidió que esta
era la mejor manera de llevarlos a cabo ya que es un método sencillo, rápido y económico.
La pantalla inicial de la aplicación será la siguiente:
Figura 8. Prototipo de pantalla principal
Como vemos, la ventana principal consta de un menú, una barra de herramientas y un panel
con diferentes pestañas. Cuando se abre la aplicación por primera vez, se observan dos
pestañas abiertas. En la primera pestaña se podrá consultar una documentación HTML sobre la
aplicación, mientras que en la segunda se mostrará una primera sesión vacía (y todavía sin
usuario asignado).
Si cambiamos a la pestaña en la que se encuentra la primera sesión creada, podremos
comenzar a trabajar añadiendo dispositivos. Podemos añadir un dispositivo arrastrándolo
25
desde la barra de herramientas hasta la vista de sesión. En ese momento, el sistema mostrará
al usuario un formulario para que introduzca los valores deseados para cada uno de los
parámetros de la simulación. Por ejemplo, para la creación de un camión introducirá nombre,
versión de firmware
Cuando intentemos añadir un dispositivo por primera vez, el sistema intentará asignar la
sesión de trabajo a un usuario, por lo que será necesario que nos logueemos. Para ello,
aparecerá una ventana en la que el usuario podrá introducir su nombre, contraseña y servidor,
así como el nombre de la sesión que desea crear. Una vez hecho esto, el dispositivo será
añadido a la sesión y podremos seguir trabajando.
De esta forma, la interfaz principal de la vista de sesión quedará de la siguiente forma:
Figura 9. Prototipo de vista de sesión en forma de mosaico
Como vemos, se muestran los dispositivos en forma de mosaico, pudiendo visualizar los
aspectos fundamentales de los mismos como el nombre o el tipo de dispositivo. También
dispondremos de espacios para añadir dispositivos nuevos. Cuando haya más dispositivos
creados de los que se puedan mostrar por pantalla, aparecerá una barra de scroll para poder
visualizarlos todos.
El usuario también tendrá la opción de cambiar la vista. Para ello, debe acceder a View desde
el menú superior. Se puede visualizar el contenido de la sesión en forma de mosaico, como se
ha visto en la figura 9, o en forma de tabla como se muestra a continuación.
26
Figura 10. Prototipo de vista de sesión en forma de tabla
Desde ambas vistas, el usuario podrá seleccionar uno o varios dispositivos haciendo clic sobre
ellos. De esta forma, podrá realizar las siguientes operaciones sobre ellos:






Copiar, cortar y pegar dispositivos.
Eliminar dispositivos.
Ver los detalles de los dispositivos.
Programar eventos.
Configurar dispositivos.
Conectar/desconectar dispositivos.
En lo referente a la barra de menú, el usuario dispondrá de las siguientes opciones:


File: para realizar tareas relacionadas con la sesión.
o New Session: crea una nueva sesión de trabajo.
o Load Session: carga una sesión de trabajo previamente guardada.
o Save Session: guarda la sesión de trabajo actual para poder cargarla de nuevo
más tarde.
o Remove Session: cierra la sesión de trabajo actual y la elimina, eliminando así
todos sus dispositivos asociados.
o Close Session: cierra la sesión.
Devices: para llevar a cabo la funcionalidad relacionada con los dispositivos.
27
o


Remove: elimina un dispositivo de la simulación. Después de pulsar este
botón, la aplicación mostrará un mensaje de alerta para preguntar al usuario si
realmente desea eliminar el dispositivo. Si el usuario no ha seleccionado
ningún dispositivo, este botón no tendrá efecto.
o Configure: permitirá mostrar y modificar los parámetros de configuración del
dispositivo.
o Add Event: al pulsar este botón, se abrirá una ventana con un formulario que
permitirá la programación de eventos para los dispositivos que se hayan
seleccionado.
o Copy/Cut/Paste: permite copiar, cortar o pegar dispositivos. Esta funcionalidad
también se podrá realizar pulsando el botón derecho sobre un dispositivo en la
vista de sesión.
o View details: muestra los detalles de un dispositivo en una nueva pestaña. En
esta vista, el usuario podrá ver una representación gráfica del dispositivo, con
la que podrá interactuar. Del mismo modo, también verá sus detalles como
nombre, Device ID (ID que le asigna la Cloud), si está conectado y otros
aspectos específicos de cada tipo de dispositivo (nivel, válvulas, temperatura,
velocidad, etc). También se podrá acceder a la vista de detalles haciendo doble
clic sobre un dispositivo.
o Connect/Disconnect: conecta o desconecta el dispositivo a la nube.
View: desde aquí el usuario podrá elegir entre la vista de mosaico (vista por defecto) y
la vista de tabla.
Help: este menú tiene dos funciones:
o Welcome page: muestra la página de bienvenida en caso de que no se
estuviera mostrando ya.
o About: da información básica sobre la aplicación como la versión.
La vista de detalles de un tanque y de un camión se muestra en las figuras 11 y 12
respectivamente.
28
Figura 11. Vista de detalle de un tanque
Figura 12. Vista de detalle de un camión.
29
2.2.2. Diagrama de navegación
Tal y como se ha planteado la aplicación, se mostrará una ventana principal al usuario en la
que habrá un panel de pestañas. En este panel se creará una pestaña para la documentación,
otra para la vista de sesión y otra para cada dispositivo que se quiera inspeccionar.
A parte de estas pestañas, se mostrarán ventanas para el LogIn, la programación de eventos y
la configuración de dispositivos.
De este modo, el diagrama de navegación queda del siguiente modo:
Figura 13. Diagrama de navegación
2.2.3. Arquitectura del sistema
Como se ha comentado en la introducción de esta memoria, el sistema completo tendrá una
arquitectura formada por un equipo con la aplicación de escritorio, la nube, un servidor con la
aplicación web y otro equipo en el que se visualiza dicha aplicación.
Por otro lado, en lo que se refiere a la aplicación de escritorio, disponemos de una arquitectura
típica de tres capas:


Capa de presentación: encargada de mostrar los datos al usuario.
Capa de lógica de negocio: llevará a cabo los procesos de la aplicación. En esta capa se
encontrará fundamentalmente la simulación del comportamiento de los dispositivos
simulados.
30

Capa de persistencia: se encarga del almacenamiento y acceso de los datos.
Principalmente se ocupará de la comunicación con la nube y del almacenamiento de
datos en el equipo.
2.2.4. Almacenamiento de datos
Como hemos comentado en el punto anterior, nos encontraremos con dos ubicaciones
distintas para el almacenamiento de los datos:
Equipo
En el equipo en el que esté funcionando la aplicación de escritorio será necesario almacenar
cierta información de la sesión. Se guardará el estado de la sesión, es decir, los dispositivos que
hay simulados, así como su configuración, programación de eventos y su estado en un
determinado momento. También será necesario almacenar el usuario al que pertenece la
sesión (por razones de seguridad no se almacenará la contraseña).
Esta información es necesaria almacenarla en el equipo para poder permitir al usuario la
simulación y el trabajo en modo offline, es decir, sin conexión a internet.
Debido a la poca cantidad de datos que hay que almacenar y a su estructura sencilla, se ha
optado por no utilizar una base de datos sino guardar esta información en el equipo utilizando
una estructura de directorios. Esta decisión está justificada por la sencillez del método y
porque permitirá al usuario navegar por dicha estructura de carpetas y visualizar los
dispositivos con sus correspondientes archivos de configuración, que serán los mismos que los
utilizados en aplicaciones reales.
Etherios Cloud
El otro punto de almacenamiento de datos es la nube de Digi, a la que se conectarán los
dispositivos simulados y enviarán datos sobre su simulación. Para ello, Etherios Cloud ofrece
varias formas de almacenamiento, de las cuales usaremos dos fundamentalmente. La primera
consiste en un sistema de ficheros, donde se almacenará información sobre las notificaciones
de una sesión y sobre los dispositivos que hay en cada sesión, teniendo de esta forma dos
archivos llamados NombreSesionNotifications.txt y NombreSession.txt. La segunda forma que
utilizaremos para subir datos a la nube será mediante DataStreams. Los DataStream son flujos
de datos asociados a cada dispositivo que permiten almacenar datos a lo largo del tiempo. Los
DataStream suponen una forma de almacenamiento más sólida, ya que se puede definir su
tipo (entero, String, booleano, etc), añadir una descripción, determinar tiempo de validez,
visualizar gráficos sobre sus valores a lo largo del tiempo, etc. Esta será la forma de almacenar
los datos sobre la simulación de cada dispositivo (nivel, temperatura, velocidad, etc).
31
2.2.6. Diseño de clases
Como hemos dicho, la aplicación estará dividida en tres capas. Debido a la naturaleza del
problema a resolver, no se ha hecho distinción entre modelo de la aplicación y lógica de
negocio. Esto es debido a que las clases del modelo y las de la lógica de negocio están
estrechamente unidas y la línea que las separa se difumina en muchas ocasiones. Así, las clases
correspondientes con los dispositivos simulados y las correspondientes a su simulación o
comportamiento están unidas en la lógica de negocio.
Figura 14. Diagrama de paquetes
En la capa de presentación se incluirán las clases que se encargan de mostrar la información al
usuario. Por simplicidad, en los diagramas de clases siguientes no se han incluido los accesores
(tanto getters como setters) ni todos los constructores de las clases.
Figura 15. Clases de la capa de presentación
32
En la capa de presentación, cabe destacar lo siguiente:




Las clases TankDetail y TruckDetail formarán las ventanas de detalle del tanque y
camión respectivamente.
MainWindow será la ventana principal de la aplicación.
TankControl consistirá en un elemento gráfico encargado de mostrar el estado de un
tanque en todo momento y permitir al usuario interactuar con él (tal y como se ve en
la Figura 11. Vista de detalle de un tanque).
TruckMap será el encargado de mostrar la ruta y el punto en el que se encuentra un
camión en todo momento, actualizándose según se mueva el camión.
Por otro lado se encuentran las clases de la lógica de negocio. En este paquete se engloban
todas las clases relacionadas con los dispositivos simulados, su comportamiento, eventos,
sesión y funcionalidades como el LogIn.
Figura 15. Clases de la capa de lógica de negocio
Por último, en la capa de persistencia encontramos tres clases: CloudConnector, SessionSaver,
DeviceFileConfiguration y RoutePoints. La clase CloudConnector se encarga de llevar a cabo la
comunicación con el Cloud. Esta clase ya estaba desarrollada por Digi y se ha incluido en el
proyecto para utilizar su funcionalidad. Por otro lado, tenemos la clase SessionSaver que se
encarga de almacenar en el equipo todos los datos relacionados con la sesión (usuario,
dispositivos y su estado, etc) para su posterior uso. La clase DeviceFileConfiguration se encarga
33
de guardar información de configuración sobre los dispositivos simulados (nombre y tipo, ya
que el resto de información se almacena en el archivo connector_config.txt que ha de usarse
con la clase CloudConnector). Por último, la clase RoutePoints se encarga de seleccionar
puntos para crear la ruta de un camión, escogiendo un punto de inicio y otro de final de un
fichero con diferentes ciudades.
Figura 16. Clases de la capa de persistencia
2.2.7. Diseño del plan de pruebas
En este apartado se especifica el método a seguir para llevar a cabo las pruebas necesarias en
la fase de test, la última del proyecto. Es importante destacar que durante la implementación
también se irán haciendo pruebas aunque la gran parte de las mismas se realizarán al final,
decidiendo así la aceptación de la parte del producto que se esté probando o, en caso de error,
revisando el código y corrigiendo los posibles fallos.
Se van a realizar tres tipos de pruebas:



Pruebas unitarias: estas pruebas se llevarán a cabo para probar el correcto
funcionamiento de un determinado módulo de código.
Pruebas de integración: son las pruebas que se realizan una vez se han aprobado las
pruebas unitarias. Se refieren a la prueba de todos los elementos unitarios que
componen un proceso, hecha en conjunto.
Pruebas de aceptación: son las pruebas finales que se utilizan para determinar que el
producto desarrollado cumple con las especificaciones iniciales y logra su cometido.
34
Todas las pruebas que se lleven a cabo han de ser documentadas en una tabla de la siguiente
forma:
Test ID
Grupo
Nombre del test
Descripción
Resultado
Comentarios
Figura 17. Tabla utilizada para los casos de test
2.3. Implementación
En este apartado se recogen los aspectos más destacables de la implementación del
proyecto, incluyendo las tecnologías y librerías externas utilizadas, así como
información sobre el desarrollo de la aplicación, los problemas encontrados y su
manera de resolverlos.
2.3.1. Tecnologías usadas
Uno de los aspectos fundamentales del proyecto era que debía poder ejecutarse en diferentes
sistemas operativos. Por ello, se estudiaron diferentes posibilidades sobre tecnologías a utilizar
y se evaluó el uso de plataformas que permitían el desarrollo de aplicaciones de escritorio con
tecnologías web como HTML5, CSS3 y Javascript, lo cual permitía la elaboración de unas
interfaces de usuario más profesionales y personalizables. Finalmente se optó por utilizar Java,
ya que los frameworks analizados no permitían la incorporación de Java en los mismos,
lenguaje en el que están escritas las principales librerías a utilizar.
Dentro de Java, se decidió utilizar JavaFX, que es una familia de productos y tecnologías de
Oracle que permiten la creación de interfaces de usuario más ricas, interactivas y
personalizables que otras tecnologías de Java como Swing o SWT. La forma de trabajar con
JavaFX consiste la implementación del patrón Modelo-Vista-Controlador. De este modo,
tenemos principalmente dos documentos: un FXML que contiene la información de la interfaz
gráfica de usuario y una clase Java que hace de controlador y permite modificar
dinámicamente dicha interfaz. Para editar estos documentos FXML se ha utilizado el programa
SceneBuilder, que es un diseñador que nos permite modificar las interfaces de una forma más
gráfica e intuitiva. Otra tecnología utilizada ha sido CSS, ya que JavaFX también permite la
personalización de sus interfaces de usuario utilizando este lenguaje.
Por último también se utilizó, aunque en menor medida, Javascript. Su utilización se justifica
por el uso de un mapa de Google Maps para poder mostrar la ruta del camión y ver cómo la va
recorriendo, conociendo así su posición exacta en cada momento.
35
2.3.2. Librerías empleadas
A la hora de la implementación se han utilizado diferentes librerías para facilitar el proceso. Las
principales han sido las siguientes:
1. Cloud Connector for Java: se trata de la librería más importante utilizada en el
proyecto. Esta librería ha sido desarrollada por Digi y nos proporciona funcionalidad
para conectar dispositivos a Etherios Device Cloud, así como para enviar datos (tanto
ficheros como DataStreams) y para recibir peticiones desde la misma.
2. JavaFX-DatePicker: librería de JavaFX que permite mostrar un calendario y elegir una
fecha del mismo. Se utilizó esta librería para que el usuario pueda seleccionar la fecha
en la que se programa un evento.
3. JavaFX-MessageBox: librería de JavaFX para mostrar mensajes al usuario de una forma
sencilla.
2.3.4. Desarrollo de la aplicación
En este apartado se profundiza en la implementación de la aplicación, centrándonos en los
aspectos más destacables de la misma y los problemas surgidos más interesantes así como la
forma en la que se resolvieron.
Tareas en segundo plano e hilos
La aplicación desarrollada es una simulación de dispositivos y su comportamiento, lo que
implica que la aplicación debe realizar diferentes tareas en segundo plano sin que el usuario
deba interactuar con la misma. Por ejemplo, a la hora de crear un camión, éste debe comenzar
la simulación de la ruta que debe recorrer, así como de la temperatura del mismo.
Para cada elemento de la simulación, hay un hilo corriendo en segundo plano que se encarga
de generar los nuevos valores de cada parámetro y enviar estos valores a la nube en caso de
que sea necesario. A continuación, se van a dar más detalles sobre cada uno de los hilos que
están funcionando cuando hay una sesión con varios dispositivos abiertos.
Hilos de un camión
La simulación de un camión está compuesta por diferentes elementos pero el más importante
es la posición en la que se encuentra y cómo se va moviendo durante la ruta. Esta simulación
se lleva a cabo mediante una vista web en la que se carga un mapa de Google Maps con una
determinada ruta y se ejecuta un código Javascript que hace que el camión se vaya moviendo
a lo largo de la misma. El principal problema en este apartado de la simulación vino debido a la
forma de comunicar el código Java de nuestra aplicación con el Javascript que se está
ejecutando en el Web View. Esto era necesario para saber en un momento determinado la
posición en la que se encuentra el camión, para modificar la ruta dinámicamente o para
modificar la velocidad con la que se mueve dicho camión. Para realizar esto, se ha utilizado
una clase denominada JSObject que nos permite cargar código Javascript y acceder a variables
guardadas en el document. De esta forma, toda la simulación del movimiento del camión se
36
lleva a cabo desde código Javascript mientras que Java se encarga de tener un timer que cada
20 segundos obtiene el valor de la localización del camión y lo envía a la nube así como de
capturar los eventos de cambio de velocidad y llamar a un método Javascript que modifica
dicho parámetro en la simulación.
Esta simulación con Google Maps ha supuesto el problema más importante encontrado en la
aplicación. Este problema consiste en un Memory Leak relacionado con el API Javascript que
ofrece Google para sus mapas. Esto hace que la memoria consumida por la aplicación crezca
de una forma irregular e inexorable. Esto es debido a que Google Maps no ofrece ningún
método para liberar memoria (incluso hay un bug abierto en Google relacionado con este
tema), por lo que cuando un camión se mueve a lo largo de una ruta necesita cargar nuevo
mapa y esto hace que la memoria crezca sin parar. Como vemos en el apartado de
seguimiento y control, se ha invertido un total de 10 horas en intentar resolver el problema y
no se ha conseguido. La consecuencia de este problema es que la aplicación no se podrá tener
abierta durante muchas horas (se estiman unas 12 como máximo) con la simulación de un
camión ya que el uso de memoria es excesivo y Java cierra la aplicación.
Otro aspecto importante en la simulación del camión es la temperatura. Para ello, hay un
timer que obtiene un valor aleatorio entre en el rango de (temperatura -3, temperatura +3) y
lo envía a la nube. Esta simulación puede ser interrumpida cuando se recibe una petición de
cambio de temperatura desde la aplicación web. En este caso, se cancelará este hilo y se
arrancará otro que aumentará o disminuirá la temperatura poco a poco hasta llegar al valor
deseado. Una vez alcanzado dicho valor, el hilo que realiza la simulación inicial volverá a ser
arrancado y continuará calculando valores aleatorios.
Hilos de un tanque
La simulación de un tanque es más sencilla ya que se trata de un elemento más estático. Un
tanque sólo dispone de un hilo funcionando en segundo plano que se encarga de llevar a cabo
la simulación de la temperatura, del mismo modo que ocurre con un camión.
Por otro lado, cuando se va a cambiar el nivel del tanque debido a que el usuario ha pulsado
en una de las válvulas, a que se ha programado un evento de cambio de nivel o a que se ha
recibido una petición desde la aplicación web, la aplicación inicia otro hilo que se encarga de ir
aumentando o disminuyendo el nivel a una determinada velocidad (se vaciará más rápido de lo
que se llena). Este hilo modificará el elemento gráfico que simula el tanque y enviará el nuevo
nivel a la nube (o lo guardará si estamos trabajando offline).
Peticiones al Cloud
Para llevar a cabo la comunicación con la nube y el envío de datos, se han llevado a cabo dos
tipos de peticiones:

Peticiones mediante el CloudConnector: son las peticiones que se llevan a cabo de una
forma transparente para el programador ya que son implementadas mediante la
librería CloudConnector. Como se comentó anteriormente, esta librería permite
principalmente conectar y desconectar dispositivos y enviar archivos y DataStreams a
37
la nube. Con esta librería se envían los principales datos de la simulación de cada
dispositivo, como la temperatura, velocidad, nivel, etc.

Peticiones Web. Hay otro tipo de funcionalidad requerida para la implementación de
la aplicación que no se podía realizar mediante la librería CloudConnector, por lo que
era necesario implementar peticiones web utilizando la API REST que nos ofrece la
nube de Digi. Para implementar esto, se ha realizado en el paquete de persistencia una
clase llamada CloudCommunicator. Con esta clase realizamos peticiones para subir
ficheros en la raíz de la nube (ya que si lo hacemos con el CloudConnector estos
ficheros quedan asociados a un determinado dispositivo) que aportan información
sobre qué dispositivos hay en cada sesión o sobre notificaciones de la sesión. También
se realizan peticiones para eliminar dispositivos de la nube así como sus DataStreams
asociados.
Modo offline
Cuando un dispositivo no está conectado a la nube, la simulación debe continuar de forma
normal y estos datos deben guardarse para poder enviarse más adelante a la nube. Para ello,
en el paquete de persistencia se ha realizado una clase llamada DataStreamSender que es
utilizada por los dispositivos simulados para enviar sus datos. Esta clase comprueba si un
dispositivo está conectado a la nube y, si es así, envía los datos de forma normal utilizando la
clase CloudConnector. De no ser así, esta clase se encarga de guardar dichos datos en un
directorio denominado DataStreams que contiene un fichero para cada DataStream del
dispositivo. Estos DataStreams son almacenados en formato CSV y se guarda una fila para cada
DataPoint del DataStreams. A cada DataPoint se le asocia un TimeStamp para saber en qué
momento se ha generado ese dato.
Una vez que capturamos el evento indicándonos que el dispositivo ha sido conectado de
nuevo, llamamos a un método de esta clase que se encarga de leer los ficheros con
DataStreams almacenados, enviarlos a la nube con la clase CloudConnector y borrar los
ficheros.
Desarrollo de las interfaces
Como hemos comentado en el apartado 2.3.1, se ha utilizado JavaFX como tecnología, lo cual
nos permite utilizar un MVC para desarrollar las aplicaciones. De esta forma, las interfaces de
usuario se han creado con documentos FXML, lo cual ha facilitado mucho su implementación.
En la figura 18 se muestra un ejemplo de un fragmento de código FXML para el diseño del
menú:
38
Figura 18. Fragmento de documento FXML para el menú
A la hora de desarrollar las interfaces de usuario se han llevado varios cambios con las
interfaces que se habían diseñado en un principio. Estos cambios han sido hechos
principalmente para hacer que los datos de la simulación de cada dispositivo se muestren de
una forma más gráfica. De esta forma, se ha introducido un termostato para mostrar la
temperatura y permitir al usuario modificarla tanto en la simulación del camión como en la del
tanque. En la vista de detalle del tanque también se ha añadido un mapa para poder observar
la localización del mismo aunque, a diferencia de como ocurre con un tanque, esta localización
será fija y sólo podrá modificarse en la configuración del tanque. En las figuras 19 y 20 se
puede observar el resultado final de las interfaces.
39
Figura 19. Interfaz final de la simulación de un tanque
Figura 20. Interfaz final de la simulación de un camión
Cambios en la librería CloudConnector
Como hemos introducido en el apartado 2.3.2, la principal librería utilizada ha sido la librería
desarrollada por Digi que nos permite crear dispositivos conectados a la nube y enviar datos a
la misma.
40
La clase más importante de esta librería es la llamada CloudConnector. Esta clase utiliza un
archivo de configuración denominado “connector_config.txt” en el que se almacenan los
parámetros necesarios para realizar la conexión del dispositivo con la nube.
El principal problema relacionado con esta librería es que había sido diseñada para que sólo se
permita utilizar una instancia de la clase CloudConnector. Esto fue desarrollado así porque ha
sido pensada para que se ejecute en un dispositivo, por lo que sólo habrá que utilizar una
conexión con la nube. Pero nuestro proyecto iba más allá, ya que es imprescindible que se
puedan crear varias instancias de la clase CloudConnector en un solo dispositivo (en este caso,
un ordenador). Para ello, fue necesario obtener el código de la librería, estudiarlo y realizar los
cambios pertinentes en el mismo.
Para adaptar la librería a nuestras necesidades han sido necesarios dos cambios:
1. Añadir un parámetro a la clase que nos permitiera indicar la localización en la que se
guardaba el fichero de configuración del dispositivo, ya que antes la localización debía
ser necesariamente la raíz del sistema de ficheros. Esto hacía que no se pudiera tener
un fichero de configuración para cada dispositivo ya que todos deben tener el mismo
nombre.
2. Modificar la forma en la que se lee y se escribe en dicho fichero de configuración ya
que, al haber varias instancias de la clase CloudConnector corriendo en varios hilos,
había problemas de sincronización.
Además de los cambios aquí mencionados, ha sido necesario extender varias clases de dicha
librería. Esto ha sido necesario ya que se requería hacer cambios en el modo en que se lleva a
cabo el log del dispositivo y la actualización de firmware. Para ello, se ha extendido de las
clases encargadas de realizar dichas funciones y se han sobrescrito los métodos necesarios.
La clase que se encarga de la actualización de firmware debe aumentar en un valor el número
de versión, mientras que la clase del log debe guardar dicha información en un fichero que en
encontrará en la raíz del sistema de ficheros del dispositivo.
En la figura 21 se muestra la clase realizada para la realización del log del dispositivo. Esta clase
extiende la clase GeneralConnectorLogger y sobrescribe el método log(String text).
41
Figura 21. Extensión de la clase GeneralConnectorLogger para la implementación de log de un dispositivo
Limitaciones del Cloud
Un aspecto muy a tener en cuenta en la implementación de la aplicación han sido las
limitaciones que nos impone el Cloud. Una cuenta de Etherios Device Cloud puede ser de dos
tipos: gratuita o de pago. Las cuentas gratuitas permiten un máximo de 5 dispositivos
conectados, por lo que ha sido necesario implementar funcionalidad para comprobar la
respuesta del servidor y, en caso de que este nos indique que se ha alcanzado el máximo de
dispositivos, informar al usuario de que su cuenta no admite más dispositivos.
Otra limitación que nos impone el Cloud es el número de peticiones. Se admiten un máximo de
10 peticiones en 10 segundos. En el caso de que se supere este número de peticiones, el Cloud
mandará como respuesta un error denominado Throttle. Esto quiere decir que los datos que
enviemos a la nube pueden no llegar correctamente al Cloud. Lamentablemente, la librería
CloudConnector no nos ofrece la funcionalidad necesaria para saber cuándo ha fallado un dato
en concreto. Así, se ha optado por enviar todos los datos periódicamente a la nube aunque no
hayan sido modificados. De este modo, todos los datos de un dispositivo se envían cada
minuto.
Un momento importante en el que pueden fallar los datos que se envían a la nube es cuando
se produce la reconexión y han de enviarse los datos obtenidos durante el tiempo que ha
estado el dispositivo desconectado. Para ello, hay que hacer una petición a la nube por cada
DataStream. Esto hace que si coincide que en ese momento se están realizando varias
peticiones a la nube, pueda saltar el Throttle y no enviarse dichos datos. Tal y como está
desarrollada la librería CloudConnector actualmente, no es posible solventar este problema de
una forma eficiente. En futuras actualizaciones, la librería CloudConnector incorporará
42
funcionalidad para enviar todos estos datos en una sola petición, lo que hará mucho menos
probable que estos datos se pierdan debido a un Throttle.
Localización de dispositivos
Tanto los tanques como los camiones disponen de al menos un campo que indica la
localización de dicho dispositivo. Para ello, se ha creado una clase denominada GeoPoint que
contiene la longitud, latitud y dirección del punto que se quiere representar. Además de esta
clase, se utiliza otra para clase denominada GeoCoder con métodos estáticos para conectar
con el servicio de Google Maps y traducir direcciones a coordenadas. De esta forma, es posible
indicar una dirección para especificar la localización de un dispositivo, lo cual es mucho más
sencillo para el usuario que introducir unas coordenadas.
Cortar dispositivos
Una de la funcionalidad a desarrollar era la de cortar dispositivos, que servía de complemento
a las de copiar y pegar. La forma en la que se implementó esta funcionalidad fue la siguiente:
se mandaba al Cloud una petición para eliminar un determinado dispositivo y se creaba otro
con todos los datos de la simulación iguales (a excepción del DeviceID, que debe ser único para
cada dispositivo). Tras realizar varias pruebas, se observó que siempre se obtenía la misma
respuesta del servidor. Esta respuesta era la misma que se recibía cuando se deseaban añadir
más dispositivos de los que una cuenta permitía, es decir, “Device ID not provided from
provisioning”. Tras analizar el problema individualmente y con ayuda de varios ingenieros de
Digi, no se consiguió encontrar la causa del problema.
Además, se volvió a hacer un análisis de dicha funcionalidad y se llegó a la conclusión de que
no nos ofrecía nada nuevo. Lo realmente útil es copiar un dispositivo y pegarlo varias veces
para así obtener una simulación de muchos dispositivos sin tener que introducir cada uno de
ellos. Por ello, se decidió eliminar la funcionalidad de cortar dispositivos.
Limitaciones
Tras llevar a cabo la implementación del proyecto, se ha descubierto que la aplicación tiene
diferentes limitaciones debidas a aspectos técnicos del mismo. Entre ellas destacamos:



Pérdida de datos: cuando salta el thorttle, no hay forma de saber qué dataPoint ha
sido el que ha fallado. Por lo tanto, no se puede volver a enviar y es posible que
algunos datos se pierdan y no se actualicen en la nube hasta dentro de un minuto
(intervalo en el que se envían todos los datos de nuevo).
Firmware update: cuando se hace una actualización de firmware o se cambian
parámetros como la descripción de un dispositivo, el Cloud no recibe ninguna
notificación de ello. Esto es debido a que se trata de una simulación y, por lo tanto, el
dispositivo no puede reiniciarse después de actualizar su firmware (se desconecta
durante 10 segundos y se vuelve a conectar, simulando el reinicio). Al no reiniciarse, el
CloudConnector no vuelve a cargar todos los datos del fichero de configuración ni se
notifica a la nube. Por ello, la única forma en la que se puede actualizar correctamente
el firmware en la nube es cerrando y abriendo de nuevo la sesión, lo que hace que se
vuelva a crear la clase CloudConnector y vuelva a cargar todos los datos.
Para realizar una actualización de firmware desde la nube es necesario pasar como
parámetro un fichero binario. Este fichero puede tener cualquier contenido o incluso
estar vacío y debe tener un tamaño menor de 2MB.
43
2.4. Pruebas
Tal y como se especificó en el plan de pruebas, se van a llevar a cabo pruebas unitarias, de
integración y de adaptación. A continuación se muestran algunos ejemplos de las pruebas
llevadas a cabo en la fase de test. Para ver todos los casos de test, acudir a Anexo1.Pruebas.
Pruebas unitarias:
Test ID: 04
Grupo
Nombre del test
Descripción
Resultado
Comentarios
Test ID: 05
Grupo
Nombre del test
Descripción
Resultado
Comentarios
Test ID: 22
Grupo
Nombre del test
Descripción
Resultado
Comentarios
Sesión
Cerrar y guardar sesión
Crear una sesión y añadir un nuevo dispositivo
Guardar la sesión
Añadir un nuevo dispositivo
Cerrar la sesión sin guardarla
Cargar la sesión de nuevo y verificar que el primer dispositivo ha sido
guardado y el último eliminado
Parcialmente correcto
Encontramos un error cuando, al crear un camión, introducimos dos
puntos de ruta que no pueden ser conectados (por ejemplo, uno en
América y otro en Europa). Este es un fallo a solucionar en un futuro, pero
no se solucionará para el proyecto por falta de tiempo.
Sesión
Guardar el estado de los dispositivos
Crear una sesión y añadir un tanque y un camión
Guardar la sesión
Modificar el estado del camión y del tanque (válvulas, temperatura,
velocidad, etc)
Cerrar la aplicación
Abrir la aplicación y cargar la sesión
Verificar que el estado de los dispositivos es el esperado
Correcto
Configuración
Configurar un dispositivo
Crear una sesión con un dispositivo
Seleccionar el dispositivo y pulsar en el botón configurar del menú
Cambiar los parámetros de configuración
Comprobar que el comportamiento del dispositivo es el esperado
Cambiar la descripción y la información de contacto
Verificar que los datos han sido actualizados correctamente
Cuando cambiamos la descripción y el email, estos datos se actualizan
correctamente en la aplicación pero no en la nube. Esto es debido a que
estos datos se actualizan en el fichero de configuración en local pero no
44
en la instancia de la clase CloudConnector. Esto es debido a la forma en la
que está diseñada y programa dicha clase, por lo que no hay nada que se
pueda hacer para solucionar este error.
Pruebas de integración
Test ID: 14
Grupo
Nombre del test
Descripción
Resultado
Comentarios
Test ID: 19
Grupo
Nombre del test
Descripción
Resultado
Comentarios
Test ID: 27
Grupo
Nombre del test
Descripción
Datos & Conexión
Modificar los datos del camión
Crear una sesión con un camión
Modificar la velocidad del camión, el estado de la puerta, la temperatura y
la ruta.
Verificar que estos datos se actualizan en la nube y que se muestran
correctamente desde la aplicación web
Repetir los pasos anteriores varias veces
Correcto
Peticiones
Peticiones de un tanque
Crear una sesión con un tanque
Enviar varias peticiones desde la aplicación web para abrir y cerrar las
válvulas y para cambiar la temperatura
Verificar que el comportamiento del tanque es el esperado
Enviar varias peticiones para actualizar el firmware
Comprobar que el firmware ha sido actualizado
Enviar una petición para desconectar el tanque
Verificar que el tanque se desconecta y se vuelve a conectar pasado el
tiempo determinado (si así está especificado en la configuración)
Enviar peticiones para ver el Log del dispositivo.
De nuevo tenemos el mismo error que en el test 22, pero esta vez con la
versión de firmware. Este error ha sido reportado a los desarrolladores de
Digi, que trabajarán para solucionarlo.
Archivos de sesión
Archivo de notificaciones
Crear una sesión
Comprobar que el archivo de notificaciones de la nube ha sido creado y
que se muestra la nueva sesión desde la aplicación web
Añadir varios dispositivos a la sesión
Comprobar que el archivo de notificaciones ha sido actualizado y las
notificaciones se muestran en la aplicación web
Eliminar un dispositivo
Comprobar las notificaciones
45
Resultado
Comentarios
Guardar y cerrar la sesión
Comprobar que el archivo ha sido eliminado de la nube
Correcto
Pruebas de aceptación
Las pruebas de aceptación se fueron realizando cada dos semanas en las reuniones de revisión
de cada Sprint. En estas reuniones, se mostraba al Product Owner el estado del proyecto y su
avance desde la última reunión. Tras esto, él era el encargado de determinar si el incremento
obtenido en ese Sprint cumplía con los requisitos iniciales, así como de añadir nueva
funcionalidad o de eliminar alguna que se consideraba innecesaria.
También se realizaron pruebas en diferentes ordenadores y sistemas operativos. En este
aspecto encontramos dos limitaciones bastante importantes. Debido a problemas con la
librería CloudConnector, ajenos al proyecto, se obtiene un fallo al ejecutar la aplicación en
Linux. Los desarrolladores de Digi están trabajando en ello y se espera que se solucione
próximamente.
La limitación más importante está relacionada con JavaFX. El proyecto utiliza una versión de
JavaFX que no es la última desarrollada. En las últimas versiones de JavaFX, Oracle ha realizado
cambios importantes y no han asegurado la compatibilidad hacia atrás, lo que hace que el
proyecto no funcione en determinadas máquinas virtuales de Java. Se estudió la migración del
proyecto a la última versión de JavaFX, pero esto suponía realizar grandes cambios en todos
los aspectos gráficos del proyecto, por lo que se desechó la idea por falta de tiempo.
46
Capítulo 3. Conclusiones
En este apartado se resumen las conclusiones obtenidas del proyecto, así como las lecciones
aprendidas y dificultades encontradas, la evaluación de los objetivos y las futuras mejoras del
proyecto.
3.1. Evaluación de objetivos
Al comienzo del proyecto se especificaron los objetivos que debía cumplir el proyecto. Tras la
finalización del mismo, es necesaria comprobar que, efectivamente, se han cumplido todos
ellos.
En lo referente al objetivo principal, podemos comprobar que se ha cumplido correctamente,
ya que se ha creado un sistema que permite a los futuros clientes de Digi comprobar el
potencial de las soluciones M2M sin la necesidad de comprar dispositivos reales o de instalar
software en dichos dispositivos.
En cuanto a los objetivos generales, se han conseguido cumplir con éxito ya que el sistema
desarrollado está compuesto por una aplicación de escritorio (la correspondiente con este
proyecto) y una aplicación web. Así, este sistema permite monitorizar datos de los dispositivos
simulados y establecer una comunicación bidireccional entre las dos partes del mismo.
También se ha invertido una cantidad importante de horas en comprobar que el sistema
funciona correctamente, llevando a cabo varias casos de test.
Finalmente, en lo que se refiere a los objetivos concretos de la aplicación de escritorio, vemos
que hay una carencia que hace que uno de los objetivos se haya cumplido de forma parcial.
Este objetivo especificaba que la aplicación debería poder ejecutarse en diferentes sistemas
operativos. Debido a limitaciones externas al proyecto no se puede ejecutar en Linux, pero se
espera que esto sea solucionado por los desarrolladores de Digi en breve. Además, tal y como
se ha comentado previamente, la aplicación es dependiente de la versión de Java para que
funcione correctamente.
Los demás objetivos de la aplicación de escritorio se han cumplido correctamente. Esta
aplicación permite simular dispositivos reales y su comportamiento, siendo estos dispositivos
los más comunes entre las soluciones M2M que genera Digi (tanque y camión). El sistema
también permite realizar una simulación bastante realista en la que el usuario puede
interactuar con ella para modificar parámetros de la misma. Por último, se ha desarrollado un
manual para el correcto uso del sistema por parte de los clientes. El manual estará accesible
desde la página web y desde la aplicación de escritorio.
3.2. Dificultades encontradas y lecciones aprendidas
A pesar de que en el apartado de implementación ya se han mencionado las principales
dificultades encontradas, se ha decidido hacer un análisis de las mismas en las conclusiones,
así como realizar una reflexión sobre las lecciones aprendidas a lo largo del proyecto.
Muchas de las dificultades que se han encontrado en el proyecto han venido por la tecnología
escogida para desarrollarlo. En muchas ocasiones, como en el caso de este proyecto, la
47
tecnología viene impuesta, ya que hay determinados requisitos que debe cumplir el producto
final (por ejemplo, plataformas en las que ha de funcionar). En los casos en los que se pueda
elegir la tecnología, es necesario invertir tiempo en realizar un buen análisis de todas las
herramientas disponibles para poder elegir la más conveniente ya que será algo que utilicemos
durante un periodo de tiempo amplio y que condicionará el proyecto. Además, en muchos
casos, una vez elegida una tecnología es muy difícil cambiarla o migrar el proyecto a otra.
El hecho de que el proyecto haya sido un proyecto real de una empresa, con el añadido de que
es un internacional, ha sido una experiencia muy enriquecedora, ya que ha hecho que se
experimenten de primera mano los problemas encontrados en un proyecto real de una
empresa real. Una lección aprendida muy importante ha sido que los requisitos del proyecto
pueden cambiar. La persona encargada de establecer los requisitos puede cambiar de opinión
durante el tiempo de desarrollo del proyecto, lo que implica que será necesario hacer cambios.
Es muy importante estar preparado en todo momento para el cambio, ya que es algo
inevitable y puede hacer que el trabajo que hemos realizado durante un determinado periodo
de tiempo ya no sirva para nada.
También se han adquirido importantes habilidades transversales muy importantes a la hora de
trabajar en una empresa. Entre ellas destacamos la capacidad de trabajar en equipo, de
participar en reuniones y tomar decisiones de forma autónoma y teniendo en cuenta los
requisitos impuestos. Del mismo modo, también se han puesto en práctica muchos de los
conocimientos aprendidos durante la carrera, tanto técnicos como transversales, como por
ejemplo guiar un proyecto propio pasando por todas las fases del mismo, realizando una
planificación adecuada y un seguimiento y control que nos permitan garantizar que el proyecto
será realizado en un tiempo lo más parecido posible al estimado y con los objetivos
establecidos cumplidos.
Por último, una lección aprendida a destacar es la importancia del correcto uso del inglés en el
mundo empresarial. Como ya se ha comentado, el proyecto se ha desarrollado en el ámbito de
la empresa Digi International, que es una multinacional americana. Esto ha hecho que toda la
documentación realizada para la empresa tenga que ser en inglés, así como los correos
electrónicos escritos internamente o la documentación leída para adquirir los conocimientos
necesarios para implementar el proyecto.
3.3. Futuras mejoras del proyecto
A lo largo de la memoria ya se han comentado diferentes aspectos que no se han realizado
debido a la falta de tiempo. Además de estos, aquí comentamos algunos más:


Permitir simular más dispositivos de clientes típicos de Digi como por ejemplo metro,
autobús, contenedores, sistemas médicos, paneles solares, estaciones meteorológicas,
etc.
Permitir grabar secuencias de acciones para programarlas sobre determinados
dispositivos. Por ejemplo, para un tanque, una secuencia de abrir la válvula de
entrada, cambiar la temperatura y abrir la válvula de salida
48


Permitir al usuario organizar los diferentes dispositivos en grupos, permitiendo así una
visualización más cómoda en el caso de tener muchos dispositivos y permitiendo
también realizar acciones sobre un grupo entero.
Implementar la configuración con el descriptor. Digi dispone de un archivo que se
utiliza como descriptor de dispositivos. En este archivo se indican los elementos que se
desean guardar del mismo. Una mejora interesante para futuro sería incorporar dicho
descriptor a la aplicación para que se puedan configurar qué parámetros enviar a la
nube. Esto no se ha llevado a cabo en el proyecto debido a que fue una característica
que incorporó Digi cuando el proyecto estaba muy avanzado.
Capítulo 4. Bibliografía





Guías y manuales de Digi sobre Etherios Device Cloud:
o http://ftp1.digi.com/support/documentation/html/90001150/90001150_R/De
fault.htm
o http://ftp1.digi.com/support/documentation/html/90002008/90002008_P/De
fault.htm
Apuntes sobre Threads, Networking y REST por Francisco García Izquierdo de la
asignatura Sistemas Distribuidos
Apuntes sobre EVS y Requisitos, Análisis, Diseño y Pruebas por Juan José Olarte Larrea
de la asignatura Ingeniería del Software
Manuales de JavaFX:
o http://docs.oracle.com/javase/8/javase-clienttechnologies.htm
http://stackoverflow.com
49
Anexos
Anexo 1. Casos de uso
Caso de uso
Guardar sesión
Descripción
El sistema guardará la sesión activa del usuario.
Actor
Usuario
Precondición
Secuencia
Paso
Normal
Acción
1
El usuario pulsa el botón de guardar sesión
2
El sistema comprueba que la sesión ha sido
3
El sistema guarda los datos de la sesión.
Postcondición
La sesión del usuario ha sido guardada.
excepciones
Si la sesión del usuario no ha sido modificada desde la última
vez que se guardó, el sistema no hace nada.
Comentarios
Caso de uso
Cerrar sesión
Descripción
El sistema cerrará la sesión activa del usuario.
Actor
Usuario
Precondición
Secuencia
Paso
Acción
1
El usuario pulsa el botón de cerrar sesión
2
El sistema comprueba si la sesión no ha sido
3
El sistema cierra la sesión.
Normal
Postcondición
50
excepciones
Si la sesión del usuario ha sido modificada desde la última vez
que se guardó, el sistema pregunta al usuario si desea guardar.
En caso afirmativo se procede al caso de uso Guardar sesión.
Comentarios
Caso de uso
Eliminar dispositivo
Descripción
El sistema eliminará el dispositivo de la simulación
Actor
Usuario
Precondición
Secuencia
Paso
Acción
1
El usuario pulsa el botón eliminar dispositivo
2
El sistema elimina todos los dispositivos que habían
sido seleccionados.
3
Normal
Postcondición
El/los dispositivos seleccionados quedan eliminados de la
simulación
excepciones
Comentarios
Caso de uso
Crear dispositivo
Descripción
El sistema creará un nuevo dispositivo, comenzará su
simulación y lo añadirá a la sesión activa.
Actor
Usuario
Precondición
Secuencia
Paso
1
Acción
El usuario pulsa el botón de añadir dispositivo
51
2
El sistema comprueba si el usuario tiene una sesión
activa.
3
El sistema pregunta al usuario qué tipo de dispositivo
desea añadir (tanque o camión)
4
El usuario elige el tipo de dispositivo
5
El sistema crea el dispositivo, lo conecta a la nube y
comienza su simulación.
6
7
Normal
Postcondición
excepciones
En el punto 1, el usuario puede hacer clic sobre uno de los
dispositivos en la barra de herramientas y arrastrar hasta la
vista principal para añadir el dispositivo.
Si el usuario no tiene una sesión activa, se mostrará un
mensaje preguntando si desea crear una nueva sesión. En caso
afirmativo, se pasa al caso de uso Crear Sesión.
Comentarios
Caso de uso
Crear sesión
Descripción
El sistema creará una nueva sesión con los datos del usuario.
Actor
Usuario
Precondición
Secuencia
Paso
Acción
1
El usuario pulsa el botón de crear sesión.
2
El usuario introduce el nombre de la sesión que va a
crear.
3
4
El sistema crea la nueva sesión.
Normal
Postcondición
La sesión del usuario ha sido creada.
52
excepciones
Comentarios
Caso de uso
Cargar sesión
Descripción
El sistema cargará la sesión del usuario previamente guardada
para trabajar con ella.
Actor
Usuario
Precondición
El usuario ha guardado previamente una sesión.
Secuencia
Paso
Acción
1
El usuario pulsa el botón de cargar sesión.
2
El sistema muestra al usuario las sesiones guardadas.
3
El usuario elige la sesión que desea cargar.
4
5
Si el usuario logueado es el mismo que el usuario de
la sesión que desea cargar, ésta se carga.
6
El sistema conecta todos los dispositivos de esa
sesión a la nube y continúa con su simulación.
Normal
Postcondición
La sesión del usuario ha sido cargada para poder trabajar con
ella.
excepciones
Si el usuario logueado es distinto al de la sesión que se desea
cargar, se muestra un mensaje advirtiéndolo y se pregunta al
usuario si desea loguearse con la otra cuenta. En caso
afirmativo, se pasa el caso de uso LogIn.
Comentarios
53
Caso de uso
LogIn
Descripción
El usuario se autentifica con sus credenciales del Cloud.
Actor
Usuario
Precondición
Secuencia
Paso
Acción
1
El usuario introduce su nombre, contraseña y servidor
al que se quiere conectar (USA o UK).
2
El sistema se conecta con el servidor y comprueba las
credenciales del usuario.
3
Si todo es correcto, el usuario se ha autentificado.
Normal
Postcondición
El usuario queda autentificado con sus credenciales.
excepciones
Si las credenciales del usuario no son correctas, el sistema
informará al usuario con un mensaje de error y volverá a pedir
que introduzca los datos.
Comentarios
Caso de uso
Programar evento
Descripción
El sistema programa un evento determinado para uno o varios
dispositivos.
Actor
Usuario
Precondición
Secuencia
Paso
Acción
1
El usuario pulsa el botón programar evento.
2
El sistema muestra un formulario con los datos del
evento.
3
El usuario introduce el tipo de evento y la fecha.
4
El evento queda programado.
Normal
54
Postcondición
El evento queda programado y se ejecutará en la fecha
determinada.
excepciones
Si llegado el momento de ejecución del evento, la aplicación
no está funcionando, el evento no se llevará a cabo.
Comentarios
Hay eventos que son específicos de un determinado tipo de
dispositivo. Por ejemplo, un camión no puede tener un evento
de apertura/cierre de válvulas. Por ello, si se seleccionan
dispositivos de diferente tipo sólo estarán disponibles los
eventos comunes a ellos.
Caso de uso
Ver detalles
Descripción
El sistema muestra los detalles de uno o varios dispositivos.
Actor
Usuario
Precondición
Secuencia
Paso
Acción
1
El usuario selecciona uno o varios dispositivos.
2
El usuario pulsa en el botón Ver detalles.
3
El sistema abre una nueva pestaña para cada uno de
los dispositivos. En estas pestañas se muestran los
detalles y el estado de cada dispositivo.
Normal
Postcondición
El sistema ha mostrado los detalles de uno o varios
dispositivos.
excepciones
También se puede acceder a la vista de detalles de un
dispositivo haciendo doble clic sobre él. De esta forma, no es
necesario que el usuario realice los pasos 1 y 2.
Comentarios
55
Caso de uso
Configurar dispositivo
Descripción
El usuario modifica o visualiza aspectos de configuración del
dispositivo.
Actor
Usuario
Precondición
El usuario ha seleccionado un dispositivo.
Secuencia
Paso
Acción
1
El usuario pulsa el botón de configuración de
dispositivo.
2
El sistema muestra un formulario con la información
de configuración.
3
El usuario modifica los parámetros que desee y pulsa
en el botón Aceptar.
4
El sistema actualiza los parámetros modificados del
dispositivo.
Normal
Postcondición
La configuración del dispositivo ha sido actualizada.
excepciones
Si el usuario pulsa en el botón Cancelar, los cambios realizados
no quedarán guardados.
Comentarios
La información mostrada en el formulario de configuración
depende del tipo de dispositivo que se esté configurando.
56
Caso de uso
Ver documentación
Descripción
El usuario visualiza la documentación del sistema.
Actor
Usuario
Precondición
Secuencia
Paso
Acción
1
El usuario pulsa el botón de Ver documentación.
2
El sistema muestra la documentación al usuario.
Normal
Postcondición
La documentación del sistema ha sido mostrada.
excepciones
Comentarios
La documentación del sistema será un documento HTML a
través del cual el usuario podrá navegar.
Caso de uso
Cambiar a vista mosaico
Descripción
La vista de la sesión pasa a visualizarse en forma de mosaico.
Actor
Usuario.
Precondición
La sesión activa se está mostrando en vista de tabla.
Secuencia
Paso
Acción
1
El usuario pulsa el botón de Vista de mosaico.
2
El sistema muestra el estado de la sesión en forma de
mosaico.
Normal
Postcondición
La sesión se ha mostrado en forma de mosaico.
excepciones
Si la sesión ya se estaba mostrando en forma de mosaico, el
sistema no hace nada.
Comentarios
57
Caso de uso
Cambiar a vista tabla
Descripción
La vista de la sesión pasa a visualizarse en forma de tabla.
Actor
Usuario
Precondición
La sesión activa se está mostrando en vista de mosaico.
Secuencia
Paso
Acción
1
El usuario pulsa el botón de Vista de tabla.
2
El sistema muestra el estado de la sesión en forma de
tabla.
Normal
Postcondición
La sesión se ha mostrado en forma de tabla.
excepciones
Si la sesión ya se estaba mostrando en forma de tabla, el
Comentarios
Caso de uso
Copiar dispositivo/s
Descripción
El/los dispositivos seleccionados se copian.
Actor
Usuario
Precondición
Secuencia
Paso
Acción
1
El usuario pulsa el botón de Copiar dispositivo.
2
El sistema copia esos dispositivos.
Normal
Postcondición
El/los dispositivos han sido copiados.
excepciones
Si el usuario no ha seleccionado ningún dispositivo, el sistema
no hace nada.
Comentarios
Entendemos por copiar dispositivo que el sistema guarda en
memoria volátil una copia de dicho dispositivo para su
posterior uso.
58
Caso de uso
Cortar dispositivo/s
Descripción
El/los dispositivos seleccionados se cortan.
Actor
Usuario
Precondición
Secuencia
Paso
Acción
1
El usuario pulsa el botón de Cortar dispositivo.
2
El sistema corta esos dispositivos.
Normal
Postcondición
El/los dispositivos han sido cortados.
excepciones
Si el usuario no ha seleccionado ningún dispositivo, el sistema
no hace nada.
Comentarios
Entendemos por cortar dispositivo que el sistema guarda en
memoria volátil una copia de dicho dispositivo para su
posterior uso y además elimina el dispositivo original.
Caso de uso
Pegar dispositivo/s
Descripción
El/los dispositivos seleccionados se pegan.
Actor
Usuario
Precondición
El usuario ha copiado o cortado previamente uno o varios
dispositivos.
Secuencia
Paso
Acción
1
El usuario pulsa el botón de Pegar dispositivo.
2
El sistema pega esos dispositivos en la sesión de
activa del usuario.
3
Normal
Postcondición
El/los dispositivos han sido pegados.
excepciones
Si no hay ningún dispositivo cortado o copiado previamente, el
59
Comentarios
Entendemos por pegar dispositivo que el sistema añade a la
sesión el/los dispositivos que se habían copiado o cortado
previamente.
Caso de uso
Conectar/Desconectar dispositivo/s
Descripción
El/los dispositivos seleccionados se conectan o desconectan
de la nube.
Actor
Usuario
Precondición
Secuencia
Paso
Acción
1
El usuario pulsa el botón de Conectar/desconectar
dispositivo.
2
El sistema comprueba si los dispositivos
seleccionados están conectados. Si es así, los
desconecta. En caso contrario, los conecta.
Normal
Postcondición
El/los dispositivos han sido conectados o desconectados.
excepciones
Si no hay ningún dispositivo seleccionado previamente, el
Comentarios
Cuando un dispositivo se desconecta, deja de enviar datos a la
nube pero su simulación sigue funcionando.
Caso de uso
Abrir/Cerrar válvula
Descripción
La válvula del tanque cambia su estado.
Actor
Usuario
Precondición
El usuario está en la vista de detalles de un tanque.
Secuencia
Paso
1
Acción
El usuario pulsa sobre una de las válvulas del tanque.
60
2
Normal
Postcondición
El sistema cambia el estado de la válvula y modifica la
simulación en consecuencia.
La válvula del tanque ha cambiado de estado.
excepciones
Comentarios
Si la válvula de entrada del tanque está abierta, la simulación
irá llenando el tanque.
Si la válvula de salida está abierta, la simulación ira vaciando el
tanque.
Si ambas válvulas están abiertas, la simulación irá vaciando el
tanque de forma más lenta.
Caso de uso
Parar/Arrancar camión
Descripción
El camión pasa de estar parado a estar en movimiento o al
revés.
Actor
Usuario
Precondición
El usuario está en la vista de detalles de un camión.
La puerta del camión está cerrada.
Secuencia
Normal
Paso
Acción
1
El usuario pulsa sobre el botón de parar/arrancar
camión.
2
El sistema comprueba si el camión está parado. Si es
así, la simulación hace que se ponga en movimiento.
En caso contrario, lo detiene.
Postcondición
El camión ha pasado de estar parado a estar en movimiento o
al revés.
excepciones
Si la puerta del camión está abierta, el sistema mostrará un
mensaje de alerta ya que no se puede arrancar el camión con
la puerta abierta.
Comentarios
61
Caso de uso
Abrir/Cerrar puerta camión
Descripción
La puerta del camión cambia su estado pasando de abierta a
cerrada o al revés.
Actor
Usuario
Precondición
El usuario está en la vista de detalles de un camión.
El camión está detenido.
Secuencia
Paso
Acción
1
El usuario pulsa sobre el botón de parar/arrancar
camión.
2
El sistema comprueba si el camión está parado. Si es
así, la simulación hace que se ponga en movimiento.
En caso contrario, lo detiene.
Normal
Postcondición
El camión ha pasado de estar parado a estar en movimiento o
al revés.
excepciones
Si el camión está en movimiento, el sistema mostrará un
mensaje de aviso ya que la puerta no se puede abrir si el
camión no está parado.
Comentarios
62
Anexo 2. Casos de test
Test
Case
ID
Group
Test Name
Commands / Description
Result
Create session
Try to create a new empty session with
wrong credentials of the Etherios Device
Cloud Verify that the application does not
allow it Create the session with the correct
credentials
Passed
Session
Save/load session
Create a new session Add a device Save
the session Close the session and load it
again Verify that all data have been loaded
properly
Passed
Session
Load another
session
Load a session Try to load another session
Verify that the application does not allow it
Close the session and create the new
session
Passed
Session
Close and save
session
Create a session and add a new device
Save the session Add a new device Close
the session without saving it Load the
session again and verify that the last device
has been deleted
Passed
Session
Create a session with a tank and a truck
Save the session Modify the state of the
tank and the truck (valves, temperature,
Save devices state speed, gate state, etc) Close the application
Open the application and load the session
Verify that the state of those devices has
been updated
Passed
6
Session
Remove session
Load a session with several devices
Remove the session Verify that the session
has been deleted in the local computer and
in the Device Cloud
Passed
7
Devices
Add a tank
Add a tank in a session Check the device in
the Cloud and in the web application
Passed
8
Devices
Add a truck
Add a truck in a session Check the device in
the Cloud and in the web application
Passed
Devices
Remove multiple
devices
Add several devices in a session and verifiy
that they have been created Select all the
devices and remove them Verify that the
devices have been removed
Passed
Devices
Copy/paste
multiple devices
device
Create 3 devices Copy and paste the
devices Verify that the new devices have
been created with the exact same data than
the original ones (except for the name and
the Device ID)
Passed
1
2
3
4
5
9
10
Session
Jira ID
63
Comments
11
Devices
Cut/paste multiple
device
Create 3 devices Cut and paste the devices
Verify that the new devices have been
created with the exact same data than the
original ones (except for the name and the
Device ID) and those have been removed
12
Data &
Connecti
on
Data sending
Create a tank and a truck Verify that the all
the data have been sent to the Cloud Verify
that the data is shown in the web application
Passed
Modify tank data
Create a tank Modify the state of the valves
and verify that those data (valves state,
level, and volume) are updated in the Cloud
and in the web application Modify the
temperature and verify that those data are
updated in the Cloud and in the web
application
Passed
Create a truck Modify the gate state and
verify that data are updated in the Cloud and
in the web application Modify the
temperature and verify that those data are
updated in the Cloud and in the web
application Modify the speed and verify that
data are updated in the Cloud and in the
web application Modify the route start and
destination and verify that data are updated
in the Cloud and in the web application
Passed
13
Data &
Connecti
on
Failed
14
Data &
Connecti
on
Modify truck data
15
Data &
Connecti
on
Create a tank Disconnect it and verify that it
has been disconnected Modify data of the
Connect/disconnec
tank Connect the tank again and verify that
t a tank
the data generated while it was
disconnected have been sent succesfully
Passed
16
Data &
Connecti
on
Create a tank Disconnect it and verify that it
has been disconnected Modify data of the
Connect/disconnec
tank Connect the tank again and verify that
t a truck
the data generated while it was
disconnected have been sent succesfully
Passed
17
Data &
Connecti
on
Create a tank and a truck Disconnect both
devices Save the session Close the session
Load the session and verify that those
devices are still disconnected
Passed
18
Requests Tank requests
Create a tank Send several requests to
open/close the valves from the web app
Send several requests to change the
Passed
Save state
Device ID
not
received
from
provisionin
g. We have
decided to
remove the
cut
functionalit
y.
64
temperature Verify that the behavior is the
correct Send requests to update the
firmware version Verify that the firmware has
been updated Send a request to disconnect
the tank Verify that the tank has been
disconnected Connect the tank again Send
a request to view the device's log
19
Requests Truck requests
Create a truck Send several requests to
change the temperature Verify that the
behavior is the correct Send requests to
update the firmware version Verify that the
firmware has been updated Send a request
to disconnect the truck Verify that the truck
has been disconnected Connect the truck
again Send a request to view the device's
log
20
Simulatio
Truck simulation
n
Create a truck Let the truck simulation
during a week
21
Simulatio
Tank Simulation
n
Create a tank Let the tank simulation during
a few days
22
Device
Configur
ation
Configure device
Create a device Select it and open the
configuration window Change the
configuration parameters Verify that the
behaviour of the device is correct Change
the description and the contact information
Verify that those data have been updated
23
Events
Tank temperature
events
Create a tank Select it and choose the "Add
event" option in the main menu Add a
temperature event Save and close the
Passed
There is a
memory
leak with
the Google
Maps
View. This
is due to
the fact
that
Google
Maps does
not release
memory,
so the
memory
keeps
growing
until the
application
stops.
Failed
Passed
Partially
Passed
Passed
The
description
and the
email are
changed in
the
application
but the
cloud does
not update
them
65
session Open the session Wait until the hour
of the event Verify that the temperature
starts changing
24
25
26
27
Events
Events
Events
Session
files
Tank valves
events
Create a tank Select it and choose the "Add
event" option in the main menu Add a valves
event Save and close the session Open the
session Wait until the hour of the event
Verify that the level starts changing
Passed
Truck temperature
events
Create a truck Select it and choose the "Add
event" option in the main menu Add a
temperature event Save and close the
session Open the session Wait until the hour
of the event Verify that the temperature
starts changing
Passed
Truck speed
events
Create a truck Select it and choose the "Add
event" option in the main menu Add a speed
event Save and close the session Open the
session Wait until the hour of the event
Verify that the speed changes
Passed
Notifications file
Create a session Verify that a notifications
file has been created in the Cloud (sessions
folder) Add several devices to the session
Verify that the notifications file is updated
Remove a device Verify that the notifications
file is updated Save the session Close the
session Verify that the notifications file has
been removed from the Cloud
Passed
session file
Create a session Verify that an empty file
has been created in the Cloud with the same
name than the session. Add a device to the
session Verify that the file session contains
the device ID of the new device Save the
session and close the application Verify that
the file is still there Load the session again
Remove the device and verify that the file
session is empty now Remove the session
Verify that the file has been deleted
Passed
Passed
Passed
28
Session
files
29
More
Devices
More Devices
Create a session with a free account Add
five devices to that session Try to add
another one Verify that the app does not
allow it
30
Devices
Table View
Create a session Add several devices Verify
that the table view keeps updated Remove
66
several devices Verify that the table view
keeps updated
31
SO
SO Test
Run the application in Linux, Windows and
MacOS
The app
does not
work in
Linux. This
is due to a
bug in the
cloud
connector
library.
Partially
passed
67

Desktop Application for Device Cloud Explorer

Transcripción

Documentos relacionados

ANTONIO CARLOS ROYO BARCENAS (1.970) Es Administrador de

listing voies terradets.txt - Bloc-notes

MORNING SESSION 12th Sept. 11.45 Miguel Ángel Melgares. Artist