Descargar - Archivo Digital UPM - Universidad Politécnica de Madrid

Escuela Técnica Superior de Ingenieros
Industriales
Universidad Politécnica de Madrid
TRABAJO FIN DE GRADO
DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE
IDENTIFICACIÓN BASADO EN TECNOLOGÍA NFC
APLICADO A SERVICIOS DE RESTAURACIÓN
Autor:
Ramón Arteaga Rodrı́guez de los Santos
Tutor:
Yago Torroja Fungairiño
Madrid, 2016
Agradecimientos
Este trabajo está dedicado a muchas personas, todas ellas fundamentales en
mi vida. Gracias a vosotros siempre se puede sacar fuerzas de flaqueza frente a la
adversidad y seguir adelante con una sonrisa.
Gracias Fran, por tu constante apoyo. Gracias por enseñarme tanto sobre programación, pero sobre todo gracias por demostrarme que la distancia no impide que
dos personas puedan ser grandes amigos.
Gracias César, por ser un referente en el modo de afrontar la adversidad, por
conducirme en mis despistes y por haber sido un gran amigo durante estos años.
Gracias Carlos, por haber estado siempre ahı́ cuando te he necesitado, ya sea como
programador, como consejero, como escuchador, o como baterista los viernes por la
noche.
Gracias Fer, por hacerme sentir maestro con nuestras charlas cientı́ficas, y
alumno con las económicas. Gracias Raquel, por alejarme del mundo de las ciencias y descubrirme nuevos horizontes en el ámbito artı́stico. Dicen que los amigos de
verdad están para lo bueno, pero sobre todo para lo malo. Gracias por ser amigos
de verdad.
Gracias Javi, gracias Benito, gracias Yago. Gracias por vuestra generosidad, por
orientarme y ser un apoyo fundamental durante este trabajo.
Y un agradecimiento especial...
A mi hermana. A pesar de haberte visto crecer, siempre serás mi hermanita
pequeña. Siempre serás esa hermana que tiene una sonrisa para mı́ aunque el mundo
vaya en contra. Es un privilegio ser tu hermano, y un honor intentar cada dı́a ser
un referente para ti. Gracias, Marta.
A mi padre y a mi madre. Vosotros sois los pilares de mi vida, los que me
habéis brindado las mejores oportunidades, los que habéis puesto a vuestros hijos
por delante de cualquier cosa, los que habéis creı́do en mı́. Siempre decı́s que soy
un orgullo para vosotros, pero la verdad es que el verdadero orgullo es el que siente
un hijo cuando ve a sus padres orgullosos de él. Gracias papá, gracias mamá, este
trabajo culmina un Grado que os agradezco y dedico especialmente a vosotros.
I
II
Enseñar no es lo importante; la función vital es aprender.
Aristóteles. Filósofo (322 a. C. - 384 a. C.)
III
IV
Resumen
La constante evolución de la tecnologı́a supone una imparable modernización del
mundo en el que vivimos. Cada vez más tareas cotidianas se actualizan introduciendo
dispositivos electrónicos que las hacen más sencillas y eficientes.
La identificación inalámbrica es un ejemplo de estas tareas: cada vez más establecimientos cuentan con sistemas de pago electrónico; el metro y los autobuses
disponen de lectores electrónicos para los abonos; el acceso a lugares restringidos
puede realizarse asimismo mediante identificación del personal, etc.
Se llevan a cabo estas tareas de identificación mediante sistemas que cuentan
con un lector que lee los tags (aquellos dispositivos que pueden ser identificados:
smartphones, llaveros, tarjetas, abonos...) que puede ser independiente o puede estar
conectado a otro módulo que actúe como cerebro que procesa la información (servidor
web, ordenador, smartphone, etc).
En el presente trabajo se diseña e implementa uno de estos sistemas de identificación contactless, tanto a nivel hardware como a nivel software. Este sistema
contará con dos módulos: el lector propiamente dicho y un dispositivo basado en
Android que controlará al lector y procesará la información recibida de aquél.
De cara al hardware, se profundiza en las tecnologı́as NFC (Near Field Communication) y Bluetooth, pues son tecnologı́as que permiten la lectura de los tags y de
comunicar ambos módulos, respectivamente. Se profundizará de igual modo en las
plataformas Arduino y Android de cara al software que gobierne el comportamiento
de ambos módulos.
Se desarrolla el sistema propuesto aplicándolo a un caso práctico: la implantación del mismo en la cafeterı́a de una residencia de estudiantes, que jugará por
tanto el rol de cliente. Se trata de un entorno que reúne las caracterı́sticas necesarias
para contemplar la implantación de un sistema de este tipo. En efecto, es necesaria
la identificación de los residentes, pero la cafeterı́a no disponı́a hasta ahora de un
dispositivo electrónico para tal fin. Por tanto este paradigma permitirá evaluar la
utilidad, productividad y eficiencia del sistema de identificación presentado en este
trabajo. Además, se complementa dicho sistema con funcionalidades acordadas con
el cliente, creando ası́ una herramienta completa para la gestión de su negocio.
V
VI
Abstract
The constant evolution of technology involves an unstoppable modernization of
the world we live in. More and more daily tasks take advantage of electronic devices,
therefore becoming easier and more efficient.
Wireless identification is an example of such tasks: the number of stores that
support electronic payment is increasing; subway and buses have electronic readers
for transport tickets; access to restricted areas is granted through staff identification,
and so on.
These identification tasks are performed by systems consisting of a device capable of reading tags (devices that can be identified: smartphones, keyrings, cards,
tickets. . . ), which can either function independently or be connected to another module that centralizes the information, such as a smartphone, a computer, a web
server, and so on.
In this project, a contactless identification system is designed and implemented, both at a hardware and software level. This system consists of two modules:
the reader itself and an Android device that controls the reader and processes the
received information.
Regarding hardware, the NFC (Near Field Communication) and Bluetooth technologies are studied in detail, since they allow for reading the tags and communicating both modules, respectively. On the other hand, the software implementation
for both modules is based on Arduino and Android.
The proposed system is developed with the aim of solving a practical problem: to
provide an identification system for the cafeteria of a student residence, which will act
as a customer. It is an environment that gathers all the requirements to implement
such a system. Indeed, it is necessary to identify the residents, but the cafeteria did
not yet have such an electronic device for this purpose. Therefore, this paradigm will
allow us to evaluate the usefulness, productivity and efficiency of the identification
system presented in this work. Furthermore, the system is complemented with a set
of functionalities agreed with the customer, therefore creating a complete tool to
manage their business.
VII
VIII
Palabras clave
Sistema de identificación, NFC, Bluetooth, Arduino, Android.
Keywords
Identification system, NFC, Bluetooth, Arduino, Android.
IX
X
Índice general
1. INTRODUCCIÓN
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Alcance y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Contenido de la memoria . . . . . . . . . . . . . . . . . . . . . . . . .
2. ESTADO
2.1. NFC
2.1.1.
2.1.2.
DEL ARTE
. . . . . . . . . . . . . . . . . . . . . . . . .
Introducción . . . . . . . . . . . . . . . . .
Caracterı́sticas . . . . . . . . . . . . . . .
2.1.2.1. Especificaciones técnicas . . . . .
2.1.2.2. Seguridad en NFC . . . . . . . .
2.1.3. Comunicación NFC . . . . . . . . . . . . .
2.1.3.1. Configuraciones de utilización . .
2.1.3.2. Estándares de comunicación . . .
2.1.3.3. Caracterı́sticas de funcionamiento
2.1.3.4. Modos de comunicación . . . . .
2.1.3.5. Protocolos . . . . . . . . . . . . .
2.1.3.6. Pasos de la comunicación . . . .
2.1.4. NFC en la actualidad . . . . . . . . . . . .
2.2. Bluetooth . . . . . . . . . . . . . . . . . . . . . .
2.2.1. Introducción . . . . . . . . . . . . . . . . .
2.2.2. Caracterı́sticas . . . . . . . . . . . . . . .
2.2.2.1. Especificaciones técnicas . . . . .
2.2.2.2. Seguridad en Bluetooth . . . . .
2.2.3. Comunicación Bluetooth . . . . . . . . . .
2.2.3.1. Arquitectura a nivel hardware . .
2.2.3.2. Protocolos . . . . . . . . . . . . .
2.2.3.3. Perfiles . . . . . . . . . . . . . .
2.2.3.4. Caracterı́sticas de funcionamiento
2.2.3.5. Pasos de la comunicación . . . .
2.2.4. Versiones . . . . . . . . . . . . . . . . . .
2.3. Comparativa . . . . . . . . . . . . . . . . . . . . .
XI
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
4
5
5
5
6
6
7
7
7
8
9
9
10
10
11
12
12
13
13
14
15
15
15
16
17
18
18
20
ÍNDICE GENERAL
ÍNDICE GENERAL
3. PLATAFORMAS DE DESARROLLO
3.1. Android . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1. Introducción . . . . . . . . . . . . . . . . . .
3.1.2. Versiones . . . . . . . . . . . . . . . . . . .
3.1.3. APIs . . . . . . . . . . . . . . . . . . . . . .
3.1.4. Arquitectura . . . . . . . . . . . . . . . . . .
3.1.5. Entorno de desarrollo: Android Studio . . .
Creación de un proyecto en Android Studio
3.1.6. Aplicaciones en Android . . . . . . . . . . .
3.1.6.1. Estructura del proyecto . . . . . .
3.1.6.2. Estructura de la aplicación . . . .
3.1.6.3. Activities . . . . . . . . . . . . . .
3.2. Arduino . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Introducción . . . . . . . . . . . . . . . . . .
3.2.2. Placas Arduino . . . . . . . . . . . . . . . .
3.2.3. Entorno de desarrollo: Arduino IDE . . . . .
4. HARDWARE
4.1. Componentes . . . . . . . . . . . . .
4.1.1. Arduino . . . . . . . . . . . .
4.1.1.1. Arduino UNO . . . .
4.1.1.2. Arduino NANO . . .
4.1.2. NFC . . . . . . . . . . . . . .
4.1.2.1. Lectores comerciales
4.1.2.2. Módulos compatibles
4.1.3. Bluetooth . . . . . . . . . . .
4.1.4. Otros componentes . . . . . .
4.1.4.1. LCD . . . . . . . . .
4.1.4.2. LED RGB . . . . . .
4.2. Montaje . . . . . . . . . . . . . . . .
4.2.1. Primer prototipo . . . . . . .
4.2.2. Prototipo final . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
con Arduino
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
5. SOFTWARE
5.1. App Android . . . . . . . . . . . . . . . .
5.1.1. Análisis . . . . . . . . . . . . . . .
5.1.1.1. Definición . . . . . . . . .
5.1.1.2. Requisitos . . . . . . . . .
5.1.2. Diseño e implementación . . . . . .
5.1.2.1. Clases . . . . . . . . . . .
5.1.2.2. Diagrama de navegación .
5.1.2.3. Gestión de la información
Base de datos local: SQLite
XII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
21
23
26
27
28
28
31
31
31
32
34
34
34
36
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
39
39
41
42
42
43
45
46
46
47
47
47
51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
59
59
60
61
65
65
68
69
69
ÍNDICE GENERAL
ÍNDICE GENERAL
Almacenamiento local . . . . . . . .
Almacenamiento en la nube: Google
5.1.2.4. Bluetooth . . . . . . . . . . . . .
5.1.2.5. Bibliotecas externas . . . . . . .
5.1.2.6. Cafeterı́a RUGP . . . . . . . . .
5.1.2.6.1. Servicio . . . . . . . . . . . . .
5.1.2.6.2. Opciones . . . . . . . . . . . .
Tags . . . . . . . . . . . . . . . . .
Residentes . . . . . . . . . . . . . .
Archivos . . . . . . . . . . . . . . .
Lista de la compra . . . . . . . . .
Instagram . . . . . . . . . . . . . .
Backups . . . . . . . . . . . . . . .
Ajustes avanzados . . . . . . . . . .
5.1.2.7. Manifest . . . . . . . . . . . . . .
Activities . . . . . . . . . . . . . . .
Permisos . . . . . . . . . . . . . . .
5.1.2.8. Casos de uso . . . . . . . . . . .
5.2. Módulo lector: firmware . . . . . . . . . . . . . .
5.2.1. Bibliotecas . . . . . . . . . . . . . . . . . .
5.2.2. Configuración inicial: setup . . . . . . . . .
5.2.3. Ejecución: loop . . . . . . . . . . . . . . .
5.2.3.1. Máquina de estados . . . . . . .
5.2.3.1.1. Diseño . . . . . . . . . .
5.2.3.1.2. Implementación . . . . .
Estados . . . . . . . . . . . . . . .
Transiciones . . . . . . . . . . . . .
6. EVALUACIÓN Y PROBLEMAS
6.1. Módulo lector . . . . . . . . . . . . . . . . . .
6.1.1. Evaluación . . . . . . . . . . . . . . . .
6.1.1.1. Primeras pruebas: BlueTerm
6.1.1.2. Pruebas con la app . . . . . .
6.1.2. Problemas encontrados . . . . . . . . .
6.2. Cafeterı́a RUGP . . . . . . . . . . . . . . . . .
6.2.1. Evaluación . . . . . . . . . . . . . . . .
6.2.2. Problemas encontrados . . . . . . . . .
7. DIRECCIÓN DEL PROYECTO
7.1. Gestión del alcance . . . . . . . . . . . .
7.2. Gestión del tiempo . . . . . . . . . . . .
7.2.1. Diagrama de Gantt del proyecto .
7.2.2. Diagrama de Gantt del producto
XIII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
Drive
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
73
76
80
82
84
86
92
93
95
98
102
103
105
105
106
106
107
108
109
109
110
111
112
112
113
113
115
.
.
.
.
.
.
.
.
119
. 119
. 119
. 119
. 120
. 121
. 123
. 123
. 124
.
.
.
.
127
. 127
. 131
. 131
. 134
ÍNDICE GENERAL
ÍNDICE GENERAL
7.3. Gestión de costes . . . . . . . . . . . . .
7.3.1. Contabilidad del proyecto . . . .
Gasto de personal . . . . . . . . .
Gasto de hardware . . . . . . . .
Gastos de software . . . . . . . .
Presupuesto de ejecución material
7.3.2. Presupuesto del producto . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
136
136
136
137
138
138
139
8. LÍNEAS FUTURAS
143
9. CONCLUSIONES
145
Apéndices
145
A. IMPACTOS
147
A.1. Impacto ambiental . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
A.2. Impacto social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
XIV
Índice de figuras
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
Configuraciones de utilización en NFC (Cortesı́a
Modo de comunicación activa . . . . . . . . . .
Modo de comunicación pasiva . . . . . . . . . .
Logotipo de la tecnologı́a Bluetooth . . . . . . .
Pila de protocolos Bluetooth [11]. . . . . . . . .
Conexiones maestro/esclavo [15]. . . . . . . . .
Scatternet formado por dos piconets [12]. . . . .
de NFC Forum).
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
9
10
12
16
17
17
3.1. Andy, logotipo de Android. . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Gráfico de la distribución de las versiones de Android en los dispositivos (20 de junio de 2016) . . . . . . . . . . . . . . . . . . . . . . . .
3.3. Distribución global de las versiones de Android durante su historia. .
3.4. Arquitectura del sistema Android[20]. . . . . . . . . . . . . . . . . . .
3.5. Android SDK Manager. . . . . . . . . . . . . . . . . . . . . . . . . .
3.6. Clase de la activity principal. . . . . . . . . . . . . . . . . . . . . . .
3.7. Layout de la activity principal. . . . . . . . . . . . . . . . . . . . . .
3.8. Ciclo de vida de una activity. . . . . . . . . . . . . . . . . . . . . . .
3.9. Comparativa de las placas oficiales (cortesı́a de Arduino [1]) . . . . .
3.10. Entorno de desarrollo de Arduino . . . . . . . . . . . . . . . . . . . .
3.11. Valores posibles para el baudrate del monitor serial del IDE de Arduino
25
25
27
29
30
30
33
35
36
37
4.1. Arduino UNO R3 (cortesı́a de Arduino) . . . . . . . . . . . . . . . . .
4.2. Arduino NANO (cortesı́a de Arduino) . . . . . . . . . . . . . . . . . .
4.3. Lector comercial con comunicación Bluetooth (cortesı́a de Sumlung).
4.4. Lector comercial con comunicación USB (cortesı́a de Emartee). . . . .
4.5. Shield RFID-NFC para Arduino UNO (cortesı́a de Elecrow). . . . . .
4.6. Módulo lector RFID-NFC basado en el sensor pn532 . . . . . . . . .
4.7. Módulo Bluetooth HC-05 . . . . . . . . . . . . . . . . . . . . . . . . .
4.8. Módulo LCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.9. Módulo LED RGB . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.10. Diseño del prototipo. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.11. Esquema del prototipo. . . . . . . . . . . . . . . . . . . . . . . . . . .
40
41
42
42
43
44
45
46
47
48
49
XV
22
ÍNDICE DE FIGURAS
ÍNDICE DE FIGURAS
4.12. Vista frontal del prototipo. . . . . . . . . . . . . . . . . . . .
4.13. Vista trasera del prototipo. . . . . . . . . . . . . . . . . . . .
4.14. Vista en perspectiva del prototipo. . . . . . . . . . . . . . .
4.15. Diseño de la PCB del prototipo. . . . . . . . . . . . . . . . .
4.16. Circuito buscado en la PCB. . . . . . . . . . . . . . . . . . .
4.17. PCB fabricada en el taller del departamento de Electrónica.
4.18. Base de la carcasa. . . . . . . . . . . . . . . . . . . . . . . .
4.19. Embellecedor de la carcasa. . . . . . . . . . . . . . . . . . .
4.20. Cubierta de la carcasa. . . . . . . . . . . . . . . . . . . . . .
4.21. Parte trasera de la carcasa. . . . . . . . . . . . . . . . . . . .
4.22. Módulo lector: carcasa y circuito electrónico. . . . . . . . . .
4.23. Módulo lector: encapsulación del circuito en la carcasa. . . .
4.24. Módulo lector ensamblado y listo para su uso. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
50
51
52
52
53
54
54
55
55
56
56
57
5.1. Diagrama de navegación de la app. . . . . . . . . . . . . . . . . . . . 68
5.2. Clases cuyas instancias permiten leer la información de la base de datos. 72
5.3. Árbol de directorios creado por la app. . . . . . . . . . . . . . . . . . 74
5.4. Clase Backups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5. Diálogo de confirmación. . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.6. Registro de la app en la consola de Google. . . . . . . . . . . . . . . . 78
5.7. Integración del Bluetooth en la app. . . . . . . . . . . . . . . . . . . . 82
5.8. ActionBar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.9. Pantalla principal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.10. Autorización para el acceso a las opciones de la app. . . . . . . . . . 86
5.11. Lógica de conexión entre los módulos durante en Servicio. . . . . . . 87
5.12. Modos de funcionamiento en servicio: modo manual. . . . . . . . . . . 90
5.13. Modos de funcionamiento en servicio: modo automático. . . . . . . . 90
5.14. Modos de funcionamiento en servicio: modo mixto. . . . . . . . . . . 91
5.15. Tipos de dialogs en función de la pensión del residente. . . . . . . . . 92
5.16. Menú de opciones de la app. . . . . . . . . . . . . . . . . . . . . . . . 93
5.17. Opciones relativas a los tags. . . . . . . . . . . . . . . . . . . . . . . . 94
5.18. Opciones relativas a los residentes. . . . . . . . . . . . . . . . . . . . 96
5.19. Fichas de residente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.20. Historial de registros de un residente. . . . . . . . . . . . . . . . . . . 97
5.21. Pantalla para añadir un residente o modificar sus datos. . . . . . . . . 98
5.22. Opciones relativas a los registros: historial y visualización de backups. 99
5.23. Opciones relativas a los registros: generación de backups. . . . . . . . 99
5.24. Personalización de gráficas. . . . . . . . . . . . . . . . . . . . . . . . . 101
5.25. Restauración de datos y visualización de la lista de la compra. . . . . 101
5.26. Ejemplos de gráficas generadas con la app. . . . . . . . . . . . . . . . 102
5.27. Administración de la lista de la compra. . . . . . . . . . . . . . . . . 103
5.28. Pantallas destinadas a compartir imágenes tomadas desde la app. . . 104
5.29. Modificación de parámetros desde Ajustes avanzados. . . . . . . . . . 105
XVI
ÍNDICE DE FIGURAS
ÍNDICE DE FIGURAS
5.30. Pantalla de aceptación de permisos previa a la instalación de
5.31. Casos de uso de la app. . . . . . . . . . . . . . . . . . . . . .
5.32. Máquina de estados del módulo lector. . . . . . . . . . . . .
5.33. Mensaje en estado de espera. . . . . . . . . . . . . . . . . .
5.34. Mensajes mostrados en el display en S4. . . . . . . . . . . .
la app.
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
107
108
112
114
115
7.1.
7.2.
7.3.
7.4.
7.5.
7.6.
7.7.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
128
129
130
132
133
135
141
Nivel superior de la EDP . . . . . . . . . . . . . . .
Desglose de la EDP (1/2) . . . . . . . . . . . . . .
Desglose de la EDP (2/2) . . . . . . . . . . . . . .
Diagrama de Gantt del proyecto: desglose de tareas.
Diagrama de Gantt del proyecto: diagrama. . . . .
Diagrama de Gantt del producto. . . . . . . . . . .
Representación gráfica del desglose del presupuesto.
XVII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE DE FIGURAS
ÍNDICE DE FIGURAS
XVIII
Índice de tablas
2.1. Clasificación de los dispositivos por su potencia de transmisión Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2. Velocidades de transmisión de las diferentes versiones Bluetooth. . . . 13
2.3. Comparativa entre las principales caracterı́sticas de NFC y Bluetooth. 20
3.1. Distribución de versiones Android en los dispositivos (20 de junio de
2016) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Resumen de caracterı́sticas de la Arduino UNO R3 (cortesı́a de Arduino) 40
4.2. Resumen de caracterı́sticas de la placa Arduino NANO (cortesı́a de
Arduino) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1. Requisito patrón. . . . . . . . . . . . . .
5.2. RC-01: Control de datos. . . . . . . . . .
5.3. RC-02: Almacenamiento de datos. . . . .
5.4. RC-03: Sincronización. . . . . . . . . . .
5.5. RC-04: Alertas sonoras. . . . . . . . . . .
5.6. RC-05: Información de la conexión con el
5.7. RC-06: Control básico del lector . . . . .
5.8. RC-07: Modo de servicio. . . . . . . . . .
5.9. RC-08: Gráficas. . . . . . . . . . . . . . .
5.10. RC-09: Lista de la compra. . . . . . . . .
5.11. RC-10: Compartir imágenes. . . . . . . .
5.12. RU-01: Interfaz de usuario (UI). . . . . .
5.13. RU-02: Conectividad automática. . . . .
5.14. RU-03: Contraseña. . . . . . . . . . . . .
5.15. RU-04: Plataforma . . . . . . . . . . . .
5.16. Clases del proyecto . . . . . . . . . . . .
7.1.
7.2.
7.3.
7.4.
Presupuesto
Presupuesto
Presupuesto
Presupuesto
parcial del proyecto no
parcial del proyecto no
parcial del proyecto no
de ejecución material.
XIX
1:
2:
3:
.
. . . .
. . . .
. . . .
. . . .
. . . .
lector.
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Gastos de
Gastos de
Gastos de
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
62
62
62
62
63
63
63
63
64
64
64
64
65
66
personal.
hardware.
sofware. .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
137
137
138
138
ÍNDICE DE TABLAS
7.5.
7.6.
7.7.
7.8.
Presupuesto
Presupuesto
Presupuesto
Presupuesto
ÍNDICE DE TABLAS
parcial del producto no 1: Gastos de personal. .
parcial del producto no 2: Gastos de hardware. .
parcial del producto no 3: Gastos de sofware. . .
de ejecución material del producto. . . . . . . .
XX
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
140
140
140
140
Listings
5.1. Lectura de registros de la base de datos. . . . . . . . . . .
5.2. Obtención del resumen MD5 del archivo debug.keystore. .
5.3. Huella digital obtenida. . . . . . . . . . . . . . . . . . . . .
5.4. Subida de la base de datos a Google Drive. . . . . . . . . .
5.5. Integración de ICallback y BluetoothHelper. . . . . . . . .
5.6. Bibliotecas importadas en build.gradle. . . . . . . . . . . .
5.7. Sistema FIFO en modo automático. . . . . . . . . . . . . .
5.8. Declaración de la activity principal. . . . . . . . . . . . . .
5.9. Declaración de las activities no principales. . . . . . . . . .
5.10. Permisos declarados en el Manifest. . . . . . . . . . . . . .
5.11. Inicialización de los módulos Bluetooth y NFC. . . . . . .
5.12. Inicialización de la máquina de estados. . . . . . . . . . . .
5.13. Ejemplo de implementación de un estado de la máquina de
5.14. Función loop. . . . . . . . . . . . . . . . . . . . . . . . . .
5.15. Progreso de la sincronización. . . . . . . . . . . . . . . . .
5.16. Transición S1 → S2. . . . . . . . . . . . . . . . . . . . . .
6.1. Lectura única de códigos recibidos por Bluetooth. . . . . .
XXI
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
estados.
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
73
78
78
79
81
84
89
106
106
107
110
111
111
112
113
116
122
LISTINGS
LISTINGS
XXII
Capı́tulo 1
INTRODUCCIÓN
El objetivo de este capı́tulo es servir como introducción a la memoria de este
Trabajo Fin de Grado, mediante la exposición de la motivación, alcance, objetivos
y estructura de la misma.
1.1.
Motivación
El progreso de la tecnologı́a busca facilitar el dı́a a dı́a de las personas, tanto en
lo profesional como en lo personal. En la revolución tecnológica en la que nos vemos
inmersos estos años se ha manifestado la tendencia a la automatización, entendida
como el desarrollo de sistemas con el fin de reducir o eliminar la intervención humana
en la producción o en el funcionamiento de bienes y servicios [14].
Este Trabajo Fin de Grado pretende proponer un sistema de identificación basado en radiofrecuencia. Se desarrollará dicho sistema enfocándolo a los servicios de
restauración alojados en hoteles, colegios mayores, residencias, etc. En este tipo de
establecimientos el cliente tiene que identificarse como tal para disfrutar del servicio,
que en el caso planteado, es un desayuno o un menú de comida o cena. En concreto,
en aquellos en los que el cliente realiza un pago previo en función de los servicios que
desea contratar, este control de acceso se torna vital de cara a una correcta gestión
de la actividad del restaurante.
A lo largo de la memoria se desarrolla un sistema que automatiza estos procesos que a dı́a de hoy algunos locales siguen llevando a cabo mediante métodos
manuales, identificando al cliente a través de una lista, que en el mejor de los casos
es informática, pero que en ocasiones es, como quien dice, con papel y bolı́grafo.
La motivación surge de la experiencia propia del autor, quien, durante sus años
de estudio en la Escuela Técnica Superior de Ingenieros Industriales, se ha alojado
1
1.1. MOTIVACIÓN
CAPÍTULO 1. INTRODUCCIÓN
en una residencia de estudiantes. En ella, se ha identificado el problema descrito
previamente, y es lo que ha motivado a buscar una solución más acorde al entorno
tecnológico y automatizado de estos dı́as. Por lo que se ha resaltado anteriormente,
la solución propuesta no solo resuelve el problema observado, sino que se concibe
como una solución perfectamente válida para otros establecimientos de similares
caracterı́sticas, otorgando al Trabajo Fin de Grado ambas perspectivas: particular y
general. En concreto, se va a aplicar al servicio de cafeterı́a de la citada residencia de
estudiantes, la cual jugará en este sentido el papel de cliente para quien se pretende
desarrollar un producto.
Se ha buscado una tecnologı́a con potencial, alcance y disponibilidad. Estas
caracterı́sticas las reúne la tecnologı́a basada en la radiofrecuencia (RFID, NFC...).
Se trata de una tecnologı́a cada vez más desarrollada, integrada en multitud de
dispositivos y compatible entre sus diferentes variantes. Además es una tecnologı́a
sencilla e intuitiva, pues permite la comunicación entre dispositivos simplemente con
el acercamiento entre ambos. Al estar integrada en los dispositivos, no requiere configuración por parte del usuario, asegurando la comodidad del mismo. Se trata de una
tecnologı́a segura, ya que para activar cualquier servicio o intercambiar información
el usuario tendrá que hacerlo manualmente, o bien juntar dos dispositivos móviles,
siendo por tanto el usuario el que confirma la acción. Todas estas cualidades confirman que es una tecnologı́a con futuro, y que está adquiriendo gran importancia,
además de popularizarse entre los usuarios. Por tanto una parte del sistema que se
pretende desarrollar es un lector basado en este tipo de tecnologı́a.
Por otra parte, el sistema de identificación planteado requiere, además del lector, una segunda parte consistente en una interfaz de cara al personal de la cafeterı́a.
El sistema que se escoge, tanto por petición del cliente como por suponer la profundización en una importante plataforma de desarrollo como es Android, será una
aplicación que gestione las tareas que se detallarán en capı́tulos posteriores.
Como resulta evidente, ambas partes del sistema, que en adelante denominaremos módulos, han de estar conectadas. Para ello se recurrirá a la tecnologı́a Bluetooth por lo que la comunicación será inalámbrica.
Por todo ello, este Trabajo Fin de Grado pretende resolver un problema detectado en el dı́a a dı́a del autor, aprovechando la oportunidad para aprender acerca
de diversas tecnologı́as, para profundizar en conocimientos y destrezas adquiridos
durante el Grado, y para desarrollar aptitudes en un entorno de programación a la
vanguardia como es Android. Además de la motivación que supone la resolución del
problema, a ello se suma la satisfacción de ver el resultado aplicado en un entorno
real que permita sacar provecho de sus caracterı́sticas y ventajas para comprobar la
utilidad y eficacia del trabajo realizado.
2
CAPÍTULO 1. INTRODUCCIÓN
1.2.
1.2. ALCANCE Y OBJETIVOS
Alcance y objetivos
El principal objetivo de este proyecto consiste en diseñar e implementar un
sistema de identificación, tanto a nivel hardware como a nivel software, como el que
se ha introducido en la sección anterior.
El sistema permite la automatización de la identificación de los clientes en el
comedor. Para ello, cada residente contará un tag de tipo llavero provisto de RFID
o NFC (se profundizará en NFC por ser una evolución más actual del RFID). El
personal contará con el sistema propuesto para la lectura de los tags. Consistirá básicamente en dos partes: un lector y un dispositivo basado en Android (smartphone o
tablet), comunicados de modo inalámbrico mediante la tecnologı́a Bluetooth.
Los tags contendrán únicamente un código de identificación. Los datos personales de cada residente se gestionarán mediante una base de datos en el dispositivo
Android, desde el cual se podrán modificar de un modo sencillo.
El lector tendrá como base un Arduino, que controlará, entre otros, los módulos de Bluetooth y NFC. Por su parte, se diseñará una aplicación en Android que
gestione la comunicación con el lector y ofrezca la posibilidad de llevar un registro.
Además se complementará el sistema con las funcionalidades que el cliente estime
oportunas.
Por ello, los objetivos a cumplir son:
Estudiar las tecnologı́as inalámbricas Bluetooth y NFC, analizando los diferentes protocolos de intercambio de datos entre los dispositivos.
Profundizar en el entorno de Arduino para desarrollar el firmware del lector.
Analizar el entorno de Android y familiarizarse con la programación de aplicaciones en esta plataforma.
Construir un módulo lector integrando las herramientas y tecnologı́as anteriores.
Programar una aplicación en Android que gobierne el funcionamiento del sistema y satisfaga los requisitos establecidos por el cliente.
Evaluar el funcionamiento global del sistema utilizándolo en la cafeterı́a de la
residencia.
Abordar el trabajo realizado desde la perspectiva de la Ingenierı́a de Proyeyctos
y analizar las lı́neas de futuro que pueden llevarse a cabo para mejorar el
producto desarrollado.
Redactar una correcta memoria del Trabajo Fin de Grado, que permita al
lector de aquélla comprender el trayecto seguido durante éste.
3
1.3. CONTENIDO DE LA MEMORIA
1.3.
CAPÍTULO 1. INTRODUCCIÓN
Contenido de la memoria
La memoria del proyecto se ha estructurado de modo que siga los pasos que se
han dado durante el desarrollo del mismo.
En primer lugar se incluye el estado del arte, esto es, el background tecnológico
resultado de un proceso de documentación en el que se analizan las tecnologı́as
inalámbricas que se van a utilizar en el proyecto para justificar su utilización.
En lı́nea con lo anterior, se incluye un análisis de las plataformas de desarrollo
de ambos módulos, ası́ como los entornos de desarrollo que permiten la creación del
software y el firmware de aquéllos.
Presentadas las bases tecnológicas, se detalla la parte relativa al hardware mediante la exposición del diseño fı́sico del producto que se propone como solución al
problema que se pretende resolver.
Posteriormente se desarrolla la implementación del sistema. Se exponen los aspectos fundamentales de la programación, la estructura y el funcionamiento del
firmware del módulo lector y de la app.
Una vez desarrollado el producto, se exponen los resultados y problemas hallados
durante la evaluación del mismo.
Con los objetivos cumplidos, se aborda el proyecto desde una perspectiva global,
analizando el trabajo realizado desde el punto de vista de la gestión del alcance, la
programación temporal, y los costes.
Se presentan en penúltimo lugar las conclusiones y las lı́neas futuras que permitan mejorar las caracterı́sticas del sistema e implementar nuevas funcionalidades.
Por último se hacen unos comentarios sobre los impactos ambientales y sociales
que tiene este Trabajo Fin de Grado, cuyo desarrollo propiamente dicho comienza a
partir del siguiente capı́tulo.
4
Capı́tulo 2
ESTADO DEL ARTE
En este capı́tulo se recopila la información necesaria para comprender las tecnologı́as que se utilizarán durante el desarrollo del proyecto. Como ya se ha introducido, el sistema propuesto tendrá dos módulos fundamentales. Uno será la interfaz
de cara al personal de establecimiento, y consistirá en un dispositivo Android y
una aplicación que gobierne el funcionamiento general del sistema. El otro consistirá en un lector que permitirá la identficación del cliente. Dicha identificación se
realizará mediante la tecnologı́a NFC, y la comunicación de ambos módulos se realizará mediante la tecnologı́a Bluetooth. Por ello, el objetivo del presente capı́tulo
se exponen los fundamentos tanto de NFC como de Bluetooth, recopilando como
conclusión sus principales caracterı́sticas que ponen de manifiesto sus diferencias y
similitudes.
2.1.
2.1.1.
NFC
Introducción
La tecnologı́a NFC (Near Field Communication) es una tecnologı́a inalámbrica
que permite la interconexión de dispositivos de corto alcance. Se basa en RFID, o
Radio-Frequency Identification. Esta tecnologı́a, de más antigüedad, permite el seguimiento y la identificación a través de ondas de radio de un objeto (normalmente
llamado tag RFID), que se adosa a un producto, animal o persona. La tecnologı́a
NFC combina las funciones de tag y reader/writer RFID en un único dispositivo.
Puesto que se trata de una extensión de RFID, es compatible con toda la infraestructura ya existente de RFID [6], lo que hace más atractiva e interesante a la
tecnologı́a NFC.
5
2.1. NFC
CAPÍTULO 2. ESTADO DEL ARTE
No obstante, la tecnologı́a NFC no está concebida para una transmisión masiva
de datos, a diferencia de otras como Bluetooth y WiFi, pero sı́ para una alta velocidad
de comunicación. En efecto, su punto fuerte es la rapidez en el intercambio de la
información, que suelen ser unos pocos bits, con lo que nos encontramos en una
comunicación casi instantánea.
A continuación profundizaremos en esta tecnologı́a para entender qué podemos
lograr con ella, su funcionamiento y su uso en la actualidad.
2.1.2.
Caracterı́sticas
Como ya se ha venido destacando, NFC es una tecnologı́a de comunicaciones
inalámbrica de corto alcance y alta frecuencia que permite el intercambio de datos
entre 2 dispositivos cercanos de manera bidireccional.
Se trata de una tecnologı́a que surgió con la idea de crear un nuevo protocolo
compatible con las tecnologı́as de corto alcance ya existentes. Se trata de una extensión de RFID, es decir, del estándar ISO/IEC 14443. Combina la interfaz de una
smart card y de un lector, integrados ambos en un mismo dispositivo.
Al incluir la posibilidad de comunicación bidireccional, entre dos dispositivos
activos, NFC difiere de RFID en dos aspectos:
1. NFC permite la comunicación peer to peer, o P2P, mientras que los protocolos anteriores solo soportan comunicación entre un dispositivo activo y tags
pasivos.
2. La activación no puede ser accidental o involuntaria, sino que ha de existir un
acercamiento entre dispositivos para iniciar la comunicación.
Desde el comienzo de su desarrollo a finales de 2002, fabricantes, desarrolladores
de aplicaciones, instituciones de servicios financieros, etc. han estado cooperando
para promover el uso de la tecnologı́a NFC en la electrónica de consumo, dispositivos
móviles y PC.
2.1.2.1.
Especificaciones técnicas
NFC opera con distancias de hasta 20 cm, y en la banda de los 13.56 MHz,
una banda de frecuencia no licenciada [22]. Con lo cual se puede usar libremente,
sin restricción y sin necesidad de licencia. Los dispositivos generan una onda de
radio mediante circuitos inductivos emparejados que posibilitan un flujo de datos
al estar próximos entre sı́. Los acoplamientos inductivos funcionan para distancias
cortas, por ello se emplea en NFC, pero no en tecnologı́as que trabajan a distancias
6
CAPÍTULO 2. ESTADO DEL ARTE
2.1. NFC
mayores como Bluetooth y WiFi, las cuales operan en el entorno de los 10 y 100 m.
respectivamente.
Otra comparación posible con entre tecnologı́as es la de la tasa de datos transmitidos. Como ya se ha dicho, NFC no está pensada para una transmisión masiva
de datos. La tasa de transferencia máxima es de 424 Kbps. en comparación a Bluetooth y WiFi, con tasas de transferencias del orden de los Mbps. Por ello el enfoque
de NFC es el de la comunicación instantánea, útil para tareas de identificación y
validación de equipos y personas. Otras tasas de transferencia ofrecidas son 106 y
212 Kbps.
2.1.2.2.
Seguridad en NFC
Dado que se trata de una comunicación por radiofrecuencia, la lectura no autorizada de la información transmitida es una posibilidad que existe siempre, por lo no
se puede descartar la copia de los códigos de nuestro chip para un uso fraudulento.
Sin embargo esto se contrarresta con la distancia de operación de NFC ya que al ser
de tan solo unos pocos centı́metros el espı́a deberı́a estar dentro de ese rango. Por
otra parte, un dispositivo pasivo, que no genera su propio campo de radio frecuencia,
es mucho más difı́cil de intervenir que un dispositivo activo [22].
La posibilidad del robo de nuestros datos no es la única preocupación. Algunas
otras amenazas son la modificación, corrupción e inserción de errores, y ataques
Man-in-the-middle 1 . Las aplicaciones deben usar protocolos criptográficos de una
capa superior para establecer un canal seguro, como por ejemplo la capa de conexión
segura, o SSL2 .
2.1.3.
Comunicación NFC
2.1.3.1.
Configuraciones de utilización
Existen tres configuraciones posibles para utilizar NFC. Esto la hace más adaptable y eficiente que otras tecnologı́as. Estas configuraciones son:
Emulación de tarjetas: en este modo un dispositivo se comporta como una
contactless card. Aprovechando las caracterı́sticas de seguridad, es útil para el
manejo de sistemas de pago o para controles de acceso e identificación.
1
Se trata de ataques en los que se adquiere la capacidad de leer, insertar y modificar a voluntad,
los mensajes entre dos partes sin que ninguna de ellas conozca que el enlace entre ellos ha sido
violado.
2
Secure Sockets Layer: https://www.digicert.com/es/ssl.htm
7
2.1. NFC
CAPÍTULO 2. ESTADO DEL ARTE
Modo reader/writer : es probablemente la configuración más habitual. En ella,
el dispositivo NFC se encuentra en modo activo, leyendo tags RFID pasivos.
Modo P2P: el NFC permite la comunicación entre dos dispositivos para el
intercambio de información. Permite el establecimiento de protocolos como
ocurre con Bluetooth o WiFi.
Figura 2.1: Configuraciones de utilización en NFC (Cortesı́a de NFC Forum).
2.1.3.2.
Estándares de comunicación
En 2004, Philips, Nokia y Sony fundaron el NFC Forum3 , encargado del desarrollo de las especificaciones, garantizando la interoperabilidad entre los dispositivos
NFC. En la figura anterior se aprecian estos estándares de comunicación:
NDEF: el formato NFC Data Exchange Format es un formato ligero de mensaje que se emplea para guardar y transportar diferentes tipos de elementos.
Únicamente especifica la estructura del formato, siendo éste el mismo tanto para un dispositivo NFC como para un tag. Por tanto, la información es
independiente de los dispositivos que se estén comunicando.
Dentro del formato de un mensaje NDEF se puede enviar información de
diversos tipos: encapsular documentos XML, datos encriptados, imágenes o
cadenas de información [7]
3
NFC Forum: http://www.nfc-forum.org/home
8
CAPÍTULO 2. ESTADO DEL ARTE
2.1. NFC
RTD: el estandar Record Type Definition especifica los tipos de registros que
pueden ser enviados en los mensajes entre los dispositivos[8]. Encontramos:
• Smart Poster RTD: Para incorporar etiquetas con datos (URLs, SMS o
números de teléfono).
• Text RTD: Para registros que solo contienen texto.
• Uniform Resource Identifier : Para registros referidos a un recurso de internet.
2.1.3.3.
Caracterı́sticas de funcionamiento
La tecnologı́a NFC se basa en las tecnologı́as contactless. Para ello se necesitan
dos tipos de dispositivos para el establecimiento de la comunicación.
El iniciador (initiator ) es el dispositivo que inicia y controla el intercambio
de información.
El objetivo (target) es el dispositivo que responde a la petición del iniciador.
Ambos roles son intercambiables entre las dos partes, con lo que cualquier dispositivo provisto de tecnologı́a NFC puede operar de las dos formas.
2.1.3.4.
Modos de comunicación
De manera similar a la tecnologı́a RFID, en NFC existen dos modos de funcionamiento:
Modo activo: cada dispositivo genera su propio campo electromagnético para
enviar los datos, reconociéndose automáticamente. Ambos dispositivos intercambian datos, y mientras está esperando respuesta, un dispositivo desactiva su campo. Por lo dicho, ambos dispositivos necesitan tener una fuente de
energı́a para su funcionamiento.
Figura 2.2: Modo de comunicación activa
9
2.1. NFC
CAPÍTULO 2. ESTADO DEL ARTE
Modo pasivo: sólamente el dispositivo iniciador genera campo, y el otro aprovecha dicho campo para intercambiar la información. Es un modo de mayor
eficiencia energética, aspecto relevante en dispositivos en los que la duración
de la baterı́a es crı́tico, como en PDAs o teléfonos móviles.
Figura 2.3: Modo de comunicación pasiva
2.1.3.5.
Protocolos
En la estandarización de la comunicación NFC ya comentada, se han definido
dos protocolos Near Field Communication Interface and Protocol :
NFCIP-1: el primero de estos dos protocolos define tanto el enlace de radiofrecuencia con la que NFC trabaja (13.56 MHz) como la arquitectura para las
tasas de datos (106, 212 y 424 Kbps) y los modos de operación activo y pasivo.
NFCIP-2: el segundo especifica un método para escoger una de las tres configuraciones de utilización (emulación, reader y P2P), de modo que no interfieran
otras comunicaciones en curso en la frecuencia de 13.56 MHz.
2.1.3.6.
Pasos de la comunicación
La comunicación que hemos venido describiendo, y caracterizada como casi
instantánea, en realidad consta de una serie de pasos:
1. Descubrimiento: es una primera etapa en la que los dispositivos comienzan un
proceso de rastreo mutuo para su posterior reconocimiento.
2. Autenticación: cada dispositivo verifica si esta autorizado para comunicarse
con el otro, o si ha de establecer algún tipo de cifrado.
3. Negociación: en esta etapa se definen parámetros como la velocidad de transmisión, el tipo de aplicación, la identificación del dispositivo, etc.
4. Transferencia: es la etapa en la que se produce el intercambio o flujo de información propiamente dicho.
10
CAPÍTULO 2. ESTADO DEL ARTE
2.1. NFC
5. Confirmación: por último, una vez se han realizado correctamente el establecimiento de comunicación y la transferencia de datos, el receptor ası́ lo confirma.
2.1.4.
NFC en la actualidad
A lo largo de la sección se han descrito las caracterı́sticas de la tecnologı́a NFC.
A partir de ellas se deducen los aspectos más interesantes que se pueden conseguir
en aplicaciones de la vida real: información y transacciones en tiempo real, ahorro en
utilización de papeles y folletos, automatización de tareas manuales y otras ventajas
derivadas de la combinación con otras tecnologı́as.
La premisa básica a la que se acoge el uso de la tecnologı́a NFC es aquella
situación en la que es necesario un intercambio de datos de forma segura y por
acercamiento de dispositivos. Lo usos que más futuro tienen son la identificación, la
recogida e intercambio de información y sobre todo, el pago electrónico.
Identificación
El acceso a lugares donde es precisa una identificación puede hacerse simplemente acercando un teléfono móvil o un tag NFC a un dispositivo de lectura. Los
abonos de autobús son un ejemplo muy válido de esto. Además está siendo utilizado
en empresas como método de validación de los empleados o incluso para llevar a cabo
un control de acceso a zonas restringidas. Las lı́neas futuras parecen apuntar a su
integración en documentos oficiales como el DNI, pasaporte o permisos de conducir
en un telefono móvil para poder llevarlos siempre encima [18].
Recogida e intercambio de datos
Aunque tradicionalmente durante los últimos años se ha utilizado Bluetooth,
con NFC existe una posibilidad de utilizar la tecnologı́a NFC para compartir datos,
siempre aprovechando la proximidad entre dos usuarios.
Google es el principal protagonista de este uso, pues en combinación con las
etiquetas RFID, utilidades como marcar dónde estamos, recibir información de un
evento o establecimiento son inmediatas.
Transacciones
Sin duda alguna, es la estrella de los usos del NFC. La comodidad de uso y que
el gasto pueda estar asociado a nuestra factura o una cuenta de banco son armas
11
2.2. BLUETOOTH
CAPÍTULO 2. ESTADO DEL ARTE
muy poderosas y esta tecnologı́a está camino de ser el método de pago del futuro.
Otro enfoque serı́a la de realizar una transferencia de dinero de una persona a otra.
Simplemente acercando el teléfono al de un amigo y validando la transacción, sin
duda una forma rápida y fácil de prestar o devolver dinero.
Además de estas aplicaciones, quizá las más evidentes y habituales, también
podemos llegar a encontrar la tecnologı́a NFC en otros contextos: folletos digitales,
hospitales, tarjetas de visitas, domótica, vehı́culos, ayudas a discapacitados, fotografı́a, localización, parkings...
2.2.
2.2.1.
Bluetooth
Introducción
Las redes de área personal inalámbrica, o WPAN, son tecnologı́as de red inalámbrica de corto alcance utilizadas para la conexión de dispositivos entre sı́ sin que dicha
conexión sea a través de cable. Bluetooth es una especificación industrial para este
tipo de redes.
Se trata de una tecnologı́a desarrollada por Ericsson en 1994 que facilita el
intercambio de información de manera inalámbrica entre dispositivos como computadores, teléfonos móviles o PDAs, manteniendo los niveles de seguridad ofrecidos
por la conexión cableada. En febrero de 1998, se formó un grupo llamado Bluetooth
Special Interest Group (Bluetooth SIG) que contó con más de 200 compañı́as, ente
las que estaban Ericsson, IBM, Intel, Microsoft, Motorola, Nokia y Toshiba [3]. Su
objetivo era desarrollar las especificaciones para Bluetooth 1.0, que se publicaron en
julio de 1999.
Figura 2.4: Logotipo de la tecnologı́a Bluetooth
El objetivo de Bluetooth es la transmisión de voz y datos mediante circuitos
de radiofrecuencia con un bajo consumo energético. Ofrece la posibilidad de crear
pequeñas redes inalámbricas entre diferentes equipos, ası́ como la sincronización de
datos entre ellos, facilitando las comunicaciones entre equipos fijos y móviles.
Los dispositivos que emplean esta tecnologı́a con mayor frecuencia pertenecen a
sectores de las telecomunicaciones o la informática personal. Ası́, encontramos total12
CAPÍTULO 2. ESTADO DEL ARTE
2.2. BLUETOOTH
mente integrada la tecnologı́a Bluetooth en PDAs, teléfonos móviles, ordenadores,
impresoras, cámaras digitales, teclados y ratones, etc.
2.2.2.
Caracterı́sticas
2.2.2.1.
Especificaciones técnicas
Las distancias permitidas por Bluetooth son mayores que las asociadas a la
tecnologı́a NFC estudiada en la sección anterior. La comunicación entre dispositivos
no exige que estos estén ni en contacto, ni siquiera alineados. Si la potencia es
suficiente, pueden estar incluso en habitaciones separadas. Por ello, encontramos
una clasificación de los dispositivos atendiendo a su potencia de transmisión, la cual
determina el alcance posible, como queda reflejado en la tabla 2.1.
Clase
Potencia máxima (mW)
Clase I
100
Clase II
2.5
Clase III
1
Alcance aproximado (m)
30
5-10
1
Tabla 2.1: Clasificación de los dispositivos por su potencia de transmisión Bluetooth.
A pesar de los valores anteriores, hay que destacar que en combinaciones de
dispositivos pertenecientes a distintas clases, dichos valores pueden extenderse. Por
ejemplo, un dispositivo de clase I, al tener mayor potencia de transmisión, permite
que la señal llegue con energı́a suficiente a un dispositivo de clase II, aunque la
separación entre ambos dispositivos sea superior a la del rango del dispositivo de
clase II.
La velocidad de transmisión, mayor en cualquier caso que las de NFC, depende
de la versión Bluetooth utilizada, como puede comprobarse en la tabla 2.2. Las
caracterı́sticas de las diferentes versiones se detallan en el posterior epı́grafe.
Versión
Versión 1.2
Versión 2.0
Versión 3.0
Versión 4.0
Velocidad de transmisión
1 Mbps
3 Mbps
24 Mbps
24 Mbps
Tabla 2.2: Velocidades de transmisión de las diferentes versiones Bluetooth.
Bluetooth opera en una banda libre de radiofrecuencia llamada banda internacional médico-cientı́fica, o banda ISM, de 2.4 a 2.48 GHz. Al ser la banda ISM
libre, está abierta a cualquier usuario que la quiera utilizar y expuesta al ruido
13
2.2. BLUETOOTH
CAPÍTULO 2. ESTADO DEL ARTE
externo pudiendo ocasionar interferencias y pérdidas de información. Por ello la tecnologı́a Bluetooth realiza un rápido emparejamiento y utiliza saltos de frecuencia en
la transmisión para garantizar una conexión robusta.
En concreto, se utiliza la técnica del espectro ensanchado por saltos de frecuencia, o FHSS (frequency hopping spread spectrum). Esta técnica consiste en dividir la
banda de frecuencia de 2.402 - 2.480 GHz en 79 canales, denominados saltos, de 1
MHz cada uno, para posteriormente transmitir la señal utilizando una secuencia de
canales que sea conocido tanto por el emisor como por el receptor. Al cambiar de
canales con una frecuencia de 1600 veces por segundo, el estándar Bluetooth permite
evitar la interferencia con otras señales de radio. El estándar Bluetooth se divide en
múltiples normas IEEE 802.15.x, con x variando desde 1 hasta 4. Entre ellas cabe
destacar la IEEE 802.15.2, que recomienda una serie de prácticas para utilizar la
banda de 2.4 GHz evitando problemas de coexistencia de otro tipo de redes WPAN.
En efecto, no sólo pueden existir otras conexiónes Bluetooth, sino que la frecuencia
de la banda también es utilizada por el WiFi.
Cada dispositivo Bluetooth tiene asignada una dirección Bluetooth única de
48 bits, basada en el estándar IEEE 802.11 para redes de área local inalámbrica
(WLAN). Esta dirección se utiliza tanto para la identificación, como para sincronizar el salto de frecuencia entre los dispositivos y la generación de claves en los
procedimientos de seguridad.
2.2.2.2.
Seguridad en Bluetooth
Bluetooth dispone de diferentes mecanismos de seguridad a la hora de llevar a
cabo las transmisiones. Estos mecanismos, o modos, son los siguientes:
No seguro: en este modo, los mecanismos de seguridad se encuentran deshabilitados.
Seguridad a nivel de alcance: se establecen mecanismos de seguridad mediante
cifrados y autenticación a través de PIN y seguridad MAC. Podemos distinguir
tres mecanismos:
• Autenticación: para establecer la comunicación entre dos dispositivos, hay
que emplear una clave secreta.
• Autorización: se establecen niveles de confianza que determinan la capacidad de acceso de un dispositivo a los servicios. Esta confianza puede ser
total, parcial o nula.
• Cifrado de datos: protege la información transmitida, asegurando la confidencialidad.
14
CAPÍTULO 2. ESTADO DEL ARTE
2.2. BLUETOOTH
Seguridad a nivel de servicio: no hay codificación, PIN o claves, sino que la
seguridad se inicia tras establecerse el canal de comunicación entre dispositivos.
La seguridad que ofrece un dispositivo, y con ello, el modo de seguridad que
posee, es decisión del fabricante. Tanto los dispositivos como los servicios que ofrecen
disponen de distintos niveles de seguridad [21].
2.2.3.
Comunicación Bluetooth
Para garantizar la interoperabilidad de unos fabricantes con otros, y que los
dispositivos Bluetooth puedan descubrirse unos a otros, explorar servicios y hacer
uso de ellos, Bluetooth esboza un sistema radio, una pila de protocolos y varios
perfiles.
2.2.3.1.
Arquitectura a nivel hardware
El hardware que compone el dispositivo Bluetooth se compone de dos partes:
Dispositivo de radio: se basa en una antena cuya función es la modulación y
transmisión de la señal. Es la parte encargada de aplicar la técnica FHSS y la
que caracteriza al dispositivo en su clase (clase I, II ó III) según su potencia.
Controlador digital: entre sus tareas destacan el envı́o y recepción de datos,
determinación de conexiones, autenticación, negociación, determinación del
tipo de enlace, etc.
2.2.3.2.
Protocolos
La especificación de Bluetooth determina el conjunto de protocolos con los que
pueden operar las distintas aplicaciones. Cada una puede operar bajo una estructura
de protocolos definida por cada columna que se presentan en la figura 2.2.1, o por
un conjunto de ellas.
Los dispositivos que vayan a participar en las comunicaciones tendrán que ejecutar la misma pila de protocolos.
Los protocolos de las capas inferiores, usados por la mayorı́a de los dispositivos,
han sido desarrollados por el Grupo Bluetooth SIG. Por el contrario, en las capas
superiores la especificación es abierta, lo que permite el desarrollo de nuevos protocolos de aplicación, lo cual se traduce en el desarrollo de una gran variedad de
servicios.
15
2.2. BLUETOOTH
CAPÍTULO 2. ESTADO DEL ARTE
Figura 2.5: Pila de protocolos Bluetooth [11].
2.2.3.3.
Perfiles
El estándar Bluetooth establece una serie de perfiles para definir qué tipos de
servicio ofrece un determinado dispositivo Bluetooth. A su vez, un dispositivo puede
admitir varios perfiles. Algunos de ellos son:
GAP (Generic Access Profile): se trata del perfil de acceso genérico, base para el resto de perfiles. Define los procedimientos generales para establecer la
comunicación entre dos dispositivos: descubrimiento, gestión, configuración, y
seguridad.
SDAP (Service Discovery Application Profile): define los procedimientos necesarios para que un dispositivo Bluetooth descubra los servicios registrados en
otro dispositivo Bluetooth y reciba la información necesaria asociada a dichos
servicios [17].
SPP (Serial Port Profile): el perfil de puerto serie define cómo configurar puertos serie virtuales y conectar dos dispositivos entre ellos. Es decir, emula una
lı́nea serie y provee una interfaz de reemplazo de comunicaciones basadas en
RS-232 (conexión cableada).
GOEP (Generic Object Exchange Profile): el perfil genérico de intercambio de
objetos está basado en OBEX, un perfil abstracto que se utiliza para transferir
objetos binarios de un dispositivo a otro.
Existen numerosos perfiles además de los anteriores, relacionados con audio y
vı́deo (A2DP, AVRCP), imagen (BIP), telefonı́a (CTP), etc. Pueden consultarse en
bibliografı́a especı́fica [10].
16
CAPÍTULO 2. ESTADO DEL ARTE
2.2.3.4.
2.2. BLUETOOTH
Caracterı́sticas de funcionamiento
El estándar Bluetooth se basa en el modo de operación maestro/esclavo. La
diferencia entre ambos es que un esclavo únicamente puede contectarse a un maestro,
mientras que un maestro puede conectarse a varios esclavos, hasta un máximo de
7, o 255 si el dispositivo está en modo espera. Además el maestro puede permitir
a dos esclavos conectarse entre sı́, actuando como un intermediario que controla las
transferencias de datos en ese caso.
Figura 2.6: Conexiones maestro/esclavo [15].
Habitualmente también incluyen un PIN de conexión que, como se comentó en
el apartado referente a la seguridad, supone una medida de seguridad.
Se denomina piconet a la red formada por un maestro y todos los esclavos
asociados, denominados puntos de acceso. Poseen una dirección lógica de 3 bits, con
lo que el máximo de dispositivos interconectados es de 8. Los dispositivos en modo
espera se sincronizan, pero no poseen su propia dirección dentro de la piconet.
Dos piconets pueden conectarse entre sı́ cuando un dispositivo actúa como enlace. De este modo se forma una red más amplia, llamada scatternet.
Figura 2.7: Scatternet formado por dos piconets [12].
17
2.2. BLUETOOTH
2.2.3.5.
CAPÍTULO 2. ESTADO DEL ARTE
Pasos de la comunicación
La seguridad que puede exigirse a la comunicación por Bluetooth implica que
el procedimiento sea relativamente complicado:
1. Modo pasivo: en condiciones normales, un dispositivo funciona en modo pasivo,
en el cual, permanece a la escucha de la red.
2. Solicitud: es la fase inicial en el establecimiento de la conexión. El maestro
envı́a una solicitud a los puntos de acceso (dispositivos en su rango), los cuales
responden con su dirección.
3. Paginación: ante las direcciones recibidas, el maestro elige una y se sincroniza
con el punto de acceso que la ha enviado, mediante la sincronización de los
relojes y frecuencia de ambos.
4. Descubrimiento del servicio: en este punto se ha creado un enlace entre el maestro y el punto de acceso. El maestro entra en esta fase mediante el protocolo
SDP (figura 2.5).
5. Creación de un canal: tras el descubrimiento del servicio, el maestro crea un
canal de comunicación mediante el protocolo L2CAP (figura 2.5). Se puede
crear un canal adicional para proporcionar un puerto serie virtual (a través
del ya mencionado perfil SPP).
6. Emparejamiento mediante PIN: si el punto de acceso incluye un número de
información personal, o PIN, se dice que posee un mecanismo de seguridad
llamado emparejamiento. Esto restringe el acceso únicamente a los usuarios
autorizados, de modo que la piconet esté segura. El punto de acceso le envı́a la
solicitud de emparejamiento al maestro, algo que habitualmente resulta en la
petición al usuario del PIN. La conexión se lleva a cabo si el PIN introducido
es correcto.
7. Utilización de la red: cuando el emparejamiento se activa, el dispositivo maestro puede utilizar el canal de comunicación establecido.
2.2.4.
Versiones
Al hablar de las diferentes tasas de transmisión de datos en la tecnologı́a Bluetooth, se ha puesto de manifiesto la existencia de diferentes versiones en esta tecnologı́a, que han ido siendo implementadas desde que esta tecnologı́a fue creada. Se
pueden destacar tres lı́neas generales que rigen la evolución de las versiones Bluetooth: reducción del consumo de energı́a, mejoras en la velocidad de transferencia y
mejoras en la seguridad.
18
CAPÍTULO 2. ESTADO DEL ARTE
2.2. BLUETOOTH
Versión 1.1
El origen de Bluetooth se remonta a un estudio llevado a cabo por Ericsson
que pretendı́a investigar la viabilidad de una interfaz de bajo coste para la conexión
entre dispositivos vı́a radio. El resultado fue un enlace de corto alcance llamado MC
link, que abrió un abanico de posibilidades en cuanto a sus potenciales aplicaciones.
Versión 1.2
Esta versión se caracteriza por introducir la compatibilidad con la tecnologı́a
WiFi en la banda de los 2.4 GHz, sin interferencias. Esto es posible mediante la técnica FHSS ya comentada, que por otra parte permite una transmisión más eficiente
y un cifrado más seguro. Cabe destacar que esta versión provee una comunicación
más rápida entre dispositivos, y ofrece otras funcionalidades, como por ejemplo la
Voice Quality - Enhanced Voice Processing, que combina una mejora en la calidad
de voz y la reducción de ruido ambiente.
Versiones 2.0 y 2.1
La caracterı́stica fundamental la versión 2.0 es la incorporación de la técnica
Enhanced Data Rate, o EDR, que permite un aumento en la velocidad de transmisión
hasta los 3 Mbps.
Si bien su versión predecesora habı́a logrado un aumento en cuanto a velocidad, la versión 2.1 introduce mejoras en el consumo energético, llegando a reducirlo
hasta cinco veces. Además simplifica los pasos para establecer la conexión entre
dispositivos.
Versiones 3.0 y 4.0
Se persigue la idea de que Bluetooth y WiFi puedan trabajar juntas, para lo
cual es necesario incrementar la velocidad en Bluetooth. Es la versión 3.0 la que la
aumenta hasta los 24 Mbps.
En la última versión de la tecnologı́a Bluetooth, la 4.0, se ha disminuido el
consumo de energı́a y se ha ampliado la gama de aplicaciones. Ası́, se ha incorporado
a dispositivos como por ejemplo los smartwatches. Por último, destacar que se ha
mejorado notablemente la seguridad mediante la introducción de la encriptación
AES-1284 .
4
El esqumema de cifado por bloques, o AES, es uno de los algoritmos más populares en cripotgrafı́a simétrica.
19
2.3. COMPARATIVA
2.3.
CAPÍTULO 2. ESTADO DEL ARTE
Comparativa
Tanto NFC como Bluetooth han sido concebidas con el objetivo de poder establecer comunicaciones inalámbricas entre dispositivos. Una vez se han expuesto las
caracterı́sticas de ambas tecnologı́as, se puede presentar una comparativa entre las
principales:
NFC
• Tiene un alcance máximo
de 20 cm.
Bluetooth
• El alcance depende de la
clase, siendo el máximo de decenas de metros (clase I).
• Trabaja en una frecuencia
de 13.56 MHz.
• La frecuencia de operación
se sitúa en los 2.4 GHz.
• Tiene una tasa de transmi- • La velocidad de transmisión menor, de 424 kbps como sión, dependiendo de la vermáximo.
sión, va desde 1 Mbps hasta
24 Mbps.
• No es posible crear una red
• Se pueden crear rede dispositivos, la conexión es des WPAN entre varios
punto-a-punto.
dispositivos.
• El establecimiento de la • El tiempo es del orden de
conexión es más rápido que los segundos.
en Bluetooth, del orden de las
décimas de segundo.
• La potencia requerida es • La potencia es más elevamenor.
da, y depende de la clase del
dispositivo.
Tabla 2.3: Comparativa entre las principales caracterı́sticas de NFC y Bluetooth.
El análisis de la sección permite concluir que NFC cuenta con un menor rango
de alcance, pero a su vez requiere un tiempo menor para establecer la comunicación.
Por otra parte, Bluetooth cuenta con unos sistemas de seguridad más férreos y con
una mayor velocidad de transmisión [9].
Teniendo en cuenta las caracterı́sticas, y con ellas, las ventajas e inconvenientes
de cada tecnologı́a, se puede establecer cuál es la apropiada para una determinada
aplicación.
20
Capı́tulo 3
PLATAFORMAS DE
DESARROLLO
Una vez expuestos los detalles de las tecnologı́as en las que se basará el sistema, se puede subir un nivel y profundizar en las plataformas de desarrollo que nos
permitirán la implementación de los módulos.
Recuérdese que el módulo del lado del usuario consiste en un dispositivo Android
y una aplicación que permita al personal del establecimiento tanto llevar a cabo
tareas de gestión como activar y atender al segundo módulo. Estará por tanto basado
en Android, primera plataforma de desarrollo que se presenta en el presente capı́tulo.
De igual modo se recuerda que el segundo módulo consiste en un lector, interfaz
de cara a los residentes. Este módulo estará gobernado por una placa Arduino, siendo
ésta la segunda plataforma de desarrollo que se exponga.
3.1.
3.1.1.
Android
Introducción
Durante los últimos años el sector de la telefonı́a móvil ha evolucionado de
manera exponencial. Esto ha desembocado en la aparición de dispositivos como
o
smartphones y tablets. Ha sido necesario implementar sistemas operativos que gestionen estos ordenadores de bolsillo.
Una plataforma de desarrollo que satisface esta necesidad es Android. Se trata
de un sistema operativo basado en Linux que se lanzó por primera vez en 2008 [20].
Desarrollado por Android Inc., pertenece a la Open Handset Alliance, que engloba
21
3.1. ANDROID
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
a 84 empresas de fabricantes y desarrolladores tanto de hardware como de software,
entre los que destacan Google, Samsung, HTC, LG e Intel.
Figura 3.1: Andy, logotipo de Android.
Se trata de una plataforma de código abierto, gracias a lo cual es sencillo programar, implementar y distribuir aplicaciones mediante Google Play1 , sin restricciones.
Además de ser de código abierto, hay varios motivos por los cuales cada vez más
desarrolladores se decantan por este sistema operativo:
Variedad en hardware: podemos encontrar en el mercado dispositivos de todas
las gamas y precios, con lo que Android se postula como una plataforma accesible a todos. Además no está diseñado exclusivamente para su uso en teléfonos
y tablets, sino para dispositivos de otra ı́ndole, con gran variedad de pantalla, memoria, entradas/salidas, etc. Esta caracterı́stica, aunque es ventajosa,
supone un esfuerzo adicional al programador.
Portabilidad: al estar desarrollado en Java, las aplicaciones pueden ser ejecutadas en cualquier tipo de dispositivo que cuente con un intérprete.
Servicios: Android cuenta con gran cantidad de servicios incorporados como
la localización por GPS y redes, bases de datos con SQL, reconocimiento y
sı́ntesis de voz, navegador, multimedia, etc.
Seguridad: hereda de Linux la ejecución aislada en sandbox 2 , además de disponer de una serie de permisos que limitan su rango de actuación.
Optimización: la implementación de Google de la máquina virtual Dalvik, supone un optimizado para baja potencia y poca memoria.
1
Google Play: es el distribuidor oficial de aplicaciones para Android.
Sandbox: cada aplicación en Android se ejecuta de manera independiente, teniendo acceso
exclusivamente a sus propios recursos (por ejemplo en cuanto a hardware).
2
22
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
3.1. ANDROID
Otras caracterı́sticas: alta calidad de gráficos (animaciones, gráficos 3D, OpenGL...),
de sonido (incorporación de códecs), arquitectura basada en XML, filosofı́a de
dispositivo siempre conectado a Internet, etc.
El principal competidor de Android es Apple, con su sistema operativo iOS. La
competencia entre ambos beneficia al usuario al redundar en una constante mejora
y optimización de los sistemas.
Una cuestión habitual en la población es qué sistema es mejor. La realidad es que
no se pueden comparar: se trata de sistemas diseñados de forma distinta para plataformas distinta. Apple desarrolla hardware y software, con lo que la compatibilidad
entre sus dispositivos es inigualable. Por otro lado, el desarrollador se encuentra más
limitado en cuanto a la compatibilidad con otras plataformas, y con restricciones como la comprobación de su aplicación antes de su distribución, ası́ como una cuota
anual. Sin embargo, como se mencionó al principio de la sección, Android ofrece un
código totalmente abierto, con lo que el desarrollador puede crear aplicaciones de
cualquier tipo y que accedan a todas las funcionalidades del dispositivo, solicitando
los permisos pertinentes.
Las caracterı́sticas expuestas en este epı́grafe justifican el uso de Android como
plataforma de desarrollo para la implementación de la aplicación.
3.1.2.
Versiones
Las versiones de Android se caracterizan por el nombre de un postre en inglés.
Además de un orden cronológico, también siguen un orden alfabético. Ası́, desde la
primera versión lanzada, versión 1.0 Apple pie, a dı́a de hoy (20 de junio de 2016),
la versión más actual es la versión 6.0 Marshmallow.
Cada nueva versión, además de corregir errores de las versiones anteriores, introduce un gran número de novedades que pueden consultarse si se desea [20]. Se
comentarán las más relevantes:
Apple Pie 1.0: primera versión de Android, aunque no llegó a utilizarse
comercialmente.
Banana Bread 1.1: se trata de una versión que se empleó para corregir los
errores de la primera.
Cupcake 1.5: incorpora un teclado integrado e introduce los widgets.
Donut 1.6: permite la adaptación a nuevos tipos de pantalla mediante cambios
de resolución.
Eclair 2.0: proporciona APIs para manejar Bluetooth e introduce el soporte
a HTML5.
23
3.1. ANDROID
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
Froyo 2.2: soporta flash 10.1 y permite el uso de almacenamiento externo.
Gingerbread 2.3: incorpora soporte para la tecnologı́a NFC. Aparece el
multi-touch y el gestor de aplicaciones, que redundará en un menor consumo energético.
Honeycomb 3.0: es especı́fico para tablets, con lo que introduce mejoras en
cuanto a gráficos y adaptabilidad de pantallas.
Ice Cream Sandwich 4.0: presenta un diseño más moderno con pantallas
de bloqueo mejoradas y gestores de datos.
Jelly Bean 4.1 - 4.3: soporte para Bluetooth 4.0, OpenGL ES 3.0, nuevos
idiomas, mejoras en seguridad. Soporte para Chromecast.
KitKat 4.4: visualización en pantalla completa, implementación de la máquina virtual ART para desarrolladores, aumento en la cantidad de dispositivos
sincronizados por Bluetooth.
Lollipop 5.0 - 5.1: aparece Material Design, un nuevo estilo de diseño. Incluye
mejoras en las notificaciones y en la duración de la baterı́a.
Marshmallow 6.0: incluye un administrador de permisos y soporte para huellas dactilares. Incorpora Android Pay y la posibilidad de restaurar datos y
aplicaciones al cambiar de dispositivo o aplicar un factory reset.
La página oficial de Android Developers3 ofrece información y estadı́sticas actuales, como por ejemplo los datos relativos a la distribución de las versiones en
los dispositivos[5], que se presentan en la figura 3.2 y en la tabla 3.1, aunque las
versiones anteriores a Froyo y versiones cuya distribución no alcanza el 0.1 % no se
muestran.
Versión
Nombre
2.2
Froyo
2.3
Gingerbread
4.0
Ice Cream Sandwich
4.1 - 4.3
Jelly Bean
4.4
KitKat
5.0 - 5.1
Lollipop
6.0
Marshmallow
API Distribución
8
0.1 %
10
2%
15
1.9 %
16-18
18.9 %
19
31.6 %
21-22
35.4 %
23
10.1 %
Tabla 3.1: Distribución de versiones Android en los dispositivos (20 de junio de 2016)
3
Android
index.html
Dashboards:
https://developer.android.com/about/dashboards/
24
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
3.1. ANDROID
Figura 3.2: Gráfico de la distribución de las versiones de Android en los dispositivos
(20 de junio de 2016)
La figura 3.3 muestra las distribuciones globales de las distintas versiones de
Android desde 2009 hasta 2015.
Figura 3.3: Distribución global de las versiones de Android durante su historia.
25
3.1. ANDROID
3.1.3.
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
APIs
Las interfaces de programación de aplicaciones, o APIs, son las capas que permiten al desarrollador interactuar cómodamente con la base del sistema Android. Se
componen de diversos elementos: paquetes, clases, atributos XML, Intents, etc [19].
En cada versión lanzada de Android se incluyen cambios y actualizaciones de
la API. Dichas modificaciones siempre se llevan a cabo de manera que sigan siendo
compatibles con las anteriores. Por ello, cuando se actualiza una API se introducen nuevas funcionalidades que pueden reemplazar a otras ya existentes, pero sin
borrarlas: se dejan como obsoletas, pero con la posibilidad de seguir empleándolas.
Por este motivo, cada versión de Android soporta un nivel de API concreto a la
perfección, y todos los anteriores prácticamente sin ningún problema. La tabla 3.1
muestra el nivel de API que incluyen las versiones de Android.
Cabe destacar la biblioteca de soporte (Support Library) llegados a este punto.
Esta biblioteca permite utilizar algunas de las APIs más recientes de Android en una
aplicación, aunque dicha aplicación se ejecute en versiones antiguas. Como ejemplo,
cabe destacar los Fragments, que se incluyeron en Honeycomb, con API 11, pero
gracias a la Support Library, pueden utilizarse a partir de la versión 1.6 con API 4.
Para elegir el nivel de API que soportará una determinada aplicación, se han de
tener en cuenta diferentes aspectos. Por una parte, parece razonable escoger aquél
nivel mı́nimo que incluya los elementos necesarios para la ejecución correcta de la
aplicación, ya que niveles de API superiores también la permitirán. Por otra parte,
si el nivel mı́nimo es demasiado bajo, debido a que los requisitos estén incluidos
desde APIs más antiguas, no conviene usarlas debido a que gran cantidad de rutinas
estarán obsoletas y no se estarı́an aprovechando las mejoras introducidas en nuevas
versiones. Además hay que tener en cuenta el público al que va dirigido debido al
tipo de terminales a los que ofrezcamos la aplicación. Se trata de buscar un consenso
entre el público al que irá dirigida y los requisitos necesarios.
Las versiones que cuentan con API 16 en adelante representan la mayorı́a de
los dispositivos actuales (97.8 %). Además cuentan con todos los recursos necesarios
para el sistema propuesto, con lo cual dicha API será la elegida para la implementación del proyecto.
26
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
3.1.4.
3.1. ANDROID
Arquitectura
La arquitectura del sistema Android se basa en un modelo de 4 capas que se
detallan a continuación, y que pueden observarse en la figura 3.4.
Figura 3.4: Arquitectura del sistema Android[20].
Capa 1: Núcleo Linux: es la única capa dependiente del hardware, permitiendo
a las restantes capas abstraerse del mismo. Proporciona servicios como la seguridad, la gestión de la memoria, el multiproceso, el soporte de controladores
(pantalla, cámara, Bluetooth...), etc.
Capa 2: Bibliotecas nativas: Android incluye un conjunto de bibliotecas en
C/C++ empleadas por varios componentes del sistema, muchas de ellas de
código abierto. Algunos ejemplos son System C Library, OpenGL, SQLite,
WebKit, FreeType, etc.
Dentro de esta capa se encuentra el entorno de ejecución, o Runtime de Android. Se trata de un conjunto de bibliotecas base que proporcionan la mayor
parte de las funciones disponibles de las bibliotecas de Java. Dadas las limitaciones de los dispositivos, en lugar de utilizar una máquina virtual estándar,
Google creó la máquina virtual Dalvik para responder a estas limitaciones y,
a partir de Android 5.0, dicha máquina virtual fue reemplazada por ART, que
incluye mejoras en el rendimiento y el consumo de memoria, entre otras.
27
3.1. ANDROID
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
Capa 3: Framework: el marco de trabajo de aplicaciones es accesible a los desarrolladores. La arquitectura está diseñada para simplificar la reutilización de
componentes. Cualquier aplicación puede publicar sus capacidades, y cualquier
otra aplicación puede hacer uso de esas capacidades, siempre sujetos a reglas
de seguridad.
Capa 4: Aplicaciones: está formada por el conjunto de aplicaciones instaladas. Normalmente están escritas en Java, y se recomienda su ejecución en la
máquina virtual Dalvik para asegurar la seguridad. Algunas aplicaciones base
incluyen un cliente de correo electrónico, programa de SMS, calendario, mapas,
navegador, contactos, etc.
3.1.5.
Entorno de desarrollo: Android Studio
El desarrollo de la parte relacionada con Android en este trabajo se ha realizado
mediante Android Studio4 . Se trata de un entorno de desarrollo basado en IntelliJ
IDEA5 cuya instalación de Android Studio incluye:
El entorno de desarrollo (editor de código) propiamente dicho.
La última versión del Android SDK (Sofware Development Kit).
Emulador para probar una aplicación en diferente dispositivos virtuales.
El SDK proporciona las bibliotecas de cada API, ası́ como herramientas de
desarrollo necesarias para construir, testear y depurar aplicaciones para Android.
Los elementos que están incluidos en la instalación de Android Studio son los más
actualizados. Para probar las aplicaciones desarrolladas en versiones anteriores de
Android, se ha de descargar e instalar el SDK correspondiente a través del SDK
Manager de Android Studio (ver figura 3.5). Además se ha de contar con el Java
Development Kit (JDK7)6 .
Creación de un proyecto en Android Studio
Al crear un nuevo proyecto en Android Studio, en primer lugar se ha de introducir el nombre de la aplicación que se va a desarrollar ası́ como el nombre de la
compañı́a y del paquete.
El nombre del paquete usa una convención llamada reverse DNS, por la cual
se invierte los nombres de la organización y de la aplicación, aplicando además
4
Android Studio: http://developer.android.com/intl/es/sdk/index.html
IntelliJ IDEA: https://www.jetbrains.com/idea/
6
JDK7: http://www.oracle.com
5
28
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
3.1. ANDROID
Figura 3.5: Android SDK Manager.
identificadores. Esto se realiza para que los paquetes sean únicos y distinguibles de
otros tanto en un dispositivo como en Google Play.
A continuación Android Studio solicita al desarrollador ciertos parámetros como
la API, diseño de la activity principal, etc. Tras completar este proceso inicial, el
proyecto estará creado, y con él, la clase (fichero Java) y el layout (fichero XML) de
la activity principal.
Por una parte, la clase permite programar la lógica del comportamiento de la
activity. Además en ella se especifica qué layout ha de mostrar dicha activity, y por
tanto, permite implementar el comportamiento de los diferentes widgets incluidos
en el layout.
Por otra parte, el layout de una activity es su aspecto gráfico, esto es, cómo se
verá en la pantalla del dispositivo cuando la aplicación se esté ejecutando. Además
de con el propio editor de código, los ficheros XML que implementan el diseño gráfico
de las activities se pueden crear o editar de manera gráfica mediante el editor de
diseño que incluye el propio Android Studio.
La clase y el layout creados para la activity principal tras crear un proyecto en
Android Studio pueden observarse, respectivamente, en las figuras 3.6 y 3.7.
En la parte izquierda de android Studio aparece la estructura del proyecto y de
la aplicación, que se detalla en el siguiente epı́grafe.
29
3.1. ANDROID
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
Figura 3.6: Clase de la activity principal.
Figura 3.7: Layout de la activity principal.
30
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
3.1.6.
Aplicaciones en Android
3.1.6.1.
Estructura del proyecto
3.1. ANDROID
Todas las aplicaciones, desde la más simple hasta la más compleja, se estructuran del mismo modo. Esta estructura se genera automáticamente con la creación
del proyecto en cualquier entorno de dearrollo que se utilice. La estructura de una
aplicación que proporciona Android Studio consta de diferentes directorios:
gradle: es una herramienta que automatiza la construcción del proyecto. La sintaxis es similar a Java, y permite realizar tareas de compilación, empaquetado
y testing.
External Libraries: como su nombre indica, se trata de bibliotecas externas
incluidas en el proyecto.
idea: es un entorno de desarrollo integrado en Java.
app: contiene todos los archivos relacionados con un proyecto, por lo que conviene profundizar más en ella. En su interior se encuentran los siguientes subdirectorios:
• build : contiene códigos generados por Android Studio cada vez que se
realiza la compilación del proyecto.
• libs: contiene las bibliotecas Java que utiliza una determinada aplicación.
La referencia a dichas bibliotecas se realiza en el fichero build.gradle (se
verá esto al exponer la parte relativa al software de este trabajo).
• src: contiene la información más importante, la que pone de manifiesto
la estructura de la aplicación.
3.1.6.2.
Estructura de la aplicación
El directorio src contiene a su vez más subdirectorios a considerar. Son los
siguientes:
java: contiene las clases, archivos .java, en los cuales se implementa toda la
codificación lógica de la aplicación.
res: incluye los archivos como imágenes, strings, layouts, estilos, menús o interfaces gráficas, cada uno en un subdirectorio dentro de res.
Android Manifest: se trata del documento más importante de la aplicación. Su
función es describir la implementación de la misma. Se profundizará más en el
capı́tulo relativo al software.
31
3.1. ANDROID
3.1.6.3.
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
Activities
Los archivos más elementales de una aplicación Android son las activities. Una
activity es una entidad de aplicación que representa cada una de las pantallas de la
misma. El usuario interactúa únicamente con una activity, pero puede navegar entre
ellas. Android almacena las activities en una pila cuyo orden indica el historial de
navegación.
En efecto, es el propio sistema Android quien se encarga de pausar, parar o
destruir una activity según las necesidades de recursos del dispositivo. Para ello se
basa en el estado de las activities, que permite identificar qué activities no están
siendo utilizadas y pueden destruirse para liberar recursos. Dichos estados son:
Activa (running): la activity está encima de la pila, con lo cual es la activity
visible. Se dice que tiene el foco (focused ).
Visible (paused ): la activity está pausada: es visible pero no tiene el foco. Este
estado se alcanza cuando nuevas activities llegan a la pila, cuando se pulsa el
botón home, etc. En definitiva, cuando se puede volver a ella sin necesidad de
que para ello tenga que volver a crearse.
Parada (stopped ): la activity no está visible. En este momento Android puede
destruirla si necesita recursos, con lo que es tarea del programador guardar los
datos que no deban perderse.
Destruida (destroyed ): la activity termina. Se alcanza al invocarse el método
finish(), o cuando Android la mata.
Los diferentes estados que puede presentar una activity durante su existencia
y el modo en que se relacionan se conoce como el ciclo de vida de la activity. La
documentación oficial de Android Developers ofrece el esquema que aparece en la
figura 3.8.
Los métodos que aparecen en el ciclo de vida de una activity son llamados por
Android, y son los siguientes:
onCreate(): se dispara cuando la activity es creada. En él se inicializa la acitivity, aunque exiten métodos que permiten que se cree manteniendo el estado
que tenı́a la última vez que existió en lugar de inicializarse.
onStart(): carga la activity en el dispositivo.
onResume(): muestra la activity en la pantalla permitiendo al usuario interactuar con ella.
onPause(): se llama cuando el sistema lanza una nueva activity, cuando el
usuario pulsa el botón home o bloque el dispositivo, etc.
32
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
3.1. ANDROID
Figura 3.8: Ciclo de vida de una activity.
onStop(): cuando se llama, la activity deja de ser visible. A partir de este
momento deja de haber garantı́a de que la activity siga estando accesible sin
necesidad de crearla de nuevo.
onRestart(): al ser llamado la activity va a volver a ser cargada después de
haber pasado por onStop().
onDestroy(): destruye la activity. Es llamado por el método finish() o cuando
el usuario pulsa el botón back. Aunque por lo dicho anteriormente, puede ser
llamado por Android si el dispositivo está escaso de recursos.
33
3.2. ARDUINO
3.2.
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
Arduino
El módulo lector se pretende diseñar desde cero, y se fundamentará en una placa
Arduino. Frente a otras opciones parecidas como Raspberry Pi, más complejas como
un PLC, o ya existentes como lectores comerciales, se ha escogido Arduino debido
a que el desarrollo del módulo lector es perfectamente abordable con ella, y supone
la profundización en una herramienta presentada en el Grado.
3.2.1.
Introducción
Arduino es una plataforma de hardware libre basada en una placa gobernada por
un microcontrolador Atmel. Se puede adquirir comercialmente o se puede fabricar de
modo casero mediante el empleo del microcontrolador apropiado. La placa comercial
conecta el microcontrolador con una serie de entradas/salidas y un puerto USB que
permite su alimentación y programación.
Se trata de una plataforma que proporciona flexibilidad para realizar infinidad
de proyectos al permitir una conexión del mundo fı́sico con el virtual a través de
entradas y salidas tanto digitales como analógicas.
Ofrece una serie de ventajas que han llevado a la elección de esta plataforma
para el desarrollo del sistema. Como ya se ha introducido, se trata de una plataforma
económica y abierta. Existe una amplia gama de versiones y accesorios compatibles,
algo que ha hecho que esté muy estandarizada. Con ello se han desarrollado infinidad
de bibliotecas de libre distribución que permiten la comunicación con hardware de
terceros. A las caracterı́sticas anteriores cabe destacar la extensa gama de modelos
disponibles.
3.2.2.
Placas Arduino
Desde su nacimiento en 2005 [4], las innovaciones no han dejado de estar presentes en Arduino. Las distintas placas7 que están disponibles en el mercado son las
que se exponen, junto con sus especificaciones, en la figura 3.9.
La arquitectura depende de la placa considerada. Por este motivo, se detallará posteriormente, una vez se exponga el hardware empleado, y por tanto, la
placa utilizada.
7
Pueden consultarse más caracterı́sticas en la web oficial: https://www.arduino.cc/en/
Main/Boards
34
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
3.2. ARDUINO
Figura 3.9: Comparativa de las placas oficiales (cortesı́a de Arduino [1])
35
3.2. ARDUINO
3.2.3.
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
Entorno de desarrollo: Arduino IDE
El desarrollo del firmware que se pretende cargar en la placa, se puede realizar
mediante Arduino IDE, que es el entorno de desarrollo oficial. A su vez, se encarga
de la correcta conexión y comunicación entre la placa y el ordenador.
Figura 3.10: Entorno de desarrollo de Arduino
Como puede observarse en la figura 3.10, el IDE de Arduino se compone de:
Barras de herramientas (1), que ofrecen diferentes funciones.
Un editor de texto (2), para implementar el código del firmware.
Un área de mensajes (3), que permite al usuario tener constancia de los posibles
problemas de comunicación, errores de compilación, procesos en ejecución, etc.
Un monitor serie (4), que no es sino una consola de texto que permite al usuario
comunicarse con la placa.
36
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
3.2. ARDUINO
El IDE de Arduino deriva de Processing 8 , del cual hereda el término sketch (se
profundizará en la estructura de un sketch cuando se detalle el firmware del módulo
lector). En Processing se considera cada código como un boceto, y de ahı́ que el
código escrito en el IDE de Arduino suela denominarse sketch.
Por su importancia cabe destacar el monitor serie, o monitor serial. Permite ver
la comunicación establecida por el puerto serie entre la placa Arduino y el ordenador
durante la ejecución del sketch. Permite tanto la lectura de los mensajes que aparecen
en la consola como el envı́o comandos a través de la barra de escritura.
Esto permite, por ejemplo, el envı́o de comandos AT9 a shields o módulos que se
conecten a la placa Arduino. También permite el establecimiento de diferentes tasas
de baudios, o baudrates, que marcan las unidades de señal transmitidas por segundo.
Este valor ha de coincidir en las dos partes que estén formando una conexión para
que ésta sea legible. De otro modo, la información ofrecida por el monitor serial no
podrá ser entendida.
Figura 3.11: Valores posibles para el baudrate del monitor serial del IDE de Arduino
La comunicación serie no es exclusivamente realizable a través del monitor serial
del IDE de Arduino, sino que puede llevarse a cabo mediante software de terceros,
o incluso a través de software desarrollado por el propio usuario.
En efecto, las placas Arduino desdoblan el canal de transmisión serie para llevarlo al puerto USB. Con el controlador apropiado, la señal puede ser reconocida
por el ordenador. Este controlador generalmente no supone un problema para el
usuario, pues la instalación del IDE de Arduino lo incluye, de modo que la placa se
detectará como un puerto COM adicional, pudiendo controlarse a través de software
apropiado. Es necesario identificar dicho puerto, pues para cargar un sketch en la
placa es necesario especificar tanto el modelo de placa como el puerto por el que se
conecta.
8
Processing: lenguaje de programación orientado a diseñadores, especialmente pensado para proyectos multimedia. Para más información se puede acudir a la web oficial: https://
processing.org/
9
Comandos AT: son comandos de atención, a través de los cuales se establece la comunicación
directa con un dispositivo mediante la petición y la recepción de una respuesta.
37
3.2. ARDUINO
CAPÍTULO 3. PLATAFORMAS DE DESARROLLO
38
Capı́tulo 4
HARDWARE
En este capı́tulo se exponen las caracterı́sticas principales de los componentes
que se utilizan para la construcción del módulo lector. Pueden encontrarse descripciones e informaciones más detalladas en los datasheets de los componentes que a
continuación se presentan.
4.1.
4.1.1.
Componentes
Arduino
Durante el desarrollo del módulo lector se han empleado dos placas Arduino:
la placa Arduino UNO y la placa Arduino NANO, pasándose a presentar las caracterı́sticas principales de ambos tipos.
4.1.1.1.
Arduino UNO
La placa Arduino UNO se ha empleado durante el montaje inicial del módulo,
durante las fases de integración de todos los componentes, y de primeras pruebas de
verificación del correcto funcionamiento del módulo.
El uso de esta placa, que es una de las más conocidas y utilizadas para introducirse en el entorno de este microcontrolador, sigue la estela de su uso durante
asignaturas más tempranas en la carrera, en las cuales despertó el interés del autor,
quien decidió darle un uso más allá de los ejemplos elementales que se mostraron en
las asignaturas de la carrera. Ası́ pues, esta placa forma parte de los primeros pasos
de este proyecto.
39
4.1. COMPONENTES
CAPÍTULO 4. HARDWARE
Figura 4.1: Arduino UNO R3 (cortesı́a de Arduino)
Sus caracterı́sticas principales son:
Microcontrolador
Tensión de operación
Tensión de entrada recomendada
Pines digitales
Pines analógicos de entrada
Corriente en pines E/S
Corriente en pin 3.3 V
Memoria Flash
SRAM
EEPROM
Frecuencia de reloj
ATmega328
5V
7-12 V
14 (6 disponen de PWM)
6
20 mA
50 mA
32 kB (0.5kB empleados por el bootloader)
2 kB
1 kB
16 MHz
Tabla 4.1: Resumen de caracterı́sticas de la Arduino UNO R3 (cortesı́a de Arduino)
Dispone además de otras caracterı́sticas como puerto USB regular, I2C, UART...
que junto con el resto de información relativa a la placa pueden encontrarse en la
página web de Arduino.
40
CAPÍTULO 4. HARDWARE
4.1.1.2.
4.1. COMPONENTES
Arduino NANO
El factor tamaño del módulo lector lleva a la búsqueda de alternativas de montaje de un menor tamaño. En esta lı́nea, se busca una placa de caracterı́sticas similares
pero de dimensiones más reducidas. Ası́ se elige la Arduino NANO para este fin, y
de cara a implementar el montaje del módulo lector en una placa de un modo más
cómodo.
Figura 4.2: Arduino NANO (cortesı́a de Arduino)
Sus caracterı́sticas principales son:
Microcontrolador
Tensión de operación
Tensión de entrada recomendada
Pines digitales
Pines analógicos de entrada
Corriente en pines E/S
Corriente en pin 3.3 V
Memoria Flash
SRAM
EEPROM
Frecuencia de reloj
ATmega168 ó ATmega328
5V
7-12 V
14 (6 disponen de PWM)
8
40 mA
50 mA
16 ó 32 kB según el microcontrolador
1 (ATmega168) ó 2 kB (ATmega328)
512 (ATmega168) ó 1 kB (ATmega328)
16 MHz
Tabla 4.2: Resumen de caracterı́sticas de la placa Arduino NANO (cortesı́a de Arduino)
También soporta comunicación I2C y SPI, y otras caracterı́sticas que pueden
consultarse en la página web oficial de Arduino.
41
4.1. COMPONENTES
4.1.2.
CAPÍTULO 4. HARDWARE
NFC
Para la elección del sensor NFC se han estudiado diferentes posibilidades, que
pueden clasificarse en dos grupos: lectores comerciales y módulos para integrar con
Arduino.
4.1.2.1.
Lectores comerciales
Los lectores comerciales presentan la ventaja de tener una mayor robustez pero
como inconvenientes destacan el precio y la baja flexibilidad a la hora de desarrollar
una aplicación con ellos, pues poseen un funcionamiento determinado de fábrica.
A continuación se presentan dos modelos de lector de este tipo:
Figura 4.3: Lector comercial con comunicación Bluetooth (cortesı́a de Sumlung).
Figura 4.4: Lector comercial con comunicación USB (cortesı́a de Emartee).
42
CAPÍTULO 4. HARDWARE
4.1. COMPONENTES
La figura 4.3 muestra un lector con comunicación por Bluetooth, y la figura 4.4
muestra un lector con comunicación USB.
El lector inalámbrico de la figura 4.3 posee un elevado coste (más de 100 ¤),
mientras que el lector plug and play es más económico pero no se adapta a las
caracterı́sticas que requiere el módulo lector planteado en este trabajo.
En efecto, se busca la comunicación inalámbrica entre los módulos lector y
recepctor, y de emplear la alternativa anterior, el módulo lector no serı́a un módulo
independiente, sino que se tendrı́a un solo módulo (tablet o smartphone) al cual se
acopları́a el lector. Ası́, requerirı́a que el personal tendrı́a que acercar el dispositivo
al cliente para que este acercara el tag.
Esto no supone una solución interesante de cara a la funcionalidad del sistema.
Existen otros lectores comerciales que están pensados para comunicación con
un ordenador a través de USB y mediante un software propio que proporciona el
proveedor junto con el lector. Esta opción se descarta pues ni se pretende emplear
un ordenador, ni se pretende usar un software de terceros, sino que se plantea un
desarrollo completo tanto a nivel hardware como a nivel software.
4.1.2.2.
Módulos compatibles con Arduino
Existen en el mercado módulos que se basan en diferentes sensores RFID-NFC
carentes de una carcasa o software propio. Suponen una mejor alternativa para el
desarrollo propio, programando el uso del sensor a placer. Hay dos grandes alternativas en este grupo: shields y módulos individuales.
Figura 4.5: Shield RFID-NFC para Arduino UNO (cortesı́a de Elecrow).
43
4.1. COMPONENTES
CAPÍTULO 4. HARDWARE
Los shields (ejemplo en la figura 4.5) son funcionales y económicos, sin embargo
se descartan puesto que no se va a emplear una Arduino UNO, que es la placa que
estas shields soportan.
La opción elegida para incluirla en el lector es el módulo basado en el sensor
pn532 que puede observarse en la figura 4.6.
Figura 4.6: Módulo lector RFID-NFC basado en el sensor pn532
Sus principales caracterı́sticas son:
Soporte I2C, SPI y HSU (UART de alta velocidad), con facilidad de cambiar
entre los modos.
Compatible con RFID, NFC y con la posibilidad de comunicación P2P.
Gran variedad de dispositivos admisibles, como tarjetas Mifare 1K y 4K o
tarjetas ISO/IEC 14443-4, por citar algunos ejemplos.
Distancia de lectura de hasta 7 cm.
Compatible con Arduino, incluyendo el sensor la biblioteca necesaria para su
correcto uso en esta plataforma.
Pequeñas dimensiones que lo hacen especialmente interesante para este proyecto.
Precio muy competitivo (se trata de la alternativa más económica).
El manual del módulo no sólo incluye las caracterı́sticas mencionadas, ası́ como
una descripción más detallada del sensor, sino también explica cómo realizar la
conexión de los pines con la placa Arduino para su uso en los diferentes modos
posibles.
44
CAPÍTULO 4. HARDWARE
4.1.3.
4.1. COMPONENTES
Bluetooth
La comunicación entre ambos módulos (lector y receptor), se ha planteado a
través de la tecnologı́a Bluetooth. Si bien el módulo receptor se trata de un dispositivo Android (tablet o smartphone), y por tanto consta de un módulo Bluetooth
propio, se necesita un módulo Bluetooth para el módulo lector.
Para elegir un módulo Bluetooth compatible con Arduino se busca una buena
combinación de caracterı́sticas como precio, distancia de alcance, documentación de
referencia, etc.
De lo anterior se decide emplear un módulo habitual en aplicaciones de Arduino
que requieren comunicación por Bluetooth: el módulo HC-05.
Figura 4.7: Módulo Bluetooth HC-05
Sus principales caracterı́sticas son:
Versión de Bluetooth 2.0
Clase II.
Velocidad de hasta 2.1 Mbps.
Antena de PCB incorporada.
Módulo montado en tarjeta con regulador de voltaje y 6 pines suministrando
acceso a VCC, GND, TXD, RXD, STATE (conectado a un led), y KEY ó EN
(dependiendo del fabricante).
Consumo de corriente: 50 mA.
Se trata de un módulo que puede actuar como maestro o esclavo y es configurable
a través de comandos AT. La forma de acceder al modo configuración depende
del modelo. Como ya se ha adelantado en las caracterı́sticas, existen dos modelos
diferentes de este módulo Bluetooth. En un modelo se dispone de un pin llamado
KEY, que dependiendo de si está a nivel alto o bajo (HIGH ó LOW) al encender el
módulo se entra en modo configurable o no. El otro modelo no dispone de dicho pin,
45
4.1. COMPONENTES
CAPÍTULO 4. HARDWARE
pues en su lugar el pin actúa como enable. Los módulos HC-05 de este tipo disponen
de un botón que dependiendo si está presionado o no al iniciar el módulo se entra o
no al modo configurable.
Puede consultarse en la bibliografı́a [15] una lista de comandos AT que pueden
emplearse con el módulo Bluetooth HC-05.
4.1.4.
Otros componentes
De cara a la viabilidad tecnológica del proyecto, bastarı́an los componentes hasta
ahora descritos. No obstante, la funcionalidad del sistema incluye la posibilidad de
ofrecer información al cliente. Para ello se hace uso de una serie de componentes que
se detallan a continuación.
4.1.4.1.
LCD
Una manera intuitiva de ofrecer información al cliente es a través de una pantalla
de cristal lı́quido (liquid-crystal display o LCD).
La opción más razonable es emplear un módulo LCD para Arduino basado en
el chip HD44780, al incluir Arduino una biblioteca para dicho chip.
Figura 4.8: Módulo LCD
46
CAPÍTULO 4. HARDWARE
4.1.4.2.
4.2. MONTAJE
LED RGB
Para indicar de una manera visual e intuitiva el estado del módulo lector (activo
o inactivo), ası́ como información de otro tipo, es conveniente disponer de un led rgb
que exprese diferentes mensajes con el color de su luz (ámbar para alerta por bajo
número de consumiciones disponibles, por ejemplo).
Figura 4.9: Módulo LED RGB
4.2.
4.2.1.
Montaje
Primer prototipo
A medida que los componentes fueron adquiridos se realizaron una serie de
pruebas para determinar su correcto funcionamiento.
Dichas pruebas fueron, en esencia, códigos de ejemplo incluidos en las bibliotecas
nativas de Arduino, o en las bibliotecas de terceros. En el primer caso encontramos
las bibliotecas LiquidCrystal y SoftwareSerial, con las que se puede comprobar el
funcionamiento individual de los módulos LCD y HC-05, respectivamente. En el
segundo caso se encuentran las bibliotecas1 PN532, PN532 I2C y NfcAdapter, que
permiten evaluar el funcionamiento del módulo lector RFID-NFC.
Por último, las pruebas realizadas al módulo led RGB no requieren de una
biblioteca especı́fica, pues el color de la luz que éste emite se consigue a través del
control de la salida de los pines analógicos o PWM a los que se conecta.
En cualquier caso, además de permitir la comprobación del buen estado y correcto funcionamiento de los módulos, estos códigos de ejemplo fueron de extraordinaria
1
Las bibliotecas necesarias para utilizar el módulo RFID-NFC se pueden descargar desde el
repositorio oficial del proveedor en GitHub: https://github.com/elechouse/PN532
47
4.2. MONTAJE
CAPÍTULO 4. HARDWARE
utilidad para comprender cómo funcionan, cómo controlarlos, y en consecuencia,
poder desarrollar sketches propios para practicar. En este sentido se desarrollaron
diferentes sketches con la filosofı́a del Hello World! para familiarizarse con los módulos, a modo de entrenamiento para el propio autor.
El siguiente paso es la integración de los módulos de manera progresiva hasta
que funcionen en conjunto.
Para esto se desarrollaron sketches que integraban los módulos por parejas.
La filosofı́a de estos sketches se basaba en que un módulo se comportaba de un
determinado modo en función de la lectura del otro módulo. De este modo, poco a
poco se llegó a la integración total de los módulos.
El carácter transitorio de este proceso y los inevitables futuros errores de montaje eléctrico y de código requerı́an que el montaje fı́sico fuese flexible y cómodo. Por
ello se recurrió al montaje temporal basado en el uso de una breadboard o protoboard.
Las siguientes imágenes muestran el primer prototipo del módulo, tanto a nivel
de diseño2 como a nivel fı́sico.
Figura 4.10: Diseño del prototipo.
2
Diseño realizado a través del software gratuito de código abierto Fritzing.
48
CAPÍTULO 4. HARDWARE
4.2. MONTAJE
Figura 4.11: Esquema del prototipo.
49
4.2. MONTAJE
CAPÍTULO 4. HARDWARE
Figura 4.12: Vista frontal del prototipo.
Figura 4.13: Vista trasera del prototipo.
50
CAPÍTULO 4. HARDWARE
4.2. MONTAJE
Figura 4.14: Vista en perspectiva del prototipo.
4.2.2.
Prototipo final
Una vez comprobado el funcionamiento de todos los componentes integrados
con el primer prototipo, se implementó el comportamiento final requerido para el
módulo lector. Este firmware es objeto de estudio de capı́tulos posteriores.
Tras comprobar de este modo que el módulo lector se comportaba tal y como
se habı́a diseñado, se desarrolló un prototipo final.
Si bien a nivel de programación los cambios son mı́nimos (fundamentalmente
alguna modificación en los pines), los cambios a nivel hardware si son considerables.
Al estar concebido el prototipo final para ser entregado al cliente, ha de perder el
carácter temporal propio del primer prototipo.
Para ello se han desarrollado:
PCB: se ha elaborado una sencilla PCB (Printed Circuit Board ) con la finalidad de reducir el tamaño del prototipo. La PCB está pensada para soldar
pines macho en los agujeros que tiene. Estos pines están agrupados por grupos
(alimentación, masa y componentes) y por componentes (LCD, led, bluetooth
y resistencias).
De este modo pueden conectarse los componentes sin más que emplear cables
jumper hembra entre dichos pines y los pines de los componentes. No obstante
pueden no soldarse pines y soldar cables directamente.
Este planteamiento se justifica por la necesidad de disponer los componentes
51
4.2. MONTAJE
CAPÍTULO 4. HARDWARE
tridimensionalmente en el módulo lector. Esta disposición espacial impide la
conexión directa de los componentes en la propia PCB.
El diseño, circuito y la placa real pueden observarse en las figuras 4.15, 4.16
y 4.17. Obsérvese cómo ha de fabricarse la PCB con el diseño en efecto espejo, puesto que el circuito ha de quedar en la capa inferior o bottom (los
componentes se colocarán en la superior o top).
Figura 4.15: Diseño de la PCB del prototipo.
Figura 4.16: Circuito buscado en la PCB.
52
CAPÍTULO 4. HARDWARE
4.2. MONTAJE
Figura 4.17: PCB fabricada en el taller del departamento de Electrónica.
Carcasa: la PCB y los componentes que forman el módulo lector se encuentran
contenidos en el interior de una carcasa diseñada por ordenador e impresa en
3D.
El diseño de la carcasa es libre, pues el cliente no ha especficado requisitos en
este sentido. Se ha diseñado una carcasa con las siguientes caracterı́sticas:
• Tamaño reducido: el módulo lector ha de ser compacto y portátil. Esto
no es una gran restricción al no ser elevado el número de componentes ni
muy grande el tamaño de los mismos:
• Zona vertical: para colocar al menos el LCD, pues es el modo más cómodo
para que el usuario vea los mensajes mostrados.
• Zona horizontal: para colocar al menos el sensor RFID-NFC, pues más
cómodo para el usuario pasar un tag sobre una superficie horizontal.
• Ranuras para los componentes: tal y como se describió anteriormente, los
componentes se dispondrán tridimensionalmente dentro de la carcasa, por
lo que se han aprovechado diferentes zonas en ella para colocar ranuras
en las que insertar los componentes.
Teniendo en cuenta las caracterı́sticas anteriores, se ha diseñado una carcasa
que consta de 4 partes:
• Base: superficie inferior del módulo lector.
• Parte trasera: contiene el soporte para el módulo Bluetooth HC-05.
• Cubierta: es la que contiene las zonas vertical y horizontal para el LCD
y el sensor RFID-NFC respectivamente, y ranuras para la inserción de
dichos módulos. Además cuenta con un agujero en la zona horizontal
53
4.2. MONTAJE
CAPÍTULO 4. HARDWARE
para posicionar el LED y cajeados en los que se inserta un embellecedor y la PCB. Incluye un agujero en el lateral por donde va el cable de
alimentación del circuito.
Se ha dividido en 2 partes para facilitar la impresión (la impresión de
una sola pieza requerirı́a un aporte extra considerable de material para
soportes auxiliares).
• Embellecedor: permite identificar visualmente la zona por la que el usuario ha de pasar el tag. Se ha extruido además en esta pieza el logo de la
empresa.
Las siguientes figuras muestran la carcasa diseñada:
Figura 4.18: Base de la carcasa.
Figura 4.19: Embellecedor de la carcasa.
54
CAPÍTULO 4. HARDWARE
4.2. MONTAJE
(a) Parte principal.
(b) Lateral auxiliar.
Figura 4.20: Cubierta de la carcasa.
Figura 4.21: Parte trasera de la carcasa.
55
4.2. MONTAJE
CAPÍTULO 4. HARDWARE
Las siguientes imágenes muestran el proceso de ensamblado del módulo lector,
una vez se ha impreso la carcasa y se ha efectuado el montaje del circuito:
Figura 4.22: Módulo lector: carcasa y circuito electrónico.
Figura 4.23: Módulo lector: encapsulación del circuito en la carcasa.
56
CAPÍTULO 4. HARDWARE
4.2. MONTAJE
Figura 4.24: Módulo lector ensamblado y listo para su uso.
57
4.2. MONTAJE
CAPÍTULO 4. HARDWARE
58
Capı́tulo 5
SOFTWARE
En este capı́tulo se abordan los detalles referentes al software que gobierna los
dos módulos que componen el sistema propuesto en este trabajo.
Se expondrá en primer lugar en la aplicación Android desarrollada para el módulo del lado del personal y posteriormente se presentará el firmware del módulo lector.
5.1.
App Android
Como ya se ha mencionado a lo largo del presente documento, el módulo del
lado del personal es un smartphone o una tablet que opere mediante el sistema
operativo Android.
Ası́ pues, se ha diseñado e implementado una aplicación (en adelante app) que
cumpla los requisitos y los objetivos necesarios para permitir la completa funcionalidad del sistema.
Para lograr una mejor comprensión del proceso de desarrollo y del funcionamiento de la app, se realizará una descripción de la misma desde diferentes puntos
de vista: análisis, diseño e implementación.
5.1.1.
Análisis
En esta sección se exponen las caracterı́sticas que han conformado el sustento
sobre el cual se ha diseñado e implementado la app. El fin último es fijar el marco en
el que se ha de envolver, por lo que se describirán el propio sistema, y se presentarán
los requisitos concretos del mismo, ası́ como los posibles casos de uso.
59
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Se debe remarcar la importancia de los requisitos del sistema. Su correcta identificación no sólo es fundamental para que el funcionamiento sea satisfactorio, sino
que al ser un sistema particularmente adaptado a una aplicación concreta, una mala
identificación de los requisitos supondrı́a un fracaso de cara al usuario final, que en
este caso es el cliente.
5.1.1.1.
Definición
El objetivo principal es ofrecer al cliente una app que le permita controlar el
módulo lector, entendiéndose este control no sólo como el gobierno de su comportamiento, sino también como la correcta adquisición e interpretación de los datos
recibidos del mismo.
El carácter dinámico de este trabajo, ha conllevado que este objetivo se vea
ampliado por otra serie de caracterı́sticas. En efecto, las diferentes reuniones que
se han mantenido con el cliente han tenido como resultado nuevas ideas, mejoras y
modificaciones del sistema. Por este motivo, se busca además que la app posea las
funciones necesarias para administrar y gestionar el negocio del cliente.
Se distinguirán por tanto dos usos de la app. Por una parte, se ha de poder
emplear durante el servicio de cafeterı́a, que es el objetivo fundamental. Por otra
parte, se han de poder realizar otras funciones complementarias como añadir, eliminar o modificar la información almacenada en la base de datos, ası́ como otra serie
de funciones que se han ajustado a la voluntad del propio cliente.
De este modo, las dos grandes funcionalidades de la app propuesta son:
Servicio: accederá a la pantalla en la que se podrá controlar el sistema durante
el horario de servicio. Se deben incluir aquı́ todas las funciones necesarias para
generar los registros de las consumiciones. Es aquı́ donde entra en juego el
módulo lector.
Opciones: accederá a un menú que ofrece al usuario (en este caso el propio cliente) todas las diferentes funcionalidades que ofrece la app y que se expondrán
con mayor grado de detalle en la sección relativa a la implementación.
Tanto durante el servicio como en alguna de las opciones de la app, es necesaria
la comunicación con el módulo lector. El SDK de Android ofrece de manera nativa
las funciones necesarias para efectuar conexiones Bluetooth con otros dispositivos.
De igual modo, en apartados posteriores se especificará cómo gestionar la conexión
por Bluetooth entre ambos módulos.
60
CAPÍTULO 5. SOFTWARE
5.1.1.2.
5.1. APP ANDROID
Requisitos
Para desarrollar la app es necesario recopilar las diferentes capacidades y restricciones que deba cumplir. Estos requisitos representan las especificaciones de las
funcionalidades que han de ser resueltas.
Son definidos tanto por el desarrollador como por el usuario, en este caso, el
cliente. Tienen como objetivo plantear el problema y delimitar qué es lo que ha de
cumplir la aplicación. Se pueden dividir según su naturaleza en:
Requisitos de capacidad (RC): tienen por objetivo plantear soluciones ante
problemáticas concretas.
Requisitos de usuario (RU): tienen por objetivo establecer las condiciones que
ha establecido el cliente.
Estos requisitos se exponen aquı́ en forma de tablas que siguen el patrón siguiente:
Identificador
Descripción
Necesidad
Prioridad
Tı́tulo: nombre del requisito
Código que identifica unı́vocamente al requisito.
Será de la forma RC-XX o RU-XX dependiendo
si el requisito es de capacidad o usuario.
Breve explicación del requisito. La descripción de
los requisitos de usuario no es habitualmente demasiado técnica.
Denota la importancia del requisito de cara al
resultado global de la app. Podrá ser alta, media
o baja.
Indica la necesidad de abordar el requisito antes
que otros. Podrá ser alta, media o baja.
Tabla 5.1: Requisito patrón.
Ası́ pues, los requisitos de la app son:
Identificador
Descripción
Necesidad
Prioridad
Control de datos
RC-01
El sistema permitirá un control total de la información: visualizar, añadir, modificar y eliminar
datos.
Alta
Alta
Tabla 5.2: RC-01: Control de datos.
61
5.1. APP ANDROID
Identificador
Descripción
Necesidad
Prioridad
CAPÍTULO 5. SOFTWARE
Almacenamiento de datos
RC-02
El sistema permitirá almacenar datos tanto localmente como en la nube.
Alta
Alta
Tabla 5.3: RC-02: Almacenamiento de datos.
Identificador
Descripción
Necesidad
Prioridad
Sincronización
RC-03
La información ha de ser accesible desde cualquier
dispositivo que cuente con la app.
Media
Media
Tabla 5.4: RC-03: Sincronización.
Identificador
Descripción
Necesidad
Prioridad
Alertas sonoras
RC-04
La app deberá emitir diferentes sonidos en función de si una consumición es aceptada o denegada.
Media
Baja
Tabla 5.5: RC-04: Alertas sonoras.
Identificador
Descripción
Necesidad
Prioridad
Información de la conexión con el lector
RC-05
Cuando sea necesario el uso del módulo lector, la
app deberá indicar el estado de la conexión con
él.
Media
Baja
Tabla 5.6: RC-05: Información de la conexión con el lector.
62
CAPÍTULO 5. SOFTWARE
Identificador
Descripción
Necesidad
Prioridad
5.1. APP ANDROID
Control básico del lector
RC-06
Puesto que el comportamiento del lector va
implı́cito en su firmware, la app ha de limitarse a
conectarse a él y a leer/enviarle datos.
Alta
Media
Tabla 5.7: RC-06: Control básico del lector
Identificador
Descripción
Necesidad
Prioridad
Modo de servicio
RC-07
La app permitirá un uso del lector de modo manual, automático y mixto.
Alta
Media
Tabla 5.8: RC-07: Modo de servicio.
Gráficas
Identificador
Descripción
Necesidad
Prioridad
RC-08
La app permitirá generar diferentes gráficas mostrando la distribución de consumiciones a lo largo
del servicio, el número de consumiciones de un tipo a lo largo de un cierto periodo de tiempo, etc.
Media
Media
Tabla 5.9: RC-08: Gráficas.
Identificador
Descripción
Necesidad
Prioridad
Lista de la compra
RC-09
La app ofrecerá la posibilidad de hacer la lista de
la compra.
Baja
Baja
Tabla 5.10: RC-09: Lista de la compra.
63
5.1. APP ANDROID
Identificador
Descripción
Necesidad
Prioridad
CAPÍTULO 5. SOFTWARE
Compartir imágenes
RC-10
La app permitirá compartir imágenes con otras
aplicaciones (particularmente se orientará a Instagram).
Baja
Baja
Tabla 5.11: RC-10: Compartir imágenes.
Identificador
Descripción
Necesidad
Prioridad
Interfaz de usuario (UI)
RU-01
La app ha de tener una interfaz sencilla para garantizar la usabilidad de la misma.
Alta
Alta
Tabla 5.12: RU-01: Interfaz de usuario (UI).
Identificador
Descripción
Necesidad
Prioridad
Conectividad automática
RU-02
La conexión con el módulo lector y con la nube se ha de hacer automáticamente, liberando al
usuario de la necesidad de efectuar una conexión
manual.
Alta
Alta
Tabla 5.13: RU-02: Conectividad automática.
Contraseña
Identificador
Descripción
Necesidad
Prioridad
RU-03
Sólo se podrá acceder a las opciones de la app mediante la introducción de una contraseña únicamente conocida por el personal. Esta contraseña
deberá poder ser modificada si se desea.
Alta
Baja
Tabla 5.14: RU-03: Contraseña.
64
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Plataforma
Identificador
Descripción
Necesidad
Prioridad
RU-04
La app será funcional a partir de la versión 4.2
de Android (JellyBean).
Alta
Alta
Tabla 5.15: RU-04: Plataforma
5.1.2.
Diseño e implementación
La solución propuesta de cara al módulo del lado del personal es una app llamada
Cafeterı́a RUGP, siendo el principal objetivo de este apartado la descripción de la
estructura y el funcionamiento de dicha app.
Para ello se expondrá la estructura del proyecto, presentando las clases existentes y un diagrama de navegación entre las clases que en la app aparecen como
pantallas (se recuerda que este tipo de clases se denominan también activities).
Posteriormente se incluyen los aspectos más relevantes de cara a la implementación de la app. Se comienza con los cimientos que sustentan su comportamiento
para llegar a descripciones más funcionales y especı́ficas.
Ası́ pues se parte de los dos pilares fundamentales de la app: la base de datos y
la comunicación Bluetooth con el módulo lector. Ambos son fundamentales de cara
a proporcionar robustez a la app, y por tanto merece la pena invertir un tiempo
superior en estos apartados.
Posteriormente se comentan las bibliotecas externas que se incluyen en la app,
ası́ como la justificación de su uso.
Por último se pasará a una descripción más funcional de la app, presentando
las opciones y funcionalidades que ofrece al usuario.
5.1.2.1.
Clases
El proyecto consta de una serie de clases que en su conjunto forman la app
que se presenta en este trabajo. Estas clases se han dividido en 5 grupos según su
finalidad, y se presentan en la tabla 5.16.
Se han establecido las categorı́as presentadas en la tabla atendiendo a la funcionalidad de las clases que incluyen. En concreto:
65
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Ajustes
Backups
CambioGeneral
CambioIndividual
Estadisticas
GenerateEntries
gestor residentes
gestor tags
Graficas
Historial registros
Activities
HomeActivity
Instagram
ListaCompra
newItemListaCompra
newResidente
newTagRoom
OtrasFuncionalidades
ResidenteView
Servicio
ListaCompraCategoriaAdapter
ListaCompraElementosAdapter
RegistrosAdapter
Adapters
ResidentesAdapter
TagRoomAdapter
Admin
Horario
ItemCompras
MediaPension
Classes
Registro
Residente
TagRoom
BluetoothNotAvailableException
Exceptions
BluetoothNotEnabledException
BluetoothHelper
ICallback
ItemClickSupport
Utils
MyDB
ResidentesConstants
WrappingRecyclerViewLayoutManager
Tabla 5.16: Clases del proyecto
66
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Activities: como el propio nombre indica, las clases incluidas en este grupo son
las que aparecen como pantallas en la app.
Adapters: algunas pantallas de la app contienen RecyclerViews, que es un
widget que permite mostar listas de otros widgets. Los adapters son las clases
que permiten la interacción del usuario con cada widget de la lista mostrada
en el RecyclerView.
Classes: las clases de este grupo son las que se emplean para leer la información
almacenada en la base de datos (se profundizará en esto al hablar de la gestión
de la información en la app).
Exceptions: son dos clases que se emplean para detectar los casos en los que
el Bluetooth del dispositivo no esté disponible o esté desactivado.
Utils: están incluidas aquı́ ciertas clases auxiliares con finalidad propia. Se
comenta brevemente la función de cada una:
• BluetoothHelper: clase que encapsula la lógica del control del Bluetooth
del dispositivo.
• ICallback: interfaz que implementan las clases que requieren el uso del
Bluetooth. Se profundizará en la clase BluetoothHelper y en esta interfaz
al hablar de la gestión del Bluetooth en la app.
• ItemClickSupport: código abierto1 que implementa un método similar al
onClick de los widgets de Android para los widgets de un RecyclerView.
Esto puede hacerse desde el adapter sin emplear esta clase, aunque de
manera menos directa. No obstante se incluyó esta clase para comprobar
cómo puede realizarse la misma tarea de diferentes maneras. Ası́ pues,
las diferentes RecyclerViews de la app implementan la gestión de las
pulsaciones de un modo u otro.
• MyDB: es la clase que permite gestionar la base de datos. Se estudiará en
detalle cuando se exponga la gestión de la información en la app.
• ResidentesConstants: clase que contiene 3 constantes que sirven para reutilizar un mismo adapter pero con diferentes condiciones. En concreto se
usa para el adapter del RecyclerView que muestra la lista de residentes,
puesto que esta lista aparece en varias activities, pero las opciones que
ha de implementar depende de qué activity contenga la lista.
• WrappingRecyclerViewLayoutManager: se trata de una clase que permite
implementar RecyclerViews anidados, esto es, RecyclerViews de RecyclerViews, algo que el layout nativo no permite. Se emplea para la lista de la
1
ItemClickSupport:
Handle-Android-RecyclerView-Clicks/
67
http://www.littlerobots.nl/blog/
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
compra, en la que las categorı́as se muestran en un RecyclerView, y cada
categorı́a contiene otro RecyclerView con los productos asociados a ella.
Es una clase creada por el desarrollador ruso Denis Nek.
5.1.2.2.
Diagrama de navegación
Las clases de un proyecto, junto con sus atributos y métodos, y la relación entre
las mismas suelen presentarse como modelos o diagramas de clases (por ejemplo
siguiendo el estándar UML). Teniendo en cuenta la extensión que presentarı́a el
diagrama de clases de este proyecto y el flaco favor a la mejora de la comprensión
global de la app lo hace poco interesante en este trabajo.
Sin embargo la futura implementación de la app sı́ puede comprenderse más
fácilmente con una simplificación de un diagrama de clases. Se presenta con este
objetivo el diagrama de navegación de la figura 5.1, que muestra las activities y el
camino que las relaciona.
Figura 5.1: Diagrama de navegación de la app.
68
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Una vez que se ha presentado una visión global de la app, se exponen en lo
sucesivo aspectos relativos a la implementación de la misma.
5.1.2.3.
Gestión de la información
La descripción de la app que se ha hecho a lo largo de los epı́grafes previos
justifica la necesidad de desarrollar una app configurable y flexible, capaz de añadir,
modificar, eliminar y almacenar una serie de datos e información que se presenta en
este apartado. Ası́ pues, es fundamental la integración de una base de datos en la
app.
Base de datos local: SQLite
Existen diversos motores de bases de datos, sin embargo SQLite es el que reúne
las caracterı́sticas adecuadas para que sea cómodo usarlo en apps [16]. Entre estas
caracterı́sticas destacan:
No requiere el soporte de un servidor, con lo que no hay que trabajar mediante
peticiones.
Libera al programador de tareas de configuración de bajo nivel.
Almacena la base de datos en la carpeta de la propia app, con lo que otras
apps no pueden acceder a ella.
Es de código abierto.
No obstante, SQLite tiene ciertas limitaciones a la hora de implementar ciertas
cláusulas que otros motores sı́ posibilitan. Sin embargo esto no será un problema en
la app propuesta.
Además, el SDK de Android ofrece una biblioteca con clases para administrar
los archivos bases de datos basadas en SQLite.
Por lo anteriormente explicado, se escoge este motor para manejar la base de
datos de la app de este trabajo.
Considérese llegados a este punto, una habitación cualquiera de la residencia. Se
pueden observar dos parámetros asociados a la misma: el tag que la identificará, y el
residente que la ocupará. Estos parámetros guardan una diferencia fundamental: la
duración. Mientras que un tag puede estar asociado permanentemente a una misma
habitación (salvo deterioro o pérdida), el residente es temporal.
En efecto, un residente ocupará una habitación durante un cierto periodo de
tiempo, y posteriormente cambiará de habitación si alguna más acorde a sus preferencias queda libre, o bien finalizará su estancia en la residencia (cuando termine
69
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
el curso académico, por ejemplo). Ası́ pues, queda constancia del carácter fijo y
temporal de los tags y residentes, respectivamente.
De esta apreciación se deducen dos conclusiones necesarias para estructurar la
base de datos:
Los códigos de los tags y los perfiles de los residentes han de almacenarse
en tablas diferentes en la base de datos, quedando ambos relacionados por la
habitación a los que están asociados.
La app ha de posibilitar las modificaciones pertinentes debidas a los cambios
de habitación.
Hecho este matiz se presentan las diferentes tablas de la base de datos, indicando
además los campos que contienen, ası́ como su tipologı́a2 :
TAGROOM: contiene los códigos de los tags (TEXT) y la habitación a la que
éstos se asocian (INTEGER).
RESIDENTES: almacena los perfiles de usuario de los residentes mediante
campos TEXT: nombre, apellidos, tipo de pensión (media pensión o pensión
completa), y campos INT: habitación, y menús y desayunos disponibles.
LISTACOMPRA: los campos de esta tabla son los necesarios para poder gestionar la lista de la compra. Son el nombre, categorı́a y medio en el que se
adquiere un producto (TEXT), y dos campos de tipo INT: la cantidad a comprar, y un campo auxiliar llamado borrar que es INT puesto que SQLITE no
admite el tipo boolean. Este serı́a el tipo recomendado, puesto que es un campo
cuyo valor indica si un elemento de la lista de la compra se ha de eliminar o
no.
Tablas de registros de consumiciones: se trata de 3 tablas que guardan información asociada a las consumiciones que se efectuan. Las 3 tienen los mismos
campos, pero se ha decidido independizarlas entre sı́ puesto que esto permite
realizar operaciones especı́ficas a cada una. Estas tablas son:
• DESAYUNOS.
• COMIDAS.
• CENAS.
Contienen los campos TEXT del residente que efectúa la consumición (nombre,
apellidos, tipo de pensión y habitación) y además contiene campos INT para
guardar la hora, minuto, segundo, dı́a, mes y año a la que la consumición
se efectúa. Por último tiene un campo TEXT que contiene el tipo de tabla
2
Los tipos requeridos son INT, TEXT, e INT PRIMARY KEY, para los valores numéricos (int,
float, long...), las cadenas de texto (String), y los identificadores de cada registro, respectivamente.
70
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
(desayuno, comida o cena) que es útil para ciertas funciones que se ejecutan
en otras clases.
Otras tablas: se recogen a continuación las restantes tablas, que, si bien de
menor relevancia que las anteriores, tienen su razón de ser.
• HORARIOS: es la tabla en la que se guardan los horarios de comienzo y
fin de los diferentes servicios (desayunos, comidas y cenas). La necesidad
de almacenar y modificar estos datos radica en que la app detecta el tipo
de consumición que se va a efectuar en base a la hora que es. Fuera de
horario, antes de efectuar la consumición, se pide al usuario que indique
el tipo. De este modo, el propio usuario puede modificar a su criterio
los horarios para que estas peticiones aparezcan con menor frecuencia.
Ası́ pues, se almacenan como TEXT el tipo de consumición (desayuno,
comida o cena) y el tipo de horario (comienzo o fin). Como INT se guardan
la hora y el minuto.
• ADMIN: es una tabla cuya misión es exclusivamente almacenar la contraseña de acceso a las opciones de la app, contraseña que al ser numérica
se almacena en un campo de tipo INT.
• MEDIAPENSIÓN: Los residentes adscritos al sistema de media pensión
cuentan con 30 menús (indistintamente se consuman como comidas o cenas) y 20 desayunos mensuales. Por otra parte, un residente recibe nuevas
consumiciones cuando abona las cuotas pertinentes, algo que se hace de
manera trimestral. De este modo, el usuario puede guardar estos valores para que al crear las fichas de nuevos residentes se asignen de manera
automática a los residentes de media pensión. Además al poder modificarlos, si en el futuro la empresea decide ofrecer más o menos consumiciones
por trimestre, seguirá siendo posible asignarlos automáticamente, pues
bastará con cambiar el valor desde la pantalla correspondiente.
Cada elemento que se almacene en la base de datos, independientemente de la
categorı́a a la que pertenezca, dispondrá de un campo denominado id, de tipo INT
PRIMARY KEY, que servirá para identificar unı́vocamente cada elemento de cada
tabla.
La clase encargada de gestionar la base de datos es MyDB, que incluye los atributos y métodos necesarios para crear, actualizar y eliminar las tablas que contiene
la base de datos.
Además, MyDB contiene los métodos que otras clases necesitan para desempeñar sus respectivas funciones relacionadas con la información de la base de datos.
Estas clases requieren un procedimiento adecuado para leer los datos de la base de
datos, que no dejan de ser filas y columnas de diferentes tablas.
71
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Dicho procedimiento consiste en generar diferentes clases (una por cada tipo de
dato almacenado) que cuentan con un constructor y con los métodos get(), o getters
que proporcionan la información previamente leı́da de la base de datos.
La figura 5.2 representa gráficamente la relación descrita.
Figura 5.2: Clases cuyas instancias permiten leer la información de la base de datos.
Las instancias de estas clases (u objetos) que se emplean en las distintas activities de la app se crean mediante los métodos incluidos en MyDB. Estos métodos se
basan a su vez en otros métodos que ofrece el SDK de Android y que están basados
en sentencias SELECT de SQL. Ası́ se pueden leer las entradas de la base de datos
que se ajusten a un cierto criterio.
72
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Los atributos de estos objetos coinciden con los campos de las tablas a los que
están asociados. Los valores numéricos (INT) de las tablas son almacenados como
variables int y las cadenas alfanuméricas (TEXT) como variables String.
Como ejemplo se presenta el fragmento de código 5.1 que genera un objeto de
tipo TagRoom. Para ello es necesario leer de la tabla TAGROOM la entrada cuya
id coincida con la deseada (pasada a la función como parámetro).
1 public TagRoom getTAGROOMwithID(int id) {
2
3
SQLiteDatabase db = getReadableDatabase();
4
TagRoom tagroom = null;
5
String[] valores_recuperar = {"_id", "room", "tag"};
6
7
//Lectura de la base de datos
8
Cursor c = db.query(TAGROOM,valores_recuperar,"_id="+id,null,null,
null,null,null);
9
if(c != null) {
10
//Lectura de los valores de la entrada
11
int id = c.getInt(0);
12
int room = c.getInt(1);
13
String code = c.getString(2);
14
//Creacion de instancia
15
tagroom = new TagRoom(id,room,code);
16
c.close();
17
}
18
19
db.close();
20
return tagroom;
21 }
Listing 5.1: Lectura de registros de la base de datos.
Definida pues la estructura y el funcionamiento de la base de datos, es de fundamental importancia de cara al cliente no perder la información que ésta contiene.
Se plantearán dos tipos de almacenamiento: local y en la nube.
Almacenamiento local
El SDK de Android ofrece la posibilidad de que una app guarde información en
un medio de almacenamiento externo, que en el caso de los smartphones o las tablets
es una tarjeta SD3 . Ası́ pues, se aplicará esta funcionalidad de cara a exportar datos
a una tarjeta SD. De este modo en caso de deterioro del dispositivo, la información
quedará a salvo en dicha tarjeta.
3
Tarjetas de memoria con formato Secure Digital, del cual puede obtenerse más información en
su página web oficial: https://www.sdcard.org/
73
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Las funciones necesarias para llevarlo a cabo están incluidas en dos clases diferentes.
Por un lado, en la clase HomeActivity se crean los directorios necesarios en
los que posteriormente se almacenará la información. Sólo se crean si no existen
previamente, de modo que en condiciones normales se crearán al iniciar la app por
primera vez. No obstante, de este modo se garantiza que si por algún motivo se
borra una carpeta, ésta se regenere al abrir de nuevo la app. Con esto se asegura
la existencia de los directorios en los que almacenar la información localmente en la
tarjeta SD. El árbol de directorios creado se observa en la figura 5.3.
Figura 5.3: Árbol de directorios creado por la app.
La copia de seguridad de la base de datos se almacenará en la carpeta Database.
Por completar la descripción: en la carpeta Fotos se guardarán las fotos de las fichas
de los residentes, en Instagram quedarán las copias locales de las fotografı́as que se
tomen desde la funcionalidad expresamente diseñada para ello, independientemente
de que se lleguen a compartir en Instagram u otra app o no. En Lista de la compra
se almacena un fichero txt en el que aparece una representación escrita de la lista de
la compra de la app. Por último, en Registros se crean a su vez 3 subdirectorios para
los desayunos, las comidas y las cenas, en los cuales se almacenan de nuevo ficheros
txt con los registros de las consumiciones (un fichero por dı́a y carpeta).
Por otro lado, la clase Backups es la que ofrece al usuario la posibilidad de
manejar las copias de seguridad de la base de datos. Esta clase se presenta como
una activity tal y como se observa en la figura 5.4.
Cabe diferenciar llegados a este punto las 3 bases de datos con las que trabaja
la app, y que coinciden con los 3 apartados de la clase Backups (figura 5.4):
1. Base de datos: es la base de datos que necesita la app para funcionar. Es la que
se modifica durante el uso de la app, y que no es accesible de manera externa.
Es por tanto de la que se desean generar copias de seguridad.
74
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Figura 5.4: Clase Backups.
La única opción disponible es la dada por el botón SUBIR. Su función es la
de generar una copia de seguridad tanto en la tarjeta SD como en la nube.
Ası́ pues, realiza una copia del fichero database.db guardado en el espacio de la
app, y la duplica tanto en la carpeta Database del árbol de directorios, como
en la nube.
Por tanto mediante un simple botón, el usuario salva la información de las dos
formas deseadas.
2. Backup local: es la copia de seguridad de la base de datos que se almacena en
la tarjeta SD (base de datos almacenada localmente).
En este caso la opción disponible para el usuario es la dada por el botón
DESCARGAR. Su función es la de restaurar la base de datos de la app con la
copia de seguridad almacenada localmente.
Básicamente comprueba si existe una copia de seguridad en la tarjeta SD, y
en caso afirmativo, sustituye la base de datos de la app por dicha copia de
seguridad.
75
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Puesto que la restauración de la base de datos conlleva la pérdida del estado
actual de la misma, hay que solicitar la confirmación del usuario para evitar
una restauración accidental. Para ello se muestra un diálogo de alerta o Alert
Dialog como el de la figura 5.5. Este es sólo un ejemplo de los numerosos
diálogos de confirmación que lanza la app, puesto que ciertas opciones deben
protegerse de este modo para evitar pérdidas de información.
Figura 5.5: Diálogo de confirmación.
Por tanto, gracias al backup local, en caso de deterioro del dispositivo o reinstalación de la app, se puede restaurar la base de datos sin necesidad de
conexión a internet, siempre que la tarjeta SD no esté dañada. De ser éste
el caso, habrı́a que recurrir a la restauración de la base de datos mediante el
backup en la nube.
3. Backup en la nube: es la copia de seguridad de la base de datos que se almacena
en la nube y que se detallará en profundidad en el apartado siguiente.
Almacenamiento en la nube: Google Drive
Se ha expuesto hasta ahora un método de almacenamiento permanente a nivel
local, pero el cliente estimó oportuna la posibilidad de almacenar la información en
la nube. De este modo no sólo se cubre la posibilidad de pérdida de información por
deterioro de la tarjeta SD, sino que se abren las puertas a una sincronización de la
información entre diferentes dispositivos que tengan la app instalada.
El SDK de Android no ofrece una funcionalidad nativa para esto. Por ello se
torna necesario emplear una herramienta alternativa.
Atendiendo al criterio económico, resulta razonable buscar opciones gratuitas. Los servidores en la nube contemplados, por su popularidad y fiabilidad, son
Google Drive y Dropbox. Ambas herramientas ofrecen APIs para la integración de
sus servicios en el desarrollo de una app.
76
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Dropbox ofrece una API4 bien documentada y completamente funcional de cara
al propósito de la app de este trabajo.
Google Drive ofrece dos APIs5,6 perfectamente documentadas y que sin duda
permiten cumplir los objetivos de la app:
Google Drive Android API (GDAA): se trata de una API de alto nivel que
permite tratar archivos y carpetas en Drive como si fueran locales. Esto implica
que pueden realizarse copias de seguridad a pesar de que no se disponga de
conexión a internet. La propia API actualizará o sincronizará los datos en
la nube cuando sı́ se disponga de conexión, con lo cual el desarrollador se
despreocupa de estos aspectos.
Google Drive REST API (REST): ofrece funciones de bajo nivel para realizar
procesos más complejos que la API anterior. Sin embargo en este caso es el
desarrollador quien tiene que prestar especial atención al estado de la conexión a internet, pues esta API no ofrece el acceso offline ni la sincronización
automática que sı́ ofrece la API GDAA.
La elección de un servidor u otro, puesto que no se tiene una restricción en este
sentido, depende del trabajo que conlleve la integración del mismo en la app. En
efecto, es objetivo de este trabajo lograr el almacenamiento de los datos en la nube,
pero no el desarrollo de una API propia o introducirse en funciones de bajo nivel
para lograrlo.
Desde esta perspectiva, se descarta la API REST de Google Drive. Entre la API
de Dropbox y la API GDAA de Google Drive no existen diferencias fundamentales
para los objetivos que busca la app. Ası́ pues, y teniendo en cuenta que ambas
opciones son válidas, se opta por la API GDAA de Google Drive por disponer de una
más amplia documentación. Además, al ser de Google, las tareas de autenticación o
login se realizan de un modo más sencillo desde la plataforma Android.
Para trabajar con Google Drive hay que seguir una serie de instrucciones que
se indican en la documentación oficial7 .
En primer lugar hay que descargar, si no se posee ya, el SDK de los servicios
de Google Play, o Google Play services SDK. Este SDK es el que incluye la Google
Drive Android API.
A continuación hay que registrar la app para poder interactuar con la API. Esto
4
Dropbox - Core API: https://www.dropbox.com/developers-v1/core
Google Drive Android API: https://developers.google.com/drive/android/
intro
6
Google Drive REST API: https://developers.google.com/drive/v2/web/
about-sdk
7
Pasos para emplear la GDAA: https://developers.google.com/drive/android/
get-started#overview
5
77
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
significa registrar un nuevo proyecto en la Google Developers Console que incluya la
app desarrollada.
Para ello hay que introducir una huella digital o resumen MD58 del fichero de
claves de prueba. Este archivo, almacenado en la carpeta de usuario del desarrollador,
se llama debug.keystore. Es un archivo que contiene las claves o firmas digitales
necesarias para verificar la autorı́a de una app durante su desarrollo (si la app se
publica en Google Play, el desarrollador deberá generar explı́citamente una clave
para firmar con ella la app). El resumen MD5 del archivo debug.keystore se obtiene
desde la consola del Android Studio mediante el código 5.29 . Tras introducir el
comando anterior, la consola de Android Studio nos proporciona la huella digital
buscada, con un aspecto como el que muestra el código 5.3.
1 keytool -exportcert -alias androiddebugkey -keystore
RUTA %AL %ARCHIVO %debug.keystore -list -v
Listing 5.2: Obtención del resumen MD5 del archivo debug.keystore.
1 Huella digital de certificado (MD5):
2 XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
Listing 5.3: Huella digital obtenida.
Introduciendo en la Google Developers Console el código anterior, y seleccionando las APIs que se desean emplear en el desarrollo, la app quedará registrada
como se observa en la figura 5.6.
Figura 5.6: Registro de la app en la consola de Google.
8
MD5: el Message-Digest Algorithm 5, o algoritmo del resumen del mensaje 5 es un algoritmo
criptográfico ampliamente usado que genera un código (resumen) a partir de un contenido digital
cualquiera[2].
9
Generación de huellas digitales y autorización de uso de APIs de Google: https://
developers.google.com/drive/android/auth
78
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
En ella se muestra la sección Credenciales de la web, en la que se comprueba que
está habilitado un cliente de Drive con un identificador único. Este procedimiento
permite emplear cualquier API de las que se ofertan en la web, siendo la necesaria
para este trabajo la API de Google Drive. Como ejemplo, se expone el fragmento de
código 5.4, que muestra el método updateDriveDb que tiene por finalidad guardar la
copia de seguridad de la base de datos en Google Drive. En el fragmento de código
5.4 se observa el uso clases, métodos e interfaces de la API de Google Drive que es
posible tras el registro de la app expuesto anteriormente.
1 private void updateDriveDb(final File fileToSave) {
2
Drive.DriveApi.newDriveContents(mGoogleApiClient).setResultCallback
(new ResultCallback<DriveApi.DriveContentsResult>() {
3
@Override
4
public void onResult(DriveApi.DriveContentsResult result) {
5
if (!result.getStatus().isSuccess()) {
6
Toast.makeText(Backups.this, "Ha ocurrido un error al
preparar los archivos para subir.", Toast.LENGTH_LONG).
show();
7
return;
8
}
9
OutputStream outputStream = result.getDriveContents().
getOutputStream();
10
//Los ficheros han de subirse a Drive como cadenas de bytes
11
byte[] bArray = file2Bytes(fileToSave);
12
try {
13
outputStream.write(bArray);
14
} catch (IOException e1) {
15
Toast.makeText(Backups.this, "No ha sido posible subir
los archivos.", Toast.LENGTH_LONG).show();
16
}
17
MetadataChangeSet metadataChangeSet = new MetadataChangeSet
.Builder()
18
.setMimeType("application/x-sqlite3")
19
.setTitle("database.db")
20
.build();
21
IntentSender intentSender = Drive.DriveApi
22
.newCreateFileActivityBuilder()
23
.setInitialMetadata(metadataChangeSet)
24
.setInitialDriveContents(result.getDriveContents())
25
.build(mGoogleApiClient);
26
try {
27
startIntentSenderForResult(intentSender,
REQUEST_CODE_CREATOR, null, 0, 0, 0);
28
} catch (SendIntentException e) e.printStackTrace();
29
}
30
});
31 }
Listing 5.4: Subida de la base de datos a Google Drive.
79
5.1. APP ANDROID
5.1.2.4.
CAPÍTULO 5. SOFTWARE
Bluetooth
La comunicación con el módulo lector pasa por incluir en la app las funciones
necesarias para el control del Bluetooth del dispositivo. Se presentan en este apartado
los aspectos fundamentales de dicho propósito.
El SDK de Android posee funcionalidades elementales para la gestión del Bluetooth. Algunas de ellas son el encendido y apagado, detección de estado y cambios de
estado, etc. Estas funciones se presentan como métodos de diferentes clases incluidas
en el SDK, con lo que no es necesario ningún paso previo como ocurre para la API
de Google Drive. No obstante, es tarea del desarrollador emplear estas herramientas
del SDK para que el funcionamiento del Bluetooth se ajuste a los requisitos de la
app.
Puesto que el Bluetooth es necesario en más de una activity, es razonable encapsular todo lo relacionado con él. Para ello se emplean los siguientes ficheros:
La clase BluetoothHelper : implementa la lógica del funcionamiento del Bluetooth.
Incluye los métodos necesarios para el correcto funcionamiento de la app: conexión y desconexión, lectura y escritura de datos, y emparejamiento con otro
dispositivo.
Esta última funcionalidad está particularizada para la app de este trabajo. Al
ser fijo el dispositivo al que ha de emparejarse (se requiere el uso del Bluetooth especı́ficamente para emparejarse al módulo lector), basta con incluir
en el código de manera especı́fica la dirección MAC del sensor Bluetooth HC05 contenido en el módulo lector. Ası́, en lugar de mostrar un listado de los
dispositivos encontrados, se emparejará directamente con el módulo lector.
El inconveniente de este proceder radica en que una posible sustitución por
deterioro del sensor HC-05 conllevarı́a una actualización del código de la app
con la MAC del nuevo sensor instalado. Sin embargo, de este modo se libera
al usuario del emparejamiento manual (algo que sugirió el propio cliente), y el
emparejamiento erróneo con otro dispositivo.
La interfaz ICallback : las interfaces son colecciones de métodos abstractos que
heredan las clases que implementan dichas interfaces.
En este caso, la interfaz contiene sólamente uno: el método call. Toda activity
de la app que requiere el uso de Bluetooth implementa esta interfaz, y por
tanto implementan sus particulares métodos call.
Se expone a continuación las lı́neas generales de la integración de ambos ficheros
con las diferentes clases que lo requieren.
80
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Las instancias de la clase BluetoothHelper son los objetos que una activity emplea para usar el Bluetooth. El constructor recibe como parámetro la activity que
lo llama, de modo que la instancia generada puede inicializar una variable de tipo
ICallback, que hereda el método call.
Este método recibe como parámetro el String que contiene los datos leı́dos (es
necesario convertirlos, pues en crudo se recibe una cadena de bytes), y es llamado
con cada lectura de datos en un proceso gestionado por un Thread y un Handler.
Lo anteriormente descrito se puede observar en el extracto de código 5.5.
1 public class BluetoothHelper {
2
...
3
private ICallback mCallback;
4
private Thread mWorkerThread;
5
private Handler mHandler();
6
private String mData;
7
...
8
private BluetoothHelper(Activity activity) {
9
mCallback = (ICallback) activity;
10
}
11
...
12
private void beginListenForData() {
13
mHandler = new Handler();
14
mWorkerThread = new Thread(new Runnable(){
15
public void run(){
16
...
17
mData = new String(encodedBytes, "US-ASCII");
18
...
19
mHandler.post(new Runnable(){
20
public void run(){
21
mCallback.call(mData);
22
}
23
...
24
}
25 }
Listing 5.5: Integración de ICallback y BluetoothHelper.
Como la variable de tipo ICallback se ha inicializado con la activity, al llamar
al método call de esta variable, se ejecuta la lógica implementada en el método call
de la activity.
Por tanto, gracias a la interfaz ICallback y a BluetoothHelper, basta implementar
un método call en cada activity que requiera Bluetooth. Este método recibe como
parámetro un String con el código recibido del sensor. De este modo es sencillo
programar la lógica necesaria para trabajar con la información recibida del módulo
lector.
La idea general descrita para encapsular la integración del uso del Bluetooth
81
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
en la app, se representa en la figura 5.7, en la que se observan las dos clases que lo
emplean.
Figura 5.7: Integración del Bluetooth en la app.
La necesidad de estas activities de emplear el Bluetooth se debe a la funcionalidad de las mismas. Esto se comentará, junto a la funcionalidad del resto de activities,
en una sección posterior.
5.1.2.5.
Bibliotecas externas
Los requisitos establecidos para el adecuado funcionamiento de la app suponen,
en algunos casos, la necesidad de recurrir a bibliotecas creadas por terceros.
En efecto, cumplir con ciertos requisitos excederı́a los objetivos de este trabajo
al requerir una gran cantidad de horas de desarrollo que no estarı́an especı́ficamente
dedicadas al fin último del trabajo. En su lugar, para implementar las funcionalidades
relacionadas con estos requisitos, se recurre a bibliotecas externas.
Ya se ha visto anteriormente un ejemplo de uso de estas bibliotecas cuando
se presentó la de Google Drive. Al igual que ésta ofrece funciones especı́ficas para
el almacenamiento en la nube, las demás bibliotecas proporcionan las herramientas
necesarias para implementar otras funcionalidades deseadas en la app.
82
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Las bibliotecas, su función y justificación de uso son las siguientes:
Support: se trata de un paquete de bibliotecas10 de Android que ya se presentó en la sección 3.1.2. Su uso es necesario para el diseño gráfico de la app.
En concreto se emplean las siguientes bibliotecas:
• AppCompat: añade soporte para la ActionBar (figura 5.8).
Figura 5.8: ActionBar.
• Design: permite emplear Material Design, que es la tendencia actual en
diseño de interfaces de usuario.
• Cardview y RecyclerView : permiten emplear dichas widgets, al no estar
incluidas por defecto en la paleta de diseño (la cual incluye widgets más
tı́picos como botones, switches, campos de texto...).
Ion: biblioteca desarrollada por Koushik Dutta11 que entre otras funcionalides,
se emplea en la app para incluir imágenes animadas con formato gif. Este
tipo de imágenes no son soportadas de manera nativa por Android, de ahı́ la
necesidad de uso de esta biblioteca.
aChartEngine: biblioteca de código abierto que se emplea para la generación
de gráficas. Las herramientas de dibujo que proporciona Android son bastante
elementales, de manera que la creación de representaciones complejas como una
gráfica es un proceso laborioso y que no concuerda con los objetivos principales
de este trabajo.
La elección de esta biblioteca frente a otras igualmente válidas se basa en que
es de código abierto y gratuita. Otras bibliotecas consultadas resultaron ser de
pago e incluso alguna de ellas requerı́a la instalación de una app externa en el
terminal.
Google Play Services: es la biblioteca necesaria para emplear las APIs de Google. Ası́ pues, se incluye para utilizar la Google Drive Android API, como ya
se detalló anteriormente.
Para incluir estas bibliotecas hay que añadirlas como dependencias en el fichero
build.gradle del proyecto, como muestra el fragmento de código 5.6.
10
Se puede consultar información más detallada en la web oficial: https://developer.
android.com/topic/libraries/support-library/features.html
11
Repositorio oficial: https://github.com/koush/ion
83
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
1 ...
2 dependencies {
3
...
4
compile ’com.android.support:appcompat-v7:23.1.1’
5
compile ’com.android.support:design:23.1.1’
6
compile ’com.android.support:cardview-v7:23.0.+’
7
compile ’com.android.support:recyclerview-v7:23.0.+’
8
compile ’com.koushikdutta.ion:ion:2.+’
9
compile ’org.achartengine:achartengine:1.2.0’
10
compile ’com.google.android.gms:play-services:7.8.+’
11 }
Listing 5.6: Bibliotecas importadas en build.gradle.
Con esto concluye la exposición de los cimientos de la app. Las funcionalidades
detalladas hasta ahora son las que permiten el desarrollo de aquélla.
Analizada pues la base, en los siguientes epı́grafes se procede con la descripción
funcional de la app, siguiendo el orden de presentación establecido al inicio de la
sección.
5.1.2.6.
Cafeterı́a RUGP
La app desarrollada para este trabajo tiene como nombre su lugar de aplicación:
Cafeterı́a RUGP. En efecto, el sistema de identificación contactless fruto de este
trabajo se ha aplicado al servicio de cafeterı́a de la Residencia Universitaria GómezPardo, de cuyas siglas nace el nombre de la app.
Se trata de una app que cumple dos funciones. Por una parte, satisface los
objetivos del trabajo que se establecieron en el capı́tulo 1. Por otra parte, ha sido
diseñada a medida, a gusto del cliente.
Puesto que su aplicación es especı́fica a la cafeterı́a, se ha mantenido una estrecha colaboración con el responsable de la misma, quien ha sugerido nuevas funcionalidades y modificaciones de las ya existentes de manera que el sistema global sea
válido desde su perspectiva para la gestión de su negocio.
La pantalla principal de la app viene dada por la activity HomeActivity, y es la
que se muestra en la figura 5.9.
Como se puede deducir de dicha pantalla, se han dividido las distintas funciones
de la app en dos grandes categorı́as, que se lanzan mediante los botones:
Servicio: carga la pantalla pensada para funcionar durante el horario de servicio
de la cafeterı́a.
84
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Figura 5.9: Pantalla principal.
Opciones: accede a un menú con las restantes funcionalidades de la app. Puesto
que desde las opciones se pueden modificar los datos almacenados, se requiere
una auntorización para acceder. Esto se logra mediante la petición de una
contraseña numérica, como muestra la figura 5.10. Por defecto, esto es, tras
instalar la app, la clave de acceso es 1234. Esta clave puede modificarse en los
ajustes avanzados de la app, como se verá posteriormente.
Se ha contemplado igualmente el caso en el que se modifique la contraseña
y posteriormente se olvide. Esta situación impedirı́a el acceso a las opciones
de la app, con lo que, entre otras cosas, no se podrı́an salvar las copias de
seguridad. Por ello existe otro modo de acceder a las opciones: mediante una
clave maestra.
Se trata de un código secreto que es aceptado siempre. Por seguridad, se le entrega dicho código al cliente, quedando en él la responsabilidad de mantenerlo
en secreto y no olvidarlo.
85
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Figura 5.10: Autorización para el acceso a las opciones de la app.
Los siguientes epı́grafes exponen en detalle las funcionalidades incluidas en cada
una de las dos categorı́as presentadas.
5.1.2.6.1.
Servicio
La activity Servicio permite al usuario desempeñar la funcionalidad principal
del sistema: validar consumiciones tras la detección de tags por el módulo lector.
Al entrar a esta pantalla, lo primero que se comprueba es el estado del Bluetooth
del dispositivo. Si está activado, se intenta conectar al módulo lector. Si no, muestra
un botón cuya función es activarlo, y posteriormente, ofrecer mediante un segundo
botón la posibilidad de conexión manual.
En cualquier caso, tras intentar conectarse al módulo lector, se indicará si
la conexión ha sido establecida o no. Como la dirección MAC del sensor HC-05
está explı́citamente escrita en el código de la app, la conexión es directa si el módulo
lector está encendido. Si está apagado, la conexión no será posible.
86
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
La información relativa tanto al estado del Bluetooth como al estado de la
conexión se muestra al usuario a través de un par indicador-mensaje situado en la
zona inferior de la pantalla.
La figura 5.11 muestra el comportamiento descrito.
Figura 5.11: Lógica de conexión entre los módulos durante en Servicio.
87
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Cabe destacar la primera conexión entre ambos módulos tras encender el módulo
lector. Cuando éste último se enciende, entra en el primer estado, que es el de espera
a la sincronización. Dicha sincronización se requiere para que el módulo lector posea
información relativa a la fecha y la hora actual.
Cada vez que el usuario accede a la pantalla Servicio, si la conexión es establecida, se envı́a el código SYNC BT al lector, seguido de un String que contiene
la fecha y la hora en formato dd-MM-yyyy HH:mm. Este mensaje sólo es aceptado
e interpretado por el módulo lector si éste se encuentra en estado de espera a la
sincronización, esto es, tras encenderlo.
De este modo el módulo lector se sincroniza con la app simplemente con entrar
a la pantalla Servicio tras encenderlo, y a partir de ese momento, el módulo lector
lleva su propia cuenta de la hora y la fecha. Por tanto, sólamente es necesaria la
sincronización tras su encendido, motivo por el cual cabı́a destacar esta primera
conexión entre ambos módulos.
Una vez que los módulos han sido conectados y sincronizados, puede comenzar a
usarse el sistema como conjunto. Se han implementado 3 modos de trabajo distintos:
Modo manual: en este modo, el usuario puede generar consumiciones sin necesidad del módulo lector. Ası́, en caso de deterioro del lector, la app sigue
siendo funcional. Puesto que se trata de un modo que no se empleará de manera habitual, no se ha reservado espacio en la interfaz gráfica para él, sino
que se selecciona a través del menú de la pantalla Servicio.
Modo automático: cuando la app opera en modo automático, el lector está constantemente activo y esperando tags.
Los tags que son leı́dos lanzan un dialog personalizado que permite al usuario
validar las consumiciones. Estos dialogs se comentarán en detalle posteriormente. Ahora bien, si un dialog está abierto y el lector lee un nuevo tag, se
lanza un nuevo dialog, quedando el primero en segundo plano y por tanto
inaccesible hasta que se cierre el dialog que se ha sobrepuesto.
Esto es lo que se conoce como una pila de tipo LIFO (Last In First Out), pues
los dialogs más recientes son los que se lanzan por encima de los anteriores.
Esta lógica no es la apropiada para el interés de la app. En efecto, supuesta
una cola de residentes que se identifican, el orden de aparición de los dialogs
debe coincidir con el orden de los residentes, de manera que se pueda validar
sus consumiciones en dicho orden.
Por ello se busca el sistema contrario, esto es, una pila de tipo FIFO (First
In First Out), pues es la que permite una lógica como la que se precisa. Para
crearla se emplea una instancia de la clase LinkedList, pues combina las propiedades de la clase List (es necesario añadir y leer elementos) y de la clase Queue
88
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
(en concreto interesa el método remove, que ejecuta lo que serı́a un POP en la
pila). Además se ha implementado el método deQueue encargado de lanzar los
dialogs siguiendo el orden FIFO deseado. La integración de ambos se observa
en el extracto de código 5.7 que se ejecuta al recibir un tag del módulo lector.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
LinkedList<String> fifoDialogStack = new LinkedList<String>();
public void call(String s) {
...
//Si no hay codigos almacenados se llama
//a deQueue() para lanzar el dialog
if(fifoDialogStack.isEmpty()){
fifoDialogStack.add(s);
deQueue();
}
//Si hay, entonces hay un dialog abierto
//luego solo se mete el codigo a la pila
else{
fifoDialogStack.add(s);
}
...
}
Listing 5.7: Sistema FIFO en modo automático.
Los botones Aceptar y Cancelar del dialog eliminan el elemento actual de la
pila, y llaman a deQueue. De este modo, es el cierre de cada dialog el que va
llamando a deQueue para comprobar si quedan códigos registrados en la pila,
y en cuyo caso, lanzar dialogs según el orden de registro de dichos códigos.
Modo mixto: es el modo por defecto, que combina propiedades del manual
y el automático. Del manual hereda la necesidad de operar individualmente
mediante un botón. Del automático hereda la identificación del residente a
través del tag leı́do mediante el módulo lector.
En este modo, cada vez que el usuario pulsa el botón, el módulo lector se activa
durante 10 segundos. Si en ese intervalo se detecta un tag, entonces el lector
se desactiva, y la app lanza un dialog para la validación de la consumición. Si
transcurren los 10 segundos sin detección de tag, el lector se desactiva hasta
que se le vuelva a llamar, notificando al usuario mediante un AlertDialog que
se ha alcanzado el lı́mite de tiempo de espera.
Los diferentes modos de funcionamiento se representan en las figuras 5.12, 5.13
y 5.14. Los registros de las consumiciones realizadas durante el dı́a se muestran en
la pantalla en orden descendente segun la hora a las que fueron efectuadas.
89
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Figura 5.12: Modos de funcionamiento en servicio: modo manual.
Figura 5.13: Modos de funcionamiento en servicio: modo automático.
90
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Figura 5.14: Modos de funcionamiento en servicio: modo mixto.
Los dialogs de los que se ha hablado previamente son elementos emergentes
que ofrecen al usuario información y opciones. Hay 2 tipos de dialogs en la pantalla
Servicio, dependiendo del tipo de pensión del residente.
Ambos dialogs muestran los datos del residente: foto, nombre, apellidos, habitación, tipo de pensión y notas. Además, los de residentes asociados al régimen de
media pensión, muestran también el número de menús o desayunos (según el tipo
de consumición que se vaya a efectuar) restantes, ası́ como un par de botones que
permiten modificar el número de consumiciones a efectuar. Por otra parte, aparece
también la fecha y la hora, ası́ como 3 botones que permiten validar o denegar la
consumición (en caso de validar la consumición se envı́an al lector la habitación y el
número de menús o desayunos restantes tras la validación, o un mensaje de consumición validada dependiendo del tipo de pensión del residente, de manera que éste
está al tanto de su situación), ası́ como cambiar el tipo de consumición.
En relación a esto último cabe destacar que teniendo en cuenta los horarios
establecidos en los ajustes de la app, al generarse un dialog, éste deduce el tipo
de consumición que se va a hacer (desayuno, comida o cena). Si la consumición se
realiza fuera de horarios, se ha de introducir manualmente el tipo.
Por último mencionar que la app informa al usuario si una consumición es
aceptada o no mediante un mensaje Toast y una alerta sonora. En concreto, se
denegará una consumición a los residentes de pensión completa si en el mismo dı́a
91
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
ya se ha validado una consumición del mismo tipo, y a los residentes de media
pensión si en el tercer trimestre, el número de consumiciones de un determinado
tipo es 0. Esto no es decisión del desarrollador, sino que es la polı́tica de la cafeterı́a.
La figura 5.15 muestra dos ejemplos de estos dialogs.
(a) Media pensión.
(b) Pensión completa.
Figura 5.15: Tipos de dialogs en función de la pensión del residente.
5.1.2.6.2.
Opciones
El menú de opciones de la app, mostrado en la figura 5.16, es el que se abre
una vez se introduce la contraseña correcta en la pantalla principal tal y como se
describió anteriormente.
Se comentará a continuación cada una de las funcionalidades implementadas a
las que se accede desde este menú.
92
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Figura 5.16: Menú de opciones de la app.
Tags
Esta opción muestra al usuario la pantalla TAGs, que contiene la lista de habitaciones y el código del tag asociado a ellas, o un mensaje informando de que no
hay un tag asociado en caso contrario.
Al pulsar sobre una habitación determinada, se genera un menú popup que
puede ser de dos tipos:
Si la habitación no tiene un tag asociado, el menú contiene una única opción:
introducir TAG. Tras leer un tag, el usuario introduce un número de habitación
al que asociarlo. Si el número es válido, la asociación se habrá realizado con
éxito.
Si la habitación tiene un tag asociado, el menú contiene dos opciones: modificar
TAG y eliminar. La modificación es similar al proceso de introducción. La
eliminación borra el código asociado a la habitación (requiere autorización).
El menú de esta pantalla muestra 3 opciones más:
93
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Búsqueda: aparecen un campo de texto en la action bar y un teclado numérico,
posibilitando la búsqueda de una habitación concreta.
Resetear lista: elimina todos los códigos almacenados (requiere confirmación).
Comprobar TAG: muestra la habitación a la que está asociado un tag que se
pase por el módulo lector (o informa de que no es un tag conocido).
Las opciones de introducir, modificar y comprobar tags lanzan una nueva pantalla gestionada por la activity newTagRoom. Se trata de una activity que tiene
como misión leer un tag del módulo lector y ejecutar una acción con el código leı́do.
Por ello y tal como se mostraba en la figura 5.7, newTagRoom requiere el uso del
Bluetooth, por lo que solo se lanzará la pantalla si el dispositivo tiene activado el
Bluetooth y si está encendido el módulo lector. En caso contrario, se mostrará un
mensaje Toast al usuario indicando el motivo (Bluetooth desactivado o lector no
encontrado).
El funcionamiento general se resume en la figura 5.17.
Figura 5.17: Opciones relativas a los tags.
94
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Residentes
Desde la pantalla Residentes se muestra una lista similar a la de la pantalla
TAGs, con la lista de habitaciones, pero en este caso, la información mostrada es un
resumen de los datos del residente asociado a cada una de ellas.
El menú de opciones de esta pantalla permite realizar 4 operaciones:
Búsqueda: similar al análogo de la pantalla TAGs, pero con la diferencia de
que en este caso permite realizar búsquedas por nombre, por apellido y por
número de habitación.
Resetear lista: elimina los datos de todos los residentes (requiere confirmación).
Ronda de tickets: lanza un dialog personalizado que permite al usuario indicar un número de menús y un número de desayunos que añadir a todos los
residentes asociados al régimen de media pensión. La lista de estos residentes
también se muestra en el dialog. Esta funcionalidad está pensada para ser empleada tras abonar los residentes las cuotas de un trimestre, pues esto les da
derecho a 30 menús y 20 desayunos mensuales. Por tanto se evita tener que
aumentar estos parámetros manualmente.
Cambio de habitación: si bien un residente está asociado a una habitación, esto
no es algo fijo. Pueden haber mudanzas a habitaciones vacı́as, intercambios
consentidos entre dos o más residentes, etc. Por ello se han implementado dos
tipos de cambios:
• Cambio individual: el usuario selecciona un residente de la lista completa,
y a continuación emerge un dialog con un campo de texto en el que
ha de introducir el número de habitación a la que se va a mudar dicho
residente. Este modo está pensado para el caso más habitual entre los
cambios que se producen: mundanzas a habitaciones vacı́as. Por ello, si
la nueva habitación está asociada a otro residente, se informa mediante
un AlertDialog al usuario de que si confirma el cambio, se eliminarán los
datos asociados al residente que hasta ahora ocupaba la habitación.
• Cambio general: en este caso, el usuario puede modificar los números de
habitación de la lista completa de residentes, pudiendo modificarse todas
las habitaciones que se deseen. Para que la modificación sea efectiva, la
app comprobará si todos los números de habitación son válidos y si no hay
ninguno repetido, en cuyo caso, informará al usuario del error encontrado,
de manera que en ningún caso se asocie a un residente a una habitación
inexistente (y por tanto sin tag asociado) ni a dos o más residentes a la
misma habitación.
Estas funciones quedan representadas en la figura 5.18
95
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Figura 5.18: Opciones relativas a los residentes.
Expuestas las funcionalidades generales, se comentan a continuación las funcionalidades relativas a cada residente de manera individual. Pulsando en una habitación se lanza la pantalla Ficha de residente, que muestra la información relativa
al residente asociado a dicha habitación, o bien indica que la habitación está vacı́a,
como puede comprobarse en la figura 5.19.
(a) Habitación vacı́a.
(b) Habitación ocupada.
Figura 5.19: Fichas de residente.
96
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Como puede apreciarse también en dicha figura, cada tipo de ficha tiene unas
opciones distintas en el menú. Una habitación vacı́a posee únicamente la opción de
añadir un nuevo residente. Una habitación ocupada permite modificar los datos del
residente actual, eliminarlo, o ver su historial de consumiciones.
Esta última funcionalidad, mostrada en la figura 5.20, genera un mensaje con
el registro de consumiciones del residente indicando el número de consumiciones de
cada tipo ası́ como la fecha y la hora en la que se efectuaron.
Figura 5.20: Historial de registros de un residente.
Las opciones de añadir o modificar un residente lanzan la pantalla Nuevo residente, mostrada en la figura 5.21. Esta pantalla posee un formulario en el que se
pueden introducir los datos pertinentes.
Al acceder desde una habitación vacı́a, el formulario de esta pantalla está vacı́o
y han de rellenarse al menos el nombre, el apellido y el tipo de pensión para que la
ficha sea válida.
Si se accede desde una habitación ocupada, el intent que lanza la pantalla
contiene la información del residente asociado a la habitación, mostrándose sus datos
en el formulario.
97
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Figura 5.21: Pantalla para añadir un residente o modificar sus datos.
Archivos
Desde la pantalla Archivos el usuario puede realizar operaciones que se enmarcan en las siguientes categorı́as:
1. Registros: ofrece una serie de funciones relativas a los registros de las consumiciones. Presentadas en las figuras 5.22 y 5.23, se comentan a continuación:
Ver historial: lanza la pantalla Historial, que muestra todos los registros almacenados. Además, manteniendo pulsado un registro en concreto
emerge un menú contextual que permite ver información detallada del
registro, ver el historial de registros del residente, y eliminar el registro.
Actualizar ficheros: genera ficheros txt y los almacena en los directorios
creados para tal fin en la tarjeta SD, como se detalló en la sección relativa
al almacenamiento local. También guarda en formato txt la lista de la
compra.
Ver copias de seguridad: muestra un calendario de manera que al seleccionar un dı́a, emerge un AlertDialog que muestra el registro de consumiciones de dicho dı́a. La información es presentada atendiendo a las preferencias del cliente: número total de consumiciones, número y desglose de
desayunos, comidas y cenas.
98
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Figura 5.22: Opciones relativas a los registros: historial y visualización de backups.
Figura 5.23: Opciones relativas a los registros: generación de backups.
2. Estadı́sticas: esta opción lanza la pantalla Estadı́sticas, desde la cual el usuario
puede generar una serie de gráficas que el cliente estimó interesantes. En esta
pantalla entra en juego la biblioteca aChartEngine que se presentó anteriormente.
99
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Las gráficas pueden personalizarse atendiendo a diferentes parámetros:
Estilo de gráfica: se pueden generar gráficas de lı́neas, barras o tartas. Las
lı́neas son adecuadas para representar evoluciones temporales de las consumiciones de cara a analizar los picos de demanda. Las barras y las tartas
son interesantes de cara a comparaciones del número de consumiciones
de cada tipo que se han validado.
Tipo de consumición: pueden generarse gráficas exclusivamente para desayunos, comidas o cenas, ası́ como gráficas de todas en conjunto.
Perı́odo: en gráficas temporales pueden seleccionarse diferentes intervalos
de tipo: el dı́a actual, la última semana, el último mes, el último año o
un dı́a en concreto seleccionado desde un calendario que emerge análogamente al caso visto en la visualización de backups de registros.
En caso de seleccionarse un diagrama de tartas, se habilita el intervalo
Siempre, que tiene en cuenta todos los registros almacenados en la base
de datos.
Si el periodo escogido es el de un dı́a en concreto (dı́a actual o dı́a seleccionado del calendario), y además el tipo de consumición es también
concreto (desayunos, comidas o cenas, pero no todos en conjunto), entonces el eje horizontal de la gráfica es el horario establecido para dicho
servicio a intervalos de 15 minutos en comidas y cenas o de 30 minutos
en el caso de los desayunos.
La figura 5.24 muestra estas opciones de personalización de las gráficas que
ofrece la app, mientras que la figura 5.26 muestra algunos ejemplos de gráficas
que pueden generarse.
3. Lista de la compra: esta opción genera un AlertDialog que muestra como texto
la lista de la compra.
4. Restauración: permite restaurar ciertos parámetros a sus valores por defecto. Por tanto, elimina los registros, y fija los valores de los horarios, contraseña y número de menús y desayunos de los residentes de media pensión. Los
parámetros a restaurar pueden seleccionarse individualmente si se desea, y por
supuesto, la restauración requiere confirmación.
Las dos últimas opciones se muestran en la figura 5.25.
100
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Figura 5.24: Personalización de gráficas.
Figura 5.25: Restauración de datos y visualización de la lista de la compra.
101
5.1. APP ANDROID
(a) Diagrama de barras que
muestra el número de desayunos servidos en la semana actual.
CAPÍTULO 5. SOFTWARE
(b) Diagrama de lı́nea que muestra la evolución temporal de
comidas servidas durante el horario de servicio.
(c) Diagrama de lı́nea que
muestra el número de cenas
servidas en la semana actual.
(d) Diagrama de tartas que muestra una
comparativa entre el número de consumiciones servidas.
Figura 5.26: Ejemplos de gráficas generadas con la app.
Lista de la compra
Se trata de una pantalla que muestra los elementos añadidos por el usuario a la
lista de la compra. Los elementos están organizados por categorı́as, y cuentan con
un CheckBox de manera que son eliminados si éste está seleccionado cuando se pulsa
102
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
el botón de eliminar presente en el menú de opciones de la pantalla.
Los productos se añaden a la lista mediante una plantilla que se lanza mediante
el botón flotante de esta pantalla. La plantilla tiene los siguientes campos:
Nombre: es el atributo principal, que identifica el producto a añadir a la lista.
Categorı́a: es el nombre de la categorı́a en la que se incluirá el producto. Se
selecciona de una lista que incluye categorı́as predefinidas.
Cantidad y medida: son dos campos en los que se puede especificar cuánto
y en qué forma se ha de comprar un determinado producto. No es necesario
introducir estos datos si no se desea.
La figura 5.27 muestra el funcionamiento descrito de la lista de la compra.
Figura 5.27: Administración de la lista de la compra.
Instagram
La cafeterı́a cuenta con un perfil en la red social Instagram, en la cual suelen
subir imágenes de los platos que preparan. Por ello se ha implementado una activity
en la app desde la cual se pueden tomar fotografı́as y compartirlas.
La pantalla cuenta con un único botón que envı́a un intent que abre la cámara,
recibiendo además la imagen tomada desde la misma. Esta imagen se carga en el
ImageView que ocupa la mayor parte de la pantalla, apareciendo además 2 nuevos
botones.
103
5.1. APP ANDROID
CAPÍTULO 5. SOFTWARE
Ası́ pues, tras tomar una imagen se tienen 3 botones:
Tomar imagen: permite tomar una nueva imagen, que sustituirá la tomada
previamente.
Compartir en Instagram: la finalidad de este botón era en un principio la de
publicar la imagen en la red social. Sin embargo, Instagram no ofrece una
API que permita llevar a cabo este propósito, por lo que se ha cambiado la
funcionalidad del mismo. Se distinguen dos comportamientos:
• Si el dispositivo tiene instalada la app oficial de Instagram, se abre dicha
app y la imagen tomada se carga automáticamente en la pantalla previa
a la publicación. Esto es lo más próximo a la propia publicación debido
a la ausencia de una API de Instagram que lo permita.
• Si el dispositivo no cuenta con la app de Instagram, el botón abre Google
Play en la pantalla de la app Instagram para que el usuario la descargue
si lo desea.
Compartir: este botón carga una lista de todas las apps a través de las cuales
se puede compartir la imagen, generalizando la funcionalidad de compartir que
tiene la app.
La figura 5.28 muestra lo anteriormente descrito.
Figura 5.28: Pantallas destinadas a compartir imágenes tomadas desde la app.
104
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Backups
La última funcionalidad a la que se accede mediante un botón del menú de
opciones de la app es a la pantalla Backups. Esta pantalla (ver figura 5.4) es la
que ofrece las funciones de subida y descarga de la base de datos, y la información
relativa a ella se expuso al profundizar en el almacenamiento de la base de datos.
Ajustes avanzados
Por último se presenta la pantalla Ajustes avanzados, a la cual se accede desde
el menú de la pantalla del menú de opciones de la app.
Esta pantalla recopila los parámetros cuya modificación no encaja en ninguna
de las pantallas anteriores. Estos parámetros son los horarios de apertura y cierre
del servicio, los menús y desayunos trimestrales correspondientes a los residentes
asociados al régimen de media pensión, y la contraseña de acceso.
Pulsando en los valores de estos parámetros emergen dialogs personalizados. En
concreto, un reloj en el caso de los horarios, y un campo de texto numérico para los
demás.
La figura 5.29 muestra esquemáticamente el funcionamiento de esta pantalla.
Figura 5.29: Modificación de parámetros desde Ajustes avanzados.
105
5.1. APP ANDROID
5.1.2.7.
CAPÍTULO 5. SOFTWARE
Manifest
Como ya se adelantó en el capı́tulo 3, el Android Manifest es el documento más
importante de una aplicación. Describe la configuración básica de la app: activities
que contiene, nombre, hardware necesario, permisos...
Activities
Todas las activities que participan en la app están declaradas en el manifest.
Esto se realiza de manera distinta según el tipo de activity.
La declaración de la main activity, esto es, la activity que se lanzará al abrir
la app, se realiza mediante la estructura mostrada en el extracto del manifest 5.8.
Como puede observarse, esta activity incluye un intent que la identifica como la
actividad principal que ha de ser la mostrada al iniciar la app.
1 <activity
2
android:name=".Activities.HomeActivity"
3
android:label="Cafeteria RUGP">
4
<intent-filter>
5
<action android:name="android.intent.action.MAIN" />
6
<category android:name="android.intent.category.LAUNCHER" />
7
</intent-filter>
8 </activity>
Listing 5.8: Declaración de la activity principal.
La declaración de las restantes activities es similar a la anterior, con la diferencia
de no incluir el intent, como muestra el extracto de código 5.9. En la declaración de
estas activities se pueden especificar configuraciones relativas a ellas. En concreto
puede observarse en el extracto cómo la activity Servicio está fijada a una orientación
vertical mediante el atributo screenOrientation incluido en su declaración.
1
2
3
4
5
6
7
8
9
10
11
...
<activity
android:name=".Activities.Servicio"
android:label="Servicio"
android:screenOrientation="portrait">
</activity>
<activity
android:name=".Activities.Historial_registros"
android:label="Historial">
</activity>
...
Listing 5.9: Declaración de las activities no principales.
106
CAPÍTULO 5. SOFTWARE
5.1. APP ANDROID
Permisos
Algunas funcionalidades implementadas
en la app requieren ciertas capacidades del dispositivo que no pueden emplearse salvo que el
usuario lo consienta.
Para solicitar dicho consentimiento hay
que incluir en el Manifest los permisos necesarios. En el caso de la app de este trabajo,
son los siguientes:
Bluetooth: los permisos BLUETOOTH
y BLUETOOTH ADMIN son necesarios
para poder usar el Bluetooth del dispositivo y ası́ poder comunicar la app con
el módulo lector.
Almacenamiento: se necesitan los permisos READ EXTERNAL STORAGE y
WRITE EXTERNAL STORAGE para
poder leer y salvar datos en la tarjeta
SD del dispositivo, algo necesario para
el almacenamiento local que requiere la
app.
Internet: el permiso INTERNET hace
posible que la app acceda a la nube, al- Figura 5.30: Pantalla de aceptación
go necesario para el almacenamiento en de permisos previa a la instalación
de la app.
Google Drive implementado en la app.
El extracto del Manifest 5.10 muestra el código que reúne los permisos necesarios
para la app, algo que el usuario ha de aceptar al instalar la app, como muestra la
figura 5.30.
1
2
3
4
5
...
<uses-permission android:name="android.permission.BLUETOOTH"/>
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN"/>
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.
READ_EXTERNAL_STORAGE" />
6 <uses-permission android:name="android.permission.
WRITE_EXTERNAL_STORAGE"/>
7 ...
Listing 5.10: Permisos declarados en el Manifest.
107
5.1. APP ANDROID
5.1.2.8.
CAPÍTULO 5. SOFTWARE
Casos de uso
Una vez que se han expuesto todas las funcionalidades disponibles de la app,
se presentan en este apartado los casos de uso, como simplificación gráfica de las
mismas.
De este modo se presentan de manera resumida en la la figura 5.31 cada interacción que puede tener el usuario con la app, mejorando ası́ la comprensión global
sobre la app.
Figura 5.31: Casos de uso de la app.
108
CAPÍTULO 5. SOFTWARE
5.2.
5.2. MÓDULO LECTOR: FIRMWARE
Módulo lector: firmware
El módulo lector basado en Arduino que se ha desarrollado en este trabajo se
comporta según el firmware que lo gobierna. Dicho firmware es un sketch en Arduino
basado en una máquina de estados.
Un sketch de Arduino posee de forma genérica las siguientes partes:
Bibliotecas: llamadas a los ficheros .h necesarios.
Definiciones y declaraciones: creación de las constantes y variables necesarias.
Función setup: función que se ejecuta una única vez al arrancar el sistema.
Por tanto suele emplearse para tareas que supongan una única configuración
(inicialización de variables, objetos, etc).
Función loop: función que se ejecuta en bucle y que contiene la implementación
de la lógica del comportamiento del sistema.
Funciones auxiliares: funciones creadas por el desarrollador y que pueden ser
llamadas desde el setup o desde el loop.
Comentarios: anotaciones que mejoran la comprensión del código. No se cargan
en la placa, por lo que no ocupan memoria.
A nivel de programación, el módulo lector tiene menor complejidad que la app
presentada en la sección anterior. El desarrollo un firmware que permita el comportamiento necesario se basa en un diseño adecuado de la máquina de estados y una
correcta implementación del control de los módulos que forman el lector.
Es el objetivo de esta sección presentar dicho firmware. Para ello se profundizará en las partes más importantes del sketch.
5.2.1.
Bibliotecas
Al igual que ocurrı́a con la app, en el desarrollo del firmware del módulo lector
es recomendable el uso de bibliotecas externas puesto que evita horas de trabajo
en creación de funciones que no son estrictamente los objetivos del trabajo. Las
bibliotecas empleadas son las siguientes:
Bibliotecas para el control de los módulos: son las bibliotecas que se presentaron en el capı́tulo 4. Se enumeran de nuevo a continuación:
• LiquidCrystal para el display LCD.
• SoftwareSerial para el módulo Bluetooth HC-05.
• Wire, PN532, PN532 I2C y NfcAdapter para el módulo RFID-NFC.
109
5.2. MÓDULO LECTOR: FIRMWARE
CAPÍTULO 5. SOFTWARE
SMLib: biblioteca creada por un usuario del foro oficial de Arduino12 . Permite
implementar de un modo sencillo una máquina de estados. La máquina de
estados del firmware del módulo lector se expondrá posteriormente.
Time.h: biblioteca oficial de Arduino13 empleada para gestionar la hora y la
fecha. Como se comentó en la exposición de la app, se manda al lector la hora
y la fecha al sincronizar ambos módulos. Gracias a esta biblioteca, al recibir
estos datos, el propio módulo lector puede llevar la cuenta de la hora y la fecha.
5.2.2.
Configuración inicial: setup
Tras encender el módulo lector hay que realizar una serie de tareas antes de
que el sistema entre en régimen permanente de funcionamiento. Dichas tareas están
implementadas en la configuración inicial del sistema, que queda mayormente representada en la funcion setup, y que se enumeran a continuación:
Configurar los pines como entrada o como salida de manera que el circuito
expuesto en el capı́tulo 4 funcione correctamente.
Inicializar los objetos myBluetooth y nfc que permiten el control del módulo
HC-05 (empleando un puerto serie creado por software) y del módulo NFC
(conectado al puerto serie). Como se puede ver en el extracto de la función
setup 5.11 (supuestas declaradas las variables que intervienen), la inicialización
del puerto serie por sofware se hace a 38400 baudios debido a que es el baudrate
adecuado para el envı́o de comandos AT si se precisa. En el caso del módulo
RFID-NFC, son las bibliotecas las que se encargan de esto, limitándose el
desarrollador a llamar al método begin.
1 void setup(){
2
...
3
//Bluetooth
4
myBluetooth.begin(38400);
5
//NFC
6
nfc.begin();
7
...
8 }
Listing 5.11: Inicialización de los módulos Bluetooth y NFC.
Bloquear el módulo lector si no se detecta el lector NFC, mostrando un mensaje
en el display LCD alertando de la falta de detección de dicho lector.
12
Biblioteca
SMLib:
http://playground.arduino.cc/Code/SMlib,
//codebender.cc/library/SM
13
Biblioteca Time: http://playground.arduino.cc/Code/Time
110
https:
CAPÍTULO 5. SOFTWARE
5.2.3.
5.2. MÓDULO LECTOR: FIRMWARE
Ejecución: loop
Si la configuración inicial se ha realizado sin errores, entonces el sistema entrará a la función loop, en la que permanecerá hasta que se apague.
Cada vez que se ejecuta la función, se realizan 3 tareas:
1. Comprobar si la app ha mandado la información relativa a la fecha y la hora, y
en caso afirmativo generar un String con dicha información que se mostrará en
el display LCD.
2. Guardar en un String el código que reciba por Bluetooth desde la app. Los
diferentes estados de la máquina de estados tienen un comportamiento u otro
dependiendo del código almacenado en este String.
3. Llamar a la macro EXEC de la máquina de estados. Para entender el funcionamiento de la macro hay que describir la estructura de la máquina de
estados.
Sirva como base de la explicación la lı́nea de código 5.12. Dicha lı́nea indica
que se genera la máquina de estados Simple mediante la biblioteca SM, y que
se inicializa situándose en el estado S1.
1 SM Simple(S1);
Listing 5.12: Inicialización de la máquina de estados.
Cada estado tiene su implementación que incluye la lógica de su comportamiento. Se adjunta como ejemplo un fragmento de la implementación del estado
S1.
1 State S1(){
2
...
3
if(!tag.equals(tagOld)){
4
String s = tag.substring(0,7);
5
if(s.equals("SYNC_BT")){
6
...
7
Simple.Set(S2);
8
}
9
}
10 }
Listing 5.13: Ejemplo de implementación de un estado de la máquina de estados.
Fundamentalmente al llamar a la macro EXEC, se ejecuta la implementación
del estado en que se encuentre la máquina de estados.
111
5.2. MÓDULO LECTOR: FIRMWARE
CAPÍTULO 5. SOFTWARE
Puede comprobarse la implementación de la función loop en el código 5.14
(supónganse declaradas las variables que intervienen).
1 void loop(){
2
if(timeReceived){
3
time_t t = now();
4
dateTimeLCD = timeToString(t);
5
}
6
tag = readKey();
7
EXEC(Simple);
8
tagOld=tag;
9 }
Listing 5.14: Función loop.
Por lo explicado previamente, se deduce que la mayor parte de la lógica del
comportamiento del lector se encuentra en la implementación de los estados, y por
tanto la máquina de estados que gobierna el funcionamiento del módulo lector ha
de ser expuesta llegados a este punto.
5.2.3.1.
5.2.3.1.1.
Máquina de estados
Diseño
La máquina de estados propuesta para el módulo lector
desarrollado en este trabajo se
ha realizado mediante la identificación de los requisitos que ha
de cumplir.
La escasa complejidad del
funcionamiento harı́a posible
resolver el problema con menos
estados de los que se han implementado. Sin embargo, por motivos estéticos de cara al usuario, se han incluido estados me- Figura 5.32: Máquina de estados del módulo lector.
ramente informativos para él.
Finalmente la máquina de estados cuenta con los 4 estados representados en
la figura 5.32. Las transiciones entre los estados se representan simplificadas, y se
comentarán con más detalle en el epı́grafe posterior.
112
CAPÍTULO 5. SOFTWARE
5.2.3.1.2.
5.2. MÓDULO LECTOR: FIRMWARE
Implementación
Estados
Las funcionalidades de los estados presentados en la figura 5.32 se recopilan a
continuación:
1. S1: es el estado de inicio, el que adopta el sistema tras el encendido. Su función
es indicar al usuario la necesidad de llevar a cabo una sincronización entre la
app y el módulo antes de que éste último quede operativo.
Esto se consigue mostrando en el display el mensaje Esperando a la sincronización y una pequeña animación en los laterales que alterna puntos. Esto
refuerza la sensación de que el sistema está esperando que ocurra algo, en este
caso que el usuario lo sincronice con la app.
2. S2: este estado es puramente estético, y se produce cuando la comunicación
entre app y lector se ha establecido. Puesto que esta comunicación es rápida,
la misión de este estado es mostrar una animación durante algunos segundos
que permita al usuario apreciar que la sincronización está siendo realizada.
Para ello el display muestra el mensaje Sincronizando... ası́ como una barra
de progreso. Esta barra se consigue mediante una concatenación de caracteres
negros. Una vez completada, se pasa al siguiente estado, como se muestra en
el extracto de código 5.15.
1 State S2(){
2
myLCD.print("Sincronizando...");
3
...
4
for(float i=0;i<16;i++){
5
myLCD.print((char)255);
6
delay((i/16)*400);
7
}
8
...
9
Simple.Set(S3);
10 }
Listing 5.15: Progreso de la sincronización.
3. S3: se trata del primero de los dos estados que gobiernan el funcionamiento
en servicio del módulo lector. Una vez se ha entrado en este estado, esto es,
la comunicación con la app se ha establecido, se supondrá que son los clientes
de la cafeterı́a los que hacen uso del mismo. Por ello este estado muestra un
mensaje de bienvenida en el display con la fecha y la hora como muestra la
figura 5.33.
113
5.2. MÓDULO LECTOR: FIRMWARE
CAPÍTULO 5. SOFTWARE
Figura 5.33: Mensaje en estado de espera.
Este estado es el estado de espera, pues únicamente se sale de él cuando el
usuario activa el lector desde la app (entiéndase activar como habilitar la
lectura de tags).
4. S4: el último estado es el segundo de los estados que gobiernan el funcionamiento en servicio del lector. Se entra a este estado cuando se recibe una orden
desde la app para activar el lector, esto es, cuando el usuario desee leer tags
mediante el lector, que supone la misión de este estado de cara a la app (al
usuario).
Además, de cara a los clientes, la misión de este estado es hacer entender
al cliente el proceder del módulo lector. Esto se consigue activando el led y
mostrando los siguientes mensajes por el display:
Bienvenido!
Acerca tu TAG: se muestra al entrar en el estado S4, independientemente
de si se entra en modo automático o mixto. En el caso de activarse en
modo automático, tras leer el tag no se vuelve a S3, sino que permanece en
S4, por tanto vuelve a aparecer este mensaje tras efectuar la consumición.
Mensajes para residentes asociados al régimen de media pensión: con
cada consumición validada el display muestra la habitación y el número
de menús o desayunos restantes mediante, respectivamente, los mensajes:
• Hab: XXX
Desayunos: XX
• Hab: XXX
Menús: XX
Mensajes para residentes asociados al régimen de pensión completa: con
cada consumición validada el display muestra un mensaje con una de las
siguientes estructuras:
• Hab: XXX
Desay. validada
114
CAPÍTULO 5. SOFTWARE
5.2. MÓDULO LECTOR: FIRMWARE
• Hab: XXX
Menu validado
• Hab: XXX
Cons no validada
Estos mensajes se muestran en la figura 5.34, y todos se reciben como un String
precedido del código CONS (abreviatura de consumición), de manera que es
este inicio del mensaje recibido el que hace saber al módulo lector que se ha
validado una consumición desde la app.
Figura 5.34: Mensajes mostrados en el display en S4.
Transiciones
Las transiciones entre los estados de la máquina de estados se presentaban
simplificadas en el diagrama de la figura 5.32. Cada transición va de un estado A
a otro estado B, de manera que la transición se establece en la implementación del
estado A.
Se detallan a continuación cada una de ellas:
1. S1 → S2: esta transición se lleva a cabo cuando la app manda el mensaje
de sincronización. Cabe recordar que la estructura de éste contenı́a el código
SYNC BT seguido del String con la fecha y la hora. Por tanto la transición se
lleva a cabo cuando dicho mensaje se recibe e interpreta, tal y como muestra
el extracto de código 5.16 perteneciente a la implementación del estado S1.
115
5.2. MÓDULO LECTOR: FIRMWARE
CAPÍTULO 5. SOFTWARE
1 State S1(){
2
...
3
if(!tag.equals(tagOld)){
4
String s = tag.substring(0,7);
5
if(s.equals("SYNC_BT")){
6
...
7
Simple.Set(S2);
8
}
9
}
10 }
Listing 5.16: Transición S1 → S2.
2. S2 → S3: esta transición se ejecuta cuando finaliza la animación de la barra
de progreso implementada en el estado S2. No requiere por tanto de un código
recibido por Bluetooth, pero sı́ que envı́a el mensaje SYNC OK de manera
que la app al recibirlo muestra un mensaje informando que la conexión ha sido
establecida con éxito.
La máquina de estados alterna los estados S3 y S4 a través de sendas transiciones que se ejecutan cuando se cumple alguna condición de las que se enuncian a
continuación
3. S3 → S4: esta transición es la que activa al lector. De este modo lo habilita
para la lectura de tags. Se ejecuta cuando la app envı́a uno de los siguientes
códigos:
WAKE READER: recibido cuando el funcionamiento en servicio es en
modo mixto y se pulsa el botón (ver figura 5.14). Este código también se
recibe desde la activity newTagRoom, que como se explicaba en la sección
anterior, también requiere comunicación con el módulo lector.
WAKE READER FOREVER: recibido cuando se activa desde la app
el modo automático de funcionamiento en servicio. Activa la bandera
reader forever (variable booleana) que indica la necesidad de no retornar
al estado S3.
4. S4 → S3: es la transición que se ejecuta cuando deja de ser necesario el uso del
lector para app. Se puede ejectuar cuando se cumplen diferentes condiciones
que se agrupan en dos categorı́as:
Desde la app: pueden recibirse por Bluetooth ciertos códigos que impliquen la desactivación del lector. Estos códigos son:
• EXIT NEWTAG: cuando la app funciona en modo mixto, se dispone
de un tiempo de 10 segundos para que el residente pase el tag por el
lector tras activarlo. Si se cancela esta espera, entonces se recibe este
116
CAPÍTULO 5. SOFTWARE
5.2. MÓDULO LECTOR: FIRMWARE
código, que hace retornar el sistema al estado de espera S3.
También se recibe al salir de la pantalla Servicio, pues en caso de
encontrarse en modo automático, si no se envı́a el código, el lector
quedarı́a activo.
Este código también se recibe cuando se sale manualmente de la
activity newTagRoom.
• FINISH AUTOMODE: si desde la app se desactiva el modo automático, se envı́a este mensaje al módulo lector. Además al recibir
este código se desactiva la bandera reader forever.
Desde el propio lector: pueden darse ciertas circunstancias no relativas a
la app que provoquen igualmente la desactivación del lector.
En efecto, y como ya se ha comentado previamente, en modo mixto la
activación del lector se mantiene durante 10 segundos, o hasta que se lea
un tag. En cualquiera de estos casos se retorna al estado S3.
Por tanto, ya sea por cumplirse el timeout o por ser leı́do un tag, se
desactiva el lector si éste trabaja en modo mixto. Cabe destacar que
cuando esto ocurre, el lector envı́a a su vez un código a la app, que puede
ser:
• TAG TIMEOUT: en caso de pasar 10 segundos activo en modo mixto
sin leer un tag. Esto hace que en la app emerja un mensaje informando de que han transcurrido 10 segundos sin que se reciba tag alguno.
• El tag leı́do en caso de que el residente pase su tag. Este código
es el que permite a la app identificar qué habitación, y por tanto,
qué residente es el que está pasando el tag.
Por útlimo, mencionar que durante la implementación del firmware del módulo
lector fueron creadas una serie de funciones auxiliares además de las nativas setup y
loop. Estas funciones son llamadas desde la implementación de los diferentes estados
presentandos en esta sección, y pueden consultarse en el sketch.
117
5.2. MÓDULO LECTOR: FIRMWARE
118
CAPÍTULO 5. SOFTWARE
Capı́tulo 6
EVALUACIÓN Y PROBLEMAS
Durante el desarrollo y la evaluación del sistema propuesto han surgido innumerables fallos de funcionamiento que han tenido que ser resueltos. Se presenta en
este capı́tulo una recopilación de los más relevantes, esto es, aquellos cuyo origen no
era demasiado evidente y que requisieron una considerable inversión de tiempo.
Al igual que en el capı́tulo anterior, se dividirá la exposición en dos partes,
comentando por separado las pruebas realizadas a ambos módulos que han permitido
la evaluación de sus comportamientos, ası́ como la detección y posterior solución de
los problemas encontrados durante dicha evaluación.
6.1.
6.1.1.
Módulo lector
Evaluación
La evaluación del comportamiento del módulo lector se puede dividir en dos
grandes bloques atendiendo al grado de desarrollo de la app de este trabajo.
6.1.1.1.
Primeras pruebas: BlueTerm
Cuando se realizaron las primeras pruebas al módulo, la app de este trabajo aún
no tenı́a completamente implementadas las funcionalidades que permiten el control
del Bluetooth. Por este motivo se recurrió a una app de un tercero para efectuar las
pruebas al módulo lector.
Las apps más interesantes para este caso son aquellas que emulan un terminal
que permite el envı́o y la recepción de texto por Bluetooth. La gama de apps disponi119
6.1. MÓDULO LECTOR
CAPÍTULO 6. EVALUACIÓN Y PROBLEMAS
bles con estas caracterı́sticas es muy amplia, por lo que se escogió la app BlueTerm 1
por sus buenas valoraciones en Google Play2 .
Cabe destacar dos pruebas realizadas mediante BlueTerm:
1. Emparejamiento con el HC-05: mediante la interfaz de búsqueda y emparejamiento de dispositivos de BlueTerm se pudo comprobar cómo el emparejamiento del dispositivo Android y el módulo adquirido era efectiva.
2. Comprobación del funcionamiento del HC-05: tenı́a por objetivo determinar si
el módulo adquirido operaba correctamente. La prueba constó a su vez de dos
fases:
Envı́o de datos: mediante la app se enviaron cadenas de texto que fueron
mostradas por el monitor serie del IDE de Arduino, comprobándose que
la recepción era correcta.
Recepción de datos: se creó un sketch que enviaba programáticamente cadenas de texto que se recibı́an y se mostraban en la terminal de BlueTerm,
comprobándose que la transferencia de datos era también correcta.
6.1.1.2.
Pruebas con la app
Tras comprobar la operatividad del HC-05, la implementación del control del
Bluetooth en la app se realizó de manera que la propia app fuera capaz de reproducir
las pruebas efectuadas con BlueTerm.
Las diferencias fundamentales respecto al modo de ejecutar dichas pruebas fueron:
Se programó un emparejamiento automático con el módulo lector, tal y como
se justificó en el capı́tulo anterior.
Se encapsuló la función de envı́o de datos en botones, de manera que cada
botón enviaba un código diferente.
Tras comprobar que la app era capaz de comunicarse correctamente con el módulo lector, se implementó la máquina de estados en éste. De este modo, combinando
la programación del firmware del lector y la app, se fue depurando el funcionamiento
de la máquina de estados hasta que se consiguió el comportamiento descrito en el
capı́tulo anterior. No obstante en este proceso surgieron algunos problemas que se
presentan, junto a otros, a continuación.
1
Sitio web: http://pymasde.es/blueterm/
BlueTerm en Google Play: https://play.google.com/store/apps/details?id=es.
pymasde.blueterm
2
120
CAPÍTULO 6. EVALUACIÓN Y PROBLEMAS
6.1.2.
6.1. MÓDULO LECTOR
Problemas encontrados
Los principales problemas que ocurrieron durante el desarrollo y evaluación del
funcionamiento del módulo lector son:
1. Fallos en los componentes que forman el lector: tal y como se comentó en
el capı́tulo 4, a medida que los componentes se adquirieron y recibieron, se
probaron. Sin embargo, en ciertas ocasiones las pruebas no pudieron realizarse
debido a comportamientos anómalos de los mismos.
El ejemplo más relevante es el caso del LCD, que mostraba completamente
oscurecidos los caracteres, y de un modo parpadeante. Tras comprobar que no
era un problema de ajuste del contraste, se determinó que era un fallo en la
soldadura de los pines, solucionando ası́ el problema.
2. Caracteres extraños en el LCD: los caracteres que el chip HD44780 puede
representar en el LCD son limitados, y no incluye, entre otros, los caracteres
con acento.
Al intentar mostrar un mensaje que contenga caracteres ajenos a los nativos,
el LCD muestra un caracter extraño. La solución se encontró en la propia
documentación del chip, la cual indica un método para crear pı́xel a pı́xel
caracteres personalizados. Puede comprobarse la función customO del sketch
a modo de ejemplo, que genera una ó.
3. Comandos AT en el HC-05: durante las pruebas realizadas al módulo Bluetooth compatible con Arduino se quiso modificar algunos parámetros (nombre, contraseña de emparejamiento, modo de funcionamiento...) mediante el
envı́o de comandos AT. Esto, siguiendo las instrucciones de la bibliografı́a, se
intentó a través de la consola del IDE de Arduino, o monitor serie. Sin embargo los mensajes que aparecı́an en él eran incomprensibles al ser cadenas de
caracteres aparentemente aleatorios.
La solución a este problema se encontró al recapacitar sobre el concepto de
baudrate expuesto en el capı́tulo 3. En efecto, el monitor serie de Arduino se
inicializa por defecto a 9600 baudios, mientras que el envı́o de comandos AT
se realiza a 38400. Ciertamente este valor es configurable, pero para modificarlo hay que enviarle un comando AT, por lo que al menos una vez hay que
inicializar el monitor serie a 38400 baudios. De este modo la comunicación fue
posible.
4. Funcionamiento anómalo de la máquina de estados: cuando se implementó la
máquina de estados, su funcionamiento no era el establecido en su diseño (ver
figura 5.32).
Por ejemplificar alguno de estos comportamientos erróneos, supóngase que en
121
6.1. MÓDULO LECTOR
CAPÍTULO 6. EVALUACIÓN Y PROBLEMAS
S3 se recibe el código WAKE READER. En ese caso se produce la transición
a S4. Supóngase ahora que se pasa un tag por el lector. Esto produce la desactivación del lector, por lo que vuelve a S3. En este punto, el lector deberı́a
permanecer en espera hasta nueva orden, sin embargo se encontró que volvı́a
a entrar en el estado S4.
Tras analizar el código se determinó que el origen del fallo residı́a en que el
código recibido se mantenı́a tras ser leı́do, y por tanto aunque en efecto se
retornaba a S3, en la implementación de S3 se volvı́a a leer el último código
recibido, que seguı́a siendo WAKE READER, y por tanto entraba de nuevo a
S4.
La solución a este problema consistió, ya no solo para el ejemplo anterior,
sino en general, en crear dos Strings que almacenan los códigos recibidos.
Al recibir un código, se almacena en un String. Posteriormente se ejecuta la
implementación del estado actual a través de la macro EXEC, y por último
se almacena en el segundo String. Este era el funcionamiento elemental de la
función loop, presentada en el capı́tulo anterior. Gracias a estas dos variables
String se puede garantizar que un código recibido sólamente se tiene en cuenta
una vez, mediante la protección presentada en el extracto de código 6.1, pues
implica que sólo se tendrá en cuenta si ambos Strings son diferentes, condición
que sólo se cumplirá la primera vez que se reciba un código.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
String tag, tagOld;
...
void loop(){
...
tag = readKey();
EXEC(Simple);
tagOld=tag;
}
...
State S3(){
if(!tag.equals(tagOld)){
...
Simple.Set(S4);
...
}
}
Listing 6.1: Lectura única de códigos recibidos por Bluetooth.
Hay que destacar que este método no serı́a efectivo si se necesitara detectar la
recepción de un mismo código varias veces seguidas. No obstante, este paradigma no se da en la máquina de estados diseñada, por lo que es válido para
resolver el problema.
122
CAPÍTULO 6. EVALUACIÓN Y PROBLEMAS
6.2.
6.2. CAFETERÍA RUGP
Cafeterı́a RUGP
Si bien el módulo del lado del usuario (cliente) a nivel hardware no requiere
de evaluación alguna al ser un dispositivo Android comercial, no ocurre lo mismo a
nivel software.
Entre los objetivos establecidos en el primer capı́tulo de esta memoria estaban
tanto la familiarización con el entorno de Android con el desarrollo de una app.
Como es habitual siempre que se inicia un aprendizaje de un lenguaje de programación, surgen innumerables errores y comportamientos inesperados que han de ser
solucionados.
No obstante, la bibliografı́a disponible en relación a Android ası́ como foros
de consulta han facilitado el desarrollo de la app, cuya evaluación y principales
problemas se presentan en esta sección.
6.2.1.
Evaluación
Las pruebas realizadas a la app se fueron llevando a cabo a medida que ésta se
desarrollaba. De este modo la app fue creciendo sobre sustentos sólidos. Las pruebas
tuvieron siempre un carácter similar: cada funcionalidad que se implementaba se
sometı́a a una evaluación que pretendı́a responder dos preguntas:
1. ¿Hace lo que tiene que hacer? Lo primero que se comprobaba era la eficacia
de la funcionalidad, de manera que hasta que el funcionamiento esperado no
se conseguı́a, no se pasaba a la siguiente fase.
2. ¿Hace algo que no tiene que hacer? Esto es, en general, más complicado. Se
trataba de buscar los puntos débiles a la app, esto es, buscar su fallo. Para ello
se usaba la funcionalidad de modo incorrecto. Por citar algunos ejemplos:
conectarse al lector sin estar éste encendido,
crear fichas de residentes sin completar todos los datos,
introducir texto cuando se espera un valor numérico,
etc.
Mediante estas comprobaciones se determinaban qué situaciones provocaban
errores y comportamientos anómalos en la app. De este modo se pudieron
corregir, resultando ası́ una app que además de funcionar, es robusta.
123
6.2. CAFETERÍA RUGP
6.2.2.
CAPÍTULO 6. EVALUACIÓN Y PROBLEMAS
Problemas encontrados
La exposición de todos los fallos que se produjeron durante el desarrollo de
la app de este trabajo serı́a demasiado extensa, por lo que se remite al lector a
la inspección del código, que es donde están implementadas las protecciones ante
posibles fallos.
Estos fallos han surgido tanto al evaluar las diversas funcionalidades de la app
(fallos de funcionamiento) como en la implementación de las mismas (fallos de implementación).
Los fallos de funcionamiento son precisamente los que se buscaban en la evaluación descrita previamente al comprobar si la app no hace lo que no debe hacer.
Los fallos de implementación de las funcionalidades son fallos cuyo origen está en
la incorrecta programación de las mismas. Al tratar de probar la app, aparecı́a en
un mensaje de error en la consola de Android Studio. Este mensaje indicaba el tipo
de error y dónde se producı́a. Gracias a esta información la solución de los fallos de
implementación fue más sencilla.
Por citar algunos ejemplos, se mencionan algunos de los fallos más relevantes
que surgieron durante el desarrollo de la app:
1. Pérdida de información al rotar el dispositivo: se comprobó cómo algunas activities perdı́an la información que mostraban cuando se cambiaba la orientación
del dispositivo.
Este fallo se observó en el formulario de creación de una ficha de residente
(al rotar el dispositivo, los campos del formulario se borraban, teniendo que
volver a rellenarlo) y en la activity Instagram (al rotar el dispositivo se perdı́a
la imagen tomada).
El origen de este fallo se debe al ciclo de vida de las activities (descrito en el
capı́tulo 3, véase la figura 3.8). Ante un cambio de orientación del dispositivo,
Android destruye la activity (onDestroy) y la crea de nuevo (onCreate), y por
ello se pierde la información.
De acuerdo con la prioridad de la información afectada (establecida en los
requisitos de la app), merece la pena desarrollar una solución más elaborada
o no.
La información relativa a los residentes es prioritaria ante la funcionalidad
de Instagram. Por ello la solución adoptada para ambos casos difiere. En el
caso de Instagram, se ha bloqueado la rotación del dispositivo, de manera
que aunque se cambie la orientación, la activity se mantiene. En el caso de la
ficha de residente, se ha implementado un método para que no se pierda la
información.
124
CAPÍTULO 6. EVALUACIÓN Y PROBLEMAS
6.2. CAFETERÍA RUGP
2. Mı́nima información: algunos comportamientos anómalos detectados tenı́an su
origen en la falta de información que se almacenaba en la base de datos.
Esta falta de información se produce cuando se crea un residente bien sin
nombre, bien sin tipo de pensión, cuando se añade un producto a la lista de la
compra sin nombre, etc.
Los comportamientos que deriva esta situación son entradas vacı́as y con mensajes erróneos en los RecyclerViews que muestran la información de la base de
datos. En efecto, si la información de la base de datos no es adecuada, lo que
verá por pantalla el usuario será anómalo.
Por este motivo la solución adoptada ha consistido en el establecimiento unos
contenidos mı́nimos que se han de introducir antes de almacenar un registro
en la base de datos. Ası́, un residente ha de tener al menos nombre, apellidos
y tipo de pensión, un producto de la lista de la compra ha de tener al menos
nombre y categorı́a, etc.
Si no se cumplen los mı́nimos, la app muestra un AlertDialog indicando qué información falta por introducir.
3. Actualización de los RecyclerViews: en la app hay numerosas listas que muestran información de la base de datos representadas en RecyclerViews. Esta
información puede ser modificada a su vez desde la app como ya se ha expuesto. El problema detectado fue que en algunos casos al modificar la base de
datos, no se actualizaban los RecyclerViews.
Para solucionar esto se encapsuló en un método el código que generaba el
RecyclerView. Además tuvo que tenerse en cuénta cómo y cuándo se podı́a
actualizar la RecyclerView correspondiente.
Cuando la base de datos se modificaba en una activity diferente a la que
contenı́a la RecyclerView, la actualización de la misma se pudo hacer sin más
que llamar al método desde el onResume de la activity. Ası́, al cerrar la activity
en la que la base de datos se modificaba, se llama al método, pues al volver
a la activity previa Android llama a onResume (como puede observarse en el
ciclo de vida en la figura 3.8).
Cuando la base de datos se modifica desde la propia activity que contiene la
RecyclerView, basta con llamar al método que la muestra tras la ejecución del
método que modifica la base de datos.
Como puede observarse, la mera exposición de 3 casos en los que se han buscado
soluciones a comportamientos anómalos de la app ya es considerablemente extensa.
Por ello es recomendable abstraerse de los problemas concretos y concluir que la
solución de estos fallos ha permitido garantizar una robustez más que aceptable de
la app desarrollada.
125
6.2. CAFETERÍA RUGP
CAPÍTULO 6. EVALUACIÓN Y PROBLEMAS
Con todo el sistema listo para ser usado, se pudieron realizar pruebas finales de
funcionamiento. Para ello se crearon una serie de residentes genéricos de diferentes
nombres, tipos de pensión y connotaciones (en algunos casos el campo Notas se
rellenaba y en otros no para comprobar que los dialogs mostraban correctamente la
información).
Estas pruebas finales consistieron en emplear el sistema presuponiendo que éste
estuviera ya finalizado. Esto se puede presuponer pues al llegar a este punto ya
se habı́an realizado numerosas pruebas unitarias expuestas a lo largo del capı́tulo.
Los resultados acompañaron a esta suposición. En efecto, fueron considerablemente
buenos, no encontrándose comportamientos anómalos más allá de algún carácter
extraño en el LCD, de fácil solución.
Ha de observarse que las figuras expuestas en el capı́tulo anterior son precisamente de esta fase de pruebas. Precisamente el llegar a dichas capturas (un ejemplo
representativo es el de las gráficas obtenidas) es lo que permite determinar cómo el
sistema se comporta adecuadamente ajustándose de manera robusta a los requisitos
establecidos.
Estas pruebas fueron realizadas junto al cliente (el jefe de la cafeterı́a), que
quedó encantado con el funcionamiento, lo cual supone un gran aliciente para considerar funcional el sistema desarrollado.
126
Capı́tulo 7
DIRECCIÓN DEL PROYECTO
Este capı́tulo pretende abordar el proyecto desde un nivel superior, englobando
los aspectos generales tras haber sido expuestos los detalles concretos en los capı́tulos
anteriores.
Con este propósito se emplearán determinadas técnicas propias de la Ingenierı́a
de Proyectos para abarcar el aquı́ presentado en su conjunto desde los puntos de
vista del alcance, temporal y económico.
7.1.
Gestión del alcance
Tras haber definido el alcance del proyecto (objetivos) en el primer capı́tulo y
el alcance del producto desarrollado (caracterı́sticas) en los capı́tulos siguientes, se
completa la exposición de la gestión del alcance mediante el estudio de la planificación.
La planificación del proyecto pasa por obtener una visión global del mismo (a
vista de pájaro). Para ello se emplea una técnica de planificación no temporal como
es la Estructura de Descomposición del Proyecto (en adelante EDP).
La EDP del proyecto posee un primer nivel de descomposición formado por los
grandes bloques en los que puede dividirse. Estos bloques son:
Dirección del proyecto.
Estudios previos.
Desarrollo del sistema.
Impactos.
127
7.1. GESTIÓN DEL ALCANCE CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
Una vez se tiene constancia de estos bloques fundamentales del proyecto, éste
es abordable desde el punto de vista de la planificación sin más que profundizar con
algo más de detalle en cada uno de los elementos del primer nivel o nivel superior
de la EDP.
La figura 7.1 muestra el primer nivel de la EDP formado por los grandes bloques
del proyecto identificados previamente.
Figura 7.1: Nivel superior de la EDP
Las figuras 7.2 y 7.3 exponen la EDP desglosada incluyendo los diferentes niveles y las actividades de cada subnivel.
128
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO 7.1. GESTIÓN DEL ALCANCE
Figura 7.2: Desglose de la EDP (1/2)
129
7.1. GESTIÓN DEL ALCANCE CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
Figura 7.3: Desglose de la EDP (2/2)
130
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
7.2.
7.2. GESTIÓN DEL TIEMPO
Gestión del tiempo
A diferencia de la planificación, la gestión del tiempo requiere del uso de técnicas
propias de programación temporal. En este caso se empleará el diagrama de Gantt
mediante la herramienta Microsoft Project (todos los derechos reservados).
Antes de profundizar en la exposición conviene diferenciar la programación temporal del presente trabajo entendido como proyecto, y la del producto desarrollado
en el mismo. En efecto, las actividades y su duración no son las mismas en ambos,
por lo que se presentan por separado.
El diagrama de Gantt del proyecto muestra un diario de las tareas realizadas
durante la elaboración de este trabajo, exponiendo el desglose de las mismas.
El diagrama de Gantt del producto muestra la programación temporal del proceso de producción del sistema desarrollado en el proyecto. Los plazos en este caso se
reducen al no requerir un diseño excesivamente distinto: basta con cambiar ciertos
aspectos para ajustarlos al negocio en el cual se implementarı́a el sistema.
Las figuras expuestas en esta sección son de dos tipos:
Tareas del diagrama de Gantt: desglose de las tareas con su identificador,
nombre, dı́as de duración, fecha de comienzo y fecha de finalización, respectivamente.
Diagrama de Gantt propiamente dicho: representa gráficamente la duración de
las tareas anteriores.
7.2.1.
Diagrama de Gantt del proyecto
A continuación se exponen las imágenes que representan el diagrama de Gantt
relativo a este trabajo entendido como proyecto.
131
7.2. GESTIÓN DEL TIEMPO
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
Figura 7.4: Diagrama de Gantt del proyecto: desglose de tareas.
132
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
7.2. GESTIÓN DEL TIEMPO
Figura 7.5: Diagrama de Gantt del proyecto: diagrama.
133
7.2. GESTIÓN DEL TIEMPO
7.2.2.
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
Diagrama de Gantt del producto
El sistema de identificación contactless desarrollado en este trabajo ha sido
aplicado al servicio de cafeterı́a de una residencia de estudiantes. Sin embargo este
tipo de sistemas está presente en multitud de establecimientos.
Resulta interesante desde esta perspectiva analizar la programación temporal de
la fabricación e instalación de sistemas de identificación similares al de este trabajo,
igualmente personalizados en función del cliente.
Se considerará una empresa genérica para esbozar la programación temporal de
la producción de un sistema de identificación. Supóngase que:
ya está instalada la fábrica para la producción,
la carcasa se imprime ajustándose a los requisitos del cliente,
los componentes electrónicos se compran (subcontratas),
se cuenta con suficientes componentes en stock, y
se dispone de una app como plantilla que se modificará atendiendo a los requisitos particulares del cliente.
La programación temporal de una empresa de estas caracterı́sticas se puede
efectuar mediante un razonamiento basado en la identificación de las fases que se
llevan a cabo desde la llegada del cliente hasta que el sistema está en funcionamiento:
1. Visita al lugar en el que el sistema será implantado: se buscará junto al cliente
la definición del alcance del sistema, es decir, su funcionalidad y el lugar donde
se colocarán el(los) lector(lectores).
2. Adaptación del producto: tras generar la oferta y presupuesto del proyecto al
cliente, se produce un tiempo de espera hasta que el cliente acepte y firme el
contrato. Este tiempo es variable dependiendo de la rapidez del cliente. Tras ser
efectuado el pedido, se procede (si es necesario modificar la plantilla) a diseñar
la carcasa y a adaptar firmware y app para cumplir los requisitos establecidos
en la fase anterior. Se comprobará el correcto funcionamiento del software y
finalmente ensamblarlo en la carcasa para proceder con las pruebas finales del
sistema.
3. Implementación del sistema: en la fase final del proyecto se incluyen las etapas
de instalación y puesta en marcha del sistema. Puede incluirse en esta fase
algún tipo de curso o charla sobre el uso del mismo al cliente y a los operarios,
por lo que se incluye una etapa de formación.
El diagrama de Gantt de la figura 7.6 recopila el razonamiento anterior. Se
observa en él la posibilidad de realizar en paralelo la programación del software
134
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
7.2. GESTIÓN DEL TIEMPO
mientras se imprime la carcasa, ası́ como el tiempo de holgura entre las fases 1 y
2 mecionado anteriormente. El tiempo estimado es de unos 3 dı́as, prolongable en
función del citado tiempo de holgura.
Figura 7.6: Diagrama de Gantt del producto.
135
7.3. GESTIÓN DE COSTES
7.3.
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
Gestión de costes
De manera análoga a lo que ocurrı́a en la gestión temporal, en la gestión de
costes ha de distinguirse entre la contabilidad del presente proyecto y el presupuesto que conlleva manufacturar el producto desarrollado, pues los costes en ambos
procesos difieren.
7.3.1.
Contabilidad del proyecto
En este apartado se detallan los costes asociados a la elaboración de este trabajo, especificando los gastos de personal, hardware y software implicados en él que
posteriormente servirán para plantear los capı́tulos del presupuesto.
Gasto de personal
En lo que al gasto de personal se refiere, el autor es quien ha jugado los diferentes roles durante el desarrollo del trabajo. Por ello se agrupan las horas invertidas
(aproximadamente 347 horas) que se han dedicado a las diferentes tareas en 4 categorı́as:
Análisis y consultas: se engloban aquı́ todas las tareas asociadas a la documentación previa, reuniones, definición del alcance y objetivos, establecimiento de
los requisitos... Esta categorı́a tiene una duración estimada de 30 horas.
Diseño: se incluyen aquı́ las tareas relacionadas con el diseño tanto del módulo lector (componentes necesarios, pcb, carcasa, prototipos) como de la app
(interfaz gráfica, arquitectura de la app). La duración estimada es de 53 horas.
Implementación: todas las tareas asociadas con la programación (app y firmware del lector) ası́ como el montaje de los prototipos y fabricación de elementos
computa una cantidad aproximada de 194 horas.
Redacción: la elaboración del presente documento se ha llevado a cabo en
aproximadamente 70 horas.
Por tanto el presupuesto parcial correspondiente al gasto del personal es el especificado en la tabla 7.1.
136
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
Num.
1.1
1.2
1.3
1.4
7.3. GESTIÓN DE COSTES
Presupuesto parcial no 1: Gastos de personal
Ud Descripción
Medición Precio Importe
h Analista
30
33.00
990
h Diseñador
53
33.00
1749
h Programador
194
25.00
4850
h Responsable de redacción
70
15.00
1050
Total presupuesto parcial no 1: Gastos de personal
8.639,00
Tabla 7.1: Presupuesto parcial del proyecto no 1: Gastos de personal.
Gasto de hardware
Si bien el usuario empleará su propio dispositivo Android, el módulo lector
está enteramente formado por componentes que no posee previamente, por lo que
se imputan al presupuesto.
Algunos de estos componentes eran propiedad del autor y otros fueron adquiridos para desarrollar el lector. En cualquier caso la tabla 7.2 muestra el coste correspondiente a los componentes necesarios que finalmente forman parte del módulo
lector. Obsérvese que no se incluye ni la PCB, al haber sido ésta obtenida por cortesı́a del departamento de Electrónica, ni la carcasa, al haber sido ésta impresa por
cortesı́a del departamento de Materiales.
Num.
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
Presupuesto parcial no 2: Gastos de hardware
Ud Descripción
Medición Precio Importe
uds Arduino NANO
1
33.30
33.30
uds Resistencias
3
0.03
0.09
uds Pines macho
25
0.078
1.95
uds Cables jumper hembra
25
0.057
0.86
uds Display LCD
1
3.52
3.52
uds Módulo Bluetooth HC-05
1
6.75
6.75
uds Sensor RFID-NFC pn532
1
10.36
10.36
uds LED RGB
1
0.90
0.90
uds Tags
130
0.63
81.90
Total presupuesto parcial no 2: Gastos de hardware
139,63
Tabla 7.2: Presupuesto parcial del proyecto no 2: Gastos de hardware.
137
7.3. GESTIÓN DE COSTES
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
Gastos de software
Durante el proyecto, se han utilizado diferentes herramientas para generar tanto
el código de la aplicación la documentación. Por ello se incluyen sus respectivas
licencias en el presupuesto parcial de la tabla 7.3, a pesar de que la mayorı́a son
gratuitas.
Num.
3.1
3.2
3.3
3.4
3.5
Presupuesto parcial no 3: Gastos de software
Ud
Descripción
Medición Precio Importe
licencia Arduino IDE
1
0
0
licencia Android Studio + SDK + APIs
1
0
0
licencia Microsoft Office 2013
1 129.00
129.00
licencia Microsoft Project 2013
1 493.00
493.00
licencia TexStudio
1
0
0
Presupuesto parcial no 3: Gastos de software
622,00
Tabla 7.3: Presupuesto parcial del proyecto no 3: Gastos de sofware.
Presupuesto de ejecución material
La recopilación de los apartados anteriores confecciona el siguiente presupuesto
de ejecución material:
Proyecto: sistema de identificación contactless
Capı́tulo
Capı́tulo 1: Gastos de personal
Capı́tulo 2: Gastos de hardware
Capı́tulo 3: Gastos de software
Presupuesto de ejecución material
Importe
8639,00
139,63
622,00
9.400,63
Tabla 7.4: Presupuesto de ejecución material.
Asciende el Presupuesto de Ejecución Material a la expresada cantidad de NUEVE MIL CUATROCIENTOS EUROS CON SESENTA Y TRES CÉNTIMOS1 .
1
Se ha expuesto el presupuesto con el formato UNE 157001.
138
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
7.3.2.
7.3. GESTIÓN DE COSTES
Presupuesto del producto
El presupuesto que ofrecerı́a una empresa por la implantación de un sistema de
este tipo en algún establecimiento difiere con el presentado en la sección anterior
que se referı́a a este trabajo entendido como proyecto.
En primer lugar, el gasto de personal incluye roles diferentes a los del proyecto.
Atendiendo a las fases vistas en la programación temporal (visita al cliente, adaptación e implementación del producto) los roles en una hipotética empresa serı́an,
respectivamente, los de comercial, desarrollador e instalador. Dichos puestos tendrı́an
un salario diferente, con lo que la relación gasto/hora varı́a.
En segundo lugar, el gasto de hardware no se desglosarı́a como en el visto
anteriormente, sino que contarı́a con la partida de los tags por un lado y el módulo
lector por otro, sin desglosar éste último en todos sus componentes. El precio del
módulo se calculará sumando el coste del material de la carcasa y las horas de
su diseño, los componentes electrónicos, la mano de obra durante el cableado y
ensamblaje...
En último lugar, el gasto de software consta de dos partidas:
Licencia de uso: la empresa habrı́a invertido tiempo y dinero en desarrollar
un firmware y una app plantilla que adaptarı́a a gusto del consumidor. Esta
inversión se recuperarı́a imponiendo una licencia por el uso de dicho software
(las licencias comenzarı́an amortizando para producir beneficios después, tras
recuperar la inversión).
Personalización del software: partida que incluye los gastos asociados a las
horas de adaptación de las plantillas a los requisitos del cliente.
Una vez calculado el presupuesto de ejecución material mediante la suma de los
capı́tulos anteriores, se establecerı́a el presupuesto que se entrega al cliente mediante
la fórmula:
Pf = Pem + G + B + I
donde:
Pf ≡ Presupuesto final.
Pem ≡ Presupuesto de ejecución material.
G ≡ Gastos generales.
B ≡ Beneficio que obtendrı́a la empresa.
I ≡ Imprevistos.
139
7.3. GESTIÓN DE COSTES
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
Al ser muy amplio el abanico de establecimientos en los que implantar un sistema de este tipo, se pondrá como ejemplo el presupuesto que una empresa entregarı́a
a la cafeterı́a de la Residencia Universitaria Gómez-Pardo para la implantación de
este sistema.
Presupuesto parcial no 1: Gastos de personal
Num. Ud Descripción Medición Precio Importe
1.1
h Comercial
6
33.00
198.00
1.2
h Desarrollador
35
12.00
420.00
1.3
h Instalador
7
30.00
210.00
o
Total presupuesto parcial n 1: Gastos de personal
828,00
Tabla 7.5: Presupuesto parcial del producto no 1: Gastos de personal.
Presupuesto parcial no 2: Gastos de hardware
Num. Ud Descripción Medición Precio Importe
2.1
uds Módulo lector
1
50.00
50.00
2.2
uds Tags
130
0.63
81.90
o
Total presupuesto parcial n 2: Gastos de hardware
131,90
Tabla 7.6: Presupuesto parcial del producto no 2: Gastos de hardware.
Num.
3.1
3.2
Presupuesto parcial no 3: Gastos de software
Ud
Descripción
Medición Precio Importe
licencia Firmware del lector y app Android
1
50.00
50.00
h
Personalización del software
5
75.00
375.00
Presupuesto parcial,no 3: Gastos de software
425,00
Tabla 7.7: Presupuesto parcial del producto no 3: Gastos de sofware.
Proyecto: instalación de un sistema de identificación contactless en la RUGP
Capı́tulo
Importe
Capı́tulo 1: Gastos de personal
828,00
Capı́tulo 2: Gastos de hardware
131,90
Capı́tulo 3: Gastos de software
425,00
Presupuesto de ejecución material
1.384,90
Tabla 7.8: Presupuesto de ejecución material del producto.
140
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
7.3. GESTIÓN DE COSTES
Para finalizar, al resultado anterior hay que añadir los restantes términos de la
fórmula del presupuesto. Estos valores son:
Gastos generales: partida destinada a ofrecer servicios auxiliares al cliente (soporte técnico, garantı́a, etc).
G = 200 ¤
Beneficio: suele calcularse como un porcentaje del presupuesto de ejecución
material. Para un valor del 15 %:
B = 207,7 ¤
Imprevistos: suele calcularse como un porcentaje del beneficio. Para un valor
del 10 %:
I = 20,77 ¤
Por tanto el presupuesto presentado al cliente asciende a:
P = 1,813,41 ¤
Figura 7.7: Representación gráfica del desglose del presupuesto.
141
7.3. GESTIÓN DE COSTES
CAPÍTULO 7. DIRECCIÓN DEL PROYECTO
142
Capı́tulo 8
LÍNEAS FUTURAS
El sistema desarrollado es susceptible de mejorar a pesar de haber obtenido
unos resultados que satisfacen los objetivos iniciales y cumplen las expectativas del
cliente. En este sentido se presentan 5 posibles lı́neas de mejora del sistema:
1. Portabilidad de la app Cafeterı́a RUGP a la plataforma iOS. De este modo
el sistema seguirı́a siendo funcional aunque el cliente cambie sus dispositivos
Android por terminales de Apple1 como el iPhone o el iPad.
2. Integrar varios de estos sistemas formando una red comunicada. Esto mejorarı́a
el sistema en momentos de saturación o en otras circunstancias (diferentes
zonas donde efectuar una consumición, catering en espacios abiertos, etc) en
las que se disponga de varios puntos de venta.
3. Modificar el método de asociación entre tags y habitaciones. Aunque la comunicación NFC es bidireccional, el sistema presentado se limita a leer tags y
programáticamente asociar los códigos a las habitaciones, por lo que la identificación de habitaciones se produce de manera indirecta. Esto mejorarı́a si la
propia app implementase una funcionalidad que permitiera al usuario escribir
en el tag la habitación a la que se asocia. Ası́ la lectura de la habitación serı́a
directa.
4. Creación de una app para los residentes complementaria al sistema. En la actualidad hay una gran cantidad de dispositivos móviles que cuentan con NFC,
de manera que puede ser interesante el desarrollo de una app para residentes.
Esta hipotética app podrı́a implementar funcionalidades como:
Escritura de datos en tags. Si el residente es quien se encarga de escribir
sus datos en el tag se agilizarı́a el proceso de modificación de la base de
1
Sitio web oficial: http://www.apple.com/
143
CAPÍTULO 8. LÍNEAS FUTURAS
datos para almacenar esta información. Cada tag identificarı́a al residente
que lo posee.
Sustitución del tag por el dispositivo. Si el dispositivo del residente posee
NFC, podrı́a usarse éste en lugar del tag para identificarse en el módulo
lector.
5. Comunicación entre ambas apps. Se ha comprobado en el sistema presentado cómo es posible establecer una sincronización entre dispositivos gracias a
información en la nube accesible desde ellos. Como extensión de esta funcionalidad, podrı́a considerarse la posibilidad de que tanto la app del cliente como
la hipotética app de los residentes estuviesen comunicadas a través de la nube.
De este modo los residentes podrı́an reservar una consumición sin necesidad de
identificarse en el lector. La nube almacenarı́a la cola de peticiones que serı́an
leı́das desde la app del cliente. Esto ayudarı́a además al cliente a tener una
mejor previsión y planificación de la actividad que tendrá durante el horario
de servicio.
144
Capı́tulo 9
CONCLUSIONES
Como se expuso en el capı́tulo 2, existen numerosas aplicaciones del NFC en la
actualidad. En concreto, la identificación basada en tecnologı́as inalámbricas está asimismo ampliamente implantada (baste mencionar el abono transporte del metro o
autobús).
Se ha desarrollado un módulo lector similar a los existentes y se ha creado un app
Android para, entre otras cosas, controlar dicho lector. El conjunto forma un sistema
de identificación contactless que cuenta con funcionalidades que van más allá de la
identificación, modernizando y agilizando al cliente la gestión de su negocio.
La realización de este trabajo ha sido posible mediante la integración de diferentes conocimientos y destrezas adquiridas a lo largo del Grado. Ası́, la programación
en C y orientada objetos ha sido esencial para la elaboración del firmware y la app
respectivamente, el diseño por computador a través de Catia ha permitido el diseño de la carcasa del lector, las técnicas de Ingenierı́a de Proyectos han permitido
contemplar globalmente el proyecto a nivel de planificación, programación temporal
y de costes, etc. Además, durante el desarrollo del trabajo se han adquirido otras
aptitudes tales como el diseño y fabricación de una PCB, la ejecución de tareas
de soldadura y verificación de circuitos, la programación de apps en Android, la
capacidad de encontrar ayuda en documentaciones oficiales, etc.
Este trabajo ha empapado al autor en la esencia de la naturaleza del ingeniero: la
resolución de problemas. En efecto, se detectó la necesidad de modernizar el sistema
de identificación de la cafeterı́a, y se consiguió no sólo resolver dicho problema, sino
crear una herramienta de gestión del negocio al cliente personalizada a gusto del
mismo, que la hace única frente a herramientas similares en el mercado.
El autor cierra tanto su Grado como su periodo en la residencia mediante una
humilde aportación a ésta, la cual ha sido su hogar durante aquél.
145
CAPÍTULO 9. CONCLUSIONES
146
Apéndice A
IMPACTOS
A.1.
Impacto ambiental
El sistema presentado en este trabajo ha permitido eliminar la identificación de
residentes y gestión de base de datos mediante papel y bolı́grafo para sustituirla por
un app compatible con dispositivos Android y un lector.
Cualquiera de los métodos predecesores (cuadernos con tablas, vales entregados
a los alumnos (más de 55.000 al año), etc) conllevaba un gasto considerable de
papel. Gracias al sistema desarrollado, se elimina el gasto del papel, generando ası́ un
impacto positivo sobre el medio ambiente.
El principal impacto ambiental durante el uso del sistema es el consumo energético del mismo, al estar basado en componentes electrónicos que necesitan electricidad
para funcionar. No obstante, el consumo energético del dispositivo Android y del
módulo lector no son excesivos, aunque no por ello deja de ser un impacto sobre el
medio ambiente.
El impacto ambiental de los componentes electrónicos es importante tanto en la
extracción de las materias primas como cuando dejan de ser útiles [13]. Cuando se
convierten en residuos, es importante un adecuado reciclaje de estos componentes,
pues contienen elementos que tienen riesgo de cara al medio ambiente por contaminación de espacios verdes, emisiones a la atmósfera de estos elementos tóxicos,
etc.
147
A.2. IMPACTO SOCIAL
A.2.
APÉNDICE A. IMPACTOS
Impacto social
Se pueden mencionar también algunos impactos que tiene el sistema desarrollado
desde la perspectiva social.
Por una parte, desde un punto de vista socioeconómico, el principal impacto
del sistema es la mejora de la productividad, si bien éste era el gran objetivo del
trabajo.
Además, este sistema es un aliciente para el atractivo del servicio de cafeterı́a,
y por extensión, de la residencia, favoreciendo con el conjunto de aspectos positivos de la misma a un aumento de la demanda de plaza en ella, lo cual repercute
positivamente en los ingresos.
Por otra parte, desde un punto de vista de sostenibilidad tecnológica, cabe
destacar la innovación que supone este trabajo en la cafeterı́a, que induce nuevas
capacidades en los usuarios sobre el uso de este tipo de sistemas.
Por último destacar como impactos positivos también a tener en cuenta la asequibilidad del producto ası́ como la robustez que se le ha conferido.
148
Bibliografı́a
[1] Arduino. Official website. http://arduino.cc.
[2] IES Bezmiliana.
Criptografı́a de reducción.
www.clubcientificobezmiliana.org/revista/index.
php?option=com_content&view=article&id=102%
3Aserie-criptografia-firmas-digitales&catid=28%
3Aarticulos&Itemid=39&limitstart=1, 2009.
http://
[3] SIG
Bluetooth.
http://www.bluetooth.com/Pages/
Bluetooth-Home.aspx, 2012.
[4] BotScience.
Historia
de
arduino
y
su
https://botscience.wordpress.com/2012/06/05/
historia-de-arduino-y-su-nacimiento/.
nacimiento.
[5] Android Developer. Dashboards. http://developer.android.com/
intl/es/about/dashboards/index.html.
[6] M.F. Carignano, P. Ferreyra. Tecnologı́a inalámbrica near field communication
y sus aplicaciones en sistemas embebidos. Congreso Argentino de Sistemas
Embebidos, 2011.
[7] NFC Forum. Especificaciones técnicas. http://members.nfc-forum.
org/specs/spec_list/#protts.
[8] NFC Forum. Nfc record type definition (rtd). technical specification. http:
//www.cardsys.dk/download/NFC_Docs/NFC%20Record%20Type%
20Definition%20(RTD)%20Technical%20Specification.pdf.
[9] Gigatecno.
Diferencias
y
similitudes
entre
nfc
y
bluetooth.
http://gigatecno.blogspot.com.es/2014/09/
diferencias-y-similitudes-entre-nfc-y.html.
[10] Comunidad
Informática.
69-como-funciona-bluetooth.
149
http://es.ccm.net/contents/
BIBLIOGRAFÍA
BIBLIOGRAFÍA
[11] Desvarı́os Informáticos. https://rooibo.wordpress.com/2008/10/
13/un-vistazo-profundo-a-bluetooth-y-su-seguridad/, 2008.
[12] Sakshat Virtual Labs. http://vlssit.iitkgp.ernet.in/ant/ant/9/
theory/.
[13] Janet
Lara.
Residuos
electrónicos.
http://
losresiduoselectronicos.blogspot.com.es/2010/03/
que-son-los-residuos-electronicos.html, 2010.
[14] F. Matı́a, A. Jiménez, R. Aracil, E. Pinto. Teorı́a de Sistemas. 4 edition, 2003.
[15] PROMETEC. http://www.prometec.net/bt-hc06/.
[16] James
Revelo.
Hermosa
programación.
//www.hermosaprogramacion.com/2014/10/
android-sqlite-bases-de-datos/, 2014.
http:
[17] Universität Rostock. http://www.amd.e-technik.uni-rostock.de/
ma/gol/lectures/wirlec/bluetooth_info/k2_sdap.html.
[18] J. Seguı́. Aplicaciones prácticas de nfc. http://www.3ciencias.com/
wp-content/uploads/2013/01/NFC.pdf, 2012.
[19] Telekitar.
Android:
versión
y
nivel
https://telekita.wordpress.com/2012/01/31/
version-de-android-y-nivel-de-api/.
de
api.
[20] Wikipedia. Android. https://es.wikipedia.org/wiki/Android.
[21] Palo Wireless. http://www.palowireless.com/bluearticles/cc1_
security1.asp, 2010.
[22] Xakata. 2011, el año de la tecnologı́a nfc. http://www.xatakamovil.com/
conectividad/2011-el-ano-de-la-tecnologia-nfc.
150