u jaÉn escuela politÉcnica superior (jaÉn)...

Escu

ela

Polit

écn

ica S

up

eri

or

de J

aé

n

UNIVERSIDAD DE JAÉN ESCUELA POLITÉCNICA SUPERIOR (JAÉN)

Trabajo Fin de Grado

ESTUDIO Y DISEÑO DE UN PROTOTIPO DE APLICACIÓN MÓVIL

HÍBRIDA PARA SEGUIMIENTO Y CONTROL DE DISPOSITIVOS CON TECNOLOGÍA BLUETOOTH LOW

ENERGY

Alumno: David Jiménez Ibáñez Tutor: Prof. D. José Ramón Balsas Almagro Dpto: Departamento de Informática

Septiembre, 2016

Universidad de Jaén

Escuela Politécnica Superior de Jaén

Departamento de Informática

Don JOSÉ RAMÓN BALSAS ALMAGRO, tutor del Trabajo de Fin de Grado titulado:

ESTUDIO Y DISEÑO DE UN PROTOTIPO DE APLICACIÓN MÓVIL HÍBRIDA PARA

SEGUIMIENTO Y CONTROL DE DISPOSITIVOS CON TECNOLOGÍA

BLUETOOTH LOW ENERGY, que presenta DAVID JIMÉNEZ IBÁÑEZ, autoriza su

presentación para defensa y evaluación en la Escuela Politécnica Superior de Jaén.

Jaén, SEPTIEMBRE de 2016

El alumno: El tutor:

DAVID JIMÉNEZ IBÁÑEZ D. JOSÉ RAMÓN BALSAS ALMAGRO

David Jiménez Ibáñez Estudio y diseño de un prototipo de aplicación móvil híbrida para seguimiento y control de dispositivos con tecnología BLE

2 Escuela Politécnica Superior de Jaén

Índice Tabla de ilustraciones ........................................................................................................... 4

1.Introducción ........................................................................................................................ 7

1.1 Propósito ................................................................................................................. 7

1.2 Motivación ............................................................................................................... 8

1.3 Objetivos ................................................................................................................. 9

1.4 Metodologías..........................................................................................................10

1.3.1 Metodologías Tradicionales vs Metodologías Ágiles .............................................10

1.3.2 SCRUM ................................................................................................................13

1.5 Estructura del documento ......................................................................................15

2. Análisis .............................................................................................................................18

2.1 Análisis preliminar ..................................................................................................19

2.1.1 Aplicaciones móviles multiplataforma ...................................................................19

2.1.2 Protocolo de comunicación Bluetooth 4.0 .............................................................23

2.1.3 Estado del arte .....................................................................................................28

2.2 Propuesta de solución ................................................................................................31

2.3 Requisitos del sistema ................................................................................................32

2.4 Historias de usuario ....................................................................................................34

2.5 Planificación de tareas ................................................................................................36

2.5.1 Planificación de Sprints ........................................................................................38

2.6 Estudio de viabilidad ...................................................................................................42

2.7 Modelo de dominio ......................................................................................................44

3.Diseño ...............................................................................................................................46

3.1 Diagrama de la base de datos ....................................................................................46

3.2 Diagrama de clases ....................................................................................................48

3.3 Diagramas de secuencia .............................................................................................56

3.3.1 Registro ................................................................................................................56

3.3.2 Login ....................................................................................................................57

3.3.3 Modificación Perfil ................................................................................................58

3.3.4 Conexión ..............................................................................................................59

3.3.5 Ver datos aplicación web ......................................................................................60

3.3 Diseño de la interfaz ...................................................................................................61

4.Implementación .................................................................................................................72



4.1 Arquitectura ................................................................................................................72

4.2 Detalles sobre implementación ...................................................................................74

4.2.1 Apache Cordova y AngularJS ...............................................................................75

4.2.2 Ionic Framework ...................................................................................................80

4.2.3 FIirebase ..............................................................................................................82

4.2.4 EVOthings ............................................................................................................86

4.2.5 Bootstrap ..............................................................................................................91

5. Conclusiones ....................................................................................................................94

5.1 Mejoras y trabajos futuros ...........................................................................................95

6. Bibliografía .......................................................................................................................97

APÉNDICE I: Manual de instalación del sistema ..................................................................99

APÉNDICE II: Manual de usuario ....................................................................................... 100

APÉNDICE III: Descripción de contenidos suministrados ................................................... 108



Tabla de ilustraciones

Ilustración 1 - SmartBand Pulse Ox. Fuente: www.withings.com ........................................... 7

Ilustración 2 - Fases en metodologías tradicionales. Fuente: www.rendoro.com ..................10

Ilustración 3 - Fases en metodologías ágiles. Fuente: www.rendoro.com.............................11

Ilustración 4 - Ciclo de desarrollo ágil. Fuente: www.grupo1u6.blogspot.com .......................12

Ilustración 5 - Ciclo de trabajo de SCRUM. Fuente: Apuntes asignatura "Desarrollo Ágil" ....13

Ilustración 6 - Logo Bluetooth 4.0. Fuente: www.secureidnews.com ....................................18

Ilustración 7 - Aplicaciones Híbridas. Fuente: www.deideaaapp.org .....................................18

Ilustración 8 - Tipos de aplicaciones móviles. Fuente: http://blog.aplicacionesmovil.com/ ....20

Ilustración 9 - Posibilidades de cada tipo de aplicación móvil. Fuente:

http://blog.aplicacionesmovil.com/ ........................................................................................22

Ilustración 10 - Resumen operacional de aplicaciones móviles. Fuente:

http://blog.aplicacionesmovil.com/ ........................................................................................22

Ilustración 11: Perfil de atributos genérico GATT Bluetooth 4.0. Fuente: www.bluetooth.com

.............................................................................................................................................26

Ilustración 12 - Componentes de una característica en Bluetooth 4.0. Fuente:

www.safaribooksonline.com/ ................................................................................................27

Ilustración 13 - Aplicación Smartband. Fuente: Google Play ................................................28

Ilustración 14 - Página de inicio aplicación Smartband. Fuente: Google Play .......................29

Ilustración 15 - Página de estadísticas aplicación Smartband. Fuente: Google Play ............29

Ilustración 16 - Pantalla estadísticas aplicación Sony Lifelog ...............................................30

Ilustración 17 - Pantalla inicial aplicación Sony Lifelog. Fuente: Google Play .......................30

Ilustración 18 - Gráfico Burn Down .......................................................................................41

Ilustración 19 - Gastos herramientas software ......................................................................42

Ilustración 20 - Gastos dispositivos hardware .......................................................................42

Ilustración 21 - Gastos de personal ......................................................................................43

Ilustración 22 - Costes totales del proyecto ..........................................................................43

Ilustración 23 - Modelo de dominio .......................................................................................44

Ilustración 24 - Esquema/Resumen de la base de datos ......................................................46

Ilustración 25: Diagrama de base de datos Firebase ............................................................47

Ilustración 26: Diagrama de base de datos con Firebase .....................................................47

Ilustración 27 - Two Way Data Binding en AngularJS. Fuente: www. docs.angularjs.org .....48

Ilustración 28 - Diagramas de Secuencia: Registro ..............................................................56

Ilustración 29 - Diagramas de Secuencia: Login ...................................................................57

Ilustración 30 - Diagramas de Secuencia: Modificar datos usuario .......................................58

Ilustración 31 - Diagramas de Secuencia: Conexión a pulsera .............................................59

Ilustración 32 - Diagramas de Secuencia: Ver datos personales (Web) ...............................60

Ilustración 33 - Características UI. Fuente: www.ida.cl .........................................................61

Ilustración 34 - Herramienta de prototipado Mockflow: www.mockflow.com .........................62

Ilustración 35 - Interfaz 1: Login ...........................................................................................63

Ilustración 36 - Interfaz 2: Perfil ............................................................................................64

Ilustración 37 - Interfaz 3: Menú lateral .................................................................................65

Ilustración 38 - Interfaz 4: Conexión .....................................................................................66



Ilustración 39 - Interfaz 5: Calendario ...................................................................................67

Ilustración 40 - Interfaz 6: Estadísticas .................................................................................68

Ilustración 41 - Interfaz 7: Actividad .....................................................................................69

Ilustración 42 - Interfaz 8: Pantalla Principal (Aplicación Web) .............................................70

Ilustración 43 - Interfaz 9: Pantalla de Estadísticas (Aplicación Web) ...................................71

Ilustración 44 - Arquitectura en capas ..................................................................................72

Ilustración 45 - Resumen de Arquitectura .............................................................................73

Ilustración 46 - Angular JS. Fuente: www.angularjs.org........................................................75

Ilustración 47 - Arquitectura de AngularJS. Fuente propia ....................................................76

Ilustración 48 - Módulo principal de la aplicación. .................................................................76

Ilustración 49 - AngularJS Router Provider ...........................................................................77

Ilustración 50 - Controlador en AngularJS ............................................................................78

Ilustración 51 - Ng-app AngularJS ........................................................................................78

Ilustración 52 - Declaración de un objeto $scope .................................................................79

Ilustración 53 - Uso de objetos $scope .................................................................................79

Ilustración 54 - Llamada a función AngularJS .......................................................................79

Ilustración 55 - Resumen AngularJS ....................................................................................79

Ilustración 56 - Ionic Framework. Fuente: www.ionicframework.com ....................................81

Ilustración 57 - Creando un proyecto Ionic ...........................................................................81

Ilustración 58 - AngularJS y Firebase. Fuente: www.firebase.com .......................................82

Ilustración 59 - Inyección de dependencias de Firebase y AngularFire ................................83

Ilustración 60 - Inyección en el módulo de AngularJS ..........................................................83

Ilustración 61 - URL de Firebase global ................................................................................83

Ilustración 62 - Login con Firebase .......................................................................................84

Ilustración 64 - URL de referencia Firebase .........................................................................85

Ilustración 63 - Estructura en página de Firebase. ................................................................85

Ilustración 65 - Sincronización de datos con Firebase ..........................................................85

Ilustración 66 - EVOthings. Fuente: www.evothings.com .....................................................86

Ilustración 67 - Importación de plugin para Cordova. Fuente: www.github.com ....................87

Ilustración 68 - Escaneo de dispositivos BLE con Evothings ................................................88

Ilustración 69 - Conexión a dispositivo BLE ..........................................................................88

Ilustración 70 - Escaneo de Servicios BLE ...........................................................................89

Ilustración 71 - Escaneo de Características BLE .................................................................89

Ilustración 72 - Lectura de Características BLE ....................................................................90

Ilustración 73 - Bootstrap. Fuente: www.bootstrap.com ........................................................91

Ilustración 74 - Sistema de columnas de Bootstrap ..............................................................92

Ilustración 75 - Visionado de la aplicación web en PC ..........................................................93

Ilustración 76 - Visionado de la aplicación web en Smartphone ...........................................93

Ilustración 77 - Pantalla de registro .................................................................................... 100

Ilustración 78 - Pantalla de inicio ........................................................................................ 100

Ilustración 79 - Pantalla principal ........................................................................................ 101

Ilustración 80 - Calendario: Selección de día ...................................................................... 102

Ilustración 81 - Calendario: Pantalla principal ..................................................................... 102

Ilustración 82 - Pantalla estadísticas: Redes sociales......................................................... 103

Ilustración 83 - Pantalla estadísticas .................................................................................. 103

Ilustración 84 - Pantalla de actividad principal .................................................................... 104

Ilustración 85 - Pantalla de comienzo de actividad ............................................................. 104



Ilustración 86 - Pantalla de conexión .................................................................................. 105

Ilustración 87 - Pantalla login aplicación web ..................................................................... 106

Ilustración 88 - Pantalla principal aplicación web ................................................................ 106

Ilustración 89 - Pantalla estadísticas aplicación web .......................................................... 107

Ilustración 90 - Pantalla datos personales aplicación web .................................................. 107



1.Introducción

1.1 Propósito

El propósito de este Trabajo de Fin de Grado es el de analizar, diseñar e

implementar un prototipo de aplicación móvil híbrida para la conexión y seguimiento

de un dispositivo con la tecnología Bluetooth Low Energy (BLE de aquí en adelante)

mediante dicho protocolo de conexión. En este caso, el dispositivo utilizado para el

estudio de la conexión BLE y la implementación del prototipo de la aplicación, ha

sido la pulsera inteligente Pulse OX de la marca Withings.

Con esta aplicación móvil, el usuario podrá hacer un seguimiento de distintos

datos relativos a su actividad, como por ejemplo el pulso cardíaco, número de pasos,

distancia recorrida, elevación ganada y perdida, calorías perdidas, además de otras

opciones de monitorización ofrecidas por la pulsera y que serán comentadas más

adelante. Además, se desarrollará un servicio web a través del cual se recibirán

datos provenientes de la aplicación móvil para su recolección y posterior uso, por

ejemplo, para monitorizaciones en intervalos temporales.

Ilustración 1 - SmartBand Pulse Ox. Fuente: www.withings.com



1.2 Motivación

Es un hecho que la tecnología evoluciona cada vez más rápidamente, y que

esta tecnología es cada vez más accesible a la sociedad. Actualmente, los

dispositivos que más claramente han evolucionado son los dispositivos móviles,

como smartphones, tablets o laptops, que forman parte en la vida diaria de la

mayoría de las personas de nuestra sociedad. La variedad en cuanto a las marcas

fabricantes de estos dispositivos es inmensa y, aunque de forma mucho más

reducida, también hay numerosos sistemas operativos o plataformas que hacen

funcionales a estos dispositivos. Algunos de los principales son Android, iOS,

Windows Phone, Linux... , aunque existen algunos más. Esta pluralidad de sistemas

operativos existentes para dispositivos móviles obligan a los desarrolladores a crear

una aplicación para cada uno de estos OS, o a dejar de lado alguno de ellos.

Es por esto que las aplicaciones móviles híbridas multiplataforma, que se

basan en programación web, tienen una gran ventaja sobre estas, ya que solo se

necesita un desarrollo para elaborar una aplicación y esta será instalable en

cualquiera de las principales plataformas. De ahí que se decida para este proyecto

obtener el conocimiento necesario para poder desarrollar una aplicación de este tipo.

Por otra parte, conocemos que la tecnología avanza también con dispositivos

que pretenden ser una ayuda en nuestro día a día, y que cada vez nos llevan en

mayor medida a vivir en un "mundo inteligente". Este conjunto de dispositivos que de

alguna forma interactúan con nosotros y con nuestro entorno forman parte de lo que

conocemos hoy en día como el "Internet de las cosas". El desarrollo de aplicaciones

que interactúan con estos dispositivos es, por tanto, claramente creciente en estos

últimos años, por lo que parecía interesante que nuestra aplicación estuviese

relacionada con este ámbito.

Gracias a que la Universidad de Jaén y, más concretamente, el Centro de

Estudios Avanzados en Tecnologías de la Información y de la Comunicación

(CEATIC) posee un centro de inteligencia ambiental, pudimos tener acceso a la

pulsera inteligente que mostramos en el anterior apartado. De esta forma, se decidió

hacer una aplicación con la que pudiéramos obtener datos que esta pulsera

almacenaba, todo esto mediante el uso de la tecnología Bluetooth 4.0, uno de los

protocolos de comunicación que más utilizan los dispositivos inteligentes que nos

rodean.

Por supuesto, destacar un agradecimiento al Centro de Estudios Avanzados

en Tecnologías de la Información y de la Comunicación por posibilitarnos el acceso

a este dispositivo.



1.3 Objetivos

Para desarrollar con éxito este Trabajo de Fin de Grado, nos planteamos los

siguientes objetivos:

-Realizar un estudio de la tecnología BLE: Estudiar y comprender en qué

consiste esta nueva tecnología de comunicación entre dispositivos, así como de los

distintos protocolos de conexión existentes, utilizando el conocimiento adquirido en

el análisis y diseño de nuestra posterior aplicación.

-Estudio de tecnologías para el desarrollo de aplicaciones móviles

híbridas multiplataforma: Estudiar las distintas metodologías y/o frameworks

existentes para la elaboración de aplicaciones móviles híbridas, y elegir aquellas que

mejor se ajusten a nuestro propósito. Será con estas tecnologías con las que

comenzaremos la implementación de la aplicación.

-Elaboración de un prototipo de aplicación móvil híbrida basada en

HTML5 que permita el control de un periférico BLE: En este apartado llevaremos

a cabo, con las tecnologías elegidas del apartado anterior, un prototipo funcional de

aplicación móvil híbrida para llevar a cabo conexiones entre esta y un dispositivo con

la tecnología BLE, en este caso nuestra pulsera inteligente.

-Estudio e implementación de un servicio web remoto: Estudio de las

tecnologías de backend acordes a nuestro frontend para elaborar un servicio web

que utilice un API REST, el cual se encargue de recibir y recopilar datos

provenientes de nuestra aplicación móvil.

-Realizar una memoria con la documentación completa de cada una de

las fases de elaboración de este proyecto: análisis, diseño e implementación.

Mediante la correcta realización y seguimiento de estos objetivos, el trabajo

cumplirá todos los requisitos que debe cubrir en un principio. A lo largo de esta

memoria se intentará reflejar de la mejor manera posible todo el trabajo desarrollado,

de forma que se facilite su comprensión.



1.4 Metodologías

Para definir una estructura, un plan y una manera de controlar todo el proceso

de desarrollo tanto de este proyecto como de cualquier otro, hemos de valorar,

comparar y seleccionar alguna de las muchas metodologías existentes en nuestro

campo. La metodología será elegida según su filosofía de desarrollo, así como por

las distintas herramientas, modelos y métodos que ofrezcan como parte de dicho

proceso de desarrollo. Según todo esto, se seleccionará aquella metodología que

más se ajuste a nuestro objetivo de trabajo.

En un primer momento, al tener que buscar una metodología, la primera

cuestión a la que nos enfrentamos es, “¿Una metodología clásica, o una ágil?” .Es

decir, tendremos que decantarnos por un estereotipo de desarrollo tradicional, o por

un enfoque más moderno, un desarrollo ágil. Cada una tiene sus ventajas e

inconvenientes, siendo ambas, en términos generales, válidas para planificar y

administrar todos los recursos de los que disponemos en nuestro proyecto de la

manera más adecuada. A continuación, estudiamos las diferencias entre estos dos

tipos de metodologías para de esta forma, seleccionar la que mejor se adapte a

nuestro proyecto.

1.3.1 Metodologías Tradicionales vs Metodologías Ágiles

Las metodologías tradicionales [1] inciden en planificar detalladamente todo

el trabajo a realizar antes de iniciar el desarrollo del producto. Una vez que toda esta

planificación está correctamente documentada, se comienza con el ciclo de

desarrollo del producto, centrándose principalmente en el control del proceso. Estas

metodologías por tanto, son metodologías de desarrollo en cascada en las que

podemos destacar cinco procesos fundamentales: Planificación, análisis, diseño,

implementación y pruebas.

Ilustración 2 - Fases en metodologías tradicionales. Fuente: www.rendoro.com



Se dice que la metodología es "en cascada" porque las distintas fases de

desarrollo son abordadas en orden y sin solapamientos temporales entre ellas. Este

modelo de desarrollo, es un modelo totalmente estático e incremental, no iterativo.

Este tipo de metodologías no admitirá grandes cambios una vez que el proceso de

desarrollo ha comenzado, y si lo admite será echando por tierra mucho de lo

avanzado y volviendo casi a la primera fase.

No obstante, las metodologías clásicas pueden ser muy útiles para el

desarrollo de sistemas sencillos, cuyos requisitos, funcionalidades y arquitecturas

estén suficientemente claros desde el principio, y en definitiva, en proyectos simples

y estáticos, con pocas decisiones que tomar sobre él una vez que comienza su

desarrollo.

Por otro lado, y tratando de ofrecer otro enfoque a estas metodologías

tradicionales, surgieron las metodologías ágiles [2] como una respuesta a la

necesidad de obtener mayor flexibilidad en los desarrollos de sistemas de software,

tratando de simplificar las prácticas y fases de desarrollo, y tratando también de

asegurar la mayor calidad posible del producto. Estas metodologías se centran en

aportar un paradigma de organización y estructuración que permitan a los equipos

crear software rápidamente y responder eficazmente a los cambios surgidos a lo

largo del proyecto.

Las metodologías ágiles, a diferencia de las tradicionales, son iterativas, por

lo que cada fase del desarrollo se llevará a cabo más de una vez a lo largo de la

elaboración del proyecto. Estas iteraciones serán continuadas en el tiempo, lo que

permite que la arquitectura del software vaya siendo definida y mejorada a lo largo

del proyecto, y siempre en contacto con el cliente.

Ilustración 3 - Fases en metodologías ágiles. Fuente: www.rendoro.com



Como bien podemos concluir, este tipo de metodologías deben ser utilizadas

en proyectos más ambiciosos que los antes mencionados para utilizar metodologías

tradicionales, ya que de esta forma se admitirán cambios en cualquier momento que

mejoren el proyecto, consiguiendo así resultados finales muy optimizados y, con la

ayuda y consulta constante del cliente, cumpliendo sus objetivos de manera

completa y eficiente.

Teniendo en cuenta todo esto, y debido a las características del proyecto a

realizar, optamos por seguir una metodología ágil, ya que desde el inicio del

proyecto nos encontramos con múltiples alternativas respecto a distintas

tecnologías, frameworks, y desarrollos de complejidad suficiente como para preveer

que durante el proceso tengamos que realizar múltiples cambios. Además, el

desarrollo iterativo nos ayudará a conseguir una aplicación más robusta y

consistente y mejores resultados finales.

La metodología ágil elegida será SCRUM [3], dado que es una de las más

extendidas y conocidas, pudiendo por tanto encontrar fácilmente más

documentación y ejemplos prácticos. Además, su modus operandi nos facilitará

Ilustración 4 - Ciclo de desarrollo ágil. Fuente: www.grupo1u6.blogspot.com



mucho las labores de desarrollo fomentando principalmente una buena

organización del trabajo. Tampoco podemos obviar que para este proyecto se

elaborarán varios desarrollos simultáneos (Aplicación móvil y servicio web) por lo

que el método iterativo que propone SCRUM nos será muy interesante para no

perdernos en el proceso. Por último, destacar también que como desarrollador,

estoy más familiarizado con esta metodología ya que se trabajó en profundidad

durante los años de mi periodo formativo y, por tanto, la elección de esta reducirá el

tiempo necesario para el desarrollo del proyecto.

1.3.2 SCRUM

SCRUM es un proceso ágil que tiene como objetivo que el desarrollador se

centre en obtener el más alto valor de negocio en el menor tiempo posible,

inspeccionando rápida y repetidamente el trabajo de desarrollo [4]. Al comienzo, se

fijan las prioridades de cada proceso y cada cierto tiempo (normalmente 2/4

semanas) se puede ver el software funcionando y decidir si liberarlo o seguir

mejorándolo.

A continuación vemos una imagen referente al ciclo de trabajo que se utiliza

en SCRUM:

En el ciclo de trabajo de SCRUM, podemos diferenciar los distintos

componentes:

-Sprint: Iteración de trabajo, normalmente entre 2-4 semanas de duración.

Ilustración 5 - Ciclo de trabajo de SCRUM. Fuente: Apuntes asignatura "Desarrollo Ágil"



-Product Backlog: Requisitos de nuestro proyecto capturados como

elementos de una lista y ordenados según su prioridad de entrega. Por cada

requisito se crea un bloque de trabajo, llamado Historia de usuario.

-Sprint Backlog: Grupo de historias de usuario (Subconjunto del Product

Backlog) con el que se trabaja durante una iteración o sprint.

-Daily Scrum Meeting: Reunión diaria de SCRUM para comprobar lo que se

hizo el anterior día, lo que se debe hacer en el día actual, y lo posibles obstáculos

que pueda haber para ello. Son reuniones cortas, de unos 15 minutos, en los que se

adquieren esos compromisos entre los trabajadores.

Durante un sprint o iteración, se llevará a cabo un proceso secuencial, en el

que se acometerán tareas de análisis, diseño e implementación de las historias de

usuarios recogidas en el sprint backlog.

Por otro lado, SCRUM nos presenta distintos roles y responsabilidades:

-Product Owner: Responsable del producto. Sus funciones principales son

las de definir las funcionalidades del producto, decidir fechas y contenidos de las

entregas, priorizar funcionalidades y aceptar o rechazar los resultados del trabajo.

-Scrum Máster: Responsable del funcionamiento de SCRUM.

-Team: Responsables de desarrollo y ha de ser multifuncional y auto-

organizado.

Dentro del marco de trabajo de SCRUM, también se nos presenta la

necesidad de hacer diferentes reuniones durante el proceso de desarrollo:

-Sprint planning: Se seleccionan las historias de usuario a partir del Product

Backlog que se considere que se podrán completar, y de esta forma se crea el Sprint

Backlog. Una vez hecho esto, se identificarán las diferentes tareas y cada una será

estimada en horas. Esta reunión se hará antes de cada iteración.

-Daily Scrum Meeting: Reunión diaria de SCRUM.

-Sprint Review: Se presenta lo realizado durante el sprint mediante una

demo que presente dicha funcionalidad.

-Sprint retrospective: Periódicamente, se echa un vistazo a lo que funciona

y lo que no, y esto se realiza tras los distintos sprints. Una vez analizados los

posibles problemas de funcionamiento, se decide lo que se va a comenzar a hacer,

seguir haciendo o dejar de hacer en la siguiente iteración.

Como sabemos, este proyecto va a ser desarrollado individualmente. Es por

esto que el modelo de SCRUM necesita una adaptación a nuestro caso. Partimos de



que todos los roles corresponderán a la misma persona, que se encargará de

responsabilizarse del funcionamiento de SCRUM, de definir las funcionalidades del

producto, estructurar sus fases de desarrollo y, por último, del desarrollo en sí,

adquiriendo el rol de analista y de programador al mismo tiempo. Por otro lado, las

reuniones de equipo carecerán de sentido y no serán necesarias como tal, aunque si

es interesante llevar a cabo un seguimiento continuo del proceso de desarrollo, que

a grandes rasgos es el objetivo de estas reuniones.

Conociendo a fondo este tipo de metodología, se procederá a ponerla en

práctica, comenzando a estructurar y organizar nuestro proyecto en cuestión. Todo

esto se expone en el apartado dos de esta memoria, correspondiente al análisis de

la aplicación. Cabe mencionar que, aunque hablaremos siempre de las distintas

iteraciones, y se especificará cuando estamos hablando de cada una, esta memoria

se estructura en apartados que más corresponderían con un modelo clásico que con

una metodología ágil. No obstante, esto es así para conseguir una mayor

condensación de cada punto del desarrollo, y una mayor facilidad para el lector de

comprender el desarrollo de cada una de las partes.

Relacionado con esto último, y para una mayor facilidad aún, en el siguiente

apartado se expone la estructura que tendrá esta memoria detalladamente.

1.5 Estructura del documento

Este documento se encuentra dividido en seis bloques principales que pasaré a

comentar a continuación:

La primera parte del documento corresponderá a las tablas de contenido del

mismo, tanto de apartados como de imágenes o tablas, lo que permitirá encontrar de

una forma rápida y sencilla cualquier parte de la memoria en concreto.

Tras este capítulo introductorio en el que se ha expuesto cual es la problemática

a la que nos enfrentamos y cuáles son nuestros objetivos, llegaremos al segundo

apartado de nuestra memoria.

En ese segundo apartado, llamado “Análisis”, haremos una división de ocho

fundamentales puntos en este aspecto, que son:



-Análisis preliminar: Se describirá el contexto de aplicación del que se parte,

comentando sus características principales, su historia, las tecnologías

principales…etc. Además se expondrán otras soluciones similares ya existentes del

mismo tipo y ámbito que nuestra aplicación a desarrollar, analizándose las ventajas

y desventajas que estas poseen. Además, y bastante importante en este caso, se

estudiarán las distintas tecnologías y frameworks que se utilizarán para resolver el

problema, si bien no centrándome en cómo se trabajará con el framework sino

analizando las propuestas tecnológicas de estos y el por qué nos serán de gran

utilidad en el proyecto.

-Propuesta de solución: En este apartado se planteará una propuesta de

solución para el trabajo, una visión general de las metodologías fusionadas con los

distintos frameworks y las distintas tecnologías que se emplearan en el proyecto.

Esta propuesta será inicial, pudiendo verse afectada por algún tipo de cambio, pero

sin duda es una primera respuesta a la pregunta de ¿Cómo lo voy a desarrollar?

-Requisitos del sistema: Se listarán y justificarán los distintos requisitos

funcionales y restricciones que se espera que contemple el desarrollo, que más

adelante serán explicados con detalle en el apartado de “Historias de usuario”. Así

mismo, también se expondrán los distintos requisitos no funcionales que vengan

impuestos por el contexto de la aplicación o por la petición del cliente. De igual

forma, estos últimos no serán explicados con detalle, pues esto se hará en el

apartado de “Implementación".

-Historias de usuario: En este punto se detallarán todos los requisitos

funcionales convertidos ahora en historias de usuario con el mayor detalle posible,

historias de usuario que se esperan alcanzar durante el desarrollo.

-Planificación inicial de tareas: En este apartado descompondremos las

distintas historias de usuario en tareas, y se especificará una propuesta inicial del

ciclo de SCRUM, detallando iteraciones necesarias, tareas que se llevarán a cabo

en dichas iteraciones y roles que participarán en cada una de ellas. A partir de este

apartado tendremos una estimación inicial del tiempo de desarrollo necesario para

finalizar el proyecto.

-Estudio de viabilidad: En este apartado se hará un análisis de costes de

desarrollo y explotación, así como la justificación del modelo de negocio.

-Modelo de dominio: Descripción de las distintas entidades, atributos y

relaciones existentes en el proyecto.



Ya en el apartado tres, titulado “Diseño”, se verán todos los componentes

relacionados con el diseño de nuestro proyecto y se elaborarán diagramas de las

principales funcionalidades del sistema, destacando un diagrama de la base de

datos, diagramas de clases y diagramas de secuencia. También mostraremos

prototipos de la interfaz.

En el apartado cuatro nos centraremos en la “Implementación” de la

aplicación/es. Veremos el diagrama arquitectónico de la aplicación/es junto a los

elementos que las forman. Además, se detallarán aspectos de la implementación y

del uso de los distintos frameworks y tecnologías utilizadas en el proyecto.

Ya finalizando esta memoria, en el punto cinco veremos las distintas

conclusiones a las que llegamos tras finalizar el desarrollo del proyecto, haciendo

una retrospectiva y analizando qué falta por mejorar y que faltaría por añadir en un

futuro al sistema implementado.

El punto seis recogerá la bibliografía referenciada a lo largo de todo el

documento y, por supuesto, la utilizada para el desarrollo del proyecto.

Para finalizar, la memoria incluirá una serie de anexos, donde se podrá

consultar un manual de usuario de instalación y uso del sistema desarrollado.



2. Análisis

Enfrentarnos al desarrollo de este proyecto suponía previamente analizar

varios aspectos que serían de gran relevancia para el mismo. Para comenzar a

plasmar la parte de análisis del proyecto, expondremos una introducción sobre el

mundo de las aplicaciones móviles híbridas o multiplataforma donde aclararemos

por qué desde el comienzo seleccionamos este tipo de tecnología para nuestra

implementación. También, y como no podía ser de otra forma, se hará un repaso a

cerca de la tecnología de comunicación Bluetooth 4.0 1 también conocida como

Bluetooth Low Energy (BLE). En este repaso especificaremos las necesidades que

se nos plantean, las posibilidades que este protocolo de comunicación nos ofrece y

el estudio de APIs que nos serán de gran ayuda para la utilización de esta

tecnología. Esta primera aproximación nos permitirá analizar brevemente las

necesidades en cuanto a funcionamiento que debería plasmar nuestra aplicación.

Por otro lado, estudiaremos distintas aplicaciones existentes en el mercado

actual similares a la que se va a implementar, y analizaremos sus puntos fuertes y

débiles, de manera que con ese estudio consigamos encontrar la mejor solución

posible a nuestro problema en cuestión. Partiendo de esta propuesta de solución

más detallada, se expondrán tanto las distintas historias de usuario como los

requisitos que conformarán el contenido de nuestro desarrollo. Por último, se

mostrará la planificación de tareas a seguir, de manera que podamos realizar una

estimación de tiempo de desarrollo de nuestro trabajo.

1 https://www.bluetooth.com

Ilustración 7 - Aplicaciones Híbridas. Fuente: www.deideaaapp.org

Ilustración 6 - Logo Bluetooth 4.0. Fuente: www.secureidnews.com



2.1 Análisis preliminar

2.1.1 Aplicaciones móviles multiplataforma

Desde un primer momento, el problema a solucionar y desarrollar era el

estudio de la comunicación entre periféricos y dispositivos móviles mediante el

protocolo de comunicación BLE, por lo que una cosa era evidente, tendríamos que

desarrollar una aplicación móvil. En ocasiones, es el desarrollador quien selecciona

una plataforma móvil (o varias) para desarrollar la aplicación. No obstante, podría

ser el cliente el que le especifica la plataforma o plataformas para la que desea

obtener la aplicación móvil. Si la elección por parte del cliente es la de la elaboración

de la aplicación para una única plataforma, el único problema relevante es que el

desarrollador posea los conocimientos necesarios para poder llevar a cabo el

trabajo. Aunque hay que señalar que en el caso de plataformas como iOS, otro

problema es que el desarrollador posea o tenga acceso al material hardware

necesario para poder hacer este trabajo.

Desafortunadamente, estos problemas se acrecentan si el cliente elige varias

plataformas para las que desarrollar la aplicación, lo que por consiguiente creará

mucho más trabajo al desarrollador. Esto en algunas ocasiones será decisivo a la

hora de afrontar el proyecto o por el contrario descartarlo. No obstante, hay que

destacar que para algunos desarrolladores, esto más que un problema es una buena

oportunidad de negocio y, en caso de que su carga de trabajo no sea elevada,

podrán aprovechar la oportunidad. También en el caso de la mayoría de las

empresas, estos problemas pueden pasar desapercibidos, ya que suelen tener a

distintos expertos en cada plataforma, y la carga de trabajo se dividiría sin problema.

Sin embargo, para equipos pequeños de desarrolladores o incluso

individuales, así como para empresas que quieran agilizar su proceso de trabajo

(amén de otras ventajas que consideren como oportunidades), existen otras

opciones de desarrollo, destacando las aplicaciones móviles multiplataforma,

también conocidas como híbridas.

Desde hace varios años, existe un enfrentamiento entre los partidarios de las

aplicaciones nativas (propias de cada plataforma) y los de las aplicaciones web que

simplemente se acceden a través de los navegadores del dispositivo móvil.

Enfrentamiento que realmente no tendría por qué existir, pues ambos métodos

pueden ser válidos según el tipo de aplicación. No obstante, a partir de ambas

formas de desarrollo nace la



idea de aplicaciones móviles híbridas [5]. Estas aplicaciones no son más que

aplicaciones web que en lugar de descargarse en un navegador desde un servidor

remoto, se incrustan en un contenedor creado nativamente por la plataforma a la

que pertenezca el dispositivo móvil, consiguiendo así que estas aplicaciones tengan

el acceso facilitado a diferentes recursos del propio sistema, como pueden ser los

sensores, cámara, almacenamiento, plugins internos, etc. Hacer esto con una

aplicación web que se abra simplemente en un navegador no siempre es posible o

igual de fácil que si nuestra aplicación es híbrida.

A continuación, se muestra una imagen resumen de los tres principales tipos

de aplicaciones móviles comentadas anteriormente y se detallarán las opciones,

ventajas e inconvenientes de cada una más específicamente:

Las aplicaciones nativas tienen la ventaja de que pueden acceder a todos los

recursos, software y hardware, y a funcionalidades del sistema, aumentando así

claramente su rendimiento y posibilidades. Además, el hecho de estar programadas

con un lenguaje propio del sistema y del dispositivo en cuestión puede hacer que la

usabilidad y la experiencia del usuario con la aplicación sea mejor que en el caso de

otras aplicaciones. Así, podemos afirmar con certeza que, en términos de

rendimiento y usabilidad, lo ideal es tener una misma aplicación desarrollada

específicamente para cada plataforma, pero eso genera unos costes

Ilustración 8 - Tipos de aplicaciones móviles. Fuente: http://blog.aplicacionesmovil.com/



añadidos importantes.

Las aplicaciones web móviles, como hemos mencionado anteriormente, son

las aplicaciones accesibles desde los navegadores de las distintas plataformas

mediante una URL y que se adaptan al tamaño de la pantalla del dispositivo para

que tenga aspecto de una verdadera aplicación móvil. Se desarrollan con lenguajes

sobradamente conocidos y actuales como HTML5, CSS o JavaScript. Estas

aplicaciones pueden ser una buena solución si ya se posee una aplicación web

accesible desde navegadores en equipos, ya que solo habría que modificar esta

aplicación para dotarla de una estructura del estilo de aplicaciones móviles que sea

mucho más fácil e intuitiva de utilizar que la aplicación web inicial. Una buena forma

de conseguir esto es utilizar técnicas que permitan “Responsive Design” [6], que

dota a una aplicación web de recursos para que esta se adapte dinámicamente al

dispositivo desde el que se visualiza.

Sin embargo, implementaciones o aumentos de código relacionados con este

tipo de diseño, puede hacer que aumente la carga de estas aplicaciones y que

comiencen a ralentizarse, por lo que el tiempo de respuesta elevado de la web nos

llevará a una mala experiencia de usuario, lo que puede suponer una gran

desventaja de este tipo de aplicaciones. Otra desventaja es lo limitado que tienen el

acceso a recursos hardware en los dispositivos, así como que los usuarios no

podrán encontrarlas en las principales tiendas de aplicaciones o “stores” de las

distintas plataformas, que es donde la inmensa mayoría busca sus APPs.

Por último, y como ya introducimos anteriormente, hay una tercera opción que

intenta recoger lo mejor de cada uno de los dos tipos anteriores de desarrollo de

aplicaciones móviles: las aplicaciones híbridas. Estas aplicaciones son aplicaciones

web, elaboradas en su núcleo también con lenguajes como HTML5, CSS o

JavaScript, normalmente utilizados bajo algún framework de desarrollo para este tipo

de aplicaciones. Estas aplicaciones deberán ser procesadas por un empaquetador o

wrapper para la plataforma específica que se desee, generando una aplicación

interpretable por cada plataforma y utilizable en los distintos markets. Este tipo de

aplicaciones tendrá acceso a recursos internos propios del dispositivo, dependiendo

el nivel de acceso a estos de lo abierta que sea cada plataforma con el framework

de desarrollo seleccionado. Pese a esto, cada vez el acceso a los recursos de los

dispositivos es más amplio, por lo que la experiencia con este tipo de aplicaciones

cada vez se acerca más a las aplicaciones nativas.

En las siguientes imágenes podemos ver de una forma resumida las

funcionalidades, ventajas y desventajas que cada tipo de aplicación tiene:



Ilustración 10 - Resumen operacional de aplicaciones móviles. Fuente: http://blog.aplicacionesmovil.com/

Ilustración 9 - Posibilidades de cada tipo de aplicación móvil. Fuente: http://blog.aplicacionesmovil.com/



Tras este repaso sobre las distintas posibilidades para el desarrollo de

aplicaciones móvil, es el turno de elegir la que mejor se adapte a nuestro problema.

En principio se requería una aplicación funcional en distintas plataformas móviles,

como pueden ser Android, iOS o Windows Phone. Además, necesitamos tener

acceso a alguno de los recursos de los dispositivos, como es la conexión Bluetooth.

Esto es clave para descartar una de las opciones de desarrollo, las aplicaciones

web, ya que nos dificultaría tener control de este recurso, vital para nuestras futuras

conexiones con periféricos. Elaborar tantas aplicaciones como dispositivos donde

queremos que esta funcione era realmente inviable, ya que el proceso de

aprendizaje iba a tener que ser realmente extenso, lo cual no es posible puesto que

contamos con un tiempo y un equipo limitado al disponer solo de un único

desarrollador.

Por tanto, dados estos últimos datos y puesto que nuestra aplicación no

necesitará acceso a recursos del dispositivo (en un primer momento) más allá de

utilizar la conexión mediante Bluetooth (al que una aplicación híbrida puede

acceder), se decide que la mejor opción es decantarse por la implementación de una

aplicación híbrida/multiplataforma, que nos permita un único desarrollo que después

será completamente funcional para cada una de las distintas plataformas y que,

además, se podrá comercializar en las diferentes tiendas o “stores” existentes en el

mercado de aplicaciones.

2.1.2 Protocolo de comunicación Bluetooth 4.0

Desde el comienzo nos enfrentamos a un problema que solucionar y estudiar,

la conexión de nuestra aplicación con periféricos mediante el protocolo de

comunicación Bluetooth 4.0 [7]. Así que, realmente, ¿En qué se basa esta

tecnología?

La tecnología Bluetooth define un protocolo y un estándar global de

comunicación inalámbrica que hace posible la transmisión de datos entre diferentes

dispositivos mediante un enlace por radiofrecuencia, consiguiendo así facilitar las

sincronizaciones directas de datos entre dispositivos personales y eliminando el

cableado y conectores entre estos. Para que dos dispositivos que poseen este

protocolo de comunicación puedan conectarse entre sí, tendrán que estar dentro de

un alcance determinado.

A lo largo de los años la tecnología Bluetooth ha tenido diversas

especificaciones y versiones, que han sido diseñadas para la retro-compatibilidad,

es decir, cada nueva versión permite cubrir y mejorar en su caso a todas las

versiones anteriores. A continuación haremos un breve repaso a las distintas



versiones que se abrieron paso hasta llegar a la de nuestro interés, la versión

del protocolo Bluetooth 4.0.

Bluetooth v1.0 y v1.0B

Estas eran las primeras versiones llevadas a cabo para los primeros

emisores/receptores de Bluetooth. No es de extrañar por tanto que tuvieran algunos

fallos, como la difícil interactuación entre teléfonos y dispositivos de distintas

compañías y sobre todo un problema mayor, en cada transmisión de datos la

dirección del dispositivo Bluetooth se enviaba, por lo que se perdía por completo el

anonimato de este tipo de conexión.

Bluetooth v1.1

Se corrigieron los principales errores de las versiones 1.0, se añadieron

soporte para los canales no cifrados así como el indicador RSSI que nos indica la

potencia con la que una señal es recibida.

Bluetooth v1.2

Esta versión mejoró la velocidad de conexión y transferencia de datos, añadió

la opción de Discovery, que permitiría escanear dispositivos Bluetooth cercanos.

Además por primera vez era compatible con usb, en este caso usb v1.1.

Bluetooth v2.0 + EDR

Con esta versión se le daba la opción a los fabricantes de dispositivos de

incorporar la EDR (“Enhanced Data Rate”), un sistema de transmisión de datos a

mayor velocidad. Esta velocidad era como máximo de 3Mb/s aunque su tasa real

máxima era de 2,1 Mb/s.

Bluetooth v2.1 + EDR

Esta nueva versión supuso un gran cambio en cuanto a la seguridad se

refiere, ya que por primera vez los datos eran filtrados. Además, mejoró

notablemente el consumo de energía.

Bluetooth v3.0

Este nuevo modelo tuvo ya una notable mejora en cuanto a la velocidad de

transmisión de datos, llegando hasta los 24Mb/s. Además fue añadida una nueva

característica que hacía uso del WIFI para el envío de paquetes de datos de gran

tamaño.



Bluetooth v4.0 - Bluetooth Low Energy

Esta versión es la más reciente actualmente, y fue lanzada en el año 2010. Se

basa en la combinación de la tecnología Bluetooth clásica con la conexión vía WIFI.

De esta forma, se dota a los dispositivos que lo incluyen de una velocidad de

transferencia y velocidad de emisión de hasta 32 Mb/s. Además, esta versión incluye

la importante mejora denominada Bluetooth Low Energy. Esta mejora es muy

importante, ya que hasta hace pocos años si muchos de los distintos dispositivos

electrónicos y periféricos no tenían incorporada la tecnología Bluetooth era en parte

por el consumo que este producía. Además, esta versión también ha mejorado la

comunicación entre dispositivos de diferentes marcas y ampliando el alcance de

conexión, por lo que el hecho de que el aumento de dispositivos que utilizan la

tecnología fue y es una realidad. Por otro lado, y no menos importante, la seguridad

en esta versión está asegurada, con un cifrado de datos completo.

Un aspecto a tener en cuenta de los dispositivos que funcionan con esta

versión es que estos pueden recoger información constantemente o bien elegir

cuándo sincronizar dicha información (lo más normal). Tanto para una opción como

para otra, el consumo claramente reducido de energía hace que la interactividad e

interoperabilidad entre dispositivos que funcionan de forma constante o por largos

periodos de tiempo crezca en nuestros días de forma constante. Esta tecnología

forma parte en gran medida de la IoT ("Internet of Things").

La versión 4.0 tiene un tercer nombre con el que puede ser referida, Bluetooth

Smart (Bluetooth Inteligente) [6]. Esta inteligencia se refiere a la facilidad que existe

para incluir esta tecnología en el desarrollo de aplicaciones móviles y/o para la

conexión con la computación en la nube.

Esta facilidad de desarrollo existe debido en gran parte a la existencia de un

perfil genérico para todos los dispositivos que poseen esta especificación de

Bluetooth en cuanto a la arquitectura y estructura de los datos que la forman. Esto

se conoce como "Generic Attribute Profile" (GATT) [8]. Este estándar o perfil único

de organización interna que existe en los dispositivos que contienen esta tecnología

define y establece como interactuar y obtener datos de un dispositivo BLE, así como

los procedimientos para ello y el formato en que estos datos serán recibidos. Por

tanto para el desarrollo de nuestra aplicación habrá que tener muy claro en qué

consiste este perfil genérico de datos de los dispositivos que poseen esta tecnología,

ya que solo conociendo este esquema arquitectónico interno podremos obtener el

conocimiento necesario para más tarde poder establecer una conexión y poder leer

datos de uno de estos dispositivos.

A continuación se muestra una imagen donde podemos ver el esquema

principal de este perfil de atributos genérico GATT:



Cada dispositivo Bluetooth 4.0 está formado por distintos servicios. Cada uno

de estos servicios están compuestos por distintas características o por referencias a

otros servicios. Las características contienen un tipo (representado por un UUID), un

valor, un conjunto de propiedades indicando las operaciones que esta característica

soporta (lectura, escritura o notificación) y también puede contener permisos.

Además pueden contener uno o varios descriptores que dan información sobre la

configuración. Estas características son las que, de poder leerlas, nos permitirán

tener acceso a los datos finales de monitorización de un dispositivo. Podemos ver

con más detalle los componentes de una característica en la siguiente imagen:

Ilustración 11: Perfil de atributos genérico GATT Bluetooth 4.0. Fuente: www.bluetooth.com



Así como existe este perfil genérico de organización de atributos, existen un

conjunto de servicios y características ya definidos con toda la información necesaria

para poder acceder a la información y datos de estos para la mayoría de dispositivos

BLE. Estos servicios ya definidos están relacionados con cualquier tipo de

monitorización que los dispositivos inteligentes llevan a cabo mediante sus distintos

sensores. Por ejemplo podemos encontrar servicios que se refieren a la

temperatura, a la medida de pulsaciones, contadores de velocidad, de distancia, de

pasos... Todos estos servicios ya predefinidos, los podemos encontrar en la página

oficial del protocolo Bluetooth:

https://www.bluetooth.com/specifications/gatt/services

Como hemos dicho, esta especificación existente pretende facilitar el

desarrollo en gran medida de aplicaciones móviles que utilicen el protocolo de

comunicación Bluetooth 4.0, y por tanto existen soportes y APIs para dicha causa en

la mayoría de plataformas móviles existentes como pueden ser Android o iOS.

Sin embargo, en nuestro caso la aplicación será una aplicación web móvil

híbrida, por lo que estas APIs no nos serán de mayor utilidad que instructiva. Por

tanto, era objetivo encontrar una API de desarrollo con Bluetooth 4.0 para

programación web.

Ilustración 12 - Componentes de una característica en Bluetooth 4.0. Fuente: www.safaribooksonline.com/

https://www.bluetooth.com/specifications/gatt/services



Tras realizar un estudio y búsqueda sobre esto mismo, se encontró una API

para desarrollo de aplicaciones BLE nos dota de un plugin escrito en lenguaje

JavaScript, totalmente adecuado para nuestra programación web. Esta API es

desarrollada por el equipo de EVOthings2, que desarrolla distintas APIs que facilitan

el desarrollo móvil utilizando diversas tecnologías que forman parte de la IoT

("Internet of things") o "Internet de las cosas". Además, esta API funciona con el

empaquetador de aplicaciones híbridas Apache Cordova, que será el que

utilizaremos para compilar nuestra aplicación para su uso en dispositivos móviles.

Hablaremos tanto de esto último como de la API en sí misma, en el apartado cuatro

de la presente documentación, sección en la que se exponen este y otros detalles de

implementación.

2.1.3 Estado del arte

A continuación vamos a estudiar algunas aplicaciones ya existentes en el

mercado similares a la aplicación que se pretende desarrollar. En este caso serán

dos las aplicaciones a estudiar.

2.1.3.1 SmartBand (Wristband)

Esta es una aplicación destinada a la

monitorización de actividad de un usuario a través

de la pulsera inteligente Wristband. Con ella, se

pueden conocer todos los datos que almacena la

pulsera mediante una sincronización con la

aplicación. Además existe acceso a numerosos

gráficos estadísticos de actividad, y se guardan los

datos de días ya pasados. A continuación pasamos

a estudiar algunas ventajas e inconvenientes

encontrados en la aplicación.

Ventajas

- Muy completa en cuanto a monitorización de múltiples datos de actividad.

- Acceso a calendario para revisar el historial de actividad.

2 www.evothings.com

Ilustración 13 - Aplicación Smartband. Fuente: Google Play



- Informes semanales con gráficos de rendimiento.

Inconvenientes:

- Aplicación muy poco intuitiva.

- Imposibilidad de registro de usuarios.

- Difícil acceso a determinadas funciones.

- Ajustes complejos.

2.1.3.1 SWR10 SmartBand

En este caso estudiamos la aplicación

oficial de Sony para su smartband SWR10.

Esta contiene funciones de registro de actividad

para poder realizar un seguimiento exhaustivo a

partir de esta pulsera. Mencionamos a

continuación algunas de las ventajas e

inconvenientes que hemos detectado.

Ilustración 14 - Página de inicio aplicación Smartband. Fuente: Google Play

Ilustración 15 - Página de estadísticas aplicación Smartband. Fuente: Google Play



Ventajas

- Completa monitorización de todos los datos de actividad.

-Posibilidad de acceder a numerosas estadísticas.

- Posibilidad de registros de usuarios.

- Propuesta de objetivos de actividad.

- Acceso a calendario para revisar el historial de actividad.

- Informes semanales, diarios y mensuales con gráficos de rendimiento.

Inconvenientes

- Puede ser compleja de utilizar.

- Optimizada para SmartPhones Sony.

- No se puede iniciar un registro de actividad durante un rango de tiempo.

Ilustración 17 - Pantalla inicial aplicación Sony Lifelog. Fuente: Google Play

Ilustración 16 - Pantalla estadísticas aplicación Sony Lifelog



2.2 Propuesta de solución

Una vez realizado un primer análisis sobre las necesidades a las que nos

enfrentamos y conocer hacia dónde queremos llegar, comenzamos a ver el proceso

bastante más claro. El desarrollo se centrará en la elaboración de un prototipo de

una aplicación web móvil híbrida, instalable y completamente funcional en la mayoría

de plataformas móviles teniendo que realizar un único código e implementación para

ello. Este prototipo marcará el camino a seguir para la finalización de una aplicación

con todas las funcionalidades elaboradas, ya que dispondrá de las principales

funciones de la aplicación de cara al usuario. De esta manera, el cliente podrá tener

una experiencia completa de usuario antes de que el desarrollo se complete.

Como ya adelantamos en el primer apartado de esta memoria, para la

realización de este proyecto y su correcta organización, así como para sacarle el

máximo partido al tiempo con el que contamos, seguiremos una metodología ágil

como es SCRUM. Como se ha comentado, se ajusta muy bien al manejo de distintas

actividades simultáneas manteniendo siempre un soporte de ayuda necesario si en

algún momento encontramos algún problema en la solución y hay que hacer un

cambio de una o varias especificaciones concretas. Consideramos vital esa

capacidad de adaptación que conseguimos con SCRUM con la que nos

aseguramos siempre de que un posible cambio no suponga una vuelta atrás que no

nos podamos permitir en un momento dado.

En referencia al desarrollo de la aplicación web móvil híbrida en sí,

utilizaremos un framework de programación en lenguaje JavaScript altamente

conocido en estos días como es AngularJS3. Este es un framework de desarrollo de

aplicaciones web en el lado del cliente siguiendo el patrón MVC (Modelo-Vista-

Controlador) que nos facilitará en gran parte el trabajo y la organización de nuestro

código. Esta separación del código fuente en tres componentes nos ayudará

también a tener un acoplamiento muy bajo ya que tendremos claramente separado

el código de interfaces y de clases de negocio, lo que facilitará su comprensión y los

posibles cambios que se tengan que añadir en cualquier momento. En el apartado

tres y cuatro detallaremos más características de este framework.

Para conseguir una interfaz vistosa, usable y con una gran diversidad en

cuanto a componentes, se hizo un amplio estudio en cuanto a diversos frameworks

que fuesen compatibles con nuestra idea de desarrollo hasta el momento.

Finalmente encontramos un framework creado para el desarrollo de interfaces

de aplicaciones web móviles híbridas, lo que no solo cumplía con nuestras

necesidades, sino que está optimizada para AngularJS, por lo que era perfecto para

3 https://angularjs.org/



nuestra aplicación. Este framework es Ionic Framework4, gratuito y de código

abierto, que ofrece una librería de componentes para interfaces móvil optimizadas

en HTML, CSS y AngularJS, además de herramientas de desarrollo para conseguir

los mejores resultados en aplicaciones móviles web. De esta forma conseguimos

que la diferencia entre una aplicación de este tipo y una aplicación nativa sea casi

nula. La combinación de Ionic con AngularJS hará que tengamos una interfaz de

usuario elegante e intuitiva para el usuario, además de una arquitectura será

robusta.

2.3 Requisitos del sistema

Los requisitos de un sistema describen los servicios que este sistema ofrecerá

y las restricciones que tendrá asociadas a su funcionamiento. Dentro de los

requisitos de un sistema, se puede distinguir entre [9]:

-Requisitos funcionales: Expresan qué debe hacer el sistema y como éste

interaccionará con su entorno.

-Requisitos no funcionales: Restricciones sobre posibles soluciones para

afrontar el problema.

En base a estos, pasamos a condensar los distintos requisitos que deberá

contener nuestro sistema.

4 http://ionicframework.com/



Requisitos funcionales:

1.Identificación: El usuario debe poder identificarse en el sistema, mediante un

correo personal y contraseña.

2.Modificación de contraseña: El usuario debe poder modificar su contraseña en el

caso de que olvide esta.

3.Añadir datos personales: El usuario debe poder completar sus datos personales

de forma manual desde la aplicación.

4.Modificación de datos personales: El usuario debe poder modificar sus datos

personales en cualquier momento desde la aplicación.

5.Escaneo de dispositivos: El usuario debe poder escanear señales de

dispositivos bluetooth desde la aplicación para así tener acceso a su pulsera

inteligente.

6.Conexión a pulsera: El usuario debe poder conectar su aplicación con la pulsera

inteligente, para que la aplicación pueda comenzar a recibir mensajes de esta.

7.Acceso a datos actuales: El usuario debe poder tener acceso a los datos

actuales (del día) monitorizados de su pulsera inteligente, una vez que estos se

sincronizan mediante la conexión.

8.Acceso a calendario: El usuario debe poder tener acceso a un calendario para

elegir el día sobre el que quiere conocer sus datos monitorizados por la pulsera.

9.Acceso a estadísticas: El usuario debe tener acceso a una sección de

estadísticas sobre sus datos recogidos de la pulsera, donde encuentre gráficos de

actividad y pueda seleccionar la característica de la que quiere ver dichas

estadísticas.

10.Acceso a comienzo de actividad: El usuario debe poder comenzar a monitorear

sus datos de la pulsera en un momento determinado y parar este, para así tener

datos a cerca de su actividad en un rango de tiempo determinado.

11.Página de perfil: El usuario debe tener acceso a una página de perfil donde

encuentre sus datos personales y donde pueda acceder a distintas opciones.

12.Menú: El usuario debe tener acceso a un menú principal dentro de la aplicación a

través del cual pueda acceder a las distintas funcionalidades del sistema.



Requisitos no funcionales:

1.Portabilidad: La aplicación debe poder funcionar correctamente en las principales

plataformas móviles. Especialmente Android y iOS por ser los que tienen una mayor

cuota de mercado.

2.Usabilidad: La aplicación deberá tener una gran facilidad de uso, y ser claramente

intuitiva para el usuario.

3.Confiabilidad: El sistema debe ofrecer un funcionamiento sin fallos con un muy

bajo porcentaje de posibilidad de errores.

4.Flexibilidad: El sistema deberá de ser flexible en cuanto a la facilidad para poder

agregarle nuevas funcionalidades.

2.4 Historias de usuario

Las historias de usuario [10] son una representación de un requisito o

funcionalidad concreta propia de la aplicación que se ha obtenido mediante las

peticiones del usuario o cliente. Han de ser de tamaño pequeño para que se

adecúen al trabajo iterativo, ya que se utilizan en las metodologías ágiles y por tanto

son muy importantes para el desarrollo de SCRUM. Estas historias pueden verse

sometidas a cambios durante el desarrollo del software.

A la hora de definir historias de usuario, estas se identificarán por un número,

un título, una descripción, una prioridad, una estimación y dependencias en el caso

de que existan. A continuación se muestra una tabla detallando las distintas historias

de usuario identificadas para nuestro proyecto.



ID TÍTULO DESCRIPCIÓN PUNTOS ESTIMADOS

PRIORIDAD

1 Aplicación móvil híbrida

Como usuario, quiero que la aplicación sea accesible en distintas plataformas, destacando Android e iOS.

10 Alta

2 Puesta a punto del entorno

Como desarrollador quiero hacer una puesta a punto del entorno para poder comenzar el desarrollo del proyecto.

10 Alta

3 Creación de cuenta Como usuario, quiero poder crearme una cuenta en el sistema con mis credenciales personales.

7 Alta

4 Datos personales Como usuario, quiero poder añadir datos personales a la aplicación que se relacionen con la actividad física, como el peso, estatura o edad.

5 Media

5 Modificación de datos personales

Como usuario, quiero tener acceso a la modificación de mis propios datos personales en cualquier momento.

3 Media

6 Conexión pulsera Como usuario, quiero poder conectar mi aplicación con la pulsera inteligente, mediante Bluetooth.

10 Alta

7 Datos diarios Como usuario, quiero que cuando esté conectado a la pulsera pueda acceder a un apartado donde pueda ver mis datos del día actual monitorizados por la pulsera.

15 Alta

8 Calendario Como usuario, quiero tener acceso a un calendario que me permita seleccionar un día para visualizar mis datos de dicho día.

10 Alta

9 Estadísticas Como usuario, quiero tener acceso a diferentes estadísticas realizadas según mis datos registrados por la pulsera inteligente.

7 Alta

10 Actividad Como usuario, quiero poder comenzar una actividad desde la aplicación en un momento concreto y que cuando esta acabe, poder pararla y que se registren mis datos monitorizados por la pulsera en ese rango de tiempo.

9 Alta

Tabla 1 - Historias de usuario



2.5 Planificación de tareas

Una vez que tenemos establecidas las distintas historias de usuario y los

diversos requisitos que nuestra aplicación debe tener, podemos descomponer esas

historias de usuario en varias tareas que serán necesarias para completar cada una

de las historias. De esta forma ya tendremos una descomposición completa de

nuestro trabajo a realizar, pudiendo asignar tareas a cada miembro del equipo de

SCRUM, en este caso los roles de analista y programador, que debido a ser un

proyecto individual serán la misma persona. Así pues, con toda esta organización

podremos hacer una estimación en el tiempo de cuánto se va a extender la

realización de nuestro proyecto. Esa será una estimación relativa, pues nos

basaremos en los puntos de historia que decidimos asignarle a cada historia de

usuario. Estos puntos de historia reflejan una estimación temporal que se decide dar

a cada tarea de una historia de usuario en función de su complejidad. En nuestro

caso, los puntos de historia se referirán a días de trabajo, por lo que sumando todos

estos días, podremos hacer una estimación temporal completa de la duración del

proyecto. A continuación, mostramos la descomposición en subtareas de cada

historia de usuario mostrada en el punto 2.3 de esta memoria. La estimación total de

cada historia de usuario también se dividirá con estas subtareas.

ID TAREA ESTIMACIÓN (Puntos de historia)

PERSONAL

1 Aplicación móvil híbrida. 10

1.1 Instalación y configuración de Apache Cordova

3 Analista

1.2 Instalación y configuración de Ionic Framework

4 Programador

1.3 Instalación de Node 3 Analista

2 Puesta a punto del entorno. 10

2.1 Instalación y configuración del entorno de desarrollo

2 Programador

2.2 Análisis y diseño de la interfaz de usuario

3 Analista

2.3 Análisis y diseño de la arquitectura de la aplicación

3 Analista

2.4 Análisis y diseño de la base de datos

2 Analista

3 Creación de cuenta. 7

3.1 Análisis y diseño de los requisitos principales relacionados

2 Analista

3.2 Implementación del controlador

3 Programador

3.3 Implementación y 2 Programador



configuración de la vista

4 Datos personales. 5


1 Analista


2 Programador

4.3 Implementación de la vista 2 Programador

5 Modificación datos personales.

3


2 Programador


6 Conexión pulsera. 10


1 Analista

6.2 Análisis y diseño de la documentación de la pulsera inteligente

2 Analista


5 Programador


7 Datos diarios 15


2 Analista

7.2 Análisis y diseño de la documentación de la pulsera inteligente relacionado a manejo de datos

3 Analista


7 Programador


8 Calendario 10


1 Analista


7 Programador


9 Estadísticas 7


1 Analista


4 Programador




10 Actividad 9


2 Analista


6 Programador

10.3 Implementación de la vista 1 Programador Tabla 2 - Descomposición de tareas

En conclusión, nuestro trabajo contará con 86 puntos de historia, separando

estos en 29 puntos de historia a realizar por el Analista y 57 puntos de historia para

el programador.

Como ya adelantamos en el primer apartado de esta memoria, el ciclo de

trabajo de SCRUM se divide en un conjunto de iteraciones o Sprints, que suelen ser

rangos de tiempo normalmente de entre 2-4 semanas de duración. Al final de cada

sprint se obtendrá un software funcional que podrá ser mostrado al cliente para

comprobar si este está conforme con el resultado o si hay que hacer algún cambio

extra. En cada sprint se llevará a cabo un número de tareas específicas que se

diseñarán, implementarán y probarán.

Un sprint tiene una secuencia de trabajo, que conlleva los siguientes puntos y

que nunca podrán ser obviados:

- El cliente ordenará las historias de trabajo según las prioridades que

considere oportunas, y a esto se le llamará "pila de trabajo" ("Product backlog").

- El equipo revisará esta pila de trabajo y seleccionará un conjunto de

historias que llevar a cabo durante el sprint, formando así el "Sprint backlog". El

cliente finalmente debe de estar de acuerdo con este trabajo seleccionado.

- Al terminar un sprint el equipo entregará el resultado de su trabajo. Después,

volverá a seleccionar un siguiente conjunto de historias para realizar en el siguiente

sprint, y así sucesivamente.

En este proyecto el equipo de desarrollo estará formado por una sola persona

(como ya comentamos con anterioridad) y el papel de cliente lo llevará a cabo esa

misma persona junto con el tutor de este trabajo de fin de grado.

2.5.1 Planificación de Sprints

Para nuestro proyecto, la duración de cada sprint será de 3 semanas

naturales, lo que en días de trabajo se reducen a 20 días por sprint. La fecha de

comienzo del trabajo será el 1 de Febrero de 2016. Para hacer una primera

estimación de trabajo que será realizado por sprint, se decide que éstos sean

aproximadamente de entre 10 y 15 puntos de historia cada uno.

Una vez que estos datos están claros, podemos hacer una primera estimación

global del tiempo de duración de nuestro proyecto:



Esta primera estimación nos muestra que serán necesarios 7 sprints de 3

semanas cada uno de trabajo. La fecha de comienzo sería el primer día del mes de

febrero, estimándose que el 26 de junio de este mismo año el proyecto será

finalizado. También podemos ver que cada sprint tiene una velocidad concreta. Esta

velocidad se refiere a la carga de trabajo real que tendrá el proyecto en un día de

trabajo. Este cálculo se obtiene mediante la división de los puntos de historia a

completar en el sprint y los días de trabajo que tendremos para ello. Como vemos, la

carga de trabajo se diversifica en cada sprint, dejando algunos de estos más

holgados en cuanto al tiempo, lo que puede ser una ayuda para el equipo si existe

algún tipo de problema durante la realización de algún sprint. Sin embargo en

determinados sprints se decide que es necesario acabar un número de historias

elevado ya que sus funcionalidades son muy comunes, por lo que será necesario

que el equipo aproveche todo el tiempo de trabajo de sus días en llevar a cabo el

proyecto en estos sprints. Si durante el proyecto no hubiera ningún cambio

importante, se respetaría este calendario si el equipo puede con la carga de trabajo

estimada y si no hay problemas.

Sin embargo sobre la mitad del tiempo del proyecto, más concretamente tras

la finalización del cuarto sprint, se detectó la necesidad de añadir al proyecto la

realización de una aplicación web de consulta para los usuarios, a través de la cual

los usuarios puedan introducir sus credenciales utilizadas para la creación de su

perfil en la aplicación móvil y acceder a sus datos personales. Además en el futuro el

usuario podría ver sus datos monitorizados por la pulsera. Por lo tanto, el trabajo

consistiría en crear una aplicación web que se conecte a la base de datos creada

para la aplicación móvil y que recogiera los datos de cada usuario. Esto supone para

el equipo elaborar nueva/s historia/s de usuario tras analizar la petición y, por tanto,

reestimar la duración del proyecto añadiendo nuevo/s sprint/s.

Nº Sprint

Fecha Inicio

Fecha Fin Días de trabajo

Puntos completados

Velocidad Historias a realizar

1 1-2-2016 22-2-2016 15 10 66% 1

2 23-2-2016 14-3-2016 15 10 66% 2

3 15-3-2016 4-4-2016 15 15 100% 3,4,5

4 5-4-2016 25-4-2016 15 10 66% 6

5 26-4-2016 16-5-2016 15 15 100% 7

6 17-5-2016 6-6-2016 15 10 66% 8

7 7-6-2016 27-6-2016 15 16 106% 9,10 Tabla 3 - Estimación del proyecto



Tras esta petición por parte del cliente y su posterior análisis por el equipo, se

decide incluir una nueva historia de usuario, que mostramos a continuación:

Ésta, a su vez, fue diversificada en distintas tareas:

ID TAREA ESTIMACIÓN (Puntos de historia)

PERSONAL

11 Aplicación móvil híbrida. 15

11.1 Análisis y diseño de los requisitos principales de la aplicación

3 Analista

11.2 Implementación de controladores

7 Programador

11.3 Implementación de vistas 5 Analista Tabla 5 - Descomposición de tareas nueva historia

Por último el equipo estimó nuevamente la duración del proyecto, quedando

finalmente de la siguiente manera:

ID TÍTULO DESCRIPCIÓN PUNTOS ESTIMADOS

PRIORIDAD

11 Aplicación web de consulta

Como usuario, quiero poder acceder a una aplicación web desde distintos dispositivos donde poder tener acceso a mis datos recogidos por la aplicación móvil

15 Alta

Tabla 4 - Nueva historia de usuario

Nº Sprint

Fecha Inicio

Fecha Fin Días de trabajo

Puntos completados

Velocidad Historias a realizar

1 1-2-2016 22-2-2016 15 10 66% 1

2 23-2-2016 14-3-2016 15 10 66% 2

3 15-3-2016 4-4-2016 15 15 100% 3,4,5

4 5-4-2016 25-4-2016 15 10 66% 6

5 26-4-2016 16-5-2016 15 10 66% 11

6 17-5-2016 6-6-2016 15 15 100% 7

7 7-6-2016 27-6-2016 15 10 66% 8

8 28-6-2016 18-7-2016 15 16 106% 9,10 Tabla 6 - Reestimación del proyecto



Como podemos comprobar, el equipo decide llevar a cabo la nueva iteración

justo cuando el cliente lo propone, para después seguir con el conjunto final de

sprints estimados anteriormente. Al añadir un sprint más, el proyecto se verá

retrasado tres semanas respecto a la primera estimación.

Estas estimaciones junto a la visión del proceso de desarrollo del proyecto

basado en sprints y puntos de historias se puede ver resumido en un diagrama burn

down o diagrama de evolución, que indica de forma gráfica el trabajo que aún queda

por hacer en un momento determinado del proyecto.

Ilustración 18 - Gráfico Burn Down

Como podemos observar en el gráfico, el cambio en la iteración 5 hace que el

proyecto se retrase tres semanas sobre la estimación temporal inicial. Sin embargo,

esta inversión de tiempo no ha sido en vano, ya que está justificada para la mejora

de las funcionalidades del sistema en su conjunto.

0

10

20

30

40

50

60

70

80

90

100

0 1 2 3 4 5 6 7 8

Estimación 1

Re-estimación

Nº Sprint

Pu

nto

s d

e h

isto

ria

a c

om

ple

tar



2.6 Estudio de viabilidad

En este punto detallaremos el coste que nos supondrá realizar la aplicación

para el cliente y el desarrollo de nuestro proyecto completo. En él veremos el valor

de las principales herramientas hardware y software necesarias para la puesta en

marcha y finalización del desarrollo y los salarios para los dos puestos laborales

necesitados: el de analista y programador.

A continuación mostramos las herramientas software utilizadas durante el

proyecto, la mayoría como se puede comprobar con licencia gratuita.

Software Precio Duración de uso

Precio ponderado

Paquete Microsoft Office 2007

30€

6 meses

30€

Brackets IO 1.5 Gratuito 6 meses 0€

Genymotion 6.0 Gratuito 6 meses 0€

Visual Paradigm Comunity Edition

Gratuito 6 meses 0€

Chrome Versión 51.0.2704.103

Gratuito 6 meses 0€

Notepad ++ 6.7 Gratuito 6 meses 0€ Ilustración 19 - Gastos herramientas software

Software y hardware a la hora de realizar un proyecto de este estilo van de la

mano. A continuación mostramos las herramientas hardware que han sido

necesarias a lo largo del proyecto:

Hardware Precio Vida estimada Precio ponderado

Asus K55V 700€ 6 años 112€

BQ Aquaris E5 240€ 3 años 73€

Tablet Chuwi Hi8 100€ 4 años 23€ Ilustración 20 - Gastos dispositivos hardware

Los equipos informáticos tienen una vida útil estimada, a partir de la cual se

calcula un precio ponderado en base al tiempo que han sido utilizados para la

realización del proyecto. En este caso los componentes incluidos han sido el

ordenador portátil utilizado para la programación y documentación, un smartphone

de la plataforma android que ha sido el principal dispositivo para pruebas y una

tablet que también ha sido utilizada para diversas pruebas. No se ha incluido el

precio de la pulsera inteligente ya que el equipo no ha afrontado su gasto, sino que

fue cedida temporalmente para el proyecto por el Centro de Estudios Avanzados en

TIC, CEATIC, 5de la Universidad de Jaén.

5 http://ceatic.ujaen.es



Los salarios para cada uno de los trabajadores han sido obtenidos de las

tasas públicas del BOE según el convenio de Telefónica. Para el desarrollo, como

hemos comentado en varias ocasiones, han sido necesarios dos perfiles distintos, el

de analista y el de programador. Para estos se calculará su sueldo en relación a sus

horas para llevar a cabo su trabajo estimado.

Puesto Salario Anual

Salario Mensual

Salario por hora

Días de trabajo

Horas/día Total horas

Precio

Analista 26.088,30€ 2.174,02€ 13,58€ 29 5 145 1969,10€

Programador 20941,34€ 1.745,11€ 10,90€ 57 5 285 3106,50€ Ilustración 21 - Gastos de personal

Para finalizar, mostramos un desglose de los gastos generales así como el

beneficio que obtendremos, normalmente alrededor de un 15% de los gastos.

Costes Precio

Gastos software 30€

Gastos hardware 208€

Gastos personal 5075,6€

Beneficio (15% de gastos totales) 792,52€

TOTAL 6106,14€ Ilustración 22 - Costes totales del proyecto



2.7 Modelo de dominio

Antes de comenzar con el apartado de diseño, es necesario realizar un

"diseño" previo de clases conceptuales que nos haga comenzar a ver la arquitectura

que tendrá nuestro proyecto, de manera que desde aquí se busque una posible

solución al problema. Cabe recordar que seguimos en el apartado de análisis, por lo

que realmente no hablaríamos de diseño exactamente, pero si de una propuesta de

solución. A continuación mostramos nuestro modelo de dominio:

Ilustración 23 - Modelo de dominio



Como podemos ver en nuestro modelo de dominio se comienza a estudiar la

arquitectura interna de un dispositivo con Bluetooth 4.0, como vemos en este caso

con la pulsera. Esta ofrece una serie de servicios y estos a su vez una serie de

características donde se almacenarán los datos. Un usuario tendrá una pulsera que

monitorizará sus datos, por lo que este tendrá acceso a dichos datos a través de la

conexión a la pulsera y la posterior búsqueda de esos datos.



3.Diseño

A continuación, pasamos a la fase de diseño de este proyecto. En esta fase se decide cual es la mejor forma de organización de nuestra aplicación teniendo en cuenta todo lo detallado en cada una de las fases de análisis, siguiendo el modelo iterativo que se lleva a cabo según la metodología de SCRUM.

3.1 Diagrama de la base de datos

Como explicaremos en detalle más adelante, se ha optado por utilizar una

base de datos de tipo NoSQL[9] utilizando la API de Firebase 6, una potente API

para almacenar y sincronizar datos en la nube en tiempo real, tanto en aplicaciones

web como aplicaciones móviles que se conecten a dicho servicio.

A continuación, podemos ver un esquema resumen de la comunicación de

nuestra aplicación con el servicio de Firebase y viceversa, es decir, la recolección de

los datos que se encuentran en esta base de datos:

Ilustración 24 - Esquema/Resumen de la base de datos

Como se puede observar, será la aplicación móvil la encargada de recolectar

los datos de la pulsera vía Bluetooth 4.0, realizándose esta aplicación la llamada al

servicio de Firebase y el envío de datos para su almacenamiento, así como la

6 https://www.firebase.com/



sincronización de estos datos. Al mismo tiempo, esta aplicación móvil hará

una llamada a este servicio de Firebase para obtener dichos datos para el usuario

que corresponda. Por otro lado, la aplicación web también se conectará al mismo

servicio de Firebase para obtener todos los datos referentes al usuario que se

identifique en ella. Esta aplicación solo será de lectura de datos, por lo que no tendrá

necesidad de almacenar ni sincronizar datos con Firebase en una primera versión

del prototipo aunque, en el futuro, podría también permitir el envío y modificación de

información.

A continuación vemos un pequeño diagrama referente al almacenamiento de

datos en este servicio remoto de Firebase:

Como vemos, en este caso tendremos una entidad principal que será la

entidad Usuario, que por sí misma almacenará los datos personales de un usuario

de la aplicación. Además, esta entidad estará directamente relacionada con los

Ilustración 25: Diagrama de base de datos Firebase Ilustración 26: Diagrama de base de datos con Firebase



datos de monitorización correspondientes de la pulsera del usuario, por lo que

también será encargada de almacenar estos datos conforme estos vayan siendo

sincronizados. El servicio de Firebase (nuestra base de datos "no-sql"), será el

encargado de almacenar a su vez esta entidad "Usuario", por lo que la información

de un usuario estará incluida en una única entrada. Los usuarios tendrán un

identificador único, un "userkey" que servirá para el acceso a la aplicación mediante

su correspondiente login. Este userkey será creado una vez que el usuario se

registre en la aplicación.

3.2 Diagrama de clases

Para comprender con claridad la organización del modelo de nuestras

aplicaciones (móvil y web), hay que conocer previamente la arquitectura de las

tecnologías utilizadas, fundamentalmente la del framework de desarrollo AngularJS7.

Con el framework AngularJS lo que realmente tenemos desde el punto de

vista del diseño es un patrón Modelo-Vista-Controlador (MVC) [11], añadiendo la

funcionalidad conocida como “Two-Way Data Binding”, es decir, la actualización

del modelo automáticamente cuando cambia la vista y viceversa, consiguiendo así

una sincronización bidireccional.

7 https://angularjs.org/

Ilustración 27 - Two Way Data Binding en AngularJS. Fuente: www. docs.angularjs.org



Tras conocer que la aplicación seguirá el patrón de Modelo-Vista-Controlador,

se puede identificar el flujo de ejecución básico de nuestra aplicación, que

consistirá en los siguientes pasos:

-El usuario hará una solicitud de acceso a la aplicación móvil o web. Esta

solicitud será recibida por el controlador.

-El controlador recibe esta solicitud o petición por parte del usuario a través de

las vistas, y solicitará información al modelo. También, tras la ejecución del usuario,

el controlador actualizará o modificará este modelo.

-Una vez conseguido esto último, esta nueva información será enviada al

controlador, y de este pasará de nuevo a las vistas correspondientes de la

aplicación.

-Cuando el usuario ve los cambios en las vistas, el flujo se repetirá con

nuevas peticiones del usuario a la aplicación.



A continuación, representamos globalmente el diagrama de clases de diseño

de la aplicación móvil y web:

APLICACIÓN MÓVIL

Una de las ventajas que nos da el framework de desarrollo AngularJS, es que

al usar el patrón MVC contamos con mayores facilidades para nuestro diseño, de

manera que habrá una clara separación de la lógica de negocio y las vistas, lo que

nos permite una clara reusabilidad del modelo, de modo que la misma

implementación de la lógica de negocio que maneja una aplicación puede ser

utilizada en otras aplicaciones, poniendo como ejemplo la aplicación web de control

que también se ha elaborado para este proyecto.

De esta forma, se reducen también los posibles impactos que podrían tener

los cambios en la interfaz de usuario sobre las operaciones internas del software

(desacoplamiento). Con el uso de este patrón conseguiremos un software mucho



más estable, y con un mantenimiento mucho más sencillo, así como una

mayor facilidad para añadirle nuevas funcionalidades sin que otra parte del modelo

se vea afectada.

Como podemos observar en el diagrama, y como hemos comentado en el

apartado anterior de este documento, tendremos tres tipos de elementos principales,

que albergarán a su vez las clases de nuestro proyecto. Estos tres elementos o

contenedores serán:

-Controladores: Presentan las principales funcionalidades de la aplicación y

la comunicación con el modelo de datos.

-Vistas: Interfaces que estarán de cara al usuario, y que se encargarán de

avisar a los controladores sobre las acciones que han de realizar, y al mismo tiempo

se encargarán de actualizarse cuando se den cambios en estos controladores.

-Servicios: Poseen funcionalidades globales que pueden ser utilizadas desde

cualquier controlador.

A continuación pasamos a detallar cada uno de estos elementos por

separado, reconociendo las diferentes clases que los forma.

Empezaremos por las clases de control que contienen la mayoría de los

detalles de funcionamiento de nuestra aplicación:



En nuestra aplicación tendremos un controlador por cada vista, y estos serán

los que le den la funcionalidad necesaria. En este caso, podemos ver los

controladores referentes a las funcionalidades de login de usuario, como el propio

login, el registro y la recuperación de contraseña. También tenemos un controlador

común a todas las vistas, que será la clase menú, que conseguirá que el tipo de

visionado de cada pantalla sea el mismo. Quizás el más importante de estos

controladores sea el controlador de la conexión, a partir del cual encontraremos

todas las funcionalidades para conectarnos a nuestra pulsera inteligente.

A continuación pasamos a ver las clases de las vistas de la aplicación:

Estas serán las principales vistas de la aplicación. En este caso tenemos una

clase encargada del enrutamiento entre vistas, lo que nos permitirá acceder a cada

una de las distintas pantallas con una ruta única por vista. Esta clase que englobará

a las demás es la clase "App".



Por último, tenemos también dos servicios:

Éstos serán los servicios que tienen funcionalidades comunes a varios

módulos de la aplicación, por lo que podrán ser utilizados desde distintos

controladores. Uno de estos servicios, el servicio "Auth", se encargará de toda la

lógica de negocio para la creación de perfiles de usuario. Por otra parte, el servicio

"GUIUtils" nos será de ayuda a la hora de mostrar distintos mensajes en pantalla y

manejar las ventanas emergentes durante la ejecución.

Se dará algún detalle más sobre funcionalidades concretas en el apartado de

implementación de esta memoria (Punto 4).



APLICACIÓN WEB

A continuación, representamos el diagrama de clases de diseño de la aplicación web:

Como podemos comprobar, esta aplicación es bastante más sencilla que la aplicación móvil, aunque sigue la misma estructura ya que también se implementa con AngularJS. La estructura de vistas, controladores y servicios se mantiene intacta. A continuación veremos cada uno de estas entidades por separado con algo más de detalle. Empezaremos con las clases de control:



Como vemos, tenemos tres controladores con funcionalidad. Por una parte

tenemos el controlador de la página de estadísticas, "chart.js", cuya función principal

será la de gestionar todos los gráficos que aparecerán en esta página. También

encontramos el controlador de la página de datos personales "blank.js", en la cual

haremos una conexión a Firebase para obtener los diferentes datos disponibles. Por

último tenemos, al igual que en la aplicación móvil, un controlador que se encarga de

implementar el login de usuario. El controlador vacío pertenece a la página principal

que de momento no tiene añadida ninguna función.

En cuanto a las vistas, tenemos la vista de login, pantalla principal, pantalla de

datos personales y la de estadísticas. Cada una de estas tendrá asignado el

controlador correspondiente de los ya comentados. La clase app, como en la

aplicación móvil, será la encargada del enrutamiento entre vistas.

Por último en esta aplicación contamos con un único servicio, en este caso un

servicio muy similar al que tenemos en la aplicación móvil, el servicio "authfactory",

con las funciones necesarias para llevar a cabo el login de usuario que el propio

controlador de login utilizará.



3.3 Diagramas de secuencia

Una vez analizados los diagramas de clase de las aplicaciones, vamos a

repasar algunos de los diagramas de secuencias que son más representativos de

una manera gráfica cómo interaccionan los distintos objetos del sistema

comprobando su evolución en el tiempo. Esto nos ayudará a comprender el

funcionamiento de los apartados fundamentales de la aplicación.

3.3.1 Registro

Ilustración 28 - Diagramas de Secuencia: Registro



En este primer caso (historia de usuario 3), el usuario entra a la aplicación,

donde se encontrará con la pantalla de login principal, y seleccionará la opción de

registrarse. Tras marcar esa opción, la aplicación le llevará a una nueva página,

donde se le pedirá su e-mail y una contraseña. Una vez rellenados, el formulario

será enviado a la nube, en este caso a la plataforma Firebase, a través de la cual, si

todo es correcto, se creará el usuario. Una vez creado, el usuario ya podrá hacer

login con normalidad y encontrarse con su página de perfil.

3.3.2 Login

Ilustración 29 - Diagramas de Secuencia: Login



Este diagrama (historia de usuario 4) de secuencia nos muestra el proceso de

login del usuario. Una vez que el usuario abre la aplicación, se le mostrará la

pantalla de acceso. En esta habrá un formulario de e-mail y contraseña que deberá

completar. Tras completarlo, la petición se enviará a Firebase, donde se buscarán

los datos de este usuario. En caso de que el formulario esté correctamente

completado, se devolverá el login con éxito al controlador de este acceso y el

usuario entrará en su página de perfil principal, donde podrá modificar y completar

sus datos.

3.3.3 Modificación Perfil

Ilustración 30 - Diagramas de Secuencia: Modificar datos usuario



En este caso (historia de usuario 5), el diagrama nos muestra el proceso a

seguir de un usuario para cambiar sus datos principales para la aplicación. Esta

modificación se podrá hacer desde la página de perfil principal de usuario. Cada vez

que los datos sean modificados estos se guardarán en nuestra base de datos y

automáticamente serán sincronizados.

3.3.4 Conexión

Ilustración 31 - Diagramas de Secuencia: Conexión a pulsera



Este diagrama (historia de usuario 6) nos muestra el proceso de

conexión/sincronización del usuario con su pulsera. El usuario deberá acceder a la

página de conexión de su aplicación, y una vez dentro pulsar en el botón de

sincronizar que encontrará. Esto hará que se active la búsqueda y posterior

conexión y sincronización de la pulsera. Si se produce la conexión, los datos serán

automáticamente sincronizados y guardados en la nube, en nuestra base de datos

de Firebase. En el caso de que la conexión no se haga efectiva, no se podrán

sincronizar estos datos.

3.3.5 Ver datos aplicación web

En este último diagrama (historia de usuario 11) se indica el proceso que hará

un usuario para acceder a sus datos personales dentro de la aplicación web. En este

caso, el usuario se encontrará en la página principal de la aplicación (tras hacer su

login) donde tendrá datos referentes al monitoreo de la pulsera. Una vez en esa

página deberá acceder mediante un apartado a sus datos personales. Esta nueva

página recogerá los datos del usuario almacenados en Firebase, y una vez los

obtenga, estos serán mostrados al usuario en una nueva pantalla. Ya que la

aplicación web es una aplicación de solo lectura, estos datos solo serán modificables

desde la aplicación móvil.

Ilustración 32 - Diagramas de Secuencia: Ver datos personales (Web)



3.3 Diseño de la interfaz

Una de las partes más importantes de un desarrollo de software, y más si

cabe tratándose de una aplicación móvil, es el diseño de la interfaz de usuario. La

calidad de esta interfaz puede ser clave de cara al éxito o fracaso de una aplicación,

sin importar la complejidad de las funcionalidades que trabajen por debajo de esta

capa.

Una buena interfaz de usuario ha de ser funcional, consistente y de fácil

operación, es decir, intuitiva [12]. Solo manteniendo estas principales características,

la aplicación ya será una aplicación usable por parte del usuario. Por el contrario, si

la interfaz no cumple con esos requisitos, muy probablemente la aplicación obtendrá

un uso por parte de los usuarios mucho menor.

Dos aspectos claves a la hora de realizar la interfaz de usuario son:

-Forma de interacción del usuario con el sistema

-Forma de presentar la información al usuario

Integrando estos dos aspectos, conseguiremos tener una interfaz coherente y

robusta.

Ilustración 33 - Características UI. Fuente: www.ida.cl



Llegados a este punto, una de las primeras tareas relacionadas con el

desarrollo del diseño de una interfaz, es diseñar los bocetos o wireframes de las

distintas pantallas y vistas a las que se va a enfrentar el usuario. Estos bocetos nos

proporcionarán una representación inicial de la estructuración de cada pantalla. Los

bocetos han de realizarse de la forma más simple posible al principio, sin incluir

estilos ni imágenes. Más adelante, estos se pueden mejorar e incluso dotar de

interactividad, con aplicaciones específicas para ello.

A continuación, se muestran los wireframes iniciales de las principales

pantallas de usuario de la aplicación móvil y web. Aunque el boceto inicial fue un

boceto a mano alzada, a papel y lápiz, estos fueron mejorados mediante una

herramienta específica para el diseño de wireframes, en este caso MockFlow8, que

nos permite utilizar una gran variedad de elementos de interfaces de usuario, lo que

hará de estos prototipos unos esquemas más claros y vistosos de la estructuración

de nuestra aplicación.

8 https://www.mockflow.com/

Ilustración 34 - Herramienta de prototipado Mockflow: www.mockflow.com



Pantalla Login

Esta será la primera pantalla presente en nuestra aplicación móvil híbrida.

Será un página de login, donde al usuario se le presentará un

formulario de entrada de datos. Estos datos de acceso serán el e-mail con que el

usuario se registre y la contraseña que este elija. Así mismo, se le mostrarán otras

dos opciones, la de registrarse en la aplicación y la de recuperar contraseña en caso

de que la haya olvidado.

Ilustración 35 - Interfaz 1: Login



Pantalla Perfil

Este segundo boceto de la interfaz de nuestra aplicación es la pantalla de

perfil del usuario. En ella habrá un apartado de imágenes de usuario, como podría

ser el avatar. Además, encontrará sus datos personales, así como un botón que le

permitirá la opción de modificar estos. También encontraremos otros botones que

nos llevarán a otras tres distintas pantallas, la de calendario, donde el usuario podrá

ver sus datos enviados por la pulsera por días; la de estadísticas, donde podrá ver

distintos gráficos y resúmenes de sus datos recogidos actuales; y por último la de

actividad. Encontramos en el apartado superior a la izquierda un botón de menú

lateral, que pasamos a ver a continuación.

Ilustración 36 - Interfaz 2: Perfil



Pantalla Menú Lateral

A la izquierda de la barra superior de nuestra aplicación siempre

encontraremos el botón de menú lateral, un menú que al seleccionarlo se abrirá de

izquierda a derecha mostrándonos distintos enlaces de acceso a páginas dentro de

nuestra aplicación, como son las que ya encontrábamos en la pantalla de perfil de

usuario, y además el acceso a ese mismo perfil y a la pantalla de conexión, donde

sincronizaremos la pulsera inteligente con nuestra aplicación. La mostramos a

continuación.

Ilustración 37 - Interfaz 3: Menú lateral



Pantalla Conexión

Esta pantalla de conexión y sincronización con la pulsera inteligente será

simple. Habrá un botón principal por el cual se activará el protocolo de conexión

mediante Bluetooth 4.0. La aplicación mostrará los distintos dispositivos que

encuentre y se conectará a nuestra pulsera de Withings Pulse OX de la que

mostrará los datos. Una vez conectada se nos mostrará una ventana emergente

anunciándonos que está conectada y que los datos han sido sincronizados.

Ilustración 38 - Interfaz 4: Conexión



Pantalla Calendario

En esta pantalla, el usuario podrá seleccionar un día utilizando un

calendario que se abrirá pulsando un botón. Además, podrá ver los datos

sincronizados por la pulsera del mismo día de manera cuantitativa, teniendo así una

primera forma de contacto con sus propios datos monitorizados.

Ilustración 39 - Interfaz 5: Calendario



Pantalla Estadísticas

En la pantalla de estadísticas el usuario podrá ver de manera gráfica

muchos detalles sobre los datos monitorizados de su pulsera inteligente. Solo tendrá

que elegir la característica de la cual quiere ver un resumen o resultados, y podrá

ver dicho resumen de datos y gráficos sobre su evolución. Al contrario que en la

pantalla de calendario, el usuario en esta podrá ver cada característica que mide la

pulsera por separado, y de una forma más detallada.

Ilustración 40 - Interfaz 6: Estadísticas



Pantalla Actividad

Accediendo a la pantalla de actividad, el usuario podría comenzar a

monitorear una característica en concreto en un momento determinado. Estas

posibilidades se le mostrarán en formato de lista, y el usuario seleccionará cual

quiere medir.

Esta sería la última pantalla de nuestra aplicación móvil, al menos en una

primera versión.

Ilustración 41 - Interfaz 7: Actividad



Pantalla Principal (Aplicación Web)

Igual que se hizo en un primer momento para la aplicación móvil, también

se crearon los bocetos de la aplicación web más adelante, una vez que se comenzó

a elaborar su diseño. En este primer caso, una vez que el usuario hace login, se le

presentará una página principal, donde podrá ver de forma cuantitativa sus datos

monitoreados por la pulsera. También, tendrá un menú izquierdo para acceder a las

dos principales páginas, las cuales son "Home", esta misma pantalla, y

"Estadísticas", pantalla que mostraremos a continuación. Además también tendrá

acceso a otra pantalla donde podrá visualizar sus datos personales.

Ilustración 42 - Interfaz 8: Pantalla Principal (Aplicación Web)



Pantalla Estadísticas (Aplicación Web)

Esta es el boceto de la pantalla de estadísticas de la aplicación web. El

usuario podrá ver en esta pantalla de forma gráfica un resumen más amplio y datos

provenientes de la pulsera. De esta manera el usuario podrá hacer una

comprobación de sus datos principales y un seguimiento de sus objetivos sin

necesidad de utilizar la aplicación móvil.

Con esto finalizaríamos una visión global de lo que sería la interfaz de usuario

de la aplicación móvil y web, siendo más importante y compleja la primera de estas,

ya que es la aplicación principal de nuestro proyecto en desarrollo. Cabe destacar y

recordar que la aplicación que se presenta es un prototipo en sí misma, por lo que

las operaciones mencionadas en cada pantalla puede que no sean aún

completamente funcionales.

Ilustración 43 - Interfaz 9: Pantalla de Estadísticas (Aplicación Web)



4.Implementación

4.1 Arquitectura

En este apartado vamos a especificar y mostrar la estructura de nuestra

aplicación, y la forma en que los distintos módulos se integran unos con otros. Al

tratarse de una aplicación móvil y web se utilizará un modelo de arquitectura de

Cliente/Servidor, donde se encuentran estas dos partes diferenciadas [13]:

- Front/end: Parte de la aplicación que interactúa con el usuario, basado en

una interfaz gráfica con la que el usuario podrá operar sobre la aplicación.

- Back/end: Parte no interactiva de la aplicación, donde se encontrará la base

de datos.

De esta forma, lo que realmente se está mostrando desde un punto de vista

arquitectónico de software es un sistema en capas, donde separaremos

presentación, lógica de negocio y base de datos.

Conociendo esto, pasaremos a definir los elementos más significativos del

desarrollo del sistema proporcionando una imagen global.

Ilustración 44 - Arquitectura en capas



Con esta imagen podemos ver de una manera ilustrativa todos los distintos

componentes internos de nuestra aplicación, así como la estructuración

arquitectónica del sistema. Como podemos observar, se representan elementos

relevantes en lo que se refiere a las interfaces de usuario así como de base de datos

y tecnologías con las que se implementa la lógica de negocio. También vemos la

separación existente entre la aplicación móvil híbrida y la aplicación web, además de

su forma de comunicación tanto con la base de datos como con la pulsera.

Ilustración 45 - Resumen de Arquitectura



4.2 Detalles sobre implementación

En este apartado vamos a desarrollar un poco más específicamente todos los

distintos aspectos tenidos en cuenta en cada fase de desarrollo del sistema que se

ha seguido mediante la metodología SCRUM a lo largo del proyecto. Veremos de

qué manera se ha implementado la arquitectura del sistema definida en anteriores

apartados de este documento. Esto se hará explicando también cada una de las

principales tecnologías y metodologías presentes en la implementación de nuestras

aplicaciones.

A continuación se muestra un listado de tecnologías que han sido utilizadas a

lo largo de la implementación:

- Angular JS v1.5.7

- Bootstrap v2.3.2

- Ionic v1.2.9

- Apache Cordova

- HTML 5

- CSS 3

- Firebase

- EVO Things API

- Bluetooth 4.0

- Node

De aquí en adelante explicaremos y justificaremos el uso de las principales

tecnologías utilizadas en cada uno de los sistemas en cuestión, tanto para la

aplicación móvil como en el caso de la aplicación web, haciendo hincapié como es

lógico en la aplicación móvil, debido a su mayor complejidad y su mayor prioridad e

importancia en el proyecto. Además, como mencionaremos más adelante, muchos

serán los aspectos comunes que la aplicación web heredará de la aplicación móvil.



4.2.1 Apache Cordova y AngularJS

Tenemos que recordar que pese a que nuestra aplicación móvil será una

aplicación web desde el punto de vista de la programación, finalmente esta será

compilada para su funcionamiento como aplicación móvil multiplataforma, lo que le

dará el tratamiento como aplicación híbrida. Esto se consigue mediante el marco de

desarrollo móvil de código abierto Apache Cordova 9[14], que permite utilizar

tecnologías web estándar para el desarrollo de aplicaciones móviles multiplataforma.

Estas tecnologías web pueden ser HTML, CSS y JavaScript. Es por esto que el

desarrollo de una aplicación móvil multiplataforma utilizando Apache Cordova va

muy ligado a JavaScript, lenguaje que tendremos que utilizar si queremos dotar a la

aplicación de ciertas funcionalidades. Apache Cordova además proporciona una

serie de bibliotecas y/o plugins que permiten la comunicación entre la interfaz web y

los elementos nativos del sistema operativo para el que la aplicación sea compilado,

así como elementos del dispositivo que pertenezca a dicha plataforma.

Existen numerosos frameworks de desarrollo basados en JavaScript que

facilitan mucho la labor del desarrollador. Uno de estos frameworks más conocidos

en la actualidad, así como de los que más documentación existe debido a su

elevado uso por parte de numerosos desarrolladores, es AngularJS [15]. Desde un

comienzo se destacó este framework para la programación del front-end de la

aplicación debido a que es muy ligero y potente, lo que lo hace ideal para una

aplicación móvil y, además, este hace uso del patrón de desarrollo MVC como ya

comentamos en apartados anteriores. Esto ayuda a que la aplicación sea más

eficiente y también a que la organización de esta sea mucho más modular

permitiendo así un bajo acoplamiento entre estos módulos.

AngularJS es una tecnología del lado del cliente desarrollada por Google, y

que funciona con las principales tecnologías web como HTML, CSS y JavaScript.

Este framework permite construir aplicaciones web modernas e interactivas. Incluye

numerosas facilidades para el desarrollador, como el hecho de que separa la lógica

de la aplicación, los modelos de datos y las vistas, permite inyecciones de

dependencias, incluye historial para la navegación en las aplicaciones (botones de

atrás/adelante) , se puede encargar también de funciones de testing, permite

9 https://cordova.apache.org/

Ilustración 46 - Angular JS. Fuente: www.angularjs.org



elaborar etiquetas propias (directivas) para así extender las etiquetas de

HTML, y muchas más operaciones.

Con AngularJS nuestra aplicación estará formada principalmente por tres

tipos de módulos, que unidos darán completa funcionalidad al conjunto de la

aplicación [16]. Estos tres módulos fundamentales serán las vistas, los controladores

y los servicios. Cada controlador se asociará a su vista y será el encargado de

dotarla de operabilidad y al mismo tiempo se suscribirá a distintos servicios globales

de la aplicación con distintas funcionalidades.

Nuestra aplicación de esta forma, quedará de la siguiente manera que

detallamos a continuación.

Tendremos un módulo principal, en este caso el módulo "App". Desde este

módulo se inyectarán las principales dependencias a servicios que tendrá nuestra

aplicación, como podemos ver en la siguiente imagen:

Ilustración 47 - Arquitectura de AngularJS. Fuente propia

Ilustración 48 - Módulo principal de la aplicación.



De esta manera, estas dependencias no necesitarán volver a ser indicadas en

ninguna otra clase. Además, en este módulo estableceremos las distintas rutas entre

pantallas que habrá en nuestra aplicación, incluyendo las vistas y los controladores

de estas vistas, por lo que desde este módulo podremos asignar rápidamente estas

rutas o incluir nuevas. Esta funcionalidad también forma parte de AngularJS

mediante su módulo de enrutado encargado de asociar las URLs introducidas con su

vista a renderizar. Necesitaremos añadir a esta función de configuración de rutas los

objetos "$stateProvider" y "$urlRouterProvider". A continuación vemos un ejemplo de

esto en nuestra aplicación:

A parte de este módulo principal, también contaremos con numerosas vistas y

controladores, en este caso un controlador por vista. Las vistas serán código HTML

y hojas de estilo CSS, mientras que en los controladores dispondremos de

funcionalidad en lenguaje JavaScript. Estos controladores son parte de el módulo

principal de la aplicación, lo que se especifica en la cabecera de cada controlador.

Ilustración 49 - AngularJS Router Provider



Además, estos controladores también tendrán inyecciones de dependencias

con otros servicios que utilicen. Vemos un ejemplo a continuación:

En la clase del módulo principal este controlador estará asociado a su vista,

como ya hemos especificado anteriormente.

Como en la mayoría de aplicaciones web, necesitaremos un fichero

"index.html" donde importar los numerosos servicios externos que utilizará nuestra

aplicación, para luego poder inyectar estos en el módulo principal. Además, en este

fichero será donde le indicaremos a la aplicación cuál será el modulo principal que

debe cargar, en este caso nuestro módulo "App". Para especificar esto, AngularJS

utiliza una directiva HTML llamada "ng-app". Vemos su uso en la aplicación:

Como vemos, el módulo se carga en el cuerpo del "index.html" de la

aplicación, tras haber cargado las hojas de estilo, servicios, etc. De esta manera la

aplicación ya comenzará a funcionar correctamente.

Una de las características más importantes de AngularJS a tener en cuenta

es la forma en que se comunican los controladores y las vistas [17]. Angular posee

un núcleo fundamental en todas sus aplicaciones, los "Scopes". Estos son los

objetos en la aplicación que sirven de unión entre estos controladores y sus vistas.

Cada vez que el valor de un objeto de tipo "Scope" ("$scope") cambia o es

modificado, también se modificará su representación en la vista, que se actualizará

con el valor correspondiente. Por lo tanto estos objetos se encargan de guardar la

información de los modelos que se representan en las vistas, así como también de

guardar atributos que se utilizarán también para manejar la lógica de estas vistas.

Estos "scopes" son manejados desde los controladores y las directivas. La

Ilustración 50 - Controlador en AngularJS

Ilustración 51 - Ng-app AngularJS



aplicación hace un manejo de todos los objetos "scopes" mediante el

elemento "$RootScope" que contendrá un contexto global de estos elementos en

toda la aplicación. A continuación vemos un ejemplo del uso de estos objetos:

Como podemos observar, estos objetos se referencian en la vista

insertados entre doble corchete ("{{ $scope }}").

Estos son los principales aspectos tenidos en cuenta a lo largo de la

implementación con AngularJS. Después, el restante contenido de los controladores

son funciones JavaScript que dotan de funcionalidad a la aplicación. Estas funciones

se llamarán también desde las vistas, como podemos apreciar a continuación:

Ilustración 52 - Declaración de un objeto $scope

Ilustración 53 - Uso de objetos $scope

Ilustración 54 - Llamada a función AngularJS

Ilustración 55 - Resumen AngularJS



Una vez que los conceptos de AngularJS están claros, se abre la necesidad

de contar con algún otro tipo de framework de plantillas de estilos CSS destinado a

dar la mejor visión posible al usuario de una interfaz elegante, ya que se trata de una

aplicación móvil y queremos dotarla de una buena usabilidad. Se abren varias

opciones de frameworks existentes para este cometido, pero tras el estudio y

búsqueda sobre el mundo de aplicaciones móviles híbridas, encontramos el

framework Ionic, que nos ayudará en este aspecto y que además no dotará de otros

contenidos interesantes. Se explicará en el siguiente apartado.

Para nuestra aplicación web también se ha utilizado este framework de

desarrollo AngularJS, lo que nos permite un desarrollo mucho más rápido ya que

tras realizar la aplicación móvil, muchas funciones han sido comunes, como por

ejemplo el login en la aplicación. Esto nos ha permitido favorecer la reusabilidad de

código. Además el proceso de desarrollo ha sido mucho más ágil debido a que ya se

conocía el funcionamiento del framework y solo hizo falta revisar nuestro código de

la aplicación móvil si había alguna duda durante el desarrollo.

4.2.2 Ionic Framework

Ionic es un framework gratuito y open source optimizado para el desarrollo de

aplicaciones móviles híbridas [18]. A parte de esta ventaja, la mayor ventaja para

nosotros es que este framework se basa en AngularJS, HTML y CSS, por lo que

resulta ideal para nuestra aplicación. Por tanto con Ionic ya tenemos todo lo

necesario para la elaboración de nuestra aplicación móvil, y que esta sea elegante

pero con una arquitectura interna robusta.

Ionic está inspirado en las principales SDK de desarrollo de las plataformas

móviles más populares, como pueden ser Android e iOS. Además, y como también

es necesario, trabaja sobre Apache Cordova, por lo que también puede hacer uso de

los innumerables plugins existentes para interaccionar con los distintos aspectos

internos de los dispositivos. También trabaja con SASS, que es un preprocesador de

elementos CSS que consigue que trabajar con estos elementos sea muy cómodo.



Lo realmente interesante, conjuntamente con todo lo anterior, es que nos

proporciona una biblioteca de componentes muy amplia para la elaboración de

nuestra interfaz de usuario, y también tenemos acceso a una documentación muy

extensa al respecto. Con estos componentes es muy difícil distinguir una de estas

aplicaciones con una aplicación móvil nativa.

La forma de trabajar con Ionic es realmente cómoda, ya que desde una

terminal podemos crear proyectos vacíos o con estructuras predeterminadas,

añadirle plugins, compilar los proyectos, ejecutarlos en simuladores o en nuestro

propio dispositivo si este está conectado con USB a nuestro ordenador (siempre que

lo configuremos en modo desarrollador). Por tanto es así de sencillo. Además, a

partir de la creación de un proyecto en una carpeta determinada, ya nos estructurará

las distintas carpetas de una forma organizada.

En definitiva este framework nos permite desarrollar aplicaciones híbridas con

una arquitectura robusta, utilizando AngularJS, HTML y CSS, con un muy buen

rendimiento y con una apariencia de aplicación móvil nativa.

Ilustración 57 - Creando un proyecto Ionic

Ilustración 56 - Ionic Framework. Fuente: www.ionicframework.com



4.2.3 FIirebase

Durante el estudio de cuál sería el mejor sistema de bases de datos a utilizar, y

relacionado con las búsquedas sobre los frameworks Ionic y AngularJS encontramos la API

de Firebase [19] y pareció muy interesante para nuestro proyecto. Firebase es una potente

API que presenta la utilidad de almacenar y sincronizar datos en tiempo real. En definitiva

estamos ante una base de datos de tipo NoSQL que se presenta como un servicio. Esta Api

está dirigida tanto a aplicaciones web como a aplicaciones móviles, desde las cuales se

puede hacer una sincronización en directo y en vivo de los datos que se desee.

Una de las cosas más interesantes para nuestro proyecto, es que esta API tiene una

librería específica para usar junto a AngularJS, y una extensa documentación al respecto.

Es por todo esto que se decidió utilizar esta API para el almacenamiento de nuestros datos,

ya que tampoco estos serán elevados, simplemente los datos de los usuarios y sus datos

provenientes de la pulsera. La sincronización llegados a este punto es muy interesante,

pues puede ser muy útil para recoger datos sistemáticamente. La librería que ofrece

Firebase para AngularJS se denomina AngularFire [20].

El primer paso para utilizar Firebase es crearse una cuenta en su web. Tras esto,

podrás crear una nueva aplicación para la que Firebase posteriormente creará una URL

única, todas siempre terminando en "firebaseio.com". Tras esto, en nuestro "index.html"

tendremos que incluir las dependencias necesarias, en este caso de Firebase y de

AngularFire.

Ilustración 58 - AngularJS y Firebase. Fuente: www.firebase.com



Después, y como ya explicamos en el apartado de AngularJS, deberemos inyectar

estas dependencias también en nuestro módulo principal como vemos a continuación:

En este caso nos basta con inyectar "firebase" como dependencia. Tras esto

Firebase nos ofrece tres tipos de servicios distintos: "$firebaseObject",

"$firebaseArray" y "$firebaseAuth". Cualquiera de estos podrá ser inyectado en los

controladores o servicios propios de nuestra aplicación.

Con Firebase siempre trabajaremos con nuestra URL única que la web nos

creó para nuestra aplicación. Es por esto que en la aplicación, esta URL ha sido

guardada como una constante, para poder utilizarla en cualquier momento de una

forma más sencilla. Lo vemos en la siguiente imagen:

La siguiente parte que se lleva a cabo en la aplicación con Firebase y

AngularFire fue la creación de un login. Firebase también proporciona sus propios

métodos para llevar eso a cabo. Además incluye funciones específicas para hacer

un login mediante distintas redes sociales o servicios como Gmail, aunque en este

caso no estén estos implementados. El login implementado se elabora partiendo del

servicio "$firebaseAuth" al que se le asigna nuestra URL única. Tras esto, se

especifican los campos que tendrá un perfil mediante la función "CreateProfile", y por

último se especificará que este login se llevará a cabo mediante correo y contraseña.

Aquí lo vemos en nuestra aplicación:

Ilustración 59 - Inyección de dependencias de Firebase y AngularFire

Ilustración 60 - Inyección en el módulo de AngularJS

Ilustración 61 - URL de Firebase global



Como vemos esta funcionalidad está implementada en un servicio que

contiene esta y otras funcionalidades correspondientes con el registro o

recuperación de contraseña. Si vemos la cabecera, comprobamos que no se trata de

un controlador si no de un "factory" que es otro elemento de AngularJS para crear

este tipo de servicios con funcionalidad útil en otras partes de la aplicación.

Después, para utilizar este login solo hará falta inyectar este servicio "Auth" como

dependencia en el controlador donde se vaya a implementar el formulario. Más tarde

en otro controlador se añadió una variable global "userkey" como identificador único

de cada uno de los usuarios, para después poder trabajar mediante ese identificador

con cada uno de ellos. Tras hacer todo esto, si vamos a la pantalla principal de

Ilustración 62 - Login con Firebase



nuestra aplicación en la página de Firebase nos encontraremos con esta

estructura, que nos indica que todo ha salido correctamente:

Para finalizar, nos queda por saber cómo añadir datos a Firebase, para que

estos puedan ser sincronizados. Nuevamente tendremos que crear un objeto

"$firebaseObject" que contenga la URL de referencia sobre la que queremos añadir

o modificar datos. Como vemos en la siguiente imagen, queremos acceder al perfil y

a los datos del usuario, por lo que guardamos dicha dirección:

Ilustración 64 - URL de referencia Firebase

Tras esto podemos, por ejemplo, pedir datos a los usuarios y guardarlos

automáticamente en nuestra base de datos de Firebase, como vemos en la siguiente

imagen:

Ilustración 63 - Estructura en página de Firebase.

Ilustración 65 - Sincronización de datos con Firebase



Como vemos, el trabajo para añadir o modificar datos consiste en recorrer el árbol de

nuestra estructura hasta llegar al campo deseado, y una vez ahí especificar, añadir o

modificar lo que se desee.

Estos son los aspectos más relevantes que han sido útiles para comprender la

manera en la que se trabaja con Firebase y AngularJS y para poder utilizarlos en la

aplicación en desarrollo.

Por otro lado, nuestra aplicación web hace uso de nuestra base de datos de firebase.

De hecho, el login de esta aplicación es muy similar al de la aplicación móvil, ya que solo

tenemos que acceder nuevamente a nuestra URL única de nuestra aplicación. Una vez que

el usuario realiza su login en la aplicación web, esta recogerá sus datos almacenados en

firebase de la misma forma en que lo implementábamos en la aplicación móvil. Esta

aplicación web hay que recordar que será un servicio para que los usuarios de la aplicación

móvil puedan acceder a ver todos sus datos recogidos con esta aplicación sin necesidad de

acceder a esta. Esta es otra de las grandes ventajas del uso de firebase, la facilidad que hay

para acceder a unos datos almacenados y sincronizados en la nube desde varias

aplicaciones y sin un elevado aumento de código.

4.2.4 EVOthings

Uno de los principales problemas a tratar de nuestro proyecto era la forma en la que

podríamos llevar a cabo el estudio e implementación del protocolo Bluetooth 4.0 en nuestra

aplicación híbrida. Existe una empresa de desarrolladores llamada "EVOthings10" [21] cuyo

objetivo es la de ofrecer un servicio para facilitar el desarrollo de aplicaciones móviles

relacionados con el mundo del IoT ("Internet de las cosas", en español) . Esta empresa ha

desarrollado numerosos plugins para poder desarrollar aplicaciones móviles que puedan

intercomunicarse con diferentes sensores, protocolos de comunicación o dispositivos

inteligentes específicos. Todos estos plugins son de código abierto y son ofrecidos de

manera totalmente gratuita para que los desarrolladores hagan uso de ellos.

10 www.evothings.com

Ilustración 66 - EVOthings. Fuente: www.evothings.com



Uno de los plugins que esta empresa ha desarrollado hace referencia a la

comunicación con dispositivos BLE, y más concretamente para utilizarlo sobre Apache

Cordova y para desarrollo con JavaScript, por lo que con esto tenemos lo que buscamos.

Pasamos a explicar cómo ha sido el desarrollo con este plugin [23].

Lo primero que tenemos que tener en cuenta es que nuestro periférico de Bluetooth

4.0 puede estar en dos estados distintos, "advertising" o "conected". Cuando un periférico

está en el primero de estos estados, lo que estará haciendo es mandar una señal con su

nombre, por lo que si se hace un escaneo de dispositivos cercanos, podremos ver dicho

dispositivo y nos podremos conectar a él. El otro estado se refiere a la existencia de un

vínculo entre nuestro sistema principal (en este caso el dispositivo móvil) y el periférico, a

través del cual ya existe la posibilidad de intercambiar datos entre los dispositivos, leer

valores o ejecutar ciertos comandos sobre el periférico.

Con el plugin que nos ofrece Evothings podremos llevar a cabo las siguientes

acciones:

- Escanear para encontrar un periférico BLE cercano.

- Identificar dicho dispositivo y conocer la distancia a la que se encuentra a partir de

su RSSI.

- Conectarte al dispositivo.

- Leer servicios, características y descriptores que contiene el dispositivo.

- Leer/escribir datos sobre las características del dispositivo que nos interesa.

- Activar notificaciones (lecturas sobre una característica cada cierto tiempo).

Para comenzar a trabajar con este plugin solo tendremos que añadir a nuestro

proyecto el fichero "ble.js" que podemos encontrar en la página de Evothings y en su

repositorio de Git-hub, e instalar el plugin propiamente dicho para Apache Cordova a partir

de la consola de comandos. En la imagen siguiente vemos como instalar este y cualquier

otro plugin de Cordova a partir de una sola línea en la consola de comandos:

El fichero "ble.js" es la API que Evothings nos ofrece para trabajar con el plugin

BLE, y a partir de la cual podremos hacer uso de las funcionalidades explicadas

anteriormente. Además en la web podemos encontrar algún tutorial al respecto, que fue de

utilidad al comienzo del desarrollo de esta parte del proyecto. Una vez instalado el plugin,

ya podemos pasar a trabajar con las distintas funciones que la API nos ofrece. A

continuación veremos ejemplos de algunas de estas funciones en nuestro controlador que

se hace cargo de la conexión con la pulsera, empezando por el escaneo de dispositivos y la

conexión.

Ilustración 67 - Importación de plugin para Cordova. Fuente: www.github.com



Como vemos todo se basa en funciones definidas previamente por Evothings, que

cubre las funciones principales. Después el objetivo es obtener todos los parámetros

necesarios sobre un dispositivo para después tener acceso a más datos sobre ellos.

Podemos ver un ejemplo de esto en la función de conexión donde, después de establecer

esta conexión, obtenemos los parámetros "deviceHandle" que es un identificador del

Ilustración 68 - Escaneo de dispositivos BLE con Evothings

Ilustración 69 - Conexión a dispositivo BLE



dispositivo y "address" que es la dirección MAC del dispositivo en cuestión, y con

estos llamamos a la función que leerá los servicios del dispositivo:

Con esta función accederemos a todos los servicios que nos ofrezca el dispositivo, y

nos dará sus propiedades principales, como el UUID por el que un servicio se identifica, y el

tipo de servicio. Tras obtener toda esta información, ya podremos comenzar a leer las

características que contiene cada uno de estos servicios:

Ilustración 70 - Escaneo de Servicios BLE

Ilustración 71 - Escaneo de Características BLE



Con esta función identificamos las características que posee cada uno de los

servicios que hemos encontrado, hasta obtener todas. Después, como podemos observar,

debemos dar un permiso de lectura para poder leer los datos que contienen estas

características, que ya serán los datos de interés que monitoriza el dispositivo. Tras dar este

permiso, se llama a la función de lectura, y también se comprueba si estas características

tienen algún tipo de descriptor. La función para leer los datos de las características la

encontramos a continuación:

En los dispositivos BLE que poseen servicios genéricos GATT, los datos vienen

codificados en formato UTF8 ("8-bit Unicode Transformation Format") [24]. Esta codificación

usa grupos de bytes para representar el estándar de "unicode", que asigna los enteros del 0

al 127 a exactamente los mismos caracteres en ASCII. UTF8 empaqueta cualquiera de

estos enteros en un octeto de bits con el primer bit de paridad a 0, a no ser que el símbolo a

empaquetar sea mayor que 127 en la tabla de "unicode" [25], en cuyo caso este bit de

paridad será 1 para indicar que aún hay que leer el siguiente octeto para completar la

descodificación. Por tanto, para obtener el valor de estos datos se utiliza la función

"fromUtf8" que se aplicará a los datos recogidos. Esta función pasará los objetos binarios a

enteros y buscará a que símbolo pertenece. De esta forma esos datos codificados podrás

ser extraídos.

Ilustración 72 - Lectura de Características BLE



Por desgracia para nuestro proyecto, la pulsera de Withings utiliza servicios

personalizados y desarrollados únicamente para esta pulsera, es decir, servicios no

genéricos y que no podemos encontrar en la lista de servicios que Bluetooth ofrece a los

desarrolladores. Esto quiere decir que los datos finales de monitorización de la pulsera

Pulse OX de Withings tienen otra codificación distinta, no genérica. Por tanto a no ser que

conociéramos como está elaborada esa codificación, no se podría hacer nada al respecto

para obtener esos datos finales. Aún así, de conocer esa codificación, habría que

implementar esa parte del trabajo, pues el plugin BLE para Cordova no contempla este tipo

de casos, como es lógico.

Durante el desarrollo se intentó ponerse en contacto con personal de la empresa de

Withings, pero solo se consiguió que nos redireccionasen a su API para desarrolladores, la

cual se basa en trabajar a partir de su propia aplicación y no de comunicarse con la pulsera,

por lo que no es lo que pretendíamos en este proyecto.

No obstante, mediante nuestra implementación podemos hacer una conexión con

cualquier dispositivo BLE, conocer sus servicios, características y descriptores. El único

paso que queda es el de hacer la lectura, que será posible solo con dispositivos que

contengan servicios genéricos contemplados por el perfil genérico de atributos GATT. Para

nuestro prototipo, tras desarrollar esta funcionalidad se decide completar el resto utilizando

valores de ejemplo, ya que es imposible en estos momentos obtener valores reales de

monitorización de nuestro dispositivo.

4.2.5 Bootstrap

Uno de los aspectos del desarrollo nuestra aplicación web que no es común con la

aplicación móvil es el uso del framework Bootstrap. Este framework [26] ofrece de forma

gratuita librerías CSS para añadir a proyectos web basados en HTML, CSS y JavaScript.

Este framework se utiliza en gran medida para hacer aplicaciones web que sean "responsive

design", es decir, que se adapten a las distintas pantallas de los distintos dispositivos donde

estas se visualicen.

Ilustración 73 - Bootstrap. Fuente: www.bootstrap.com



De esta forma, nuestra aplicación web se adaptará también a dispositivos móviles

como smartphones o tablets. Bootstrap 11define diferentes clases y formatos CSS, además

de poseer un potente sistema de grids y columnas. Bootstrap divide la pantalla en doce

partes y posee cuatro rangos de resoluciones distintas, por lo que para conseguir ese

"responsive design" se deciden, para cada elemento de la página, las partes que se le

asignarán de esas doce dependiendo del rango de resolución donde se visualiza la

aplicación en cuestión.

Además bootstrap tiene una extensa documentación sobre su funcionamiento, por lo

que es uno de los frameworks más conocidos y utilizados por los desarrolladores. A parte de

esta documentación, también tenemos un rápido acceso a todos sus componentes, que

podemos encontrar en su web, como por ejemplo botones, iconos, listas, mensajes de error,

barras de tareas, grupos...etc. Además contamos con numerosos ejemplos de uso de cada

uno.

Bootstrap es descargable desde su propia web, aunque también lo podemos clonar

de un repositorio mediante consola de comandos. Una vez descargado, tendremos que

especificar en el "index.html" de nuestra aplicación las dependencias necesarias. No

obstante también encontramos un completo manual de instalación en la web.

Como podemos observar, tenemos nuestra aplicación desarrollada con AngularJS y

con el framework de diseño bootstrap, trabajando sin ningún problema.

11 http://getbootstrap.com/

Ilustración 74 - Sistema de columnas de Bootstrap



A continuación mostramos cómo se comporta el "responsive design" de nuestra

aplicación:

Ilustración 75 - Visionado de la aplicación web en PC

Ilustración 76 - Visionado de la aplicación web en Smartphone



5. Conclusiones

En la actualidad vivimos en un mundo donde el objeto más cotidiano que nos

rodea puede estar continuamente aportando o recibiendo información de algún tipo.

Podemos encontrar objetos que poseen sensores de temperatura, de actividad vital,

de proximidad, y de otros muchos más tipos con mirar a nuestro alrededor. Estos

sensores pueden formar parte de un reloj, de una pulsera, de un llavero, de una

nevera, de un sistema de calefacción y en definitiva de una inmensidad de objetos

que nos rodean, y que aunque no lo sepamos son dispositivos inteligentes. Es por

esto que el desarrollo de aplicaciones que hacen uso de estos dispositivos o que se

comunican con ellos es claramente creciente en la actualidad, ya que de esta forma

es como utilizamos esta inteligencia para conseguir mejorar nuestro estilo de vida.

La mayoría de estas aplicaciones son aplicaciones móviles, ya que son estos

los dispositivos más fáciles y rápidos de usar en un momento determinado. El

problema a día de hoy con el desarrollo móvil es la gran diversidad de plataformas

que hay disponibles, para cada una de las cuales hace falta un desarrollo por

separado. No obstante, y debido a esta problemática, otros ámbitos de desarrollo

móvil están ganando terreno, como puede ser la programación de aplicaciones

móviles híbridas. Es por esto que resulta tan interesante conocer en profundidad

ciertos aspectos del desarrollo de este tipo de aplicaciones y su relación con

dispositivos que contienen información, como una pulsera inteligente en nuestro

caso.

El objetivo de estudiar, obtener conocimientos y demostrar estos en relación a

las aplicaciones móviles híbridas ha sido cumplida de una forma bastante efectiva,

ya que el resultado final conseguido ha sido el de una aplicación totalmente

funcional y que raramente diferenciaríamos de una aplicación móvil nativa. Por otra

parte, este mismo objetivo pero relacionado con el proceso de comunicación entre

aplicaciones híbridas y dispositivos inteligentes mediante el protocolo de

comunicación Bluetooth 4.0 también ha sido positivo, aunque en este caso nos

encontramos con alguna barrera más. El hecho de que los datos que estos

dispositivos puedan tener una codificación personalizada por parte de las empresas

que los confeccionan, y que esta codificación no se dé a conocer públicamente a

desarrolladores, hace que se dificulte mucho la opción de desarrollo de distintas

aplicaciones, y promueve bastante poco la creación e investigación sobre estos

dispositivos. No obstante ocurre todo lo contrario con otros grupos que se dedican a

crear y mantener APIs para facilitar el desarrollo con estos dispositivos. Gracias a

ellos, como por ejemplo Evothings, hemos podido establecer una comunicación

entre nuestra aplicación móvil híbrida y la pulsera inteligente que hemos tenido a



nuestra disposición, y hemos podido conocer la estructura interna de este dispositivo

inteligente.

Afortunadamente, existen otros dispositivos cuya codificación es genérica y

podemos trabajar con ellos sin ningún tipo de problema.

El desarrollar este proyecto ha supuesto una gran motivación por obtener

nuevos conocimientos y poder conocer en primera persona lo que es enfrentarse a

un proyecto de estas magnitudes. Durante el desarrollo hubo altibajos como no

puede ser de otra manera, y quizás la parte de la conexión con la pulsera inteligente

ha dado más problemas que los esperados, pero finalmente esos problemas

también han aportado más conocimiento sobre el protocolo de comunicación y sobre

el funcionamiento de estos dispositivos, que son desconocidos para la mayoría de

nosotros. Es cierto que de no haber tenido los problemas con la conexión, el

prototipo podría haber estado más avanzado, pero se ha intentado plasmar todo lo

necesario. Otro aspecto que me ha parecido muy útil de aquí en adelante es el

descubrimiento del servicio web Firebase como base de datos NoSQL en la nube,

sobre todo por su fácil uso y su rápido aprendizaje. Me parece una buena opción

para el almacenamiento de sistemas que no sean excesivamente complejos.

En definitiva pienso que este proyecto me resultará útil en el futuro. Conocer

el desarrollo de aplicaciones híbridas es muy interesante, sobre todo teniendo en

cuenta que los resultados son muy positivos, y comenzar a conocer aspectos sobre

la comunicación de estas aplicaciones con dispositivos inteligentes en la época en la

que nos situamos, también me parece muy interesante y útil para el futuro.

5.1 Mejoras y trabajos futuros

Con este tipo de aplicaciones y dispositivos se nos abre un mundo de

posibilidades sobre el tratamiento de los datos que obtenemos. Sería muy

interesante que la aplicación contase con otras funcionalidades distintas a las

especificadas, como consejos de salud, marcador de objetivos, creación de horarios

para hacer actividades, y cualquier idea de este tipo que se considere interesante.

Como es evidente, quizás tendríamos que encontrar una pulsera cuyos servicios que

proporciona fueran genéricos, y podamos así acceder a los datos finales y utilizar

estos, de manera que la aplicación sea totalmente funcional con el dispositivo.

Además se podrían mejorar los sistemas de estadísticas mostrando muchas

más posibilidades de estudio de los datos monitorizados. Otra parte que podría

pasar a tener más funcionalidades es la aplicación web, que en nuestro caso es solo

de lectura de datos y estadísticas, y que incluso podría comunicarse directamente



con la aplicación móvil para iniciar actividades o activar notificaciones de datos. De

esta forma se conseguiría interconectar en mayor medida las dos aplicaciones.



6. Bibliografía

[1] A.Álvarez, Heras, R. D., & Lasa, C. (2011). Métodos ágiles y Scrum (Manuales

imprescindibles). Anaya multimedia.

[2] Cockburn, A. (2001). Agile Software Development. Addison Wesley.

[3] Qué es SCRUM. (s.f.). Obtenido de Proyectos Ágiles: https://proyectosagiles.org/

[4] Jiménez, E. (2010). Ingenieria de software ágil. Bubok.

[5] Tipos de APPS: Nativas, híbridas y web apps. (s.f.). Obtenido de Appio:

http://appio.es/

[5] SIG, B. (s.f.). Low energy. Obtenido de https://www.bluetooth.com/.

[6] Essex, M. (28 de June de 2012). Why Google loves responsive design (and you

should too). Obtenido de https://econsultancy.com/blog/10210-why-google-loves-responsive-

design-and-you-should-too/: https://econsultancy.com

[7] Lee, N. (5 de October de 2011). Bluetooth 4.0: What is it, and does it matter?

Obtenido de http://www.cnet.com/: http://www.cnet.com/news/bluetooth-4-0-what-is-it-and-

does-it-matter/

[8] Townsend, K., Cufí, C., & Davidson, R. (2014). Getting Started with Bluetooth Low

Energy. En Getting Started with Bluetooth Low Energy. O'Reilly Media.

[9] Barranco, M. (s.f.). Apuntes de la asignatura Ingeniería de Requisitos. Jaén.

Universidad de Jaén.

[10] González, P. (2014). Apuntes de la asignatura Desarrollo Ágil. Jaén. Universidad de

Jaén.

[11] Díaz, W. (2013). Bases de datos NoSql. Obtenido de

http://basesdedatosnosql.blogspot.com.es/.

[12] Larman, C. (2003). UML y patrones: introducción al análisis y diseño orientado a

objetos y al proceso unificado. Madrid: Prentice-Hall.

[13] Rivas, V. (s.f.). Apuntes de la asignatura: Interacción Persona y Ordenador.

Universidad de Jaén. Jaén.

[14] González, P. (2015). Apuntes de la asignatura de Diseño de Software. Jaén.

Universidad de Jaén.



[15] Documentación de Apache Cordova. (2015). Obtenido de

https://cordova.apache.org/.

[16] Guía de desarrolladores de AngularJS. (2015). Obtenido de

https://docs.angularjs.org/guide: https://angularjs.org/

[17] Azaustre, C. (s.f.). ¿Qué es AngularJS? Primeros pasos para entenderlo. Obtenido

de https://carlosazaustre.es/blog/empezando-con-angular-js/: https://carlosazaustre.es/

[18] Learn AngularJS 1.X. (s.f.). Obtenido de

https://www.codecademy.com/es/learn/learn-angularjs: https://www.codecademy.com/es

[19] Getting Started with Ionic Framework. (s.f.). Obtenido de http://ionicframework.com/

[20] Firebase Developer Docs. (s.f.). Obtenido de https://www.firebase.com/docs/:

https://www.firebase.com

[21] AngularFire. (s.f.). Obtenido de https://www.firebase.com/docs/web/libraries/angular/:

https://www.firebase.com

[22] Evothings Api Overview. (s.f.). Obtenido de https://evothings.com/doc/api/api-

overview.html: https://evothings.com

[23] BLE app development in JavaScript. (25 de September de 2014). Obtenido de

https://evothings.com/ble-app-development-explained/: https://evothings.com

[24] Townsend, K., Cufí, C., & Akiba. (2014). GATT (Services and Characteristics). En

Getting Started with Bluetooth Low Energy. O'Reilly Media.

[25] The Unicode Consortium. (s.f.). Obtenido de http://unicode.org/

[26] Getting started. (s.f.). Obtenido de http://getbootstrap.com/getting-started/:

http://getbootstrap.com/getting-started/



APÉNDICE I: Manual de instalación del sistema

Aplicación móvil

La aplicación está compilada para su uso en sistema operativo android. En el

dispositivo USB suministrado para la entrega del trabajo de fin de grado, hay una

carpeta denominada aplicación móvil. Dentro de esta estará por un lado el código

fuente y por otro un archivo con extensión "apk". Este archivo es directamente

instalable en un dispositivo android.

Aplicación Web

Para probar la aplicación web en un navegador, este ha de soportar

JavaScript. Esto no será mucho problema ya que la mayoría de navegadores lo

soportan. Una vez que tenemos la carpeta del código fuente descomprimido,

tendremos que abrir la consola de comandos. Una vez en la consola, debemos

situarnos mediante rutas en la carpeta app de la aplicación web. Tras esto, basta

con lanzar un comando http-server para que la aplicación se ejecute en el

"localhost". Tras esto, la consola nos especificará algunas de las direcciones de

localhost a las que podemos acceder desde un navegador. Tras acceder, ya

veremos la pantalla de login de nuestra aplicación.



APÉNDICE II: Manual de usuario

Aplicación móvil

Cuando abrimos la aplicación móvil nos encontraremos con un formulario de

login. Pulsaremos sobre "Register" si no tenemos una cuenta creada. Tras realizar el

registro, si todo es correcto ya podrás hacer el login en la aplicación.

Una vez que nos hemos logueado, llegaremos a la página principal de nuestro

perfil, que en un primer momento estará vacío. Debemos entonces pulsar sobre el

botón de modificación de datos y se nos pedirán todos los datos necesarios. Los

datos después se podrán modificar en cualquier momento.

Ilustración 78 - Pantalla de inicio Ilustración 77 - Pantalla de registro



Como vemos, desde el perfil nos podemos mover a tres distintas páginas:

calendario, estadísticas y actividad. Además, si pulsamos sobre el botón de menú

que hay en la esquina superior izquierda, se nos abrirá un menú lateral que nos

permitirá acceder a estas tres páginas y además a la página de conexión. También

en dicho menú tendremos la opción de salir de la aplicación.

Pasamos a la pantalla de calendario. En este caso encontraremos datos

referentes a la monitorización de la pulsera (no reales) y el día actual marcado.

Pulsando sobre este día, podremos seleccionar otro día del calendario para ver

nuestros datos guardados.

Ilustración 79 - Pantalla principal



Otra de las pantallas es la de estadísticas. En esta pantalla podremos ver las

estadísticas de la última semana referente a cada uno de los datos de actividad que

mide la pulsera. El último día será el día actual. Podremos ver dos tipos de gráficos,

de área y de línea. Cambiaremos de datos pulsando sobre su nombre. Además,

desde esta página podremos compartir mensajes a través de Whatsapp, Twitter o

Facebook.

Ilustración 81 - Calendario: Pantalla principal

Ilustración 80 - Calendario: Selección de día



Por último desde el perfil, podíamos acceder al apartado de actividad. Este

apartado está destinado a monitorizar un aspecto en específico durante un rango de

tiempo determinado, por ejemplo si se va a hacer una carrera. En esta pantalla

primero seleccionaremos uno de los aspectos que queremos medir, y después

pasaremos a otra pantalla donde podremos comenzar la actividad y pararla en el

momento que queramos. Habrá un botón para cada una de estas posibilidades, y un

contador de tiempo.

Ilustración 83 - Pantalla estadísticas Ilustración 82 - Pantalla estadísticas:

Redes sociales



Por último, faltaría la pantalla de conexión. Una vez dentro de esta solo habrá

que pulsar sobre el botón de sincronizar y la aplicación se conectará a la pulsera y

obtendrá todos sus servicios y características. No obstante, la aplicación buscará la

pulsera que se tuvo para el desarrollo, por lo que no podrá conectarse a otra.

Ilustración 84 - Pantalla de actividad principal

Ilustración 85 - Pantalla de comienzo de actividad



Ilustración 86 - Pantalla de conexión



Aplicación web

La primera parte de nuestra aplicación web será un formulario de login. En este

introduciremos el correo y contraseña con los que nos creamos la cuenta en la aplicación

móvil. Tras esto, podremos acceder sin problema.

Una vez dentro nos encontraremos en la página principal donde veremos los datos

actuales recogidos por la pulsera inteligente. También podremos acceder a nuestros datos

personales.

Por último, también tenemos acceso a una pantalla de estadísticas en la columna

izquierda de la pantalla. En esta pantalla podremos ver estadísticas de nuestros datos de

actividad en la última semana, igual que podemos hacer en la aplicación móvil.

Ilustración 87 - Pantalla login aplicación web

Ilustración 88 - Pantalla principal aplicación web



Ilustración 90 - Pantalla datos personales aplicación web

Ilustración 89 - Pantalla estadísticas aplicación web



APÉNDICE III: Descripción de contenidos suministrados

La memoria USB que se entrega se compondrá de los siguientes elementos:

-Aplicación web: Carpeta que contendrá el código fuente de la aplicación web

comprimido en formato ".rar".

-Aplicación móvil: Carpeta que contendrá por una parte el código fuente de la

aplicación móvil comprimido en formato ".rar" y por otra parte un fichero ".apk" de

instalación de la aplicación en android.

-Video: Carpeta que contiene un video resumen del funcionamiento de las

aplicaciones.

-Diagramas: Carpeta que contiene un fichero con todos los diagramas utilizados

para la memoria del trabajo.

u jaÉn escuela politÉcnica superior (jaÉn)...

Documents