Trabajo Fin de Grado Grado en Ingeniería de las ...bibing.us.es/proyectos/abreproy/90265/fichero/TFG-Priscila_Crespo_Bolaños.pdf · 3 Trabajo Fin de Grado Grado en Ingeniería de

Equation Chapter 1 Section 1

Trabajo Fin de Grado

Grado en Ingeniería de las Tecnologías de

Telecomunicación

Diseño e implementación de una aplicación Android

para geolocalización.

Autor: Priscila Crespo Bolaños

Tutor: Juan Manuel Vozmediano Torres

Departamento de Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2015

2

3

Trabajo Fin de Grado

Grado en Ingeniería de Tecnologías de Telecomunicación

Diseño e implementación de una aplicación Android

para geolocalización.

Autor:

Priscila Crespo Bolaños

Tutor:

Juan Manuel Vozmediano Torres

Profesor titular

Departamento de Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2015

4

5

Trabajo Fin de Grado: Diseño e implementación de una aplicación Android para geolocalización.

Autor: Priscila Crespo Bolaños

Tutor: Juan Manuel Vozmediano Torres

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

6

Sevilla, 2015

El Secretario del Tribunal

7

A mi familia

A mis profesores

8

Resumen

Dada la importancia y la fuerza con la que se introducen las tecnologías en nuestra vida cotidiana, resulta

interesante pensar en maneras en las que dichas tecnologías pueden ayudarnos o facilitarnos tareas del día a día.

En este caso hemos diseñado e implementado una aplicación Android destinada a la localización de personas.

Esto resulta de gran interés a la hora de poder supervisar a los sectores de la población más vulnerables como

pueden ser las personas de la tercera edad o niños y adolescentes.

Se ha decidido realizar el desarrollo para la plataforma Android, que según un informe de IDC (International

Data Corporation), durante noviembre de 2013 ha superado la barrera del 80% en cuota de mercado mundial de

smartphones. Esto significa que 4 de cada 5 teléfonos vendidos hasta octubre montan el sistema operativo de

Google, frente al 15% con el sistema operativo iOS.

9

Abstract

Due to the importance of technologies and the fact that they are entered in our daily routine in force, it is

interesting to think about how they can help us make our life easier.

In this case we have designed and implemented an Android application with the objective of locate people. This

is of great interest when it comes to being able to monitor the most vulnerable sectors of the population such as

the elderly people or children and adolescents.

It has been decided to develop an application for the Android platform because according to an IDC

(International Data Corporation) report, in November 2013 has overcome the barrier of 80% global market share

of smartphones. This means that 4 out of 5 phones sold until October have the Google operating system,

compared to 15% with the iOS operating system.

10

Índice Resumen 8

Abstract 9

Índice de Tablas 13

Índice de Ilustraciones 16

1. Introducción 20 1.1. Motivación 20 1.2. Problema planteado 20 1.3. Soluciones existentes en el mercado 21 1.4. Solución planteada 22 1.5. Estructura de la memoria 23

2. Recursos 25 Recursos humanos 25 Recursos Hardware 25

2.2.1 Pc Portatil HP ProBook 4520s 25 2.2.2 Pc portátil MacBook 13 pulgadas (finales de 2009) 25 2.2.2. Teléfonos móviles 25

Recursos Software 26 Elaboración de diagramas y tablas 26 Procesadores de texto 27 Entornos de desarrollo 27

3. Visión Global del Sistema 28 3.1. Participantes y Roles implicados 28

3.1.1. Organizaciones 28 3.1.2. Personas 28

3.2. Objetivos del sistema 29

4. Requisitos del Sistema 32 4.1 Introducción 32 4.2 Requisitos de Información 32 4.3. Requisitos funcionales 35

4.3.1. Definición de los actores 38 4.3.2. Casos de usos 38

4.4. Requisitos no funcionales 52 4.5. Matriz de rastreabilidad 56

4.5.1. Matriz de rastreabilidad IRQ frente a Objetivos 56 4.4.2. Matriz de rastreabilidad UC frente a Objetivos 57

5. Análisis del Sistema 58 5.1. Análisis estático del sistema 58

5.1.1. Modelo estático: Subsistema de Gestión de mensajes e IPs 59 5.1.2. Modelo estático: Subsistema de Solicitud de localización 63 5.1.3. Modelo estático: Subsistema de Gestión de localización propia 74

5.2. Análisis dinámico del sistema 79 5.2.1. Acciones gestión de mensajes e IPs 79 5.2.2. Acciones de solicitud de localización 81 5.2.3. Acciones de gestión de localización propia 83

5.3. Prototipo del sistema 86

11

6. Diseño del Sistema 91 6.1. Clases: Subsistema de gestión de mensajes e IPs 91

6.1.1. ServidorUdp 91 6.1.2. ArgumentosRecibidos 92 6.1.3. Borrado 93 6.1.4. ElementoLista 93 6.1.5. EscribeFichero 93

6.2. Clases: Actividad principal 94 6.3. Clases: ContactosFragment 94 6.4. Clases: Base de datos 95

6.4.1. MySQLiteHelper 95 6.4.2. TablaLocalizo 96 6.4.3. TablaPermitidos 96

6.5. Clases: Subsistema de solicitud de localización 97 6.5.1. DetalleLocalizoFragment 97 6.5.2. ClienteUdp 98 6.5.3. RecibeUdp 99 6.5.4. Notificaciones 100 6.5.5. Temporizador 100 6.5.6. TemporizadorEnvio 101 6.5.7. ReceptorUdp 102 6.5.8. GestionaNotificacion 102 6.5.9. VerMapaFragment, AddressResultReceiver y AddressIntentService 102

6.6. Clases: Subsistema de gestión de la localización propia 103 6.6.1. DetallePermitoFragment 103 6.6.2. SmsReceptor y ObtenerLocalizacion 104

6.7. Clases: Interfaz gráfica 106

7. Implementación del Sistema 108 7.1. Escenario 108

7.1.1. Flujo de mensajes 108 7.2. Tipos de mensajes 110 7.3. Envío de mensajes 112 7.4. Aplicación Android 113

7.4.1. Obtención de la localización 113 7.4.2. Recepción y procesamiento de los mensajes 114 7.4.3. Mantenimiento del puerto UDP activo en el NAT 115 7.4.4. Notificaciones de la aplicación 116 7.4.5. Visualización del mapa 117 7.4.6. Permisos: AndroidManifest 118

7.5. Servicio Java 119 7.5.1. Recepción y procesamiento de los mensajes 119

8. Pruebas y validación 121 8.1. Pruebas manuales 121 8.2. Purebas automatizadas 125 8.3. Pruebas de aceptación 126

9. Estimación temporal 127 9.1. Estimación temporal a priori 127 9.2. Planificación temporal real 129

10. Conclusiones 132 10.1. Principales problemas enfrentados 132 10.2. Línea futura de desarrollo 132

12

10.3. Conclusión personal 134

11. Referencias 135

12. Anexo 136 12.1. Glosario de términos 136 12.2. Resultado de pruebas automatizadas 138

12.2.1. Prueba 15 138 12.2.2. Prueba 16 140

12.3. Manual de usuario 142 12.3.1. Instalación 142 12.3.2. Vista principal de la aplicación 144 12.3.3. Acceso a Agenda para agregar contactos 145 12.3.4. Eliminar un contacto de la lista de Localizados 147 12.3.5. Eliminar un contacto de la lista de Permitidos 148 12.3.6. Ver la localización propia 150 12.3.7. Solicitar la localización de un contacto 152 12.3.8. Configuración del servidor a usar 153

12.4. Ejemplos de funcionamiento 158 12.4.1. Localizar a un contacto 158 12.4.2. Localización de dos contactos 162

13

ÍNDICE DE TABLAS

Tabla 1 - Organizaciones 28

Tabla 2 - Participante: Alumna 28

Tabla 3 - Participante: Tutor del proyecto 29

Tabla 4 - Objetivos: OBJ-0001 30



Tabla 7 – IRQ-0001: Información de la agenda 32

Tabla 8 – IRQ-0002: Información de contactos que se localizan 33

Tabla 9 - IRQ-0003: Información de contactos permitidos 34

Tabla 10 - IRQ-0004: Información sobre el usuario solicitante 34

Tabla 11 - IRQ-0005: Información de localización 35

Tabla 12 - ACT-0001: Usuario final de la aplicación 38

Tabla 13 - UC-0001: Enviar mensajes desde/hacia cualquier IP 39

Tabla 14 - UC-0002: Recibir mensajes con independencia de IPs 40

Tabla 15 – UC-003: Establecer la IP y puerto del servidor 40

Tabla 16 - UC-0004: Eliminar contactos que no se quiera localizar 41

Tabla 17 - UC-0005: Agregar contactos a lista de localizados 42

Tabla 18 - UC-0006: Comenzar a localizar 43

Tabla 19 - UC-0007: Elegir tiempo con el que se reciben actualizaciones de localización 44

Tabla 20 - UC-0008: Localizar a verios contactos simultáneamente 45

Tabla 21 - UC-0009: Recibir notificaciones de localización 46

Tabla 22 - UC-0010: Localizar sólo a los contactos a los que no este localizando 46

Tabla 23 - UC-0011: Elegir contactos permitidos 47

Tabla 24 - UC-0012: Enviar localización propia 48

Tabla 25 - UC-0013: Modificar contactos permitidos (Agregar) 49

Tabla 26 - UC-0014: Modificar contactos permitidos (Eliminar) 50

Tabla 27 - UC-0015: Acceder al GPS del teléfono 51

Tabla 28 - UC-0016: Consultar localización propia 52

Tabla 29 - NFR-0001: Escalabilidad 53

Tabla 30 - NFR-0002: Interfaz 53

Tabla 31 - NFR-0003: Mantenibilidad 54

Tabla 32 - NFR-0004: Usabilidad 54

Tabla 33 - NFR-0005: Portabilidad 55

Tabla 34 - NFR-0006: Actualizaciones 56

14

Tabla 35 - TRM-0001: Matriz de rastreabilidad IRQ/Objetivos 56

Tabla 36 - TRM-0002: Matriz de rastreabilidad UC frente a Objetivos 57

Tabla 37 - TYP-0001: ServidorUdp 60

Tabla 38 - TYP-0002: ElementoLista 61

Tabla 39 - TYP-0003: Borrado 61

Tabla 40 - TYP-0004: ArgumentosRecibidos 62

Tabla 41 - TYP-0005: EscribeFichero 62

Tabla 42- TYP-0006: MainActivity 65

Tabla 43 - TYP-0007: DetalleMainFragment 65

Tabla 44- TYP-0008: ContactosFragment 66

Tabla 45 - TYP-0009: DetalleLocalizoFragment 66

Tabla 46-TYP-0010: TablaLocalizo 67

Tabla 47-TYP-0011: EntradaTabla 67

Tabla 48- TYP-0012: MySQLiteHelper 68

Tabla 49 - TYP-0013: ClienteUdp 70

Tabla 50 - TYP-0014: RecibeUdp 70

Tabla 51-TYP-0015: Temporizador 71

Tabla 52 - TYP-0016: TemporizadorEnvio 72

Tabla 53 - TYP-0017: Notificaciones 72

Tabla 54 - TYP-0018: GestionaNotificacion 73

Tabla 55 - TYP-0019: VerMapaFragment 73

Tabla 56 – TYP-0020: ReceptorUdp 74

Tabla 57-TYP-0021: DetallePermitoFragment 75

Tabla 58 – TYP-0022: TablaPermitidos 75

Tabla 59- TYP-0023: SmsReceptor 77

Tabla 60- TYP-0024: ObtenerLocalización 78

Tabla 61 – TYP-0025: LocalizacionPropiaActivity 79

Tabla 62 – Tabla Localizados 96

Tabla 63 – Tabla permitidos 97

Tabla 64 – Pruebas manuales: Prueba 1 121









15







Tabla 79 – Pruebas manuales: Prueba 16. 125

Tabla 80 – Pruebas manuales: Prueba 17. 125

Tabla 81 – Pruebas automatizadas: Prueba 18 125

Tabla 82 – Pruebas automatizadas: Prueba 19 126

Tabla 83 – Pruebas de aceptación: Prueba 20 126

Tabla 84 – Estimación a priori: Documentación 127

Tabla 85 – Estimación a priori: Obtención de información 127

Tabla 86 – Estimación a priori: Análisis 127

Tabla 87 – Estimación a priori: Diseño. 127

Tabla 88 – Estimación a priori: Implementación 128

Tabla 89 – Estimación a priori: Testeo y pruebas 128

Tabla 90 – Estimación a priori: Documentación final 128

Tabla 91 – Estimación a priori: Horas totales 128

Tabla 92 – Estimación real: Documentación 129

Tabla 93 – Estimación real: Obtención de información 129

Tabla 94 - Estimación real: Análisis 130

Tabla 95 – Estimación real: Diseño 130

Tabla 96 – Estimación real: Implementación 130

Tabla 97 – Estimación real: Testeo y pruebas 130

Tabla 98 – Estimación real: Documentación final 130

Tabla 99 – Estimación real: Horas totales 130

16

ÍNDICE DE ILUSTRACIONES

Ilustración 1 – Icono de Android 21

Ilustración 2 - Icono de la aplicación 'Seguimiento GPS' 21

Ilustración 3 - Icono de la aplicación 'Localizador Familiar & Chat’ 21

Ilustración 4 - Icono de la aplicación 'Wayo' 22

Ilustración 5 - Icono del entorno de desarrollo Eclipse 27

Ilustración 6 - Icono del entorno de desarrollo Android Studio 27

Ilustración 7 - Subsistemas 36

Ilustración 8 - Subsistema Gestión de mensajes e IPs 36

Ilustración 9 - Subsistema Gestión de la localización solicitada 37

Ilustración 10 - Subsistema Gestión de la localización propia 37

Ilustración 11 - Diagrama de clases: subsistema de gestión de mensajes e IPs. 59

Ilustración 12 - Diagrama de clases: Agregar contacto a lista de localizados 64

Ilustración 13 – Diagrama de clases: Proceso de localización 69

Ilustración 14 - Diagrama de clases: selección de contactos permitidos 74

Ilustración 15 - Diagrama de clases: envío de localización propia 76

Ilustración 16 - Diagrama de clases: Visualización de localización propia 78

Ilustración 17 – Envío y recepción de mensajes con independencia de IPs 80

Ilustración 18 – Configuración de IP y puerto del servidor 81

Ilustración 19 - Acción de agregar a un contacto a “Localizados” 82

Ilustración 20 - Acción de comenzar a localizar 83

Ilustración 21 - Acción de envío de localización propia 84

Ilustración 22 - Acción de modificar lista de "Permitidos" 85

Ilustración 23 - Acción de consultar localización propia 86

Ilustración 24 - Interfaz de usuario: Página principal 87

Ilustración 25 - Interfaz de usuario: Agregar contactos a las listas 87

Ilustración 26 - Interfaz de usuario: Lista de contactos que localizamos 88

Ilustración 27 - Interfaz de usuario: Opciones sobre contactos que localizamos 88

Ilustración 28 - Interfaz de usuario: Elección del tiempo entre notificaciones 89

Ilustración 29 - Interfaz de usuario: Contactos permitidos 89

Ilustración 30 - Interfaz de usuario: Mapa con la localización del contacto 90

Ilustración 31 - Clase ServidorUdp 92

Ilustración 32 - Clase ArgumentosRecibidos 92

Ilustración 33 - Clase Borrado 93

Ilustración 34 - Clase ElementoLista 93

Ilustración 35 - clase EscribeFichero 94

17

Ilustración 36 - Clase principal: ActivityMain 94

Ilustración 37 – Clase ContactosFragment 95

Ilustración 38 - Clase MySQLiteHelper. 95

Ilustración 39 - Clase TablaLocalizo y EntradaTabla 96

Ilustración 40 – Clase TablaPermitidos y EntradaTabla 96

Ilustración 41 – Clase DetalleLocalizoFragment 98

Ilustración 42 - Clase clienteUdp 99

Ilustración 43- Clase RecibeUdp 100

Ilustración 44 - Clase Notificaciones 100

Ilustración 45 – Clase Temporizador 101

Ilustración 46 – Clase TemporizadoEnvio 101

Ilustración 47 – Clase ReceptorUdp 102

Ilustración 48 - Clase GestionaNotificacion 102

Ilustración 49 - Clases VerMapaFragment, AddressResultReceiver, AddresIntentService 103

Ilustración 50 – Clase DetallePermitoFragment 103

Ilustración 51 – Clases SmsReceptor y ObtenerLocalización 105

Ilustración 52 - Clases de la interfaz gráfica I 106

Ilustración 53 – Clases de la interfaz gráfica II 107

Ilustración 54 – Escenario planteado 108

Ilustración 55 – Paso de mensajes en las solución elegida 109

Ilustración 56 – Obtención del serial de la Sim del teléfono 110

Ilustración 57 – Obtención del hash 111

Ilustración 58 – Llamada a la función getHash 111

Ilustración 59 – Envio de mensajes: Socket en el servidor 112

Ilustración 60 – Envio de mensajes: Socket en Android 112

Ilustración 61 – Envio de mensajes: Obtención de dirección destino en el servidor. 112

Ilustración 62 – Envio de mensajes: Obtención de dirección destino en Android 112

Ilustración 63 – Envio de mensajes: Envio del paquete UDP 113

Ilustración 64 – GoogleApi: Implementación de interfaces de callback() 113

Ilustración 65 – GoogleApi: Creación de GoogleApiClient 113

Ilustración 66 – GoogleApi: Obtención de coordenadas de latitud y longitud 114

Ilustración 67 – Espera de datos en Android 115

Ilustración 68 – Envio de SMS 115

Ilustración 69 – Creación del temporizador “esperaRefresco” 115

Ilustración 70 – Activación del temporizador de refresco 116

Ilustración 71 – Notificaciones: Error en la conexión con el servidor 116

Ilustración 72 – Notificaciones: Contacto no disponible 117

Ilustración 73 – Visualización de mapas Android 117

18

Ilustración 74 – Permisos para enviar, leer y recibir SMS 118

Ilustración 75 – Permisos para realizar operaciones de red 118

Ilustración 76 – Permisos para acceder a la localización 118

Ilustración 77 – Permiso para escribir en la memoria externa 118

Ilustración 78 – Permiso para poder leer los contactos de la agenda 118

Ilustración 79 – Permiso para acceder al estado del teléfono 118

Ilustración 80 – Permiso para controlar el estado de “activo” del teléfono 118

Ilustración 81 – Clave de Google para poder usar mapas 119

Ilustración 82 – aplicación registrada en la consola de Google 119

Ilustración 83 – Actualización de un elemento en el servidor 119

Ilustración 84 – Búsqueda de un elemento en el servidor 120

Ilustración 85 – Estimación a priori: Diagrama de Gantt 129

Ilustración 86 – Estimación real: Diagrama de Gantt 131

Ilustración 87 - Número UIT-T E.164 internacional para Redes. 133

Ilustración 88 – Estructura del proyecto que soporta varios lenguajes 133

Ilustración 89 – values-es/strings.xml 133

Ilustración 90 – values-fr/strings.xml 134

Ilustración 91 – Prueba 15: mensajes cada 5 minutos 138



Ilustración 94 – Prueba 16: SMS para comenzar (periodo 5 minutos) 140

Ilustración 95- Prueba 16: Recepción de localización cada 5 minutos 140

Ilustración 96 – Envío de SMS para comenzar (cada 15 minutos) 140

Ilustración 97 – Prueba 16: Recepción de mensajes cada 15 minutos 141

Ilustración 98 – Envio de SMS para comenzar (cada 30 minutos) 141

Ilustración 99 – Prueba 16: Recepción de mensajes cada 30 minutos 141

Ilustración 100 – Instalación: Permisos de la aplicación (I) 142

Ilustración 101 – Instalación: Permisos de la aplicación (II) 143

Ilustración 102 – Instalación: Aplicación instalada 143

Ilustración 103 – Manual de usuario: Splash de bienvenida 144

Ilustración 104 – Manual de usuario: Página principal 145

Ilustración 105 – Manual de usuario: Acceso a los contactos de la agenda 145

Ilustración 106 – Manual de usuario: Filtrado de contactos por nombre 146

Ilustración 107 – Manual de usuario: Agregar contactos a las listas 147

Ilustración 108 – Manual de usuario: Eliminación de un contacto que localizamos 147

Ilustración 109 – Manual de usuario: Confirmación de eliminación 148

Ilustración 110 – Manual de usuario: Eliminar contacto permitido 149

Ilustración 111- Manual de usuario: Confirmación de eliminación de contacto Permitido 149

19

Ilustración 112 – Manual de usuario: Acceso a localización propia 150

Ilustración 113 – Manual de usuario: Visualización de localización propia 151

Ilustración 114 – Manual de usuario: Localización propia no disponible 151

Ilustración 115 – Manual de usuario: Comienzo de la localización 152

Ilustración 116 – Manual de usuario: Elección del tiempo entre notificaciones 153

Ilustración 117 – Manual de usuario: Configuración Avanzada 154

Ilustración 118 – Manual de usuario: Configuración Avanzada-campos vacíos 154

Ilustración 119 – Manual de usuario: Configuración Avanzada-IP vacía 155

Ilustración 120 – Manual de usuario: Configuración Avanzada-Puerto vacío 155

Ilustración 121 – Manual de usuario: Configuración Avanzada-Puerto no numérico. 156

Ilustración 122 – Manual de usuario: Configuración Avanzada-Puerto fuera de rango 156

Ilustración 123 – Configuración Avanzada: IP y puerto correctos 157

Ilustración 124 – Configuración Avanzada: Guardando cambios 158

Ilustración 125 – Localizar a un contacto: Notificación error 158

Ilustración 126 – Localizar a un contacto: Detalle de la notificación de error 159

Ilustración 127 – Localizar a un contacto: Notificaciones 159

Ilustración 128 – Localizar a un contacto: Detalle de las notificaciones 160

Ilustración 129 – Localizar a un contacto: Ver mapa 161

Ilustración 130 – Localizar a un contacto: Notificación en el extremo localizado 161

Ilustración 131 – Localización de dos contactos: Notificaciones 162

Ilustración 132 – Localización de dos contactos: Aviso de fin de localización 162

Ilustración 133 – Localización de dos contactos: tiempo entre notificaciones 163

Ilustración 134 – Localización de un contacto: Mapa del contacto 1 163

Ilustración 135 – Localización de dos contactos: Mapa del contacto 2 164

Ilustración 136 - Localización de dos contactos: notificación en el extremo localizado (contacto 1) 164

Ilustración 137 – Localización de dos contactos: notificación en el extremo localizado (contacto 2) 164

20

1. INTRODUCCIÓN

1.1. Motivación

Como punto final a los estudios de grado, debemos ser capaces de enfrentarnos a problemas reales que

se nos planteen, proponiendo y diseñando distintas alternativas para darles solución.

En este proyecto, poniendo en práctica todos los conocimientos hasta ahora adquiridos a lo largo de la

carrera afronté un problema de diseño software y de comunicaciones, pudiendo así proporcionar una

solución al mismo usando tecnologías tales como Android y Java, a las que se les prevé un amplio futuro

en el sector de las Telecomunicaciones.

He optado por el desarrollo de una aplicación Android, ya que resulta evidente el creciente número de

usuarios de Smartphone que buscan distintas aplicaciones que les sean de utilidad en su día a día, siendo

yo misma usuario de un Smartphone con sistema operativo Android.

Otro aspecto a tener en cuenta en la elección de este trabajo fue el reto que para mí supuso adentrarme

en el aprendizaje en mayor profundidad del lenguaje de programación Java, del que no poseía un gran

conocimiento antes de la realización del proyecto.

1.2. Problema planteado

El objetivo de este proyecto es poner solución a un problema de geolocalización mediante desarrollo

de una aplicación Android. Es decir, lo que buscamos es obtener la localización geográfica del

dispositivo siempre y cuando éste posea conexión a internet

Se nos plantea el poder solicitar la localización de un contacto de la agenda, con una periodicidad

determinada por el usuario que desea localizar y que, con dicho, se reciban las actualizaciones de

localización a su teléfono durante un tiempo máximo.

“Concentra todos tus pensamientos en el

trabajo que estás haciendo. Los rayos de sol no

queman hasta que se concentran en un punto.”

-Alexander Graham Bell–

21

Ilustración 1 – Icono de Android

1.3. Soluciones existentes en el mercado

En este trabajo no estamos diseñando un tipo nuevo de aplicación. La geolocalización es un problema

que ya se había planteado previamente y se le había dado solución, por tanto tenemos ya disponible en

“Google Play” distintas aplicaciones que le dan solución. Algunas de ellas se nombran a continuación:

- Seguimiento GPS: Gratuita, con un número de instalaciones de 10.000.000 - 50.000.000 y una

puntuación de 4,3 sobre 5. Te permite localizar a tus contactos y ubicarlos en un mapa.

Ilustración 2 - Icono de la aplicación 'Seguimiento GPS'

- Localizador Familiar & Chat: Aplicación gratuita, con un número de instalaciones entre 100.000 –

500.000 y una puntuación de 4,1 sobre 5. Además de la funcionalidad propia de localización de

personas, añade otras funciones como son la mensajería, una lista de tareas a compartir con tus

contactos, un álbum familiar y un botón de pánico que al pulsarlo envía una notificación instantánea a

familiares indicándoles tu localización.

Ilustración 3 - Icono de la aplicación 'Localizador Familiar & Chat’

- Localizador de personas, Wayo: Aplicación gratuita, con un número de instalaciones entre 500.000 -

1.000.000 y una puntuación de 3,7 sobre 5. Al igual que la anterior, te permite enviar mensajes y mandar

22

mensajes de alerta. Además, tiene la opción de crear grupos o bloquear contactos a los que no quieres

que se le envíe tu localización.

Ilustración 4 - Icono de la aplicación 'Wayo'

1.4. Solución planteada

La solución que se ha planteado a este problema se centra únicamente en los aspectos de localización,

es decir, no se contemplarán aspectos como chat o grupos.

La aplicación se va a dividir en tres partes:

- “Localizo a…”: Es en la que tendremos una lista de todos los contactos a los que queramos

localizar, seleccionados previamente de nuestros contactos del teléfono.

- “Contactos Permitidos”: será la parte en la que podremos especificar a qué contactos les

permitimos obtener nuestra localización.

- Y por último, “Ver mi localización”: Nos da la opción de poder visualizar en el mapa nuestra

propia localización.

23

1.5. Estructura de la memoria

A continuación, se mostrará qué contenidos cubre esta memoria y su distribución dentro de la misma.

Punto 1. Introducción.

En este punto que acabamos de ver, se trata la motivación para llevar a cabo este trabajo y se expone el

problema así como la solución elegida.

Punto 2. Recursos

En este apartado se describirán los recursos que se han empleado en la elaboración del trabajo, tanto

hardware, software como humanos.

Punto 3. Visión global del sistema

En este punto se van a concretar los objetivos principales del desarrollo, así como los participantes del

mismo.

Punto 4. Requisitos del sistema

En este apartado se mostrarán los requisitos pedidos para el correcto funcionamiento de nuestra

aplicación.

Punto 5. Análisis del sistema

Una vez conocidos los requisitos del sistema, así como su funcionalidad, realizaremos un análisis del

sistema, aportando modelos estático y dinámico, así como el prototipo de la aplicación a desarrollar.

Punto 6. Diseño del sistema

En este apartado mostraremos el diseño que llevaremos a cabo para cada uno de los componentes de

nuestro sistema con el objetivo de que éste lleve a cabo la funcionalidad que se ha descrito en apartados

anteriores.

Punto 7. Implementación.

En este apartado, describiremos a nivel de código los aspectos más relevantes tenidos en cuenta en la

implementación del sistema para un correcto funcionamiento.

Punto 8. Pruebas y validación.

En este apartado, describiremos las pruebas que se han hecho para comprobar el correcto

funcionamiento del sistema.

Punto 9. Estimación temporal.

En este apartado se mostrará la estimación temporal hecha a priori, en comparativa con el tiempo real

dedicado a cada tarea.

Punto 10. Conclusiones.

En este apartado, incluiremos, tanto los principales problemas encontrados durante el desarrollo así

24

como las posibles mejoras de la aplicación.

Punto 11. Referencias.

Se proporcionarán las distintas fuentes consultadas para la realización del trabajo.

Punto 12. Anexos.

En este anexo se proporcionará un glosario de términos propios en la programación de Android, los

resultados correspondientes a las pruebas automatizadas, un manual de usuario para un correcto uso de

la aplicación y por último mostraremos algunos ejemplos de la aplicación en funcionamiento.

25

2. RECURSOS

ara la correcta realización de este proyecto ha sido necesario disponer de un conjunto de recursos humanos,

hardware y software que especificaremos a continuación.

Recursos humanos

A la realización de este proyecto contribuyen dos personas: una de ellas a modo de desarrolladora del mismo, y

la otra persona ejerce un papel de ayuda y tutelaje del proyecto, garantizando entre ambas que efectivamente se

cumplen los requisitos pedidos.

Priscila Crespo Bolaños. Alumna desarrolladora del proyecto.

Juan Manuel Vozmediano Torres. Tutor del proyecto.

Recursos Hardware

A continuación especificaremos los recursos hardware que se han necesitado en la realización del proyecto,

indicando también sus características.

2.2.1 Pc Portatil HP ProBook 4520s

- Procesador: Intel Celeron CPU P4500 1.87GHz.

- Memoria RAM: 3GB.

- Almacenamiento: 200GB.

- Gráficos (GPU): Intel HD Graphics.

- Sistema Operativo: Windows 8.1, Ubuntu 14.04 LTS

2.2.2 Pc portátil MacBook 13 pulgadas (finales de 2009)

- Procesador: Intel Core 2 Duo 2,26 GHz.

- Memoria RAM: 2GB 1067 MHz DDR3.

- Almacenamiento: 250GB

- Gráficos (GPU): NVIDIA GeForce 9400M 256 MB

- Sistema Operativo: OSX 10.9.5

2.2.2. Teléfonos móviles

2.2.2.1 Samsung GALAXY CORE2

Teléfono principal con el que se realizó el desarrollo de la aplicación.

- Número del modelo: SM-G355HN

- Versión de Android: 4.4.2 (KitKat)

- Capacidad total del dispositivo: 4GB

- Memoria RAM: 768 MB

- Procesador: Quad-Core 1.2GHz

- Tamaño: 480x800 píxeles, 4.5 pulgadas

- Batería: Li-Ion 2000mAh

P

26

2.2.2.2. Samsung GALAXY CORE PRIME

Teléfono empleado para la realización de pruebas de conectividad y comprobación del correcto funcionamiento

de la aplicación.

- Número de modelo: SM-G360F

- Versión de Android: 4.4.4 (KitKat)


- Memoria RAM: 1 GB

- Procesador: Quad-Core 1.3GHz



2.2.2.3. Sony Xperia Z1 compact

Teléfono empleado igualmente para realización de pruebas de la aplicación.

- Número de modelo: D5503

- Versión de Android: 5.0.2 (Lollipop)


- Memoria RAM: 2GB

- Procesador: Qualcomm MSM8974 Snapdragon 800 quad-core 2.2GHz

- GPU: Adreno 330



Recursos Software

Para poder llevar a cabo el desarrollo de este proyecto también nos hemos ayudado con algunas herramientas

software que explicaremos a continuación.

Elaboración de diagramas y tablas

Pencil Project

Herramienta de código abierto usada para crear mockups de aplicaciones. Nos sirvió para crear un diseño inicial

de las distintas pantallas de la aplicación.

Microsoft Visio 2013

Esta herramienta de Microsoft nos permite la creación de diagramas para simplificar información compleja,

proporcionándonos un conjunto completo de galerías de símbolos y formas.

Microsoft Project 2013

Se trata de un software de administración de proyectos, que emplearemos para realizar diagramas de Gantt para

organizar las tareas a lo largo del tiempo de desarrollo.

Herramienta REM

REM (REquirements Management), es una herramienta experimental gratuita de Gestión de Requisitos que nos

ayudará a soportar la fase de Ingeniería de Requisitos en este proyecto software.

27

Procesadores de texto

2.3.2.1. Microsoft Word 2013

Software que nos permitirá la redacción y modificación de documentos de texto con formato a lo largo del

desarrollo.

Entornos de desarrollo

Eclipse

Eclipse es una plataforma de desarrollo integrado (IDE), diseñada para ser extendida de forma indefinida a través

de plug-ins. No está definida para trabajar en un lenguaje de programación específico, pero goza de gran

popularidad entre la comunidad de desarrolladores Java.

Ilustración 5 - Icono del entorno de desarrollo Eclipse

En nuestro caso utilizamos la versión de Eclipse: Eclipse Luna SR2 (4.4.2).

Android Studio

Es un entorno de desarrollo integrado (IDE) diseñado específicamente para desarrollar en Android. Fue

anunciado por Ellie Powers el 16 de mayo de 2013 y la última versión estable de dicha plataforma es la 1.2.1.1

(12 mayo de 2015).

Ilustración 6 - Icono del entorno de desarrollo Android Studio

En este caso usamos la versión 1.0.2 de Android Studio (Diciembre de 2014).

28

3. VISIÓN GLOBAL DEL SISTEMA

n este apartado queremos mostrar una visión general del sistema donde se incluya qué personas van a estar

implicadas en su desarrollo así como qué objetivos se busca cumplir.

3.1. Participantes y Roles implicados

3.1.1. Organizaciones

Organización Departamento de Ingeniería Telemática

Dirección Camino de los Descubrimientos, s/n. 41092 Sevilla (España)

Teléfono +34 954487384

Fax +34 954487385

Comentarios Departamento para el cuál se realiza este proyecto

Tabla 1 - Organizaciones

3.1.2. Personas

Tabla 2 - Participante: Alumna

E

Participante Priscila Crespo Bolaños

Organización Departamento de Telemática

Rol Desarrollador

Es desarrollador Sí

Es cliente No

Es usuario No

Comentarios Alumna del Grado en Ingeniería de las Tecnologías de Telecomunicación que llevará a cabo este desarrollo como motivo de su Trabajo de Fin de Grado

29

Participante Juan Manuel Vozmediano Torres

Organización Departamento de Telemática

Rol Tutor de este Trabajo Fin de Grado

Es desarrollador No

Es cliente Sí

Es usuario Sí

Comentarios Profesor titular del departamento de Ingeniería Telemática. Será quien tutele el progreso de este proyecto.

Tabla 3 - Participante: Tutor del proyecto

3.2. Objetivos del sistema

En las siguientes tablas describiremos cuáles son los principales objetivos del sistema, que nos permitirán

abordar el problema de manera más sencilla y concreta.

OBJ-0001 Solicitud de localización

Versión 1.0 ( 24/05/2015 )

Autores Priscila Crespo Bolaños

Fuentes Juan Manuel Vozmediano Torres


Descripción El sistema deberá permitir a un usuario del mismo solicitar la localización de cualquiera de sus contactos

Subobjetivos [OBJ-0004] Gestión de personas que localizamos: El sistema deberá permitir al

usuario seleccionar de su agenda telefónica aquellos contactos de los que desee recibir información de localización

Importancia Vital

Urgencia Inmediatamente

Estado Validado

30

Estabilidad Alta

Comentarios Un usuario de la aplicación a través de su interfaz gráfica debe poder solicitar la localización de cualquiera de sus contactos guardados en la agenda

Tabla 4 - Objetivos: OBJ-0001

OBJ-0002 Recepción de localización

Versión 1.0 ( 24/05/2015 )




Descripción El sistema deberá proporcionarle al usuario las respuestas de localización a las solicitudes que éste haya realizado

Subobjetivos Ninguno

Importancia Vital


Estado Validado

Estabilidad Alta

Comentarios Una vez que un usuario lanzó una solicitud de localización hacia cualquiera de sus contactos, el sistema debe ser capaz de gestionar dicha solicitud y responder al usuario. Debemos ser capaces de representar en un mapa la información de localización recibida.


OBJ-0003 Envio de localización propia

Versión 1.0 ( 24/05/2015 )




Descripción El sistema deberá permitir al usuario el envio de la localización propia cuando sea solicitada

31

por cualquier contacto permitido

Subobjetivos [OBJ-0005] Gestión de personas que nos localizan: El sistema deberá permitir al

usuario determinar a qué personas les permite que se envíe su localización

[OBJ-0006] Independencia de IPs: El sistema deberá poder realizar el envio de notificaciones de localización independientemente de las IPs asignadas al emisor o al receptor de dicha notificación

Importancia Vital


Estado Validado

Estabilidad Alta

Comentarios Ninguno


32

4. REQUISITOS DEL SISTEMA

4.1 Introducción

En este apartado vamos a realizar el proceso conocido como Ingeniería de requisitos. Esto nos permitirá

identificar las necesidades del cliente respecto del software a desarrollar, pudiendo así llegar a una solución que

se adapte lo máximo posible a sus necesidades y expectativas.

Los requerimientos del sistema que veremos a continuación nos determinarán lo que hará el sistema, y definirán

las restricciones de su operación e implementación. Acotando así la problemática planteada.

4.2 Requisitos de Información

A continuación detallaremos los requisitos de información, que nos servirán para determinar con qué

información trabajará nuestro sistema y cómo debe de hacerlo.

IRQ-0001 Información de la agenda

Versión 1.0 ( 24/05/2015 )


Fuentes Priscila Crespo Bolaños

Dependencias [OBJ-0005] Gestión de personas que nos localizan

[OBJ-0004] Gestión de personas que localizamos

Descripción El sistema deberá almacenar la información correspondiente a la información de la agenda del usuario para poder mostrarle dicha lista de contactos a través de la interfaz gráfica de la aplicación. En concreto:

Datos específicos

Nombre

Número de teléfono

Importancia Vital


Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 7 – IRQ-0001: Información de la agenda

33

IRQ-0002 Informacion de contactos que se localizan

Versión 1.0 ( 24/05/2015 )



Dependencias [OBJ-0001] Solicitud de localización

[OBJ-0004] Gestión de personas que localizamos

Descripción El sistema deberá almacenar la información correspondiente a los contactos que un usuario determinado quiere localizar. En concreto:

Datos específicos

Nombre (el que figura en la agenda)

Teléfono

Importancia vital

Urgencia inmediatamente

Estado validado

Estabilidad alta

Comentarios Ninguno

Tabla 8 – IRQ-0002: Información de contactos que se localizan

IRQ-0003 Información de contactos permitidos

Versión 1.0 ( 24/05/2015 )




[OBJ-0003] Envio de localización propia

Descripción El sistema deberá almacenar la información correspondiente a los contactos a los que un determinado usuario les permite conocer la localización propia. En concreto:

Datos específicos

Nombre (el que figura en la agenda).

Teléfono.

34

Importancia Vital


Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 9 - IRQ-0003: Información de contactos permitidos

IRQ-0004 Información sobre el usuario solicitante

Versión 1.0 ( 24/05/2015 )



Dependencias [OBJ-0006] Independencia de IPs

Descripción El sistema deberá almacenar la información correspondiente al usuario que solicita la localización de un contacto. En concreto:

Datos específicos

IP con la que se realizó la solicitud

Puerto con el que se realizo la solicitud

Identificador del usuario que realizó la solicitud: hash (número SIM+puerto)

Importancia Vital


Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 10 - IRQ-0004: Información sobre el usuario solicitante

35

IRQ-0005 Información de localización

Versión 1.0 ( 24/05/2015 )



Dependencias [OBJ-0002] Recepción de localización

Descripción El sistema deberá almacenar la información correspondiente a la localización del usuario. En concreto:

Datos específicos

Latitud

Longitud

Dirección correspondiente a las coordenadas anteriores

Importancia Vital


Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 11 - IRQ-0005: Información de localización

4.3. Requisitos funcionales

Los requisitos que detallaremos a continuación nos darán información sobre el funcionamiento del sistema así

como de la interacción del mismo con su entorno.

Los mostraremos en forma de diagramas de casos de usos, separados para cada uno de los subsistemas.

36

Ilustración 7 - Subsistemas

Ilustración 8 - Subsistema Gestión de mensajes e IPs

37

Ilustración 9 - Subsistema Gestión de la localización solicitada

Ilustración 10 - Subsistema Gestión de la localización propia

Una vez mostrados las distintas interacciones entre nuestros subsistemas y los actores pasaremos a describirlos,

y a especificar más detalladamente los distintos casos de uso

38

4.3.1. Definición de los actores

En nuestro sistema vamos a tener un único actor, que será el usuario final de la aplicación.

ACT-0001 Usuario

Versión 1.0 ( 02/06/2015 )




Descripción Este actor representa a cualquier usuario final del sistema

Comentarios Ninguno

Tabla 12 - ACT-0001: Usuario final de la aplicación

4.3.2. Casos de usos

4.3.2.1. Subsistema Gestión de mensajes e IPs

UC-0001 Enviar mensajes desde/hacia cualquier IP

Versión 1.0 ( 02/06/2015 )




Dependencias [OBJ-0006] Independencia de IPs

[OBJ-0001] Solicitud de localización

Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando El usuario del sistema pulsa sobre el botón de "Comenzar a localizar"

Precondición -

Secuencia normal

Paso Acción

1 El actor Usuario (ACT-0001) Lanza la solicitud de localización hacia un contacto

39

2 El sistema envía dicha solicitud de manera correcta independientemente de la IP origen y la IP que se quiera localizar

Postcondición -

Excepciones Paso Acción

2 Si no se puede establecer la comunicación para solicitar la localización, el sistema notificará al usuario indicándole que la localización del contacto pedido no se ha podido realizar, de manera que éste pueda volver a intentar solicitar la localización nuevamente.

Importancia Vital


Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 13 - UC-0001: Enviar mensajes desde/hacia cualquier IP

UC-0002 Recibir mensajes con independencia de IPs

Versión 1.0 ( 02/06/2015 )





[OBJ-0006] Independencia de IPs

Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando se produce una respuesta hacia el usuario que lanzó la solicitud

Precondición Que se haya realizado previamente una solicitud

Secuencia normal

Paso Acción

1 El actor Usuario (ACT-0001) Solicita la localización de un contacto

2 El actor Usuario (ACT-0001) Recibe una respuesta de dicho contacto

Postcondición -

40

Importancia Vital


Estado Validado

Estabilidad Alta

Comentarios Tras el envío de una solicitud, la aplicación android debe quedarse a la espera de las posibles respuestas a la misma.

Tabla 14 - UC-0002: Recibir mensajes con independencia de IPs

UC-0003 Establecer la IP y puerto del servidor

Versión 1.0 ( 02/06/2015 )




Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desee cambiar la IP o puerto al que se conecta

Precondición -

Secuencia normal

Paso Acción

1 El actor Usuario (ACT-0001) cambia la IP y puerto del servidor al que se quiere conectar

Postcondición -

Importancia Importante


Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 15 – UC-003: Establecer la IP y puerto del servidor

41

4.3.2.2. Subsistema Gestión de la localización solicitada

UC-0004 Eliminar contactos que no se quiera localizar

Versión 1.0 ( 02/06/2015 )



Dependencias [OBJ-0004] Gestión de personas que localizamos

Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desee eliminar un usuario de su lista de “localizados”

Precondición Que el usuario se encuentre en la lista de contactos que se quieran localizar

Secuencia normal

Paso Acción

1 El sistema tiene al contacto a eliminar en la lista de localizados

2 El actor Usuario (ACT-0001) es capaz de eliminar a dicho contacto de esa lista

Postcondición -



Estado Validado

Estabilidad Alta

Comentarios Cualquier usuario de la aplicación debe de ser capaz en cualquier momento de eliminar los contactos que se encuentren en la lista de "Localizo a..."

Tabla 16 - UC-0004: Eliminar contactos que no se quiera localizar

UC-0005 Agregar contactos a lista de localizados

Versión 1.0 ( 02/06/2015 )



42


Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario quiera agregar a un nuevo contacto para localizarlo

Precondición -

Secuencia normal

Paso Acción

1 El actor Usuario (ACT-0001) Accede a su lista de contactos a través de la aplicación

2 El actor Usuario (ACT-0001) Una vez encontrado el contacto que desea, lo agrega a la lista de contactos localizados

Postcondición -


2 Si el usuario seleccionado ya está en la lista de contactos localizados, el sistema no

permite volver a agregarlo a dicha lista y notifica al usuario.



Estado Validado

Estabilidad Alta

Comentarios Cualquier usuario de la aplicación debe de ser capaz de agregar a cualquier usuario de su lista de contactos a la lista de localizados

Tabla 17 - UC-0005: Agregar contactos a lista de localizados

UC-0006 Comenzar a localizar

Versión 1.0 ( 02/06/2015 )






Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el

43

usuario pulsa el botón "Comenzar a localizar" de un contacto concreto

Precondición Que el contacto que se quiere localizar esté en la lista de localizados

Secuencia normal

Paso Acción

1 El actor Usuario (ACT-0001) selecciona al usuario que deseea de su lista de localizados, y pulsa sobre el botón "Comenzar a localizar"

Postcondición -


1 Si el usuario que se quiere comenzar a localizar ya está siendo localizado, el sistema deberá notificar al usuario que dicho contacto ya está siendo localizado, y no se

deberá volver a iniciar el proceso de localización de dicho usuario.

Importancia Vital


Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 18 - UC-0006: Comenzar a localizar

UC-0007 Elegir tiempo con el que se reciben actualizaciones de localización

Versión 1.0 ( 02/06/2015 )





Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario pulsa "Comenzar a localizar"

Precondición -

Secuencia normal

Paso Acción

1 El actor Usuario (ACT-0001) pulsa sobre el botón "Comenzar a Localizar"

44

2 El sistema proporciona tres tiempos entre notificaciones para elegir por el usuario

3 El actor Usuario (ACT-0001) indica cuál de esos tiempos es el que desea

Postcondición -


3 Si el usuario no indica ningún tiempo de los propuestos, el sistema tendrá un valor

por defecto para ese tiempo que será el que use.



Estado Validado

Estabilidad Alta

Comentarios Cuando un usuario quiere comenzar a localizar a alguno de sus contactos tiene la opción de elegir cada qué tiempo quiere recibir dicha información de localización

Tabla 19 - UC-0007: Elegir tiempo con el que se reciben actualizaciones de localización

UC-0008 Localizar a varios contactos simultáneamente

Versión 1.0 ( 02/06/2015 )





Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario esté localizando a un contacto, y quiera localizar a otro distinto

Precondición El usuario ya está localizando a un contacto determinado

Secuencia normal

Paso Acción

- -

45

Postcondición -



Estado Validado

Estabilidad Alta

Comentarios Un usuario puede localizar simultáneamente más de un contacto

Tabla 20 - UC-0008: Localizar a verios contactos simultáneamente

UC-0009 Recibir notificaciones de localización

Versión 1.0 ( 02/06/2015 )





Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario del sistema solicitó la localización de uno de sus contactos y se encuentra a la espera de datos.

Precondición Estar localizando a una/varias personas

Secuencia normal

Paso Acción

1 El actor Usuario (ACT-0001) solicita la localización de un contacto

2 El sistema vence el tiempo máximo

3 El sistema deja de enviar/recibir notificaciones de localización

Postcondición -



Estado Validado

46

Estabilidad Alta

Comentarios El usuario estará recibiendo información de localización de los contactos a los que localiza durante un tiempo máximo marcado por el sistema. Una vez superado este tiempo, el usuario tendrá que lanzar una nueva solicitud de localización.

Tabla 21 - UC-0009: Recibir notificaciones de localización

UC-0010 Localizar sólo a contactos a los que no este localizando

Versión 1.0 ( 02/06/2015 )




Dependencias [OBJ-0001] Solicitud de localización

Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando intentar localizar a un contacto que ya está siendo localizado

Precondición -

Secuencia normal

Paso Acción

- -

Postcondición -



Estado Validado

Estabilidad Alta

Comentarios Si un usuario está localizando a un contacto, no podrá volver a realizar una solicitud de localización hacia ese mismo contacto antes de que termine el tiempo en el que recibe información de localización el él.

Tabla 22 - UC-0010: Localizar sólo a los contactos a los que no este localizando

47

4.3.2.3. Subsistema de gestión de localización propia

UC-0011 Elegir contactos permitidos

Versión 1.0 ( 02/06/2015 )





Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario de la aplicación quiera agregar a algún contacto de su agenda para permitir que le localice.

Precondición -

Secuencia normal

Paso Acción

1 El actor Usuario (ACT-0001) accede a su lista de contactos a través de la aplicación

2 El actor Usuario (ACT-0001) elige un contacto de los de su agenda para agregarlos a la lista de permitidos

Postcondición -



Estado Validado

Estabilidad Alta

Comentarios Cualquier usuario de la aplicación debe de ser capaz de agregar a cualquier usuario de su lista de contactos a la lista de permitidos

Tabla 23 - UC-0011: Elegir contactos permitidos

UC-0012 Enviar localización propia

Versión 1.0 ( 04/06/2015 )


48



Dependencias [OBJ-0003] Envio de localización propia

[OBJ-0005] Gestión de personas que nos localizan

Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un contacto de mi lista de permitidos solicita mi localización

Precondición El contacto que solicita mi localización debe estar en mi lista de permitidos

Secuencia normal

Paso Acción

1 El sistema recibe una petición de localización de un usuario

2 El sistema comprueba que el contacto solicitante este en la lista de contactos permitidos del usuario

3 El sistema en caso de estar en la lista de permitidos, envía un mensaje de respuesta con la localización del usuario

4 El sistema notifica al usuario de que se va a enviar la localización al contacto que la solicitó

Postcondición -


3 Si El usuario no tiene al contacto en la lista de permitidos, el sistema envía un mensaje

al contacto indicándole que no tiene permiso para conocer la localización que solicita.

Importancia Vital


Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 24 - UC-0012: Enviar localización propia

49

UC-0013 Modificar contactos permitidos (Agregar)

Versión 1.0 ( 04/06/2015 )





Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desea agregar un contacto nuevo a su lista de permitidos

Precondición El usuario a agregar no debe de estar ya en la lista de permitidos

Secuencia normal

Paso Acción

1 El actor Usuario (ACT-0001) pulsa sobre el botón "Agregar contacto"

2 El actor Usuario (ACT-0001) selecciona el contacto deseado y pulsa "Agregar a Permitidos"

Postcondición -


2 Si el contacto a agregar a permitidos ya se encontraba en dicha lista, el sistema notificará al usuario de que dicho contacto no puede agregarse, ya que ya se

encuentra en la lista.



Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 25 - UC-0013: Modificar contactos permitidos (Agregar)

50

UC-0014 Modificar contactos permitidos (Eliminar)

Versión 1.0 ( 04/06/2015 )





Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario de la aplicación desea eliminar a uno de sus contactos agregados a la lista de permitidos

Precondición -

Secuencia normal

Paso Acción

1 El actor Usuario (ACT-0001) Selecciona de su lista de permitidos al contacto que desea eliminar

2 El actor Usuario (ACT-0001) Pulsa sobre dicho contacto, y selecciona la opción "Eliminar contacto"

Postcondición -

Importancia Vital


Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 26 - UC-0014: Modificar contactos permitidos (Eliminar)

UC-0015 Acceder al GPS del teléfono

Versión 1.0 ( 04/06/2015 )




51

Dependencias [OBJ-0003] Envio de localización propia

Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario quiera ver su localización, o se reciba una solicitud de localización

Precondición Querer visualizar la localización propia, o bien, haber recibido una petición de localización

Secuencia normal

Paso Acción

1 El sistema recibe una petición de localización de un contacto permitido, o el propio usuario pulsa sobre el botón "Ver mi localización"

2 El sistema Accede a la información de la red y al GPS del teléfono para poder obtener las coordenadas y la dirección.

Postcondición -


2 Si El sistema no es capaz de obtener latitud y longitud, el sistema muestra un mensaje

de error, indicando que no se ha podido obtener dicha información.

Importancia Vital


Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 27 - UC-0015: Acceder al GPS del teléfono

UC-0016 Consultar localización propia

Versión 1.0 ( 04/06/2015 )



Dependencias Ninguno

Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario pulsa sobre la opción de "Ver mi localización"

52

Precondición -

Secuencia normal

Paso Acción

- -

Postcondición -

Importancia Quedaría bien

Urgencia Puede esperar

Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 28 - UC-0016: Consultar localización propia

4.4. Requisitos no funcionales

Los requisitos no funcionales, o atributos de calidad, son aquellos requisitos que se pueden usar para juzgar la

operación de un sistema en lugar de sus comportamientos específicos (requisitos funcionales). Algunos ejemplos

de requisitos funcionales son los siguientes: rendimiento, disponibilidad, accesibilidad, usabilidad, etc.

NFR-0001 Escalabilidad

Versión 1.0 ( 04/06/2015 )




Descripción El sistema deberá ser fácilmente escalable ante un crecimiento en el número de usuarios


Urgencia Hay presión

Estado Validado

Estabilidad Alta

53

Comentarios Ninguno

Tabla 29 - NFR-0001: Escalabilidad

NFR-0002 Interfaz

Versión 1.0 ( 04/06/2015 )




Descripción El sistema deberá tener una interfaz gráfica sencilla e intuitiva



Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 30 - NFR-0002: Interfaz

NFR-0003 Mantenibilidad

Versión 1.0 ( 04/06/2015 )




Descripción El sistema deberá tener un mantenimiento fácil y rápido. Para ello deberán documentarse todos los cambios o actualizaciones realizadas.

54



Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 31 - NFR-0003: Mantenibilidad

NFR-0004 Usabilidad

Versión 1.0 ( 04/06/2015 )




Descripción El sistema deberá tener una obtención e instalación sencilla, al igual deberá tener un uso fácil e intuitivo



Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 32 - NFR-0004: Usabilidad

NFR-0005 Portabilidad

Versión 1.0 ( 04/06/2015 )

55




Descripción El sistema deberá usarse sólo en dispositivos con sistema operativo Android, en versiones igual o superiores a la 4.0.3 (IceCreamSandwich). Por lo tanto no se nos pide tener un sistema portable.



Estado Validado

Estabilidad Alta

Comentarios Ninguno

Tabla 33 - NFR-0005: Portabilidad

NFR-0006 Actualizaciones

Versión 1.0 ( 04/06/2015 )




Descripción El sistema deberá ser fácilmente actualizable ante las nuevas necesidades e intereses de los usuarios, quedando siempre bien documentadas dichas actualizaciones y siempre manteniendo la compatibilidad hacia atrás e interoperatibilidad entre distintas versiones.



Estado Validado

Estabilidad Alta

Comentarios Ninguno

56

Tabla 34 - NFR-0006: Actualizaciones

4.5. Matriz de rastreabilidad

A continuación, a modo de resumen, mostraremos dos matrices de rastreabilidad, una que nos relacionará los

requisitos de información frente a los objetivos del sistema, y otra que nos relacionará los casos de uso con los

requisitos del sistema.

Pudiendo ver así de manera directa las relaciones entre requisitos (de información y funcionales) y objetivos.

4.5.1. Matriz de rastreabilidad IRQ frente a Objetivos

TRM-0001 OBJ-0001 OBJ-0002 OBJ-0003 OBJ-0004 OBJ-0005 OBJ-0006

IRQ-0001 - - -

-

IRQ-0002

- -

- -

IRQ-0003 - -

-

-

IRQ-0004 - - - - -

IRQ-0005 -

- - - -

Tabla 35 - TRM-0001: Matriz de rastreabilidad IRQ/Objetivos

57

4.4.2. Matriz de rastreabilidad UC frente a Objetivos

TRM-0002 OBJ-0001 OBJ-0002 OBJ-0003 OBJ-0004 OBJ-0005 OBJ-0006

UC-0001

- - - -

UC-0002 -

- - -

UC-0003 - - - - - -

UC-0004 - - -

- -

UC-0005 - - -

- -

UC-0006

- -

- -

UC-0007 -

- - - -

UC-0008

- - - -

UC-0009 -

- - - -

UC-0010

- - - - -

UC-0011 - - - -

-

UC-0012 - -

-

-

UC-0013 - - - -

-

UC-0014 - - - -

-

UC-0015 - -

- - -

UC-0016 - - - - - -

Tabla 36 - TRM-0002: Matriz de rastreabilidad UC frente a Objetivos

58

5. ANÁLISIS DEL SISTEMA

l objetivo principal del Análisis del Sistema es servir como medio de comunicación entre ingenieros de

requisitos y desarrolladores.

En este apartado desarrollaremos el modelo estático del sistema, el modelo dinámico del sistema y los prototipos

iniciales. Dichos análisis los llevaremos a cabo mediante una serie de diagramas.

5.1. Análisis estático del sistema

En el modelo estático del sistema se deben identificar los tipos o clases de objetos así como sus asociaciones y

composiciones.

Lo representaremos para cada uno de los subsistemas vistos.

E

59

5.1.1. Modelo estático: Subsistema de Gestión de mensajes e IPs

Ilustración 11 - Diagrama de clases: subsistema de gestión de mensajes e IPs.

60

TYP-0001 ServidorUdp

Versión 1.0 ( 10/06/2015 )



Descripción Objeto principal que representa un servicio UDP que se encargará de hacer llegar los mensajes a su destino final con independencia de IPs.

Supertipo Ninguno

Subtipos Ninguno

Componentes Nombre Tipo Multiplicidad

- - -

Comentarios Ninguno

Tabla 37 - TYP-0001: ServidorUdp

TYP-0002 ElementoLista

Versión 1.0 ( 10/06/2015 )



Descripción Este tipo de objetos representa un elemento de la lista que almacenará la clase ServidorUdp y que se borrará si es preciso en la clase Borrado

Supertipo Ninguno

Subtipos Ninguno


- - -

61

Comentarios Ninguno

Tabla 38 - TYP-0002: ElementoLista

TYP-0003 Borrado

Versión 1.0 ( 10/06/2015 )



Descripción Será la clase encargada del borrado de elementos de la lista una vez hayan permanecido en ella el tiempo máximo permitido (establecido en 35 minutos).

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Ninguno

Tabla 39 - TYP-0003: Borrado

TYP-0004 ArgumentosRecibidos

Versión 1.0 ( 10/06/2015 )



Descripción Este tipo de objetos representa los argumentos que el usuario le pasa al servicio por línea de comandos a la hora de ejecutarlo.

Supertipo Ninguno

Subtipos Ninguno


62

- - -

Comentarios Los argumentos que se les puede pasar son: puerto de escucha del servidor, periodo, y la ruta donde desee que se guarde el fichero de logs.

Tabla 40 - TYP-0004: ArgumentosRecibidos

TYP-0005 EscribeFichero

Versión 1.0 ( 10/06/2015 )



Descripción Este tipo de objetos representa el fichero donde se quieren escribir los registros de Logs generados en la ejecución del servicio

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Ninguno

Tabla 41 - TYP-0005: EscribeFichero

Identificación de relaciones

Se pueden observar dos relaciones de Asociación:

La primera de ellas entre la clase principal, ServidorUdp y la clase EscribeFichero. En dónde ServidorUdp usa

un elemento de tipo EscribeFichero para poder escribir en el fichero de Logs los eventos relevantes.

La segunda relación de asociación se observa entre la clase Borrado y EscribeFichero, con la misma finalidad

que en el caso anterior, lo que se quiere es almacenar eventos en el fichero de Logs. En este caso serán eventos

correspondientes al borrado de elementos.

Relaciones de Agregación:

Se observan entre la clase ServidorUdp y ElementoLista, ya que la primera contiene un ConcurrentHashMap en

el que uno de sus elementos es de tipo ElementoLista, y dónde la clase ServidorUdp irá almacenando la

información (si procede) de los paquetes que recibe. De igual manera se relacionan Borrado y ElementoLista,

en este segundo caso Borrado eliminará si es necesario elementos de dicha lista.

63

Relaciones de Dependencia:

Por último, vemos dos relaciones de dependencia entre ServidorUdp y ArgumentosRecibidos, Borrado. La clase

ServidorUdp utiliza esos otros dos tipos de datos para poder realizar de manera adecuada su función. La primera

de ella para poder realizar una correcta comprobación de los argumentos pasados como parámetros, y la segunda

de ellas para poder realizar la liberación de elementos de la lista pasado un tiempo determinado.

Todas las relaciones descritas son de multiplicidad 1:*

5.1.2. Modelo estático: Subsistema de Solicitud de localización

Para este subsistema dividiremos el diagrama en dos partes. En el primero de ellos mostraremos las clases y

relaciones entre ellas que intervienen en el proceso previo a la localización, es decir, en el proceso de acceso a

la agenda y selección de contactos que se quieren localizar. En el segundo diagrama nos ocuparemos de aquellas

clases que intervienen una vez el usuario lanzó la localización de uno de sus contactos previamente agregado.

64

5.1.2.1. Selección de contactos a localizar

Ilustración 12 - Diagrama de clases: Agregar contacto a lista de localizados

65

TYP-0006 MainActivity

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa la actividad principal de la aplicación Android

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Su función será ir cargando distintos Fragments según sea conveniente

Tabla 42- TYP-0006: MainActivity

TYP-0007 DetalleMainFragment

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa el layout y operaciones que se deben de realizar en la página principal de la aplicación

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Ninguno

Tabla 43 - TYP-0007: DetalleMainFragment

66

TYP-0008 ContactosFragment

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa el layout y operaciones que se pueden realizar sobre la sección de la aplicación que muestra la lista de contactos de la agenda

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Ninguno

Tabla 44- TYP-0008: ContactosFragment

TYP-0009 DetalleLocalizoFragment

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa el layout y las operaciones que se pueden realizar sobre la lista de contactos a localizar

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Ninguno

Tabla 45 - TYP-0009: DetalleLocalizoFragment

67

TYP-0010 TablaLocalizo

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa a la tabla de contactos localizados dentro de la base de datos

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios En esta clase se va a especificar la estructura que tendrá nuestra tabla. Conocida en android como 'contract class'.

Tabla 46-TYP-0010: TablaLocalizo

TYP-0011 EntradaTabla

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa la estructura (columnas) que tendrá la tabla de localizados

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Ninguno

Tabla 47-TYP-0011: EntradaTabla

68

TYP-0012 MySQLiteHelper

Versión 1.0 ( 11/06/2015 )



Descripción Clase de ayuda para la creación y gestión de la base de datos de nuestra aplicación

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Nuestra base de datos contendrá dos tablas: la tabla de contactos localizados, y la tabla de contactos permitidos. Se trata de una base de datos local al teléfono.

Tabla 48- TYP-0012: MySQLiteHelper


La clase principal, MainActivity, tiene una relación de asociación con la clase DetalleMainFragment, ya que la

primera contiene un elemento de la segunda, y cuando es preciso se encarga de cargar el contenido de

DetalleMainFragment. También observamos otra relación de asociación entre la clase DetalleLocalizoFragment

y MySQLiteHelper, en el que la primera posee un elemento de la segunda que usará para poder acceder a la

tabla de localizados existente en la base de datos.

Podemos ver cinco relaciones de dependencia, la primera de ellas entre MainActivity con ContactosFragment,

ya que usa esta clase para mostrar la lista de contactos y permitir al usuario realizar operaciones con ellos.

La segunda relación de dependencia es de MainActivity con la clase DetalleLocalizoFragment, en este caso la

clase MainActivity muestra la clase DetalleLocalizoFragment cuando es oportuno, mostrándole así al usuario la

lista de contactos localizados y permitiéndole realizar operaciones sobre ellos.

La tercera relación de dependencia que encontramos es entre ContactosFragment y MySQLiteHelper. La

primera instancia un elemento del tipo MySQLiteHelper para tener así acceso a la base de datos del sistema, y

poder agregar contactos a la tabla de localizados, esto se ve representado en la otra relación de dependencia que

va dirigida desde ContactosFragment hacia EntradaTabla, ya que utiliza dicha clase para la inserción de datos

en las distintas columnas.

La quinta relación de dependencia es entre MySQLiteHelper y EntradaTabla, esto es así porque la primera de

ellas necesitará acceso a la estructura interna de la tabla de localizados para poder crearla en la base de datos.

Por último, tenemos una relación de composición entre TablaLocalizo y EntradaTabla ya que EntradaTabla es

una clase interna a TablaLocalizo que define la estructura de dicha tabla.

69

5.1.2.2. Proceso de solicitud de localización

Ilustración 13 – Diagrama de clases: Proceso de localización

70

Vamos a definir los datos que no se hayan definido en el apartado anterior.

TYP-0013 ClienteUdp

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa un cliente UDP que va a realizar el envio del mensaje que le llega mediante el protocolo UDP

Supertipo Ninguno

Subtipos Ninguno


- - -

Tabla 49 - TYP-0013: ClienteUdp

TYP-0014 RecibeUdp

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa un receptor UDP, estará a la escucha en un puerto para la recepción de los primeros paquetes.

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Ninguno

Tabla 50 - TYP-0014: RecibeUdp

71

TYP-0015 Temporizador

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa un temporizador que va a estar durmiendo un tiempo dado, y al despertar realizará una determinada tarea

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Vamos a tener dos instancias de este tipo: esperaServidor y esperaCliente. Según qué instancia sea realizará una tarea u otra al despertar, y estará el proceso dormido un tiempo distinto.

Tabla 51-TYP-0015: Temporizador

TYP-0016 TemporizadorEnvio

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa un temporizador que va a estar durmiendo, y al despertar va a enviar un mensaje determinado

Supertipo Ninguno

Subtipos Ninguno


- - -

72

Comentarios Tendremos dos instancias de este tipo: esperaRefresco y esperaEnvío (este último actúa en la gestión de localización propia). Según en qué instancia estemos cambiará el mensaje que se envíe al despertar.

Tabla 52 - TYP-0016: TemporizadorEnvio

TYP-0017 Notificaciones

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa una notificación que se le va a mostrar al usuario

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Ninguno

Tabla 53 - TYP-0017: Notificaciones

TYP-0018 GestionaNotificacion

Versión 1.0 ( 11/06/2015 )



Descripción Es una clase que va a gestionar el click del usuario sobre la notificación

Supertipo Ninguno

Subtipos Ninguno


73

- - -

Comentarios En caso de mostrar una notificación con contenido de localización esta clase extraerá de la notificación la Latitud y Longitud, para poder posteriormente mostrarle la localización al usuario en un mapa.

Tabla 54 - TYP-0018: GestionaNotificacion

TYP-0019 VerMapaFragment

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa el layout del mapa con el marcador en la dirección donde se encuentra el contacto del que se recibió la notificación.

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Ninguno

Tabla 55 - TYP-0019: VerMapaFragment

TYP-0020 ReceptorUdp

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa la clase que va a estar a la escucha para recibir un paquete en un puerto dado que se le indique. Tras recibir un paquete, termina la escucha.

Supertipo Ninguno

Subtipos Ninguno

74


- - -

Comentarios Ninguno

Tabla 56 – TYP-0020: ReceptorUdp


En este diagrama vemos dos relaciones de asociación, que son las existentes entre ClienteUdp y Temporizador,

y entre VerMapaFragment y AddressResultReceiver. En la primera de ellas la clase ClienteUdp contiene dos

instancias del tipo Temporizador, que lanzará cuando sea adecuado. En la segunda, VerMapaFragment contiene

un elemento de tipo AddressResultReceiver, que será a través del cuál se reciba la dirección correspondiente a

una latitud y longitud dadas. Estas relaciones son de 1:*.

El resto de relaciones que observamos en el diagrama son de tipo dependencia. Unas clases usan/llaman a otras

de manera que al final se consiga una correcta funcionalidad del sistema.

5.1.3. Modelo estático: Subsistema de Gestión de localización propia

Este apartado vamos a dividirlo en tres partes, el primero de ellos como en el caso anterior será el paso previo al

envío de localización propia, el proceso de agregar contactos a la lista de permitidos. El segundo diagrama

mostrará las clases que intervienen en el proceso de envío de dicha localización, mientras que en el último

representaremos las clases implicadas cuando el usuario decide ver su propia localización.

5.1.3.1. Selección de contactos permitidos

Ilustración 14 - Diagrama de clases: selección de contactos permitidos

75

TYP-0021 DetallePermitoFragment

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa el layout y operaciones que se pueden hacer sobre la parte de la aplicación que muestra los contactos permitidos

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Ninguno

Tabla 57-TYP-0021: DetallePermitoFragment

TYP-0022 TablaPermitidos

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa la estructura (columnas) que tendrá la tabla de contactos permitidos

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Ninguno

Tabla 58 – TYP-0022: TablaPermitidos

76


En este diagrama tenemos una relación de asociación entre el elemento DetallePermitoFragment y

SQLiteHelper, ya que el primero contiene un objeto del tipo del segundo. Dicho objeto lo emplea para poder

acceder a la base de datos, y por tanto poder modificar y mostrar la lista de contactos permitidos.

Al igual que en el diagrama de selección de contactos para localizar, tenemos la relación de composición entre

la clase TablaPermitidos que definirá la estructura de esta tabla mediante la clase EntradaTabla, que nos indica

las columnas de dicha tabla.

El resto de relaciones son de tipo dependencia, la clase principal MainActivity muestra la agenda de contactos

mediante ContactosFragment. Dicha clase para poder agregar contactos a la lista de permitidos necesita poder

acceder a la base de datos, mediante la clase SQLiteHelper, y poder modificar las distintas entradas de la tabla

permitidos en la base de datos, mediante la clase EntradaTabla.

Por otro lado, la clase DetallePermitoFragment también usa a la clase EntradaTabla en caso de que se quiera

eliminar un contacto de la lista de permitidos, poder borrar dicha entrada de la tabla.

5.1.3.2. Proceso de envío de la localización propia

Ilustración 15 - Diagrama de clases: envío de localización propia

77

TYP-0023 SmsReceptor

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa un receptor de sms

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Esta clase recibirá sms, comprobará que sea de la aplicación y si es así efectuará las operaciones que sean convenientes. Ignorará todos aquellos mensajes que no sean de la aplicación.

Tabla 59- TYP-0023: SmsReceptor

TYP-0024 ObtenerLocalizacion

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa la clase encargada de acceder al gps del teléfono y obtener la localización de la forma latitud,longitud.

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Una vez obtenida la localización, deberá encargarse de llamar a la clase que realizará el envío (ClienteUdp) o a la clase que muestra la localización propia

78

(LocalizacionPropiaActivity), según proceda

Tabla 60- TYP-0024: ObtenerLocalización


Al igual que en el caso anterior, y con el mismo motivo vemos la relación de composición entre TablaPermitidos

y EntradaTabla.

Existe una relación de asociación entre SmsReceptor y MySQLiteHelper ya que el primero contiene un

elemento del tipo del segundo, que usará para poder realizar la comprobación de si el contacto que le solicita la

localización se encuentra en la tabla de Permitidos.

El resto de relaciones son de tipo dependencia. La clase SmsReceptor usa a la clase EntradaTabla para poder

acceder a los nombres de las columnas y luego poder realizar la consulta. También utiliza la a la clase

ObtenerLocalización en caso de estar el contacto permitido, para una vez obtenida latitud y longitud llamar a la

clase ClienteUdp que enviará la información de localización. En caso de que el contacto no se encuentre en

permitidos, directamente llamará a la clase ClienteUdp para enviar el mensaje de error.

También, la clase SmsReceptor usa a la clase TemporizadorEnvio para el envío periódico de mensajes de

localización. Y la clase Notificaciones para, en caso de enviar la localización, poder informar al contacto a quién

le esta enviando su localización.

5.1.3.3. Visualización de la localización propia

Ilustración 16 - Diagrama de clases: Visualización de localización propia

79


En este caso existe una relación de dependencia entre MainActivity, que llama a ObtenerLocalización y ésta

última, una vez obtenidas las coordenadas del usuario lanza la actividad LocalizacionPropiaActivity, que se

encargará de mostrar el mapa con la posición del usuario cargando el fragment VerMapaFragment.

Las relaciones de asociación y dependencia entre VerMapaFragment, AddressResultReceiver y

AddressIntentService ya se explicaron anteriormente.

TYP-0025 LocalizacionPropiaActivity

Versión 1.0 ( 11/06/2015 )



Descripción Este tipo de objetos representa la actividad que mostrará el mapa con la posición del usuario de la aplicación cuando éste lo solicite.

Supertipo Ninguno

Subtipos Ninguno


- - -

Comentarios Ninguno

Tabla 61 – TYP-0025: LocalizacionPropiaActivity

5.2. Análisis dinámico del sistema

En este apartado especificaremos las operaciones del sistema. Lo haremos mediante diagramas de flujos

diferenciados igualmente para cada uno de los subsistemas.

5.2.1. Acciones gestión de mensajes e IPs

El usuario debe de poder recibir y enviar mensajes de localización independientemente de las IPs origen y

destino.

- UC-0001: Enviar mensajes desde/hacia cualquier IP

- UC-0002: Recibir mensajes con independencia de IPs

- UC-003: Establecer la IP y puerto del servidor al que se conecta.

80

Ilustración 17 – Envío y recepción de mensajes con independencia de IPs

81

Ilustración 18 – Configuración de IP y puerto del servidor

5.2.2. Acciones de solicitud de localización

En los siguientes diagramas se cubrirán los siguientes casos de usos:

- UC-0004: Eliminar contactos que no se quiera localizar.

- UC-0005: Agregar contactos a lista de localizados.

- UC-0006: Comenzar a localizar.

82

- UC-0007: Elegir tiempo con el que se reciben actualizaciones de localización.

- UC-0008: Localizar a varios contactos simultáneamente.

- UC-0009: Recibir notificaciones de localización.

- UC-0010: Localizar solo a contactos a los que no se esté localizando.

Ilustración 19 - Acción de agregar a un contacto a “Localizados”

83

Ilustración 20 - Acción de comenzar a localizar

5.2.3. Acciones de gestión de localización propia

En los siguientes diagramas se cubrirán los siguientes casos de usos:

- UC-0011: Elegir contactos permitidos.

- UC-0012: Enviar localización propia.

- UC-0013: Modificar los contactos permitidos (Agregar).

- UC-0014: Modificar los contactos permitidos (Eliminar).

- UC-0015: Acceder al GPS del teléfono.

- UC-0016: Consultar la localización propia.

84

Ilustración 21 - Acción de envío de localización propia

85

Ilustración 22 - Acción de modificar lista de "Permitidos"

86

Ilustración 23 - Acción de consultar localización propia

5.3. Prototipo del sistema

n este apartado haremos el desarrollo del prototipo inicial de la aplicación Android a desarrollar. Según la

información recopilada hasta ahora podemos ver que nuestro diseño debe de tener 5 partes principales:

- Vista principal de la aplicación.

- Vista de acceso a la agenda.

- Vista de contactos permitidos.

- Vista de contactos localizados.

- Vista donde se muestre la localización propia.

Realizamos este prototipo únicamente para la aplicación Android, ya que es el único componente del sistema

con el que el usuario final interactuará directamente a través de su interfaz gráfica.

A continuación se mostrarán los diseños de la interfaz pensados para cada una de las partes.

E

87

Ilustración 24 - Interfaz de usuario: Página principal

Ilustración 25 - Interfaz de usuario: Agregar contactos a las listas

88

Ilustración 26 - Interfaz de usuario: Lista de contactos que localizamos

Ilustración 27 - Interfaz de usuario: Opciones sobre contactos que localizamos

89

Ilustración 28 - Interfaz de usuario: Elección del tiempo entre notificaciones

Ilustración 29 - Interfaz de usuario: Contactos permitidos

90

Ilustración 30 - Interfaz de usuario: Mapa con la localización del contacto

91

6. DISEÑO DEL SISTEMA

n este apartado vamos a ocuparnos del diseño del sistema. Lo dividiremos en cada uno de los subsistemas

con los que estamos trabajando. Igualmente diseñaremos la interfaz de usuario, que en nuestro caso es de

vital importancia ya que es el único médio del que dispone el usuario para interactuar con el sistema.

6.1. Clases: Subsistema de gestión de mensajes e IPs

6.1.1. ServidorUdp

Es la clase principal de este subsistema, esta clase representa un servicio UDP que permanece a la escucha de

datos en un puerto determinado por defecto. Al recibir un paquete lo procesa y efectúa la operación que sea

necesaria. Para ello tiene una serie de atributos y métodos:

- Con los métodos compruebaArgumentos, muestraHelp y muestraUso, se realiza una

comprobación de los arguementos que se les pase como parámetros a la hora de ejecutar. En

caso de estar todos los parámetros correctos se procederá la escucha UDP, en caso contrario

se mostrará al usuario una ayuda del uso de los mismos.

- Tras recibir un paquete, el método procesaDatos nos devuelve el tipo del paquete recibido

(solicitud, respuesta, error o refresco). Para ello usa los datos recibidos y las cadenas con los

tipos por defecto para la comparación.

- Una vez conocido el tipo del mensaje, y dependiendo de cuál sea, se procederá a ejecutar los

siguientes métodos: guardaElemento (para mensajes de solicitud o refresco) y buscaLista

(para mensajes de respuesta y de error).

- Con el método enviaPaquete, reenvíamos el paquete que nos llegó (respuesta, error) hacia su

destino final.

Esta clase almacena información sobre los destinos a los que debe de reenvíar dicha información en su atributo

listaElementos, que es del tipo ConcurrentHashMap donde almacena objetos de tipo ElementoLista

identificados con una Key. Estos elementos del tipo ElementoLista los describiremos más adelante.

A su vez esta clase hace uso de la clase Borrado para que pasado un tiempo, se puedan eliminar elementos de la

lista aterior. También hace uso de la clase EscribeFichero, para poder actualizar el fichero de logs con cada

paquete que recibe/reenvía.

E

92

Ilustración 31 - Clase ServidorUdp

6.1.2. ArgumentosRecibidos

Esta clase almacena en sus atributos los parámetros que se les pasa por línea de comandos en el momento de

ejecución (si se les pasa). En caso contrario almacenará los valores por defecto para dichos parámetros.

Ilustración 32 - Clase ArgumentosRecibidos

93

6.1.3. Borrado

Esta clase es una clase que actúa de temporizador y pasado el tiempo que está “durmiendo”, se “despierta” y

ejecuta la función eliminaElementos, esto lo hace siguiendo el siguiente criterio: borrará sólo aquellos elementos

que lleven un tiempo en la lista superior al valor del atributo tiempo_max.

También usa la clase EscribeFichero para que una vez terminada de recorrer la lista, indique en el fichero de

logs el número de paquetes que ha borrado.

Ilustración 33 - Clase Borrado

6.1.4. ElementoLista

Esta clase representa a un elemento de la lista que actualizan ServidorUdp y Borrado. Se trata de una lista en

dónde se guarda la ip origen, puerto origen del paquete de solicitud o refresco que nos llegó, y el tiempo en el

que se recibió dicho paquete. Es decir este elemento guarda la información que necesita el servidorUdp para

poder hacer llegar el paquete recibido a su destino.

Ilustración 34 - Clase ElementoLista

6.1.5. EscribeFichero

Mediante el método público escibreFicheroLog, esta clase escribe la cadena que se le pasa como parámetro en

el fichero que se le indica en el constructor (ficheroLog).

94

Ilustración 35 - clase EscribeFichero

6.2. Clases: Actividad principal

Esta es la clase principal de la aplicación. Se encargará de cargar cada uno de los fragments con su funcionalidad

y estilo asociados.

Con las funciones click_recibo y click_envio, nos permitirá navegar por la lista de contactos permitidos

(click_envio) y de los localizados (click_recibo). También gestionará los clicks del usuario en los botones del

menú superior de la aplicación mediante la función onOptionsItemSelected.

Por último, también será la encargada de controlar la salida de la aplicación cuando el usuario pulse la tecla

“back”.

Ilustración 36 - Clase principal: ActivityMain

6.3. Clases: ContactosFragment

Esta clase se encarga de cargar su propio layout en el método onCreateView, y se utiliza para realizar acciones

sobre la lista de contactos que muestra.

- Con los métodos onTextChanged, beforeTextChanged, afterTextChanged y runQuery somos

capaces de filtrar la lista de contactos según las letras que vayamos escribiendo en el cuadro

de texto y mostrar así sólo los contactos que comiencen con esa cadena que escribimos.

- Por otro lado, para poder mostrar un menú para cada contacto permitiendo así que el usuario

pueda interactuar con ellos tenemos el método onCreatecontextMenu. Para poder gestionar y

95

actuar en consecuencia al elemento del menú que pulsó el usuario tenemos el método

onContextItemSelected.

Ilustración 37 – Clase ContactosFragment

6.4. Clases: Base de datos

6.4.1. MySQLiteHelper

Como dijimos anteriormente en el análisis, esta es una clase de ayuda que nos ayudará a gestionar nuestra base

de datos SQLite.

- onCreate: con este método, y utilizando las sentencias guardadas en los String

CREA_LOCALIZO y CREA_PERMITO me permitirá crear las tablas Localizo y

Permitidos respectivamente.

- onUpgrade nos permite actualizar la base de datos a una versión nueva, debe borrar los datos

existentes haciendo uso de las sentencias guardadas en sus atributos

“DELETE_LOCALIZO” y “DELETE_PERMITO”, después de eliminarlas debe de volver

a crear los datos llamando a la función onCreate.

Ilustración 38 - Clase MySQLiteHelper.

96

6.4.2. TablaLocalizo

Esta clase contiene a otra clase, EntradaTabla, que nos define la estructura de la tabla. EntradaTabla

implementará la interfaz ‘BaseColumns’.

Ilustración 39 - Clase TablaLocalizo y EntradaTabla

6.4.2.1. Estructura de la tabla “Localizados”

Campo Tipo Nulo PK FK

_id integer No Sí No

nombre text No No No

telefono text No No No

Tabla 62 – Tabla Localizados

6.4.3. TablaPermitidos

Ilustración 40 – Clase TablaPermitidos y EntradaTabla

97

6.4.3.1. Estructura de la tabla “Permitidos”

Campo Tipo Nulo PK FK

_id integer No Sí No

nombre text No No No

telefono text No No No

Tabla 63 – Tabla permitidos

Para las tablas hemos seguido la misma estructura en la que guarda Android los contactos en la agenda. Aunque

el número de teléfono podría ser clave primaria ya que es único, Android le asigna a cada contacto un

identificador, y ese mismo identificador del contacto en la agenda será el que usaremos para distinguir a los

contactos de nuestras tablas.

6.5. Clases: Subsistema de solicitud de localización

6.5.1. DetalleLocalizoFragment

Esta clase se encarga de mostrar su propio layout mediante su método onCreate. Además ofrece operaciones a

realizar con los contactos que aparezcan en la lista.

- Mediante el método onCreateContextMenu y onContextItemSelected se le permitirá al

usuario interactuar con los contactos que tenga en esta lista vía un menú. Podrán eliminarse

contactos o comenzar a localizar.

- Si lo que se desea es comenzar la localización, mediante la función mostrarDialogo se le

permitirá al usuario elegir el tiempo entre notificaciones, y una vez elegido se llamará a la

función comienzaLocalizacion.

- Sobre los atributos cabe destacar que listaLocalizados nos almacenará los contactos que

estemos localizando en un momento dado, de manera que si se vuelve a comenzar la

localización el sistema no nos lo permita. Mediante el método público eliminaElementoLista

se podrán eliminar elementos de dicha lista una vez transcurrido el tiempo máximo de

localización.

98

Ilustración 41 – Clase DetalleLocalizoFragment

6.5.2. ClienteUdp

Esta clase se encarga de recibir el mensaje UDP a enviar almacenado en la variable mensaje_udp, comprueba el

tipo del mensaje mediante su método getTipoMensaje, si se trata de un mensaje de solicitud entonces, mediante

su método getHash obtiene el hash, que agregará al mensaje de solicitud, posteriormente lo envía, y lanza la

clase RecibeUdp, que se quedará a la escucha de paquetes.

En caso de que la variable mensaje_udp contenga un mensaje de error o respuesta no habrá que hayar ningún

hash, sólo será necesario enviar el mensaje al servidor y cerrar el puerto con método cierraSocket.

Esta clase también se encargará de instanciar dos elementos de tipo Temporizador, para prevenir que la

aplicación se quede indefinidamente a la espera en caso de que el servidor o el cliente no estén disponible.

Otro método a destacar es el método desbloqueaUdp, que nos permitirá salir del método bloqueante receive()

de los sockets mediante el envío de un automensaje UDP.

99

Ilustración 42 - Clase clienteUdp

6.5.3. RecibeUdp

Esta clase se ejecuta en segundo plano. Es llamada desde la clase ClienteUdp. Los atributos de esta clase

almacenan el nombre del contacto a localizar, el teléfono del contacto a localizar, el hash con el que se

identificará la conexión con ese contacto y el tiempo con el que se desea recibir notificaciones del contacto.

Esta clase será la encargada de quedarse a la escucha de mensajes UDP. Al recibir un mensaje esta clase deberá

procesarlo para saber de qué tipo se trata, y en función del tipo realizar una operación u otra. En el caso de que

sea un mensaje de tipo error o respuesta, lanzará la clase Notificaciones que se encargará de mostrarle la

notificación al usuario. Si por el contrario se trata del tipo solicitud, deberá enviar un sms al contacto al que

quiere localizar para desencadenar así el proceso de envío de localización.

100

Ilustración 43- Clase RecibeUdp

6.5.4. Notificaciones

Esta clase es la encargada de llamar al método mostrarNotificacion, que mostrará la notificación en la pantalla

del dispositivo y dependiendo del tipo de notificación del que se trate, permitirá o no que el usuario interactue

con ella al hacer click sobre la misma.

Ilustración 44 - Clase Notificaciones

6.5.5. Temporizador

Esta clase se encarga de gestionar los tiempos de espera de la aplicación:

- Espera del servidor: para prevenir la escucha indefinida en caso de que el servidor no

responda.

- Espera del cliente: para prevenir la escucha indefinida en caso de que el contacto que debería

responder con su localización no lo haga.

Esta clase deberá encargarse de temporizar los distintos tiempos, y en caso de que sea necesario, cerrar el socket

de escucha. Para poder realizar su tarea de forma adecuada se le pasa el Socket actual de escucha (por si debe

cerrarlo), el tipo de espera en la que se encuentre (existen las dos nombradas previamente), y el tiempo (tiempo

en el que tiene que estar “durmiendo”).

101

Ilustración 45 – Clase Temporizador

6.5.6. TemporizadorEnvio

Esta clase se utilizará tanto en el subsistema de solicitud de localización (el que estamos tratando) como en el

subsistema de gestión de localización propia.

La función de este temporizador es, igual que el anterior contabilizar un tiempo dado como tiempo_envio, y al

despertar, según el tipo de espera en el que estemos realizar una función u otra:

- Tipo_espera = refresco. Significa que debemos enviar un mensaje al servidor para actualizar

el socket de escucha y mantener la comunicación. Se cerrará el socket anterior de escucha y

se abrirá uno nuevo a través del cuál se enviará el mensaje de refresco. Posteriormente

lanzaremos el AsyncTask RecepciónUdp, proceso que se mantendrá a la escucha en el nuevo

puerto pasado como parámetro.

- Tipo_espera = espera_envío. Significa que debemos de enviar un mensaje con nuestra

localización.

Esta clase TemporizadorEnvio, se estará ejecutando durante el tiempo máximo que dura el proceso de

localización.

Ilustración 46 – Clase TemporizadoEnvio

102

6.5.7. ReceptorUdp

Se trata de una clase que extiende de AsyncTask y es llamada desde TemporizadorEnvio en el caso de que se

mande un paquete de refresco. La función de esta clase es estar a la escucha de un paquete UDP en el Puerto

pasado como parámetro (Puerto por donde se envió el paquete de refresco anterior). En esta clase solo se

recibirán mensajes de tipo “respuesta”. Al recibir un paquete, muestra la notificación adecuada y termina la

tarea.

Ilustración 47 – Clase ReceptorUdp

6.5.8. GestionaNotificacion

Esta clase es llamada por la clase Notificacion, se encarga de coger los datos de la notificación: Nombre del

contacto, longitud y latitud.

Una vez con estos datos cargará el fragment VerMapaFragment, que será la clase encargada de mostrar la

dirección y el marcador en el mapa a partir de la latitud y longitud pasadas.

Ilustración 48 - Clase GestionaNotificacion

6.5.9. VerMapaFragment, AddressResultReceiver y AddressIntentService

Esta es la clase encargada de pintar el mapa y colocar el marcador en la posición indicada por las coordenadas

de latitud y longitud. Mediante su método startIntentService, llamará a un servicio Android

(AddressIntentService) que nos devolverá a través del método onReceiveResult, la dirección correspondiente a

la latitud y longitud dadas.

La clase AdressIntentService es la encargada de, usando un Geocoder transformar las coordenadas de latitud y

longitud a una dirección. Mediante el método deliverResultToReceiver, enviará esta dirección a la clase

AddressResultReceiver mostrada antes.

103

Ilustración 49 - Clases VerMapaFragment, AddressResultReceiver, AddresIntentService

6.6. Clases: Subsistema de gestión de la localización propia

6.6.1. DetallePermitoFragment

Al igual que en las clases ContactosFragment y DetallePermitoFragment, esta clase proporciona el estilo de esta

sección de la aplicación, y permite al usuario realizar operaciones sobre los contactos de esta lista. El número de

operaciones está limitado a una: Eliminar contactos.

Ilustración 50 – Clase DetallePermitoFragment

104

6.6.2. SmsReceptor y ObtenerLocalizacion

Cuando el teléfono recibe un SMS lo recoge en la clase SmsReceptor dentro de su atributo msgRecibido y lo

procesa para comprobar que provenga de la aplicación, es decir, que comience con la cadena “[LOCALIZAPP]”

Una vez confirmamos que efectivamente, el sms pertenece a nuestra aplicación extraemos el emisor y

comprobamos si se encuentra en la lista de permitidos. En caso negativo enviamos un mensaje de error. En caso

de que si esté permitido el contacto, llamamos a la clase ObtenerLocalización, que se encargará de consultar la

localización.

En el proceso de envío de la localización propia también intervienen las clases ClienteUdp (ver punto 6.5.2) para

enviar los mensajes, ya sea los de localización o de error (en caso de que el solicitante no esté en la lista de

permitidos) y TemporizadorEnvio (ver punto 6.5.6), que se usará en este subsistema para controlar la

periodicidad de los mensajes de localización que se envíen.

105

Ilustración 51 – Clases SmsReceptor y ObtenerLocalización

106

6.7. Clases: Interfaz gráfica

La clase ActivityMain, va cargando en la interfaz del usuario distintos fragments, cada uno de los cuales tiene

un layout asociado (en forma de fichero .xml) que será el que contiene la información sobre los elementos de la

pantalla, su posición, tamaño, color etc.

La clase SplashActivity, en su método onCreate carga su layout asociado, y nos mostrará el splash de bienvenida

durante dos segundos, pasado este tiempo dará paso a la actividad principal la cuál tiene un layout asociado

(activity_main.xml) que es un contenedor vacío dónde irá cargando según sea conveniente los diversos

fragments con sus layouts asociados. En un principio el layout cargado es el correspondiente a la página principal

(fragment_main.xml). En los métodos onCreateView, cada fragment carga su layout propio.

Ilustración 52 - Clases de la interfaz gráfica I

107

En el caso de las actividades LocalizacionPropiaActivity y GestionaNotificacion ambas tienen como layout un

contenedor vacío en el que cargarán el fragment VerMapaFragment con su layout correspondiente.

Ilustración 53 – Clases de la interfaz gráfica II

108

7. IMPLEMENTACIÓN DEL SISTEMA

n este apartado nos centraremos en cómo hemos implementado los aspectos más importantes del problema

de envío de mensajes en el sistema.

7.1. Escenario

El escenario de comunicaciones que se nos plantea es el siguiente: tendremos un usuario de nuestra aplicación,

conectado ya sea a una red wifi o móvil que desea realizar la localización de otro usuario, igualmente conectado

a una red wifi o móvil y debemos conseguir que los mensajes lleguen correctamente.

Para poder realizar dicha comunicación, dado que tenemos un equipo NAT por medio, precisamos de un servicio

intermedio entre ambos clientes de la aplicación que procese y encamine los mensajes. Dicho servidor lo

desplegaremos en saeta.us.es.

En el siguiente diagrama mostramos de manera gráfica la situación.

Ilustración 54 – Escenario planteado

7.1.1. Flujo de mensajes

En este apartado intentaremos mostrar el funcionamiento global de la solución adoptada mediante un diagrama

de paso de mensajes, de esta manera podremos hacernos una idea clara de cómo funciona el sistema

implementado.

Cabe destacar la importancia de los primeros mensajes en la comunicación (solicitud al servidor y SMS hacia el

contacto a localizar) así como de los mensajes de refresco periódicos hacia el servidor, ya que sin ellos sería

imposible hacer llegar los mensajes de un extremo a otro.

E

109

Ilustración 55 – Paso de mensajes en las solución elegida

El comienzo de la comunicación lo inicia A lanzando un mensaje de solicitud hacia el servidor, abriendo así un

puerto a través del NAT de manera que puede recibir respuestas a través del mismo.

Cuando el servidor recibe un mensaje de solicitud, antes de responder almacena en su lista el hash recibido junto

con su IP y puerto, de manera que así podrá realizar un encaminamiento posterior buscando por el Hash.

Una vez el servidor le ha contestado, le manda un SMS al contacto que quiere localizar, de manera que el

contacto nombrado como B conocerá el hash del usuarioA y el tiempo con el que quiere las notificaciones.

El contacto que va a ser localizado revisará si el usuario A está en su lista de permitidos, y en cualquier caso

respondería al servidor, ya sea con un mensaje de error o de respuesta con información de localización. Para que

la comunicación se produzca, B debe de mandar un mensaje al servidor indicando el hash que le llegó en el SMS

de A. Seguidamente en el servidor se busca en su ConcurrentHashMap qué IP y puerto se corresponden con el

usuario al que quiere responder B. Una vez lo encuentra, realiza el envío.

Otro mensaje relevante en esta comunicación son los mensajes de refresco que envía el usuario A, tienen doble

función:

- La primera de ellas es actualizar su entrada en el NAT, ya que por defecto, tras 5 minutos se

elimina la entrada UDP en el NAT, haciendo imposible que pasado dicho tiempo, los

mensajes del servidor llegasen a su destino.

- La segunda función es actualizar puerto e IP en el servidor, cuando el servidor recibe un

mensaje de refresco, actualiza en su ConcurrentHashMap el nuevo par IP, puerto

correspondiente al Hash dado de manera que la comunicación seguirá siendo correcta si el

usuario A cambia de red (y por tanto de IP) en un momento dado.

El procedimiento explicado anteriormente y su flujo de mensajes fue la solución adoptada para poder realizar el

envío correcto teniendo en cuenta que los extremos se encontraban en redes privadas. Para ello se tuvo que

110

implementar la técnica conocida como “UDP Hole Punching”, es decir, la apertura desde un puerto interno hacia

el servidor, que se consigue con el mensaje de solicitud y el posterior el refresco de dicho puerto para mantener

activa la entrada en el NAT, que se consigue como acabamos de explicar mediante los mensajes de refresco.

Asímismo, teniendo en cuenta los tiempos de expiración de las entradas en el NAT, cuyo tiempo mínimo de

expiración es de 2 minutos y siendo 5 minutos el tiempo por defecto, fijamos los mensajes de refresco cada dos

minutos de manera que podamos cubrir tanto los NAT con mayor tiempo de expiración y los de menor.

Aunque siempre debemos tener en cuenta que este tiempo es configurable, y por tanto, aunque desaconseja un

tiempo menor de dos minutos, podríamos llegar a encontrarnos con tiempos menores, por ejemplo, hay algunos

NATs con temporizadores para las entradas UDP de 20 segundos.

7.2. Tipos de mensajes

En nuestro sistema tendremos distintos tipos de mensajes que describiremos a continuación, todos ellos son de

tipo String.

Todos los mensajes tienen una estructura definida, con separadores entre campos determinada que permitirán su

procesamiento haciendo uso de la función Split.

Mensajes de solicitud

Estos son los mensajes de inicio de la comunicación, será el tipo de mensaje que envíe el usuario que quiere

localizar hacia el servidor, y también de este tipo será la respuesta del servidor a un contacto que solicita la

localización, la estructura de ellos es, respectivamente:

Tipo: solicitud, hash: hash_id_origen (mensaje en el sentido: usuario servidor).

Tipo: solicitud, mensaje: respuesta del servidor (mensaje en el sentido: servidor usuario).

El mensaje de respuesta del servidor le indica al cliente que debe terminar con el temporizador de espera del

servidor (ya obtuvo su respuesta) y debe lanzar el temporizador de espera del cliente.

En este apartado cabe destacar la obtención del hash. Se decidió que el hash fuese la concatenación del serial de

la Sim del teléfono con el puerto que abre la aplicación para esperar respuesta. Esto es así porque por cada cliente

abriremos un puerto distinto a la escucha, de esta manera en el servidor tendremos a todos los conctactos que

quiera localizar un mismo usuario bien identificacos.

A continuación se muestran las fracciones de código correspondientes a la obtención del serial de la Sim y del

hash.

Ilustración 56 – Obtención del serial de la Sim del teléfono

Una vez tenemos el serial y hemos abierto un socket, pasamos a obtener el hash con la siguiente función.

111

Ilustración 57 – Obtención del hash

Como vemos en la llamada a la función getHash, el parámetro cadena que recibe es la concatenación del puerto

abierto y el serial.

Ilustración 58 – Llamada a la función getHash

Mensajes de respuesta

Este mensaje de respuesta se corresponde con los mensajes con información de localización que envía el

contacto que es localizado hacia el servidor y que, posteriormente llegan al usuario que solicitó la localización.

Los mensajes de este tipo tendrán la siguiente estructura:

Tipo: respuesta, hash: hash_id_destino, mensaje: latitud_valor longitud_valor, id: valor_identificador.

Hay que recordar que el hash_id_destino se trata del hash que le llegó por SMS, que identifica al contacto que

inició el proceso de solicitud de localización.

En este tipo de mensajes los valores de latitud y longitud pueden ser “No disponible” en caso de que no se tengan

los servicios de ubicación activos en el terminal que los envió.

Cuando el servidor reenvía dicho mensaje hasta su destinatario elimina la información del hash, de manera que

el mensaje de respuesta que viaja entre servidor y destinatario es:

Tipo: respuesta, mensaje: latitud_valor longitud_valor, id: valor_identificador.

Al usarse un protocolo de transporte no fiable (UDP), intentamos aumentar la fiabilidad del servicio enviando

ráfagas de 6 paquetes, todos ellos con el mismo identificador, de esta manera la aplicación descartará qué

paquetes son réplica y cuáles nuevos en función de su identificador consiguiendo así no mostrar al usuario

información de localización duplicada.

Mensajes de error

Estos mensajes son los que se envían en el caso de que al usuario que solicita la localización no se le permita

conocer dicha información, es decir, no se encuentra en la lista de “Permitidos” del contacto localizado.

La estructura del mensaje es la siguiente:

Tipo: error, hash: hash_id_destino, mensaje: No tienes permiso para conocer la localización.

Igual que en el caso anterior, en la comunicación entre servidor y destinatario se omite el hash, y el mensaje

queda de la forma:

Tipo: error, mensaje: No tienes permiso para conocer la localización.

112

Mensajes de refresco

Como explicamos antes, estos mensajes se envían entre el usuario que solicita la localización y el servidor,

teniendo la doble función de mantener la entrada del NAT correspondiente a su puerto activa y poder realizar

actualizaciones de IP y puerto en el servidor. Estos mensajes no se reenvían, el servidor los consume.

Para mitigar las posibles pérdidas que puedan producirse y que no se vea afectado el proceso de localización se

enviarán, al igual que los mensajes de respuesta, en ráfagas de 6 paquetes.

La estructura de esos mensajes es la siguiente:

Tipo: refresco, hash: hash_id_origen. Cuando el servidor recibe un mensaje de este tipo actualiza la IP y puerto

correspondientes al hash que recibe.

7.3. Envío de mensajes

Dado que el proceso de envío de mensajes es idéntico para el servicio Java y para la aplicación Android, en este

apartado explicaremos la formación del datagrama y su posterior envío. Destacando que el puerto destino será

lo que variará de un caso a otro. Siendo en la aplicación android el puerto destino el del servidor (hemos tomado

el 4440), y en el caso del servidor el puerto destino se corresponderá al que se encuentre en la lista

ConcurrentHashMap y que identifique al cliente dado.

En estas dos primeras imágenes se ve cómo se ponen a la escucha los sockets del servidor en un puerto concreto

(Ilustración 59) y en la aplicación Android no se especifica cuál abrir (Ilustración 60)

Ilustración 59 – Envio de mensajes: Socket en el servidor

Ilustración 60 – Envio de mensajes: Socket en Android

A continuación, se obtienen las direcciones ip destino que variará igualmente de un caso a otro. En el servidor

(Ilustración 61) la dirección destino es la dirección que encuentra en su lista, y en el caso de Android (Ilustración

62) la dirección va a ser fija y siempre la misma, la dirección del servidor. Salvo esta diferencia, los métodos

usados para obtenerlas vemos que son los mismos.

Ilustración 61 – Envio de mensajes: Obtención de dirección destino en el servidor.

Ilustración 62 – Envio de mensajes: Obtención de dirección destino en Android

Por último, una vez tenemos el socket abierto e identificado el destino de nuestro paquete procedemos a su envío.

Primero necesitamos obtener los bytes del mensaje a enviar, mediante la función getBytes(), posteriormente

creamos nuestro Datagrama, que enviaremos mediante el método send().

Este procedimiento es el mismo tanto para android como para el servidor.

113

Ilustración 63 – Envio de mensajes: Envio del paquete UDP

El tiempo máximo que la aplicación estará enviando, y por tanto recibiendo mensajes de localización será de 1

hora y 30 minutos, pasado dicho tiempo se notificará al usuario, y éste tendrá que lanzar una nueva localización.

7.4. Aplicación Android

Vamos a describir los aspectos considerados más importantes en la implementación de la aplicación Android.

7.4.1. Obtención de la localización

Para el desarrollo de aplicaciones de localización pueden elegirse dos APIS:

- android.Location.

- Google Location Services API.

Se optó por el uso de la segunda, ya que de acuerdo a la documentación de Android es preferible. Esta API nos

proporciona una precisión mayor y un ‘geofencing’ de menor consumo que la API android.Location.

En primer lugar, al crear la clase, tenemos que especificar en nuestra clase que implemente las interfaces de

callback() ConnectionCallbacks y OnConnectionFailedListener. Estas interfaces reciben callbacks en caso de

que la conexión con GooglePlay services sea correcta, falle, o se suspenda.

Ilustración 64 – GoogleApi: Implementación de interfaces de callback()

Para poder conectarnos a las Apis de Google es necesario crear una instancia de “GoogleApiClient”. En el

siguiente método creamos un cliente Google y usamos el Builder para agregar la API Location Services. Este

método lo llamamos en el método onHandleIntent del IntentService.

Ilustración 65 – GoogleApi: Creación de GoogleApiClient

114

Una vez que tenemos el cliente Google nos conectamos a él mediante el método connect(). Estando conectados

a los servicios de Google y a la API Location Services, podemos obtener la localización del usuario del

dispositivo. Para pedir la localización llamamos al método getLastLocation, pasándole nuestro cliente Google.

Este método nos devuelve un objeto de tipo Location, del cuál se pueden extraer fácilmente las coordenadas de

latitud y longitud mediante los métodos: getLatitude() y getLongitude().

Ilustración 66 – GoogleApi: Obtención de coordenadas de latitud y longitud

En nuestro caso, como se ve en el fragmento de código anterior, en caso de no obtener ninguna localización

rellenamos la latitud y longitud con el texto “No disponible”, de manera que al enviarlo al usuario que solicita

la información sea información comprensible, ya que en caso contrario el contenido de latitud y longitud sería

“null”.

7.4.2. Recepción y procesamiento de los mensajes

Al lanzar una solicitud de localización, la aplicación se queda en escucha en el mismo puerto con el que realizó

la petición. En la siguiente ilustración se ve cómo se crea un array de bytes donde se guardará el mensaje que se

reciba. Hemos tomado el tamaño máximo que puede tener, después creamos el paquete donde se van a guardar

los datos, y nos quedamos bloqueados en la espera mediante el método receive() (Ilustración 67)

Una vez que recibimos un paquete, salimos de la espera bloqueante, extraemos en un String el mensaje que nos

ha llegado y llamaremos a la función procesaDatos().

En la función procesaDatos, se obtiene el tipo del mensaje que acabamos de recibir, y se procesa en función de

éste.

- Mensaje de solicitud: Significa que el servidor me ha respondido, y por tanto lanzamos el

sms hacia el contacto que queremos localizar, indicándole el hash y el tiempo que deseamos

entre notificaciones. En la Ilustración 68 podemos ver el envío de un SMS en Android

mediante el SmsManager.

- Mensaje de error o de respuesta: mostramos una notificación al usuario.

La llamada a la función procesaDatos() solo se realizaría para los primeros mensajes recibidos, una vez recibida

la primera respuesta con información de localización no resulta necesario ya que los siguientes serán igualmente

de localización.

115

Ilustración 67 – Espera de datos en Android

Ilustración 68 – Envio de SMS

7.4.3. Mantenimiento del puerto UDP activo en el NAT

Para mantener el puerto UDP activo nos servimos de un temporizador, que cuando despierta envía mensajes de

refresco hacia el servidor.

Vamos a suponer en el siguiente diagrama (Ilustración 69) el caso en el que tanto servidor, como cliente han

contestado.

Cuando se recibe un mensaje del servidor, se para el temporizador y éste lanza el de esperaCliente, una vez me

llega el primer mensaje de respuesta, paro el temporizador esperaCliente ejecutándose así el método finally del

mismo que lo que hará será lanzar el temporizador esperaRefresco.

Igualmente cada vez que expira esperaRefresco se ejecuta su método finally, y lo que se realiza en ese momento

es la apertura de un nuevo socket y el envío de un mensaje de refresco a través de dicho socket, también se cierra

el socket que estaba anteriormente abierto. El temporizador esperaRefresco estará ejecutándose durante el

tiempo máximo de localización.

Ilustración 69 – Creación del temporizador “esperaRefresco”

116

Ilustración 70 – Activación del temporizador de refresco

7.4.4. Notificaciones de la aplicación

Para mostrarle las notificaciones al usuario usamos el método notify del objeto NotificationManager.

Nuestra aplicación mostrará distintos tipos de notificaciones:

Notificaciones informándonos de error

En este grupo podemos incluir tres tipos de notificaciones:

- Aquellas en las que se nos avisa de que no se ha podido conectar con el servidor. Esto nos

indica que el servidor puede no estar operativo, y por tanto no podrá llevarse a cabo la

localización en dicho momento.

Ilustración 71 – Notificaciones: Error en la conexión con el servidor

- Notificaciones en las que se nos avisa de que no podemos localizar al contacto que

solicitamos. Esto puede ser debido o bien que el contacto que queremos localizar no recibió

nuestro SMS y por tanto no pudo comenzar el proceso de localiación, o que, aun recibiendo

el SMS no dispone de conexión a Internet y por tanto no puede enviar mensajes.

117

Ilustración 72 – Notificaciones: Contacto no disponible

- Notificaciones en las que nos avisan de que no tenemos permiso para obtener la información

de localización del contacto. Esto significa que el contacto al que queremos localizar no nos

tiene en la lista de permitidos, un ejemplo de esta notificación se verá en el apartado 12.4.1.

Notificaciones informándonos del proceso de localización

En este caso igualmente, podemos distinguir tres tipos:

- Notificaciones en las que se le informan al contacto localizado a quién se le va a mandar su

localización.

- Notificaciones sobre la información de localización del usuario, donde se indican el nombre

del contacto al que pertenece la localización, así como sus coordenadas de latitud y longitud.

- Notificaciones de fin de localización, gracias a estas notificaciones sabremos cuándo finaliza

la localización de un contacto. Si queremos seguir recibiendo información de localización de

dicho contacto tras recibir esta notificación, debemos volver a iniciar una solicitud.

Todas estas notificaciones se muestran en los ejemplos del apartado 12.4 del anexo.

7.4.5. Visualización del mapa

Para la visualización del mapa con la posición del usuario en él se usa la clase VerMapaFragment. Para ello

usamos un elemento GoogleMap. Este elemento nos muestra el mapa, y nos da la opción de añadir un marcador

a unas coordenadas dadas o mover el mapa de manera que quede centrado en unas coordenadas específicas.

En la ilustración que vemos a continuación la variable map es de tipo GoogleMap.

Ilustración 73 – Visualización de mapas Android

118

7.4.6. Permisos: AndroidManifest1

El fichero de manifiesto es imprescindible en toda aplicación android, y su nombre debe de ser siempre el mismo:

AndroidManifest.xml. Este fichero contiene información esencial acerca de nuestra aplicación que usará el

sistema operativo de Android para poder ejecutar el código.

A continuación presentaremos los permisos que hemos tenido que incluir en nuestro fichero manifiesto.

Ilustración 74 – Permisos para enviar, leer y recibir SMS

Ilustración 75 – Permisos para realizar operaciones de red

Ilustración 76 – Permisos para acceder a la localización

Ilustración 77 – Permiso para escribir en la memoria externa

Ilustración 78 – Permiso para poder leer los contactos de la agenda

Ilustración 79 – Permiso para acceder al estado del teléfono

Ilustración 80 – Permiso para controlar el estado de “activo” del teléfono

1 Permisos explicados en el glosario, apartado 12.1

119

Este último permiso es de gran importancia ya que en los dispositivos Android, al apagarse la pantalla bien

porque se bloquee, o bien porque no se use durante un tiempo, la CPU se duerme y por tanto sólo se permite la

realización de tareas importantes tales como recepción de llamadas, SMS, etc., de manera que la aplicación

dejaba de enviar y recibir mensajes mientras el teléfono se encontraba bloqueado.

Para solucionar el problema anterior, se obtuvo este permiso y se agregaron las líneas de código necesarias que

permitan que la CPU nunca se duerma aunque se bloquee la pantalla. Así se garantiza que la recepción y envío

de mensajes sigue realizándose de manera correcta, eso sí, a costa de un mayor consumo de batería.

Por último, mostramos un dato que es necesario introducir en el fichero manifiesto para poder ver los mapas de

Google, y es el valor de una clave de Google que se obtiene a través de su consola de desarrollador.

Esta clave una vez obtenida puede utilizarse en distintas aplicaciones que necesiten incorporar mapas.

Ilustración 81 – Clave de Google para poder usar mapas

Ilustración 82 – aplicación registrada en la consola de Google

7.5. Servicio Java

En este punto explicaremos cómo se lleva a cabo el procesamiento de los mensajes que llegan al servidor. Es de

gran importancia este punto ya que este programa es el nexo de unión entre ambas aplicaciones Android (lado

que localiza y lado localizado).

7.5.1. Recepción y procesamiento de los mensajes

En este programa tenemos un proceso que se encuentra de manera continua a la espera de mensajes UDP en el

puerto 4440 (puerto elegido para la escucha, se podría haber elegido cualquier otro).

Al recibir un mensaje, comprueba el tipo del mensaje que le llega, y al igual que en el caso de la aplicación

Android la acción a llevar a cabo dependerá de éste.

- Tipo solicitud o tipo refresco, se guardará un elemento en la lista. Además si el mensaje es de

tipo solicitud, se responderá enviando un mensaje como explicamos en el apartado 7.3.

Ilustración 83 – Actualización de un elemento en el servidor

- Tipo error o respuesta: En este caso, el servidor recorrerá la lista para comprobar si existe en

ella un elemento identificado con el hash recibido. En caso afirmativo enviará el mensaje a la

ip y puerto que haya guardados en la entrada identificada por el hash.

120

Ilustración 84 – Búsqueda de un elemento en el servidor

121

8. PRUEBAS Y VALIDACIÓN

8.1. Pruebas manuales

A continución describiremos el conjunto de pruebas que se han hecho de manera manual, disponiendo para ello

de uno o dos teléfonos con sistema operativo Android, según fue preciso (los nombrados en los apartados 2.2.2.1

y 2.2.2.2).

Prueba Prueba 1

Objetivo Apertura y navegación correcta en la aplicación

Descripción Se abrirá la aplicación y se navegará por todas sus partes. También se introducirán

cambios en la orientación de la pantalla, comprobando que no afectan ni al diseño ni al

funcionamiento de la misma.

Resultado Superada

Tabla 64 – Pruebas manuales: Prueba 1

Prueba Prueba 2

Objetivo Comprobación del acceso a la agenda

Descripción Se entrará en la sección de la aplicación que nos permite el acceso a la agenda. Se

comprobará que aparecen todos los contactos esperados, y que se puede realizar un filtro

correcto por nombre.

Resultado Superada


Prueba Prueba 3

Objetivo Agregar contactos a las listas

Descripción Situados en la página que nos muestra la agenda, comprobaremos que al mantener pulsado

sobre un contacto se nos permite agregarlo a las listas “Localizados” o “Permitidos”.

Agregaremos un contacto cualquiera a dichas listas, y posteriormente comprobaremos que

se encuentran agregados en las listas correspondientes.

Resultado Superada


122

Prueba Prueba 4

Objetivo Eliminación de contactos en las listas

Descripción Nos situaremos en las listas “Localizados” y “Permitidos” y borraremos algún contacto de

ellas. Comprobaremos que tras hacer esto, el contacto no aparece en la lista de la cuál se

borró.

Resultado Superada


Prueba Prueba 5

Objetivo Visualización de la localización propia

Descripción Accederemos a la parte de la aplicación que nos muestra el mapa con nuestra localización

y comprobaremos que, efectivamente, se muestra correctamente cuando tenemos el gps

activo, o nos muestra las coordenads y dirección como “No disponible” cuando no se

encuentra activo.

Resultado Superada


Prueba Prueba 6

Objetivo Comprobar que la aplicación deja de esperar respuesta del servidor pasado un tiempo, y

avisa al usuario de que no se pudo realizar la localización

Descripción Se lanzará desde un teléfono la solicitud de localización, pero el programa del servidor no

se estará ejecuando, pasado el tiempo de espera máximo del servidor, el teléfono que

lanzo la solicitud debe parar la escucha y

Resultado Superada


Prueba Prueba 7

Objetivo Comprobación del tiempo de espera del cliente

Descripción Prueba análoga a la anterior, pero en este caso se desconecta el wifi del teléfono

localizado, pasado el tiempo de espera del cliente, deberá pararse la escucha del teléfono

que solicita y se le deberá notificar al usuario de que no se ha podido realizar la

localización del contacto.

Resultado Superada


123

Prueba Prueba 8

Objetivo Comprobar que no se puede localizar a una persona que ya está siendo localizada

Descripción Se comenzará la localización de un contacto concreto. Después, se volverá a realizar otra

solicitud sobre el mismo contacto, y se comprobará que no se puede volver a localizar.

Resultado Superada


Prueba Prueba 9

Objetivo Funcionamiento cuando el contacto no está en la lista de permitidos

Descripción Se lanzará la localización de un contacto que no tenga al usuario que solicita en la lista de

permitidos. Se comprobará que el mensaje de respuesta que le llegará será de tipo “error”

Resultado Superada


Prueba Prueba 10

Objetivo Comprobar el correcto envío y recepción de los mensajes de localización

Descripción Se lanzará la localización de un contacto dado que si tenga al usuario solicitante en su lista

de permitidos. Se comprobará que los mensajes periódicos se envían correctamente y se

reciben por tanto en el destino.

Resultado Superada


Prueba Prueba 11

Objetivo Comprobar la continuidad en el proceso de localización ante cambios en las IPs, tanto del

localizado como del que localiza.

Descripción Se lanzará la localización de un usuario, y se irá alternando entre uso de datos y red wifi

en ambos extremos de la comunicación. El envío y recepción de mensajes debe de

realizarse de manera correcta.

Resultado Superada


124

Prueba Prueba 12

Objetivo Comprobar la correcta visualización del contacto localizado en el mapa.

Descripción Se lanzará la localización de un usuario concreto y, al recibir notificaciones, se pulsará

sobre ellas, comprobando así que la información de localización de dicho usuario se

muestra de manera correcta en el mapa.

Resultado Superada


Prueba Prueba 13

Objetivo Comprobar la localización de más de una persona simultáneamente

Descripción Se lanzará la localización de dos personas distintas, y se comprobará que nos llegan

notificaciones independientes para cada una de ellas, y que se puede ver la información de

localización de esas personas de manera adecuada e independiente en el mapa.

Resultado Superada


Prueba Prueba 14

Objetivo Extracción correcta de los datos del SMS

Descripción Se comprobará tanto por el uso de logs mostrando el contenido de las variables que

guardan la información del sms, como por el correcto funcionamiento de la aplicación ya

que es un reflejo de que se han extraído bien los datos del sms.

Resultado Superada


Prueba Prueba 15

Objetivo Continuidad de la localización ante una pérdida

Descripción Ante la pérdida de un paquete debido a que alguno (o ambos) extremos pierdan la

conexión a la red, una vez recuperada dicha conexión se deberá reanudar correctamente el

envío y recepción de paquetes.

Resultado Superada


Prueba Prueba 16

125

Objetivo Comprobar la correcta configuración del servidor y puerto a usar

Descripción En la parte de la aplicación de “Configuración Avanzada”, se comprobará que sólo se

permitirá guardar la nueva información cuando los campos no estén vacíos, y además,

sean correctos.

Resultado Superada

Tabla 79 – Pruebas manuales: Prueba 16.

Prueba Prueba 17

Objetivo Comprobar que no se puede conectar a un servidor inexistente

Descripción En la parte de la aplicación de “Configuración Avanzada”, se comprobará que en caso de

introducir una IP y puerto de un servidor que no existe, se mostrará la notificación de “No

se pudo conectar con el servidor”, y que no se produzca la detención de la aplicación.

Resultado Superada

Tabla 80 – Pruebas manuales: Prueba 17.

8.2. Purebas automatizadas

Para este conjunto de pruebas se han diseñado en java unos módulos de prueba se simulan el envío y recepción

de mensajes UDP. Para todas estas pruebas se ha tomado un tiempo máximo de envío y recepción de 35 minutos.

Prueba Prueba 18

Objetivo Envío de mensajes con una periodicidad dada (5, 15 y 30 mins)

Descripción Se lanzará una solicitud de localización, y se esperará que el módulo de pruebas que envía

mensajes hacia el teléfono lo haga con las periodicidades nombradas.

Resultado Superada

Tabla 81 – Pruebas automatizadas: Prueba 182

Prueba Prueba 19

Objetivo Recepción de mensajes con una periodicidad dada

Descripción En este caso el módulo de pruebas será el receptor, y se comprobará que el teléfono le

envia correctamente los mensajes UDP periódicos.

Resultado Superada

2 Se puede ver el resultado de esta prueba en el punto 12.2.1 del anexo

126

Tabla 82 – Pruebas automatizadas: Prueba 193

8.3. Pruebas de aceptación

En esta prueba se evaluará la calidad del producto en función del uso para el que fue diseñado e implementado.

Prueba Prueba 20

Objetivo Validación el producto final por parte del tutor

Descripción Se le entregará el producto final al tutor del proyecto, de manera que éste lo pruebe, y

determine si realmente cumple las expectativas planteadas.

Resultado Superada

Tabla 83 – Pruebas de aceptación: Prueba 20

3 Se puede ver el resultado de esta prueba en el punto 12.2.2 del anexo

127

9. ESTIMACIÓN TEMPORAL

ste proyecto ha estado dividido en una serie de tareas. Estas tareas fueron identificadas y se les asignó un

tiempo determinado así como se planificó la secuencia de ejecución de las mismas para intentar conseguir

que el tiempo de desarrollo fuese el mínimo.

En este apartado veremos cuál fue la planificación inicial que se hizo del proyecto y la compararemos con la

estimación temporal real.

9.1. Estimación temporal a priori

Documentación 92 horas

Documentación de Android 90 horas

Plataformas de desarrollo: Androuid Studio vs Eclipse 2 horas

Tabla 84 – Estimación a priori: Documentación

Obtención de información 12 horas

Comprensión del problema 2 horas

Estudio del Objetivo del sistema 3 horas

Obtención de requisitos del sistema 7 horas

Tabla 85 – Estimación a priori: Obtención de información

Análisis 7 horas

Identificación de subsistemas y su función 7 horas

Tabla 86 – Estimación a priori: Análisis

Diseño 39 horas

Diseño del servicio 27 horas

Diseño de la interfaz de usuario 2 horas

Diseño de las clases 10 horas

Tabla 87 – Estimación a priori: Diseño.

E

128

Implementación 90 horas

Codificación de las clases 60 horas

Codificación de las pruebas 30 horas

Tabla 88 – Estimación a priori: Implementación

Testeo y pruebas 45 horas

Pruebas manuales 10 horas

Pruebas automatizadas 5 horas

Corrección de errores 30 horas

Tabla 89 – Estimación a priori: Testeo y pruebas

Documentación final 70 horas

Redacción de la memoria 70 horas

Tabla 90 – Estimación a priori: Documentación final

Horas totales 355 horas

Tabla 91 – Estimación a priori: Horas totales

129

Ilustración 85 – Estimación a priori: Diagrama de Gantt

9.2. Planificación temporal real

Documentación 122 horas

Documentación de Android 80 horas

Documentación Java 40 horas

Plataformas de desarrollo: Androuid Studio vs Eclipse 2 horas

Tabla 92 – Estimación real: Documentación

Obtención de información 10 horas

Comprensión del problema 2 horas

Estudio del Objetivo del sistema 3 horas

Obtención de requisitos del sistema 5 horas

Tabla 93 – Estimación real: Obtención de información

Análisis 15 horas

Identificación de subsistemas y su función 15 horas

130

Tabla 94 - Estimación real: Análisis

Diseño 67 horas

Diseño del servicio 50 horas

Diseño de la interfaz de usuario 2 horas

Diseño de las clases 15 horas

Tabla 95 – Estimación real: Diseño

Implementación 112 horas

Codificación de las clases Android 70 horas

Codificación de las clases Java 35 horas

Codificación de las pruebas 7 horas

Tabla 96 – Estimación real: Implementación

Testeo y pruebas 80 horas

Pruebas manuales 21 horas

Pruebas automatizadas 9 horas

Corrección de errores 50 horas

Tabla 97 – Estimación real: Testeo y pruebas

Documentación final 80 horas

Redacción de la memoria 80 horas

Tabla 98 – Estimación real: Documentación final

Horas totales 486 horas

Tabla 99 – Estimación real: Horas totales

131

Ilustración 86 – Estimación real: Diagrama de Gantt

132

10. CONCLUSIONES

10.1. Principales problemas enfrentados

A lo largo de todo el proceso de desarrollo hemos encontrado diversos problemas a los que hicimos frente. A

continuación se resumirán dichos problemas así como la solución aportada.

El primer problema que surgió fue el encaminamiento de los mensajes UDP, ya que tanto el emisor de mensajes

como el receptor de los mismos tenían asignadas direcciones IP privadas. Para ello fue necesario incluir en

nuestro sistema un programa intermedio, el servidor nombrado durante la memoria, que guarda la relación hash–

IP,puerto de manera que pueda encaminar los mensajes correctamente.

Otro problema enfrentado fue el de la expiración de las entradas en la tabla del NAT, ya que como mecanismo

de seguridad pasado cierto tiempo sin recibir paquetes provenientes del dominio interno (5 minutos por defecto

para puertos UDP) se eliminaba la entrada correspondiente a dicho puerto, haciendo imposible que llegasen los

mensajes de respuesta de localización pasados esos primeros 5 minutos. Para solucionar este inconveniente

incluimos los mensajes de refresco.

Por último, nos encontramos con un problema de los dispositivos Android, ya que cuando éstos se encontraban

bloqueados, o con la pantalla apagada dejaban de enviar y recibir mensajes. Luego, al desbloquear la pantalla se

reanudaba el envío y recepción. Esto es así porque en estos dispositivos al apagar la pantalla el procesador

“duerme”, y sólo mantiene activas las funciones necesarias como son recepción de llamadas telefónicas o SMS.

Para solucionar esto se tuvo que introducir las líneas adecuadas en el código para evitar que la CPU entre en

dicho modo, permitiendo así que se siguiese ejecutanto el código tanto de envío como de recepción de paquetes.

10.2. Línea futura de desarrollo

La aplicación desarrollada cumple con la función y requisitos especificados, sin embargo, y debido al tiempo

limitado del desarrollo, se pueden encontrar futuras mejoras para llevar a cabo sobre la misma.

Se puede plantear una mejora de esta aplicación solucionando el problema de tarificación, de manera que

podamos evitar el envío inicial del SMS. Esto podría conseguirse mediante el uso de protocolos de mensajería

instantánea como por ejemplo XMPP, en el cuál los teléfonos al encenderse iniciaran sesión en el servidor y

envíarían su localización de manera periódica al mismo, y éste lo almacenaría en una base de datos, junto con

otros datos como pueden ser: nombre de contacto, teléfono, contactos que permite, etc. De esta manera cuando

un usuario desee conocer la localización de otro contacto realizará una petición a dicha base de datos para obtener

la última conocida, o un mensaje de error en caso de no ser un contacto permitido. Este método requeriría un

registro previo en dicho servidor.

Igualmente se podría considerar la posibilidad de seguir localizando al terminal a pesar de que éste no tenga

tarjeta SIM, que sea un teléfono únicamente con conexión a Internet y GPS. En este caso necesitaríamos también

una base de datos, y el usuario que desea localizar debe introducir, mediante un formulario, el nombre de usuario

con el que está registrado en el servidor el usuario que desea localizar, así como la clave para obtener su

localización, comunicada previamente mediante otra vía. Ante esta petición se comprobaría que el nombre de

usuario del que se solicita la localización es usuario del servicio, y si además la clave para dicho usuario coincide

con la clave recibida. Considerando esta situación, al igual que en el caso anterior se le enviaría al usuario

solicitante la última posición conocida del usuario solicitado.

Una limitación actual de la aplicación es que sólo está pensada para localizar a teléfonos Españoles, de la forma

(+34)-9 dígitos. Por lo que sería interesante ampliar esta localización independientemente del número de teléfono

de los extremos. Esto lo podríamos implementar almacenando los códigos de países en una base de datos, y

sabiendo que todos los teléfonos tienen 15 dígitos (Ilustración 87) procesarlo y separar lo que es código de país

y lo que es el número de teléfono.

133

Ilustración 87 - Número UIT-T E.164 internacional para Redes.

Derivada de la anterior mejora, si se cubrieran los números de todos los países, necesitaríamos que nuestra

aplicación soportase distintos idiomas, para una experiencia de usuario satisfactoria en cada región.

Para añadir soporte de nuevos lenguajes necesitamos crear directorios de “values” adicionales, dentro de nuestra

carpeta de recursos /res. Cada directorio values acabará con el código del lenguaje según la ISO4. Android

cargará el recurso adecuado en tiempo de ejecución en función de la configuración local del dispositivo.

Ilustración 88 – Estructura del proyecto que soporta varios lenguajes

El contenido del fichero strings que contiene las cadenas en español podría ser, por ejemplo:

Ilustración 89 – values-es/strings.xml

Mientras que el contenido del fichero que contiene las cadenas correspondientes al idioma francés, sería:

4 Language codes – ISO 639

134

Ilustración 90 – values-fr/strings.xml

En cuanto a seguridad, y debido a que nuestra aplicación transporta datos de tipo sensible como son las

coordenadas de latitud y longitud de un usuario concreto podría plantearse la encriptación de dichos datos y su

posterior desencriptación en el destino. Dos posibles alternativas para hacer frente a esto pueden ser:

Protocolo DTLS (Datagram Transport Layer Security)

Se trata de un protocolo basado el TLS que proporciona privacidad en las comunicaciones para protocolos de

datagramas. Este protocolo permite a las aplicaciones cliente/servidor comunicarse de manera que se eviten las

escuchas no deseadas (eavesdropping), accesos no permitidos, o modificación de mensajes. Este protocolo

proporciona garantías de seguridad equivalentes a TLS.

DTLS y su uso junto con el protocolo UDP queda definido en la RFC 6347.

Paquete javax.crypto

Este paquete proporciona las clases e interfaces para aplicaciones criptográficas implementando algoritmos de

cifrado, descifrado, o acuerdo de clave.

La autenticación puede basarse en MAC (Message Authentication Code), tales como HMAC (Hash MAC, es

decir, con una función hash SHA-1).

Por último, también podríamos considerar la posibilidad de adaptar esta aplicación a distintas plataformas, ya

que actualmente sólo estaría disponible para dispositivos con el sistema operativo Android.

10.3. Conclusión personal

Con la realización de este proyecto se me ha permitido completar mi formación enfrentándome a un problema

de cierta complejidad, teniendo que aportar soluciones a los problemas que surgían e investigar formas de

solucionarlos.

Con este ptoyecto no sólo he mejorado en tecnologías poco estudiadas durante la carrera como son Java y

Android, si no que también me he adentrado en la Ingeniería de software aprendiendo la importancia de una

buena planificación, diseño e identificación de requisitos.

Este ha sido un proyecto en el que he disfrutado trabajando y aprendiendo cosas nuevas, tanto en aspectos de

conocimientos como aspectos de desenvoltura a la hora de enfrentar un problema real y dar una solución al

mismo aportando mis conocimientos tecnológicos.

135

11. REFERENCIAS

[1] Documentación Android: http://developer.android.com/index.html

[2] Documentación Google APIs para Android:

https://developers.google.com/android/reference/com/google/android/gms/maps/MapFragment

[3] http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf

[4] https://eclipse.org/

[5] http://docs.oracle.com/javase/8/docs/api/

[6] http://download.java.net/jdk7/archive/b123/docs/api/java/net/DatagramSocket.html

[7] “Cómo programar en Java”. Paul Deitel, Harvey Deitel.

[8] http://stackoverflow.com/

[9] http://www.idc.com/getdoc.jsp?containerId=prUS24676414

[10] http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html

[11] http://tools.ietf.org/html/rfc4787#section-4.3

[12] https://tools.ietf.org/html/rfc5128#section-3.3.1

[13] ITU – Recomendación E.164 : Plan internacional de numeración de telecomunicaciones públicas:

https://www.itu.int/rec/T-REC-E.164-201011-I/es

[14] Language Codes - ISO 639: http://www.iso.org/iso/es/home/standards/language_codes.htm

[15] DTLS: https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security

[16] http://www.brynosaurus.com/pub/net/p2pnat/

http://developer.android.com/index.html

https://developers.google.com/android/reference/com/google/android/gms/maps/MapFragment

http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf

https://eclipse.org/

http://docs.oracle.com/javase/8/docs/api/

http://download.java.net/jdk7/archive/b123/docs/api/java/net/DatagramSocket.html

http://stackoverflow.com/

http://www.idc.com/getdoc.jsp?containerId=prUS24676414

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html

http://tools.ietf.org/html/rfc4787#section-4.3

https://tools.ietf.org/html/rfc5128#section-3.3.1

https://www.itu.int/rec/T-REC-E.164-201011-I/es

http://www.iso.org/iso/es/home/standards/language_codes.htm

https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security

http://www.brynosaurus.com/pub/net/p2pnat/

136

12. ANEXO

12.1. Glosario de términos

A continuación vamos a definir una serie de términos propios de la programación Android que hemos usado en

la redacción de la memoria.

Activity: Son las clases Android. Representa una acción que puede realizar el usuario. Las activities se

encargan de colocar la ventana dónde luego se podrá poner la interfaz de usuario. Todas las actividades

de una aplicación deben de estar recogidas en el fichero AndroidManifest.

AsyncTask: esta clase nos permite usar el hilo UI de manera correcta y fácil. Nos permite ejecutar tareas

en segundo plano y mostrar los resultados en la interfaz de usuario.

BroadcastReceiver: Clase base para el código que recibirán los Intents enviados por sendBroadcast().

Hay dos tipos principales de clases broadcast que pueden recibirse:

- Broadcast normales (enviados con Context.sendBroadcast) son completamente asíncronos.

Todos los receptores de la emisión se ejecutan en un orden definido, a menudo al mismo

tiempo. Esto es más eficiente, pero significa que los receptores no pueden utilizar el resultado

o abortar APIs incluidas aquí.

- Broadcast normales (enviados con Context.sendBroadcast) son completamente asíncronos.

Todos los receptores de la emisión se ejecutan en un orden definido, a menudo al mismo

tiempo. Esto es más eficiente, pero significa que los receptores no pueden utilizar el resultado

o abortar APIs incluidas aquí.

En nuestro caso utilizamos esta clase para recibir los SMS que envía la aplicación.

Content provider: los proveedores de contenido gestionan el acceso a un conjunto de datos

estructurados. Encapsulan los datos y nos proporcionan mecanismos para definir la seguridad de los

datos. Se trata de la interfaz estándar para conectar los datos de un proceos con el código ejecuntándose

en otro proceso. En nuestro caso, utilizamos un content provider para el acceso a los contactos de la

agenda.

Context: Interfaz con información global sobre un entorno de aplicación. Ésta es una clase abstracta

cuya implementación está prevista por el sistema Android. Permite el acceso a los recursos y las clases

específicas de la aplicación, así como la puesta en marcha de las operaciones a nivel de aplicación, tales

como el lanzamiento de las actividades, la difusión y recepción de las intenciones, etc...

Contract class: es una clase que nos define constantes que ayudan a las aplicaciones a trabajar con URIs,

nombres de columnas, acciones de Intent y otras características de los content provider. En nuestro caso,

nuestras Contract Class lo que nos definen son los nombres de las columnas de nuestras tablas de la

base de datos, para poder acceder a ellas de manera sencilla en cualquier parte del código.

Fragment: reperesenta el comportamiento de una porción de la interfaz de usuario de una Activity. Se

pueden combinar múltiples fragments en una única actividad para construir una aplicación con

múltiples interfaces. También los fragments se pueden reutilizar en otras Activities.

Los fragments tienen su propio ciclo de vida, reciben sus propios eventos de entrada y se pueden añadir

a la interfaz de usuario en tiempo de ejecución.

Geocoder: es una clase para manejar la geocodificación y la geocodificación inversa. El proceso de

“Geocoding” es el de transformar una dirección (calle) u otra descripción de localización en

coordenadas de latitud y longitud. “Geocoding inverso” es el proceso contrario, con el que a partir de

unas coordenadas de latitud y longitud pasamos a una dirección en forma de calle.

Geofencing: es una caracaterística software de los programas que usan el GPS o identificación por radio frecuencia (RFID) para definir fronteras geodráficas.

137

googleApiClient: es el principal punto de entrada para la integración de servicios de GooglePlay.

GoogleMap: es la clase principal de la Api de Google Maps de android, es el punto de entrada para

todos los métodos relacionados con el mapa de la aplicación. Obtenemos un objeto de este tipo mediante

el método getMap().

Intent: se trata de una descripción abstracta de una operación que debe realizarse. Su uso más frecuente

es para lanzar actividades mediante startActivity(Intent).

IntentService: es la clase base para los servicios que manejan peticiones asíncronas bajo demanda. Los

clientes envían peticiones a través del método startService(Intent). El servicio comienza cuando se

necesita, gestiona cada Intent en su turno, y cuando termina se para él solo. Sólo una solicitud va a ser

atendida a la vez.

LatLng: clase que representa el par de coordenadas latitud y longitud, almacenadas en grados.

MapFragment: un componente de tipo Mapa (Map) en una aplicación. Esta es la forma más sencilla de

colocar el mapa en la aplicación.

NotificationManager: clase para notificar al usuario de eventos que sucede. Es la forma que se tiene para avisar al usuario de aquellos eventos que sucenden en background.

onHandleIntent: método que se invoca en el hilo de trabajo del IntentService cuando tiene una petición

que atender.

Permisos:

- READ_CONTACTS: permite a la aplicación leer los datos de los contactos del usuario.

- ACCESS_COARSE_LOCATION: permite a la aplicación acceder a la localización

aproximada.

- ACCESS_FINE_LOCATION: permite a la aplicación en acceso a una localización más

precisa.

- SEND_SMS: permite a la aplicación el envío de SMS

- READ_SMS: permite a la aplicación la lectura de SMS

- RECEIVE_SMS: permite a la aplicación monitorizar los mensajes que llegan, almacenarlos

o procesarlos.

- INTERNET: permite a la aplicación abrir sockets.

- ACCESS_NETWORK_STATE: permite a la aplicación acceder a la información de red.

- READ_PHONE_STATE: permite leer el estado del teléfono.

- WRITE_EXTERNAL_STORAGE: permite a la aplicación escribir en el almacenamiento

externo.

- WAKE_LOCK: permite usar el PowerManager para mantener funcionando el procesador

ante el bloqueo o apagado de la pantalla.

PowerManager: esta clase nos da el control sobre el estado de la alimentación del dispositivo.

SQLiteOpenHelper: Clase que nos ayudará a gestionar la creación de la base de datos y la gestión de

versiones.

TelephonyManager: Nos proporciona acceso sobre los servicios de telefonía del dispositivo y su estado.

Toast: es una clase que ayuda a mostrar una vista de Android llamada toast que contiene un mensaje

rápido y pequeño para el usuario. Cuando la vista se muestra al usuario, aparece como una vista flotante

sobre la aplicación. La idea es ser lo más discreto posible, sin dejar de mostrar al usuario la información

que desea. Dos ejemplos son el control de volumen, y el breve mensaje diciendo que los ajustes se han

guardado.

138

12.2. Resultado de pruebas automatizadas

12.2.1. Prueba 15

En las siguientes capturas veremos los mensajes del módulo de pruebas qure recibe nuestra aplicación, el

primero de ellos con un periodo de 5 minutos entre mensajes, el siguiente de 15 y el último de 30minutos. Las

pruebas se han hecho para un tiempo total de 35 minutos.

Ilustración 91 – Prueba 15: mensajes cada 5 minutos

139



En esta última prueba el tiempo entre mensajes es cada 30 minutoss, como el tiempo total de localización son

35 minutos sólo nos llega un mensaje UDP antes de cerrar el socket de escucha y terminar la localización.

140

12.2.2. Prueba 16

En este caso, el modulo de pruebas consiste en un receptor UDP, que recibirá los mensajes provenientes del

teléfono.

Para iniciar el proceso de localización, se le envío al dispositivo el SMS que se ve en la Ilustración 94, tras el

cuál ya comenzó el envío de mensajes de localización.

Ilustración 94 – Prueba 16: SMS para comenzar (periodo 5 minutos)

Ilustración 95- Prueba 16: Recepción de localización cada 5 minutos

Ilustración 96 – Envío de SMS para comenzar (cada 15 minutos)

141

Ilustración 97 – Prueba 16: Recepción de mensajes cada 15 minutos

Ilustración 98 – Envio de SMS para comenzar (cada 30 minutos)

Ilustración 99 – Prueba 16: Recepción de mensajes cada 30 minutos

142

12.3. Manual de usuario

12.3.1. Instalación

Tenemos dos formas de instalar nuestra aplicación, que se encuentra en forma de archivo .apk:5

- La primera forma es descargando directamente la aplicación en nuestro teléfono, y úna vez

en él, al pulsar sobre ella comenzará la instalación de la misma.

- La segunda de ellas es transfiriendo desde nuestro PC a nuestro teléfono o Tablet android

dicho .apk, mediante un cable USB, y lo colocamos en nuestra tarjeta SD. Una vez allí lo

ejecutamos y se realizará la instalación.

Una vez entramos en la instalación de la aplicación, nos avisa de todos los permisos que necesita, como se ve

en las ilustraciones 90 y 91.

Ilustración 100 – Instalación: Permisos de la aplicación (I)

5 Es necesario indicarle a Android que permita la instalación de aplicaciones fuera del Google Play (Ajustes>Seguridad>Orígenes desconocidos).

143

Ilustración 101 – Instalación: Permisos de la aplicación (II)

Finalmente, pulsamos “Instalar” y tendremos la aplicación en nuestro dispositivo.

Ilustración 102 – Instalación: Aplicación instalada

144

12.3.2. Vista principal de la aplicación

Al iniciar la aplicación lo primero que no encontraremos será con un Splash de bienvenida que dará paso a la

página principal.

Ilustración 103 – Manual de usuario: Splash de bienvenida

En la siguiente imagen se muestra la página principal de la aplicación con la funcionalidad de cada uno de los

botones.

145

Ilustración 104 – Manual de usuario: Página principal

12.3.3. Acceso a Agenda para agregar contactos

Ilustración 105 – Manual de usuario: Acceso a los contactos de la agenda

146

Ilustración 106 – Manual de usuario: Filtrado de contactos por nombre

Para agregar un contacto de los de la agenda a una de las listas que tenemos, debemos mantener pulsado sobre

dicho contacto, y entonces aparecerá un menú en el que podremos seleccionar la lista en la que queremos

introducir un usuario. No podremos agregar al un usuario dos veces a una misma lista.

147

Ilustración 107 – Manual de usuario: Agregar contactos a las listas

12.3.4. Eliminar un contacto de la lista de Localizados

Ilustración 108 – Manual de usuario: Eliminación de un contacto que localizamos

148

Tras pulsar en el botón de “Eliminar Contacto” nos aparecerá una confirmación de la eliminación, y veremos

que ya no aparece dicho contacto en la lista.

Ilustración 109 – Manual de usuario: Confirmación de eliminación

12.3.5. Eliminar un contacto de la lista de Permitidos

Para ello nos situamos en nuestra lista de contactos permitidos, y mantenemos pulsado sobre el contacto que

queremos eliminar. Nos aparecerá un menú, en el que seleccionaremos la única opción que hay: “Eliminar

contacto”.

149

Ilustración 110 – Manual de usuario: Eliminar contacto permitido

Tras haber pulsado en dicho botón, nos aparecerá, al igual que en el caso anterior, una confirmación de la

eliminación del contacto. Y no nos aparecerá dicho contacto en la lista de permitidos.

Ilustración 111- Manual de usuario: Confirmación de eliminación de contacto Permitido

150

12.3.6. Ver la localización propia

Para ello debemos de pulsar sobre el botón “Ver mi localización” situado en el menú superior de la aplicación.

Este botón será accesible desde cualquier parte de la aplicación, excepto en la pantalla de agregar contactos.+

Ilustración 112 – Manual de usuario: Acceso a localización propia

151

Ilustración 113 – Manual de usuario: Visualización de localización propia

En caso de no tener activo el gps del teléfono nos aparecerá lo siguiente al intentar ver nuestra localización.

Ilustración 114 – Manual de usuario: Localización propia no disponible

152

12.3.7. Solicitar la localización de un contacto

Para ello nos situaremos en la lista de contactos que queremos localizar, es decir, me voy a la sección “Localizo

a…” de la aplicación.

Una vez allí, volvemos a seleccionar un contacto, y elegimos la opción de “Comenzar a Localizar”.

Ilustración 115 – Manual de usuario: Comienzo de la localización

Tras pulsar en el botón de “Comenzar a Localizar” tendremos la opción de elegir el tiempo con el que deseamos

recibir notificaciones del contacto. En caso de no seleccionar ninguna opción, se tomará por defecto un tiempo

de 5 minutos.

153

Ilustración 116 – Manual de usuario: Elección del tiempo entre notificaciones

12.3.8. Configuración del servidor a usar

En esta sección de la aplicación, se le ofrece la oportunidad al usuario de poder modificar la IP y puerto del

servidor al que se conecta.

Al abrir la configuración, aparecerán la IP y puerto usados actualmente, el usuario podrá borrarlos, e introducir

los nuevos valores que desee.

154

Ilustración 117 – Manual de usuario: Configuración Avanzada

En las siguientes ilustraciones mostraremos los posibles errores en la introducción de los valores IP y puerto.

Ilustración 118 – Manual de usuario: Configuración Avanzada-campos vacíos

155

Ilustración 119 – Manual de usuario: Configuración Avanzada-IP vacía

Ilustración 120 – Manual de usuario: Configuración Avanzada-Puerto vacío

156

Ilustración 121 – Manual de usuario: Configuración Avanzada-Puerto no numérico.

Ilustración 122 – Manual de usuario: Configuración Avanzada-Puerto fuera de rango

157

Finalmente, si los datos son correctos se guardarán.

Ilustración 123 – Configuración Avanzada: IP y puerto correctos

158

Ilustración 124 – Configuración Avanzada: Guardando cambios

12.4. Ejemplos de funcionamiento

12.4.1. Localizar a un contacto

No se permite la localización

Estamos en el caso en el que el contacto que se quiere localizar no nos tiene agregados a su lista de contactos

permitidos, en este caso recibiremos un mensaje de error.

Ilustración 125 – Localizar a un contacto: Notificación error

Si desplegamos la notificación, entonces podremos ver el contenido de la misma:

159

Ilustración 126 – Localizar a un contacto: Detalle de la notificación de error

Se permite la localización

En este caso se nos permite conocer la localización del contacto, y por tanto, recibimos de manera periódica

mensajes de localización. Para este ejemplo, hemos tomado como tiempo entre notificaciones 5 minutos.

Lanzamos la solicitud y seleccionamos el tiempo como vimos en el apartado 12.3.7 y obtenedremos un resultado

como el que se muestra:

Ilustración 127 – Localizar a un contacto: Notificaciones

Si desplegamos las notificaciones podremos ver el contenido de las mismas:

160

Ilustración 128 – Localizar a un contacto: Detalle de las notificaciones

Si pulsamos sobre cualquiera de las notificaciones con contenido de localización, podremos visualizar la

posición del contacto en el mapa, como vemos en la siguiente imagen.

161

Ilustración 129 – Localizar a un contacto: Ver mapa

Por su parte, en el extremo que va a ser localizado, se genera una notificación para informarle a quién se le está

enviando su localización.

Ilustración 130 – Localizar a un contacto: Notificación en el extremo localizado

162

12.4.2. Localización de dos contactos

Para este caso vamos a realizar la localización de dos contactos simultáneamente. Localizaremos a uno de ellos

con un tiempo entre notificaciones de 5 minutos, y al otro con un tiempo de 15 minutos.

En las siguientes imágenes mostraremos la vista con todas las notificaciones en la parte superior del teléfono

(Ilustración 131), la notificación de fin de localización (Ilustración 132), el tiempo entre notificaciones para cada

contacto (Ilustración 133) y por último dos ilustraciones correspondientes a los mapas con la localización de

cada contacto (Ilustración 134 e Ilustración 135).

Ilustración 131 – Localización de dos contactos: Notificaciones

Ilustración 132 – Localización de dos contactos: Aviso de fin de localización

163

Ilustración 133 – Localización de dos contactos: tiempo entre notificaciones

Ilustración 134 – Localización de un contacto: Mapa del contacto 1

164

Ilustración 135 – Localización de dos contactos: Mapa del contacto 2

Al igual que en el ejemplo anterior, se generan notificaciones para avisar a los contactos que van a ser localizados

a quién envían su localización, como se muestra a continuación.

Ilustración 136 - Localización de dos contactos: notificación en el extremo localizado (contacto 1)

Ilustración 137 – Localización de dos contactos: notificación en el extremo localizado (contacto 2)

Documents

Trabajo Fin de Grado Grado en Ingeniería de las ...bibing.us.es/proyectos/abreproy/90265/fichero/TFG-Priscila_Crespo_Bolaños.pdf · 3 Trabajo Fin de Grado Grado en Ingeniería de